you should reply to the original thread, so that you don't create a new one. makes it almost impossible to find what you're referencing. also, don't bother with git-rm. a simple rm is the same thing. (committing will notice that this file is gone) On Mon, Dec 29, 2008 at 8:29 PM, Zorba <cr@xxxxxxxxxxxxx> wrote: > (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@xxxxxxxxx> wrote in message > news:8c9a060812292017m600ca246pf8660630d49a7067@xxxxxxxxxxxxxxxxx >> On Mon, Dec 29, 2008 at 20:11, Conor Rafferty >> <conor.rafferty@xxxxxxxxxxxxx> 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@xxxxxxxxx] >>> Sent: 30 December 2008 04:01 >>> To: git@xxxxxxxxxxxxxxx >>> Cc: Conor Rafferty >>> Subject: Re: is there an easier way to do this ? [Scanned] >>> >>> On Mon, Dec 29, 2008 at 19:51, Zorba <cr@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> wrote in message >>>> news:gjc52u$ehc$4@xxxxxxxxxxxxxxxx >>>>> 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@xxxxxxxxxxxxxxx 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. > > > > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html