GNOME Bugzilla – Bug 552476
git fetch/pull could be made configurable
Last modified: 2009-04-24 14:18:55 UTC
Old behavior (git pull) was what one expects and doesn't force committing to test a trivial change. Perhaps using fetch or pull could be made configurable ? Other information:
Riccardo: what kind of configurability would you want? Marc-Andre: any input on this?
I guess being able to switch behavior by setting the relative variable in jhbuildrc would be quite handy
My question was more about the different types of git workflows people use; JHBuild matches the way Marc-Andre works; there may be others; I am no git user and certainly not the kind who would come with a novel workflow. So a detailed description of the workflow/commands you'd want is what I expect here. For example Subversion has: - checkout: svn checkout uri - update: svn update (svn switch in some situations) Bzr has: - checkout: bzr branch uri - update: bzr pull Git: - checkout: git clone uri - update: git fetch, git stash save, git checkout, git rebase ... What would your checkout/update commands be?
For updating a local tree I almost always use `git pull'. (git pull calls indeed git fetch but also git merge subsequently; yeah, the name of the bug report is unfortunate, sorry :/) I guess the GitBranch class should follow the behaviour of bzr and svn's ones where one isn't forced to commit to have changes preserved for build time. ps. I see that git.py always calls git rebase with a branch name in the args thus making git checkout redundant.
I was pointed here from bug 549704. In our workflow, we want to be able to clone a branch from a remote git repository and always track that remote branch. There should be no local changes, and any local changes can be overwritten (or saved away with git-stash). This is meant for integration with buildbot. The assumption is that the local copy exactly matches the remote branch, so that all merges should apply cleanly. I believe the raw git commands that I'd want are: git clone git clone file:///path/to/foorepo foorepo git checkout --track -b mybranch origin/mybranch ... kickoff a build, then ... git pull ... kickoff a build, then ... etc. There may be better/other ways to achieve this workflow in git.
In general, a bare 'git pull' is never right when you have a centralized repo. The bare git pull is for merging somebody else's tree into yours and creates a merge commit. 'git pull --rebase', or a manual 'git fetch' 'git rebase' sequence is more appropriate. And this is pretty much what jhbuild does now. There are a few things that I don't like about the current jhbuild git setup: - It does a git stash save to save current uncommitted changes, but doesn't git stash pop when done. Which makes it looks like your changes got lost and requires manual intervention. I don't really know what the thinking is behind this. Obviously, the git stash pop could leave conflicts but that seems like the expected behavior in the situation. - The rebase procedure doen't work very well in the face of outstanding merges from other branches. It would probably be good to detect such issues and refuse to do anything and let the user figure out. If you want to completely wipe out local changes always - maybe you are worried about make rules that modify checked in files and cause conflict, then: git fetch origin git reset --hard origin/master But I think a blow-away-all-changes option would be a global cross-vc option for jhbuild and not a git-specific option. The current method should work as well as a 'svn up' for this use case. (Well, better, because of the git stash issue discussed above, but I'd like to see that fixed...)
(In reply to comment #6) > In general, a bare 'git pull' is never right when you have a centralized repo. > The bare git pull is for merging somebody else's tree into yours and creates a > merge commit. 'git pull --rebase', or a manual 'git fetch' 'git rebase' > sequence is more appropriate. And this is pretty much what jhbuild does now. > Ah! finally someone that agree with my workflow :) I practically updated jhbuild git.py to do what it is currently doing, without really asking anyone, in r1678 (in 2007-10, git rebase was not available widely at that time), and r2116. I guess nowadays people understand better why git rebase in jhbuild make more sense than just pull. But apparently, some people have a different workflow. > There are a few things that I don't like about the current jhbuild git setup: > > - It does a git stash save to save current uncommitted changes, but doesn't > git stash pop when done. Which makes it looks like your changes > got lost and requires manual intervention. I don't really know what > the thinking is behind this. Obviously, the git stash pop could > leave conflicts but that seems like the expected behavior in the > situation. > Good point. I did the stash, but not the pop. The idea was to make sure that you can do automated build of a serie. Quite often a package mess up it's own files. And you really don't want to check the generated changes all them time when you build. That was the idea. Do best effort to get a successful build without intervention. Although this is not documented and customizable. I wonder if using .git/config variable we could tweak that behavior. What do you think? > - The rebase procedure doen't work very well in the face of outstanding > merges from other branches. It would probably be good to detect such > issues and refuse to do anything and let the user figure out. > > If you want to completely wipe out local changes always - maybe you are worried > about make rules that modify checked in files and cause conflict, then: > > git fetch origin > git reset --hard origin/master > > But I think a blow-away-all-changes option would be a global cross-vc option > for jhbuild and not a git-specific option. The current method should work as > well as a 'svn up' for this use case. (Well, better, because of the git stash > issue discussed above, but I'd like to see that fixed...) > yeah, a global option to force the force behaviour would be good too, if I understand you correctly.
(In reply to comment #7) ebase' > > There are a few things that I don't like about the current jhbuild git setup: > > > > - It does a git stash save to save current uncommitted changes, but doesn't > > git stash pop when done. Which makes it looks like your changes > > got lost and requires manual intervention. I don't really know what > > the thinking is behind this. Obviously, the git stash pop could > > leave conflicts but that seems like the expected behavior in the > > situation. > > > > Good point. I did the stash, but not the pop. The idea was to make sure that > you can do automated build of a serie. Quite often a package mess up it's own > files. And you really don't want to check the generated changes all them time > when you build. > > That was the idea. Do best effort to get a successful build without > intervention. Although this is not documented and customizable. > I wonder if using .git/config variable we could tweak that behavior. > What do you think? I don't think configuring what jhbuild does with git-config makes sense ...config should be done though the jhbuildrc. My basic feeling about the default behavior is that one of the large points of jhbuild is to make the transition between "try to build gnome" and "hack on gnome" really thin and easy. And if someone's first experience with hacking on gnome is "I updated and my changes vanished!!!", that's bad. The most common reason for a module to "mess up its own files" is gtk-doc, and jhbuild defaults to building with --disable-gtk-doc.
(In reply to comment #8) > I don't think configuring what jhbuild does with git-config makes sense > ...config should be done though the jhbuildrc. I was thinking quickly about this option, because it's only valid for git so far (is there stash for other systems?). Also, you have plenty of projects named git* (all of them?) that update the .git/config to put user preference. Rename jhbuild to git-jhbuild, and here you go :) Aren't you also using .git/config for git-bz? What if your tool would be named just bz? To me it looks like a very small difference. But yes, I agree on the principle that we should try to keep jhbuild configuration in .jhbuildrc. > My basic feeling about the default behavior is that one of the large points of > jhbuild is to make the transition between "try to build gnome" and "hack on > gnome" really thin and easy. And if someone's first experience with hacking on > gnome is "I updated and my changes vanished!!!", that's bad. > I don't have the same feeling. When I use jhbuild, it's to build the all set, with the dependencies. My development is indepedant, and I skip the modules I actively work on in jhbuild. > The most common reason for a module to "mess up its own files" is gtk-doc, and > jhbuild defaults to building with --disable-gtk-doc. > Well, that's not a good idea, because gtk-doc are really useful when you want to develop for GNOME, it lower the barriers to have the full documentation build with jhbuild, imho :) Too bad it is so slow to build though.
Ok, I'm not exactly sure which side I'm landing on but here's my take. jhbuild is primarily a developer tool. It has a secondary use as an automated build / tinderbox tool. I think it is reasonable to assume that if a developer makes a change in a module that the change is intentional in some way. Setting aside vcs specific issues for a moment, there are two types of changes that I make: patches that need testing, preparations for a release. For the first case (patches that need testing), I really want to say something like: "build me a GNOME with these patches (already applied on disk)". In jhbuild terms the way one does this is to apply patches to the trunk/current-branch and run jhbuild build -a. For the second case (a release), I am saying that create a tarball (and test it) using the changes I've made in this directory. In jhbuild terms this is done using: jhbuild buildone -ad --distcheck I can't see how stash is at all helpful for these cases. However, I think it is pretty easy to show that it interferes. For the automated build scenario (eg. tinderbox) I can see how it would be useful to forcefully override local changes to avoid any conflicts etc. However, why would you want to retain the changes in this case either? Seems like rather than stash you'd want to git reset hard and make maintainerclean or similar. But this should be a jhbuildrc option or something. Bigger picture, I'd like to see all of this go away and be replaced with a new bug tracker, patch reviewer / IDE, build system, and virtual machines for testing. Workflow would be something like: Patch testing: * review issue * review patch * tweak patch * build GNOME with patch (and prerequisite patches) * test GNOME in VM * approve patch * close bug Release * Update files for release from web * review changes * build GNOME with release * test GNOME in VM * mark build as official and tested * Save changes (with comment) * label change as a release (OK nevermind this bluesky stuff)
So we're converging with bug 549704 and bug 532673, what now; last comment in bug 549704 is a concrete proposal by Owen, I think it can start as the basis for the default behaviour, and then we could have a new option for the fetch/stash behaviour.
I changed a lot of things wrt the git support, and it should address comments raised in this bug report; in any case if some git command fails it will always offer the possibility to start a shell to fix the situation. 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)