Q: how can i find the upstream merge point of a commit?

Q: how can i find the upstream merge point of a commit?

[Ingo Molnar]

This might be a FAQ, but i couldn't find an elegant Git-ish answer 
for it, so please bear with my stupid question :-)

In an upstream Linux kernel Git repo, with linux-next as a remote 
present (but -git checked out), what is the way to find out when a 
particular commit was merged upstream?

So for example when was 189d3c4a94 merged upstream?

The proper Git answer would be:

  $ git describe --contains 189d3c4a94
  next-20080501~97

But the next-20080501 tag is useless, and i don't have linux-next as 
HEAD, it's only a remote.

Right now i have this imperfect hack instead:

  $ git log --pretty=oneline 189d3c4a94.. Makefile | tail -5

Which gives this answer:

  $ git log --pretty=oneline 189d3c4a94.. Makefile | tail -5
  b8291ad07a7f3b5b990900f0001198ac23ba893e Linux 2.6.26-rc3
  492c2e476eac010962850006c49df326919b284c Linux 2.6.26-rc2
  a95bcfac2b5f353f99c6a338d77eb5584ab35d83 kbuild: escape meta characters in regular expression in make TAGS
  2ddcca36c8bcfa251724fe342c8327451988be0d Linux 2.6.26-rc1
  90ebd878a5900839106664fae40a6cc83dbe86ab kbuild: fix vmlinux.o link

So i can see that this commit went upstream in the .26 merge window 
and was released in .26-rc1 for the first time.

This (ab)-uses the fact that the toplevel Makefile gets edited for 
every release by Linus, and it does not have many other changes.

But ... it would be much nicer if i could make 'git describe 
--contains' work better.

Any ideas?

Thanks,

	Ingo

Re: Q: how can i find the upstream merge point of a commit?

[Johannes Sixt]

Am 6/8/2011 11:36, schrieb Ingo Molnar:
> So for example when was 189d3c4a94 merged upstream?
> 
> The proper Git answer would be:
> 
>   $ git describe --contains 189d3c4a94
>   next-20080501~97
> 
> But the next-20080501 tag is useless, and i don't have linux-next as 
> HEAD, it's only a remote.
> ...
> But ... it would be much nicer if i could make 'git describe 
> --contains' work better.

$ git describe --contains --match 'v2.*' 189d3c4a94

-- Hannes

Re: Q: how can i find the upstream merge point of a commit?

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 892 bytes --]

Hi Ingo,

On Wed, 8 Jun 2011 11:36:48 +0200 Ingo Molnar <mingo@elte.hu> wrote:
>
> 
> This might be a FAQ, but i couldn't find an elegant Git-ish answer 
> for it, so please bear with my stupid question :-)
> 
> In an upstream Linux kernel Git repo, with linux-next as a remote 
> present (but -git checked out), what is the way to find out when a 
> particular commit was merged upstream?
> 
> So for example when was 189d3c4a94 merged upstream?
> 
> The proper Git answer would be:
> 
>   $ git describe --contains 189d3c4a94
>   next-20080501~97
> 
> But the next-20080501 tag is useless, and i don't have linux-next as 
> HEAD, it's only a remote.

You can restict which tags get used:

$ git describe --contains --match 'v*' 189d3c4a94
v2.6.26-rc1~155

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: Q: how can i find the upstream merge point of a commit?

[Peter Zijlstra]

On Wed, 2011-06-08 at 20:34 +1000, Stephen Rothwell wrote:

> You can restict which tags get used:
> 
> $ git describe --contains --match 'v*' 189d3c4a94
> v2.6.26-rc1~155

*groan*, I tried that, but got:

# git describe --contains  189d3c4a94ef19fca2a71a6a336e9fda900e25e7 --match '^v.*'
fatal: cannot describe '189d3c4a94ef19fca2a71a6a336e9fda900e25e7'

and

