fedpkg switch-branch behavior

[Jesse Keating]

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