Simple UI question...

Simple UI question...

[Chris Lee]

Hey guys,

So I'm trying to figure out the best way to pull out a checkout of the
entire tree as of a given revision ID. I have a whole bunch of
revision IDs, and I'd like to know what the git equivalent of (say)
the following is:

svn co -r280600 file:///path/to/svn/repo

For the sake of argument, let's say that r280600 imported as
07058310db903317faa300b93004a5a2e0fc2dcc into my git tree.

How do I get a pristine checkout in my working copy of the entire tree
as the repository saw it at 07058310db903317faa300b93004a5a2e0fc2dcc?

Eric Anholt suggested 'git checkout -b temporary-branch-name
$sha1sum'; davej suggested 'git-read-tree $sha1sum &&
git-checkout-index -a -f' but for some reason, neither of these
commands seems to do exactly as I expect. davej's method seems to work
for some revision IDs, but not for others, and the other method seems
to work just about as well. (The problem I have seen is that, for some
revisions, the only files I get in the working copy are the files that
were changed in that commit; the rest of the files in the tree do not
get checked out.)

Re: Simple UI question...

[Josef "Jeff" Sipek]

On Sun, Jan 07, 2007 at 03:02:59AM -0800, Chris Lee wrote:
> Hey guys,
> 
> So I'm trying to figure out the best way to pull out a checkout of the
> entire tree as of a given revision ID. I have a whole bunch of
> revision IDs, and I'd like to know what the git equivalent of (say)
> the following is:
> 
> svn co -r280600 file:///path/to/svn/repo
> 
> For the sake of argument, let's say that r280600 imported as
> 07058310db903317faa300b93004a5a2e0fc2dcc into my git tree.
> 
> How do I get a pristine checkout in my working copy of the entire tree
> as the repository saw it at 07058310db903317faa300b93004a5a2e0fc2dcc?

I have great success with:

git-reset --hard $hash

Jeff.

-- 
#endif /* NO LIFE */

Re: Simple UI question...

[Shawn O. Pearce]

Chris Lee <clee@kde.org> wrote:
> So I'm trying to figure out the best way to pull out a checkout of the
> entire tree as of a given revision ID. I have a whole bunch of
> revision IDs, and I'd like to know what the git equivalent of (say)
> the following is:
> 
> svn co -r280600 file:///path/to/svn/repo
> 
> For the sake of argument, let's say that r280600 imported as
> 07058310db903317faa300b93004a5a2e0fc2dcc into my git tree.
> 
> How do I get a pristine checkout in my working copy of the entire tree
> as the repository saw it at 07058310db903317faa300b93004a5a2e0fc2dcc?

One way is:

  git archive \
    --format=tar \
    07058310db903317faa300b93004a5a2e0fc2dcc \
    | (mkdir ../export; cd ../export; tar xf -)

Would give you a new directory tree which is not related to any
Git repository, but which contains the exact set of files in 070583.
But that's probably not what you meant.
 
> Eric Anholt suggested 'git checkout -b temporary-branch-name
> $sha1sum';

Yes, that is usually the way you do this.  Unlike the archive trick
above the result will be in your current working directory and
will be associated with the current Git repository.  Further you
can modify this and commit changes if you need to.

> davej suggested 'git-read-tree $sha1sum &&
> git-checkout-index -a -f'

That's just cruel.  Its only part of the underlying operations that
git checkout is performing, and its trashing your current branch
by making HEAD no longer match the index.  And its very low-level.
And it doesn't really do a 2-way merge to fully update the working
directory.  Not the best way for a user to perform this action.
Forget davej ever suggested this.

> but for some reason, neither of these
> commands seems to do exactly as I expect. davej's method seems to work
> for some revision IDs, but not for others, and the other method seems
> to work just about as well. (The problem I have seen is that, for some
> revisions, the only files I get in the working copy are the files that
> were changed in that commit; the rest of the files in the tree do not
> get checked out.)

The problem is davej's method doesn't take into account what the
current working directory actually has stored in it.  It does not
delete any files which should not appear in $sha1sum.  It also
overwrites more files than it needs to, as it overwrites everything
instead of just those files which actually differ between the
current working directory and $sha1sum.

Eric Anholt's version is the correct way to do it.  It is also very
fast as it only has to modify the files which actually differed.

If Eric's version isn't always working then I'd have to suggest
that you exmaine the output of `git status` for switching to
some temporary branch based on $sha1sum.  Perhaps you have local
modifications which are carrying over in your working directory?

-- 
Shawn.

Re: Simple UI question...

[Chris Lee]

