git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alex Riesen <raa.lkml@gmail.com>
To: Shak <sshaikh@hotmail.com>
Cc: git@vger.kernel.org
Subject: Re: Deleting files
Date: Thu, 12 Jun 2008 22:44:19 +0200	[thread overview]
Message-ID: <20080612204419.GA22787@steel.home> (raw)
In-Reply-To: <g2r4ha$74i$1@ger.gmane.org>

Shak, Thu, Jun 12, 2008 14:23:53 +0200:
> "Pieter de Bie" <pdebie@ai.rug.nl> 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.

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

      reply	other threads:[~2008-06-12 20:45 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-12 11:28 Deleting files Shak
2008-06-12 11:38 ` Shak
2008-06-12 12:01   ` Shak
2008-06-12 12:11     ` Pieter de Bie
2008-06-12 12:23       ` Shak
2008-06-12 20:44         ` Alex Riesen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080612204419.GA22787@steel.home \
    --to=raa.lkml@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=sshaikh@hotmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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 NNTP newsgroup(s).