What I miss from Cogito...

What I miss from Cogito...

[H. Peter Anvin]

This much later, there are a few minor things I still miss from Cogito. 
  I believe fixing either would be quite trivial, so I thought I'd post 
a note.

1. The ability to clone into the current directory

    cg-clone had a -c option, which allowed cloning into the current
    directory.  This is particularly useful, since I keep my common
    dot files in a git repository, so all I need to do to set up a new
    machine is to clone that git repository over my empty home directory.

    Native git doesn't have any equivalent, other than:

    git clone -n .... tmp
    mv tmp/.git .
    rm -rf tmp
    git checkout HEAD


2. cg-restore

    Cogito separated "reset" and "restore".  This is a syntactic sugar
    issue, but having to type "git reset --hard -- path" makes me
    nervous, especially since hitting Enter at the wrong time could have
    serious and irrevocable consequences.

    I also note that this particular use of "git reset" is actually
    undocumented, but it seems to work.


Those are pretty much the only Cogito command I have found myself either 
missing or using since I made a mental note to track this stuff, a few 
months ago.

	-hpa

Re: What I miss from Cogito...

[Theodore Tso]

On Sun, Mar 23, 2008 at 10:15:48AM -0700, H. Peter Anvin wrote:
> 2. cg-restore
>
>    Cogito separated "reset" and "restore".  This is a syntactic sugar
>    issue, but having to type "git reset --hard -- path" makes me
>    nervous, especially since hitting Enter at the wrong time could have
>    serious and irrevocable consequences.
>
>    I also note that this particular use of "git reset" is actually
>    undocumented, but it seems to work.

I didn't think "git reset --hard -- <pathame>" was valid, since it's
not documented in the man page.

I have the following in my path as "git-revert-file" (which is easier
to type and less dangerous than typing "git reset --hard -- <path>"):

#!/bin/sh
#
prefix=$(git rev-parse --show-prefix)

for i in $*
do
        git show HEAD:$prefix$i > $i
done


							- Ted

Re: What I miss from Cogito...

[H. Peter Anvin]

Theodore Tso wrote:
> On Sun, Mar 23, 2008 at 10:15:48AM -0700, H. Peter Anvin wrote:
>> 2. cg-restore
>>
>>    Cogito separated "reset" and "restore".  This is a syntactic sugar
>>    issue, but having to type "git reset --hard -- path" makes me
>>    nervous, especially since hitting Enter at the wrong time could have
>>    serious and irrevocable consequences.
>>
>>    I also note that this particular use of "git reset" is actually
>>    undocumented, but it seems to work.
> 
> I didn't think "git reset --hard -- <pathame>" was valid, since it's
> not documented in the man page.
> 
> I have the following in my path as "git-revert-file" (which is easier
> to type and less dangerous than typing "git reset --hard -- <path>"):
> 
> #!/bin/sh
> #
> prefix=$(git rev-parse --show-prefix)
> 
> for i in $*
> do
>         git show HEAD:$prefix$i > $i
> done
> 

FWIW, cg-restore is a 131-line shell script, so one can assume it's not 
just doing it for fun.

	-hpa

Re: What I miss from Cogito...

[Luciano Rocha]

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

On Sun, Mar 23, 2008 at 01:38:41PM -0400, Theodore Tso wrote:
> On Sun, Mar 23, 2008 at 10:15:48AM -0700, H. Peter Anvin wrote:
> > 2. cg-restore
> >
> >    Cogito separated "reset" and "restore".  This is a syntactic sugar
> >    issue, but having to type "git reset --hard -- path" makes me
> >    nervous, especially since hitting Enter at the wrong time could have
> >    serious and irrevocable consequences.
> >
> >    I also note that this particular use of "git reset" is actually
> >    undocumented, but it seems to work.
> 
> I didn't think "git reset --hard -- <pathame>" was valid, since it's
> not documented in the man page.
> 
> I have the following in my path as "git-revert-file" (which is easier
> to type and less dangerous than typing "git reset --hard -- <path>"):
> 
> #!/bin/sh
> #
> prefix=$(git rev-parse --show-prefix)
> 
> for i in $*
> do
>         git show HEAD:$prefix$i > $i
> done