On 1/7/07, Shawn O. Pearce <spearce@spearce.org> wrote:
> Chris Lee <clee@kde.org> wrote:
> > So I'm trying to figure out the best way to pull out a checkout of the
> > entire tree as of a given revision ID. I have a whole bunch of
> > revision IDs, and I'd like to know what the git equivalent of (say)
> > the following is:
> >
> > svn co -r280600 file:///path/to/svn/repo
> >
> > For the sake of argument, let's say that r280600 imported as
> > 07058310db903317faa300b93004a5a2e0fc2dcc into my git tree.
> >
> > How do I get a pristine checkout in my working copy of the entire tree
> > as the repository saw it at 07058310db903317faa300b93004a5a2e0fc2dcc?
>
> One way is:
>
>   git archive \
>     --format=tar \
>     07058310db903317faa300b93004a5a2e0fc2dcc \
>     | (mkdir ../export; cd ../export; tar xf -)
>
> Would give you a new directory tree which is not related to any
> Git repository, but which contains the exact set of files in 070583.
> But that's probably not what you meant.
>
> > Eric Anholt suggested 'git checkout -b temporary-branch-name
> > $sha1sum';
>
> Yes, that is usually the way you do this.  Unlike the archive trick
> above the result will be in your current working directory and
> will be associated with the current Git repository.  Further you
> can modify this and commit changes if you need to.
>
> > davej suggested 'git-read-tree $sha1sum &&
> > git-checkout-index -a -f'
>
> That's just cruel.  Its only part of the underlying operations that
> git checkout is performing, and its trashing your current branch
> by making HEAD no longer match the index.  And its very low-level.
> And it doesn't really do a 2-way merge to fully update the working
> directory.  Not the best way for a user to perform this action.
> Forget davej ever suggested this.

Heh. He's going to kill me for continuing to drag his name throught he
mud. Anyway... :)

> > but for some reason, neither of these
> > commands seems to do exactly as I expect. davej's method seems to work
> > for some revision IDs, but not for others, and the other method seems
> > to work just about as well. (The problem I have seen is that, for some
> > revisions, the only files I get in the working copy are the files that
> > were changed in that commit; the rest of the files in the tree do not
> > get checked out.)
>
> The problem is davej's method doesn't take into account what the
> current working directory actually has stored in it.  It does not
> delete any files which should not appear in $sha1sum.  It also
> overwrites more files than it needs to, as it overwrites everything
> instead of just those files which actually differ between the
> current working directory and $sha1sum.

What I've been doing is 'rm -rf *' from the working directory and
trying the commands out; I don't want any empty folders or anything.

> Eric Anholt's version is the correct way to do it.  It is also very
> fast as it only has to modify the files which actually differed.

Eric's shows the same problem - for some revision IDs, when I do a
checkout, I only get the files that were changed in that revision.

> If Eric's version isn't always working then I'd have to suggest
> that you exmaine the output of `git status` for switching to
> some temporary branch based on $sha1sum.  Perhaps you have local
> modifications which are carrying over in your working directory?

I assume 'removing everything in the working tree' counts as "local
modifications"? :)

Re: Simple UI question...

[Shawn O. Pearce]

Chris Lee <clee@kde.org> wrote:
> Eric's shows the same problem - for some revision IDs, when I do a
> checkout, I only get the files that were changed in that revision.
> 
> >If Eric's version isn't always working then I'd have to suggest
> >that you exmaine the output of `git status` for switching to
> >some temporary branch based on $sha1sum.  Perhaps you have local
> >modifications which are carrying over in your working directory?
> 
> I assume 'removing everything in the working tree' counts as "local
> modifications"? :)

Yes!  That's what's going wrong.  Don't do "rm -rf *".  Let Git take
care of the empty directories for you.  If Git deletes all source
files in that directory (as they don't belong in this version that
you are checking out) it will also delete the now empty directory.

The only time it fails is if you are on Windows and some process
has the directory busy.  :-)

-- 
Shawn.

Re: Simple UI question...

[Junio C Hamano]

"Chris Lee" <clee@kde.org> writes:

> Eric Anholt suggested 'git checkout -b temporary-branch-name
> $sha1sum'; davej suggested 'git-read-tree $sha1sum &&
> git-checkout-index -a -f' but for some reason, neither of these
> commands seems to do exactly as I expect.

These two do vastly different things (but the latter is flawed
and does _not_ do what it is trying to do).

 - If this checkout is just to look-see, and if you are on a
   branch that is precious to you (say, you intend to keep
   importing from svn or other repository onto that branch),
   then you should use a temporary branch.  Eric's suggestion is
   this approach -- but "git checkout -b $branch $start" is
   about CREATING a new branch, so once you used the temporary
   branch name, you cannot expect the same command line with
   only different starting point to work.  In other words, I
   suspect you saw "it doesn't work" because you did this:

	$ git checkout -b foo $commit1
	$ git checkout -b foo $commit2

   and got an error message from the second one.

 - If you do not mind trashing the current branch, then "git
   reset --hard" is what you want, and what you said was Dave's
   suggestion is an incorrectly spelled version of old timer's
   way to do what "git reset --hard" does by hand.

