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

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 17, 2010, 00:29 UTC
Message-ID: <7v4olgvh5y.fsf@alter.siamese.dyndns.org>
In-Reply-To: <201002170118.53639.trast@student.ethz.ch>

Thomas Rast <trast@student.ethz.ch> writes:

Show 17 quoted lines

> On Wednesday 17 February 2010 00:59:51 Junio C Hamano wrote:
>> 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.

I was solely interested in the documentation at this point. I don't see a reason to report "old -> nul"; somebody else may, but I don't.

Show 11 quoted lines

>> 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?

For example, a user may say "I _always_ make a big commit that describes everything at the beginning, and then follow-ups are irrelevant", in which case the user may want to say "notes for B carries to B+C but discard anything attached to C" in _his_ hook.

Another example. A build-bot may attach "builds fine" note to C but B may have "failed to build" note without the fix-up in C. B+C will want to have the "builds fine" note from C (you would probably also need to verify that C^{tree} == (B+C)^{tree} before moving the note, but the point is you do not even want to consider moving it from B to B+C).

These become possible if the output at least guarantees topological ordering for things that are squashed into one.

But again I am just thinking aloud. I don't know how much benefit will such a guarantee give us in practice.