Junio C Hamano wrote:
> That world view is broken, isn't it?  Perhaps you forgot to consider
> symmetric differences, where left positives and right positives have
> to be treated differently.

No, I did consider symmetric difference.  How is git log A B --not
$(git merge-base --all A B) different from git log B A --not $(git
merge-base --all A B)?

> "diff A B" and "diff B A" mean very
> different things, for that matter.

In fact, I would go so far as to claim that git diff A B is broken.
diff should be forbidden from taking two positives (since it has no
way to differentiate between them but for the ordering).  It should
diff a positive against a negative.

> A line of thought that begins
> with "there is no ordering" may be a "brave proposal", perhaps, but
> it is not "fundamental principles".

My claim is very simple.  If a command _depends_ on A..B being
resolved as ^A B, and not B ^A, we have have a big problem.  Why?
Because we've already established that git log A B is exactly the same
thing as git log B A.  To maintain consistency with this, ordering
should never matter.

> "rebase requires three: onto, list and a ref" (by the way, it is not
> refspec, which has a specific meaning)

Sorry about that thinko: yes, I meant ref.

After working on the implicit-push proposal for so long, I think I can
tell the difference between a ref and refspec ;)

> It is not far-fetched to allow rebase to handle a history with two
> branches A and B that share the common initial part (i.e. ^X A B)
> and replay that history on top of an unrelated point in history Y to
> transform:
>              o---o---Y
>             /
>     ---o---X---C---C---A---A---A (tip of branch A)
>                     \
>                      B---B---B (tip of branch B)
> into
>              o---o---Y---C'--C'--A'--A'--A' (updated tip of branch A)
>             /         \
>     ---o---X           B'--B'--B' (updated tip of branch B)

I wholeheartedly agree.

However, I think you've misunderstood what I said: my goal is to
define _everything_ in terms of how different commands interpret a
list of positive and negative commits.  It's not that some commands
take DAGs, other ranges, and yet others lists; all of them take rev
specs that resolve to a list of positive-negative commits.  What to do
with that information is up to the command (erroring out is a valid
response).  In my above proposal, I'd like to change "rebase can take
one negative commit and one positive commit" to "rebase can take one
negative commit and multiple positive commits" (in fact, this was my
original sentence, but I went back to "one positive commit" before
sending out the email because I thought I was being crazy).

> So what?  Why do you even _need_ to mix up all positive revisions,
> some of which mean different things from others, into a single bag,
> only to later differenciate some as special (i.e. used as the onto
> commit) from the others (i.e. the tips in the DAG)?  If something is
> special, you can say not just it is special and can say what it
> means by saying "this is where I want to replay the DAG on top".

Um, my point was again that "ordering does not matter"; therefore for
a third type of commit, you need a command-line parameter.

>     git show A..B C..D

This is seriously bad.  We'll have to think about fixing this along the way.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to