Thanks all for the great info! The scenarios you describe, Junio,
make perfect sense. In fact, that's pretty much the way I think when
I'm coding and decided to branch or not to branch (that is the
question). Along the lines of those scenarios (maybe this should be a
separate post), are there any guidelines or best practices on when/if
to sync your branches with master (hope that's not a stupid question,
I'm still learning)?
-Joe
On Mar 21, 2008, at 12:42 AM, Junio C Hamano wrote:
Jeff King <peff@xxxxxxxx> writes:
On Fri, Mar 21, 2008 at 12:06:47AM -0400, Shawn O. Pearce wrote:
Use `git checkout -m` to switch the branch anyway. However, if
there is a merge conflict while you are trying to carry the changes
to the other branch you may be faced with a merge conflict you are
not prepared to resolve, or simply cannot resolve in a reasonable
period of time.
Ah, for some reason I didn't think of '-m' in the advice I gave (I
guess
I have just never used it). It is almost certainly simpler than
using a
'stash' at this point (but I do think stashing _beforehand_ still has
advantages).
The thing is, that -m is really to mollify people who are _too_
accustomed
to CVS/SVN update behaviour. Over there, "scm update" does not give
you
any choice other than having to merge.
With git, stashing or creating Park commits are very cheap operation
and
unless you are reasonably sure that your local changes do not conflict
with the branch you are switching to, there is no strong reason to
prefer
"checkout -m".
Switching branches with dirty state can have three scenarios:
(1) you are getting interrupted and your current local changes do not
belong to what you are going to commit after switching (e.g. "the
boss says fix that right away").
recommendation: stash, or Park commit
(2) you have started working but realized what you are working on
belongs
to a new topic.
recommendation: checkout -b
(3) you have started working but realized what you are working on
belongs
to an existing topic.
recommendation: checkout -m
In case (1), if the change is small, trivial or independent from
what you
are switching branches to work on, you can "git checkout" (if the
change
is about an unrelated thing, hopefully there won't be any overlap at
the
file level) or "git checkout -m" (again, if the change is about an
unrelated thing, the merge hopefully would be trivial) to switch
branches,
perform the unrelated change and commit only that unrelated change,
and
"git checkout" (or "git checkout -m") to come back to where you
started.
But if you had to use "-m" when switching branches, that means the
change
you need to commit in the switched branch may have to include some
changes
you will do to that modified file, and you would need per-hunk
commit with
"git add -i" to exclude existing changes. In such a case, stashing
the
local changes away before branch switching would be much easier
workflow.
In case (2), the solution is always "checkout -b". There is no other
choice.
In case (3), the solution is always "checkout -m". Stashing,
switching
and then unstashing will give the same conflicts as "checkout -m"
would
give you, and the change you were working on has to be done on that
switched to branch, so there is no escaping from conflict resolution,
unless you are willing to redo your change on the breanch you
switched to
again.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
