# [BUG?] git rebase not accepting :/ syntax

5 messages from 2012-09-07 to 2012-09-10. Participants: Yann Dirson, Andreas Schwab, Joachim Schmitz, Junio C Hamano.
Thread: https://gitlist.dev/t/31471

## Yann Dirson, 2012-09-07 13:08

Subject: [BUG?] git rebase not accepting :/ syntax
Message-ID: <20120907150803.0ae2b186@chalon.bertin.fr>
URL: https://gitlist.dev/e/20120907150803.0ae2b186%40chalon.bertin.fr

```
In 1.7.10.3, "git rebase -i :/Merge" will complain with:

fatal: Needed a single revision
invalid upstream :/Merge

... whereas "git rev-parse :/Merge" has no problem resolving
to a single revision.  OTOH, "git rebase -i HEAD^{/Merge}" does
work, and rev-parse resolves it to the same commit.

Is that due in some way to the semantic differences between the two
revspecs, or is that just a bug ?
-- 
Yann Dirson - Bertin Technologies

```

## Andreas Schwab, 2012-09-07 13:54

Subject: Re: [BUG?] git rebase not accepting :/ syntax
Message-ID: <m2ipbqx7iu.fsf@igel.home>
URL: https://gitlist.dev/e/m2ipbqx7iu.fsf%40igel.home
In-Reply-To: <20120907150803.0ae2b186@chalon.bertin.fr>

```
Yann Dirson <dirson@bertin.fr> writes:

> In 1.7.10.3, "git rebase -i :/Merge" will complain with:
>
> fatal: Needed a single revision
> invalid upstream :/Merge
>
> ... whereas "git rev-parse :/Merge" has no problem resolving
> to a single revision.

git rebase actually calls "git rev-parse :/Merge^0", which due to the
unlimited nature of :/ doesn't work.

> OTOH, "git rebase -i HEAD^{/Merge}" does work, and rev-parse resolves
> it to the same commit.

OTOH, "git rev-parse HEAD^{/Merge}^0" works as expected.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

```

## Yann Dirson, 2012-09-10 07:12

Subject: Re: [BUG?] git rebase not accepting :/ syntax
Message-ID: <20120910091224.4eca1b6e@chalon.bertin.fr>
URL: https://gitlist.dev/e/20120910091224.4eca1b6e%40chalon.bertin.fr
In-Reply-To: <m2ipbqx7iu.fsf@igel.home>

```
On Fri, 07 Sep 2012 15:54:49 +0200
Andreas Schwab <schwab@linux-m68k.org> wrote:

> Yann Dirson <dirson@bertin.fr> writes:
> 
> > In 1.7.10.3, "git rebase -i :/Merge" will complain with:
> >
> > fatal: Needed a single revision
> > invalid upstream :/Merge
> >
> > ... whereas "git rev-parse :/Merge" has no problem resolving
> > to a single revision.
> 
> git rebase actually calls "git rev-parse :/Merge^0", which due to the
> unlimited nature of :/ doesn't work.

Hm.  But then, git rev-parse $(git rev-parse :/Merge}^0 does work, a trivial
patch would appear to make things better.

BTW, git-rebase.sh seems to be quite inconsistent on the use of $() vs. ``,
not to mention the clear preference stated in CodingGuidelines.

I guess I'll find a moment for a couple of patches...

> > OTOH, "git rebase -i HEAD^{/Merge}" does work, and rev-parse resolves
> > it to the same commit.
> 
> OTOH, "git rev-parse HEAD^{/Merge}^0" works as expected.
> 
> Andreas.
> 


-- 
Yann Dirson - Bertin Technologies

```

## Joachim Schmitz, 2012-09-10 08:29

Subject: Re: [BUG?] git rebase not accepting :/ syntax
Message-ID: <k2k8dt$i5v$1@ger.gmane.org>
URL: https://gitlist.dev/e/k2k8dt%24i5v%241%40ger.gmane.org
In-Reply-To: <20120910091224.4eca1b6e@chalon.bertin.fr>

```
Yann Dirson wrote:
> On Fri, 07 Sep 2012 15:54:49 +0200
...
> BTW, git-rebase.sh seems to be quite inconsistent on the use of $()
> vs. ``, not to mention the clear preference stated in
> CodingGuidelines.

There are still quite a few more places in *.sh where `cmd`is used instead 
of $(cmd):

check-builtins.sh, git-am.sh, git-merge-one-file.sh, git-pull.sh, 
git-rebase--merge.sh, git-repack.sh, git-stash.sh, 
git-web--browse.sh,test-sha1.sh, unimplemented.sh

> I guess I'll find a moment for a couple of patches...

Might wanna fix them all in one go?

Bye, Jojo 

```

## Junio C Hamano, 2012-09-10 16:19

Subject: Re: [BUG?] git rebase not accepting :/ syntax
Message-ID: <7v8vchq298.fsf@alter.siamese.dyndns.org>
URL: https://gitlist.dev/e/7v8vchq298.fsf%40alter.siamese.dyndns.org
In-Reply-To: <20120910091224.4eca1b6e@chalon.bertin.fr>

```
Yann Dirson <dirson@bertin.fr> writes:

> Hm.  But then, git rev-parse $(git rev-parse :/Merge}^0 does work, a trivial
> patch would appear to make things better.

That, if done unconditionally, smells like a bad hack that wastes an
extra fork for a corner case that appears only very rarely.

I guess something like this

	upstream=$(
        	git rev-parse --verify -q "$upstream_name"^0 ||
                git rev-parse --verify -q $(git rev-parse --verify "$upstream_name")^0
	) ||
	die "$(eval_gettext 'invalid upstream $upstream_name')"

may be an acceptable usability workaround, but I wonder if we can do
the same fallback inside the revision argument parser, so that

	git <cmd> ":/Merge^0"

first looks for a commit that has string "Merge^0" in it and if it
fails then it looks for a commit that has string "Merge" and then
apply "^0" to it.

```