Re: Cleaning up git user-interface warts

Carl Worth [off-list ref] writes:

What I have been doing up to this point is a little script I wrote
that does git-ls-remote on the repository I want to track and writes a
.git/remotes file to bring in all their branches. So if I want to see
what behdad is up to, I first refresh his .git/remotes file with my:

	cairo-git-setup-remotes behdad
then:
	git fetch behdad

And I end up with a bunch of branch names with "behdad-" prefixes that
I can explore or blow away if I'm no longer interested, (could have
used a "behdad/" prefix as well).

I would suggest refs/remotes/behdad.

So, yes, I'll definitely look into improving this. I think the details
will involve:

1. Making clone do the --use-separate-remotes behavior by default

2. Taking advantage of that consistently for all branches instead of a
   special master:origin mapping in clone

This already should be the case if you use separate-remote.  I
haven't run "clone --separate-remote" myself for a long time,
but the design was certainly to make it behave that way.
Specifically, map everything in refs/heads/ at remote to
refs/remotes/$origin/ with corresponding names, one-to-one.

I do not see much reason to change the mapping of master:origin
which is done for the traditional layout.  The traditional
layout is not suitable for your workflow anyway, and that is why
you prefer separate-remote layout for your project, and I fully
agree it would suit you better.

3. Enhancing git-fetch (or other) to modify .git/remotes, (or was
   there a desire for some other branch-specific section in the config
   file?)

4. Making git-fetch handle the disappearance of a remote branch
   gracefully

5. Adding something like git-fetch --all to allow it to pick up all new
   branches

These three are easily done for separate-remote layout but at
that point you would not want --all but more powerful --mirror
(or --update if you want to use that word), which goes the whole
nine yards of noticing disappearance of remote branch, making
matching deletion of local tracking branch, updating
.git/remotes, etc.  I've muttered something similar in a nearby
thread; see below.

6. Adding a "git update" that does a fetch for all appropriately
   marked remotes.

On this last point, maybe we do something like:

	update=no|yes|all

in .git/remotes. Then git-clone would set this up with update=all for
origin so git-update would do a "fetch --all" on the origin
repository. Then step 3 above would have to provide for setting this
update option as appropriate.

I would prefer this to be kept in contrib/; it feels like it is
filling rather very narrow need.

Anyway, something along those lines perhaps. Any feedback?

I muttered something less elaborate in the nearby thread.

	Message-ID: [ref]
	Message-ID: [ref]

The part that deals with manual configuration (the last point in
the first message, and the second in message its entirety) is
something your workflow would not need nor want to worry about,
but I think it is necessary for different ref namespace layouts
and different workflows.  I think the automatable part (the
first two points in the "sensible thing to do" list in the first
message) is very relevant to what you talked about in your
message.