RE: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]

RE: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]

[Conor Rafferty]

 

-----Original Message-----
wtf is wrong with

git checkout <something>

??

** It doesn't reliably put the files that were in that revision into the
working directory - a fairly major flaw, for what I'm using SCM for (and
80% of the market IMHO)

if you must have

git checkout <something> <paths>

then instead use

git checkout <something> <paths>
git clean

** hmm, might try this - obviously as per Daniels post there is some
undefined interaction happenign with the index, to screw up the working
directory. I presume clean flushes the index?

but you will lose other files that aren't part of the repo but are still
in the project's dir (i.e. untracked files).

** don't care, I'll be removing them from working dir anyhow before
doing a rollback

On Tue, Dec 30, 2008 at 4:15 PM, Daniel Barkalow <barkalow@iabervon.org>
wrote:
> On Tue, 30 Dec 2008, Conor Rafferty wrote:
>
>> I don't understand, sorry. I thought I'd already removed all files 
>> from the local tree, in the $ rm *.* move just above the checkout
>
> That removes them from the filesystem, but they're still in the index.

> And "git checkout <something> ." first gets everything that *is* in 
> "." in <something> into the index, and then gets everything from "." 
> in the index into the filesystem.
>
> I suppose it is questionable as to whether it ought to copy paths that

> aren't in versionA from the index into the filesystem.
>
> To see this in a bit more detail, do:
>
> $ rm *.*
> $ git status
> (notice that the deletes are in the "won't be committed" section)
>
> Now, "git checkout <path>" will discard any changes in the "won't be 
> committed" section for that path. Maybe "git checkout versionA <path>"
> should only discard changes that are in the "won't be committed" 
> section for filenames that match that path and are in versionA (or are
> *different* in versionA and not removed?), but I think it's an area 
> where, if you're expecting any particular behavior out of that 
> command, you're likely to be surprised in some way in some situation.
>
>        -Daniel
> *This .sig left intentionally blank*
> --
> 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: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]

[Jeff Whiteside]

sir, i believe you're not reading what is typed.

> wtf is wrong with
>
> git checkout <something>
>
> ??
>
> ** It doesn't reliably put the files that were in that revision into the
> working directory - a fairly major flaw, for what I'm using SCM for (and
> 80% of the market IMHO)

yes it does.  your example uses "git checkout versionB .", which is
NOT "git checkout <something>"
we are suggesting you do "git checkout versionB" which is different
(HINT: there is NO dot), and which i'm 99% positive will work.

if you still disagree, then i'm sure mercurial will be sufficient for
your needs, and all your dcvs book-lernin' over christmas will be
transferrable.

good luck with whatever option you choose.

Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]

[Boyd Stephen Smith Jr.]

[-- Attachment #1: Type: text/plain, Size: 1065 bytes --]

On Tuesday 2008 December 30 20:27:26 Conor Rafferty wrote:
> -----Original Message-----
> wtf is wrong with
>
> git checkout <something>
>
> ??
>
> ** It doesn't reliably put the files that were in that revision into the
> working directory - a fairly major flaw, for what I'm using SCM for (and
> 80% of the market IMHO)

And you would be wrong, IMHO.  Many people have untracked files or directories 
in their working directory ('cause they are working there) that they don't 
want deleted willy-nilly.  Build files, modifications that should be on a 
different branch, etc.  There's another thread active on the list complaining 
that git removes too much from the working tree.

Most users of SCMs do make active modifications to the files in the SCM.  It's 
not a system only for archiving static projects.
-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss@iguanasuicide.net                     ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.net/                      \_/     

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

RE: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]

[Daniel Barkalow]

On Wed, 31 Dec 2008, Conor Rafferty wrote:

> -----Original Message-----
> wtf is wrong with
> 
> git checkout <something>
> 
> ??
> 
> ** It doesn't reliably put the files that were in that revision into the
> working directory - a fairly major flaw, for what I'm using SCM for (and
> 80% of the market IMHO)

It certainly does for me; I rely on it pretty much constantly. Can you 
give a sequence of commands (ideally the whole sequence from the "git 
init") that leads to a difference?

The only case I know of where there will be files left over is if you 
switch from a situation where you have an untracked file (e.g., you create 
C.txt but don't add it to anything) to another situation where the file 
still isn't tracked, it won't remove it. But, of course, you wouldn't 
really want git to remove your uncommitted work in general, since it's 
generally irreplaceable. It'll only be lacking files if it fails to switch 
(if, for instance, you had uncommitted changes that conflict with the 
changes that it would do), and it will give an error message in that case.

> if you must have
> 
> git checkout <something> <paths>
> 
> then instead use
> 
> git checkout <something> <paths>
> git clean
> 
> ** hmm, might try this - obviously as per Daniels post there is some
> undefined interaction happenign with the index, to screw up the working
> directory. I presume clean flushes the index?

git clean wouldn't remove those files, because they're supposed to be 
there at that point.

In the sequence:

...
$ git tag versionD
$ git checkout versionA .

This means: "Update the index with the files in versionA, and working 
directory from the index"

So now you're working on a commit based versionD (because you didn't 
switch branches), and your work thus far, which is marked as ready for 
your next commit, is to recover the removed files ABC.txt and AC.txt (from 
versionA).

$ rm *.*

This removes those files again, but only in your working directory. Your 
index still says that your next commit will recover them.

$ git checkout versionB .

This recovers ABC.txt and BC.txt (from versionB). Your index has ABC.txt, 
BC.txt (from versionB), and AC.txt (from versionA), marked as going into 
the next commit. It also puts all of these in your working directory (when 
you might expect it to only put ABC.txt and BC.txt there).

So (a) you're still working on the commit after versionD, rather than 
navagting history at all; and (b) you've recovered files from two 
different commits.

Now:

$ git clean

will remove any files that you happen to have around, other than the one 
you're confused about and trying to get rid of.

	-Daniel
*This .sig left intentionally blank*

RE: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]

[Daniel Barkalow]

On Tue, 30 Dec 2008, Daniel Barkalow wrote:

