several quick questions

several quick questions

[Nicolas Vilz 'niv']

Hello everyone,

i wonder, how i revoke a straight forward merge of two trees... I
actually wanted to be look like somewhere in the git-repository, where
some branches are merged back with the master tree, but i think, that
wasn't "cg-merge -c <tree to merge with the actual one>"...

my result was that my master tree has now the same sha1-sum as my
development-tree and gitk visualisation differs from that what i saw in
the git-repository. (Several Arrows headed into back into one line...)

maybe that was because i didn't do anything in my master tree in the
meantime.

And another thing, is there no posibility to get back to some commits or
tags? I realized you can rebranch tags... what, if i want to switch back
to git version 1.1.6 in the git repository? Or a certain commit?

do you have to make a new private branch out of the tag 1.1.6?

i used svn and there i could go back some revisions. I haven't found
such a feature in git, yet... but i think i am blind all the time.

I like git very much and every new day I like it more.

Sincerly
Nicolas

Re: several quick questions

[Andreas Ericsson]

Nicolas Vilz 'niv' wrote:
> Hello everyone,
> 
> i wonder, how i revoke a straight forward merge of two trees... I
> actually wanted to be look like somewhere in the git-repository, where
> some branches are merged back with the master tree, but i think, that
> wasn't "cg-merge -c <tree to merge with the actual one>"...
> 
> my result was that my master tree has now the same sha1-sum as my
> development-tree and gitk visualisation differs from that what i saw in
> the git-repository. (Several Arrows headed into back into one line...)
> 
> maybe that was because i didn't do anything in my master tree in the
> meantime.
> 

Correct. The "several arrows" thing is when a merge happens (i.e. two 
simultaneous lines of development crash into one another with 
surprisingly pleasant results most of the time). When you do

$ git checkout -b topic-branch
# work, work, work
$ git checkout master
$ git pull . topic-branch

git will recognize the merge-base as being the current HEAD and simply 
sets HEAD to point to that of topic-branch. This is why it's called a 
fast-forward, since no heavy computing needs to be done to combine the 
two development tracks.

> And another thing, is there no posibility to get back to some commits or
> tags? I realized you can rebranch tags... what, if i want to switch back
> to git version 1.1.6 in the git repository? Or a certain commit?
> 

git reset is your friend.

$ git reset --hard v1.1.6
$ git reset --hard ORIG_HEAD

should do something along the lines of what you want.

> do you have to make a new private branch out of the tag 1.1.6?
> 

No, you don't, but you can if you wish. It's nifty if you want to fork 
the development from a particular branch. In your case, if you really, 
really *want* the arrows pointing to one line, you can do

$ git branch topic-branch HEAD^
# work, work, work
$ git checkout master
$ git pull . topic-branch

That would create one pretty arrow. When multiple tracks of development 
(rather than just two) are combined into one it's called an octopus 
merge. Unless you really know what you're doing, you should try to avoid 
those for small projects, and doing it just for the pretty arrows is.... 
well, let's call it "interesting from the behaviour science scholars 
point of view".


> i used svn and there i could go back some revisions. I haven't found
> such a feature in git, yet... but i think i am blind all the time.
> 

Most likely. I believe at least the reset command is mentioned in the 
tutorial. I trust you've read it before asking, so something is amiss 
either with your eyesight or the tutorial.


> I like git very much and every new day I like it more.
> 

It's a Good Thing. ;)

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: several quick questions

[Nicolas Vilz 'niv']

Andreas Ericsson wrote:
> 
> git will recognize the merge-base as being the current HEAD and simply
> sets HEAD to point to that of topic-branch. This is why it's called a
> fast-forward, since no heavy computing needs to be done to combine the
> two development tracks.

well finaly, if nothing happened in one of the lines, then the two lines
become the same, when merging back into one line. and the two lines
overlay each other. That is what i saw during playing with git-merge,
git-pull and git-reset.. ok.

> 
>> do you have to make a new private branch out of the tag 1.1.6?
>>
> 
> No, you don't, but you can if you wish. It's nifty if you want to fork
> the development from a particular branch. In your case, if you really,
> really *want* the arrows pointing to one line, you can do
> 
> $ git branch topic-branch HEAD^
> # work, work, work
> $ git checkout master
> $ git pull . topic-branch
> 
> That would create one pretty arrow. When multiple tracks of development
> (rather than just two) are combined into one it's called an octopus
> merge. Unless you really know what you're doing, you should try to avoid
> those for small projects, and doing it just for the pretty arrows is....
> well, let's call it "interesting from the behaviour science scholars
> point of view".

its just the thought "cool, it looks like there at the git repo"... just
to realize "ok, that happens, when i merge two trees.

>> i used svn and there i could go back some revisions. I haven't found
>> such a feature in git, yet... but i think i am blind all the time.
>>
> 
> Most likely. I believe at least the reset command is mentioned in the
> tutorial. I trust you've read it before asking, so something is amiss
> either with your eyesight or the tutorial.

well the namespace of the references confused me, before i realized,
that HEAD finally points to an sha1sum (which symbolizes a certain commit)

mh.. I use pull if i want to get an external development tree, right? I
still search for a possibility to replace the svn:externals, which were
quite handy some times.

lets imagine, i want to reuse work i did in another repository, then I
can easily pull from that repository, which my work i want to reuse is
stored at... i see... i just will have to pull frequently.... and hope
there is no conflict between some files.


once more... thank you all and good work.

Nicolas

Re: several quick questions

[Linus Torvalds]

On Tue, 14 Feb 2006, Nicolas Vilz 'niv' wrote:
> 
> i wonder, how i revoke a straight forward merge of two trees... I
> actually wanted to be look like somewhere in the git-repository, where
> some branches are merged back with the master tree, but i think, that
> wasn't "cg-merge -c <tree to merge with the actual one>"...
> 
> my result was that my master tree has now the same sha1-sum as my
> development-tree and gitk visualisation differs from that what i saw in
> the git-repository. (Several Arrows headed into back into one line...)
> 
> maybe that was because i didn't do anything in my master tree in the
> meantime.
> 
> And another thing, is there no posibility to get back to some commits or
> tags? I realized you can rebranch tags... what, if i want to switch back
> to git version 1.1.6 in the git repository? Or a certain commit?

Both of these can be solved with "git reset".

Before going into any more detail on that, let's go over the other related 
"basic operations" too:

 - "git branch". This creates a new branch of development at an arbitrary 
   point (that defaults to "current state").

   Example:

	git branch development-trial v1.1.6

   This will create a new branch called "development-trial", which starts 
   at the v1.1.6 state. NOTE! It will _not_ check it out - your old active 
   state is left totally alone, and you still stay on whatever branch you 
   used to be on.

 - "git checkout". This switches to another branch. As a shorthand, you 
   can also choose to create the branch at the same time, but normally 
   you'd just do like this example:

	git checkout development-trial

   which will switch to the branch you just created and check that out.

 - "git reset". This will reset the current branch state to something 
   else. This is what you would use if you want to undo a commit, 
   for example: you can "reset" the current branch to before the commit 
   happened.

   NOTE! When you do this, you also have to choose what you want to do 
   about your checked-out working tree. For example, when undoing the last 
   commit, you normally want to totally undo all the working tree changes 
   too, but you might also want to just undo the commit, and leave the 
   actual changes you committed alone, so that you can re-commit them with 
   a fixed commit message, for example.

   Example:

	git reset --hard HEAD^

   this will undo the last commit (more exactly: it will select the first 
   parent of HEAD to be the new top-of-development, so if the last thing 
   you did was a merge, it will reset to the previous state). The "--hard" 
   means that you want to reset the working tree too.

   Other example:

	git reset --hard v1.1.6

   This will just reset the current branch to a particular known state (ie 
   1.1.6 in this case).

   Without the "--hard", it will _not_ change the working tree, but just 
   update the index (and branch pointer, of course) to the new state, and 
   tell you which files are "dirty" in that new state. This is great for 
   undoing just a "git commit", but leaving the tree in the state is was 
   before you committed. It's not so great if you expected to revert 
   everything, and are now confused because "git diff" shows lots of 
   changes ;)

Finally, let's go over the difference between "git fetch" and "git pull":

 - "git fetch" is what you want to do if you want to _update_ another 
   branch. For example, if you want to track what Junio is doing in his 
   git repository (assuming that was what you cloned for), doing

	git fetch origin

   will update the "origin" branch, but will _not_ touch the current 
   branch itself. This is very useful for seeing what Junio has been 
   doing, without actually affecting your own work in any way.

 - "git pull" is really just "git fetch" + "git merge". It will fetch the 
   state you asked for, and then merge that into your current branch. So 
   it's important to rmember that this actually _changes_ what you have 
   checked out and have worked on. 

   One very special case of "git pull" is when you only use the repository 
   to track another branch, and you never do any changes at all, and you 
   never switch branches around, and you always pull from the same source. 
   In that case, "git pull" will basically boil down to just a read-only 
   tracking mechanism (ie you could think of this particular usage as 
   being the git equivalent of "anoncvs" access)

The reason people may get confused is that they start out using "git pull" 
as a read-only tracking mechanism, and it's not necessarily obvious that 
"git pull" really fundamentally is a very powerful operations - much MUCH 
more complex and powerful than just "track that other branch". Which is 
why I try to make the distinction between "git fetch" and "git pull" 
clear.

			Linus

Re: several quick questions

[Kenneth Johansson]

On Tue, 14 Feb 2006 09:05:16 -0800, Linus Torvalds wrote:

> 
> 
> On Tue, 14 Feb 2006, Nicolas Vilz 'niv' wrote:
>> 
>> i wonder, how i revoke a straight forward merge of two trees... I
>> actually wanted to be look like somewhere in the git-repository, where
>> some branches are merged back with the master tree, but i think, that
>> wasn't "cg-merge -c <tree to merge with the actual one>"...
>> 
>> my result was that my master tree has now the same sha1-sum as my
>> development-tree and gitk visualisation differs from that what i saw in
>> the git-repository. (Several Arrows headed into back into one line...)
>> 
>> maybe that was because i didn't do anything in my master tree in the
>> meantime.
>> 
>> And another thing, is there no posibility to get back to some commits or
>> tags? I realized you can rebranch tags... what, if i want to switch back
>> to git version 1.1.6 in the git repository? Or a certain commit?
> 
> Both of these can be solved with "git reset".

I also had this exact question today since I wanted to compile an earlier
version of the kernel and like Nicolas I naturally got stuck on the
checkout command and that dose not work like one would think.

What I ended up doing was going nee deep into the plumbing.

first doing cat on the tag in .git/refs/tags/ 
taking the output as an argument to  "git-read-tree"
followed by "git-update-index --replace" and "git-checkout-index -a -f -u"

