On Wednesday 17 February 2010 00:59:51 Junio C Hamano wrote:
quoted text
> Thomas Rast <trast@student.ethz.ch> 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.

quoted text
> 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 :-)

quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html