Home » Eclipse Projects » EGit / JGit » Push to upstream - confusing dialogue
|
| Re: Push to upstream - confusing dialogue [message #896153 is a reply to message #896128] |
Tue, 17 July 2012 12:27   |
 R Shapiro
Messages: 386
Registered: June 2011 |
Senior Member |
|
|
The SVN/CVS operation here is 'commit'. If you think about the meaning of the word 'commit' that's the appropriate time for a review. Same is true for Git: do your review as part of the commit operation. The Git Staging view is very good for this. Reviewing per commit also enforces the important idea that commits should be self-contained and intended to address one specific issue.
Push is entirely different. At this point you should already be satisfied with the changes you made, given that they're already in your local repository. You can still review all the changes relative to the remote if you feel you must, either with the Synchronization view in egit or, much more efficiently, with command-line Git. But note that if you change your mind about something, the cleanup process is more involved than simply editing files. By definition at least one local commit will have to be undone, and it might not be immediately obvious which one, and which parts of it you might still want to keep.
Better to get in the habit of reviewing at commit time rather than push time. To put it another way, don't commit to any change without reviewing it first. If you do that, you can just push.
|
|
| | |
| Re: Push to upstream - confusing dialogue [message #896705 is a reply to message #896637] |
Thu, 19 July 2012 12:29 |
R Shapiro
Messages: 386
Registered: June 2011 |
Senior Member |
|
|
If your complaint is that the post-push dialog showing what commits were pushed is somewhat pointless, I agree, more or less. For sure it's useless as a review tool. As an information display, I have very occasionally double-clicked entries in this dialog to look at them in a Commit view, just as a kind of confirmation. But that's unusual. If the post-push dialog went away completely, I wouldn't mind.
To review before pushing, the Egit answer would be to use the Synchronization view. That's exactly what this view is intended for: comparing the active branch to some other branch or reference (the remote ref in this case). I happen not to like the egit Synchronization view so when I feel the need to do a pre-push review, I use command-line Git, as it's a lot more efficient. If you configure a decent difftool you can get a reasonable gui view this way.
re: label decorations, I have not any problem with status decorations on branches that track a remote ref other than origin/master.
On the other hand if you're referring to the lack of status decorations when a branch tracks another local branch (for example a topic branch tracking master) that's definitely a significant nuisance for me, multiple times every day. I filed a bug way back in April, to no effect. No one else seems to be bothered by this, at least not that I've seen on this forum. This is a puzzle to me. I think of the regular creation and destruction of local work branches as a routine Git operation, and I always want these local branches to track whatever branch it was created from, specifically so I can see the relative status very quickly.
|
|
| |
| Re: Push to upstream - confusing dialogue [message #896747 is a reply to message #896705] |
Thu, 19 July 2012 14:56 |
|
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Am 19.07.2012 14:29, schrieb R Shapiro:<br>
<blockquote cite="mid:ju8uk7$6nt$1@xxxxxxxxe.org" type="cite">If
your complaint is that the post-push dialog showing what commits
were pushed is somewhat pointless, I agree, more or less. For
sure it's useless as a review tool. As an information display, I
have very occasionally double-clicked entries in this dialog to
look at them in a Commit view, just as a kind of confirmation.
But that's unusual. </blockquote>
And could probably done via the history view, as well.<br>
<br>
<blockquote cite="mid:ju8uk7$6nt$1@xxxxxxxxe.org" type="cite">If
the post-push dialog went away completely, I wouldn't mind.
<br>
<br>
To review before pushing, the Egit answer would be to use the
Synchronization view. That's exactly what this view is intended
for: comparing the active branch to some other branch or reference
(the remote ref in this case). I happen not to like the egit
Synchronization view so when I feel the need to do a pre-push
review, I use command-line Git, as it's a lot more efficient. If
you configure a decent difftool you can get a reasonable gui view
this way.
<br>
</blockquote>
I'm going to try it again. When I first used the Synchronize view
with EGit it didn't work at all but that's really some time ago ;-)<br>
<br>
<blockquote cite="mid:ju8uk7$6nt$1@xxxxxxxxe.org" type="cite">
<br>
re: label decorations, I have not any problem with status
decorations on branches that track a remote ref other than
origin/master.
<br>
</blockquote>
Here a proof from one of my workspaces:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=10767" alt=""><br>
<br>
I would expect to see exactly one outgoing commit, given the
committers/estepper/rmf branch is checked out because the local
branch is one commit ahead of the remote tracking branch. Am I
misunderstanding something?<br>
<br>
<blockquote cite="mid:ju8uk7$6nt$1@xxxxxxxxe.org" type="cite">On
the other hand if you're referring to the lack of status
decorations when a branch tracks another local branch (for example
a topic branch tracking master) that's definitely a significant
nuisance for me, multiple times every day. I filed a bug way back
in April, to no effect. No one else seems to be bothered by this,
at least not that I've seen on this forum. This is a puzzle to
me. I think of the regular creation and destruction of local work
branches as a routine Git operation, and I always want these local
branches to track whatever branch it was created from,
specifically so I can see the relative status very quickly.
<br>
</blockquote>
I don't think that I was referring to this situation but it seems to
make sense to me that the label decorator always shows the number of
commits that checked out branch is away from the branch it will be
pushed to.<br>
<br>
Cheers<br>
/Eike<br>
<br>
----<br>
<a class="moz-txt-link-freetext" href="http://www.esc-net.de">http://www.esc-net.de</a><br>
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a><br>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a><br>
<br>
<br>
<br>
</body>
</html>
Attachment: fffebijg.png
(Size: 71.90KB, Downloaded 368 times)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
| Re: Push to upstream - confusing dialogue [message #896837 is a reply to message #896830] |
Fri, 20 July 2012 05:10 |
|
Am 20.07.2012 01:44, schrieb R Shapiro:
> Quote:
>> I don't think that I was referring to this situation but it seems to
>> make sense to me that the label decorator always shows the number of
>> commits that checked out branch is away from the branch it will be
>> pushed to
>
>
> I would say the correct behavior would be the same as you would get with command-line Git via 'git status'. That
> means it can show both the ahead-of and behind-by counts, and applies whether the tracking is primarily for pull
> (local tracking) or for both push and pull (remote tracking).
>
>
> The decorations do in fact work this way if the active branch is tracking a remote reference. This part seems fine.
> It does NOT work if the active branch is tracking another local branch, which is what you get with the standard Git
> topic-branch pattern. Basically egit is forcing us to choose between using a recommended pattern, on the one hand, and
> ready access to status info, on the other. It's a nasty bug that should have been fixed long ago.
I notice that the nasty NNTP bridge has removed the screenshot I had embedded (and left all the HTML markup). That
mayhave made it difficult or impossible to see my exact situation. But I start to see what you're saying. Let me
explain/ask again:
I've created a local branch "committers/estepper/rmf" from local master and checked it out. I *thought* that it, by
naming convention (better: pattern configuration aka fetch ref spec?), tracks its remote tracking branch that properly
gets created during the first push. But indeed it seems that it still tracks my local master branch, which would explain
my confusion about the decoration.
So my question should be: What is the simplest way to create a new remote branch, together with a respective remote
tracking branch and a local branch to checkout and work with? I think that would be more or less the same thing as a
normal new branch in CVS or SVN, which I can create with a single and obvious mouse click there.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: Push to upstream - confusing dialogue [message #896938 is a reply to message #896837] |
Fri, 20 July 2012 13:35 |
R Shapiro
Messages: 386
Registered: June 2011 |
Senior Member |
|
|
Tracking doesn't use name patterns. A branch tracks another branch or reference iff you explicitly configure it to do so. Usually this is done at branch creation, either with the "--track" option in Git or by selecting the Rebase or Merge radio button in the EGit "Create Branch" dialog. You can also do it after the fact by setting repository configuration values.
As for creating a new remote branch and tracking it, this is a known issue is EGit/JGit. In command line Git, the creation of a new remote branch from a local branch automatically configures the local branch to track the corresponding remote reference. JGit doesn't do this. To configure tracking in this case you must either delete and recreate the local branch with the right options in the Create Branch dialog, or you must add configuration values for branch.<local-branch>.remote and branch.<local-branch>.merge where <local-branch> is the name of your local branch. You might also need to adjust remote.<remote-name>.push. where <remote-name> is the name of the remote (typically 'origin'). If you want pull to use rebase rather than merge, that's yet another config setting.
As you can see, the simplest option is to use command-line Git to create the new remote branch. It does everything for you. If you want to use EGit, the simpler choice is to delete the local branch, then recreate it from the remote reference, selecting either Merge or Rebase in the Create Branch dialog. Setting the configuration directly isn't difficult but it's certainly the least simple option.
|
|
| | |
Goto Forum:
Current Time: Tue Apr 23 10:58:15 GMT 2024
Powered by FUDForum. Page generated in 0.03866 seconds |
] 
Search
Help
Register
Login
Home
. So it's a little bit pity to remove it. Better try to move it before push to give it a reason to exists.