git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Cc: git@vger.kernel.org, "J.V." <jvsrvcs@gmail.com>
Subject: Re: Git: Unexpected behaviour?
Date: Mon, 14 Nov 2011 12:55:35 -0800	[thread overview]
Message-ID: <7vr51aifug.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <CAOeW2eEUbvd0eJHjNfbvi9QnDiUO=mFA9rrKsjv8Yu0_QiPgSw@mail.gmail.com> (Martin von Zweigbergk's message of "Mon, 14 Nov 2011 09:20:37 -0800")

Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> writes:

> Either you want the modifications to stay on the branch, or you want
> them to carry over to the branch you are checking out. In the former
> case, you would want Git to fail if there are modifications (that you
> might have forgotten you made). In the latter case, you would want
> "git checkout -m". The current behavior is somewhere in between. It is
> not clear to me if there is a use case where the current behavior is
> better (from the user's point of view) than either failing or
> "checkout -m".

Current behaviour is deliberately made safe because "checkout -m" may end
up forcing you to resolve a 3-way conflict you may not be prepared to do
correctly at your first attempt. Stopping and refusing to check out the
other branch gives you the choice to create a temporary stash-away commit
either on a current branch, or a temporary branch you create with "git
checkout -b temp && git commit" before switching to the target branch to
attempt to port the change over with "git cherry-pick @{-1}", which you
_can_ redo if you screw up conflict resolution and want to start over.
If you are confident that your local changes are trivial that you can
reproduce it even if you screw up your conflict resolution attempt, then
you can choose to run "checkout -m". If we made it the default, you will
lose this safety.

On the other hand, if you do *not* want to carry over the change when
checking out a different branch, you can easily stash-away the changes.

  reply	other threads:[~2011-11-14 20:55 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-11 20:55 Git: Unexpected behaviour? Jvsrvcs
2011-11-11 21:03 ` Carlos Martín Nieto
     [not found] ` <CAPZPVFb-VbTfkuyg4KtTsaWiNvd37GHeH7crPtqv1fKRbwuyfQ@mail.gmail.com>
2011-11-11 21:04   ` Eugene Sajine
2011-11-11 21:09 ` Jvsrvcs
2011-11-11 21:14   ` Taylor Hedberg
2011-11-11 21:25   ` Gelonida N
2011-11-11 21:31 ` Chris Packham
2011-11-12  0:24   ` J.V.
2011-11-12  8:25     ` Chris Packham
2011-11-12 19:37     ` Junio C Hamano
2011-11-14 17:20       ` Martin von Zweigbergk
2011-11-14 20:55         ` Junio C Hamano [this message]
2011-11-14 21:33         ` Jakub Narebski
2011-11-12  8:32 ` Alexey Shumkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vr51aifug.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=jvsrvcs@gmail.com \
    --cc=martin.von.zweigbergk@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).