Hi, On Mon, 11 Aug 2008, Johannes Sixt wrote: > Johannes Schindelin schrieb: > > That would actually be a problem, no? I am not sure that resolutions > > for reverts make sense for cherry-picks, so I am not sure if > > resolutions should be recorded for reverts. > > Of course they should. Are you sure? > If the reversal is part of a topic branch that you rebase at least once, > then you want to have the resolutions recorded, don't you? That is not the revert we are talking about. The revert we are talking about is a literal "git revert <commit>". Not a replay of a commit (that might have been a revert originally). I am a little worried that these reverts (being negative changes) could interfer with the common operation: positive changes. Although I haven't been able to come up with a scenario where the recorded revert would actively be wrong in a subsequent rebase/cherry-pick. Yes, I see your point that a revert on a topic branch which is then rebased would be nice to have its resolution recorded; that will happen with the first rebase, though. However, if my suspicion is true, recording the resolution only with the first rebase could make things safer overall, because an occasional temporary revert would not affect later cherry-picks in an unintuitive way. Thinking about a good example, or a counterexample, Dscho -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
