3 ms·

If you have a long running branch, you're going to have conflicts. When you resolve those conflicts during a rebase, you lose your history of the conflict reso

If you have a long running branch, you're going to have conflicts. When you resolve those conflicts during a rebase, you lose your history of the conflict resolution. What you're thinking of as a "simple linear history" is actually not. Notice that when you rebase there are new hashes for each of your commits. If you're rebasing your branch with master and resolving merge conflicts along the way, you're going to get bit eventually. Even if you're somehow not dealing with merge conflicts, you're losing your ability to look at the git log and figure out when the last time you synced up with master was.

kazinator 7y ago
You can have conflicts even if you have a single-commit local change, that's less than an hour old. Long running branches are a bad idea. Try not to do that. Not everything in a long running branch can be merged; selective things will end up cherry-picked (which is a generalization of rebase). Suppose the trunk maintainers like 75% of what was done in the branch. They might go through the commits one by one and take what is relevant. When you merge a branch, and want to follow a good SCM process, you must treat it as a closed topic; do not commit anything more to that branch. Start a new branch, even for a closely-related continuation of the same work. The correct way to merge a branch is to rework every single commit onto the new baseline. That is true whether that rework is represented as a merge, or a cherry-pick. Therefore, we can't avoid the issue that every change turns into a new object with a different hash. What we can do is put tracking information in the commit message to correlate these together. The Gerrit review system uses a Change-Id: line for this. Each commit has random ID which is not a content digest; it stays the same across cherry picks. If I'm debugging a problem on trunk T, across some commits that came from a branch R, I do not care what those commits looked like in R. Only in a very rare case will I be interested how a change looked like there. I want every commit that came from R to be reworked on T, as if it was originally developed on T. If I find the problem and have a hunch that it was introduced during the merge, then I might out of curiosity find the commit's cousin in the original R branch just to see how it looked like there. Other than that, I'm shipping T, not R, so that's what I'm debugging.

kazinator 7y ago

You can have conflicts even if you have a single-commit local change, that's less than an hour old. Long running branches are a bad idea. Try not to do that. Not everything in a long running branch can be merged; selective things will end up cherry-picked (which is a generalization of rebase). Suppose the trunk maintainers like 75% of what was done in the branch. They might go through the commits one by one and take what is relevant. When you merge a branch, and want to follow a good SCM process, you must treat it as a closed topic; do not commit anything more to that branch. Start a new branch, even for a closely-related continuation of the same work. The correct way to merge a branch is to rework every single commit onto the new baseline. That is true whether that rework is represented as a merge, or a cherry-pick. Therefore, we can't avoid the issue that every change turns into a new object with a different hash. What we can do is put tracking information in the commit message to correlate these together. The Gerrit review system uses a Change-Id: line for this. Each commit has random ID which is not a content digest; it stays the same across cherry picks. If I'm debugging a problem on trunk T, across some commits that came from a branch R, I do not care what those commits looked like in R. Only in a very rare case will I be interested how a change looked like there. I want every commit that came from R to be reworked on T, as if it was originally developed on T. If I find the problem and have a hunch that it was introduced during the merge, then I might out of curiosity find the commit's cousin in the original R branch just to see how it looked like there. Other than that, I'm shipping T, not R, so that's what I'm debugging.