# git describe --contains  189d3c4a94ef19fca2a71a6a336e9fda900e25e7 --match 'v.*'
fatal: cannot describe '189d3c4a94ef19fca2a71a6a336e9fda900e25e7'

at which point I gave up.. 

Re: Q: how can i find the upstream merge point of a commit?

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 448 bytes --]

Hi Peter,

On Wed, 08 Jun 2011 12:40:36 +0200 Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
>
> *groan*, I tried that, but got:
> 
> # git describe --contains  189d3c4a94ef19fca2a71a6a336e9fda900e25e7 --match '^v.*'
                                                                                 ^
These are globs. not regexps.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: Q: how can i find the upstream merge point of a commit?

[Peter Zijlstra]

On Wed, 2011-06-08 at 21:29 +1000, Stephen Rothwell wrote:
> Hi Peter,
> 
> On Wed, 08 Jun 2011 12:40:36 +0200 Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> >
> > *groan*, I tried that, but got:
> > 
> > # git describe --contains  189d3c4a94ef19fca2a71a6a336e9fda900e25e7 --match '^v.*'
>                                                                                  ^
> These are globs. not regexps.

Yeah, figured as much, never would have thought of trying that though.
The man page said pattern, my brain made regex.

Re: Q: how can i find the upstream merge point of a commit?

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> > But the next-20080501 tag is useless, and i don't have linux-next 
> > as HEAD, it's only a remote.
> 
> You can restict which tags get used:
> 
> $ git describe --contains --match 'v*' 189d3c4a94
> v2.6.26-rc1~155

Ok, that works.

Still it's not entirely logical that 'foreign' tags invade another 
branch this aggressively.

Yeah, i know that Git tags are global but still, if i add a remote i 
do not intuitively expect it to create a union of tags, do i?

So it would be nice to have more separation for remotes - right now 
they do not sit still in their sandboxes! :-)

Thanks,

	Ingo

Re: Q: how can i find the upstream merge point of a commit?

[Sverre Rabbelier]

Heya,

[+Peff, Duy, who seemed interested in this]

On Wed, Jun 8, 2011 at 14:52, Ingo Molnar <mingo@elte.hu> wrote:
> So it would be nice to have more separation for remotes - right now
> they do not sit still in their sandboxes! :-)

Sounds like the "tags should go in their own namespaces in git 1.8.0"
[0] discussion? :)

[0] http://thread.gmane.org/gmane.comp.version-control.git/165799/focus=165837

-- 
Cheers,

Sverre Rabbelier

Re: Q: how can i find the upstream merge point of a commit?

[Ingo Molnar]

* Sverre Rabbelier <srabbelier@gmail.com> wrote:

> Heya,
> 
> [+Peff, Duy, who seemed interested in this]
> 
> On Wed, Jun 8, 2011 at 14:52, Ingo Molnar <mingo@elte.hu> wrote:
> > So it would be nice to have more separation for remotes - right now
> > they do not sit still in their sandboxes! :-)
> 
> Sounds like the "tags should go in their own namespaces in git 1.8.0"
> [0] discussion? :)
> 
> [0] http://thread.gmane.org/gmane.comp.version-control.git/165799/focus=165837

Cool, i like banging on open doors! :-)

Thanks,

	Ingo

Re: Q: how can i find the upstream merge point of a commit?

[Nguyen Thai Ngoc Duy]

2011/6/8 Sverre Rabbelier <srabbelier@gmail.com>:
> Heya,
>
> [+Peff, Duy, who seemed interested in this]
>
> On Wed, Jun 8, 2011 at 14:52, Ingo Molnar <mingo@elte.hu> wrote:
>> So it would be nice to have more separation for remotes - right now
>> they do not sit still in their sandboxes! :-)
>
> Sounds like the "tags should go in their own namespaces in git 1.8.0"
> [0] discussion? :)
>
> [0] http://thread.gmane.org/gmane.comp.version-control.git/165799/focus=165837

