* checkout and rm
@ 2007-09-07 2:59 Jeff Jenkins
2007-09-07 22:00 ` Junio C Hamano
0 siblings, 1 reply; 2+ messages in thread
From: Jeff Jenkins @ 2007-09-07 2:59 UTC (permalink / raw)
To: git
I couldn't find a thread in the archive about this. Here's the
abbreviated scenario:
$ git add bar.c
$ git-rm foo.c
rm 'foo.c'
$ git-status
# On branch FOO
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: bar.c
# deleted: foo.c
#
$ git-checkout master
M bar.c
Switched to branch "master"
$ git-status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: bar.c
#
When I change branches:
- the modified files in the index/working directory stay there
(that's fine)
- the *removed* files are re-added to the working directory when the
branch changes
- the remove entries aren't in the index anymore
There was no warning about any the lost changes, and if the intent
was to commit these changes to master because you were in FOO by
accident, then only some would be committed if you weren't paying
close attention. If working directory/index changes are going to be
kept when a branch switch is done, then the remove changes should be
propagated as well.
Ideally there would be a config setting which would stop checkouts if
the working directory or index were dirty (and a flag on checkout
which overrode the setting). With stash in 1.5.3 the only reason I
can think of to allow working directory changes to propagate is gone
(though i haven't tested how stash works with rm'd files). At the
very least, there should be a warning and a prompt if some of the
changes are going to vanish by a user action
-Jeff Jenkins
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: checkout and rm
2007-09-07 2:59 checkout and rm Jeff Jenkins
@ 2007-09-07 22:00 ` Junio C Hamano
0 siblings, 0 replies; 2+ messages in thread
From: Junio C Hamano @ 2007-09-07 22:00 UTC (permalink / raw)
To: Jeff Jenkins; +Cc: git
Jeff Jenkins <Jeff@ShopWiki.com> writes:
> With stash in 1.5.3 the only reason I
> can think of to allow working directory changes to propagate is gone
This reasoning is utterly wrong.
We often begin exploring a solution while on one branch (perhaps
'master'), starting with small changes in the work tree, and
then realize that it needs to be worked on in a separate branch:
$ edit some work tree files
$ git branch new-topic
$ git checkout new-topic
Or maybe we would realize that the fix we started to work on
while on 'master' also applies to 'maint', and do the checkout
without creating a new branch:
$ edit some work tree files
$ git checkout maint
In either case, it is a _good_ thing that you can take your
local changes with you when you switch branches, without extra
stash/unstash sequence, and I do not think this is going to
change.
About the "lost remove", I think it is related to the fact that
we try to be usable in a sparsely checked out work tree, and
during a two-way merge (aka "switching branches") we consider a
missing file equivalent to an unmodified file and this might be
a bug in the logic to implement it there. I haven't checked
this conjecture and won't have time now to do the digging myself
(you're welcome to do the digging yourself in the meantime). It
may turn out to be a trivial change, but I dunno at this moment.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2007-09-07 22:00 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-09-07 2:59 checkout and rm Jeff Jenkins
2007-09-07 22:00 ` Junio C Hamano
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).