3 ms·
The author never elaborates on why exactly he thinks this is needed. I think reading between the lines the reason is that if someone's done a merge/rebase and s
by avar 11y ago
The author never elaborates on why exactly he thinks this is needed. I think reading between the lines the reason is that if someone's done a merge/rebase and screwed up a conflict resolution the information about how that's happened is lost forever, so let's come up with some hack to save that information in case there was a conflict.
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.
- gkop 11y agoIn addition to losing less information, your solution allows you to keep merge conflict resolution off of master entirely (if that's your choice).
- avar 11y agoIndeed, but actually much more importantly it doesn't try to "freeze" derived information that you could just as well construct after the fact from raw information. 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.