Git freebase
ericrie.se
ericrie.se
If that's the case, a solution that would categorically lose less information would be:
1. You're going to push branch you/whatever
2. You rebase you/whatever on on master
3. You solve whatever conflicts you have
4. You make a non-fast-forward merge commit to indicate that you/whatever was rebased as a series with a name
5. You push your conflict resolved & rebased you/whatever branch to master
6. You push the original you/whatever as unrebased/you/whatever
Now you have the original unrebased commits in your repository, you can now simply inspect your history to see what the original commits were, how they conflicted, and how those conflicts were resolved.
Once branches in unrebased/* get old enough you just delete them. In my experience the importance of seeing how someone did something in source control is inversely proportional to how recently it was committed.
This is a very important general concept in Git. It's reason for why it doesn't have an explicit "rename" primitive, instead you construct that information after the fact from the raw history.
Similarly if you're looking to do forensics on merge conflicts it's much better to have the raw original information.
As an aside, the author also seems to be making the dangerous assumption that just because the default merge driver doesn't indicate something as conflicting that he doesn't have to save the original information, his implementation hinges on `rebaseWithoutConflictsPossible()`.
It's possible to have logical conflicts that Git doesn't detect. E.g. if your addition of some code uses a function that's been removed from the upstream.
Thus if you really want to cover all these cases just push your original unrebased branch, then rebase it and push the result (with conflicts, if any, resolved). That gives you all the information you need for after the fact forensics, while keeping your history simple for casual inspection.
> Oops! That page can’t be found.
> It looks like nothing was found at this location. Maybe try a search?
"Eventually you’ll discover the Easter egg in Git: all meaningful operations can be expressed in terms of the rebase command. Once you figure that out it all makes sense. I thought the joke would be obvious: rebase, freebase, as in what was Linus smoking? But programmers are an earnest and humorless crowd and the gag was largely lost on them."
http://typicalprogrammer.com/linus-torvalds-goes-off-on-linu...
My simpler suggestion to avoid unnecessary merges is to try to wrap an alias around merge that simple just prompts whether they tried to rebase first. If you need to merge it often smells like a branch has existed too long.
changing the past to make a single linear thread is just weird imo.
depending on what rebaseWithoutConflictsPossible() is doing it might be helpful though - doing a rebase is an opportunity for the merging algorithms to cause subtle problems, and taking things out of the context in which they were actually made reduces the utility of the history for seeing what was done. the more people you have working on different things at once, the more likely these problems will manifest as something real. if this rebaseWithoutConflictsPossible() check is looking for any potential conflict, not just the ones the algorithms get stuck on then i can see the utility... but its still not necessary if you never rebase and never fast-forward.
"git recursive merge doesn't screwup x% of merges in some linux kernel repo" isn't an argument for it being useful in x% of cases so much as an argument for it causing damage in (100-x)% of cases. the many options available to tweak its behaviour to make it safer should be a giveaway that the merge feature is dangerous out of the box... the difficulty of resolving conflicts and dealing with merges is usually greatly overstated. a lot of programmers seem to have 'mergephobia'... i'm pretty sure we should just suck it up and do our jobs - learn that merges aren't that hard, and spend our time thinking about more important things. :)
You should never (not even rarely) resolve merge conflicts on master...
What's the reason to document rebase conflicts?