Thomas Rast <trast@xxxxxxxxxxxxxxx> writes:
> 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 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.
>> 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.
--
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