Re: is there an easier way to do this ? [Scanned]

["Zorba" <cr@altmore.co.uk>]

(punches air with fist)
yes indeed !

sorry, I didn't follow up on the --update flag first time

$ git add -A .
$ git commit

home in a boat!

"Jacob Helwig" <jacob.helwig@gmail.com> wrote in message 
news:8c9a060812292017m600ca246pf8660630d49a7067@mail.gmail.com...
> On Mon, Dec 29, 2008 at 20:11, Conor Rafferty
> <conor.rafferty@altmore.co.uk> wrote:
>> Ah, but what about the files that have been removed from this version ?
>> - that's the whole point of doing commit -a, so I don't have to spend
>> ages doing diffs to produce a list of files to feed into git-rm
>>
>> Or have I missed another glarer ?
>>
>> -----Original Message-----
>> From: Jacob Helwig [mailto:jacob.helwig@gmail.com]
>> Sent: 30 December 2008 04:01
>> To: git@vger.kernel.org
>> Cc: Conor Rafferty
>> Subject: Re: is there an easier way to do this ? [Scanned]
>>
>> On Mon, Dec 29, 2008 at 19:51, Zorba <cr@altmore.co.uk> wrote:
>>> The manual shows you can SHOW untracked files, but not add them as
>>> part of the commit -a jig
>>>
>>> Seems a bit strange that git-add operates on both exisging and new
>>> files when used standalone, but its behaviour changes when
>>> encapsulated in commit -a...
>>>
>>> So, I thought maybe $ git commit -a, then $ git add .
>>> but then the files tracked have missed the commit boat they were meant
>>
>>> to be on, haven't they,
>>>
>>> hang on -
>>> what about
>>>
>>> $ git add .
>>> $ git commit -a
>>>
>>> I do believe I've cracked it
>>> if so, it seems a bit wasteful, 2x adds (one explicti and one embedded
>>
>>> in -a) ? shame on you linux kernel guys, i'd have expected better :-)
>>>
>>> "Zorba" <cr@altmore.co.uk> wrote in message
>>> news:gjc52u$ehc$4@ger.gmane.org...
>>>> ok, now I'm in this for real, archiving versions of our website
>>>> project (5k files approx)
>>>>
>>>> so here is the workflow:
>>>>
>>>> - copy version 1 files into GIT dir
>>>>
>>>> - open git bash
>>>>
>>>> $ git init
>>>>
>>>> $ git add .
>>>>
>>>> $ git commit -m "version1"
>>>>
>>>> all vanilla ? cool
>>>> next job = store version 2, so delete version 1 files from GIT dir,
>>>> copy in version 2
>>>> version2 has different files from 1 - which ones? Out of 5k files
>>>> could be 1% = 50 new ones, and same amount removed. Why should I
>>>> care, with such a powerful friend as git around, n'est pas?
>>>> THIS TIME we are going to be CLEVER and use "-a" flag on commit to
>>>> pick up any files that have been REMOVED (or "deleted" in git-speak)
>>>>
>>>> $ git commit -a -m "version2"
>>>>
>>>> BUT this does not pick up any new ones that have been added,
>>>>
>>>> and when we run
>>>>
>>>> $ git status > ../git_status.txt
>>>>
>>>> these are referred to as "untracked files"
>>>> only problem there are 50 ish
>>>> is there not another flag on git commit to treat any untracked file
>>>> as a new file ?
>>>> (would save me typing or creating a list out of these untracked ones
>>>> and feeding them into git add)
>>>>
>>>> I know, I realise now I should have looked up git-commit in the
>>>> manual - in case its not there, pls enlighten me !
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe git" in the
>>> body of a message to majordomo@vger.kernel.org More majordomo info at
>>> http://vger.kernel.org/majordomo-info.html
>>>
>>
>> If you do an explicit git add, then you don't need the -a on git commit,
>> since everything you want to commit will already be in the index for git
>> commit to work with.
>>
>
> See the -A flag for git add (and it's reference to --update).  -A will
> remove files that have been removed, add untracked, and update ones
> that have changed, all in one go.