> On Wed, 31 Dec 2008, Conor Rafferty wrote:
> 
> > -----Original Message-----
> > wtf is wrong with
> > 
> > git checkout <something>
> > 
> > ??
> > 
> > ** It doesn't reliably put the files that were in that revision into the
> > working directory - a fairly major flaw, for what I'm using SCM for (and
> > 80% of the market IMHO)
> 
> It certainly does for me; I rely on it pretty much constantly. Can you 
> give a sequence of commands (ideally the whole sequence from the "git 
> init") that leads to a difference?

Actually, I know what you must be doing:

$ git tag versionD
$ git checkout versionA
(versionA in the working directory)
$ rm *.*
(versionA with ABC.txt and AC.txt deleted)
$ git checkout versionB
(versionB with ABC.txt and AC.txt deleted)

If you've made any changes (including deleting files), "git checkout" (no 
pathes) will preserve them. On the other hand, it will remove files that 
are in the commit you're leaving and not in the commit you're going to. So 
just don't remove the working directory files and you should be all set.

In order to get them back if you have removed them, you can do:

$ git checkout .

This will discard all of the changes you've made only to the working 
directory; i.e., it'll recover the deleted files. You should also try "git 
status" whenever anything's mysterious, because it will tell you what's 
going on.

	-Daniel
*This .sig left intentionally blank*

Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]

[Zorba]

Ok, now I'm following you, cos I just "broke" checkout again by deleting 
files from working dirs before running it.

git-checkout takes into account the state of the working tree in the commit 
it is run FROM, as well as the commit it is checking out.

It relies on the working tree being in synch with the commit it is run from.
If I delete files, I screw around with this initial state.
Files that git-checkout is relying on to be there are not copied in by it, 
so if I've deleted (or modified) those files, hard luck.

I remember s/o saying git minimizes file I/O, and this whats happening here.

It puts a big demand on the user, to keep their index & working dir in synch 
with whats in the commit.

Ah,

$ git checkout .

will restore the state of the working dir to be in synch with the CURRENT 
commit, so it will be safe to checkout other branches

BINGO !!
what I need to do is run the sequence

$ git checkout .                    // tidy up current commit
$ git checkout <version>     // roll back

n'est pas ?


"Daniel Barkalow" <barkalow@iabervon.org> wrote in message 
news:alpine.LNX.1.00.0812302236190.19665@iabervon.org...
> On Tue, 30 Dec 2008, Daniel Barkalow wrote:
>
>> On Wed, 31 Dec 2008, Conor Rafferty wrote:
>>
>> > -----Original Message-----
>> > wtf is wrong with
>> >
>> > git checkout <something>
>> >
>> > ??
>> >
>> > ** It doesn't reliably put the files that were in that revision into 
>> > the
>> > working directory - a fairly major flaw, for what I'm using SCM for 
>> > (and
>> > 80% of the market IMHO)
>>
>> It certainly does for me; I rely on it pretty much constantly. Can you
>> give a sequence of commands (ideally the whole sequence from the "git
>> init") that leads to a difference?
>
> Actually, I know what you must be doing:
>
> $ git tag versionD
> $ git checkout versionA
> (versionA in the working directory)
> $ rm *.*
> (versionA with ABC.txt and AC.txt deleted)
> $ git checkout versionB
> (versionB with ABC.txt and AC.txt deleted)
>
> If you've made any changes (including deleting files), "git checkout" (no
> pathes) will preserve them. On the other hand, it will remove files that
> are in the commit you're leaving and not in the commit you're going to. So
> just don't remove the working directory files and you should be all set.
>
> In order to get them back if you have removed them, you can do:
>
> $ git checkout .
>
> This will discard all of the changes you've made only to the working
> directory; i.e., it'll recover the deleted files. You should also try "git
> status" whenever anything's mysterious, because it will tell you what's
> going on.
>
> -Daniel
> *This .sig left intentionally blank* 

Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]

[Sitaram Chamarty]

On 2008-12-31, Zorba <cr@altmore.co.uk> wrote:
> It puts a big demand on the user, to keep their index & working dir in synch 
> with whats in the commit.

or they could just use "git checkout -f tag_to_goto" I
suppose...

Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]

[Daniel Barkalow]

On Wed, 31 Dec 2008, Zorba wrote:

> Ok, now I'm following you, cos I just "broke" checkout again by deleting 
> files from working dirs before running it.
> 
> git-checkout takes into account the state of the working tree in the commit 
> it is run FROM, as well as the commit it is checking out.
> 
> It relies on the working tree being in synch with the commit it is run from.
> If I delete files, I screw around with this initial state.
> Files that git-checkout is relying on to be there are not copied in by it, 
> so if I've deleted (or modified) those files, hard luck.

It's not relying on these files to be there; it's actually aware that 
they're not there. It thinks that any modifications you've made might be 
important work, and carefully preserves it.

Actually, it should be telling you the changes that it's carrying over 
with lines like:

D	ABC.txt

(which indicated that you've deleted ABC.txt, and it's keeping that 
modification)

> I remember s/o saying git minimizes file I/O, and this whats happening here.
> 
> It puts a big demand on the user, to keep their index & working dir in synch 
> with whats in the commit.

The user is hopefully not going to make a lot of random undesired changes 
in general. It's hard to get much done that way. If you have made changes, 
you can use "git checkout ." to get the versions back from the index, or 
"git checkout HEAD ." to get them back from the commit. 

> Ah,
> 
> $ git checkout .
> 
> will restore the state of the working dir to be in synch with the CURRENT 
> commit, so it will be safe to checkout other branches
> 
> BINGO !!
> what I need to do is run the sequence
> 
> $ git checkout .                    // tidy up current commit
> $ git checkout <version>     // roll back
> 
> n'est pas ?

Either that, or:

$ git checkout <version>
$ git checkout .

(it doesn't matter whether you get rid of the local modifications and 
deletions before switching, or switch first, and then get rid of any 
remaining local modifications and deletions)

You may also want:

$ git clean

To get rid of untracked files you may have around (use "git clean -x" if 
you also want to get rid of files you've told git to ignore).

Incidentally, if your goal is to give someone a copy of the state as of a 
particular version, you can use:

$ git archive --format=zip <commit> > version.zip

This doesn't involve your working directory at all, and just generates a 
zip file out of the history. I find that this means I rarely actually care 
about having a working directory that's free of random junk.

	-Daniel
*This .sig left intentionally blank*

Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]

[Sitaram Chamarty]

On 2008-12-31, Daniel Barkalow <barkalow@iabervon.org> wrote:
>> $ git checkout .                    // tidy up current commit
>> $ git checkout <version>     // roll back

> Either that, or:
>
> $ git checkout <version>
> $ git checkout .
>
> (it doesn't matter whether you get rid of the local modifications and 
> deletions before switching, or switch first, and then get rid of any 
> remaining local modifications and deletions)
>
> You may also want:
>
> $ git clean

