Bugzilla – Full Text Bug Listing
| Summary: | push should not push up all local branches to upstream | ||
|---|---|---|---|
| Product: | [Technology] EGit | Reporter: | Thomas Watson <tjwatson> |
| Component: | Core | Assignee: | Project Inbox <egit.core-inbox> |
| Status: | NEW --- | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | achilles.sabine, curtis.windatt.public, daniel_megert, dj.houghton, info, jens.baumgart, john.arthorne, jwross, matthias.sohn, pwebster, remy.suen, robin, stefan.lay |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Mac OS X - Carbon (unsup.) | ||
| Whiteboard: | |||
|
Description
Thomas Watson
One correction. "git push" with no parameters will push all branches to upstream that exist upstream, but I don't think it creates new branches upstream that only exist locally. Root cause being bug 351314? Which version of EGit are you using? I suppose that commit c6dd679 of 2011-07-06 has fixed this and the error does not occur in the nightly build, now the currently checked out branch is pushed. (In reply to comment #2) > Root cause being bug 351314? No, I don't think so. This refspec which led to the described behavior that all local branches are created on the remote was created in EGit and passed to the PushCommand (in class PushOperationUI). Bug 351314 describes the behavior that the *currently checked out* branch is pushed when no refspec is given. (In reply to comment #3) > Which version of EGit are you using? I suppose that commit c6dd679 of > 2011-07-06 has fixed this and the error does not occur in the nightly build, > now the currently checked out branch is pushed. I am using EGit version 1.0.0.201106090707-r (In reply to comment #4) > (In reply to comment #3) > > Which version of EGit are you using? I suppose that commit c6dd679 of > > 2011-07-06 has fixed this and the error does not occur in the nightly build, > > now the currently checked out branch is pushed. > > I am using EGit version 1.0.0.201106090707-r this fix was submitted after this release, could you retry with current nightly build version from http://download.eclipse.org/egit/updates-nightly ? (In reply to comment #0) > I just > performed my first push to upstream with eGit and to my surprise it pushed up > all my local branches to dev.eclipse.org and even created new branches that did > not exist up stream. Tom, when you pushed, did you remember what you did? Did you go 'Team > Push to Upstream'? Or did you go 'Team > Remote... > Push' and went through a wizard? (In reply to comment #6) > (In reply to comment #0) > > I just > > performed my first push to upstream with eGit and to my surprise it pushed up > > all my local branches to dev.eclipse.org and even created new branches that did > > not exist up stream. > > Tom, when you pushed, did you remember what you did? Did you go 'Team > Push to > Upstream'? Or did you go 'Team > Remote... > Push' and went through a wizard? IIRC I used 'Team > Push to Upstream'. I don't see the 'Team > Remote...' option anywhere. (In reply to comment #7) > IIRC I used 'Team > Push to Upstream'. I don't see the 'Team > Remote...' > option anywhere. That should actually be 'Team > Remote > Push...' but I guess you don't see that either. You might be seeing a bug with Eclipse 4, if you restart it should show up again. (In reply to comment #8) > (In reply to comment #7) > > IIRC I used 'Team > Push to Upstream'. I don't see the 'Team > Remote...' > > option anywhere. > > That should actually be 'Team > Remote > Push...' but I guess you don't see > that either. You might be seeing a bug with Eclipse 4, if you restart it should > show up again. restart made it show up again. But looking at that wizard, nothing looks familiar. I am almost certain I used 'Team > Push to Upstream'. But this is all confusing to me. How am I to know the difference between the two? Why are there two ways to push in the UI. Remy, is there an Eclipse 4 bug open about the disappearing menu item? (In reply to comment #9) > Remy, is there an Eclipse 4 bug open about the disappearing menu item? I just opened bug 354831 and have already CC'd you on it. I'm using EGit 1.0 (Eclipse 3.7) and trip over the same problem as Thomas Watson (see my question in the forum http://www.eclipse.org/forums/index.php/m/716515/#msg_716515). Steps to reproduce: Clone a repository e.g. from GitHub. Create a local branch (it seems to make no difference whether it is based on a local or a remote branch) and choose Push to upstream (the one with no wizard) to push it. EGit pushes all local branches, even those that are not available remote, to the remote repository. This is different from the command line, as Thomas pointed out. The only way to prevent this is to configure push to upstream to only push e.g. local/master to remote/master. As Matthias Sohn mentioned in my forum post, the spec (http://kernel.org/pub/software/scm/git/docs/git-push.html) contains the following: "The special refspec : (or +: to allow non-fast-forward updates) directs git to push "matching" branches: [xxx]for every branch that exists on the local side, the remote side is updated if a branch of the same name already exists on the remote side.[xxx] This is the default operation mode if no explicit refspec is found (that is neither on the command line nor in any Push line of the corresponding remotes file---see below)." The important part is highlighted with [xxx]. In my eyes, EGit does not implement this correctly. (In reply to comment #11) > EGit pushes all local > branches, even those that are not available remote, to the remote repository. > This is different from the command line, as Thomas pointed out. This behavior has changed in the meantime. To prevent the users from pushing all local branches accidentally now for the time being only the currently checked out branch is pushed if no refspec is given (like "git push <repository> HEAD"). (Yes, we have to fix the now wrong message in the Configure Push dialog.) > The only way to prevent this is to configure push to upstream to only push e.g. > local/master to remote/master. Yes, or HEAD/refs/heads/master if you do not want to merge into master locally each time you push. > As Matthias Sohn mentioned in my forum post, the spec > (http://kernel.org/pub/software/scm/git/docs/git-push.html) contains the > following: > > "The special refspec : (or +: to allow non-fast-forward updates) directs git to > push "matching" branches: [xxx]for every branch that exists on the local side, > the remote side is updated if a branch of the same name already exists on the > remote side.[xxx] This is the default operation mode if no explicit refspec is > found (that is neither on the command line nor in any Push line of the > corresponding remotes file---see below)." > > The important part is highlighted with [xxx]. In my eyes, EGit does not > implement this correctly. You are absolutely right and you may wonder why EGit does not just implement that behavior. The problem is that the underlying library JGit does not yet support it. There is a comment of Shawn Pearce (main author of JGit) about that: "We don't have a way to do the default update-only-if-existing-on-remote-side logic inside of JGit. The Transport code doesn't have a mode to do this matching, and the matching needs to happen only after the advertisement has been received from the remote side." (http://egit.eclipse.org/r/#patch,unified,3808,1,/COMMIT_MSG). So someone has to dive into the JGit Transport code to fix that. See also the posting of Shawn on the JGit mailing list: http://dev.eclipse.org/mhonarc/lists/jgit-dev/msg01227.html (In reply to comment #12) > You are absolutely right and you may wonder why EGit does not just implement > that behavior. The problem is that the underlying library JGit does not yet > support it. See bug 353405 for that. |