Community
Participate
Working Groups
To push a certain tag I currently need to open the push dialog (with 'Push...' from the context menu of the repository) and manually specify 'refs/tags/myTag:refs/tags/myTag' as push ref specification. I would find it more convenient if I could simply choose 'Push...' in the context menu on a tag (in the Repositories View on the tags shown under <repository> -> 'Tags'). Then a very simply push dialog could be shown, which just has 3 prefilled fields: 1. the push URL (prefilled with the push URL from the configured push specification, maybe drop-down list if several push URLs are configured) 2. the source ref (prefilled and fixed with the tag ref of the tag on which the push is done, e.g. 'refs/tags/myTag') 3. destination ref (prefilled with the tag ref of the tag on which the push is done, e.g. 'refs/tags/myTag') With this it would be pretty easy to push a tag: find the tag -> 'Push...' -> confirm the dialog with 'OK' :-) Maybe something similar could be even done for branches!?
i have proposed a fix for this: http://egit.eclipse.org/r/#/c/4999/ it probably needs some more love to make it great, bu still it already works
After a few months of pushing to Eclipse git repos I'm already guilty of producing bogus pushes of two opposite kinds: - push a local branch which was supposed to remain private and - push the content of a local featurebranch into origin/master instead of origin/featurebranch I believe a nice solution in this bug could significantly help me and others to avoid such embarrassing mistakes in the future! (In reply to comment #0) > Maybe something similar could be even done for branches!? Are branches already covered by the proposed fix? What exactly will be the workflow? I'd assume after selecting the tag/branch to be pushed, it just needs max 2 more options: - push to master or the equivalent branch/tag on origin? - should a dry-run be performed? For branches it would be interesting, how the dialog would connect to storing refspecs in the remote configuration. Maybe, the dialog could indeed simply distinguish private vs. public branches? Private ones would go to master, when pushed, public ones to their corresponding branch on the remote. And then this choice could be persisted using a matching refspec. Makes sense? I think starting from a selected tag/branch will greatly improve usability. If the next step is simple and easy, too, a lot fewer mistakes will be made, I hope.
(In reply to comment #2) > What exactly will be the workflow? in the current proposal, just right-click a branch/tag in repo view or a commit in history view, and select Push... you're presented with a wizard, which allows to choose the remote to push to, and after that just a very (very very) simple wizard page that allows you to enter the target ref name to push to. Nothing is persisted for now. > I'd assume after selecting the tag/branch to be pushed, it just needs max 2 > more options: > - push to master or the equivalent branch/tag on origin? > - should a dry-run be performed? just at first, the target remote is selected, and dry-run is not there (yet?) > For branches it would be interesting, how the dialog would connect to storing > refspecs in the remote configuration. Maybe, the dialog could indeed simply > distinguish private vs. public branches? Private ones would go to master, when > pushed, public ones to their corresponding branch on the remote. And then this > choice could be persisted using a matching refspec. Makes sense? hm. i don't think that such kind of super-duper intelligent logic is good. it may fit some cases, but may not in other cases. how would you, for example, determine whether a branch is private? just because it was never pushed? That would already be easy, if the dialog would offer the possibility to persist the spec. just have no spec to start with, and persist those you push, and you're there. > > I think starting from a selected tag/branch will greatly improve usability. If > the next step is simple and easy, too, a lot fewer mistakes will be made, I > hope. true :) thats why i wanted this to happen.
(In reply to comment #3) > just at first, the target remote is selected, and dry-run is not there (yet?) I'm very much in favor of dry-run, it's another great tool to avoid wrong pushes... > how would you, for example, determine whether a branch is private? I was thinking that for some users it might be appropriate to just have an explicit selection in this dialog (and maybe other dialogs, too): The current branch is: (o) private ( ) public and the target refspec would be pre-set from that selection: private : push to master public : push to branch If refspecs are stored, the dialog could remember the private/public selection from those refspecs. This could perhaps enable Joe-the-programmer to safely use branches without even understanding refspecs? But I won't insist on this :) Emphasis is on: simple to understand and simple to use. How this is achieved is secondary for me.
Markus: please confirm the following contribution statements which are required to be answered for IP approval: 1. Did you author 100% of the content you are contributing? 2. Do you have the rights to contribute the content to Eclipse? 3. Is the content being contributed under the EPL?
(In reply to comment #5) > Markus: please confirm the following contribution statements which are required > to be answered for IP approval: > > 1. Did you author 100% of the content you are contributing? yes > 2. Do you have the rights to contribute the content to Eclipse? yes > 3. Is the content being contributed under the EPL? yes :)
merged as 82b60e5aff1bd4ee9e8413806ab491d4da4302fa
Compile error in SimplePushSpecPage.java if compiled against proper JRE (1.5): The method isEmpty() is undefined for the type String
> Compile error in SimplePushSpecPage.java if compiled against proper JRE Tomasz fixed the compile error, but added a useless null check.
(In reply to comment #9) > Tomasz (...) added a useless null check. Right, I admit, I haven't read the javadoc for Text#getText(). If I had I would have known it doesn't return null.
Fixed the remaining issue with https://git.eclipse.org/r/5643
I verified the behavior in 2.0.0.201204191915 and it's not simple to use 1. The remote ref is not pre-filled with my tag. 2. The remote ref content assist shows branches instead of tags which I think is wrong. See attached screenshot. I would expect that I can simply select the tag, invoke the action and press 'Finish' (or 'Next' + 'Finish').
Created attachment 214375 [details] Picture of current wizard
(In reply to comment #12) > I verified the behavior in 2.0.0.201204191915 and it's not simple to use > > 1. The remote ref is not pre-filled with my tag. > 2. The remote ref content assist shows branches instead of tags which I think > is wrong. > > See attached screenshot. > > I would expect that I can simply select the tag, invoke the action and press > 'Finish' (or 'Next' + 'Finish'). I finally had a chance to try this feature and I agree with Dani that it is not as easy as hoped. While the wizard has only few elements, filling in the text field with only wrong content assist requires more attention / understanding what you are doing than I'd hoped.
*** Bug 358103 has been marked as a duplicate of this bug. ***
See also the following question: http://stackoverflow.com/questions/18396182/egit-push-tag-broken IMO the wizard should only allow selecting a remote and then show a confirmation page, that's it. I plan to have a stab at implementing this soon.
(In reply to comment #16) > IMO the wizard should only allow selecting a remote and then show a > confirmation page, that's it. I plan to have a stab at implementing this > soon. Hurray! :)
Pushed changes to implement this: https://git.eclipse.org/r/18723 (remove some duplication) https://git.eclipse.org/r/18724 ("Push Tags" wizard)
(In reply to Robin Stocker from comment #18) > Pushed changes to implement this: > > https://git.eclipse.org/r/18723 (remove some duplication) merged as dd15ed98779b602d49c71cc3f13a7fb7989d68c6
(In reply to Robin Stocker from comment #18) > Pushed changes to implement this: > https://git.eclipse.org/r/18724 ("Push Tags" wizard) merged as 4db03b082f5cb7884ae4710e763cef8f5845e1fb
Created attachment 237886 [details] screenshot of new "Push Tags" wizard For reference, here's how the wizard looks with the above change for EGit 3.2.
