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

Quoted 17 lines · Yubin Ruan

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)

Quoted 6 lines

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

Quoted 11 lines · Yubin Ruan

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

Quoted 6 lines

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

Quoted 8 lines · Junio C Hamano

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?

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.

Quoted 4 lines · Yubin Ruan

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.