(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
