is there an easier way to do this ?

is there an easier way to do this ?

[Zorba]

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 !

Re: is there an easier way to do this ?

[Jacob Helwig]

On Mon, Dec 29, 2008 at 19:37, Zorba <cr@altmore.co.uk> wrote:
> 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
>

git help add

Look at -A

Re: is there an easier way to do this ?

[Zorba]

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 !
>
>
> 

Re: is there an easier way to do this ?

[Jacob Helwig]

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.

Re: is there an easier way to do this ?

[Jeff Whiteside]

$ git add .
$ git commit -a

no, you don't need git commit -a, just git commit

so,

$ git add .
$ git commit -m "my msg"

why?

git add . will add everything to the index, including a notation about
removing deleted files (i hope you know what the index is, if not,
google 'index' or 'staging area', this will clear everything up).

git commit will take everything from the index and commit (not the
working tree of files) it to the actual repository.

git commit -a will take every file that is already tracked in git, but
NOT newly added files, and add/update the content in the index, then
commit it.

so, git commit -a is equivalent to

git add -u
git commit



On Mon, Dec 29, 2008 at 8:00 PM, Jacob Helwig <jacob.helwig@gmail.com> wrote:
> 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.
> --
> 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
>

Re: is there an easier way to do this ?

[Jakub Narebski]

"Zorba" <cr@altmore.co.uk> writes:

> 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 [...]

Check out contrib/fast-import/import-tars.perl

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: is there an easier way to do this ?

[Zorba]

thanks Jakub, but I don't mind copying the versions in by hand and running 
the git commits on them sequentially.

I only have 5 max historical versions to archive..

"Jakub Narebski" <jnareb@gmail.com> wrote in message 
news:m3k59hb6xr.fsf@localhost.localdomain...
> "Zorba" <cr@altmore.co.uk> writes:
>
>> 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 [...]
>
> Check out contrib/fast-import/import-tars.perl
>
> -- 
> Jakub Narebski
> Poland
> ShadeHawk on #git 

Re: is there an easier way to do this ?

[Johannes Schindelin]

Hi,

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

On Tue, 30 Dec 2008, Zorba wrote:

> > "Zorba" <cr@altmore.co.uk> writes:
> >
> >> 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 [...]
> >
> > Check out contrib/fast-import/import-tars.perl
>
> thanks Jakub, but I don't mind copying the versions in by hand and 
> running the git commits on them sequentially.

It's not only about how much work you are doing.  It's also about 
preserving as much metadata as possible.

Ciao,
Dscho