[Scummvm-devel] git force-push

Max Horn max at quendi.de
Tue May 17 14:36:30 CEST 2011


Am 17.05.2011 um 14:24 schrieb Johannes Schickel:

>> Well, if one follows the pure git / DVCS ideology, then more squashing and
>> rebasing is evil, and we should preserve the true development history as
>> closely as possible... :) Actually, this stance does have some merits. If
>> one rebases and squashes a lot, then there is always a risk of producing a
>> history with many intermediate revisions that are broken in various ways
>> (e.g. they don't compile).
>> 
>> So, for this particular large series of commits, it might actually be best
>> if the original commits were merged, instead of doing lots of rebasing and
>> squashing. Alas, I am not sure if that history is still available...
>> 
>> 
> 
> I mostly agree with this. But that "detune" change was really messy, since the 
> partial revert later on included decreasing the savegame format version number 
> for SCUMM. So in theory we would include commits which could create/process 
> possibly incorrect savegames (due to later commits really utilising a "proper" 
> version 85 of the save format), probably that's even more annoying for 
> regression testing than without it.

Well, every rule has its exceptions, and this may very well be it, no doubt about that. Likewise, I understand Willem when he says:

> It feels a bit silly to push a commit that you _know_ is broken,
> since there's a bugfix commit right after it.

That's true, and in my local history, I always try to avoid that. But only if there is not too much distance between the first and the second commit, *and* if I am pretty sure I understand all the ramifications. 

In other words: Merging two (almost) adjacent commits where the second just fixes up the first one usually is a no-brainer, and fine.
Merging two or more commits that span a couple dozen commits and which are non-trivial is more risky and should be carefully considered (and ideally, the resulting new history should be checked for consistency / compilability).

As usual, there is no strict rule, but I think that if in doubt, it's usually better to preserve history than to try to rewrite it and potentially mess up.


Anyway, if we are changing history anyway, then I'd like to request that the commit messages are fixed up to follow our guidelines. E.g.
 
  MONKEY2 / INDY4 FM-TOWNS: set proper GUIO flags

really should be

  SCUMM: set proper GUIO flags
or
  SCUMM: set proper GUIO flags for MONKEY2 / INDY4 FM-TOWNS

Bye,
Max



More information about the Scummvm-devel mailing list