I use git checkout path ...

Isn't that the same thing?

-- 
Luciano Rocha <luciano@eurotux.com>
Eurotux Informática, S.A. <http://www.eurotux.com/>

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

Re: What I miss from Cogito...

[Johannes Schindelin]

Hi,

On Sun, 23 Mar 2008, H. Peter Anvin wrote:

> 1. The ability to clone into the current directory
> 
>    cg-clone had a -c option, which allowed cloning into the current
>    directory.  This is particularly useful, since I keep my common
>    dot files in a git repository, so all I need to do to set up a new
>    machine is to clone that git repository over my empty home directory.
> 
>    Native git doesn't have any equivalent, other than:
> 
>    git clone -n .... tmp
>    mv tmp/.git .
>    rm -rf tmp
>    git checkout HEAD

Well, it has:

	$ git init
	$ git remote add -f origin <url>
	$ git checkout -b master origin/master

If you really want to track /etc with Git, you can do that easily, and you 
can easily take the flak for a not-so-popular workflow.

Ciao,
Dscho

Re: What I miss from Cogito...

[Junio C Hamano]

"H. Peter Anvin" <hpa@zytor.com> writes:

>    Native git doesn't have any equivalent, other than:
>
>    git clone -n .... tmp
>    mv tmp/.git .
>    rm -rf tmp
>    git checkout HEAD

Or

	git init
        git add remote -f .....


>
> 2. cg-restore
>
>    Cogito separated "reset" and "restore".  This is a syntactic sugar
>    issue, but having to type "git reset --hard -- path" makes me
>    nervous, especially since hitting Enter at the wrong time could have
>    serious and irrevocable consequences.

Why --hard?

Re: What I miss from Cogito...

[H. Peter Anvin]

Junio C Hamano wrote:
> "H. Peter Anvin" <hpa@zytor.com> writes:
> 
>>    Native git doesn't have any equivalent, other than:
>>
>>    git clone -n .... tmp
>>    mv tmp/.git .
>>    rm -rf tmp
>>    git checkout HEAD
> 
> Or
> 
> 	git init
>         git add remote -f .....
> 
>> 2. cg-restore
>>
>>    Cogito separated "reset" and "restore".  This is a syntactic sugar
>>    issue, but having to type "git reset --hard -- path" makes me
>>    nervous, especially since hitting Enter at the wrong time could have
>>    serious and irrevocable consequences.
> 
> Why --hard?

To make it actually change the file in the working directory (equivalent 
to the -f option in cg-restore.)

	-hpa

Re: What I miss from Cogito...

[Junio C Hamano]

"H. Peter Anvin" <hpa@zytor.com> writes:

> Junio C Hamano wrote:
> ...
>>> 2. cg-restore
>>>
>>>    Cogito separated "reset" and "restore".  This is a syntactic sugar
>>>    issue, but having to type "git reset --hard -- path" makes me
>>>    nervous, especially since hitting Enter at the wrong time could have
>>>    serious and irrevocable consequences.
>>
>> Why --hard?
>
> To make it actually change the file in the working directory
> (equivalent to the -f option in cg-restore.)

Then "git checkout HEAD -- path"?

Re: What I miss from Cogito...

[Mike Hommey]

