Hi,
Are files supposed to be continually tracked after commiting after deleting
them?
git status reports that files have been deleted as expected (they're not
there anymore). I commit as wanted. I do some more work, but then git status
still reports that the same files have been deleted. As such I have a
historical list of "deleted" files that I may have been working on
previously and had committed.
I have to run git rm to erase these entries, but I've no idea how that
affects my history.
Shouldn't git add/commit remember that a file has been deleted previously?
On a related note, once I do git rm on one of these files, git status
sometimes reports that these rm'd files have been renamed to a new one
instead! What's going on? :(
Shak
"Shak" [off-list ref] wrote in message
news:g2r19e$s6e$1@ger.gmane.org...
Hi,
Are files supposed to be continually tracked after commiting after
deleting them?
git status reports that files have been deleted as expected (they're not
there anymore). I commit as wanted. I do some more work, but then git
status still reports that the same files have been deleted. As such I have
a historical list of "deleted" files that I may have been working on
previously and had committed.
I have to run git rm to erase these entries, but I've no idea how that
affects my history.
Shouldn't git add/commit remember that a file has been deleted previously?
On a related note, once I do git rm on one of these files, git status
sometimes reports that these rm'd files have been renamed to a new one
instead! What's going on? :(
To be clear on the last point, git seems to be incorrectly detecting that
I've copied (sometimes to the same directory) and renamed files. What's the
difference anyway? And is there anyway to override it's overzelaous
assumptions?
Shak
"Shak" [off-list ref] wrote in message
news:g2r1sb$tut$1@ger.gmane.org...
"Shak" [off-list ref] wrote in message
news:g2r19e$s6e$1@ger.gmane.org...
quoted
Hi,
Are files supposed to be continually tracked after commiting after
deleting them?
git status reports that files have been deleted as expected (they're not
there anymore). I commit as wanted. I do some more work, but then git
status still reports that the same files have been deleted. As such I
have a historical list of "deleted" files that I may have been working on
previously and had committed.
I have to run git rm to erase these entries, but I've no idea how that
affects my history.
Shouldn't git add/commit remember that a file has been deleted
previously?
On a related note, once I do git rm on one of these files, git status
sometimes reports that these rm'd files have been renamed to a new one
instead! What's going on? :(
To be clear on the last point, git seems to be incorrectly detecting that
I've copied (sometimes to the same directory) and renamed files. What's
the difference anyway? And is there anyway to override it's overzelaous
assumptions?
To rudely reply to my own message a second time, it seems I have to
explicitly run "git add -u" to actually commit deletions before committing.
I don't notice any changes in "git status" so there doesn't seem a way of
knowing that it's required.
I've also noticed that renames aren't detected until you commit a delete.
This is all becoming very counter-intuitive :(
Shak
From: Pieter de Bie <hidden> Date: 2016-06-15 22:44:44
On 12 jun 2008, at 14:01, Shak wrote:
This is all becoming very counter-intuitive :(
It seems you are missing the concept of the index. Let's look
at an example:
Vienna:a pieter$ git init
Initialized empty Git repository in /Users/pieter/a/.git/
Vienna:a pieter$ touch a b
Vienna:a pieter$ git commit -m "Initial commit"
Created initial commit f0a0fe2: Initial commit
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 a
create mode 100644 b
Vienna:a pieter$ rm a
Vienna:a pieter$ git status
# On branch master
# Changed but not updated:
# (use "git add/rm <file>..." to update what will be committed)
#
# deleted: a
#
This is the point where you were. Look at the line "Changed but no
updated"
and also the hint "(use "git add/rm <file>..." to update what will be
committed)".
Vienna:a pieter$ echo "text" >b && git add b && git commit -m "change"
Created commit e28a131: change
1 files changed, 1 insertions(+), 0 deletions(-)
You changed b and commited it, but did nothing with a. now when you do
git status:
Vienna:a pieter$ git status
# On branch master
# Changed but not updated:
# (use "git add/rm <file>..." to update what will be committed)
#
# deleted: a
#
no changes added to commit (use "git add" and/or "git commit -a")
It'll still show it as deleted. And still gives you a hint on what to do
(TWICE!). So, let's do that:
Vienna:a pieter$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# deleted: a
#
Notice that it now says "Changes to be committed"! If you commit now,
your
status will be clean:
Vienna:a pieter$ git commit -m "deleted a"
Created commit 02bbe7b: deleted a
0 files changed, 0 insertions(+), 0 deletions(-)
delete mode 100644 a
Vienna:a pieter$ git status
# On branch master
nothing to commit (working directory clean)
In short, the point is that you never commited the deletions! Your
whole history
until now will still show those deleted files. You can commit the
actually deletions
now, as you should have done before (either by using "git rm <file>",
"git add -u",
"git commit -a" or "git commit <file>".
- Pieter
"Pieter de Bie" [off-list ref] wrote in message
news:477B22F6-9F24-4CBE-98EE-58EF697E6320@ai.rug.nl...
In short, the point is that you never commited the deletions! Your whole
history
until now will still show those deleted files. You can commit the
actually deletions
now, as you should have done before (either by using "git rm <file>",
"git add -u",
"git commit -a" or "git commit <file>".
Thanks for the quick workflow. To fill in a gap in my OP, I was using "git
add ." to add new files before a "commit". Since I (perhaps incorrectly)
took "commit -a" as a short cut for these two commands, I assumed that "git
add ." would also commit deletions.
So sticking to my previous workflow (I need to do this since "commit -a" as
I understand it doesn't commit new files, and I often forget that I've added
:)), it seems I should do the following to keep the working directory in
sync with the repository:
git add .
git add -u
git commit
Is that right? Should the two add commands be called in that order or
doesn't it matter?
I ask because I'm still concerned with how git assumed I had renamed files
after I had "git rm"d them. As far as I could tell they were not very alike.
Perhaps adding the new files before removing the old ones would stop this
behavior?
Shak
From: Alex Riesen <hidden> Date: 2016-06-15 22:44:44
Shak, Thu, Jun 12, 2008 14:23:53 +0200:
"Pieter de Bie" [off-list ref] wrote in message
news:477B22F6-9F24-4CBE-98EE-58EF697E6320@ai.rug.nl...
quoted
In short, the point is that you never commited the deletions! Your
whole history
until now will still show those deleted files. You can commit the
actually deletions
now, as you should have done before (either by using "git rm <file>",
"git add -u",
"git commit -a" or "git commit <file>".
Thanks for the quick workflow. To fill in a gap in my OP, I was using
"git add ." to add new files before a "commit". Since I (perhaps
incorrectly) took "commit -a" as a short cut for these two commands, I
assumed that "git add ." would also commit deletions.
"git add" just adds, unless told to update (with -u). And "git commit -a"
just updates and commits. Updates include forgetting removed files,
but not adding new (thats on purpose: too many of us have random files
in our working trees).
So sticking to my previous workflow (I need to do this since "commit -a"
as I understand it doesn't commit new files, and I often forget that I've
added :)), it seems I should do the following to keep the working
directory in sync with the repository:
git add .
this will add everthing which isn't ignored (in .git/info/exclude or
.gitignore's). Are you sure you want that generated and backup files
in your history? Maybe your workflow could use "git add new-file-1
new-file-2..."?
git add -u
git commit
Is that right? Should the two add commands be called in that order or
doesn't it matter?
either "git add . && git commit -a" or "git add . && git add -u && git
commit".
I ask because I'm still concerned with how git assumed I had renamed
files after I had "git rm"d them. As far as I could tell they were not
very alike. Perhaps adding the new files before removing the old ones
would stop this behavior?
Why should you care? They seem to be similar enough, but besides the
listing, there is nothing which relates them in the git structures.
Happens often for small files.
Just adopt "git commit -a" and ignore that.