I think "git checkout -f <version>" will do *all* of that.

Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]

[Zorba]

Ok, starting from scratch, new dir, new repo

I can now get $ git checkout <version> to work (see extract below, missed 
the first few lines due to exceeding buffer)

The difference with the instance when I found "errors" is that that time I'd 
run $ git checkout <version> .
a few times first, which as I now know, would have been making updates to 
the index all along.

I presume this is what screwed things up for the normal checkout situation, 
because when I ran $ git checkout <version> on all the versions, there were 
always less files than I expected in the working dir

Still not sure if I can trust $ git checkout <version>...

Why should

$ git checkout <version> .

screw things up for

$ git checkout <version>

?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

BC

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ cat > AC.txt
AC


conorr@KINKLADZE /w/GITPLATFORM/swproj
$ cat > C.txt
C

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ ls
ABC.txt  AC.txt  BC.txt  C.txt

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git init
Initialized empty Git repository in w:/GITPLATFORM/swproj/.git/

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git add ABC.txt AC.txt

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git commit -m "version A"
Created initial commit 8ce0d2c: version A
 2 files changed, 3 insertions(+), 0 deletions(-)
 create mode 100644 ABC.txt
 create mode 100644 AC.txt

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git tag versiona 8ce0

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git rm AC.txt
rm 'AC.txt'

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ ls
ABC.txt  BC.txt  C.txt

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git add BC.txt

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       deleted:    AC.txt
#       new file:   BC.txt
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       C.txt

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git commit -m "version B"
Created commit fad9c29: version B
 2 files changed, 1 insertions(+), 2 deletions(-)
 delete mode 100644 AC.txt
 create mode 100644 BC.txt

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git tag versionB fad9

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ ls
ABC.txt  BC.txt  C.txt

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ cat > AC.txt
AC

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ ls
ABC.txt  AC.txt  BC.txt  C.txt

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git commit -m "version C"
# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       AC.txt
#       C.txt
nothing added to commit but untracked files present (use "git add" to track)

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ // mistake - forgot to stage changes
sh.exe": //: is a directory

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git reset --hard versionB
HEAD is now at fad9c29 version B

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ ls
ABC.txt  AC.txt  BC.txt  C.txt

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git add *c*.txt

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       new file:   AC.txt
#       new file:   C.txt
#

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git commit -m "version C"
Created commit 9cf73cb: version C
 2 files changed, 2 insertions(+), 0 deletions(-)
 create mode 100644 AC.txt
 create mode 100644 C.txt

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git tag versionC 9cf7

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ ls
ABC.txt  AC.txt  BC.txt  C.txt

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git rm *.*
rm 'ABC.txt'
rm 'AC.txt'
rm 'BC.txt'
rm 'C.txt'

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ ls

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git commit -m "version D"
Created commit 8e4b5be: version D
 4 files changed, 0 insertions(+), 4 deletions(-)
 delete mode 100644 ABC.txt
 delete mode 100644 AC.txt
 delete mode 100644 BC.txt
 delete mode 100644 C.txt

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git tag versionD 8e4b

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git status
# On branch master
nothing to commit (working directory clean)

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ gitk

conorr@KINKLADZE /w/GITPLATFORM/swproj
<sionA = ABC.txt, AC.txt, version B = ABC.txt, BC.txt
sh.exe": //: is a directory

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ cat > commet.txt// gitk confirms that versionA = ABC.txt, AC.txt,
sh.exe": commet.txt//: No such file or directory

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ cat > comment.txt
gitk confirms that:
versionA = ABC.txt, AC.txt
versionB = ABC.txt, BC.txt
versionC = ABC.txt, AC.txt, BC.txt, C.txt
versionD =

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ gitk

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git show
WARNING: terminal is not fully functional
commit 8e4b5bed1faadc608fc114e62bf1859b6bbed4a0
Author: Conor Rafferty <cr@altmore.co.uk>
Date:   Wed Dec 31 11:40:45 2008 +0000

    version D

diff --git a/ABC.txt b/ABC.txt
deleted file mode 100644
index 83871a5..0000000
--- a/ABC.txt
+++ /dev/null
@@ -1 +0,0 @@
-ABC
diff --git a/AC.txt b/AC.txt
deleted file mode 100644
index 9eadfae..0000000
--- a/AC.txt
+++ /dev/null
@@ -1 +0,0 @@
-AC
diff --git a/BC.txt b/BC.txt
deleted file mode 100644
index b3ac6f5..0000000
--- a/BC.txt
+++ /dev/null
@@ -1 +0,0 @@
-BC
diff --git a/C.txt b/C.txt
deleted file mode 100644
index 06a63fe..0000000
--- a/C.txt
+++ /dev/null
@@ -1 +0,0 @@
-C
(END)
conorr@KINKLADZE /w/GITPLATFORM/swproj
$

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git checkout versionA
Note: moving to "versionA" which isn't a local branch
If you want to create a new branch from this checkout, you may do so
(now or later) by using -b with the checkout command again. Example:
  git checkout -b <new_branch_name>
HEAD is now at 8ce0d2c... version A

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ ls
ABC.txt  AC.txt  comment.txt

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git checkout versionB
Previous HEAD position was 8ce0d2c... version A
HEAD is now at fad9c29... version B

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ ls
ABC.txt  BC.txt  comment.txt

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git checkout versionC
Previous HEAD position was fad9c29... version B
HEAD is now at 9cf73cb... version C

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ ls
ABC.txt  AC.txt  BC.txt  C.txt  comment.txt

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git checkout versionD
Previous HEAD position was 9cf73cb... version C
HEAD is now at 8e4b5be... version D

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ ls
comment.txt

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ rm *.*

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ ls

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git checkout versionA
Previous HEAD position was 8e4b5be... version D
HEAD is now at 8ce0d2c... version A

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ ls
ABC.txt  AC.txt

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git checkout versionB
Previous HEAD position was 8ce0d2c... version A
HEAD is now at fad9c29... version B

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ ls
ABC.txt  BC.txt

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git checkout versionC
Previous HEAD position was fad9c29... version B
HEAD is now at 9cf73cb... version C

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ ls
ABC.txt  AC.txt  BC.txt  C.txt

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git checkout versionD
Previous HEAD position was 9cf73cb... version C
HEAD is now at 8e4b5be... version D

conorr@KINKLADZE /w/GITPLATFORM/swproj
$ ls