I'm not sure that many people will understand that they want git-reset for
this just reading the man pages.

Re: several quick questions

[Andreas Ericsson]

Kenneth Johansson wrote:
> 
> I'm not sure that many people will understand that they want git-reset for
> this just reading the man pages.
> 

Hence the tutorial.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: several quick questions

[Kenneth Johansson]

On Tue, 14 Feb 2006 19:08:49 +0100, Andreas Ericsson wrote:

> Kenneth Johansson wrote:
>> 
>> I'm not sure that many people will understand that they want git-reset for
>> this just reading the man pages.
>> 
> 
> Hence the tutorial.

It could be a little clearer what you would do in any other tool is
checkout a specifically tagged version. Perhaps adding a pointer from the
checkout man page to the reset command.

 

Re: several quick questions

[Linus Torvalds]

On Tue, 14 Feb 2006, Kenneth Johansson wrote:
> 
> What I ended up doing was going nee deep into the plumbing.
> 
> first doing cat on the tag in .git/refs/tags/ 
> taking the output as an argument to  "git-read-tree"
> followed by "git-update-index --replace" and "git-checkout-index -a -f -u"
> 
> I'm not sure that many people will understand that they want git-reset for
> this just reading the man pages.

Hey, but I bet you now as a result feel you really understand git, right? 

;)

You did it the old-fashioned way - the way real men did it back in June.

In general, doing "ls *.sh" in the git source tree shows you pretty much 
every command that you might ever want to use. Using the actual core git 
binaries directly is normally not all that useful, unless you want to do 
some strange shell pipeline to do statistics about different things in the 
tree.

		Linus

Re: several quick questions

[Carl Worth]

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

On Tue, 14 Feb 2006 09:05:16 -0800 (PST), Linus Torvalds wrote:
> 
> Both of these can be solved with "git reset".
...
>  - "git branch". This creates a new branch of development at an arbitrary 
>    point (that defaults to "current state").
> 
>  - "git checkout". This switches to another branch.
> 
>  - "git reset". This will reset the current branch state to something 
>    else.

Thanks for the summary.

I don't know if it's the original poster's question or not, but an
operation I don't see in the above is "put the working files into the
state of a given revision".

I recently needed this for some historical investigation,
(specifically examining all release tags to ensure that the results
after a git import match the results of what we get from the former
CVS repository).

In this kind of historical exploration, the notion of a "current
branch" isn't interesting, since I won't be doing any commits. So the
handling of the current branch in the above commands ends up getting
in my way [*].

Is there a more fundamental operation to "put the working files into
the state of the index"? If that exists, then that combined with
git-read-tree would give me what I wanted I think.

-Carl

[*] I did succeed in performing the operation, but only in rather
awkward ways. Here are a couple of versions of "put the working files
into the state of <revision>", both requiring the use of an otherwise
unnecessary branch, (bogus-branch):

1) Ensure bogus-branch doesn't exist, then create it at <revision>:

	# Can't be on bogus-branch when we delete it
	git checkout master
	# Use -D to force the removal, ignore errors for branch-does-not-exist
	git branch -D bogus-branch >& /dev/null || true
	# Create the branch where we want it
	git checkout -b bogus-branch <revision>

