On Mon, Mar 09, 2009 at 05:07:08PM -0700, Junio C Hamano wrote:
> Finn Arne Gangstad <finnag@xxxxxxx> writes:
>
> I think the last four are more or less sane, but I am not sure about the
> first three, which makes it very unfortunate that the former depends on
> the latter.
No problem splitting them up, there is just a single function that is
shared between 1-3 and 4-7 really.
[...]
> * What's the point of having --matching option, when you can already say
> ':', i.e.
>
> $ git push origin :
If you have the name of your remote easily available, --matching is
identical to "git push remote :". As I believe I found out, getting
the name of the current remote is a bit more tedious than it should
be, which is why I also suggested being able to use "-" as the current
remote.
If a way to specify the default remote is possible, --matching would
not be necessary, but would probably be more obvious to the reader
than "git push - :" or whatever we can agree on.
> * What's the point of having --current option, when you can already
> say HEAD, i.e. $ git push origin HEAD
It does something very different. Maybe --tracking would be a better name.
--current does basically this:
branch=`git-symbolic-ref HEAD`
branch=${branch#refs/heads/}
remote=$(git config branch.$branch.remote)
for remotebranch in $(git config branch.$branch.merge); do
git push $remote $branch:$remotebranch
done
This is the shortest shell script sequence I could find to mimic the
behaviour, maybe I have missed something very obvious. All error
handling is removed for clarity.
The goal here is to be able to:
git checkout -b junios-next origin/next
git push --current <=> git push origin junios-next:next
git push origin HEAD would do git push origin junios-next:junios-next,
which was not the intention.
It seems that there is an assumption that branch names are identical
in different repositories, we find that that is not the case at all,
people choose local names that make sense to themselves. Or, from
another viewpoint, even if branches have the same name in two
repositories, they are not necessarily (strongly) related!
"A tracks B" can be a much stronger relation than "A has the same name
as B".
> * Is push.default still necessary if we had "remote.*.push" (where '*' is
> literally an "asterisk") that is used as a fall-back default when there
> is no "remote.<name>.push" for the remote we are about to push to?
The main reason for push.default is to be able to change the default
behaviour for git push to push nothing in a staged manner, and still
let people who are used to and fond of the old behavior continue as before.
You are thinking of something like this in .gitconfig?
[remote "*"]
push = __something__
Previously you indicated that there is no way to specify the current
matching rule in a remote push line I think?
- Finn Arne
--
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
