From: Yubin Ruan <ablacktshirt@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [RFC] Add warning when git discard changes on another branch?
Date: Mon, 8 May 2017 20:01:32 +0800 [thread overview]
Message-ID: <20170508120129.GA3540@HP> (raw)
In-Reply-To: <xmqqvapc9fsg.fsf@gitster.mtv.corp.google.com>
On Mon, May 08, 2017 at 12:41:03PM +0900, Junio C Hamano wrote:
> Yubin Ruan <ablacktshirt@gmail.com> writes:
>
> > I understand this. I just suggest that git add some warning in case some users
> > are not aware of this, as it does when , on branch 'issue', changes to 'lala.txt'
> > are based on a commit different from where the checkout happened, i.e.
> >
> > on branch 'master'
> > |
> > | <-- git checkout -b issue
> > \
> > \ <-- modification to git happened on a commit different from where
> > the checkout happened
> >
> > in this situation, git would warn us something like this:
> >
> > error: Your local changes to the following files would be overwritten by checkout:
> > lala.txt
> > Please, commit your changes or stash them before you can switch branches.
> > Aborting
>
> That does not have much to do with "are commits the same?". If
> 'master' and 'issue' branches are pointing at different commit, as
> long as they record the same content at the path "lala.txt", you can
> check out between these branches freely, as we can do so without
> having to resort to merging the edit the user made to the working
> tree to the different contents of "lala.txt".
>
> There already is an indication that you have local modification in
> the working tree when we check out another branch (you would have
> seen "M lala.txt" when you did a "checkout" of another branch while
> you have local changes to the path).
That is convincing :)
> Because it is a quite commonly used feature that you can checkout
> another branch and carry local changes with you, making it error out
> like we do when the branches record different contents for the
> locally changed paths when we do not have to would be a bad change
> that hurts productivity of users who do use Git correctly, which
> would mean that we need to make it an opt-in feature.
I agree.
> But to help "some users are not aware of this" situation, an opt-in
> "feature" would not help all that much. The same number of lines in
> the documentation to tell end-users how to toggle on such a "safety"
> feature can be spent to teach them that their local changes in the
> working tree do *not* belong to any particular branch, and as soon
> as it is understood, the user would be OK.
>
> So...
>
---
Yubin
prev parent reply other threads:[~2017-05-08 4:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-07 23:35 [RFC] Add warning when git discard changes on another branch? Yubin Ruan
2017-05-08 3:05 ` Junio C Hamano
2017-05-08 11:18 ` Yubin Ruan
2017-05-08 3:41 ` Junio C Hamano
2017-05-08 4:19 ` Junio C Hamano
2017-05-08 12:27 ` Yubin Ruan
2017-05-08 6:07 ` Junio C Hamano
2017-05-08 14:10 ` Yubin Ruan
2017-05-08 12:01 ` Yubin Ruan [this message]
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=20170508120129.GA3540@HP \
--to=ablacktshirt@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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).