A lengthy thread. Does anybody remember the outcome? Was Johan's
proposal OK and only waiting to be implemented, or is there still
unanswered questions?
-- 
Duy

Re: Q: how can i find the upstream merge point of a commit?

[Johan Herland]

On Wednesday 08 June 2011, Nguyen Thai Ngoc Duy wrote:
> 2011/6/8 Sverre Rabbelier <srabbelier@gmail.com>:
> > Heya,
> > 
> > [+Peff, Duy, who seemed interested in this]
> > 
> > On Wed, Jun 8, 2011 at 14:52, Ingo Molnar <mingo@elte.hu> wrote:
> >> So it would be nice to have more separation for remotes - right now
> >> they do not sit still in their sandboxes! :-)
> > 
> > Sounds like the "tags should go in their own namespaces in git 1.8.0"
> > [0] discussion? :)
> > 
> > [0]
> > http://thread.gmane.org/gmane.comp.version-control.git/165799/focus=16
> > 5837
> 
> A lengthy thread. Does anybody remember the outcome? Was Johan's
> proposal OK and only waiting to be implemented, or is there still
> unanswered questions?

(Sorry for the late answer. Unfortunately, I don't have much Git time these 
days...)

Browsing that thread, it seems my proposal was largely OK. AFAICS there are 
no major technical problems with moving to the following ref mapping:

  Remote repo    ->   Local repo
  --------------------------------------------------
  refs/heads/*        refs/remotes/$remote/heads/*
  refs/tags/*         refs/remotes/$remote/tags/*
  refs/replace/*      refs/remotes/$remote/replace/*
  refs/notes/*        refs/remotes/$remote/notes/*

There was a fair amount of discussion around whether we really _want_ to put 
all refs (especially tags) in separate per-remote namespaces, and it seems 
(both from that thread, and from later threads, like this one) that we _do_ 
want per-remote namespaces for all refs.

That said, there are a couple of outstanding questions/challenges before 
this can be implemented:


1. How to deal with tag auto-following

The tag auto-follow behavior currently depends on the implicit 
"refs/tags/*:refs/tags/*" refspec, and the "refs/tags/" prefix is presently 
hardcoded both at the local and remote end. If we want to support auto-
follow behavior in the new ref mappings (e.g. specified with a "~" prefix: 
"~+refs/tags/*:refs/remotes/$remote/tags/*"), we must change code both on 
the local and remote side. In order to get optimal behavior we will probably 
also need to make some protocol changes.

On the other hand, it is not clear how useful tag auto-following really is. 
Quoting Peff from the earlier thread ( 
http://thread.gmane.org/gmane.comp.version-control.git/160503/focus=160726 
): "Now you could argue that auto-follow is not worth the effort. It is 
somewhat confusing, and I can't think of a time when it ever actually 
reduced the set of objects I was fetching (as opposed to just fetching all 
tags). But maybe others have use cases where it matters."

Or, quoting Junio further down in the thread ( 
http://thread.gmane.org/gmane.comp.version-control.git/165799/focus=166694 
): "Also if you give tags a totally separate namespace, I don't see much 
reason to still give it the "auto-follow" semantics.  It is far simpler to 
explain if you just fetch all of them and be done with it, no?"

So far nobody have stood up to defend the current auto-following behavior as 
a necessary feature.


2. Interpreting/DWIMing refs

Changing the ref mappings require a revised set of rules for interpreting 
shorthand ref names (expanding them into full ref names), and handling 
ambiguities when they arise:

- "foo" should still be usable for "refs/heads/foo", "refs/tags/foo", etc.

- "origin/foo" must continue to work, even if "refs/remotes/origin/foo" has 
now become "refs/remotes/origin/heads/foo". In other words, "foo/bar" where 
"foo" is a valid remote, must try to resolve "bar" against the refspecs 
specified for the "foo" remote.

- For tag name "foo": "refs/tags/foo" (if exists) is unambiguous.

- If "refs/tags/foo" does not exist, tag name "foo" is unambiguous if it 
exists in one or more "refs/remotes/*/tags/foo" and they all point to the 
same SHA1.

