ansaurus

Question

Answer 1

+1 A:

You could:

cd 1.0.0.1
git init .
git add -A
git commit -m "1.0.0.1"
git tag 1.0.0.1 -m "1.0.0.1"

(using an unsigned annotated tag)

And then (not necessary the smartest way, but it should work)

(*) remove everything except .git directory
copy the next version content in the current directory
git add -A (see this SO question on git add -A)
commit and tag
repeat (*)

VonC 2010-04-16 13:46:23

Thanks for the quick reply. I will try this shortly and report back. I normally use 'git add .' and never 'git add -u'. Most cheat sheets encourage this. I also noticed that you do not use '-a' for 'git commit'- any correlations here?

XO 2010-04-16 16:44:32

@user309779: `git add -A` is a shortcut for `git add .` and `git add -u`. `git commit -a` won't commit new files not yet added. Plus I like to check (`git status`) what is about to be committed first (that sometimes prompts me to update my `.gitignore` and to `git rm --cached` some extra files that shouldn't be committed in the first place)

VonC 2010-04-16 17:00:01

Makes sense. So what's the danger in exclusively using 'git add .' and never using -A or -u? Just concerned because, in all my research, this is the 1st I'm hearing of it. Thanks again.

XO 2010-04-16 18:19:46

I just referenced another SO response submitted by you, makes sense now (http://stackoverflow.com/questions/2190409/whats-the-difference-between-git-add-and-git-add-u).

XO 2010-04-16 18:26:51

There does appear to be a correlation. Correct me if I am wrong. Folks using (git add .) use (git commit -a). Folks using (git add -A) drop the -a from (git commit). || (git add .), add all files from the current directory that either changed, are new or not ignored. (git add -u), stage files being tracked. This includes removing files from the index that were deleted from working tree. (git commit -a), automatically stage files that have been modified and deleted, but new files you have not told git about are not affected.

XO 2010-04-16 19:07:48

@user309779: that is the general idea, but again I prefer keeping the adding (add or remove from the staging area) separate from the committing ;)

VonC 2010-04-16 19:13:25

Duh. I just had a moment of clarity and was rushing back to modify my post- hehe. 24 hours of straight programming - lol. I'll try the version stuff after I get some much needed rest.

XO 2010-04-16 19:24:04

Is it a bad idea to use git versions between remove and local?

XO 2010-04-17 19:18:23

@XO: different versions of Git between Git installed in the local machine and Git in the remote machine, you mean? Not necessarily. If the versions are recent enough (1.6.x, 1.7x), it shouldn't matter.

VonC 2010-04-17 19:27:45

Yes. 1.5.6.4 (no git add -A), 1.7.0.3 (yes git add -A). Upgrading now. Thanks. Also, in example, do you mean git init (without .). It didn't fly with version 1.5.x.

XO 2010-04-17 19:39:06

@XO: I confirm: `git init` with a path did not before late 1.6.x or 1.7

VonC 2010-04-17 20:14:23

I've merged to source trees together per your instructions (1.0.0.1, 1.0.0.4). All seems to have gone well. I have a bit more reading to do to get comfortable with all of this - thanks.

XO 2010-04-18 12:08:18

@XO: you're welcome. From there, you can go on with your development, or branch from any of those tag for some maintenance and bug fixes for a specific release.

VonC 2010-04-18 12:11:10

ansaurus

tags:

views:

answers:

merging 3 source versioned trees into 1

related questions