Philip Jägenstedt [off-list ref] writes:
1. If I make a typo with remote set-branches, fetch will fail with
"fatal: Couldn't find remote ref refs/heads/typotopic" and not fetch
anything at all.
At that point you can notice the earlier typo and remove or fix the fetch
refspec you have.
Alternatively, set-branches could run ls-remote against the remote and
notice that there is no such branch over there. However, even if you got
the branch name right when you did "set-branches", you would still see the
same "Couldn't find" when the branch gets removed over there, so you would
need a way to remove or fix the fetch refspec you have *anyway*.
So, assuming that there is no easy way to remove one branch from the set
of branches tracked from a given remote, it is much more important to add
such a way. Checking against a typo when "set-branches" is run is "nicer
to have" but lack of it is not a show-stopper.
Wouldn't "git config --unset remote.origin.fetch '/typotopic'" be
sufficient in the meantime even if a user fears "vi .git/config"?
2. If I forget that I've previously worked with footopic and
set-branches --add it again, I'll get a duplicate line in my config.
I do not know the duplicate hurts anything, but I agree that it would be
more aescetically pleasing if "--add" noticed what you already had and
avoided duplicates.
3. When I don't care about footopic anymore, there's no clear way to
stop fetching it and remove refs/remotes/main/footopic.
Isn't the lack of "set-branches --delete" the same as #1 above? The
latter would be "branch -r -d main/footopic" but I could imagine
"set-branches --delete" would do that for you once implemented.
4. If set-branches --delete existed one could end up with no fetch
lines in the remote config, at which point fetch falls back to
fetching HEAD, instead of the expected nothing.
Don't do that, then ;-)
I could imagine a new preference "fetch.$remote.default=nothing" that
causes "git fetch" to fail with "You have fetch.$remote.default=nothing
set, so I am not fetching anything from there without any configured
refspec". The default would be fetch.$remote.default=HEAD, I would guess.
The preference can be set automatically when you use "set-branches"
without "--add" for a given remote, as use of "set-branches" is a clear
indication that you want to deviate from the built-in default behaviour
when interacting with that remote.
I'd appreciate feedback on these issues so that I don't waste time
trying to patch the wrong problems. Suggestions for an alternative
work flow is of course also most welcome!
Admittedly I wouldn't use "set-branches" myself (it is far easier to tweak
with "vi .git/config", and I wasn't involved in), but looking at the whole
history of the feature with "git log --grep=set-branch builtin/remote.c",
I have a feeling that not many people used, cut by its still-unrounded
edges, and polished the subcommand by rounding them out yet, and it has a
large room for improvement.
It would have saved you time to wait for a round-trip if you did the above
"git log" yourself to find out from whom this subcommand came from, and
looked at list archive to see if the original author is still active here
(in this case he is), and Cc'ed him before posting the message I am
responding to.
On Sun, Feb 19, 2012 at 22:36, Junio C Hamano [off-list ref] wrote:
Philip Jägenstedt [off-list ref] writes:
quoted
1. If I make a typo with remote set-branches, fetch will fail with
"fatal: Couldn't find remote ref refs/heads/typotopic" and not fetch
anything at all.
At that point you can notice the earlier typo and remove or fix the fetch
refspec you have.
Alternatively, set-branches could run ls-remote against the remote and
notice that there is no such branch over there. However, even if you got
the branch name right when you did "set-branches", you would still see the
same "Couldn't find" when the branch gets removed over there, so you would
need a way to remove or fix the fetch refspec you have *anyway*.
So, assuming that there is no easy way to remove one branch from the set
of branches tracked from a given remote, it is much more important to add
such a way. Checking against a typo when "set-branches" is run is "nicer
to have" but lack of it is not a show-stopper.
Wouldn't "git config --unset remote.origin.fetch '/typotopic'" be
sufficient in the meantime even if a user fears "vi .git/config"?
Yeah, one can recover if one knows what config "set-branches" maps to,
but I'd like this to be less error-prone so that I can recommend it to
others suffering from branch explosion. Tab completion and
"set-branches --remove" is probably a good start.
quoted
2. If I forget that I've previously worked with footopic and
set-branches --add it again, I'll get a duplicate line in my config.
I do not know the duplicate hurts anything, but I agree that it would be
more aescetically pleasing if "--add" noticed what you already had and
avoided duplicates.
Right, it's not worthwhile by itself, but something to consider if
implementing --delete.
quoted
3. When I don't care about footopic anymore, there's no clear way to
stop fetching it and remove refs/remotes/main/footopic.
Isn't the lack of "set-branches --delete" the same as #1 above?
Kind of, several of these points can be solved by the same fixes.
The
latter would be "branch -r -d main/footopic" but I could imagine
"set-branches --delete" would do that for you once implemented.
Letting "set-branches --delete" manage this per-branch would be nice, I agree.
Would it be wrong, though, if "fetch --prune" and "remote prune"
simply pruned all refs under refs/remotes/main/ that were not fetched?
It seems to me that if one starts out with all branches and then
"set-branches main footopic", one really does want all other refs to
go away on the next fetch.
quoted
4. If set-branches --delete existed one could end up with no fetch
lines in the remote config, at which point fetch falls back to
fetching HEAD, instead of the expected nothing.
Don't do that, then ;-)
I could imagine a new preference "fetch.$remote.default=nothing" that
causes "git fetch" to fail with "You have fetch.$remote.default=nothing
set, so I am not fetching anything from there without any configured
refspec". The default would be fetch.$remote.default=HEAD, I would guess.
The preference can be set automatically when you use "set-branches"
without "--add" for a given remote, as use of "set-branches" is a clear
indication that you want to deviate from the built-in default behaviour
when interacting with that remote.
That sounds like a good idea. To make sure that I understand the
notation, the actual config would look something like this:
[remote "origin"]
url = git://github.com/gitster/git.git
# no fetch, it was removed
[fetch "origin"]
default = nothing
This looks a bit odd to me, shouldn't the new setting file under
[remote "origin"]?
quoted
I'd appreciate feedback on these issues so that I don't waste time
trying to patch the wrong problems. Suggestions for an alternative
work flow is of course also most welcome!
Admittedly I wouldn't use "set-branches" myself (it is far easier to tweak
with "vi .git/config", and I wasn't involved in), but looking at the whole
history of the feature with "git log --grep=set-branch builtin/remote.c",
I have a feeling that not many people used, cut by its still-unrounded
edges, and polished the subcommand by rounding them out yet, and it has a
large room for improvement.
That was my impression as well.
It would have saved you time to wait for a round-trip if you did the above
"git log" yourself to find out from whom this subcommand came from, and
looked at list archive to see if the original author is still active here
(in this case he is), and Cc'ed him before posting the message I am
responding to.
Thanks for the tip. (I did look at the original commit and search the
archives, but found no answers.)
--
Philip Jägenstedt
Hi Philip,
Philip Jägenstedt wrote:
It seems to me that if one starts out with all branches and then
"set-branches main footopic", one really does want all other refs to
go away on the next fetch.
I would expect set-branches to remove the remote-tracking branches
that are no longer relevant itself, actually.
Martin, does this seem sensible to you? If so, I'll be happy to look
into it in the next few days (or I'll be even happier someone else
gets to it first).
Hope that helps,
Jonathan