All of lore.kernel.org
 help / color / mirror / Atom feed
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

      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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.