Re: Specifying revisions in the future
- From
- Jonathan Paugh <jpaugh@gmx.us>
- Date
- Feb 7, 2012, 21:25 UTC
- Message-ID
- <4F3196CC.9020406@gmx.us>
- In-Reply-To
- <buosjiozity.fsf@dhlpc061.dev.necel.com>
On 02/05/2012 11:28 PM, Miles Bader wrote:
Show 12 quoted lines
> Andreas Schwab <schwab@linux-m68k.org> writes:
>> The rule should be to follow the leftmost parent as far as possible.
>> That means that X+2->D is B.
>
> It might also be reasonable (and safer -- the user may not actually
> realize when there's an ambiguating branch-point) to simply have it
> abort with an error ("ambiguous future-ref specification") when
> there's any doubt... I suspect most uses would be very simple "+1"
> etc., and not crossing branch points.
>
> -miles
> Perhaps default to --linear or --no-cross or such. Whenever there's ambiguity, it will likely be harder for the user to think about than for git to resolve it in some defined-as-sane way, at least for many users.
At any rate, I got the answer I needed for my use case (sorry for not cc-ing the list, and thanks Jakub for that: http://article.gmane.org/gmane.comp.version-control.git/189926/match=specify+revisions+future).
Still, forward-refs would still be really cool.
Jonathan