[RFC] Add warning when git discard changes on another branch?

> I think it would be better if git can warn use if we switch to another branch
> without committing the modification. Git will warn if the modification is based
> on a commit different from where the checkout happened.
>
> For example, say I am now on branch 'master' and all files *clean*. Now if I do:
>     $ git checkout -b issue
> and make some changes to a file:
>     $ echo "modification on branch issue" >> lala.txt
> and then switch back to branch 'master':
>     $ git checkout master
> and git can see the changes:
>     $ git status
>       On branch master
>       Changes not staged for commit:
>         (use "git add <file>..." to update what will be committed)
>         (use "git checkout -- <file>..." to discard changes in working directory)
>       
>       	modified:   lala.txt
>       
>       no changes added to commit (use "git add" and/or "git commit -a")
>       
> Now, if I do "git checkout -- lala.txt", then I will lose that change on branch
> 'issue' too!!! 

> Yubin Ruan <ablacktshirt@gmail.com> writes:
> 
> > I think it would be better if git can warn use if we switch to another branch
> > without committing the modification. Git will warn if the modification is based
> > on a commit different from where the checkout happened.
> >
> > For example, say I am now on branch 'master' and all files *clean*. Now if I do:
> >     $ git checkout -b issue
> > and make some changes to a file:
> >     $ echo "modification on branch issue" >> lala.txt
> > and then switch back to branch 'master':
> >     $ git checkout master
> > and git can see the changes:
> >     $ git status
> >       On branch master
> >       Changes not staged for commit:
> >         (use "git add <file>..." to update what will be committed)
> >         (use "git checkout -- <file>..." to discard changes in working directory)
> >       
> >       	modified:   lala.txt
> >       
> >       no changes added to commit (use "git add" and/or "git commit -a")
> >       
> > Now, if I do "git checkout -- lala.txt", then I will lose that change on branch
> > 'issue' too!!! 
> 
> There may be a fundamental misunderstanding here.  In Git, changes
> you make in the working tree do *not* belong to any branch.  The
> request "git checkout -- lala.txt" you made in this step does *not*
> say "Hey, Git, these changes to lala.txt are not necessary in the
> 'master' branch".  It says "I started editing lala.txt, but it turns
> out that I do not need that change at all, anywhere, please remove
> it."

> If you meant the changes while you were on "issues" branch were not
> yet ready to be committed, but now you want to work on "master"
> branch without having to worry about these changes, "git stash" may
> be a useful tool.  Alternatively, you can just create a temporary
> commit while on "issues" branch before checking out "master" branch
> to work on something else, and when you are ready to continue
> working on the "issues" branch, check out "issues" branch and either
> (1) start with "reset HEAD^" or (2) just continue working on it and
> conclude with "commit --amend".

> 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

> 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).  

> 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. 

> 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...
> 

> 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...

> Junio C Hamano <gitster@pobox.com> writes:
> 
> > 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...
> 
> It might help if we treat this similarly to how we treat the
> "detached HEAD" state.  By default when you do "git checkout HEAD^0"
> (not "git checkout --detach HEAD"), you would get a large warning,
> which you can silence by the advice.detachedhead configuration.  In
> addition to the list of "these paths have local modifications" that
> we show as a reminder, perhaps you want to show a warning that tells
> the user that the local modifications in these paths are not
> recorded anywhere else, or somesuch, and silence it with a new
> advice.* variable?

> Yubin Ruan <ablacktshirt@gmail.com> writes:
> 
> > That would be helpful. But, frankly, if a user would be aware of that `advice.*'
> > variable, he would have enough knowledge of Git to be aware of that situation.
> > So, I think that 'M lala.txt' in transitions from branch to branch would be
> > sufficient.
> 
> Ah, you got the advice.* thing wrong.  The "advice" messages are by
> default noisy, and experts can turn them down by setting advice.* to
> "false", saying "I know Git well enough that I do not need handholding
> in this area."
> 
> So a newbie does not have to know about "advice.*".  When s/he gets
> experienced enough to get annoyed by noisy messages, s/he can tune
> it out.