- If "refs/tags/foo" does not exist, and more than one 
"refs/remotes/*/tags/foo" exist, and they do NOT all point to the same SHA1, 
then there is an ambiguity.

- The user may resolve the ambiguity by creating "refs/tags/foo" pointing to 
the chosen SHA1 ("refs/tags/foo" takes precedence over 
"refs/remotes/*/tags/foo").

- The same rules apply to heads, notes, etc.

- Extra care must be taken across different "types" of refs, depending on 
the context. I.e. in some situations we might want to prefer 
"refs/remotes/origin/heads/foo" to "refs/remotes/otherremote/tags/foo", or 
the other way around (or flag the ambiguity and abort).


3. Migration path

We need both styles of ref mappings ("traditional", with the implicit and 
auto-following tag refspec, and "new-style", where all refspecs are 
explicit) to work side-by-side in the same repo (i.e. having one remote use 
traditional refspecs, while another uses new-style). At first, we will 
probably still default to the traditional refspecs when creating a new 
remote, but over time we should migrate to new-style refspecs, before 
finally deprecating the traditional refspecs. I'm not sure if traditional 
vs. new-style can be reliably autodetected from the refspecs themselves, or 
if we need an explicit per-remote config variable to discern between the 
two.


I think all of the above problems are solvable.


...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net

Re: Q: how can i find the upstream merge point of a commit?

[Jeff King]

On Tue, Jun 14, 2011 at 11:56:56AM +0200, Johan Herland wrote:

> 2. Interpreting/DWIMing refs
> 
> Changing the ref mappings require a revised set of rules for interpreting 
> shorthand ref names (expanding them into full ref names), and handling 
> ambiguities when they arise:
> [...]
> 
> - "origin/foo" must continue to work, even if "refs/remotes/origin/foo" has 
> now become "refs/remotes/origin/heads/foo". In other words, "foo/bar" where 
> "foo" is a valid remote, must try to resolve "bar" against the refspecs 
> specified for the "foo" remote.

What happens if I ask for foo/bar/baz? Should it try to resolve:

  1. refs/remotes/foo/heads/bar/baz

or

  2. refs/remotes/foo/bar/heads/baz

or both (and if both, in which order)?

I don't know offhand if "git remote" and "git clone" allow slashes in
remote names, but I don't think we forbid it if somebody configures it
themselves (and of course, remote names aside, they are free to write
whatever refspecs they like in the config file).

> - If "refs/tags/foo" does not exist, tag name "foo" is unambiguous if it 
> exists in one or more "refs/remotes/*/tags/foo" and they all point to the 
> same SHA1.
> 
> - If "refs/tags/foo" does not exist, and more than one 
> "refs/remotes/*/tags/foo" exist, and they do NOT all point to the same SHA1, 
> then there is an ambiguity.
> 
> - The user may resolve the ambiguity by creating "refs/tags/foo" pointing to 
> the chosen SHA1 ("refs/tags/foo" takes precedence over 
> "refs/remotes/*/tags/foo").
> 
> - The same rules apply to heads, notes, etc.

I'm not sure we need all of these rules for anything but tags. We
already keep remote heads in a separate namespace, and we don't
automagically look them up. And that's OK, because the way tags and
heads work is fundamentally different. I can peek at your remote heads,
but if I checkout or merge, I better make a local branch that matches
your remote one.  Whereas with tags, I don't think that is the case.
They're really a read-only thing, and you want them to stay in the
remotes namespace.

I think notes should behave more like heads. You can use them as-is if
you just want to look, but you need to use the full remote name. And if
you want to do more (like keeping your own notes and merging somebody's
remote notes in), then you'll make your own local notes branch, and use
"git notes merge" to keep it up to date.

