Re: Cleaning up git user-interface warts

[Carl Worth <cworth@cworth.org>]

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

On Fri, 17 Nov 2006 00:41:33 -0800, Junio C Hamano wrote:
> I have no objection to this if it is done in a controlled way
> that does not make life more difficult for people who work with
> multiple remote repositories.

That's fine with me. Maybe I didn't explain this well before, but my
desire is exactly for this to work with multiple repositories.

Specifically, what we have in cairo is a "central" shared tree that
many people push to. But we only have two branches there, (one for
bug-fixes only for our stable releases, and one for ongoing
development of new features, and that only of stuff that's well
cooked).

So that tree looks and acts an awful lot like our cvs tree back in the
past. It's often very linear and often fairly boring to look at in gitk.

Meanwhile, all the really interesting stuff happens in personal
repositories where people have their own branches for stuff that is
still getting cooked. This is what's a lot more fun to watch, and
there's a lot more distributed back-and-forth that goes on here as
people collaborate on things. And it's all this kind of collaboration
that cvs never helped with at all, but git has been great.

So, what I want is both "git update" for the central tree. I said we
only have two branches, but that's really only two that are
active---the "stable" branch is actually a new branch after every
major release. It was 1.0 for a while, is 1.2 now, and will be 1.4
later. So I want "git update" to automatically pick those new branches
up as they get created.

Meanwhile, I also want to use "git update" to track everything that
people are working on in the more wild personal trees. So, yes, I do
want "git update" to be able to track lots of remote repositories in a
sane way.

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).

The first problem we ran into when doing that months ago was that I
don't want any tracking branches to come across this way. Or else I
end up with behdad-origin, he then gets cworth-behdad-origin, ad
nauseum. So we filtered "origin" out, but it will be nice to revisit
this if there's a sane distinction in git now to separate tracking
branches from heads.

> And I think "git fetch" is the tool for what you want if
> enhanced properly; see Linus's message that explaind that we
> already have that support in "manually configurable" form but
> initializing and maintaining the configuration is currently all
> manual and can be improved.

Yes, git-fetch is lovely, and it's the need for manual configuration
that's a problem, (and the mixing up of heads and remote tracking
branches that has been in git historically).

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

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

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.

Anyway, something along those lines perhaps. Any feedback?

-Carl

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