conorr@KINKLADZE /w/GITPLATFORM/swproj
$

"Daniel Barkalow" <barkalow@iabervon.org> wrote in message
>
>> wtf is wrong with
>>
>> git checkout <something>
>>
>> ??
>>
>> ** It doesn't reliably put the files that were in that revision into the
>> working directory - a fairly major flaw, for what I'm using SCM for (and
>> 80% of the market IMHO)
>
> It certainly does for me; I rely on it pretty much constantly. Can you
> give a sequence of commands (ideally the whole sequence from the "git
> init") that leads to a difference?

Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]

[Sitaram Chamarty]

a quick comment: you don't need to use the sha1 to create a
tag at the current HEAD.  "git tag newtag sha" can be
shortened to "git tag newtag" if the sha is for the latest
commit you did.  Like the "." thing, I'd be curious where
you picked up this habit...

On 2008-12-31, Zorba <cr@altmore.co.uk> wrote:
> Why should
>
> $ git checkout <version> .
>
> screw things up for
>
> $ git checkout <version>

These are quite different operations so yes you could say
they should have used some other name instead of overloading
two different functions on the same command.  But to be
fair, the doc is fairly clear, in the first 2 paras.

And really, if I understand all your angst and what you're
trying to do, you just have to stop using the "." and -- if
you want untracked files gone each time you switch to an
older version -- use git clean.  See below.

I have snipped your log heavily but it should still be
fairly simple to follow which piece I am referring to below:

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

> $ git rm AC.txt
> $ git add BC.txt
> $ git commit -m "version B"
> $ git tag versionB fad9

> $ cat > AC.txt
> $ ls
> ABC.txt  AC.txt  BC.txt  C.txt

> $ git reset --hard versionB
> HEAD is now at fad9c29 version B
> $ ls
> ABC.txt  AC.txt  BC.txt  C.txt

you're wondering why AC.txt is still hanging around when
resetting to a commit where that file was explicitly
deleted?

A commit represents a state, not a set of actions.

"versionB" doesn't represent a "delete of AC.txt", plus an
"add of BC.txt".  It represents a state where ABC.txt and
BC.txt exist, that's it.

So AC.txt is now just an untracked file at the point you do
the reset, as you would have seen if you did a "git status".

A reset will not touch untracked files -- hardly any
operation will touch an untracked file actually.

If you really want that functionality, use git clean after
the reset, this is the only command I know that deletes
untracked files:
        git clean -d -f
        # or first try with "-n" for a "dry-run"

[later]

> $ git checkout versionA
> $ ls
> ABC.txt  AC.txt  comment.txt

> $ git checkout versionB
> $ ls
> ABC.txt  BC.txt  comment.txt

And now you're wondering what happened to "AC.txt"?  Well
this time it's a known and tracked file for the current
state (versionA), so it is a candidate for removal/change as
dictated by the new state you're going to.

I should also mention that you have not yet tried the case
where you have local modifications to some file that is
known to both the current branch and the branch you're
switching to.  "git help checkout" and look for the word
"merge" and read up the two places it is relevant to this
context (one a description and one an example).

RE: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]

[Conor Rafferty]

And you would be wrong, IMHO.  Many people have untracked files or
directories in their working directory ('cause they are working there)
that they don't want deleted willy-nilly.  Build files, modifications
that should be on a different branch, etc.  There's another thread
active on the list complaining that git removes too much from the
working tree.

** An SCM should be able to cope with both use cases. In fact I make it
easy for the SCM by deleting EVERYTHING from the working directory,
before calling git-checkout.

Most users of SCMs do make active modifications to the files in the SCM.
It's not a system only for archiving static projects.

** Archiving static projects is not the ONLY thing I want to do with my
SCM, it just happens to be the FIRST thing.

RE: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]

[Daniel Barkalow]

On Wed, 31 Dec 2008, Conor Rafferty wrote:

> And you would be wrong, IMHO.  Many people have untracked files or
> directories in their working directory ('cause they are working there)
> that they don't want deleted willy-nilly.  Build files, modifications
> that should be on a different branch, etc.  There's another thread
> active on the list complaining that git removes too much from the
> working tree.
> 
> ** An SCM should be able to cope with both use cases. In fact I make it
> easy for the SCM by deleting EVERYTHING from the working directory,
> before calling git-checkout.

In this case, git thinks you actually meant to delete those tracked files, 
and does its best to not undelete them unless you ask it to get them back. 
Git is very careful not to lose your changes, which is very nice most of 
the time, but means that you can't make changes and expect git to lose 
them.

	-Daniel
*This .sig left intentionally blank*

RE: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]

[Conor Rafferty]

Haha, no probs

Neither does the job

I either need to figure out how the indexes get involved in the dot
version,
Or give in and create a branch - that's how you guys work mainly, so
that use case will no doubt work 
Or find something else to do the job - mercurial looks promising

-----Original Message-----
From: Jeff Whiteside [mailto:jeff.m.whiteside@gmail.com] 
Sent: 31 December 2008 02:36
To: Conor Rafferty
Cc: Daniel Barkalow; Boyd Stephen Smith Jr.; git@vger.kernel.org
Subject: Re: for newbs = little exercise / tutorial / warmup for windows
and other non-sophisticated new Git users :-) [Scanned]

sir, i believe you're not reading what is typed.

> wtf is wrong with
>
> git checkout <something>
>
> ??
>
> ** It doesn't reliably put the files that were in that revision into 
> the working directory - a fairly major flaw, for what I'm using SCM 
> for (and 80% of the market IMHO)

yes it does.  your example uses "git checkout versionB .", which is NOT
"git checkout <something>"
we are suggesting you do "git checkout versionB" which is different
(HINT: there is NO dot), and which i'm 99% positive will work.

if you still disagree, then i'm sure mercurial will be sufficient for
your needs, and all your dcvs book-lernin' over christmas will be
transferrable.

good luck with whatever option you choose.

RE: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]

[Conor Rafferty]

MERCURIAL:

Update
hg update [-C] [-d DATE] [[-r] REV] 

Update the repository's working directory (the "working copy") to the
specified revision of the repository or to the tip revision of the
current (named) branch if no revision is specified.  

> I'm not looking for much....

-----Original Message-----
From: Jeff Whiteside [mailto:jeff.m.whiteside@gmail.com] 
Sent: 31 December 2008 02:22
To: Daniel Barkalow
Cc: Conor Rafferty; Boyd Stephen Smith Jr.; git@vger.kernel.org
Subject: Re: for newbs = little exercise / tutorial / warmup for windows
and other non-sophisticated new Git users :-) [Scanned]

