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

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

[Conor Rafferty]

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








-- 

 
<http://www.altmore.co.uk/xNON_SITE/SignatureFiles/AltmoreIT_signature_l
ogo.JPG> 

Conor Rafferty BSc (Hons.)
REGIONAL MANAGER
Altmore IT Recruitment
Townsend Enterprise Park
28 Townsend Street
Belfast BT13 2ES 

T: +44 (0)28 9032 8400
E: conor.rafferty@altmore.co.uk
W: www.altmore.co.uk <http://www.altmore.co.uk/>  

LinkedIn: http://www.linkedin.com/in/conorrafferty

________________________________

This electronic message contains information from Altmore IT Recruitment
which may be privileged or confidential. The information is intended to
be for the use of the individual(s) or entity named above. If you are
not the intended recipient be aware that any disclosure, copying
distribution or use of the contents of this information is prohibited.
If you have received this electronic message in error, please notify us
by telephone or email (to the numbers or address above) immediately.

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

[René Scharfe]

Conor Rafferty schrieb:
> 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 ?

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é

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

[Zorba]

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

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 ?) 

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

[Junio C Hamano]

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

> 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 ?) 

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

> $ <import code>
> $ git init
> $ git commit

which is a good way to make an initial import.

> $ git tag versionA <commitID>
> $ hack hack hack
> ...

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.

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

[Zorba]

> Drop "rm *.*".  Instead, probably what you want is
>
>> $ <import code>
>> $ git init
>> $ git commit
>
> which is a good way to make an initial import.
>
>> $ git tag versionA <commitID>
>> $ hack hack hack
>> ...
>
> 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 

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

[Daniel Barkalow]

On Fri, 26 Dec 2008, Conor Rafferty wrote:

> We want to use git to
> a) archive old versions of our project that have till now had no SCM
> applied

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*

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

[Zorba]

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...
> On Fri, 26 Dec 2008, Conor Rafferty wrote:
>
>> We want to use git to
>> a) archive old versions of our project that have till now had no SCM
>> applied
>
> 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*