[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    [PATCH 0/6] implement @{push} shorthand
From:       Jeff King <peff () peff ! net>
Date:       2015-03-31 17:33:40
Message-ID: 20150331173339.GA17732 () peff ! net
[Download RAW message or body]

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]