2) Ensure that bogus-branch exists somewhere (don't care where), then
   move it:

	# Create the branch (if it doesn't exist)
	git checkout -b bogus-branch >& /dev/null
	# Switch to it (which doesn't happen above if it already existed)
	git checkout bogus-branch
	# Move the branch to the revision of interest
	git reset --hard <revision>

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: several quick questions

[Linus Torvalds]

On Tue, 14 Feb 2006, Carl Worth wrote:
> 
> I don't know if it's the original poster's question or not, but an
> operation I don't see in the above is "put the working files into the
> state of a given revision".

What a strange thing to ask for.

But you can do it several ways:

 - just use "git reset" to move around in history, possibly on a temporary 
   branch.

 - use "git checkout <rev> <filename>" to checkout a particular filename 
   of a particular version (it's a special case of "git checkout", which 
   is useful, but I personally think it's a bit confusing, so I wouldn't 
   mention it unless you asked)

 - use the core internal git functions, in particular

	git-read-tree -m -u <oldtree> <newtree>

   will switch from "oldtree" to "newtree" and update (-u) the working 
   tree.

> 2) Ensure that bogus-branch exists somewhere (don't care where), then
>    move it:
> 
> 	# Create the branch (if it doesn't exist)
> 	git checkout -b bogus-branch >& /dev/null
> 	# Switch to it (which doesn't happen above if it already existed)
> 	git checkout bogus-branch
> 	# Move the branch to the revision of interest
> 	git reset --hard <revision>

This is actually what I'd suggest you always do.

Why?

It's actually as efficient as anything else, and there's much less room 
for confusion. When you want to go back, you can just do a simple

	git checkout -f master

and there's no room for confusion. You've not lost sight of any old state, 
and your HEAD never differs from your checked-out copy, so all the normal 
commands work the way you'd expect them to.

		Linus

Re: several quick questions

[Carl Worth]

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

On Tue, 14 Feb 2006 10:34:35 -0800 (PST), Linus Torvalds wrote:
> On Tue, 14 Feb 2006, Carl Worth wrote:
> > 
> > I don't know if it's the original poster's question or not, but an
> > operation I don't see in the above is "put the working files into the
> > state of a given revision".
> 
> What a strange thing to ask for.

It's pretty common in other tools. For example, many tools have a way
to examine the files from a previous state in a "no current branch"
state. Any attempt to commit from that state would prompt the user to
create a new branch name at that point.

In fact, this is the natural operation for the basis of something like
git-bisect.

> It's actually as efficient as anything else, and there's much less room 
> for confusion. When you want to go back, you can just do a simple
> 
> 	git checkout -f master

OK, the efficiency arguments made elsewhere in the thread make it
clear that these are the operations that need to happen.

But I'd still like to be able to do this without having to invent a
fake branch name, without the ability to accidentally commit on the
fake branch, and without the possibility of accidentally leaving those
commits dangling the next time I seek somewhere else.

So I looked, and git-bisect does use this approach with a fake branch
of "bisect" and by saving the original head ref in $GIT_DIR/head-name
for the sake of the final "git bisect reset".

Also, git-bisect does take advantage of the $GIT_DIR/head-name state
to prevent nested calls to "git bisect start", ("won't bisect on
seeked tree").

That gives a very natural name, "seek", for the operation I'd like.

How about "git seek" for doing the operations above, and using some
reserved branch name, (say "seek"). Then, git-bisect could easily be
built on that, and git-commit could respect the "seek" name and refuse
to commit to it, (could tell the user how to create the branch
necessary to commit from the current point).

There could also be a "git seek reset" to return to the HEAD saved by
the first in a chain of "git seek" operations.

That looks like I minor generalization of existing behavior in
git-bisect, but it would provide an operation that I would find
useful.

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: several quick questions

[Petr Baudis]

Dear diary, on Tue, Feb 14, 2006 at 09:10:28PM CET, I got a letter
where Carl Worth <cworth@cworth.org> said that...
> That gives a very natural name, "seek", for the operation I'd like.
> 
> How about "git seek" for doing the operations above, and using some
> reserved branch name, (say "seek"). Then, git-bisect could easily be
> built on that, and git-commit could respect the "seek" name and refuse
> to commit to it, (could tell the user how to create the branch
> necessary to commit from the current point).
> 
> There could also be a "git seek reset" to return to the HEAD saved by
> the first in a chain of "git seek" operations.
> 
> That looks like I minor generalization of existing behavior in
> git-bisect, but it would provide an operation that I would find
> useful.

Well, this is exactly what cg-seek does (and it's one of pretty old
Cogito commands) - it even has the same name. ;-) See my other mail in
this thread.

It works by creating a new branch cg-seek-point and storing the seeked
point there; if HEAD is already on the branch, it merely changes the
seek point and resets the working tree appropriately. cg-seek without
any arguments will then return to your original head, whose name was
stored in .git/head-name.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe.  -- Douglas Adams

Re: several quick questions

[Johannes Schindelin]

Hi,

On Tue, 14 Feb 2006, Petr Baudis wrote:

> [...]
>
> It works by creating a new branch cg-seek-point and storing the seeked
> point there; if HEAD is already on the branch, it merely changes the
> seek point and resets the working tree appropriately. cg-seek without
> any arguments will then return to your original head, whose name was
> stored in .git/head-name.

And if you want to prevent accidental commit, just "chmod a-w 
$GIT_DIR/index".

Ciao,
Dscho

Re: several quick questions

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Hi,
>
> On Tue, 14 Feb 2006, Petr Baudis wrote:
>
>> [...]
>>
>> It works by creating a new branch cg-seek-point and storing the seeked
>> point there; if HEAD is already on the branch, it merely changes the
>> seek point and resets the working tree appropriately. cg-seek without
>> any arguments will then return to your original head, whose name was
>> stored in .git/head-name.
>
> And if you want to prevent accidental commit, just "chmod a-w 
> $GIT_DIR/index".

That is a wrong answer.  It is perfectly sane to modify index
without an intention to commit that change (you can always say
"git reset").

Re: several quick questions

[Johannes Schindelin]

Hi,

On Tue, 14 Feb 2006, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > Hi,
> >
> > On Tue, 14 Feb 2006, Petr Baudis wrote:
> >
> >> [...]
> >>
> >> It works by creating a new branch cg-seek-point and storing the seeked
> >> point there; if HEAD is already on the branch, it merely changes the
> >> seek point and resets the working tree appropriately. cg-seek without
> >> any arguments will then return to your original head, whose name was
> >> stored in .git/head-name.
> >
> > And if you want to prevent accidental commit, just "chmod a-w 
> > $GIT_DIR/index".
> 
> That is a wrong answer.  It is perfectly sane to modify index
> without an intention to commit that change (you can always say
> "git reset").

Okay, I was not being completely truthful. If I did not get the original 
idea of git-seek wrong, then it was kind of an excursion, just taking a 
peek. And if you want to return from that excursion, I thought maybe it 
would make sense to disallow index operations *at all* until returning to 
the HEAD.

But I agree it is nasty. And Linus mentioned that the benefits of being 
able to commit into a temporary branch outweigh the shortcoming easily. 
(The shortcoming being that you have to keep in mind that you are in 
another branch. Which does not come easily to a fresh CVS convert.)

Ciao,
Dscho

Re: several quick questions

[Petr Baudis]

  Hi,

Dear diary, on Tue, Feb 14, 2006 at 09:37:39PM CET, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> On Tue, 14 Feb 2006, Petr Baudis wrote:
> 
> > [...]
> >
> > It works by creating a new branch cg-seek-point and storing the seeked
> > point there; if HEAD is already on the branch, it merely changes the
> > seek point and resets the working tree appropriately. cg-seek without
> > any arguments will then return to your original head, whose name was
> > stored in .git/head-name.
> 
> And if you want to prevent accidental commit, just "chmod a-w 
> $GIT_DIR/index".

  currently, Cogito has a generic "blocking" mechanism which will
prevent you to do operations mutating the history (mostly committing and
mergnign) - seeking is the only user now.

  Note that this is not very flexible and I consider this legacy stuff;
I will replace that by a specific check for a seek when I have some time
(which will also make it compatible with the git-bisect-using-headname).

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe.  -- Douglas Adams

Re: several quick questions

[Linus Torvalds]

On Tue, 14 Feb 2006, Carl Worth wrote:
> > 
> > What a strange thing to ask for.
> 
> It's pretty common in other tools.

Well, it's pretty common in git too. But in git, the notion of "branch" 
really has been made so cheap that it's basically a no-op.

The "overhead" of creating a branch is literally the cost of writing one 
(small) file.

> In fact, this is the natural operation for the basis of something like
> git-bisect.

Right. And "git bisect" very much does exactly that. It creates a 
temporary branch for bisection (the branch is called "bisect", one of the 
less confusing naming decisions in git ;)

That's really my point. It all boils down to the same three operations: 
"git branch", "git checkout" and "git reset".

In fact, if you look into git-bisect, you'll notice that it doesn't even 
use "git reset" internally. It _literally_ creates a new branch (which it 
does by hand for some strange reason, but never mind) called "new-bisect", 
and then does "git checkout new-bisect" followed by renaming the branch 
back to "bisect" (which it again does by hand).

So "git bisect" may actually get its hands dirty by knowing a bit too much 
about the internal workings of git branches, but conceptually, it really 
does just

	git checkout -b new-bisect <newrev>

to switch its state around.

> But I'd still like to be able to do this without having to invent a
> fake branch name, without the ability to accidentally commit on the
> fake branch, and without the possibility of accidentally leaving those
> commits dangling the next time I seek somewhere else.

Pasky did this before the "multi-branch" thing was common, and calls it 
"cg-seek". 

I think that does exactly what you ask for, I just don't really see the 
point. The downside of cg-seek is that you're really really limited to 
what you can do with it.

For example, it may be "overhead" to have a dummy branch for bisection, 
but it means (for example) that you can actually do real work on the point 
that "git bisect" points you to.

For example, if you hit a compile error, you can _literally_ fix that 
compile error AND COMMIT that state, and when you then mark that commit 
"good" or "bad" when you continue to bisect, bisection will actually do 
the right thing. Something that would be impossible in a "seek" 
environment, where you don't have a branch that you can do development on.

I realize that when you come from an environment where branches are big 
things, this is kind of strange. But in git, a branch is literally a 
single file that is 41 bytes in size. That's it. No more, no less.

		Linus

Re: several quick questions

[Petr Baudis]

Dear diary, on Tue, Feb 14, 2006 at 09:40:24PM CET, I got a letter
where Linus Torvalds <torvalds@osdl.org> said that...
> On Tue, 14 Feb 2006, Carl Worth wrote:
> > But I'd still like to be able to do this without having to invent a
> > fake branch name, without the ability to accidentally commit on the
> > fake branch, and without the possibility of accidentally leaving those
> > commits dangling the next time I seek somewhere else.
> 
> Pasky did this before the "multi-branch" thing was common, and calls it 
> "cg-seek". 
> 
> I think that does exactly what you ask for, I just don't really see the 
> point. The downside of cg-seek is that you're really really limited to 
> what you can do with it.
> 
> For example, it may be "overhead" to have a dummy branch for bisection, 
> but it means (for example) that you can actually do real work on the point 
> that "git bisect" points you to.
> 
> For example, if you hit a compile error, you can _literally_ fix that 
> compile error AND COMMIT that state, and when you then mark that commit 
> "good" or "bad" when you continue to bisect, bisection will actually do 
> the right thing. Something that would be impossible in a "seek" 
> environment, where you don't have a branch that you can do development on.

That's a neat idea - I like this. I just tweaked cg-commit -f so that it
will now override the cg-seek block, with a warning that you should be
content about your commit being thrown away.

Really, except this blocking restriction (which is really a check for a
non-empty .git/blocked file), cg-seek does exactly the fake branch
thing, as you actually persuaded me to do. So you are on a dedicated
seeking branch and theoretically you can do development on it - it's
only too easy to lose the commits.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe.  -- Douglas Adams

Re: several quick questions

[Carl Worth]

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

On Tue, 14 Feb 2006 12:40:24 -0800 (PST), Linus Torvalds wrote:
>
> That's really my point. It all boils down to the same three operations: 
> "git branch", "git checkout" and "git reset".

Yes. I understand that much.

> I think that does exactly what you ask for, I just don't really see the 
> point. The downside of cg-seek is that you're really really limited to 
> what you can do with it.

Well, I think it would be useful to generalize and export what
git-bisect currently does even if there are no limitations added to
it. If nothing else, it's a tiny bit of sugar to allow exploring the
tree without having to invent a branch name first.

So I'd be happy with "git seek" even if git-commit didn't refuse to
commit on the seek branch, (but I still think that limitation makes
sense---see below).

> For example, if you hit a compile error, you can _literally_ fix that 
> compile error AND COMMIT that state, and when you then mark that commit 
> "good" or "bad" when you continue to bisect, bisection will actually do 
> the right thing. Something that would be impossible in a "seek" 
> environment, where you don't have a branch that you can do
> development on.

The only difference in the "seek" case would be that you would be
required to create a branch before committing, right?

And this would have the benefit of not leaving the commit object
dangling after continuing the bisect, wouldn't it?

You've pointed out that branches are free in terms of what git has to
do. I'm saying that they're not free for the user who bears the cost
of inventing a name. And in the case of any commit-while-seeking, it's
at the time of the commit itself that the user has enough information
to invent a useful name, not prior to seeking, (when the user is still
trying to figure things out).

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: several quick questions

[Junio C Hamano]

Carl Worth <cworth@cworth.org> writes:

> You've pointed out that branches are free in terms of what git has to
> do. I'm saying that they're not free for the user who bears the cost
> of inventing a name. And in the case of any commit-while-seeking, it's
> at the time of the commit itself that the user has enough information
> to invent a useful name, not prior to seeking, (when the user is still
> trying to figure things out).

I think this is a very valid point and I am happy to accept a
workable proposal (does not have to be a working patch, but a
general semantics that covers most of if not all the corner
cases).

[PATCH] New git-seek command with documentation and test.

[Carl Worth]

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

Add git-seek which allows for temporary excursions through the
revision history. With "git seek <revision>" one gets a working tree
corresponding to <revision>. When done with the excursion "git seek"
returns back to the original branch from where the first seek began.

Signed-off-by: Carl Worth <cworth@cworth.org>

---

 git-seek could be used as a new basis for git-bisect. This patch does
 not do that, but even so, git-bisect and git-seek should play nicely
 with each other, (in the sense that either will refuse to do anything
 if .git/head-name already exists).

 On Tue, 14 Feb 2006 14:39:34 -0800, Junio C Hamano wrote:
 > Carl Worth <cworth@cworth.org> writes:
 > > [arguments in favor of a new git-seek] 
 > 
 > I think this is a very valid point and I am happy to accept a
 > workable proposal (does not have to be a working patch, but a
 > general semantics that covers most of if not all the corner
 > cases).
 
 I had planned to just let this drop as my original need was some
 historical exploration that I've already finished. But now I've found
 a common use case in my everyday workflow that could benefit from
 git-seek. Here it is:
 
 I receive a bug-fix patch that updates a test case to demonstrate the
 bug. I can apply both the fix and the test case and see it succeed.
 But what I really want to do is first commit the test case, see it
 fail, and only then commit the fix and see the test now succeed.  I'd
 also like the history to reflect that order. So what I do is:
 
 	$ git-am
 	$ git update-index test.c ; git commit -m "Update test"
 	$ git update-index buggy.c ; git commit -m "Fix bug"
 
 At that point, without git-seek I can get by with:
 
 	$ git checkout -b tmp HEAD^
 	$ make check # to see failure
 	$ git checkout <branch_I_was_on_to_begin_with>
 	$ git branch -d tmp # easy to forget, but breaks the next time otherwise
 	$ make check # to see success
 
 But what I'd really like to do, (and can with the attached patch), is:
 
 	$ git seek HEAD^
 	$ make check # to see failure
 	$ git seek
 	$ make check # to see success
 
 This avoids me having to: 1) invent a throwaway name, 2) remember the
 branch I started on, 3) remember to actually throwaway the temporary
 branch.

 I've documented git-seek quite carefully and added a test that tries
 to cover every documented failure mode.

 -Carl

 .gitignore                 |    1 
 Documentation/git-seek.txt |   44 +++++++++++++++++++++
 Makefile                   |    4 +-
 git-seek.sh                |   94 ++++++++++++++++++++++++++++++++++++++++++++
 t/t3800-seek.sh            |   82 ++++++++++++++++++++++++++++++++++++++
 5 files changed, 223 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/git-seek.txt
 create mode 100644 git-seek.sh
 create mode 100755 t/t3800-seek.sh

2656ffb6e3fcbd9443c22b4675b13f23c031600e
diff --git a/.gitignore b/.gitignore
index 94f66d5..55484b0 100644
--- a/.gitignore
+++ b/.gitignore
@@ -85,6 +85,7 @@ git-rev-list
 git-rev-parse
 git-revert
 git-rm
+git-seek
 git-send-email
 git-send-pack
 git-sh-setup
diff --git a/Documentation/git-seek.txt b/Documentation/git-seek.txt
new file mode 100644
index 0000000..cb5c13d
--- /dev/null
+++ b/Documentation/git-seek.txt
@@ -0,0 +1,44 @@
+git-bisect(1)
+=============
+
+NAME
+----
+git-seek - Provide a temporary excursion through the revision history.
+
+
+SYNOPSIS
+--------
+'git seek' [<revision>]
+
+DESCRIPTION
+-----------
+When given a <revision>, git-seek updates the files in the working
+tree to the state of the given revision. It will do this by performing
+a checkout of <revision> to a new branch named "seek", or by resetting
+the seek branch if it already exists.
+
+When run with with no <revision> argument, git-seek will return to the
+original branch from which the initial git-seek operation was
+performed, (this original branch name is saved in $GIT_DIR/head-name).
+
+git-seek refuses to do anything if the working tree or index are
+modified with respect to HEAD. If you want to carry modifications
+around, use git-checkout rather than git-seek.
+
+git-seek will also fail if GIT_DIR/head-name exists when a seek is not
+already in progress, or if a seek branch already exists that is not a
+subset of the current branch, (that is, if it has unmerged commits).
+
+Author
+------
+Written by Carl Worth <cworth@cworth.org>, based on git-bisect by
+Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+-------------
+Documentation by Carl Worth and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Makefile b/Makefile
index 8e6bbce..f3383d8 100644
--- a/Makefile
+++ b/Makefile
@@ -120,8 +120,8 @@ SCRIPT_SH = \
 	git-merge-one-file.sh git-parse-remote.sh \
 	git-prune.sh git-pull.sh git-push.sh git-rebase.sh \
 	git-repack.sh git-request-pull.sh git-reset.sh \