Assuming that you do not want to trash your branch (and you
usually don't), the correct sequence is first do:

	$ git checkout -b look-see

This creates a new branch "look-see" (the name does not matter
as long as you do not have such a branch) from whatever branch
you happen to be on and switch to it.  After this, you will be
on the new "look-see" branch.  At which commit this branch
starts does not matter.

Then, whichever commit you would want to check out and look at,
you would do:

	$ git reset --hard $commit
 
This "trashes" look-see branch by moving to that commit -- it
trashes in the sense that it makes the "look-see" branch forget
about all commits that comes after you resetted to, but you do
not care because this branch is temporary branch you created.
Once you are done looking at this commit, you can repeatedly say
"git reset --hard" to move around to look at different commits.

Once you are done, you do not need to be on (nor need) look-see
branch, so get rid of it.

	$ git checkout master
        $ git branch -D look-see

> ... (The problem I have seen is that, for some
> revisions, the only files I get in the working copy are the files that
> were changed in that commit; the rest of the files in the tree do not
> get checked out.)

This is because the low-level commands in the above example to
mimick "git reset --hard" does is flawed.

If you are curious,...

The way "git-reset --hard" does it (it is just a shell script) is:

	git-read-tree --reset -u $rev

but it does other things for safety.  Dave apparently learned
git long time before we only had plumbing (set of low-level
commands), so the suggestion did not use Porcelain (higher level
commands) "git-reset"; back then, the correct way to spell that
was:

	git-read-tree $rev &&
        git-checkout-index -f -q -u -a

but git-read-tree learned -u option and made the second command
in this sequence unnecessary.

In general, you should not have to use git-checkout-index nor
git-read-tree yourself if you are working with today's git.

Re: Simple UI question...

[Chris Lee]

On 1/7/07, Shawn O. Pearce <spearce@spearce.org> wrote:
> Chris Lee <clee@kde.org> wrote:
> > I assume 'removing everything in the working tree' counts as "local
> > modifications"? :)
>
> Yes!  That's what's going wrong.  Don't do "rm -rf *".  Let Git take
> care of the empty directories for you.  If Git deletes all source
> files in that directory (as they don't belong in this version that
> you are checking out) it will also delete the now empty directory.
>
> The only time it fails is if you are on Windows and some process
> has the directory busy.  :-)

So, if I were starting with an empty working directory, and I had just
synced over the .git folder from the place where I'm doing the actual
importing - how would I populate the working directory with a copy of
the contents of the tree from (say)
07058310db903317faa300b93004a5a2e0fc2dcc ?

Re: Simple UI question...

[Junio C Hamano]

"Chris Lee" <clee@kde.org> writes:

> On 1/7/07, Shawn O. Pearce <spearce@spearce.org> wrote:
>> Chris Lee <clee@kde.org> wrote:
>> > I assume 'removing everything in the working tree' counts as "local
>> > modifications"? :)
>>
>> Yes!  That's what's going wrong.  Don't do "rm -rf *".  Let Git take
>> care of the empty directories for you.  If Git deletes all source
>> files in that directory (as they don't belong in this version that
>> you are checking out) it will also delete the now empty directory.
>>
>> The only time it fails is if you are on Windows and some process
>> has the directory busy.  :-)
>
> So, if I were starting with an empty working directory, and I had just
> synced over the .git folder from the place where I'm doing the actual
> importing - how would I populate the working directory with a copy of
> the contents of the tree from (say)
> 07058310db903317faa300b93004a5a2e0fc2dcc ?

git reset --hard 070583

Re: Simple UI question...

[Chris Lee]

On 1/7/07, Junio C Hamano <junkio@cox.net> wrote:
> "Chris Lee" <clee@kde.org> writes:
> > So, if I were starting with an empty working directory, and I had just
> > synced over the .git folder from the place where I'm doing the actual
> > importing - how would I populate the working directory with a copy of
> > the contents of the tree from (say)
> > 07058310db903317faa300b93004a5a2e0fc2dcc ?
>
> git reset --hard 070583

Okay, thanks :)

(I don't really care about trying to do actual development on any of
the branches that I've imported - I mostly am interested in finding
out some numbers on things like 'How much faster is git when rewinding
the directory tree to a given commit ID?' and related issues.)