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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html