getting started, happy with cmd line on windows [Scanned]

We want to use git to a) archive old versions of our project that have till now had no SCM applied b) moving forward, provide robust SCM on new versions of project

Just to get familiar, I created a folder, ran

$ git init

then created a few files: ABC.txt, AC.txt, BC.txt, C.txt This mimics our real life sitch for purpose (a), files are in version A, but not in version B, which introduces new files, whick might not be in version C

$ git add *c*.txt $ git commit -m "version A"

so now ABC.txt and AC.txt are in the repo, at a commit with comment "version A"

$ git show

confirms this

$ git status

confirms that BC.txt and C.txt have not been tracked - great, as designed

I then deleted all files from the working directory, so I can pull out ONLY the ones in version A. I tried both fetch and checkout - but nothing was copied into working dir How do I do this ?

NB along the way I also tagged this first commit as "tag_versionA" also tried

$ git checkout tag_versionA which changed HEAD back to version A, but didn't create the files

Seems like I'm missing some fundamental concepts here - from other SCM's, I understood fetch or checkout would copy files into your working dir that were replicas of the versions stored in repository

Conor Rafferty schrieb:

git treats deleted files just like edited files: as having been changed in preparation for the next commit. You can get back all of the tracked files using this command:

	$ git reset --hard

It undoes _all_ changes: tracked edited files will be reverted to their in-repository state, deleted files created again. You can also check out individual files like this:

	$ git checkout ABC.txt

If you just want to get rid of untracked files, you'd use the command "git clean".

In general, if you switch your work tree from one revision to another (git checkout), git tries to minimize the I/O needed. Files that are the same in both aren't touched.

René

git treats deleted files just like edited files: as having been changed in preparation for the next commit. You can get back all of the tracked files using this command:

$ git reset --hard

It undoes _all_ changes: tracked edited files will be reverted to their in-repository state, deleted files created again. You can also check out individual files like this:

$ git checkout ABC.txt

If you just want to get rid of untracked files, you'd use the command "git clean".

In general, if you switch your work tree from one revision to another (git checkout), git tries to minimize the I/O needed. Files that are the same in both aren't touched.

Hi Rene,

Thanks for taking the time.

My workflow is such that I inherit projects that are hard to debug and I need to hack around a lot changing a lot of files to output tracking msgs just to learn the code's functionality (e,g, PHP on a webserver), but these changes I never intend to keep. After learning the code, I want to go back to a "last known good". I.e. a previous stable version and start making proper changes.

In other SCMs, there was a way to "discard" all local changes, after the hacking phase, without EVER having had to commit.

For a while it seemed like you were telling me I had to COMMIT my hacked code (against all my instincts :-), and THEN rollback ($ git reset --hard).

Now, I went back and read the manual pages for git-checkout and think I see how to do it....

$ <import code> $ git init $ git commit $ git tag versionA <commitID> $ hack hack hack ... now ready to start coding, want "last known good" $ rm *.* $ git checkout versionA .

This worked fine when versionA had only files and no dirs - but will it work ok still if versionA is a proper tree ? (more of a unix question I suppose - will "." suffice as the path ?)

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

Drop "rm *.*".  Instead, probably what you want is

which is a good way to make an initial import.

and you futzed with the codebase without any intention of committing; it is nice to be able to experiment freely.

After you are done experimenting,

$ git reset --hard versionA

if you did not make any commit, or even if you did commit while you were experimenting, if you do not want these experimental commits at all.

No need for "rm *.*" anywhere.

Hi Junio,

Yes, I had not considered the possibility of being able to reset to last commit (as manual page talked about UNDOing commits). $git reset -hard HEAD = This is great, and gives me the functionality I want, get back to the last conscious commit after hacking.

I've noticed since discovering this that the Reset function on the Win GUI will ONLY let you reset as far as but not beyond the last commit (i.e. unable to undo any commits) so I can use that too.

The other functionality I was looking for is being able to handle a changing "portfolio" of files from version to version:

e.g. version A = ABC.txt, AB.txt, AC.txt version B = ABC.txt, AB.txt version C = ABC.txt, AC.txt version D = no files

I'm sure this is a common scenario, for ppl starting out with git as they load up versions that till now have been sitting in file systems.

By using git-add and git-rm (or git-commit -a) I was able to have my add/remove files to the index in "staging" and in the end the versions in the repo match up to real life example. Then I can --hard reset back to any of these, and ONLY got the files that were in that version.

Its a shame though that git-commit -a only removes files from the index, and doesn't add files to the index, otherwise creating new versions is just a case of importing the files needed for eacch version and cranking..

$ git commit -a

repeatedly.

But thanks to all who helped me on this one, and who knows maybe this post will help some other pilgrim following after me :-) Season's geetings, CR

On Fri, 26 Dec 2008, Conor Rafferty wrote:

There's actually an importer for this; if you can put all of the old versions into tar files in the same format and list them in order, you can use "import-tars.perl", which is in contrib/fast-import in the git source tree. Of course, using that won't teach you anything about the tools, but it might be the best way to get the real import done with the least chance of mistakes.

	-Daniel
*This .sig left intentionally blank*

Thanks Daniel, I'm not a tar man anyhow, so that would be one more thing to learn. So I'll pass, but someone else into unix will find this useful (maybe me, a few mths down the track)

Believe it or not, I had budgeted half a day for getting git installed, learned, and all the versions safely stowed away. That was on Xmas eve (24th Dec.)

I've been on this every day since - gawd, its becoming an Odyssey.

SCM is a support to my software development, which is a support to my business (a user business, not technology based) and iin a normal year (not like this current one) would be <10% of our effort. I can sense the beauty of git, but A WEEK ! to get close to making the first LIVE COMMIT.

I'm going to assert that a large number of possible users will not be interested, or how shall I put it better, they'l be very interested in git, but that's where it will stay. The blogosphere is littered with the burnt bodies of those who have tried to ride this dragon. Gawd its tempting to give up and install CVS or something, the only thing keeping me going is that I HATE quitting !

What is it about this stuff ? I am not unintelligent but struggling with this.

It seems like to do something simple you have to understand EVERYTHING - its not like other systems with a clear set of "basic", "intermediate" and "advanced" commands that are fairly standalone.

everything in git seems so interleaved - its like relativity, or nuclear 
physics !
I'm sure git nirvana is coming sometiime for me,
gawd please may it be in this lifetime!
 :-)

"Daniel Barkalow" <barkalow@iabervon.org> wrote in message news:alpine.LNX.1.00.0812281326300.19665@iabervon.org...