GNOME Bugzilla – Bug 532673
Unstash changes and return to previous branch
Last modified: 2009-04-24 14:18:50 UTC
When using git-svn the update currently stage leaves the working copy in a bit of an odd state. It should return to the previous branch and pop the stash after rebasing the master branch. Other information: Patch attached
Created attachment 110740 [details] [review] Reverts to previous branch and unstashes changes
Comment on attachment 110740 [details] [review] Reverts to previous branch and unstashes changes >diff --git a/jhbuild/versioncontrol/git.py b/jhbuild/versioncontrol/git.py >index 77d168e..0e67807 100644 >--- a/jhbuild/versioncontrol/git.py >+++ b/jhbuild/versioncontrol/git.py >@@ -287,6 +287,8 @@ class GitSvnBranch(GitBranch): > > cwd = self.get_checkoutdir() > >+ branch = get_output(['git', 'name-rev', 'HEAD'], cwd=cwd)[5:-1] >+ > # stash uncommitted changes on the current branch > cmd = ['git', 'stash', 'save', 'jhbuild-build'] > buildscript.execute(cmd, 'git stash', cwd=cwd) >@@ -297,6 +299,14 @@ class GitSvnBranch(GitBranch): > cmd = ['git-svn', 'rebase'] > buildscript.execute(cmd, 'git-svn rebase', cwd=cwd) > >+ #return to previous branch >+ cmd = ['git', 'checkout', branch] >+ buildscript.execute(cmd, 'git checkout', cwd=cwd) >+ >+ #unstash any changes >+ cmd = ['git', 'stash', 'pop', 'jhbuild-build'] >+ buildscript.execute(cmd, 'git stash pop', cwd=cwd) >+ > try: > #is known to fail on some versions > cmd = ['git-svn', 'show-ignore', '>>', '.git/info/exclude']
Apologies patch in attachment is bad - Comment #2 is the correct patch.
Oops, the patch doesn't quite work as it is since you can only stash pop if you actually stashed something so we need to add a check for whether the stash save actually created a stash.
(In reply to comment #4) > Oops, the patch doesn't quite work as it is since you can only stash pop if you > actually stashed something so we need to add a check for whether the stash save > actually created a stash. > The other problem I see is that git-stash "pop" will probably break more often than without. I introduced git stash to _clean_ the local repository, not to rebase the dirty uncommitted changes. :) We might want to add an option somewhere, but as a more-than-1 year user, I prefer to have just a "stash save", because I developp on 3/4 projects that are in my skip list. What do you think?
Well I think we should at least switch back to the branch that the user was previously on and not blindly assume that master is the branch that should be used. The only reason that using master currently works is because the current implementation doesn't include proper support for dealing with tags and branches. I thought that the git stash was there to allow you to cleanly switch to the master branch (it would otherwise fail if there are local changes). I would argue that an update should attempt to leave a users working copy invariant as much as possible c.f. after a subversion update your local changes are still there, along with conflicts if the changes don't cleanly apply. I just think that not popping the stash is confusing to new users who aren't used to using all of git's functionality; I agree stash is useful, but I could see a new user getting confused as to where their changes have gone after running jhbuild.
Dealing with tags and branches means changing the jhbuild moduleset, most probably, which is not going to happen just for git-svn, unfortunately. Or we need to convince F. Peters, and update _all_ the modules (a daunting task) Jhbuild is a _build_ system, used to _build_ certain versions of GNOME. Doing developpement is usually better handled manually (-> the skip list of modules I work on, which have all history and branches/tags) The git stash was introduced because git rebase failed with unclean repository, when the module itself (not developers) leave the local repo with local changes - it's the soft version of git reset --hard, which was here before (or may be is still here?). Well, I have to agree that I adapted the git-svn/cvsimport support to my own workflow. If we have a better solution that every user agree (which means practically you and me ;), then I'll change my habit ;). Using git-svn with jhbuild was not meant to be for a "new user", but if we can go there, then it's a + :)
(In reply to comment #7) > Dealing with tags and branches means changing the jhbuild moduleset, most > probably, which is not going to happen just for git-svn, unfortunately. Or we > need to convince F. Peters, and update _all_ the modules (a daunting task) > When I said deal with tags and branches I meant if you had an existing full checkout using git-svn and the moduleset then the updates should occur on the correct branch and not assume the master branch is the one that needs to be updated as it currently does i.e. it should use an appropriate branch tracking the correct remote. > Jhbuild is a _build_ system, used to _build_ certain versions of GNOME. Doing > developpement is usually better handled manually (-> the skip list of modules I > work on, which have all history and branches/tags) > Ok, being new to Gnome development I was under the impression that you should use jhbuild to build your local mods during development. However I still feel that there is an argument for creating a proper repo with branches/tags since although you don't currently have to develop a module, it doesn't mean that you won't have to in the future and so wouldn't it be nice if you had that module correctly cloned as a git-svn repository. I think that I'd envisaged preferring to use jhbuild for development so that I didn't need to manually track which packages need recompiling since I'm going to be doing all my work across multiple packages. > The git stash was introduced because git rebase failed with unclean repository, > when the module itself (not developers) leave the local repo with local changes > - it's the soft version of git reset --hard, which was here before (or may be > is still here?). Indeed, that's one of the intended uses for git stash being implemented in the first place. > > Well, I have to agree that I adapted the git-svn/cvsimport support to my own > workflow. If we have a better solution that every user agree (which means > practically you and me ;), then I'll change my habit ;). > Tbh I had no idea at the size of the user base that uses git-svn, but if its just you and me then it at least minimizes the > Using git-svn with jhbuild was not meant to be for a "new user", but if we can > go there, then it's a + :) Indeed, and its largely a hidden feature: I only found out about it by looking through the jhbuild code. In fact I may add some instructions for using it to http://live.gnome.org/GitForGnomeDevelopers to help increase visibility.
Marc-Andre: any conclusion on this bug report?
With the move to git, I feel like jhbuild git behaviour should stay as close as its current (svn) behaviour, and doing git stash pop would certainly help here, to avoid the "jhbuild ate my change" shouts. On the branch side, I do not know, jhbuild would do a svn switch to get back to the defined-in-moduleset branch, would it be possible for git to switch branch if the "parent" branch is different? Say I create a new-feature branch off master, then jhbuild moduleset changes and jhbuild wants the gnome-2-26 branch, as master != gnome-2-26, it switches, but if I had created the new-feature branch off gnome-2-26, it wouldn't have switched. I am not sure it is really clear :/ James, Marc-Andre, what do you think?
I also propose not to discuss the branch issue here but in bug 549704, let's cater this one to unstash.
I changed a lot of things wrt the git support, and it now calls jhbuild stash pop when necessary. commit bb0119d28d8d4823a493f43f165ee2575366bf73 Author: Frederic Peters <fpeters@0d.be> Date: Fri Apr 24 16:08:46 2009 +0200 improve git support in many ways Changes to a simpler support of branches; switch from git fetch/git rebase to git pull --rebase, only stash when there is a diff, and pop afterwards, and no longer use git rev-parse to check for branch existance. (GNOME #532673, #549704, #552476 and #564672)