wtf is wrong with

git checkout <something>

??

if you must have

git checkout <something> <paths>

then instead use

git checkout <something> <paths>
git clean

but you will lose other files that aren't part of the repo but are still
in the project's dir (i.e. untracked files).

On Tue, Dec 30, 2008 at 4:15 PM, Daniel Barkalow <barkalow@iabervon.org>
wrote:
> On Tue, 30 Dec 2008, Conor Rafferty wrote:
>
>> I don't understand, sorry. I thought I'd already removed all files 
>> from the local tree, in the $ rm *.* move just above the checkout
>
> That removes them from the filesystem, but they're still in the index.

> And "git checkout <something> ." first gets everything that *is* in 
> "." in <something> into the index, and then gets everything from "." 
> in the index into the filesystem.
>
> I suppose it is questionable as to whether it ought to copy paths that

> aren't in versionA from the index into the filesystem.
>
> To see this in a bit more detail, do:
>
> $ rm *.*
> $ git status
> (notice that the deletes are in the "won't be committed" section)
>
> Now, "git checkout <path>" will discard any changes in the "won't be 
> committed" section for that path. Maybe "git checkout versionA <path>"
> should only discard changes that are in the "won't be committed" 
> section for filenames that match that path and are in versionA (or are
> *different* in versionA and not removed?), but I think it's an area 
> where, if you're expecting any particular behavior out of that 
> command, you're likely to be surprised in some way in some situation.
>
>        -Daniel
> *This .sig left intentionally blank*
> --
> 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: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]

[Boyd Stephen Smith Jr.]

[-- Attachment #1: Type: text/plain, Size: 1231 bytes --]

On Tuesday 2008 December 30 20:30:46 Conor Rafferty wrote:
> MERCURIAL:
>
> Update
> hg update [-C] [-d DATE] [[-r] REV]

Which is the role of "git checkout <branch>"

"git checkout <branch> <paths>" is similar to "hg revert -r <branch> <paths>", 
but the later seems to handle your use case properly.  I don't know much 
about the workings of hg revert -- it might use the history to determine 
what's correct, or completely bypass the existing "index" when determining 
what to drop.  In any case, it seems to work better for what you are trying 
to do.  Why not just use it?

I could do with more hg/bzr/darcs experience myself, but git seems to behave 
the way I like it so it's what I use.  When deciding on the right tool for 
the job, it does help to have many.  "To the man with only a hammer, all 
problems look like nails."

That said, I'm pretty sure that if you hasn't specified '.' and just used "git 
checkout <branch>" you wouldn't have seen those "artifacts".
-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss@iguanasuicide.net                     ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.net/                      \_/     

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]

[Junio C Hamano]

"Boyd Stephen Smith Jr." <bss@iguanasuicide.net> writes:

> On Tuesday 2008 December 30 20:30:46 Conor Rafferty wrote:
>> MERCURIAL:
>>
>> Update
>> hg update [-C] [-d DATE] [[-r] REV]
>
> Which is the role of "git checkout <branch>"
>
> "git checkout <branch> <paths>" is similar to "hg revert -r <branch> <paths>", 

No it is not.

The form of the command is makes this request:

    Please look into that named <tree-ish>, and check out the named
    <paths> out of it to my work tree.  Because the reason I want them in
    my work tree is so that I can include them as part of the next commit
    I am preparing to create in the index, please update these paths in my
    index while at it.

After working for some time on top of the current HEAD to make changes to
existing files in "lib/" directory, if you notice that none of your
changes in the directory does not make any sense, you may rather want to
start over from the version that you began with.  In such a case, you
would make the above request with <tree-ish> equal to HEAD and <paths>
equal to "lib", i.e.

    git checkout HEAD lib

and as the end result you may be able to achieve "reverting my crappy
changes to all of the files in lib/".

HOWEVER.

Read what the above request says carefully again, and think about what
would happen to a path that exists in the work tree but not in the named
<tree-ish>.

In other words, what would happen to a new file you added since you
started working on top of HEAD?

See?

A new file that you added in lib/ directory since you started working will
not be molested in any way, because they do not even exist in the
<tree-ish>.

If you think "git checkout <tree-ish> <paths>" has anything to do with
reverting, you will keep confusing yourself.  The command is "checking out
the named paths out of the named tree", and absense of a file is not
something that is checked out by this operation.

Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]

[Daniel Barkalow]

On Tue, 30 Dec 2008, Junio C Hamano wrote:

> "Boyd Stephen Smith Jr." <bss@iguanasuicide.net> writes:
> 
> > On Tuesday 2008 December 30 20:30:46 Conor Rafferty wrote:
> >> MERCURIAL:
> >>
> >> Update
> >> hg update [-C] [-d DATE] [[-r] REV]
> >
> > Which is the role of "git checkout <branch>"
> >
> > "git checkout <branch> <paths>" is similar to "hg revert -r <branch> <paths>", 
> 
> No it is not.
> 
> The form of the command is makes this request:
> 
>     Please look into that named <tree-ish>, and check out the named
>     <paths> out of it to my work tree.  Because the reason I want them in
>     my work tree is so that I can include them as part of the next commit
>     I am preparing to create in the index, please update these paths in my
>     index while at it.

With that description, there's a bug: in addition to the above, it checks 
out from the index any path which does match the <paths> but isn't in 
<tree-ish>. I think the way to fix that would be to update the work tree 
from read_tree_some() instead of using the "if pathspec_match() ... 
checkout_entry()" loop over the index.

With the current code, you can have git check out a file that you've 
changed/deleted from a tree that doesn't contain it at all (and you get 
the index version). E.g.:

$ rm wt-status.c
$ git checkout e83c5163316f89bfbde7d9ab23ca2e25604af290 wt-status.c
$ ls wt-status.c
wt-status.c

(instead, you should get an error if a <path> doesn't match anything in 
the <tree-ish> and only get those things that it matches in the 
<tree-ish>.)

I think I was too zealous sharing code back in February. I should have a 
patch by the weekend if nobody beats me to it. (And I still think that, if 
you hit this case, you must be confused, but git isn't helping by doing 
what it does.)

	-Daniel
*This .sig left intentionally blank*

Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]

[Junio C Hamano]

Daniel Barkalow <barkalow@iabervon.org> writes:

