On Tue, 2011-04-26 at 10:33 -0700, Junio C Hamano wrote: > Dan McGee <dpmcgee@xxxxxxxxx> writes: > > > $ git fetch -v > > From git://git.kernel.org/pub/scm/git/git > > = [up to date] html -> origin/html > > ... > > I see this full URL output as a nice reminder of what "origin" refers to, > especially when you said "git fetch -v origin". This is especially useful > when you are fetching from different locations that house repositories of > the same project (e.g. among my multiple git.git working trees on my > notebook, some of them fetch from my private, primaty development machine > and others from public k.org). > > Changing this output ... > > > Versus the new output: > > > > $ ./git fetch -v > > From origin > > ... this way feels like a regression to me. > > > Alternatively, we could do something like > > From origin (git://git.kernel.org/pub/scm/git/git) > > That is much less problematic. > > But let's step back a bit. What problem are you trying to solve? > > Are you trying to give a reminder that you are interacting with 'origin' > when you said "git fetch -v" without saying where you are fetching from? > I think that is a good thing to aim for (the same reasoning behind the > comment of mine above). If so, the ideal change from my gut feeling is to > add an extra " (origin)" at the end, like so: > > From git://git.kernel.org/pub/scm/git/git (origin) > > when and only when the fetch is done without mentioning any remote > nickname; iow, "git fetch -v origin" or "git fetch -v git://.../git" won't > get the extra " (origin)" at the end. I was about to compose mail to the same effect, so I'll just agree instead. -- -Drew Northup ________________________________________________ "As opposed to vegetable or mineral error?" -John Pescatore, SANS NewsBites Vol. 12 Num. 59 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html