-Peff

Re: Q: how can i find the upstream merge point of a commit?

[Johan Herland]

On Tuesday 14 June 2011, Jeff King wrote:
> On Tue, Jun 14, 2011 at 11:56:56AM +0200, Johan Herland wrote:
> > 2. Interpreting/DWIMing refs
> > 
> > Changing the ref mappings require a revised set of rules for
> > interpreting shorthand ref names (expanding them into full ref names),
> > and handling ambiguities when they arise:
> > [...]
> > 
> > - "origin/foo" must continue to work, even if "refs/remotes/origin/foo"
> > has now become "refs/remotes/origin/heads/foo". In other words,
> > "foo/bar" where "foo" is a valid remote, must try to resolve "bar"
> > against the refspecs specified for the "foo" remote.
> 
> What happens if I ask for foo/bar/baz? Should it try to resolve:
> 
>   1. refs/remotes/foo/heads/bar/baz
> 
> or
> 
>   2. refs/remotes/foo/bar/heads/baz
> 
> or both (and if both, in which order)?

I think we want to do both, following these pseudo-bash steps (or something 
similar):

  shorthand=$1  # e.g. "foo/bar/baz"
  for remote in $(git remote)
  do
      case $shorthand in
        "$remote/"*)
          # Found matching remote
          trailer=${shorthand#$remote/}
          # Assert $remote/$trailer == $shorthand
          # DWIM $trailer into
          # - refs/heads/$trailer
          # - refs/tags/$trailer
          # etc.
          for dwimmed_ref in dwim_ref($trailer)
          do
              # Map $dwimmed_ref through refspec to get
              # remote-tracking ref, e.g. mapping
              # "refs/heads/spam" to "refs/remotes/$remote/heads/spam"
              remote_ref=map_through_refspec($dwimmed_ref, $remote)
              if test -n "$remote_ref"
              then
                  # Add $remote_ref to list of candidates
              fi
          done
          ;;
        *)
          # Non-match, ignore
          ;;
      esac
  done

  # We now have a list of (fully qualified) ref candidates
  # for $shorthand.

  # If there are zero candidates, there is no match for $shorthand.

  # If there is only one candidate, we have found an unambiguous
  # match for $shorthand.

  # If our current context demands a SHA1 object name, and all
  # candidates point to the same SHA1, there is no ambiguity.

  # Otherwise, $shorthand is ambiguous.


Using the above (pseudo)code, and assuming remotes "foo" and "foo/bar" exist 
(with remote branches "bar/baz" and "baz", respectively, and default new-
style refspecs), then the "foo/bar/baz" shorthand would resolve to the 
following two remote-tracking branches:

- refs/remotes/foo/heads/bar/baz
- refs/remotes/foo/bar/heads/baz

This would likely result in an "ambiguous shorthand" error, unless the 
current context wants a SHA1 object name, and the two remote-tracking refs 
happen to point to the same SHA1 (in which case the result is unambiguous).

(Obviously, all of the above assumes that "foo/bar/baz" does not match any 
local ref, which would take precedence over the remote-tracking refs listed 
above.)

> I don't know offhand if "git remote" and "git clone" allow slashes in
> remote names, but I don't think we forbid it if somebody configures it
> themselves (and of course, remote names aside, they are free to write
> whatever refspecs they like in the config file).

  git remote add foo/bar .

does not report any errors for me.