On Sun, Mar 23, 2008 at 06:21:02PM +0000, Luciano Rocha wrote:
> On Sun, Mar 23, 2008 at 01:38:41PM -0400, Theodore Tso wrote:
> > On Sun, Mar 23, 2008 at 10:15:48AM -0700, H. Peter Anvin wrote:
> > > 2. cg-restore
> > >
> > >    Cogito separated "reset" and "restore".  This is a syntactic sugar
> > >    issue, but having to type "git reset --hard -- path" makes me
> > >    nervous, especially since hitting Enter at the wrong time could have
> > >    serious and irrevocable consequences.
> > >
> > >    I also note that this particular use of "git reset" is actually
> > >    undocumented, but it seems to work.
> > 
> > I didn't think "git reset --hard -- <pathame>" was valid, since it's
> > not documented in the man page.
> > 
> > I have the following in my path as "git-revert-file" (which is easier
> > to type and less dangerous than typing "git reset --hard -- <path>"):
> > 
> > #!/bin/sh
> > #
> > prefix=$(git rev-parse --show-prefix)
> > 
> > for i in $*
> > do
> >         git show HEAD:$prefix$i > $i
> > done
> 
> I use git checkout path ...
> 
> Isn't that the same thing?

Yes, it does the same. Note there is unfortunately no shorthand for
git show $arbitrary_commit:$path > $path

Mike

Re: What I miss from Cogito...

[Bruce Stephens]

Mike Hommey <mh@glandium.org> writes:

> On Sun, Mar 23, 2008 at 06:21:02PM +0000, Luciano Rocha wrote:

[...]

>> I use git checkout path ...
>> 
>> Isn't that the same thing?
>
> Yes, it does the same. Note there is unfortunately no shorthand for
> git show $arbitrary_commit:$path > $path

Isn't that what 

      git checkout $arbitrary_commit -- $path

does?

Re: What I miss from Cogito...

[Mike Hommey]

On Sun, Mar 23, 2008 at 08:00:17PM +0100, Mike Hommey wrote:
> On Sun, Mar 23, 2008 at 06:21:02PM +0000, Luciano Rocha wrote:
> > On Sun, Mar 23, 2008 at 01:38:41PM -0400, Theodore Tso wrote:
> > > On Sun, Mar 23, 2008 at 10:15:48AM -0700, H. Peter Anvin wrote:
> > > > 2. cg-restore
> > > >
> > > >    Cogito separated "reset" and "restore".  This is a syntactic sugar
> > > >    issue, but having to type "git reset --hard -- path" makes me
> > > >    nervous, especially since hitting Enter at the wrong time could have
> > > >    serious and irrevocable consequences.
> > > >
> > > >    I also note that this particular use of "git reset" is actually
> > > >    undocumented, but it seems to work.
> > > 
> > > I didn't think "git reset --hard -- <pathame>" was valid, since it's
> > > not documented in the man page.
> > > 
> > > I have the following in my path as "git-revert-file" (which is easier
> > > to type and less dangerous than typing "git reset --hard -- <path>"):
> > > 
> > > #!/bin/sh
> > > #
> > > prefix=$(git rev-parse --show-prefix)
> > > 
> > > for i in $*
> > > do
> > >         git show HEAD:$prefix$i > $i
> > > done
> > 
> > I use git checkout path ...
> > 
> > Isn't that the same thing?
> 
> Yes, it does the same. Note there is unfortunately no shorthand for
> git show $arbitrary_commit:$path > $path

Actually, git checkout $arbitrary_commit -- $path works (and puts the
contents in the index). Somehow, I thought it didn't work...

Mike

Re: What I miss from Cogito...

[Florian Weimer]

* Luciano Rocha:

>>         git show HEAD:$prefix$i > $i

> I use git checkout path ...
>
> Isn't that the same thing?

No, it restores the file version in the index.  "git checkout HEAD --
$path" should be the same.

Personally, I'm not all that happy with the multiple different meanings
of "git reset" and "git checkout", either.  Depending on the parameters,
the two comments manipulate both the contents of the working copy, or
the location at which the working copy is hooked in the history.  If we
need to have two separate commands for this, it would make more sense to
draw distinction between the two aspects, and not the mess we have now.
OTOH, it's probably too late for that.

Re: What I miss from Cogito...

[Daniel Barkalow]

On Sun, 23 Mar 2008, H. Peter Anvin wrote:

> This much later, there are a few minor things I still miss from Cogito.  I
> believe fixing either would be quite trivial, so I thought I'd post a note.
> 
> 1. The ability to clone into the current directory
> 
>    cg-clone had a -c option, which allowed cloning into the current
>    directory.  This is particularly useful, since I keep my common
>    dot files in a git repository, so all I need to do to set up a new
>    machine is to clone that git repository over my empty home directory.
> 
>    Native git doesn't have any equivalent, other than:
> 
>    git clone -n .... tmp
>    mv tmp/.git .
>    rm -rf tmp
>    git checkout HEAD

Maybe "git --work-tree=. clone <remote>"? It currently complains about the 
directory existing, but we could have a flag to override that. And this 
ends up with a sort of neat arrangement where your home directory is "Not 
a git repository", but if you go into the subdirectory that has the repo 
files, you can do all the usual stuff. This helps to avoid the case where 
you forget to do "git init" in a new project and accidentally check things 
into your dotfiles.

	-Daniel
*This .sig left intentionally blank*

Re: What I miss from Cogito...

[H. Peter Anvin]

Daniel Barkalow wrote:
> 
> Maybe "git --work-tree=. clone <remote>"? It currently complains about the 
> directory existing, but we could have a flag to override that. And this 
> ends up with a sort of neat arrangement where your home directory is "Not 
> a git repository", but if you go into the subdirectory that has the repo 
> files, you can do all the usual stuff. This helps to avoid the case where 
> you forget to do "git init" in a new project and accidentally check things 
> into your dotfiles.
> 
> 	-Daniel

That sounds cumbersome.

	-hpa

Re: What I miss from Cogito...

[Theodore Tso]

On Sun, Mar 23, 2008 at 08:14:47PM +0100, Florian Weimer wrote:
> 
> Personally, I'm not all that happy with the multiple different meanings
> of "git reset" and "git checkout", either.  Depending on the parameters,
> the two comments manipulate both the contents of the working copy, or
> the location at which the working copy is hooked in the history.  If we
> need to have two separate commands for this, it would make more sense to
> draw distinction between the two aspects, and not the mess we have now.
> OTOH, it's probably too late for that.

Yeah, it's not at all intuitive.  I've been using git for quite some
time and had *absolutely* *no* *idea* that "git checkout <treeish> --
path" did what "bk revert" and "hg revert" does.  In fact, I'm pretty
sure I remember asking for this functionality a while back, and being
told the right answer was "git show HEAD:pathname > pathname", and I
kept on typing it until I got sick and tired of it, and so I created
my short-hand shell script.  

