Junio C Hamano writes:
> A much larger issue is that the current setup_revisions()
> infrastructure does not let us express an operation that involves
> two or more DAGs. People sometimes wish to say an equivalent of
>
> git show $(git rev-list A..B) $(git rev-list C..D)
>
> but obviously
>
Junio C Hamano wrote:
> * Where the bottom of the DAG being replayed is (i.e. X);
> * What refs are the top of the DAG (i.e. A and B);
> * Where the new bottom of the replayed DAG (i.e. Y).
Okay, so can I start writing a series that will make git rebase accept
one negative commit (N) and one po
Junio C Hamano wrote:
> Compare these (gitk will give you nicer picture):
>
>$ git log --oneline --graph --left-right A...B
>$ git log --oneline --graph --left-right B...A
Darn. I didn't realize that rev-list had a --left-right to mark
commits with <, >, or - before giving it to the comma
Ramkumar Ramachandra writes:
> 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
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
Ramkumar Ramachandra writes:
>> - If the UI language for "rebase" were designed following the
>>"composition using common elements like ranges and revisions"
>>school, it would have started from "rebase --onto=X A..B".
>
> I think you're looking at the whole issue backwards from the way
On Mon, 29 Apr 2013 20:38:03 +0530 Ramkumar Ramachandra
wrote:
> 3. "Range" is not an inherent property of A..B or A...B. There are no
> "revision ranges".
Well, that could be seen as a problem, the .. syntax being commonly associated
with the concept of range.
> 4. Every command is free to in
Junio C Hamano wrote:
> - If the UI language for "rebase" were designed following the
>"composition using common elements like ranges and revisions"
>school, it would have started from "rebase --onto=X A..B".
I will try to drive the point home one more time. What do you really
want to re
Junio C Hamano wrote:
> - If the UI language for "rebase" were designed following the
>"composition using common elements like ranges and revisions"
>school, it would have started from "rebase --onto=X A..B".
I think you're looking at the whole issue backwards from the way I
look at it.
Matthieu Moy venit, vidit, dixit 25.04.2013 10:22:
> Ramkumar Ramachandra writes:
>
>> Hi,
>>
>> So, I have three serious itches that would be nice to address:
>>
>> 1. git reset --hard HEAD~1/ git show HEAD~1 is a very common idiom
>> that's unnecessarily cumbersome to type out. We can make the
Felipe Contreras writes:
> I don't know what 'git rebase master' does, but I would expect 'git
> rebase --onto=master' to do the same thing. Then, if 'git rebase
> --onto=next master..topic' makes sense, so should 'git rebase next
> master..topic'.
>
> Moreover, it often annoys me that 'git rebas
On Fri, Apr 26, 2013 at 12:49 PM, Junio C Hamano wrote:
> Johannes Sixt writes:
>
>> Allow alternative spelling of
>>
>>git rebase -i master topic
>>
>> like this:
>>
>>git rebase -i master..topic
>>
>> (as always, the default for topic is HEAD).
>
> I actually made this typo a few times
Johannes Sixt writes:
> Allow alternative spelling of
>
>git rebase -i master topic
>
> like this:
>
>git rebase -i master..topic
>
> (as always, the default for topic is HEAD).
I actually made this typo a few times in the past.
In a single-strand-of-pearls history, what rebase operates
Johannes Sixt wrote:
>git rebase -i master..topic
>git rebase -i master...topic
We absolutely don't want to go down the inconsistent diff UI route. See [1].
[1]: http://thread.gmane.org/gmane.comp.version-control.git/48
--
To unsubscribe from this list: send the line "unsubscribe git
Am 4/26/2013 10:19, schrieb Yann Dirson:
>> 2. git rebase -i master fails unless I've rebased my branch on top of
>> master. I always wished I could do the equivalent of 'git rebase -i
>> master..', but I can't. Can we give the A..B syntax a new meaning in
>> the context of rebase, namely $(git m
>2. git rebase -i master fails unless I've rebased my branch on top of
>master. I always wished I could do the equivalent of 'git rebase -i
>master..', but I can't. Can we give the A..B syntax a new meaning in
>the context of rebase, namely $(git merge-base A B)?
If I understand well, you're re
On Thu, Apr 25, 2013 at 1:07 AM, Ramkumar Ramachandra
wrote:
> 2. git rebase -i master fails unless I've rebased my branch on top of
> master. I always wished I could do the equivalent of 'git rebase -i
> master..', but I can't.
In what way does it fail? It seems to work ok for me. Do you mea
Felipe Contreras wrote:
> Yeah, probably fine, but I would also like H~1.
You can get that now using `git symbolic ref H HEAD`. I'm wondering
if we can do better than hard-interpreting HEAD as H at the rev-parse
level.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body
Andreas Schwab wrote:
> Ramkumar Ramachandra writes:
>
>> you might argue that ~ normally refers to a /home/, but who uses
>> numbers in place of usernames?
>
> ~ expands to the th element of the dir stack.
Oh, ouch. And this is bash.
Have to think of something else.
--
To unsubscribe from this
Ramkumar Ramachandra writes:
> you might argue that ~ normally refers to a /home/, but who uses
> numbers in place of usernames?
~ expands to the th element of the dir stack.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276
On Thu, Apr 25, 2013 at 3:22 AM, Matthieu Moy
wrote:
> Ramkumar Ramachandra writes:
>
>> Hi,
>>
>> So, I have three serious itches that would be nice to address:
>>
>> 1. git reset --hard HEAD~1/ git show HEAD~1 is a very common idiom
>> that's unnecessarily cumbersome to type out. We can make t
Ramkumar Ramachandra writes:
> Hi,
>
> So, I have three serious itches that would be nice to address:
>
> 1. git reset --hard HEAD~1/ git show HEAD~1 is a very common idiom
> that's unnecessarily cumbersome to type out. We can make the
> part of ~ optional without being ambiguous: you might arg
Ramkumar Ramachandra wrote:
> 3. Even though I lashed out strongly against 'git diff A..B' because
> of inconsistency, I can't say that it's not useful (omit specifying
> HEAD on one side). If we were to start over today, I would argue that
> 'git diff A ^B' and 'git diff B ^A' be handled as speci
Hi,
So, I have three serious itches that would be nice to address:
1. git reset --hard HEAD~1/ git show HEAD~1 is a very common idiom
that's unnecessarily cumbersome to type out. We can make the
part of ~ optional without being ambiguous: you might argue
that ~ normally refers to a /home/, but
24 matches
Mail list logo