> With that description, there's a bug: in addition to the above, it checks 
> out from the index any path which does match the <paths> but isn't in 
> <tree-ish>....
> ...
> (instead, you should get an error if a <path> doesn't match anything in 
> the <tree-ish> and only get those things that it matches in the 
> <tree-ish>.)
>
> I think I was too zealous sharing code back in February. I should have a 
> patch by the weekend if nobody beats me to it. (And I still think that, if 
> you hit this case, you must be confused, but git isn't helping by doing 
> what it does.)

I think that may be a good thing to do.

By the way, I am not opposed to have "git $revert <tree-ish> <path>..."
that makes the work tree and the index identical to what existed in
<tree-ish> at the named <paths>, i.e. checking out "the absense" of files
in the named directory if <path> is a subtree.  Because it is very
established to use the command verb "revert" to mean making a
counter-commit by now, we may have to use a word other than "revert" for
that purpose, though.

Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]

[Boyd Stephen Smith Jr.]

[-- Attachment #1: Type: text/plain, Size: 1329 bytes --]

On Tuesday 30 December 2008, Junio C Hamano <gitster@pobox.com> wrote 
about 'Re: for newbs = little exercise / tutorial / warmup for windows and 
other non-sophisticated new Git users :-) [Scanned]':
>"Boyd Stephen Smith Jr." <bss@iguanasuicide.net> writes:
>> "git checkout <branch> <paths>" is similar to "hg revert -r <branch>
>> <paths>",
>
>No it is not.
>
>The form of the command is makes this request:
>
>    Please look into that named <tree-ish>, and check out the named
>    <paths> out of it to my work tree.

That seems similar to "hg revert":
Using the -r option, revert the given files or directories to their
contents as of a specific revision.

>    Because the reason I want them in 
>    my work tree is so that I can include them as part of the next commit
>    I am preparing to create in the index, please update these paths in
> my index while at it.

This part is odd to me, but does make some sense.  I can only think of a 
few reasons to retrieve a file from a different tree-ish without 
immediately turning around and doing "git add <bar>".
-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss@iguanasuicide.net                     ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.net/                      \_/     

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

RE: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]

[Conor Rafferty]

Whoa there Stevey, I'm a windows user, don't forget

I mighta had a chance at following this 10-12 years ago when last I did
some scripting, but not now

Its very generous of you to go to all this bother and I'm mighty
grateful. 

However if this is what its gonna take to get what I want, then Im'
outta here.

Getting a snapshot on the filesystem, in terms of a directory tree (not
a reference to, representation of etc etc. but a real life directory
tree, files and folders that you can actually interact with - build,
edit etc.), of a past version is a basic operation in my book.
Even in clearcase this was a cinch.

Is there anyone who can see anyway to do this simply, without a script,
without creating a branch ?

Personally I suspect "$ git checkout <version> ." is what should be
doing this (I have confidence in saying this because it seems to want to
do this, and does it right at least half the time). But no-one wants to
admit to the remotest possibility that it might be off ....

In any case, a bunch of smart guys like you should be able to knock this
functionality together in hours, if you put your mind to it.

I know you guys have put a lot into this project and for many of you it
defines who you are 
- but if you want ppl out there in the user world to take this stuff on,
its gotta work for them 

<END>impassioned plea</>

-----Original Message-----
From: Boyd Stephen Smith Jr. [mailto:bss@iguanasuicide.net] 
Sent: 30 December 2008 22:17
To: Conor Rafferty
Cc: git@vger.kernel.org
Subject: Re: for newbs = little exercise / tutorial / warmup for windows
and other non-sophisticated new Git users :-) [Scanned]

On Tuesday 2008 December 30 15:49:22 Boyd Stephen Smith Jr. wrote:
> On Tuesday 2008 December 30 15:27:33 you wrote:
> > conorr@KINKLADZE /w/GITPLATFORM/swproj $ git status # On branch 
> > master nothing to commit (working directory clean)
> >
> > conorr@KINKLADZE /w/GITPLATFORM/swproj $ git checkout versionA .
> >
> > conorr@KINKLADZE /w/GITPLATFORM/swproj $ ls ABC.txt  AC.txt
> >
> > conorr@KINKLADZE /w/GITPLATFORM/swproj $ rm *.*
> >
> > conorr@KINKLADZE /w/GITPLATFORM/swproj $ git checkout versionB .
> >
> > conorr@KINKLADZE /w/GITPLATFORM/swproj $ ls ABC.txt  AC.txt  BC.txt
>
> Not a bug.  git checkout <commit> <paths> does not delete files by
design.
> Try using "git checkout versionB" instead (no paths specified), and it

> will properly remove AC.txt from your working tree as well as warning 
> you that "You're Doing It Wrong" (tm).

This may be what you want:
(commands)
mkdir test && cd test && git init &&

echo 'ABC' > ABC.txt && echo 'AC' > AC.txt && echo 'BC' > BC.txt && echo
'C' > C.txt &&

find -name '*C*' -print0 | xargs -r0 -- git add -- && git commit -m '"C"
files.' && git branch versionC master &&

git checkout -b versionA master &&
find -type f -not -wholename '*.git*' -not -name '*A*' -print0 | \
	xargs -r0 -- git rm -- &&
git commit -m 'Removed non-"A" files.' &&

git checkout -b versionB &&
find -type f -not -wholename '*.git*' -not -name '*B*' -print0 | \
	xargs -r0 -- git rm -- &&
git commit -m 'Removed non-"B" files.' &&

git checkout -b versionD master &&
find -type f -not -wholename '*.git*' -not -name '*D*' -print0 | \
	xargs -r0 -- git rm -- && git commit -m 'Removed non-"D" files.'
&&

git checkout master && git branch -v --abbrev=4 && ls -l && git checkout
versionA && ls -l && git checkout versionB && ls -l && git checkout
versionC && ls -l && git checkout versionD && ls -l

(output)
/home/bss/test
Initialized empty Git repository in /home/bss/test/.git/ Created initial
commit 8dbf3a1: All files.
 4 files changed, 4 insertions(+), 0 deletions(-)  create mode 100644
ABC.txt  create mode 100644 AC.txt  create mode 100644 BC.txt  create
mode 100644 C.txt Switched to a new branch "versionA"
rm 'BC.txt'
rm 'C.txt'
Created commit a06e10c: Removed non-"A" files.
 2 files changed, 0 insertions(+), 2 deletions(-)  delete mode 100644
