Carl Worth [off-list ref] writes:
On Thu, 16 Nov 2006 09:57:00 -0800, "Michael K. Edwards" wrote:
quoted
What do you want all of those branches for? They haven't been
published to you (that's a human interaction that doesn't go through
git), so for all you know they're just upstream experiments, and doing
things with them is probably shooting yourself in the foot.
The same "what do you want them all for" question could be asked of
git-clone which also fetches all available branches. I really just
want to be able to easily watch what's going on in multiple
repositories.
I want to be able to just say "git update" (or whatever) and then be
able to list and browse and explore the stuff locally.
...
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.
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.
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
Johannes Schindelin [off-list ref] wrote:
I introduced the remote.<nick>.{url,fetch,push} entries into the config
with the goal to enhance -fetch to remember the current command line with
a setting. I was the only one to find that useful.
BTW I still would argue that it is better to write the remote information
into the config, because you have a saner way to manipulate that from
scripts than .git/remotes/<nick>.
I'm *fully* in favor of the remote.<nick>.{url,fetch,push} entries
in the config file. I've pretty much switched every repository to
that format at this point.
In writing git-gui I'm finding it much, much easier to manage
things through repo-config than to do any mucking around in the
.git/remotes directory. Yes, the remote files have simple format,
but I can get everything in one "git repo-config --list" pull it
all into a Tcl array and work with it; using .git/remotes means I
have to open the file and read each line too. :-(
--
Hi,
On Fri, 17 Nov 2006, Carl Worth wrote:
1. Making clone do the --use-separate-remotes behavior by default
Fully agree.
2. Taking advantage of that consistently for all branches instead of a
special master:origin mapping in clone
Fully agree, too.
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?)
I introduced the remote.<nick>.{url,fetch,push} entries into the config
with the goal to enhance -fetch to remember the current command line with
a setting. I was the only one to find that useful.
BTW I still would argue that it is better to write the remote information
into the config, because you have a saner way to manipulate that from
scripts than .git/remotes/<nick>.
4. Making git-fetch handle the disappearance of a remote branch
gracefully
I think a message like "This remote branch no longer exists. Maybe you
want to use 'git branch -d <branch>' to remove it locally?" should
suffice.
5. Adding something like git-fetch --all to allow it to pick up all new
branches
IIRC this idea was rejected, but I would find it useful. Especially with
what Han-Wen said: you can store the branches you fetch with "git fetch
--all <nick>" under .git/refs/remotes/<nick>/<branchname>.
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.
First thought was: it is only useful if you want to track multiple
repositories. But next thought: if you mark the correct remotes in every
of your local repositories, you don't have to remember which nick your
upstream has. Yeah, I like it. But maybe do it as "git fetch --update" to
avoid more cluttering of the bindir?
Ciao,
Dscho