On Thu, Sep 05, 2013 at 09:18:25AM +0000, Jørgen Edelbo wrote:
> > -----Original Message-----
> > From: Johannes Sixt [mailto:j.s...@viscovery.net]
> > Sent: 5. september 2013 10:57
> > Please do not top-post.
> > Am 9/5/2013 10:29, schrieb Jørgen Edelbo:
> > > -----Original Message----- From: Johannes Sixt
> > >> Am 9/2/2013 10:54, schrieb Joergen Edelbo:
> > >>> Changes done:
> > >>>
> > >>> Remove selection of branches to push - push always HEAD. This can be
> > >>> justified by the fact that this far the most common thing to do.
> > >>
> > >> What are your plans to support a topic-based workflow? "Far the most
> > >> common thing to happen" is that someone forgets to push completed
> > >> topics. With this change, aren't those people forced to relinguish
> > >> their current work because they have to checkout the completed topics
> > >> to push them?
> > >
> > > I am not quite sure what your concern is.
> > When I have completed topics A and B, but forgot to push them, and now I
> > am working on topic C, how do I push topics A and B?
> > You say I can only push HEAD. I understand this that I have to stop work on
> > C
> > (perhaps commit or stash any unfinished work), then checkout A, push it,
> > checkout B, push it, checkout C and unstash the unfinished work. If my
> > understanding is correct, the new restriction is a no-go.
> Ok, this way of working is not supported. It just never occurred to me that
> you would work this way. Forgetting to push something that you have just
> completed is very far from what I am used to. I think it comes most natural
> to push what you have done before changing topic. The reason I make a commit
> is to get it out of the door.
FWIW, I also think that we should keep the box which allows you to
select the branch to push. I did not realize that you were removing it
when I first glanced at your patch.
Even if your reasoning that pushing the currently checked out branch is
correct: This box has been around for too long, so it will annoy people
that got used to the fact that they can select the branch to push.
Another problem: It is not very intuitive to only select the branch to
push to. You can do that on the command line but IMO using
git push origin HEAD:refs/heads/<branchname>
is way less common than
git push origin <branchname>
and I think that should also be reflected in the gui. It might be more
common for a gerrit user but for the typical git user without gerrit it
So to make it easy for the user to transition from gui to commandline
and back with your patch I would expect: The user selects a branch
to push. The new "Destination Branches" section automatically selects/shows
the same name for the default case as destination (like the cli). So
if I only select the branch to push it behaves the same as before.
If you detect (I assume that is possible somehow) that the remote is a
gerrit remote: "Push for Gerrit review" would automatically be ticked and
the branch a git pull would merge (e.g. the one from branch.<name>.merge)
is selected as the destination branch under refs/for/... . If there is
no config for that, fallback to "master".
This is what I would expect with no further extension of the current git
command line behavior and config options. So that way your patch will be
an *extension* and not a change of behavior.
Another unrelated thing that is currently left out: You can transport
the local branchname when pushing to the magical gerrit refs/for/... . I
would like to see that appended as well. But opposed to the branch
selection that is not a show stopper for the patch more a side note.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html