| |||||||||||||
why skip the merge commits?why skip the merge commits?Posted Feb 21, 2007 19:01 UTC (Wed) by iabervon (subscriber, #722)In reply to: why skip the merge commits? by dlang Parent article: Who wrote 2.6.20?
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.
(Log in to post comments)
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.
|
|||||||||||||