Re: What's in git.git

[Junio C Hamano <junkio@cox.net>]

Andreas Ericsson <ae@op5.se> writes:

> But wouldn't rebase detect the commits as being the same, unless
> you've made changes to them? If it doesn't, can we teach it to discard
> parent info and re-hash the commits if they conflict? That should
> solve most such merge-conflicts, really.

Yes, rebase would help somewhat (I said that didn't I?).  But
the thing is, with the "pu" workflow of mine so far, I _did_
rewrite/replace commits on my topic branches, especially when
they are young and not in a good shape.

For example, the topic branch jc/nostat ("Assume unchanged" git)
has four commits since it forked from the mainline:

 + [jc/nostat] "Assume unchanged" git: --really-refresh fix.
 + [jc/nostat^] ls-files: debugging aid for CE_VALID changes.
 + [jc/nostat~2] "Assume unchanged" git: do not set CE_VALID with --refresh
 + [jc/nostat~3] "Assume unchanged" git

With the "pu" workflow, I would have merged the "do not set
CE_VALID" commit and "--really-refresh fix" commit into the
first "Assume unchanged" commit after I found out about these
two small mistakes.  So one day "pu" would have contained what
is there right now as "jc/nostat~3", but the next day it would
have a commit, perhaps with slightly modified log message from
what is there as "jc/nostat~3" to contain fixes jc/nostat~2 and
jc/nostat have right now (the ls-files one is a debugging aid so
I would have left it separate even with the rewriting-history
workflow).

That kind of rewriting history is not being honest, but the end
result is that people do not have to see intermediate states and
earlier mistakes when things are fully cooked and ready to be
merged into the mainline.  By promising not to rewind "next" and
topic branches that go to "next", I am closing the door for me
to do this kind of history rewrite freely.  I can still rewrite
things I have not pushed out yet, though.

BTW, it is always a judgement call if it is a good thing to
squash commits into one like this.  Being too honest hurts the
usability of the history.  Especially if you have a trivial "Oh,
what I checked in does not even compile" kind of mistakes left
in the development trail, that would inconvenience bisection.
Being too sanitized OTOH tends to drop a single big ball of wax
into the history, and makes correcting things harder if it is
found later that only parts of that change are desired and the
other parts are not.