Re: Q: how can i find the upstream merge point of a commit?
- From
Jakub Narebski <jnareb@gmail.com>
- Date
- Jun 16, 2011, 11:33 UTC
- Message-ID
- <m3aadiui6d.fsf@localhost.localdomain>
- In-Reply-To
- <20110616004803.GD20355@sigill.intra.peff.net>
Jeff King <peff@github.com> writes:
> On Wed, Jun 15, 2011 at 04:53:55PM -0700, Junio C Hamano wrote:
Show 21 quoted lines
> > 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