On Wednesday 17 February 2010 00:59:51 Junio C Hamano wrote:
> Thomas Rast <trast@xxxxxxxxxxxxxxx> writes:
>
> > +rebase::
> > + For the 'squash' and 'fixup' operation, all commits that were
> > + squashed are listed as being rewritten to the squashed commit.
> > + This means that there will be several lines sharing the same
> > + 'new-sha1'.
>
> Similar to filter-branch being silent on dropped commits, I presume
> "rebase -i" will stay silent if a pick is removed, or rebase --skip is
> given.
Indeed. Due to the way that rebase works, it would be a hassle to
report '00..00' (or so) for dropped commits, so I'm not too keen on
going there. (My intended use-cases don't require it. Do you have
one that does?) Documenting this absence wouldn't hurt though.
> I wondered if squash/fixup case wants to distinguish the "primary" commit
> and "follow-up" fixup commits (not a complaint, but thinking-aloud), but I
> think the rebase command itself and this hook have the same amount of
> information needed to guess which one is the primary and which ones are
> the follow ups, so it probably is Ok.
That's what I put in the <extra-info> for :-)
> Is the order of input lines guaranteed in some way? For example, if I run
> rebase to make A B C into A' and B+C, do we get these three lines:
>
> A -> A'
> B -> B+C
> C -> B+C
>
> in some known order? If so, should we document that order?
Currently they're in the order that they were rewritten, but what
would the hook learn from that?
I left it unspecified because I wasn't sure we would always have the
list in a specific order (e.g., when reconstructed from a hash map of
rewritings, it's not) but then, keeping the list ordered isn't that
expensive either...
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
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