Re: [RFC PATCH v2 01/11] Documentation: document post-rewrite hook

On Wednesday 17 February 2010 00:59:51 Junio C Hamano wrote:

Thomas Rast [off-list ref] writes:

quoted

+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