+1. And much better than my RFC for "git clone --add".
Just some comments. I know it's in its early shape, tell me if you
want this kind of comments later.
* I think it is more coherent to list the tracked branches first and
second the "branch merges".
* In "git remote add <name> <remote>": git could use the remote url to
deduce a <name>, like what git-clone does.
* If a branch does not have a branch.<name>.remote git-remote does not
default it to "origin" and sends an:
Use of uninitialized value in string ne at
/home/santi/usr/stow/git/bin/git-remote line 222.
Maybe, in addition to this, git should require a branch.<name>.remote.
* With the config:
[remote "origin"]
url = git://git2.kernel.org/pub/scm/git/git.git
fetch = master:refs/remotes/origin/master
fetch = next:refs/remotes/origin/next
fetch = +refs/heads/pu:refs/remotes/origin/pu
fetch = refs/heads/*:refs/remotes/origin/*
[branch "next"]
merge=next
It outputs something as:
* remote origin
URL: git://git2.kernel.org/pub/scm/git/git.git
Tracked remote branches
html maint man master next pu todo
Tracked remote branches
pu
* The first "Tracked ..." is for the wildcards and the second for the
explicit fetch. Maybe it should join the two or mark different as:
Implicit tracked ...
Tracked ...
* The next and master branches are missing because they are written
without the refs/heads/ prefix. And for this reason there is no:
Remote branch(es) merged with 'git pull' while on branch next
next
(and the absence of branch.next.remote).
* In addition I would reformat this as:
Merges with 'git pull' while on branch:
"next" merges "next"
"topic" merges "master"
...
That's all for today :)
Santi
-
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