On 1/13/11 8:39 AM, John Dennis wrote: > I recently got slightly burned by an unexpected behavior with > switch-branch. Apparently after switching branches fedpkg does not do a > pull, I'm not sure if this is right or wrong, I can see arguments on > both sides. Let me give an example: > > foo (master)$ fedpkg switch-branch f14 > foo (f14)$ > > You can see the files changed as would be expected. But the changed > files are not current with f14, they are the version from the last time > I was in the f14 branch. That's contrary to my expectation, I would have > expected after switching to f14 I would see the current state of f14. To > get the current state you have to do a pull after the switch. > > I can see a (pedantic) argument which says preserving the branch state > as last "visited" is correct. But on the other hand I'm not sure that > matches most people's work habits and expectations. The only real > argument I can see for "reverting" to a prior revision when switching > branches is if one had modified files associated with that revision in > the working tree, but you can't switch branches in this scenario so I > don't think it applies. > > I guess I have two goals here: > > 1) Alert folks to what might be unexpected behavior > 2) Resolve if this really is the desired behavior > > Thanks, > > John > The way it works is by design, as it emulates the way that git works (in fact it is just calling git in the background for this). Often people are doing work on multiple branches at the same time, and may have commits on that branch that have not been pushed. Blindly doing a pull could corrupt that work or introduce unwanted merge commits. I didn't feel comfortable trying to "guess" here. There is also two stages of unknown status. There is the case that when we switch to the branch, your last used state is behind or ahead the local index (that is the cached metadata the repo has about the state of each branch upstream). There is also the case that your branch is either behind or ahead of /upstream/ changes which have not yet been fetched and cached locally. A pull would go all the way out to upstream and fetch new metadata, which may either be not desired, or perhaps impossible if working in an offline state. At most, we could warn about your status compared to the local index, a simple "git status" would show that. We cannot warn about your stats compared to upstream without fetching new data. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