> > - If "refs/tags/foo" does not exist, tag name "foo" is unambiguous if
> > it exists in one or more "refs/remotes/*/tags/foo" and they all point
> > to the same SHA1.
> > 
> > - If "refs/tags/foo" does not exist, and more than one
> > "refs/remotes/*/tags/foo" exist, and they do NOT all point to the same
> > SHA1, then there is an ambiguity.
> > 
> > - The user may resolve the ambiguity by creating "refs/tags/foo"
> > pointing to the chosen SHA1 ("refs/tags/foo" takes precedence over
> > "refs/remotes/*/tags/foo").
> > 
> > - The same rules apply to heads, notes, etc.
> 
> I'm not sure we need all of these rules for anything but tags. We
> already keep remote heads in a separate namespace, and we don't
> automagically look them up. And that's OK, because the way tags and
> heads work is fundamentally different. I can peek at your remote heads,
> but if I checkout or merge, I better make a local branch that matches
> your remote one.  Whereas with tags, I don't think that is the case.
> They're really a read-only thing, and you want them to stay in the
> remotes namespace.

I don't really have any strong opinions here. As long as the rules end up 
being fairly intuitive and usable in practice, I'm quite happy to let others 
decide on the details.

FWIW, if I run "git log some_topic" and "some_topic" only exists as a 
remote-tracking ref ("refs/remotes/origin/heads/some_topic"), I do think I 
would prefer git to DWIM it, instead of simply failing with:

  fatal: bad revision: some_topic

This would be somewhat in line with the DWIMing already performed by "git 
checkout some_topic".


Have fun! :)

...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net

Re: Q: how can i find the upstream merge point of a commit?

[Jeff King]

On Wed, Jun 15, 2011 at 01:45:12AM +0200, Johan Herland wrote:

> > What happens if I ask for foo/bar/baz? Should it try to resolve:
> > 
> >   1. refs/remotes/foo/heads/bar/baz
> > 
> > or
> > 
> >   2. refs/remotes/foo/bar/heads/baz
> > 
> > or both (and if both, in which order)?
> 
> I think we want to do both, following these pseudo-bash steps (or something 
> similar):
> 
>   shorthand=$1  # e.g. "foo/bar/baz"
>   for remote in $(git remote)
>   do
>       case $shorthand in
>         "$remote/"*)
>           # Found matching remote
>           trailer=${shorthand#$remote/}
>           # Assert $remote/$trailer == $shorthand
>           # DWIM $trailer into
>           # - refs/heads/$trailer
>           # - refs/tags/$trailer
>           # etc.
>           for dwimmed_ref in dwim_ref($trailer)
>           do
>               # Map $dwimmed_ref through refspec to get
>               # remote-tracking ref, e.g. mapping
>               # "refs/heads/spam" to "refs/remotes/$remote/heads/spam"
>               remote_ref=map_through_refspec($dwimmed_ref, $remote)
>               if test -n "$remote_ref"
>               then
>                   # Add $remote_ref to list of candidates
>               fi
>           done
>           ;;
>         *)
>           # Non-match, ignore
>           ;;
>       esac
>   done
> 
>   # We now have a list of (fully qualified) ref candidates
>   # for $shorthand.
> 
>   # If there are zero candidates, there is no match for $shorthand.
> 
>   # If there is only one candidate, we have found an unambiguous
>   # match for $shorthand.
> 
>   # If our current context demands a SHA1 object name, and all
>   # candidates point to the same SHA1, there is no ambiguity.
> 
>   # Otherwise, $shorthand is ambiguous.
> 

The current code doesn't care about configured remotes at all.  It
simply looks for $X in:

  refs/remotes/$X

and

  refs/remotes/$X/HEAD

So it is not the configured remotes which are special, but rather that
is a special namespace. For remotes configured with the default
refspecs, it ends up the same. But it also lets me do stuff like:

  # one-off fetch, but put it somewhere useful to us
  git fetch git://host/foo.git refs/heads/*:refs/remotes/foo/*

and then still get the shortcut of "foo/master".

I think adapting that to your scheme is pretty straighforward, though.

Given 1/2/3, you would look for tags in:

  refs/remotes/1/tags/2/3
  refs/remotes/1/2/tags/3

and then similarly heads in:

  refs/remotes/1/heads/2/3
  refs/remotes/1/2/heads/3