BC.txt  delete mode 100644 C.txt Switched to a new branch "versionB"
rm 'AC.txt'
Created commit 2029ca2: Removed non-"B" files.
 1 files changed, 0 insertions(+), 1 deletions(-)  delete mode 100644
AC.txt Switched to a new branch "versionD"
rm 'ABC.txt'
rm 'AC.txt'
rm 'BC.txt'
rm 'C.txt'
Created commit 1793ba0: Removed non-"D" files.
 4 files changed, 0 insertions(+), 4 deletions(-)  delete mode 100644
ABC.txt  delete mode 100644 AC.txt  delete mode 100644 BC.txt  delete
mode 100644 C.txt Switched to branch "master"
* master   8dbf "C" files.
  versionA a06e Removed non-"A" files.
  versionB 2029 Removed non-"B" files.
  versionC 8dbf "C" files.
  versionD 1793 Removed non-"D" files.
total 16
-rw-r--r-- 1 bss users 4 2008-12-30 16:10 ABC.txt
-rw-r--r-- 1 bss users 3 2008-12-30 16:10 AC.txt
-rw-r--r-- 1 bss users 3 2008-12-30 16:10 BC.txt
-rw-r--r-- 1 bss users 2 2008-12-30 16:10 C.txt Switched to branch
"versionA"
total 8
-rw-r--r-- 1 bss users 4 2008-12-30 16:10 ABC.txt
-rw-r--r-- 1 bss users 3 2008-12-30 16:10 AC.txt Switched to branch
"versionB"
total 4
-rw-r--r-- 1 bss users 4 2008-12-30 16:10 ABC.txt Switched to branch
"versionC"
total 16
-rw-r--r-- 1 bss users 4 2008-12-30 16:10 ABC.txt
-rw-r--r-- 1 bss users 3 2008-12-30 16:10 AC.txt
-rw-r--r-- 1 bss users 3 2008-12-30 16:10 BC.txt
-rw-r--r-- 1 bss users 2 2008-12-30 16:10 C.txt Switched to branch
"versionD"
total 0
-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss@iguanasuicide.net                     ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.net/                      \_/     

Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]

[Boyd Stephen Smith Jr.]

[-- Attachment #1: Type: text/plain, Size: 3297 bytes --]

On Tuesday 2008 December 30 16:55:38 Conor Rafferty wrote:
> Whoa there Stevey, I'm a windows user, don't forget

I just assumed you were also a git user. ;)

> However if this is what its gonna take to get what I want, then Im'
> outta here.

You aren't being entirely clear about what you want.

> Getting a snapshot on the filesystem, in terms of a directory tree (not
> a reference to, representation of etc etc. but a real life directory
> tree, files and folders that you can actually interact with - build,
> edit etc.), of a past version is a basic operation in my book.
> Even in clearcase this was a cinch.

Well, there's a lot of things about UNIX and Windows directories that git 
doesn't store.  It'll restore the contents, sure, but not the permissions, 
timestamps, etc.  However git also stores the *history*, if you don't care 
about that, tarballs or zip archives might actually be a better system for 
your purposes.

But, each time you commit you've made some snapshot (completeness depends on 
what you staged with git add and friends) and recorded that snapshot as 
a "later point in time" from the last snapshot you "git checkout"ed.  That 
new object (a "commit") can be identified by it's sha1.  It holds a sha1 of 
all it's parents (also "commits") and of the snapshot alone (a "tree").

You've also figured out how to use lightweight tags to give names (other than 
their sha1) to your commits.

> Is there anyone who can see anyway to do this simply, without a script,
> without creating a branch ?

Branching is arguably easier than tagging, and probably what you want to do 
instead.  Sure, branches are mutable, but unsigned tags are also fairly 
mutable.

> Personally I suspect "$ git checkout <version> ." is what should be
> doing this.

I'm pretty sure what you want is "git checkout <version>" not "git checkout 
<version> <paths>".  They operate differently.  Modern git can checkout a 
lightweight tag, but it's going to warn you that it not what you want.

> - but if you want ppl out there in the user world to take this stuff on,
> its gotta work for them

Maybe others do, but I don't really see git as an end-user tool.  It's a 
developer tool and rightly demands a bit of RTFMing before using it 
effectively.

What you seem to *really* want is a bunch of named trees without any 
relationship between one another.  IMHO, git isn't really good at that (but 
only because it demands to do more).  A directory full of tarballs / 
zip-archives and a couple of scripts you wrote yourself (extract.sh; 
name-and-save.sh) would probably be better.

I admit that there seems to be quite a niche for some sort of trivially usable 
VCS, but it needs to be good at merging spreadsheets, compressed/binary XML, 
presentations/decks, and other things not-text, have a pretty GUI, and run 
securely over TCP/IP ports that no one is willing to block.  It will probably 
be next to useless for doing what git was initially designed for (managing 
Linux kernel patches).
-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss@iguanasuicide.net                     ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.net/                      \_/     

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]

[Sitaram Chamarty]

On 2008-12-30, Conor Rafferty <conor.rafferty@altmore.co.uk> wrote:

[re-arranged some of the quotes; it's not in the same order
as in your original email...]

> Even in clearcase this was a cinch.

Hey there's no need to use swear words ;-)

> Is there anyone who can see anyway to do this simply, without a script,
> without creating a branch ?

You'll have to unlearn this resistance to creating branches.
I've never used clearcase, but people tell me it is
expensive to create branches and/or merge them later --
almost a project in itself perhaps?

In git, however, creating a branch is as cheap as creating a
tag, so why not go with the flow until you're a little more
familiar with it?

> Personally I suspect "$ git checkout <version> ." is what should be

leave out the "." is all you needed to do.

> doing this (I have confidence in saying this because it seems to want to
> do this, and does it right at least half the time). But no-one wants to
> admit to the remotest possibility that it might be off ....

Because it's not off :-)  You're using an unusual construct
that is not often used.  (I've done path checkout of one or
a few files, but not the whole "." ever).  So it took people
time to analyse what was happening -- such as suggesting you
use "git ls-files -s" to see what's in the index at each
stage.

May I ask where you got the idea that "." is needed?  We
need to fix that source too ;-)

> In any case, a bunch of smart guys like you should be able to knock this
> functionality together in hours, if you put your mind to it.

> I know you guys have put a lot into this project and for many of you it
> defines who you are 
> - but if you want ppl out there in the user world to take this stuff on,
> its gotta work for them 

While I applaud your efforts to try and understand
everything in one long weekend, you'd have more fun if you
spaced it out a bit :-)

