Matthieu Moy venit, vidit, dixit 25.04.2013 10:22:
Ramkumar Ramachandra artag...@gmail.com 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
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. Let's
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 rebase? B
On Mon, 29 Apr 2013 20:38:03 +0530 Ramkumar Ramachandra artag...@gmail.com
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
Ramkumar Ramachandra artag...@gmail.com 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
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 artag...@gmail.com 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
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 command.
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
Junio C Hamano gits...@pobox.com 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
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
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
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
Johannes Sixt j.s...@viscovery.net 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
On Fri, Apr 26, 2013 at 12:49 PM, Junio C Hamano gits...@pobox.com wrote:
Johannes Sixt j.s...@viscovery.net 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
Felipe Contreras felipe.contre...@gmail.com 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
Ramkumar Ramachandra artag...@gmail.com 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 rev
part of rev~n optional without being
On Thu, Apr 25, 2013 at 3:22 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Ramkumar Ramachandra artag...@gmail.com 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
Ramkumar Ramachandra artag...@gmail.com writes:
you might argue that ~n normally refers to a /home/n, but who uses
numbers in place of usernames?
~n expands to the nth element of the dir stack.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756
Andreas Schwab wrote:
Ramkumar Ramachandra artag...@gmail.com writes:
you might argue that ~n normally refers to a /home/n, but who uses
numbers in place of usernames?
~n expands to the nth element of the dir stack.
Oh, ouch. And this is bash.
Have to think of something else.
--
To
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 of
On Thu, Apr 25, 2013 at 1:07 AM, Ramkumar Ramachandra
artag...@gmail.com 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
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 rev
part of rev~n optional without being ambiguous: you might argue
that ~n normally refers to a
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 special
24 matches
Mail list logo
