Problem: It is not possible to push for Gerrit review
as you will always try to push to /refs/heads/... on
the remote. As you should not be forced to work on a
branch with the same name as some branch on the remote,
some more flexibility in the selection of destination
branch is also needed.
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.
Specify both the remote repository to push to as well as
the specific branch on that remote. This gives the flexibility.
Add option to specify "Gerrit review". If selected, replace
the traditional "heads" with the artificial "for" in the
destination ref spec. This is what actually solved the trigger
problem.
Limit the branches to select from to the known branches
for currently selected remote. This is motivated in better
usability. Works only when "usettk" is true - it is left for
further study how to change the values in tk_optionMenu on the
fly.
Signed-off-by: Joergen Edelbo <redacted>
---
Hi there,
We are at Napatech A/S just about to roll out a Git/Gerrit/Jenkins
solution. It will really help the gui oriented people in pushing
commits if this can be done directly in git-gui.
BR
Joergen Edelbo
Napatech A/S
lib/transport.tcl | 184 +++++++++++++++++++++++++++++++++++++++++------------
1 file changed, 142 insertions(+), 42 deletions(-)
Hi,
On Mon, Sep 02, 2013 at 10:54:19AM +0200, Joergen Edelbo wrote:
Problem: It is not possible to push for Gerrit review
as you will always try to push to /refs/heads/... on
the remote. As you should not be forced to work on a
branch with the same name as some branch on the remote,
some more flexibility in the selection of destination
branch is also needed.
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.
Specify both the remote repository to push to as well as
the specific branch on that remote. This gives the flexibility.
Add option to specify "Gerrit review". If selected, replace
the traditional "heads" with the artificial "for" in the
destination ref spec. This is what actually solved the trigger
problem.
Limit the branches to select from to the known branches
for currently selected remote. This is motivated in better
usability. Works only when "usettk" is true - it is left for
further study how to change the values in tk_optionMenu on the
fly.
Signed-off-by: Joergen Edelbo <redacted>
---
Hi there,
We are at Napatech A/S just about to roll out a Git/Gerrit/Jenkins
solution. It will really help the gui oriented people in pushing
commits if this can be done directly in git-gui.
I like where this is heading. I myself was thinking about this some time
ago. Lets include Pat in the CC, since he is the current maintainer of
git-gui.
Give me some time to review/testdrive the patch.
Cheers Heiko
From: Johannes Sixt <hidden> Date: 2016-06-15 22:58:38
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?
-- Hannes
Hi,
I am not quite sure what your concern is.
Anyway - I don't think you are any more restricted with this change than before. If you currently work on a topic branch, and the same branch exists on the chosen remote, then this branch will be the default one to push to.
BR Jørgen Edelbo
-----Original Message-----
From: Johannes Sixt [mailto:j.sixt@viscovery.net]
Sent: 5. september 2013 08:42
To: Jørgen Edelbo
Cc: git@vger.kernel.org; spearce@spearce.org; hvoigt@hvoigt.net
Subject: Re: [PATCH] git-gui: Modify push dialog to support Gerrit review
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?
-- Hannes
From: Johannes Sixt <hidden> Date: 2016-06-15 22:58:38
Please do not top-post.
Am 9/5/2013 10:29, schrieb Jørgen Edelbo:
-----Original Message----- From: Johannes Sixt
quoted
Am 9/2/2013 10:54, schrieb Joergen Edelbo:
quoted
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.
-- Hannes
-----Original Message-----
From: Johannes Sixt [mailto:j.sixt@viscovery.net]
Sent: 5. september 2013 10:57
Please do not top-post.
Am 9/5/2013 10:29, schrieb Jørgen Edelbo:
quoted
-----Original Message----- From: Johannes Sixt
quoted
Am 9/2/2013 10:54, schrieb Joergen Edelbo:
quoted
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.
From: Johannes Sixt <hidden> Date: 2016-06-15 22:58:38
Am 9/5/2013 11:18, schrieb Jørgen Edelbo:
Forgetting to push something that you have just
completed is very far from what I am used to.
"Forgetting to push" is just one of many reasons why a branch that is not
equal to HEAD is not yet pushed... The new restriction is just too tight.
-- Hannes
On Thu, Sep 05, 2013 at 09:18:25AM +0000, Jørgen Edelbo wrote:
quoted
-----Original Message-----
From: Johannes Sixt [mailto:j.sixt@viscovery.net]
Sent: 5. september 2013 10:57
Please do not top-post.
Am 9/5/2013 10:29, schrieb Jørgen Edelbo:
quoted
-----Original Message----- From: Johannes Sixt
quoted
Am 9/2/2013 10:54, schrieb Joergen Edelbo:
quoted
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
is not.
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.
Cheers Heiko