I'll also say that "ppl out there in the user world" will
not experiment the way you have -- they'll follow a basic
set of commands that work.

They'll even (gasp!) use the GUI.  Believe me the GUIs are
pretty nice, though it won't let you checkout a tag (you can
checkout a branch, but not a tag -- because this gets you a
detached head which is a little too advanced for normal
folks I guess).

In other words, you're combining newbie and expert too
fast...

Finally, I heartily recommend reading the following article:
http://thedailywtf.com/Articles/Happy_Merge_Day!.aspx

If the hints in the article are not enough for you to figure
out this is about clearcase read the comments :-)

RE: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]

[Conor Rafferty]

I don't understand, sorry. I thought I'd already removed all files from
the local tree, in the $ rm *.* move just above the checkout  

-----Original Message-----
From: Boyd Stephen Smith Jr. [mailto:bss@iguanasuicide.net] 
Sent: 30 December 2008 21:49
To: Conor Rafferty
Cc: git@vger.kernel.org
Subject: Re: for newbs = little exercise / tutorial / warmup for windows
and other non-sophisticated new Git users :-) [Scanned]

On Tuesday 2008 December 30 15:27:33 you wrote:
> conorr@KINKLADZE /w/GITPLATFORM/swproj $ git status # On branch master

> nothing to commit (working directory clean)
>
> conorr@KINKLADZE /w/GITPLATFORM/swproj $ git checkout versionA .
>
> conorr@KINKLADZE /w/GITPLATFORM/swproj $ ls ABC.txt  AC.txt
>
> conorr@KINKLADZE /w/GITPLATFORM/swproj $ rm *.*
>
> conorr@KINKLADZE /w/GITPLATFORM/swproj $ git checkout versionB .
>
> conorr@KINKLADZE /w/GITPLATFORM/swproj $ ls ABC.txt  AC.txt  BC.txt

Not a bug.  git checkout <commit> <paths> does not delete files by
design.  
Try using "git checkout versionB" instead (no paths specified), and it
will properly remove AC.txt from your working tree as well as warning
you that "You're Doing It Wrong" (tm).
-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss@iguanasuicide.net                     ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.net/                      \_/     

Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]

[Boyd Stephen Smith Jr.]

[-- Attachment #1: Type: text/plain, Size: 1975 bytes --]

On Tuesday 2008 December 30 16:36:19 Conor Rafferty wrote:
> I don't understand, sorry. I thought I'd already removed all files from
> the local tree, in the $ rm *.* move just above the checkout

Yeah, I guess I missed that, and I am seeing some "odd" behavior from git 
checkout <treeish> <path>, but I'm not an expert on exactly what that is 
supposed to do, particularly when applied to a directory.

The description is:
"When <paths> are given, this command does not switch branches. It
updates the named paths in the working tree from the index file, or from a 
named commit.  [...]  <tree-ish> argument can be used to specify a
specific tree-ish to update the index for
the given paths before updating the working tree."

I'm guess what is happening here is that the index is getting updated in a way 
that includes both the files from the HEAD tree and from the named tree.  
Then the modified index is written out, outputting all of them, effectively 
doing some sort of "theirs" merge.  It's not quite what I would expect but I 
don't normally use git checkout <treeish> <path> when path indicates a 
directory.

You should do a "git status" when you get ls output that is "unexpected".  
Here, it confirms that the index has been updated (git thinks I've staged 
some changes).

Personally, I expected "git checkout <treeish> <paths>" to bypass the index 
entirely, the way "git commit <paths>" does, but this way also makes sense -- 
at least when applied to a single file.  (And probably saves a good number of 
git add commands...).

In short, while I can't say for sure, I'm pretty sure you don't want the "git 
commit <treeish> <path>" form and want the "git commit <treeish>" form 
instead.
-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss@iguanasuicide.net                     ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.net/                      \_/     

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

RE: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]

[Daniel Barkalow]

On Tue, 30 Dec 2008, Conor Rafferty wrote:

> I don't understand, sorry. I thought I'd already removed all files from
> the local tree, in the $ rm *.* move just above the checkout  

That removes them from the filesystem, but they're still in the index. And 
"git checkout <something> ." first gets everything that *is* in "." in
<something> into the index, and then gets everything from "." in the index 
into the filesystem.

I suppose it is questionable as to whether it ought to copy paths that 
aren't in versionA from the index into the filesystem.

To see this in a bit more detail, do:

$ rm *.*
$ git status
(notice that the deletes are in the "won't be committed" section)

Now, "git checkout <path>" will discard any changes in the "won't be 
committed" section for that path. Maybe "git checkout versionA <path>" 
should only discard changes that are in the "won't be committed" section 
for filenames that match that path and are in versionA (or are 
*different* in versionA and not removed?), but I think it's an area where, 
if you're expecting any particular behavior out of that command, you're 
likely to be surprised in some way in some situation.

	-Daniel
*This .sig left intentionally blank*

Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]

[Jeff Whiteside]

wtf is wrong with

git checkout <something>

??

if you must have

git checkout <something> <paths>

then instead use

git checkout <something> <paths>
git clean

but you will lose other files that aren't part of the repo but are
still in the project's dir (i.e. untracked files).

On Tue, Dec 30, 2008 at 4:15 PM, Daniel Barkalow <barkalow@iabervon.org> wrote:
> On Tue, 30 Dec 2008, Conor Rafferty wrote:
>
>> I don't understand, sorry. I thought I'd already removed all files from
>> the local tree, in the $ rm *.* move just above the checkout
>
> That removes them from the filesystem, but they're still in the index. And
> "git checkout <something> ." first gets everything that *is* in "." in
> <something> into the index, and then gets everything from "." in the index
> into the filesystem.
>
> I suppose it is questionable as to whether it ought to copy paths that
> aren't in versionA from the index into the filesystem.
>
> To see this in a bit more detail, do:
>
> $ rm *.*
> $ git status
> (notice that the deletes are in the "won't be committed" section)
>
> Now, "git checkout <path>" will discard any changes in the "won't be
> committed" section for that path. Maybe "git checkout versionA <path>"
> should only discard changes that are in the "won't be committed" section
> for filenames that match that path and are in versionA (or are
> *different* in versionA and not removed?), but I think it's an area where,
> if you're expecting any particular behavior out of that command, you're
> likely to be surprised in some way in some situation.
>
>        -Daniel
> *This .sig left intentionally blank*
> --
> 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
>