| |||||||||||||
why skip the merge commits?why skip the merge commits?Posted Feb 21, 2007 2:13 UTC (Wed) by dlang (✭ supporter ✭, #313)Parent article: Who wrote 2.6.20?
in many cases the merges involve a significant amount of effort and skill to do right. I'm curious why they were stripped out of the results?
If I understand git correctly a merge commit will only happen when there's something interesting. if linus pulls from a subsystem tree that is based directly on his latest version it will do a fast-forward, not a merge.
(Log in to post comments)
why skip the merge commits? Posted Feb 21, 2007 2:35 UTC (Wed) by corbet (editor, #1) [Link] There's no useful information in the merges - at least, for the depth I have gone to so far. They do carry information on the path patches took into the kernel, but they do not, themselves, carry any code changes. If you look at the short-form 2.6.20 changelog, you'll see a lot of lines like:
Merge git://git.kernel.org/.../bunk/trivial
Merge git://git.kernel.org/.../sfrench/cifs-2.6
Merge master.kernel.org:/.../gregkh/driver-2.6
Merge master.kernel.org:/.../gregkh/pci-2.6
Merge master.kernel.org:/.../gregkh/usb-2.6
They only indicate that the trees came together at that point.
why skip the merge commits? Posted Feb 21, 2007 5:03 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link] my git-foo isn't good enough to know the answer to this, so I'll as what's probably a dumb question
I know that the vast majority of merges are non-events like this, what happens when there is a conflict in the merge?
I thought the changes were recorded as part of the merge, the only other option would be for a merge, followed by the changes needed to make it work, and this would seem to cause problems for things like bisect
why skip the merge commits? Posted Feb 21, 2007 19:01 UTC (Wed) by iabervon (subscriber, #722) [Link] For all commits, what is recorded is the resulting state and the commit(s) which went into it. In order to determine if there were conflicts, you just try merging the inputs yourself and see if it's trivial or not. Of course, you can't tell if the person who actually did the merge used some special strategy which knew how to do the merge without conflicts. If your try didn't give conflicts, you should also compare the result against the commit, because it's possible that the person fixed stuff that didn't get flagged as a conflict (e.g., the two branches added the same function in different places, and the person removed one copy when the compiler complained).
In a sense, all merges are events (otherwise, you get a fast-forward), but an external observer can never really tell how much of the event was done by the committer and how much was done by software. Who knows, somebody might have a secret special sparse-based C source merger.
why skip the merge commits? Posted Feb 21, 2007 20:17 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link] the question is, should merge events be ignored, or can code changes take place as part of the merge event.
if so then we'll need to update the scripts to account for this when corbet releases them in a week or so.
why skip the merge commits? Posted Feb 21, 2007 21:20 UTC (Wed) by iabervon (subscriber, #722) [Link] Code changes really shouldn't be part of a merge event. Even resolving conflicts is really a matter of "not changing" stuff in some sense.
|
|||||||||||||