Community
Participate
Working Groups
It's not obvious for a user to remember/guess what will happen if clicking "Push to Upstream" from context menu. The menu item could for example show "Push to origin:master" or "Push to gerrit:refs/for/master" to be more explicit.
+100 - its one of the reasons I don't use egit much. I simply cannot grok what git to Upstream means. I don't even know where to configure/change it or which exact git command it refers to.
@Max: Hm, sorry to hear that. In theory it should do the same as a plain "git push". But there are quite a few configuration options that EGit may not handle (or bugs) so that the result is different. +1 to having a clear label. It will probably need a dynamic menu item (see how the "Push Branch 'master'..." menu item does it). Regarding the labels, I added a comment to bug 441938.
late answer, but IMO if git push Upstream does the same as a "git push" it really should be named as such. btw. part of the confusion for me is that I for the longest time in early day of git usage had my upstream remote named "upstream" and thus seeing "git push upstream" and it actually did not push to upstream was just confusing ;) but that said I think call it either just "git push" or add a more specific label based on the actual "upstream" branch would be much better.
This is very confusing for new users. It's been pretty common practice when dealing with github to refer to your fork as "origin" and the upstream project as "upstream". This makes ramping people up with git and the UI tools more difficult than it needs to be. Please also fix "Fetch from Uptsream".
[Batch change] Remove pre-3.7 Target Milestones If anyone on CC list is going to fix/implement this, please assign a new 3.7+ target milestone.
Would "Push to remote"
(In reply to Pierre-Yves B. from comment #6) > Would "Push to remote" Damn, bug in Bugzilla, adding yourself to CC list automatically (or voting?) sends anything you started typing as a comment without prompting. My suggestion would be to rename it to "Push to remote"/"Fetch from remote" in the first instance if the dynamic menu is more involved work. Like that we avoid the confusion from the overloaded term "Upstream", whilst still staying quite generic (as is "git push").
(In reply to Pierre-Yves B. from comment #7) > My suggestion would be to rename it to "Push to remote"/"Fetch from remote" > in the first instance if the dynamic menu is more involved work. Like that > we avoid the confusion from the overloaded term "Upstream", whilst still > staying quite generic (as is "git push"). To me, "remote" is as ambiguous as "upstream". On CLI, I never use just `git push` because I'm most often on detached branched, working on multiple remotes where I can push. Relying on some repo setting to keep the default target in mind is too dangerous. That's why I disambiguize everything and use `git push gerrit HEAD:refs/for/master`; when I push, I do need to see what I push (HEAD) and where I push to (gerrit:refs/for/master). EGit has the `Push branch...` menu that gives this capability, and I do use it always, even in some cases where "Push to Upstream" would do what I want, but I don't dare clicking it because I don't know what it's actually going to do; and that won't change until menu says the remote name and target refs for the push so that makes this menu totally useless and noisy to me while it could actually be useful and saving me a few clicks.
New Gerrit change created: https://git.eclipse.org/r/158119
I played around with a dynamic menu contribution for the entry. As stated in the gerrit comment, I am not quite sure about the actual label and there seems to be an issue with resizing the repositories view context menu. If a very long label is shown, the width stays the same for the next context menu which only has very short entries. This does not look nice at all! Ideally the label should be very short no matter what: "Push to <remoteName>". Maybe if there are x Push-URIS and y RefSpecs append " (x/y)". But this is equally cryptic (see PushOperationUI#createPushOperation).
Gerrit change https://git.eclipse.org/r/158119 was merged to [master]. Commit: http://git.eclipse.org/c/egit/egit.git/commit/?id=6f46e09be6e1ec6425b21c4650f6504a2a386eee
The command now indicates the name of the remote that's being pushed to, if it can. Otherwise it still says "Push to Upstream", and the behavior in that case seems to be the subject of bug 431872. (In reply to Alexander Nittka from comment #10) > If a very long label is shown, the width stays the same for the next context > menu which only has very short entries. This does not look nice at all! Yes, that's a known bug on Windows. See bug 315619 (and EGit bug 540778).
Maybe I'm missing something, but this patch doesn't solve the issue of having 'origin' hardcoded as name of the remote referenced as upstream. I think most of participats were asking of a fix to be able to change the remote assigned to "fetch/push to upstream" function. For me too 'origin' refers to my forked repo, and 'upstream' to the one I forked from.
> Maybe I'm missing something origin is not hardcoded. When cloning a repository you can specify the name.
Yes, I know that. But I cloned the forked copy of a repo, and called its remote 'origin', as a common convention. Now I want to setup my "Fetch from Upstream" function to the, well... upstream copy, the repo from which I forked. I created a new remote pointing to the latter and called it 'upstream'. Is it possible to make "Fetch from Upstream" pointing to 'upstream' and not to 'origin'?
> Is it possible to make "Fetch from Upstream" pointing to 'upstream' and not > to 'origin'? The menu entry does a fetch from the remote configured as upstream repository for the branch. Before the change the menu text was static (Upstream) no matter which repository was configured, so you did not see where you were fetching from. With this change the name of the remote is shown. Answering your actual question: Yes, you just have to configure your "Upstream" as the remote repository. Open the context menu for the branch, select "Configure Branch" and change the remote repository.
(In reply to Alexander Nittka from comment #16) > Answering your actual question: Yes, you just have to configure your > "Upstream" as the remote repository. Open the context menu for the branch, > select "Configure Branch" and change the remote repository. Thanks, I was looking for a global repo configuration and didn't think to check on single branch context menu. I find a little uncomfortable having to set it up for every branch, but that's not the real problem. The issue now is that configuration doesn't distinguish between push and fetch. If I set it to my 'upstream' remote, every push control (from context menu, but from Git Staging view too) will try to push to that remote, while I just want to fetch from it.
(In reply to Javier Reg from comment #17) > If I set it to my 'upstream' remote, every push control (from context menu, > but from Git Staging view too) will try to push to that remote, while I just > want to fetch from it. Just use the context menu in the Git Repositories view. Navigate to the wanted remote (Expand the "Remotes" node), select it, then Context Menu->Fetch. I use that frequently when working with repositories with several remotes (typically Github repos). My local branches have "origin" remote tracking branches (i.e., pointing to my fork). To fetch from the original repo I forked from, I create an "upstream" remote once (but don't base my branches on that one) and use the above method to fetch from the original repo.
*** Bug 363469 has been marked as a duplicate of this bug. ***