And the fact that Peter was using "git reset --hard -- pathname" is
another hint that it isn't at *all* obvious that "git checkout" does
two completely different things, and it's not something that you're
likely to intuit from the name or looking at the top-level git man
page (where the summary in the top-level git manpage is, "checkout and
switch to a branch").

If we were going to separate the two commands out, I'd use the name
"git revert-file", because that's what people who are coming from bk
or hg are used to (where "revert" means to undo the local edits done
to a particular file, as opposed to the git meaning of undoing a
particular commit).

						- Ted

Re: What I miss from Cogito...

[Björn Steinbrink]

On 2008.03.23 20:16:17 -0400, Theodore Tso wrote:
> On Sun, Mar 23, 2008 at 08:14:47PM +0100, Florian Weimer wrote:
> > 
> > Personally, I'm not all that happy with the multiple different meanings
> > of "git reset" and "git checkout", either.  Depending on the parameters,
> > the two comments manipulate both the contents of the working copy, or
> > the location at which the working copy is hooked in the history.  If we
> > need to have two separate commands for this, it would make more sense to
> > draw distinction between the two aspects, and not the mess we have now.
> > OTOH, it's probably too late for that.
> 
> Yeah, it's not at all intuitive.  I've been using git for quite some
> time and had *absolutely* *no* *idea* that "git checkout <treeish> --
> path" did what "bk revert" and "hg revert" does.  In fact, I'm pretty
> sure I remember asking for this functionality a while back, and being
> told the right answer was "git show HEAD:pathname > pathname", and I
> kept on typing it until I got sick and tired of it, and so I created
> my short-hand shell script.

There is a difference between "checkout HEAD -- $file" and "show
HEAD:$file > $file". The former will also update the index, while the
latter does not. Maybe you asked for not updating the index back then?
Just guessing...

> And the fact that Peter was using "git reset --hard -- pathname" is
> another hint that it isn't at *all* obvious that "git checkout" does
> two completely different things, and it's not something that you're
> likely to intuit from the name or looking at the top-level git man
> page (where the summary in the top-level git manpage is, "checkout and
> switch to a branch").

Maybe it's just a misunderstanding on my side, but to me "checkout"
means as much as "get me something out of the repo". And git checkout
does exactly that. It can get you a branch (naturally switching your
HEAD to it), or it can get you trees or blobs. The latter can come from
either the index (default) or from a specific treeish. To say that you
want to revert your local changes is just the same as saying that you
want the file as it is in HEAD. And that's what git checkout gives you,
without introducing an extra command for that one special case.

> If we were going to separate the two commands out, I'd use the name
> "git revert-file", because that's what people who are coming from bk
> or hg are used to (where "revert" means to undo the local edits done
> to a particular file, as opposed to the git meaning of undoing a
> particular commit).

Nah, that would create confusion within git, because it does something
totally different from git revert. And checkout can also checkout a
whole tree, not just a file. So you would either need revert-tree as
well... Or add more confusion, because revert-file "reverting" a tree is
not quite intuitive.

Björn

Re: What I miss from Cogito...

[Theodore Tso]

On Mon, Mar 24, 2008 at 02:40:30AM +0100, Björn Steinbrink wrote:
> > If we were going to separate the two commands out, I'd use the name
> > "git revert-file", because that's what people who are coming from bk
> > or hg are used to (where "revert" means to undo the local edits done
> > to a particular file, as opposed to the git meaning of undoing a
> > particular commit).
> 
> Nah, that would create confusion within git, because it does something
> totally different from git revert. And checkout can also checkout a
> whole tree, not just a file. So you would either need revert-tree as
> well... Or add more confusion, because revert-file "reverting" a tree is
> not quite intuitive.

That's why I said "git revert-file" as being different from "git
revert".  If you want to revert the entire tree in the sense of
"undoing local edits", most people today use "git reset --hard".

> Maybe it's just a misunderstanding on my side, but to me "checkout"
> means as much as "get me something out of the repo". 

If that's true, why is the one-line summary in the git-checkout man
page and in the git top-level man page read as follows?

       git-checkout - Checkout and switch to a branch

At the very least, will you admit that the summary in the man page is
perhaps just a wee bit misleading?

						- Ted

Re: What I miss from Cogito...

[Junio C Hamano]

Theodore Tso <tytso@MIT.EDU> writes:

>        git-checkout - Checkout and switch to a branch
>
> At the very least, will you admit that the summary in the man page is
> perhaps just a wee bit misleading?

It's not "wee bit misleading" but it just is outright stale.

Back then, before people realized the operation "to check out the path out
of index or tree-ish" belongs naturally to a command whose name is
"checkout", "to check out the named branch or a commit" was the only thing
that you could do with the command.  The one-line description you quoted
above reflects that history.

Patches very much welcome; I did not notice it was kept stale.

Re: What I miss from Cogito...

[Björn Steinbrink]

On 2008.03.23 22:14:11 -0400, Theodore Tso wrote:
> On Mon, Mar 24, 2008 at 02:40:30AM +0100, Björn Steinbrink wrote:
> > > If we were going to separate the two commands out, I'd use the name
> > > "git revert-file", because that's what people who are coming from bk
> > > or hg are used to (where "revert" means to undo the local edits done
> > > to a particular file, as opposed to the git meaning of undoing a
> > > particular commit).
> > 
> > Nah, that would create confusion within git, because it does something
> > totally different from git revert. And checkout can also checkout a
> > whole tree, not just a file. So you would either need revert-tree as
> > well... Or add more confusion, because revert-file "reverting" a tree is
> > not quite intuitive.
> 
> That's why I said "git revert-file" as being different from "git
> revert".  If you want to revert the entire tree in the sense of
> "undoing local edits", most people today use "git reset --hard".

But that still leaves out e.g. "git checkout HEAD -- some_directory/".
Passing a directory to git revert-file seems plain broken, but you can
do that with checkout, so you would also need a git revert-tree (or come
up with a better name ;-)). And IMHO the difference between git revert
and the suggested revert-file has too much potential for confusion
already.

> > Maybe it's just a misunderstanding on my side, but to me "checkout"
> > means as much as "get me something out of the repo". 
> 
> If that's true, why is the one-line summary in the git-checkout man
> page and in the git top-level man page read as follows?
> 
>        git-checkout - Checkout and switch to a branch
> 
> At the very least, will you admit that the summary in the man page is
> perhaps just a wee bit misleading?

I won't disagree on that one ;-) But I probably won't come up with
something better either. My brain stops somewhere at "Checkout stuff",
and that's even less useful than the current one.

Björn

[PATCH] Documentation/git-checkout: Update summary to reflect current abilities

[Julian Phillips]

For a while now, git-checkout has been more powerful than the man-page
summary would suggest (the main text does describe the new features),
so update the summary to hopefully better reflect the current
functionality.

Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
---

On Sun, 23 Mar 2008, Junio C Hamano wrote:

> Theodore Tso <tytso@MIT.EDU> writes:
>
>>        git-checkout - Checkout and switch to a branch
>>
>> At the very least, will you admit that the summary in the man page is
>> perhaps just a wee bit misleading?
>
> It's not "wee bit misleading" but it just is outright stale.
>
> Back then, before people realized the operation "to check out the path out
> of index or tree-ish" belongs naturally to a command whose name is
> "checkout", "to check out the named branch or a commit" was the only thing
> that you could do with the command.  The one-line description you quoted
> above reflects that history.
>
> Patches very much welcome; I did not notice it was kept stale.

Something like this perhaps?

 Documentation/git-checkout.txt |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index 4014e72..1b8caf1 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -3,7 +3,7 @@ git-checkout(1)
 
 NAME
 ----
-git-checkout - Checkout and switch to a branch
+git-checkout - Checkout/update/refresh items in the working tree
 
 SYNOPSIS
 --------
-- 
1.5.4.4

[PATCH] Documentation/git-checkout: Update summary to reflect current abilities

[Julian Phillips]

For a while now, git-checkout has been more powerful than the man-page
summary would suggest (the main text does describe the new features),
so update the summary to hopefully better reflect the current
functionality.  Also update the glossary description of the word checkout.

Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
---
On Mon, 24 Mar 2008, Junio C Hamano wrote:

> Julian Phillips <julian@quantumfyre.co.uk> writes:
>
>> diff --git a/Documentation/git-checkout.txt
b/Documentation/git-checkout.txt
>> index 4014e72..1b8caf1 100644
>> --- a/Documentation/git-checkout.txt
>> +++ b/Documentation/git-checkout.txt
>> @@ -3,7 +3,7 @@ git-checkout(1)
>>
>>  NAME
>>  ----
>> -git-checkout - Checkout and switch to a branch
>> +git-checkout - Checkout/update/refresh items in the working tree
>
> Hmm.
>
> The glossary may be a good place to define what the verb "checkout" means.
> I think using that defined word without adding "/update/refresh" to
> muddy its meaning would be more appropriate, after we establish what
> "checkout" means in the glossary.
>
> So how about saying "Check out a whole branch, or paths to the work tree"
> or something like that?

Ok, so more like this?  I've updated the glossary entry for checkout too,
though I'm thinking that there ought to be a clearer way to explain it ...

 Documentation/git-checkout.txt |    2 +-
 Documentation/glossary.txt     |    9 ++++++---
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index 4014e72..e11cddb 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -3,7 +3,7 @@ git-checkout(1)
 
 NAME
 ----
-git-checkout - Checkout and switch to a branch
+git-checkout - Checkout a branch or paths to the working tree
 
 SYNOPSIS
 --------
diff --git a/Documentation/glossary.txt b/Documentation/glossary.txt
index ab4caf4..51b6353 100644
--- a/Documentation/glossary.txt
+++ b/Documentation/glossary.txt
@@ -45,9 +45,12 @@ GIT Glossary
 	"changesets" with git.
 
 [[def_checkout]]checkout::
-	The action of updating the <<def_working_tree,working tree>> to a
-	<<def_revision,revision>> which was stored in the
-	<<def_object_database,object database>>.
+	The action of updating all or part of the
+	<<def_working_tree,working tree>> with a <<def_tree_object,tree object>>
+	or <<def_blob_object,blob>> from the
+	<<def_object_database,object database>>, and updating the
+	<<def_index,index>> and <<def_HEAD,HEAD>> if the whole working tree has
+	been pointed at a new <<def_branch,branch>>.
 
 [[def_cherry-picking]]cherry-picking::
 	In <<def_SCM,SCM>> jargon, "cherry pick" means to choose a subset of
-- 
1.5.4.4

Re: [PATCH] Documentation/git-checkout: Update summary to reflect current abilities

[Junio C Hamano]

Julian Phillips <julian@quantumfyre.co.uk> writes:

>> Theodore Tso <tytso@MIT.EDU> writes:
>>
>>>        git-checkout - Checkout and switch to a branch
>>>
>>> At the very least, will you admit that the summary in the man page is
>>> perhaps just a wee bit misleading?
>>
>> It's not "wee bit misleading" but it just is outright stale.
>>
>> Back then, before people realized the operation "to check out the path out
>> of index or tree-ish" belongs naturally to a command whose name is
>> "checkout", "to check out the named branch or a commit" was the only thing
>> that you could do with the command.  The one-line description you quoted
>> above reflects that history.
>>
>> Patches very much welcome; I did not notice it was kept stale.
>
> Something like this perhaps?
>
>  Documentation/git-checkout.txt |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
> index 4014e72..1b8caf1 100644
> --- a/Documentation/git-checkout.txt
> +++ b/Documentation/git-checkout.txt
> @@ -3,7 +3,7 @@ git-checkout(1)
>  
>  NAME
>  ----
> -git-checkout - Checkout and switch to a branch
> +git-checkout - Checkout/update/refresh items in the working tree

Hmm.

The glossary may be a good place to define what the verb "checkout" means.
I think using that defined word without adding "/update/refresh" to
muddy its meaning would be more appropriate, after we establish what
"checkout" means in the glossary.

So how about saying "Check out a whole branch, or paths to the work tree"
or something like that?

Re: What I miss from Cogito...

[Petr Baudis]

On Sun, Mar 23, 2008 at 10:46:52AM -0700, H. Peter Anvin wrote:
> Theodore Tso wrote:
>> #!/bin/sh
>> #
>> prefix=$(git rev-parse --show-prefix)
>> for i in $*
>> do
>>         git show HEAD:$prefix$i > $i
>> done
>
> FWIW, cg-restore is a 131-line shell script, so one can assume it's not 
> just doing it for fun.

Actually, such an assumption is not safe, simply since it was written
long before the :-syntax and many other nice features were invented; if
one wants to do things in Git sanely these days, it's not even safe to
look at Cogito's source code for inspiration anymore as it had to work
only with really hardcore primitives.

(And 38 lines is documentation.  ;-)

-- 
				Petr "Pasky" Baudis
Whatever you can do, or dream you can, begin it.
Boldness has genius, power, and magic in it.	-- J. W. von Goethe