And then complain of ambiguity if they both match (which will almost
_never_ happen, unless you have a totally insane repo setup. So this is
really just about having well-defined rules just in case, and probably
won't affect most people in practice. In most cases, it will just DWYM).

The "HEAD" thing remains simple. You check for:

  refs/remotes/1/2/3/HEAD

since HEAD is going to be at the top-level anyway.

> Using the above (pseudo)code, and assuming remotes "foo" and "foo/bar" exist 
> (with remote branches "bar/baz" and "baz", respectively, and default new-
> style refspecs), then the "foo/bar/baz" shorthand would resolve to the 
> following two remote-tracking branches:
> 
> - refs/remotes/foo/heads/bar/baz
> - refs/remotes/foo/bar/heads/baz
> 
> This would likely result in an "ambiguous shorthand" error, unless the 
> current context wants a SHA1 object name, and the two remote-tracking refs 
> happen to point to the same SHA1 (in which case the result is unambiguous).

Yeah, I think I was just being dumb asking about the order. Of course it
shouldn't matter because we should complain of ambiguity.

> FWIW, if I run "git log some_topic" and "some_topic" only exists as a 
> remote-tracking ref ("refs/remotes/origin/heads/some_topic"), I do think I 
> would prefer git to DWIM it, instead of simply failing with:
> 
>   fatal: bad revision: some_topic
> 
> This would be somewhat in line with the DWIMing already performed by "git 
> checkout some_topic".

I'm not sure I agree, but then I'm not sure I really like the "git
checkout" DWIM, either. :)

However, I think this is an orthogonal topic to the reorganization of
the refs. So one doesn't have to come with the other.

-Peff

Re: Q: how can i find the upstream merge point of a commit?

[Junio C Hamano]

Jeff King <peff@github.com> writes:

> Given 1/2/3, you would look for tags in:
>
>   refs/remotes/1/tags/2/3
>   refs/remotes/1/2/tags/3
>
> and then similarly heads in:
>
>   refs/remotes/1/heads/2/3
>   refs/remotes/1/2/heads/3

> And then complain of ambiguity if they both match (which will almost
> _never_ happen, unless you have a totally insane repo setup. So this is
> really just about having well-defined rules just in case, and probably
> won't affect most people in practice. In most cases, it will just DWYM).
>
> The "HEAD" thing remains simple. You check for:
>
>   refs/remotes/1/2/3/HEAD
>
> since HEAD is going to be at the top-level anyway.

Gaah, why is this even a good thing?

Yes, you demonstrated that it is _possible_ to define disambiguation
rules, but do we currently allow (or horrors encourage) hierarchical
remote nicknames, and do people rely on being able to do so?  What
workflows benefit from such a confusing layout?

I am not fundamentally opposed to it, but just trying to tell between "we
do so because we can" and "because we need to for such and such reasons".

Re: Q: how can i find the upstream merge point of a commit?

[Jeff King]

On Wed, Jun 15, 2011 at 04:53:55PM -0700, Junio C Hamano wrote:

> Jeff King <peff@github.com> writes:
> 
> > Given 1/2/3, you would look for tags in:
> >
> >   refs/remotes/1/tags/2/3
> >   refs/remotes/1/2/tags/3
> >
> > and then similarly heads in:
> >
> >   refs/remotes/1/heads/2/3
> >   refs/remotes/1/2/heads/3
> 
> > And then complain of ambiguity if they both match (which will almost
> > _never_ happen, unless you have a totally insane repo setup. So this is
> > really just about having well-defined rules just in case, and probably
> > won't affect most people in practice. In most cases, it will just DWYM).
> >
> > The "HEAD" thing remains simple. You check for:
> >
> >   refs/remotes/1/2/3/HEAD
> >
> > since HEAD is going to be at the top-level anyway.
> 
> Gaah, why is this even a good thing?

I do think it's slightly insane, but if we are going to have "foo/bar"
map into "refs/remotes/foo/heads/bar", then we have to start giving some
significance to the slash; a straight append won't work anymore. It may
be enough to say "the first slash always ends the part between "remotes"
and "heads" (i.e., remotes cannot have slashes).

> Yes, you demonstrated that it is _possible_ to define disambiguation
> rules, but do we currently allow (or horrors encourage) hierarchical
> remote nicknames, and do people rely on being able to do so?  What
> workflows benefit from such a confusing layout?
> 
> I am not fundamentally opposed to it, but just trying to tell between "we
> do so because we can" and "because we need to for such and such reasons".

My reasoning is that we don't disallow remote names with slashes, nor do
we disallow people putting arbitrarily nested refs into refs/remotes. So
in the name of compatibility, we should assume people are doing it and
not break them.

If we want to declare this illegal, I'm not too opposed. The only use
case I could think of is somebody who works with two different sets of
remotes, like "upstream" people and internal people. E.g., if I'm at
company "foo" working on linux internally, I might have a few remotes:

  origin: linus
  foo/alice: coworker alice's tree
  foo/bob: coworker bob's tree

And then I could ask questions that involve globbing on the refs like
"which commits are in my company but not published upstream?"
Something like:

  git log \
    `git for-each-ref --format='%(objectname)' refs/remotes/foo/*` \
    --not linus/master

I've never actually seen anything like this, though. That was just the
only useful example I could come up with.

-Peff

Re: Q: how can i find the upstream merge point of a commit?

[Jakub Narebski]

Jeff King <peff@github.com> writes:
> On Wed, Jun 15, 2011 at 04:53:55PM -0700, Junio C Hamano wrote:

> > Yes, you demonstrated that it is _possible_ to define disambiguation
> > rules, but do we currently allow (or horrors encourage) hierarchical
> > remote nicknames, and do people rely on being able to do so?  What
> > workflows benefit from such a confusing layout?
> > 
> > I am not fundamentally opposed to it, but just trying to tell between "we
> > do so because we can" and "because we need to for such and such reasons".
> 
> My reasoning is that we don't disallow remote names with slashes, nor do
> we disallow people putting arbitrarily nested refs into refs/remotes. So
> in the name of compatibility, we should assume people are doing it and
> not break them.
> 
> If we want to declare this illegal, I'm not too opposed. The only use
> case I could think of is somebody who works with two different sets of
> remotes, like "upstream" people and internal people. E.g., if I'm at
> company "foo" working on linux internally, I might have a few remotes:
> 
>   origin: linus
>   foo/alice: coworker alice's tree
>   foo/bob: coworker bob's tree

I currently have "gsoc2008/gitweb-caching" and "gsoc2010/gitweb-write"
remotes in my clone of git.git repository...

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: Q: how can i find the upstream merge point of a commit?

[Junio C Hamano]

Ingo Molnar <mingo@elte.hu> writes:

> Still it's not entirely logical that 'foreign' tags invade another 
> branch this aggressively.

Is it a problem for "describe", or is the root of the problem that git
allowed you to slurp in 'foreign' tags that you do not care about?

Re: Q: how can i find the upstream merge point of a commit?

[Ingo Molnar]

* Junio C Hamano <gitster@pobox.com> wrote:

> Ingo Molnar <mingo@elte.hu> writes:
> 
> > Still it's not entirely logical that 'foreign' tags invade another 
> > branch this aggressively.
> 
> Is it a problem for "describe", or is the root of the problem that 
> git allowed you to slurp in 'foreign' tags that you do not care 
> about?

Well, if i checked out a linux-next related branch i'd expect those 
tags to go live, but if i stayed on -git i'd expect only Linus's tags 
to live.

I would not expect the linux-next tags to go away altogether - i 
added it as a remote, so i'd expect to see 'its' tags when i check it 
out.

at least that's my naive expectation from a 'remote' repository - if 
there's a better way to think about this then i'm eager to improve
:-)

Thanks,

	Ingo