git checkout no longer warning about uncommitted/untracked files!

I found some other posts that seem to indicate that this is the right place to file bug reports for git. If this is wrong, please let me know the proper method. We are using git version 1.7.3. We just noticed that git checkout no longer warns about uncommitted/untracked files and just deletes them!!! I had a developer lose a lot of work today because they were not committing regularly (which they will do now), and because I told them to perform the checkout believing that it would do as it has always done, and warn about their modified and untracked new files. I believe this is a bug. Is it fixed in a later release already? If so, which release? You guys really need to get a bug tracking system like Jira to allow the git user community to file bugs and feature requests!!!! Thanks for your help.

-- View this message in context: http://git.661346.n2.nabble.com/git-checkout-no-longer-warning-about-uncommitted-untracked-files-tp6395441p6395441.html Sent from the git mailing list archive at Nabble.com.

Am 23.05.2011 19:29, schrieb funeeldy:

I can't reproduce this behaviour based on this description alone:

	$ git --version
	git version 1.7.3
	$ uname -a
	Linux ubuntu 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:50 UTC 2011 i686 i686 i386 GNU/Linux

	$ mkdir /tmp/repo && cd /tmp/repo
	$ git init
	Initialized empty Git repository in /tmp/repo/.git/
	$ git config -l
	color.ui=auto
	user.name=René Scharfe
	user.email=rene.scharfe@lsrfire.ath.cx
	core.repositoryformatversion=0
	core.filemode=true
	core.bare=false
	core.logallrefupdates=true

	$ echo 1 >a
	$ git add a
	$ git commit -m.
	[master (root-commit) b0e60d3] .
	 1 files changed, 1 insertions(+), 0 deletions(-)
	 create mode 100644 a

	$ git branch x
	$ echo uncommitted >a
	$ echo untracked >b

	$ git checkout x
	M	a
	Switched to branch 'x'

	$ cat a
	uncommitted
	$ cat b
	untracked

Can you reconstruct what your colleague did, perhaps using his or her shell's command history file (e.g. ~/.bash_history)?

On Mon, May 23, 2011 at 10:37:17PM +0200, René Scharfe wrote:

But you're not actually switching trees here, so there is by definition no merge that needs to happen, and the changes stay in place.

And here, there is no contention over "b" since git would never need to write it at all.

A better test would be:

  git init repo && cd repo
  echo 1 >a && git add a && git commit -m a1
  echo 2 >a && git add a && git commit -m a2

  git checkout -b check-uncommitted master^
  # should fail because we would have to merge
  echo 3 >a && git checkout master

  git checkout -f master
  echo 4 >b && git add b && git commit -m b4
  git checkout -b check-untracked master^
  echo untracked >b
  # should fail because we would overwrite untracked b
  git checkout master

And indeed, testing with v1.7.3., both of my "should fail" checkouts do fail, with the following messages respectively:

  error: Your local changes to the following files would be overwritten by checkout:
        a
  Please, commit your changes or stash them before you can switch branches.
  Aborting

and

  error: The following untracked working tree files would be overwritten by checkout:
        b
  Please move or remove them before you can switch branches.
  Aborting

So I still don't know what the bug is.

-Peff

This is with version 1.7.5.2 - it just keeps the files as modified when I checkout a different branch. The bad thing about this is that if I make a change on both branches, only the last change is kept, silently. Earlier today when I tried this new version, the first checkout failed with the error message I expected, but I cannot get it to show me that again.

private/marlene_cote/test/anroot/projects/kernel main_int $ git st # On branch main_int # Changed but not updated: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: Makefile # no changes added to commit (use "git add" and/or "git commit -a") /private/marlene_cote/test/anroot/projects/kernel main_int $ git checkout main M Makefile Branch main set up to track remote branch main from origin. Switched to a new branch 'main' /private/marlene_cote/test/anroot/projects/kernel main $ git checkout main_int M Makefile Switched to branch 'main_int' /private/marlene_cote/test/anroot/projects/kernel main_int $ git checkout main M Makefile Switched to branch 'main' v/private/marlene_cote/test/anroot/projects/kernel main $ vi Makefile /private/marlene_cote/test/anroot/projects/kernel main $ git checkout main_int M Makefile Switched to branch 'main_int'

-- View this message in context: http://git.661346.n2.nabble.com/git-checkout-no-longer-warning-about-uncommitted-untracked-files-tp6395441p6396225.html Sent from the git mailing list archive at Nabble.com.

Is there any way a checkout would not warn about modified and untracked files, and then proceed to lose them all?

-- View this message in context: http://git.661346.n2.nabble.com/git-checkout-no-longer-warning-about-uncommitted-untracked-files-tp6395441p6396282.html Sent from the git mailing list archive at Nabble.com.

On Mon, May 23, 2011 at 02:17:23PM -0700, funeeldy wrote:

Git checkout -f ?

-Peff

Yes, we didn't use -f .

-------------------------- Regards, Marlene Cote Affirmed Networks 978-268-0821

->-----Original Message----- ->From: Jeff King [mailto:peff@peff.net] ->Sent: Monday, May 23, 2011 5:19 PM ->To: Marlene Cote ->Cc: git@vger.kernel.org ->Subject: Re: git checkout no longer warning about uncommitted/untracked files! -> ->On Mon, May 23, 2011 at 02:17:23PM -0700, funeeldy wrote: -> ->> Is there any way a checkout would not warn about modified and untracked ->> files, and then proceed to lose them all? -> ->Git checkout -f ? -> ->-Peff

On Mon, May 23, 2011 at 02:05:04PM -0700, funeeldy wrote:

Right. This has always been the way git works.

No, in the example below, you don't actually make a change on a branch. You make a change to your _worktree_, but that change is not associated with a branch until you actually commit (which you never do in your example).

OK, so you have a change to your Makefile...

And now you switch to another branch. Because the version of Makefile in "main" is the same as the one on "main_int", git can switch branches and preserve your worktree change (if there had been a change to Makefile in main_int, you would have seen an error, and git would have told you to commit or stash your change sfirst).

Now you're back on main_int, but again, you still have the same change in Makefile in your worktree.

And back to main, with the same change in the worktree.

And now you edit the Makefile to new content. If you are expecting the intermediate state of the Makefile to be kept, it is not. You never committed it.

And you still have the new content, because none of these checkouts is changing your Makefile at all; you are just switching other files around while the same changes to Makefile sit in the worktree.

-Peff