The basic idea is that in a triangular workflow, it's useful to be able
to refer to both @{upstream} and "the place I would push to" with a
shorthand. This idea was discussed over a year ago:
http://thread.gmane.org/gmane.comp.version-control.git/240144/focus=240198
I've found it useful since then, so I decided to clean it up and submit
it. This iteration renames it to "@{push}" (rather than "@{publish}"),
which is more descriptive. It's rebased, as there were some changes in
the area, and it also fixes some bugs in the original (of course, I may
also have _introduced_ bugs, as this is largely a rewrite that has not
had a year's worth of exercise).
I also took the opportunity to do some more aggressive refactoring of
the remote.c code, as there were some bits there that confused me every
time I looked at it. I think the result is easier to follow.
[1/6]: remote.c: drop default_remote_name variable
[2/6]: remote.c: drop "remote" pointer from "struct branch"
[3/6]: remote.c: hoist branch.*.remote lookup out of remote_get_1
[4/6]: remote.c: provide per-branch pushremote name
[5/6]: sha1_name: refactor upstream_mark
[6/6]: sha1_name: implement @{push} shorthand
The one thing I _didn't_ do here is refactor the logic in
builtin/push.c so what we could reuse it. There's still a switch
statement here on push_default. I don't like that, but I spent an hour
or so trying to pull out the push.c logic, and it got rather nasty.
There are a lot of global variables that get mutated by one-off
functions, and it all needs to happen in the right order. It looked like
any serious refactoring there is going to have a risk of regressions in
push.
So I punted on that. The simplified logic that is here in sha1_name is
not too bad, and I feel like we can unify the two at a later date if we
want to. And I'd much rather see bug reports like "@{push} doesn't act
like git-push" and deal with that, as opposed to "your series breaks
push".
-Peff
--
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