-	git-resolve.sh git-revert.sh git-rm.sh git-sh-setup.sh \
-	git-tag.sh git-verify-tag.sh git-whatchanged.sh \
+	git-resolve.sh git-revert.sh git-rm.sh git-seek.sh \
+	git-sh-setup.sh git-tag.sh git-verify-tag.sh git-whatchanged.sh \
 	git-applymbox.sh git-applypatch.sh git-am.sh \
 	git-merge.sh git-merge-stupid.sh git-merge-octopus.sh \
 	git-merge-resolve.sh git-merge-ours.sh git-grep.sh \
diff --git a/git-seek.sh b/git-seek.sh
new file mode 100644
index 0000000..26f0b76
--- /dev/null
+++ b/git-seek.sh
@@ -0,0 +1,94 @@
+#!/bin/sh
+
+USAGE='[<revision>]'
+LONG_USAGE='git-seek provides a temporary excursion through the revision history.
+
+When given a <revision>, git-seek updates the files in the working
+tree to the state of the given revision. It will do this by performing
+a checkout of <revision> to a new branch named "seek", or by resetting
+the seek branch if it already exists.
+
+When run with with no <revision> argument, git-seek will return to the
+original branch from which the initial git-seek operation was
+performed, (this original branch name is saved in $GIT_DIR/head-name).
+
+git-seek refuses to do anything if the working tree or index are
+modified with respect to HEAD. If you want to carry modifications
+around, use git-checkout rather than git-seek.
+
+git-seek will also fail if GIT_DIR/head-name exists when a seek is not
+already in progress, or if a seek branch already exists that is not a
+subset of the current branch, (that is, if it has unmerged commits).'
+
+. git-sh-setup
+
+# Does $GIT_DIR/head-name contain the given revision
+# We use git-rev-parse to correctly resolve any aliases through references.
+head_name_contains() {
+	old_head=$(git-rev-parse $(cat "$GIT_DIR/head-name"))
+	new_head=$(git-rev-parse "$1")
+	[ "$old_head" = "$new_head" ]
+}
+
+seek_to() {
+	target="$1"
+	head=$(GIT_DIR="$GIT_DIR" git-symbolic-ref HEAD) ||
+	die "Bad HEAD - I need a symbolic ref"
+	case "$head" in
+	refs/heads/seek)
+		# An explicit seek to head-name is treated as a reset
+		if head_name_contains "$target"; then
+			seek_reset
+		else
+			git reset --hard $target
+		fi
+		;;
+	refs/heads/*)
+		[ -s "$GIT_DIR/head-name" ] && die "Will not seek: $GIT_DIR/head-name is already in use"
+		echo "$head" | sed 's#^refs/heads/##' >"$GIT_DIR/head-name"
+		if git-rev-parse --verify seek >&/dev/null ; then
+			git-branch -d seek || exit
+		fi
+		git checkout -b seek $target
+		;;
+	*)
+		die "Bad HEAD - strange symbolic ref"
+		;;
+	esac
+}
+
+seek_reset() {
+	if [ -s "$GIT_DIR/head-name" ]; then
+		source=$(cat "$GIT_DIR/head-name") || exit
+	else
+		echo >&2 "No seek is in progress: returning to master."
+		source 
+	fi
+	git checkout "$source" &&
+	(git branch -d seek || err=$? ; git checkout seek ; exit $err) &&
+	rm -f "$GIT_DIR/head-name"
+}
+
+head=$(git-rev-parse --verify HEAD) || die "You do not have a valid HEAD"
+
+files_dirty=$(git-diff-index --name-only $head) || exit
+index_dirty=$(git-diff-index --cached --name-only $head) || exit
+if [ "$files_dirty" -o "$index_dirty" ]; then
+	die "Will not seek from a dirty state:
+	${index_dirty:+(dirty in index: $index_dirty)} ${files_dirty:+(dirty in working tree: $files_dirty)}
+You may want to commit these changes first or perhaps use git-checkout
+-m instead of git-seek."
+fi
+
+case "$#" in
+0)
+	seek_reset
+	;;
+1)
+	seek_to "$1"
+	;;
+*)
+	usage 
+	;;
+esac
+
diff --git a/t/t3800-seek.sh b/t/t3800-seek.sh
new file mode 100755
index 0000000..e5d8f90
--- /dev/null
+++ b/t/t3800-seek.sh
@@ -0,0 +1,82 @@
+#!/bin/sh
+#
+# Copyright (c) 2006 Carl D. Worth
+#
+
+test_description='Test of git-seek and all documented failure modes.'
+
+. ./test-lib.sh
+
+echo "first" > file
+git-add file && git-commit -m "add first revision of file"
+echo "second" > file
+git-commit -a -m "commit second revision"
+git tag second
+echo "third" > file
+git-commit -a -m "commit third revision"
+
+verify_revision() {
+    contents=$(cat file) && [ "$contents" = "$1" ]
+}
+
+test_expect_success \
+    'Test of initial "git-seek <revision>"' \
+    'git-seek HEAD~2 && verify_revision first'
+
+test_expect_success \
+    'Test of "git-seek <revision>" during seek' \
+    'git-seek second && verify_revision second'
+
+test_expect_success \
+    'Test that "git-seek" returns to starting point and resets seek state' \
+    'git-seek && verify_revision third &&
+     [ ! -f .git/refs/seek ] &&
+     [ ! -f .git/head-name ]'
+
+test_expect_success \
+    'Test that "git-seek master" also resets seek state' \
+    'git seek HEAD^1 &&
+     git seek master && verify_revision third &&
+     [ ! -f .git/refs/seek ] &&
+     [ ! -f .git/head-name ]'
+
+test_expect_success \
+    'Test that "git-seek <revision>" which aliases to master also resets seek state' \
+    'source=$(git-rev-parse HEAD) &&
+     git seek HEAD^1 &&
+     git seek $source && verify_revision third &&
+     [ ! -f .git/refs/seek ] &&
+     [ ! -f .git/head-name ]'
+
+echo modified > file
+test_expect_failure \
+    'Test that git-seek fails with local file modification' \
+    'git-seek HEAD^'
+git-reset --hard master
+
+echo modified > file
+git-update-index file
+test_expect_failure \
+    'Test that git-seek fails with a modified index' \
+    'git-seek HEAD^'
+git-reset --hard master
+
+echo master > .git/head-name
+test_expect_failure \
+    'Test that git-seek fails when .git/head-name exists and not seeking' \
+    'git-seek HEAD^'
+rm .git/head-name
+
+git-seek HEAD^
+echo new > new; git-add new; git-commit -m "Commit new file to seek branch"
+test_expect_failure \
+    'Test that git-seek fails when there are unmerged commits on seek branch' \
+    'git-seek'
+
+git checkout master
+git-pull . seek >&/dev/null
+test_expect_success \
+    'Test that git-seek works again after merging in the seek branch' \
+    'git-seek'
+
+test_done
-- 
1.2.3.g207a-dirty





[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] New git-seek command with documentation and test.

[J. Bruce Fields]

On Thu, Feb 23, 2006 at 12:31:25PM -0800, Carl Worth wrote:
> --- /dev/null
> +++ b/Documentation/git-seek.txt
> @@ -0,0 +1,44 @@
> +git-bisect(1)
> +=============

Oops.

> +When given a <revision>, git-seek updates the files in the working
> +tree to the state of the given revision. It will do this by performing
> +a checkout of <revision> to a new branch named "seek", or by resetting
> +the seek branch if it already exists.

I wonder if its a good idea to silently reset a branch named with a
short common word?

> +LONG_USAGE='git-seek provides a temporary excursion through the revision history.
> +
> +When given a <revision>, git-seek updates the files in the working
> +tree to the state of the given revision. It will do this by performing
> +a checkout of <revision> to a new branch named "seek", or by resetting
> +the seek branch if it already exists.

These long usage texts with language duplicated from the man pages seem
like they'd be asking for bit-rot, when an update happens in one place
but not the other.  I dunno.

--b.

[PATCH] git-seek: Eliminate spurious warning. Fix errant reference to git-bisect in docs.

[Carl Worth]

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

This fixed a bug that would cause "git seek" to mistakenly try to
checkout the seek branch just after deleting it. Of course, that would
never work, but fixing the bug does squelch the annoying error caused
by the bug.

Also fix an errant title of "git-bisect" in the git-seek documentation.

---

On Thu, 23 Feb 2006 19:18:48 -0500, "J. Bruce Fields" wrote:
> On Thu, Feb 23, 2006 at 12:31:25PM -0800, Carl Worth wrote:
> > +git-bisect(1)
> > +=============
> 
> Oops.

Thanks.

> I wonder if its a good idea to silently reset a branch named with a
> short common word?

It at least takes some care not to leave commits dangling when doing
this, (the seek branch must at least be a subset of the current
HEAD). I was pretty much following the lead of git-bisect here,
(though "bisect" is definitely a touch longer and less common than
"seek").

If it would be preferred to hide such "internal" branch names behind
some unlikely symbol or such, that would obviously be easy to do.

As is, the seek branch is at least documented, and rather well
advertised in operation, (for example, returning with "git seek"
reported "Deleted branch seek.").

> These long usage texts with language duplicated from the man pages seem
> like they'd be asking for bit-rot, when an update happens in one place
> but not the other.  I dunno.

Yeah, I don't know. Again, I was just imitating things I'd seen
elsewhere.

 Documentation/git-seek.txt |    4 ++--
 git-seek.sh                |    2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

43f042982c26859b6b7f6055fc03dda8e89f4e70
diff --git a/Documentation/git-seek.txt b/Documentation/git-seek.txt
index cb5c13d..513dbc7 100644
--- a/Documentation/git-seek.txt
+++ b/Documentation/git-seek.txt
@@ -1,5 +1,5 @@
-git-bisect(1)
-=============
+git-seek(1)
+===========
 
 NAME
 ----
diff --git a/git-seek.sh b/git-seek.sh
index 26f0b76..921c014 100644
--- a/git-seek.sh
+++ b/git-seek.sh
@@ -65,7 +65,7 @@ seek_reset() {
 		source 
 	fi
 	git checkout "$source" &&
-	(git branch -d seek || err=$? ; git checkout seek ; exit $err) &&
+	(git branch -d seek || (err=$? ; git checkout seek ; exit $err)) &&
 	rm -f "$GIT_DIR/head-name"
 }
 
-- 
1.2.3.g2656-dirty


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] git-seek: Eliminate spurious warning. Fix errant reference to git-bisect in docs.

[Junio C Hamano]

Carl Worth <cworth@cworth.org> writes:

>> I wonder if its a good idea to silently reset a branch named with a
>> short common word?
>
> It at least takes some care not to leave commits dangling when doing
> this, (the seek branch must at least be a subset of the current
> HEAD). I was pretty much following the lead of git-bisect here,
> (though "bisect" is definitely a touch longer and less common than
> "seek").

IIUC Cogito seems to use cg-seek-point or something long and
unusual like that...

Re: [PATCH] New git-seek command with documentation and test.

[Andreas Ericsson]

Carl Worth wrote:
> Add git-seek which allows for temporary excursions through the
> revision history. With "git seek <revision>" one gets a working tree
> corresponding to <revision>. When done with the excursion "git seek"
> returns back to the original branch from where the first seek began.
> 

I've said it before, and I'll say it again. This tool provides less 
flexibility and much less power than "git checkout -b branch 
<commit-ish>" (although it would be nice to have '-o' for 'overwrite 
existing branch' as an argument to git checkout)

> Signed-off-by: Carl Worth <cworth@cworth.org>
> 
> ---
>  
>  I had planned to just let this drop as my original need was some
>  historical exploration that I've already finished. But now I've found
>  a common use case in my everyday workflow that could benefit from
>  git-seek. Here it is:
>  
>  I receive a bug-fix patch that updates a test case to demonstrate the
>  bug. I can apply both the fix and the test case and see it succeed.
>  But what I really want to do is first commit the test case, see it
>  fail, and only then commit the fix and see the test now succeed.  I'd
>  also like the history to reflect that order. So what I do is:
>  
>  	$ git-am
>  	$ git update-index test.c ; git commit -m "Update test"
>  	$ git update-index buggy.c ; git commit -m "Fix bug"
>  
>  At that point, without git-seek I can get by with:
>  
>  	$ git checkout -b tmp HEAD^
>  	$ make check # to see failure
>  	$ git checkout <branch_I_was_on_to_begin_with>
>  	$ git branch -d tmp # easy to forget, but breaks the next time otherwise
>  	$ make check # to see success
>  
>  But what I'd really like to do, (and can with the attached patch), is:
>  
>  	$ git seek HEAD^
>  	$ make check # to see failure
>  	$ git seek
>  	$ make check # to see success
>  
>  This avoids me having to:
> 1) invent a throwaway name,

All programmers have at least five throwaway names that are only ever 
used as such (mine are, in order of precedence, foo, bar, tmp, fnurg, 
sdf and asd).

> 2) remember the branch I started on,

With topic branches, you need to pick more careful topic names. Without 
topic branches you're always on "master". Surely you know what the 
patches touch, so you know what branch they should be in.

> 3) remember to actually throwaway the temporary branch.
> 

This isn't always a bad thing, since you after applying some patch or 
other decide you want to go back to this point in history, or want to 
keep the point so you can show the author some problem or other with the 
patch. With git-seek you'll then have to remember the hard-to-learn 
SHA1, or how far below HEAD or some other easily remembered point in 
history it is. In that case, you need to remember to add the 
branch/tag/whatever to where you seeked rather than just go on with the 
work. Removing a branch later is simple. Finding the right spot to 
create it later can be trouble-some.

If I had a vote, I'd say no to this patch, and to this tool entirely.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: [PATCH] New git-seek command with documentation and test.

[Junio C Hamano]

Andreas Ericsson <ae@op5.se> writes:

> I've said it before, and I'll say it again. This tool provides less
> flexibility and much less power than "git checkout -b branch
> <commit-ish>" (although it would be nice to have '-o' for 'overwrite
> existing branch' as an argument to git checkout)

True, but assembly provides more flexibility than higher level
languages and you need to strike a balance between power and
usability.

The real question is if the structure the tool enforces to your
workflow is simply being a straight-jacket or helping an average
user to avoid common mistakes.

One occasion I've felt the need for "seek" like feature was when
starting to bisect.  You usually notice breakage, so you can
start with "git bisect bad HEAD", but then what next?  You
usually are not absolutely sure which one _was_ working the last
time.

If I had a seek, then I could go back to some randomly chosen
version to try it out, going back until I find a good one.

Maybe "git bisect try $committish" would be a good addition.  We
could live without it (we can just say "git reset --hard
$committish"), but it can be a bit more than just that.  If
given committish is known to be good or bad, we could remind the
user what she said the last time, and offer a chance to take it
back.  That is, (1) if the given $committish is an ancestor of
existing good one, list those good ones and ask "do you mean you
are not sure if they are good anymore, and retry the
bisection?"  If yes, delete those good-* refs; (2) if the given
$committish is a descendant of a bad one, show it and ask "do
you mean you are not sure if they are good anymore, and retry
the bisection?"  If yes, remove the existing bad ref.  In any
case, "reset --hard" to it after user responds.

Other than that, I haven't felt a need for seek-like feature;
instead, I make liberal use of throw-away branches.

Re: [PATCH] New git-seek command with documentation and test.

[Carl Worth]

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

On Fri, 24 Feb 2006 11:00:29 +0100, Andreas Ericsson wrote:
> 
> I've said it before, and I'll say it again. This tool provides less 
> flexibility and much less power than "git checkout -b branch 
> <commit-ish>"

Yes, that's by design. It's not intended to be a replacement for git
checkout -b. It's intended to be easier to use than that when its
purpose fits what you want to to.

> > 1) invent a throwaway name,
> 
> All programmers have at least five throwaway names that are only ever 
> used as such (mine are, in order of precedence, foo, bar, tmp, fnurg, 
> sdf and asd).

Sure, and when I use "git checkout -b" I have to keep trying these
linearly until I found one that is available. That's what I've been
doing, and it's painful enough that I wrote this. (Though yes,
something like checkout -o would help here).

> > 2) remember the branch I started on,
> 
> With topic branches, you need to pick more careful topic names. Without 
> topic branches you're always on "master". Surely you know what the 
> patches touch, so you know what branch they should be in.

I almost put "remember" in quotation marks. Obviously I know what I'm
working on. It's more a matter of just having to type the name, (I do
use very careful topic names so they tend to be longish). Having
tab-completion for git-checkout would help here.

So (1) and (2) have potential workarounds, but neither exists, and
even then they would still be harder to use than git-seek.

> > 3) remember to actually throwaway the temporary branch.
> 
> This isn't always a bad thing, since you after applying some patch or 
> other decide you want to go back to this point in history,

That assumes that I've made any change though. If you're going back in
the past to make changes, then "git checkout -b" is the right thing to
use. It's when you're not planning to make changes, but just exploring
the past that "git seek" is helpful.

So (3) is just extra pain when using git-seek for what its designed to
be good for, (exploring history when not planning on writing to it).

But note that the git-seek I've implemented *does* provide a writable
branch, so if you discover that you do want to commit something, then
that's always available. Linus gave compelling arguments for this.

>                In that case, you need to remember to add the 
> branch/tag/whatever to where you seeked rather than just go on with the 
> work. Removing a branch later is simple. Finding the right spot to 
> create it later can be trouble-some.

Yes. And that's why git-seek stops and warns you before it leaves
dangling commits by moving the branch. (Though it might make sense to
add a -f option to force it to seek regardless of the things it
currently balks at.)

> If I had a vote, I'd say no to this patch, and to this tool entirely.

One argument in favor is that seeking already exists in git privately
within git-bisect. Exposing git-seek makes it easier to code new
operations along the lines of git-bisect. It's certainly consistent
with git's current implementation strategy to have the more primitive
pieces of complex operations exported and available.

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] New git-seek command with documentation and test.

[Johannes Schindelin]

Hi,

On Fri, 24 Feb 2006, Carl Worth wrote:

> On Fri, 24 Feb 2006 11:00:29 +0100, Andreas Ericsson wrote:
> > 
> > I've said it before, and I'll say it again. This tool provides less 
> > flexibility and much less power than "git checkout -b branch 
> > <commit-ish>"
> 
> Yes, that's by design. It's not intended to be a replacement for git
> checkout -b.

I do not really understand why.

git-seek shares so many characteristics with git-seek, you could make 
git-seek just another command line option to checkout (like "--temporary" 
and "--go-back").

Hth,
Dscho

Re: [PATCH] New git-seek command with documentation and test.

[J. Bruce Fields]

On Fri, Feb 24, 2006 at 10:48:46PM +0100, Johannes Schindelin wrote:
> git-seek shares so many characteristics with git-seek, you could make 
> git-seek just another command line option to checkout (like "--temporary" 
> and "--go-back").

Well, as a user interface, git-seek seems a bit simpler (e.g., easier to
remember).--b.

Re: several quick questions

[Josef Weidendorfer]

On Tuesday 14 February 2006 21:10, you wrote:
> How about "git seek" for doing the operations above, and using some
> reserved branch name, (say "seek"). Then, git-bisect could easily be
> built on that, and git-commit could respect the "seek" name and refuse
> to commit to it, (could tell the user how to create the branch
> necessary to commit from the current point).

Why not allow something like

	git-checkout master~5

which implicitly does create a read-only branch "seek-point"?
I do not think that it is important to remember the branch name you seek
from.

A branch could be marked readonly by above command with

	chmod a-w .git/refs/heads/seek

And git-commit should refuse to commit on a readonly ref, telling
the user to create a writable branch before with "git-branch new".

This would also help "cg-seek" to prohibit the user to commit on
"cg-seek-point" via "git-commit" (by setting cg-seek-point read-only).

BTW, "origin" (and any local branch that tracks a remote one) should
be set to readonly this way to signal that these are not developer
branches.

Josef

Re: several quick questions

[Junio C Hamano]

Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:

> Why not allow something like
>
> 	git-checkout master~5
>
> which implicitly does create a read-only branch "seek-point"?

Now what does "git-checkout branch" mean?  Does it switch to the
branch, or does it force tip of seek-point to be the tip of
branch and switch to seek-point branch?  More interestingly,
what does "git-checkout seek-point" mean? 

If we _were_ to do something like cg-seek where an implicit
throw-away branch is used, you at least need a way to
disambiguate these cases, and "git seek" originally suggested is
far clearer than what you said above.

Having said that, I am not convinced in either way, though.

> A branch could be marked readonly by above command with
>
> 	chmod a-w .git/refs/heads/seek

I do not think that would work.  Have you tried it?

> And git-commit should refuse to commit on a readonly ref, telling
> the user to create a writable branch before with "git-branch new".

Now, read-only ref does not interest me, but "do not commit on
top of this yourself, only fast-forward from somewhere else is
allowed" may be useful, for the reason why you mentioned
"origin".

Re: several quick questions

[Josef Weidendorfer]

On Tuesday 14 February 2006 22:40, you wrote:
> Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> 
> > Why not allow something like
> >
> > 	git-checkout master~5
> >
> > which implicitly does create a read-only branch "seek-point"?
> 
> Now what does "git-checkout branch" mean?  Does it switch to the
> branch, or does it force tip of seek-point to be the tip of
> branch and switch to seek-point branch?  More interestingly,
> what does "git-checkout seek-point" mean? 

You are right; it would get quite confusing.
But perhaps the current error message

  git checkout: you need to specify a new branch name

should be a little bit more explaining by appending

  "... to switch to for being able to checkout the requested revision"

> Having said that, I am not convinced in either way, though.

Me too. Specifying a branch name is easy enough.

> > And git-commit should refuse to commit on a readonly ref, telling
> > the user to create a writable branch before with "git-branch new".
> 
> Now, read-only ref does not interest me, but "do not commit on
> top of this yourself, only fast-forward from somewhere else is
> allowed" may be useful, for the reason why you mentioned
> "origin".

Yes. The idea to make the ref readonly to specify this intent was
a quick (not so good) idea.

Still, being able to specify that you can not commit on some branch
(as you said) is very useful to prohibit doing things by accident.
.git/config does not sound very good for such a thing, especially
if there could be other branch-specific properties in the future.

Josef

Re: several quick questions

[Junio C Hamano]

Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:

> On Tuesday 14 February 2006 22:40, you wrote:
>> Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
>> 
>> > Why not allow something like
>> >
>> > 	git-checkout master~5
>> >
>> > which implicitly does create a read-only branch "seek-point"?
>> 
>> Now what does "git-checkout branch" mean?  Does it switch to the
>> branch, or does it force tip of seek-point to be the tip of
>> branch and switch to seek-point branch?  More interestingly,
>> what does "git-checkout seek-point" mean? 
>
> You are right; it would get quite confusing.
> But perhaps the current error message
>
>   git checkout: you need to specify a new branch name
>
> should be a little bit more explaining by appending
>
>   "... to switch to for being able to checkout the requested revision"

While we are on the subject of improving the error message to
better guide users in a likely-to-be-what-he-meant direction,
there is another confusing message (I am assuming you are
interested in this enough to come up with a patch to fix that
"... to switch to ..." thing):

	$ git checkout -b test v2.6.10

The user wanted to create a new branch test based on tag
v2.6.10, alas that tag does not exist.  We give quite confusing
error message because we are confused that the user meant to
checkout only "./v2.6.10" file and that operation and switching
branches are incompatible.

[PATCH] More useful/hinting error messages in git-checkout

[Josef Weidendorfer]

Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
---

On Tuesday 14 February 2006 23:26, you wrote:
>
> 	$ git checkout -b test v2.6.10
> 
> The user wanted to create a new branch test based on tag
> v2.6.10, alas that tag does not exist.  We give quite confusing
> error message because we are confused that the user meant to
> checkout only "./v2.6.10" file and that operation and switching
> branches are incompatible.

Does this patch clarify the error condition?

Josef


 git-checkout.sh |   13 ++++++++++---
 1 files changed, 10 insertions(+), 3 deletions(-)

d15e024c0bd07a2f0dad6e2729e2681df374c8e6
diff --git a/git-checkout.sh b/git-checkout.sh
index 6a87c71..b7d892d 100755
--- a/git-checkout.sh
+++ b/git-checkout.sh
@@ -22,7 +22,7 @@ while [ "$#" != "0" ]; do
 		[ -e "$GIT_DIR/refs/heads/$newbranch" ] &&
 			die "git checkout: branch $newbranch already exists"
 		git-check-ref-format "heads/$newbranch" ||
-			die "we do not like '$newbranch' as a branch name."
+			die "git checkout: we do not like '$newbranch' as a branch name."
 		;;
 	"-f")
 		force=1
@@ -75,9 +75,15 @@ done
 
 if test "$#" -ge 1
 then
+	hint=
+	if test "$#" -eq 1
+	then
+		hint="
+Did you intend to checkout '$@' which can not be resolved as commit?"
+	fi
 	if test '' != "$newbranch$force$merge"
 	then
-		die "updating paths and switching branches or forcing are incompatible."
+		die "git checkout: updating paths is incompatible with switching branches/forcing$hint"
 	fi
 	if test '' != "$new"
 	then
@@ -117,7 +123,8 @@ fi
 
 [ -z "$branch$newbranch" ] &&
 	[ "$new" != "$old" ] &&
-	die "git checkout: you need to specify a new branch name"
+	die "git checkout: to checkout the requested commit you need to specify 
+              a name for a new branch which is created and switched to"
 
 if [ "$force" ]
 then
-- 
1.2.0.g719b

Re: several quick questions

[Andreas Ericsson]

Junio C Hamano wrote:
> Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> 
> 
>>Why not allow something like
>>
>>	git-checkout master~5
>>
>>which implicitly does create a read-only branch "seek-point"?
> 
> 
> Now what does "git-checkout branch" mean?  Does it switch to the
> branch, or does it force tip of seek-point to be the tip of
> branch and switch to seek-point branch?  More interestingly,
> what does "git-checkout seek-point" mean? 
> 
> If we _were_ to do something like cg-seek where an implicit
> throw-away branch is used, you at least need a way to
> disambiguate these cases, and "git seek" originally suggested is
> far clearer than what you said above.
> 

Nah. What's the point of having another protected name. Just allow

	$ git checkout -b discard HEAD~15

and we're good to go.

> Having said that, I am not convinced in either way, though.
> 
> 
>>A branch could be marked readonly by above command with
>>
>>	chmod a-w .git/refs/heads/seek
> 
> 
> I do not think that would work.  Have you tried it?
> 

It wouldn't on cygwin, for one. I'm against having things work 
differently on different platforms. If nothing else it usually worsens 
the bitrot that always happens to documentation.

> 
>>And git-commit should refuse to commit on a readonly ref, telling
>>the user to create a writable branch before with "git-branch new".
> 
> 
> Now, read-only ref does not interest me, but "do not commit on
> top of this yourself, only fast-forward from somewhere else is
> allowed" may be useful, for the reason why you mentioned
> "origin".
> 

Do my suggestion and you wouldn't have to worry about read-only 
branches, and although merging any changes from it might be more trouble 
than its worth, it might be possible to cherry-pick the commit rather 
than reverting and re-applying it.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: several quick questions

[Johannes Schindelin]

Hi,

On Wed, 15 Feb 2006, Andreas Ericsson wrote:

> What's the point of having another protected name. Just allow
> 
> 	$ git checkout -b discard HEAD~15
> 
> and we're good to go.

Last time I checked (2 hours ago) it did exactly what you want it to.

Hth,
Dscho

Re: several quick questions

[Andreas Ericsson]

Johannes Schindelin wrote:
> Hi,
> 
> On Wed, 15 Feb 2006, Andreas Ericsson wrote:
> 
> 
>>What's the point of having another protected name. Just allow
>>
>>	$ git checkout -b discard HEAD~15
>>
>>and we're good to go.
> 
> 
> Last time I checked (2 hours ago) it did exactly what you want it to.
> 

Heh. You're right. :) Didn't grok that from the man-page. I'm so used to 
seeing <commit-ish> everywhere that when it says "<branch> can be any 
object that refers to a commit" I get confused.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: several quick questions

[Junio C Hamano]

Andreas Ericsson <ae@op5.se> writes:

> Heh. You're right. :) Didn't grok that from the man-page. I'm so used
> to seeing <commit-ish> everywhere that when it says "<branch> can be
> any object that refers to a commit" I get confused.

You are right; the documentation is wrong.  It says

'git-checkout' [-f] [-b <new_branch>] [-m] [<branch>] [<paths>...]

It should have said something like:

git-checkout [ -f | -m ] <branch>    		or
git-checkout [-b <new_branch>] <committish>	or
git-checkout [<committish> | -- ] <paths>...

The first form is to switch to a branch (with flag to say what
to do when conflict can lose local modification); the second
form is to create a new branch out of comittish and switch to
it; and the third is not switching branches but just checking
out named paths out of index or arbitrary comittish (I think any
ent should do but I have not verified it).

Re: several quick questions

[Junio C Hamano]

Andreas Ericsson <ae@op5.se> writes:

> Junio C Hamano wrote:
>
>> Now, read-only ref does not interest me, but "do not commit on
>> top of this yourself, only fast-forward from somewhere else is
>> allowed" may be useful, for the reason why you mentioned
>> "origin".
>
> Do my suggestion and you wouldn't have to worry about read-only
> branches, and although merging any changes from it might be more
> trouble than its worth, it might be possible to cherry-pick the commit
> rather than reverting and re-applying it.

Sorry, is this "do my suggestion" a solution to my "do not
commit on top of this yourself, only fast-forward from somewhere
else is allowed -- e.g. to protect 'origin'" issue, or is it
something completely different?

Re: several quick questions

[Andreas Ericsson]

Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
> 
> 
>>Junio C Hamano wrote:
>>
>>
>>>Now, read-only ref does not interest me, but "do not commit on
>>>top of this yourself, only fast-forward from somewhere else is
>>>allowed" may be useful, for the reason why you mentioned
>>>"origin".
>>
>>Do my suggestion and you wouldn't have to worry about read-only
>>branches, and although merging any changes from it might be more
>>trouble than its worth, it might be possible to cherry-pick the commit
>>rather than reverting and re-applying it.
> 
> 
> Sorry, is this "do my suggestion" a solution to my "do not
> commit on top of this yourself, only fast-forward from somewhere
> else is allowed -- e.g. to protect 'origin'" issue, or is it
> something completely different?
> 

The "git checkout -b foo HEAD~15", which was already supported, although 
I missed that. All programmers have names to use just for throwaway 
variables (never heard "frotz" and "nitfol" before though), so adding 
the burden of selecting a name for the throw-away search branch 
shouldn't be too hard on them. Then it would be possible to commit to 
it, and merge or cherry-pick from it later. It's usually preferrable to 
amend to a broken patch than to revert it completely.

In essence, I claim that git-seek is superfluous and inferior to "git 
checkout -b foo <commit-ish>" and shouldn't be implemented. If anyone 
wants to distribute the source to non-scm people as per a given point in 
the history I think "git tar-tree" works marvelously as is.

The good thing about being past 1.0 in a project is that it's 
feature-complete, or close to. The bad thing is that bloat usually 
starts to happen around 1.1.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: several quick questions

[Junio C Hamano]

Andreas Ericsson <ae@op5.se> writes:

> The good thing about being past 1.0 in a project is that it's
> feature-complete, or close to. The bad thing is that bloat usually
> starts to happen around 1.1.

Thanks -- be kind and stop me whenever somebody else tempts me
to add excess things to the core, please.  Always good to have
adult supervision ;-), eh, voice of sanity.

Re: several quick questions

[Petr Baudis]

Dear diary, on Tue, Feb 14, 2006 at 10:30:11PM CET, I got a letter
where Josef Weidendorfer <Josef.Weidendorfer@gmx.de> said that...
> Why not allow something like
> 
> 	git-checkout master~5
> 
> which implicitly does create a read-only branch "seek-point"?
> I do not think that it is important to remember the branch name you seek
> from.
> 
> A branch could be marked readonly by above command with
> 
> 	chmod a-w .git/refs/heads/seek
> 
> And git-commit should refuse to commit on a readonly ref, telling
> the user to create a writable branch before with "git-branch new".

We just abolished symlinks. Can we afford doing this, from the
portability standpoint?

> This would also help "cg-seek" to prohibit the user to commit on
> "cg-seek-point" via "git-commit" (by setting cg-seek-point read-only).

For now, this is accomplished (in Cogito, but we just introduced this to
git-bisect as well) by creating .git/head-name. This has the advantage
that you know to which branch to return after the seeking is over, and
it also marks the current head "read-only" (in the commit sense) for
Cogito (and git-bisect start).

It is obviously less flexible since it lets you mark only the current
head read-only, but noone asked for more before. ;)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe.  -- Douglas Adams

Re: several quick questions

[Carl Worth]

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

On Tue, 14 Feb 2006 10:10:53 -0800, Carl Worth wrote:
> 
> Is there a more fundamental operation to "put the working files into
> the state of the index"? If that exists, then that combined with
> git-read-tree would give me what I wanted I think.

Oh, I'm blind. I didn't see git-checkout-index, (thanks Kenneth for
mentioning it elsewhere in the thread). So now I've at least got the
recipe I was after:

	git-read-tree <revision>
	git-update-index --replace
	git-checkout-index -a -f -u

And I think that would make for a dandy command to have in git. Any
suggestions for a name?

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: several quick questions

[Linus Torvalds]

On Tue, 14 Feb 2006, Carl Worth wrote:
> 
> Oh, I'm blind. I didn't see git-checkout-index, (thanks Kenneth for
> mentioning it elsewhere in the thread). So now I've at least got the
> recipe I was after:
> 
> 	git-read-tree <revision>
> 	git-update-index --replace
> 	git-checkout-index -a -f -u

This is very very inefficient, because it will replace the old 
index without using the (valid) information that is there from before. 
Resulting in a lot of unnecessary IO..

You may not care for a small project, but for bigger stuff, you're better 
off using more subtle approaches.

Explore using "git-read-tree --reset <revision>" or, perhaps even more 
interesting is "git-read-tree -u -m <oldrev> <newrev>"

> And I think that would make for a dandy command to have in git. Any
> suggestions for a name?

I'd suggest "git reset" as a cool way to say that it "resets" the tree to 
another version ;)

		Linus

Re: several quick questions

[Andreas Ericsson]

Linus Torvalds wrote:
> 
> I'd suggest "git reset" as a cool way to say that it "resets" the tree to 
> another version ;)
> 

OTOH, it would be nifty (and I imagine not particularly hard) to teach 
"git checkout" to check out any revision, and not just a branch.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: several quick questions

[Johannes Schindelin]

Hi,

On Tue, 14 Feb 2006, Andreas Ericsson wrote:

> [...] it would be nifty (and I imagine not particularly hard) to teach 
> "git checkout" to check out any revision, and not just a branch.

You have to have a valid HEAD. So, you can create a throw-away branch 
easily:

	git-checkout -f throw HEAD~56

Hth,
Dscho

Re: several quick questions

[Carl Worth]

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

On Tue, 14 Feb 2006 11:00:44 -0800 (PST), Linus Torvalds wrote:
> > And I think that would make for a dandy command to have in git. Any
> > suggestions for a name?
> 
> I'd suggest "git reset" as a cool way to say that it "resets" the tree to 
> another version ;)

Heh. It also moves a branch name though, and that's the part I don't
want. See my suggestion elsewhere of "git seek". [*]

-Carl

[*] Yes, I appear doomed to be reinventing cogito piecemeal. I got
"seek" from the error message in git-bisect, before I heard about
cg-seek, (as Junio pointed out elsewhere in the thread).

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: several quick questions

[Keith Packard]

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

On Tue, 2006-02-14 at 10:10 -0800, Carl Worth wrote:

> I don't know if it's the original poster's question or not, but an
> operation I don't see in the above is "put the working files into the
> state of a given revision".

I was using:

	 rm -r *
	 rm -f .cvsignore .gitignore
	 git-reset --hard <tag>

to get to a specific tag. Of course, I cloned the repository and did
this in a separate directory; I wanted to make sure nothing 'bad'
happened to my working directory.

Creating a fake branch seemed like a lot more bother.  
-- 
keith.packard@intel.com

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

Re: several quick questions

[Linus Torvalds]

On Tue, 14 Feb 2006, Keith Packard wrote:
>
> I was using:
> 
> 	 rm -r *
> 	 rm -f .cvsignore .gitignore
> 	 git-reset --hard <tag>

Ooh.

Try doing that on a big project, and it will just kill you. You've also 
lost the "top-of-branch" info, but if you're just tracking some other 
tree, that's likely not an issue.

(actually, under Linux, with enough memory, and the git stuff all cached, 
it will perform pretty well, but that's just because the OS does a _lot_ 
to try to hide how expensive it is to re-write everything. And even under 
Linux it will suck in the cold-cache case).

> Creating a fake branch seemed like a lot more bother.  

You'll find that if cairo ever grows bigger, it has huge advantages to 
switch between branches (or any random state, for that matter) without 
having to rewrite it all is a _major_ performance impact.

		Linus

Re: several quick questions

[Keith Packard]

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

On Tue, 2006-02-14 at 11:04 -0800, Linus Torvalds wrote:

> Try doing that on a big project, and it will just kill you. You've also 
> lost the "top-of-branch" info, but if you're just tracking some other 
> tree, that's likely not an issue.

I was validating the cvs import by comparing every tagged version. Trust
me, the git tree-rewriting stage was somewhat faster than the CVS
checkout of the same content. And, as an egg, one often prefers BFI to
finesse. I had trouble figuring out precisely what sequence of commands
were needed to make git-reset --hard happy with existing bits in the
directory.     

-- 
keith.packard@intel.com

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

Cogito turbo-introduction

[Petr Baudis]

I suppose this might be interesting for others (and Google) as well, so
I'm bringing it back to the mailing list...

Dear diary, on Wed, Feb 15, 2006 at 01:26:23AM CET, I got a letter
where Keith Packard <keithp@keithp.com> said that...
> I will see about learning enough cogito to point appropriate people at
> it in place of full-on git exposure.

Actually, everything should be really trivial, since Cogito is very
similar to CVS or SVN in practice. A turbo introduction to Cogito, which
actually proved to be enough to get started fast with the regular work,
was:

	* cg-clone URL to get the stuff
	* cg-commit just like in CVS (but cooler)
	* cg-update just like in CVS (or rather SVN)
	* cg-status to get the status letters produced by cvs update
	  (just like in SVN)
	* cg-diff, cg-log, cg-add, cg-rm just like in CVS (but cooler)

	* After committing for a while, you need to run cg-push
	* Merge commits are perfectly ok, don't mind them; no really,
	  you will get used; in reality, they are cool
	* If you hit conflicts during merge, the software will tell you
	  how to proceed
	* If you need something different / more advanced, look it up
	  in cg-help list (there is actually significantly less Cogito
	  commands to go through than in CVS, yet in most areas Cogito
	  is much more powerful)
	* If you are confused about the distributed concept or want to
	  learn about branching, try Cogito README

I've been trying to design Cogito's UI pretty carefully to really
absolutely minimize the learning curve from CVS/SVN, while also making
it consistent on its own so that people who learn it as their first VCS
will get actually something nice. Well, the users shall judge. ;-)
(At this stage I would probably design few bits of the UI slightly
differently than how they have evolved, but the gripes are pretty
minor.)

In this sense, the good UI goal has indeed higher priority than the
powerfulness goal, but most of the time we hopefully manage to make it
go together well. The significant areas where Cogito is fundamentally
less powerful than GIT itself are:

	* No git-whatchanged -p - this is huge deficiency, and I'm
	  entirely at fault here
	* Consequently, no pickaxe and renames detection - same
	* Recursive merge strategy - not much of a UI problem, it just
	  needs the time and work to get integrated
	* Remote branches handling - Cogito's handling is strictly 1:1
	  while GIT's remotes are much more powerful and allow you to
	  fetch/push many branches at once (and in fact do so by
	  default); I did not invent a good UI for something similarly
	  powerful yet, and it is no high priority for me so far;
	  I think you actually want 1:1 in by far the most common usage
	  pattern
	* No email interface - but you can trivially just fall back to
	  GIT in this area

Note that Cogito's goal is not to reproduce and wrap all GIT commands -
e.g. I have currently no plans to wrap up git-bisect.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe.  -- Douglas Adams

Re: Cogito turbo-introduction

[Petr Baudis]

Dear diary, on Wed, Feb 15, 2006 at 02:12:11AM CET, I got a letter
where Petr Baudis <pasky@ucw.cz> said that...
> In this sense, the good UI goal has indeed higher priority than the
> powerfulness goal, but most of the time we hopefully manage to make it
> go together well. The significant areas where Cogito is fundamentally
> less powerful than GIT itself are:
> 
> 	* No git-whatchanged -p - this is huge deficiency, and I'm
> 	  entirely at fault here
> 	* Consequently, no pickaxe and renames detection - same
> 	* Recursive merge strategy - not much of a UI problem, it just
> 	  needs the time and work to get integrated
> 	* Remote branches handling - Cogito's handling is strictly 1:1
> 	  while GIT's remotes are much more powerful and allow you to
> 	  fetch/push many branches at once (and in fact do so by
> 	  default); I did not invent a good UI for something similarly
> 	  powerful yet, and it is no high priority for me so far;
> 	  I think you actually want 1:1 in by far the most common usage
> 	  pattern

(And you can pretty easily script/alias multi-branch fetches, it just
won't be as super-efficient as if you would fetch/push at once.)


The above is though not to say that Cogito is strict subset of GIT!
Cogito has many cool things GIT doesn't have. ;-) To pick some random
examples:

	* cg-clean
	* cg-commit - packed with convenience stuff, from multiple -m's
	  to --review
	* cg-init's initial commit
	* resumable cg-clone
	* cg-fetch's cute progressbars ;-)
	* things which are rather thin wrappers automating sequence of
	  few commands, nevertheless providing much convenience
	  (cg-admin-setuprepo, cg-admin-uncommit, cg-seek, cg-export...)

(Perhaps some of this GIT can already do, I don't watch the core
porcelain that closely.)

> Note that Cogito's goal is not to reproduce and wrap all GIT commands -
> e.g. I have currently no plans to wrap up git-bisect.

To explain, that's not because I consider git-bisect to be bad, but the
very opposite - because it is so cool and I couldn't really add much
value by adding it to Cogito. When Cogito will have good tutorial
documentation (I think it already has _very_ good reference
documentation - please prove me wrong so that we can improve it
further), I will just happily reference people to those GIT core
commands.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe.  -- Douglas Adams

Re: several quick questions

[Martin Langhoff]

On 2/15/06, Keith Packard <keithp@keithp.com> wrote:
> I was validating the cvs import by comparing every tagged version. Trust
> me, the git tree-rewriting stage was somewhat faster than the CVS
> checkout of the same content. And, as an egg, one often prefers BFI to
> finesse.

Keith,

Did that lead to finding any problems with the import? Can I get my
hands on that script you've written to run the comparison?

cheers,


martin

Re: several quick questions

[Keith Packard]

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

On Wed, 2006-02-15 at 17:11 +1300, Martin Langhoff wrote:

> Did that lead to finding any problems with the import? Can I get my
> hands on that script you've written to run the comparison?

The only issues we had were with manual changes to the repository; other
than that, we now has a usable git repository for cairo (visible at
git://git.cairographics.org/cairo). The comparison tool that I wrote was
a cheesy shell script; I think Carl has updated it to do something less
severe than rm -rf *; git-reset --hard; if he can share that, I think
you'll like it a lot better than mine.

Our CVS import script has some magic ChangeLog-style mangling which
we've posted to the list before; that clearly needs to be encapsulated
in an optional log-reformatting bit for it to be generally useful. 
 
-- 
keith.packard@intel.com

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

Re: several quick questions

[Carl Worth]

[-- Attachment #1.1: Type: text/plain, Size: 2040 bytes --]

On Tue, 14 Feb 2006 21:25:45 -0800, Keith Packard wrote:
> On Wed, 2006-02-15 at 17:11 +1300, Martin Langhoff wrote:
> 
> > Did that lead to finding any problems with the import? Can I get my
> > hands on that script you've written to run the comparison?
> 
> The only issues we had were with manual changes to the repository;

For anyone interested, here are the problems our script found after
importing cairo with git-cvsimport:

1) Some "future" files existed at old tags since we had copied ,v
   files to preserve per-file history. This one was no surprise.

2) We had a couple tags in CVS that didn't tag the current head,
   (instead a file had been manually reverted before the tag). In the
   git checkout of the same tag name, we got the results as if HEAD
   had been tagged.

Those two weren't too surprising. We remembered quite clearly what had
happened as soon as we saw the results. I've fixed these up
post-import by making git commits to fix the problems and then moving
the tags.

3) There are some sub-tree tags in cairo's CVS tree as
   well. Obviously, those aren't very interesting for direct
   comparison.

Also not surprising. For these, I just modified the script to
whitelist the tags I actually cared about checking.

4) There was a branch that diverged from the main line two commits
   "late" in the git history.

I'm not sure what caused this, but it's obviously happening in the
cvsps output. I fixed the problem by capturing the cvsps output into a
file, reordering the branching patchset up two positions in the list,
then feeding the result into git-cvsimport with its -P option.

I've attached the script I used to do the git and cvs comparisons. I
was getting perfect results with a local rsync of cairo's CVS
repository. The version here does a pserver checkout instead. When I
run this I'm apparently getting different substitution of some of
those annoying RCS $Id:...$ strings. Looks like the formatting of the
date is different. So your mileage may vary.

But here it is if its of any interest.


[-- Attachment #1.2: git-cvs-compare --]
[-- Type: application/octet-stream, Size: 1976 bytes --]

#!/bin/sh
set -e

CVSROOT=:pserver:anoncvs@cairographics.org:/cvs/cairo
GITMASTER=git://git.cairographics.org/cairo

if [ ! -e cairo-cvs ]; then
    echo -n "Performing CVS checkout to cairo-cvs..."
    cvs -d $CVSROOT co -d cairo-cvs cairo > /dev/null
    echo "done."
fi

if [ ! -e cairo-git ]; then
    echo -n "Cloning git repository to cairo-git..."
    git clone $GITMASTER cairo-git
    echo "done."
fi

# This is what you probably want to check all tags
#for tag in $(ls cairo-git/.git/refs/tags); do

# Instead, for cairo we whitelist the tags to check since there are
# some bogus partial-tree tags that just aren't interesting.
for tag in SNAPSHOT_0_1_16 SNAPSHOT_0_1_20 SNAPSHOT_0_1_21 SNAPSHOT_0_1_22 SNAPSHOT_0_1_23 LGPL_CHANGE_BEFORE LGPL_CHANGE_AFTER SNAPSHOT_0_2_0 SNAPSHOT_0_3_0 SNAPSHOT_0_4_0 SNAPSHOT_0_5_0 SNAPSHOT_0_5_1 SNAPSHOT_0_5_2 SNAPSHOT_0_6_0 RELEASE_0_9_0 RELEASE_0_9_2 RELEASE_1_0_0 RELEASE_1_0_2; do

    echo -n "Performing cvs update to $tag..."
    (cd cairo-cvs; cvs -Q update -r $tag > /dev/null)
    echo "done."

    echo -n "Performing git checkout of $tag..."

    # Linus says this is the most efficient way to do this, but it
    # seems to leave some empty directories around that shouldn't be
    # there.
    # (cd cairo-git; git checkout -b cvs-compare >& /dev/null || true; git checkout cvs-compare; git reset --hard $tag)

    # This might be slower, but it's plenty fast still and it does the right thing
    (cd cairo-git; git checkout master; git branch -D cvs-compare >& /dev/null || true; git checkout -b cvs-compare $tag)

    echo "done."

    echo -n "Comparing cvs and git trees for $tag..."
    if diff -r -x CVS -x .git cairo-cvs cairo-git >& cairo.diff; then
	echo "perfect."
	rm cairo.diff
    else
	echo "different. :("
	echo "	Saving trees to cairo-git-$tag & cairo-cvs-$tag and diff to cairo-$tag.diff"
	cp -a cairo-git cairo-git-$tag
	cp -a cairo-cvs cairo-cvs-$tag
	mv cairo.diff cairo-$tag.diff
    fi

done

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



[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: several quick questions

[Junio C Hamano]

Carl Worth <cworth@cworth.org> writes:

> 2) Ensure that bogus-branch exists somewhere (don't care where), then
>    move it:
>
> 	# Create the branch (if it doesn't exist)
> 	git checkout -b bogus-branch >& /dev/null
> 	# Switch to it (which doesn't happen above if it already existed)
> 	git checkout bogus-branch
> 	# Move the branch to the revision of interest
> 	git reset --hard <revision>

For moving around in history (like cg-seek if I understand
correctly), the above is the right and probably most efficient
way to do with the core-git tools.

	# setup
	$ git branch -f temp ;# make sure it exists
        $ git checkout temp ;# and switch to it
	# repeatedly...
        $ git reset --hard <revision1>
        # do interesting things
        $ git reset --hard <revision2>
        # do interesting things
        $ git reset --hard <revision3>
        # ...
        $ git reset --hard <revisionn>
        # do interesting things
        # once you are done
        $ git checkout master
        $ git branch -D temp

Re: several quick questions

[Petr Baudis]

  Hi,

  now from the simple Cogito's point of view. I will swap the two parts
of your mail.

Dear diary, on Tue, Feb 14, 2006 at 05:28:34PM CET, I got a letter
where Nicolas Vilz 'niv' <niv@iaglans.de> said that...
> And another thing, is there no posibility to get back to some commits or
> tags? I realized you can rebranch tags... what, if i want to switch back
> to git version 1.1.6 in the git repository? Or a certain commit?
> 
> do you have to make a new private branch out of the tag 1.1.6?
> 
> i used svn and there i could go back some revisions. I haven't found
> such a feature in git, yet... but i think i am blind all the time.

  The simple answer is cg-seek, which is meant for temporary ventures to
the commit history - e.g. you want to go back to git version 1.1.6, but
intend to do no development on top of it and to return back to the top
later. cg-seek will remember "where you came from" and by doing either
cg-reset or simply calling cg-seek without any parameters, it will
return back to the top.

  If you want to permanently change your branch to point to the 1.1.6
tag, the command to use is cg-switch -f. There is also a simpler but
less powerful variant of this command available as cg-admin-uncommit.

> i wonder, how i revoke a straight forward merge of two trees... I
> And another thing, is there no posibility to get back to some commits or
> tags? I realized you can rebranch tags... what, if i want to switch back
> to git version 1.1.6 in the git repository? Or a certain commit?
> 
> do you have to make a new private branch out of the tag 1.1.6?
> 
> i used svn and there i could go back some revisions. I haven't found
> such a feature in git, yet... but i think i am blind all the time.
> 
> I like git very much and every new day I like it more.
> actually wanted to be look like somewhere in the git-repository, where
> some branches are merged back with the master tree, but i think, that
> wasn't "cg-merge -c <tree to merge with the actual one>"...
> 
> my result was that my master tree has now the same sha1-sum as my
> development-tree and gitk visualisation differs from that what i saw in
> the git-repository. (Several Arrows headed into back into one line...)
> 
> maybe that was because i didn't do anything in my master tree in the
> meantime.

  So I assume that it made a fast-forward merge and you want to undo it.
Unfortunately, there is no facility to automatically remember what your
previous last commit was, so you either:

  * Remember the "fast-forwarding" message cg-merge gave you. ;-)
  * Fire up cg-log and find the commit you want to go back to.

  Now, when you have the commit id, this is the time for cg-switch -f -
what you want to do is to "repoint" your current branch (let's assume it
is master) to the commit id you've just found:

	cg-switch -f -r commit_id master

  (The same thing could be done using cg-admin-uncommit, but it is a
little confusing in this particular usage; you would have to rather
choose the commit id of the last commit to uncommit, and it does not
cope well with merges.)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe.  -- Douglas Adams