What I miss from Cogito...
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
Quoted 9 lines · H. Peter Anvin
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
Quoted 17 lines · Theodore Tso
Quoted 9 lines · H. Peter Anvin
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>"):
Quoted 8 lines
#!/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?
Signature · 2 lines
Luciano Rocha <[email protected]> Eurotux Informática, S.A. <http://www.eurotux.com/>
Quoted 22 lines · Luciano Rocha
Quoted 21 lines · Theodore Tso
Quoted 9 lines · H. Peter Anvin
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)
Quoted 8 lines
Quoted 4 lines
for i in $*
do
git show HEAD:$prefix$i > $i
doneI 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
Quoted 28 lines · Mike Hommey
Quoted 27 lines · Luciano Rocha
Quoted 25 lines · Theodore Tso
Quoted 9 lines · H. Peter Anvin
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
Quoted 6 lines
Quoted 3 lines
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
Quoted 1 line · Mike Hommey
On Sun, Mar 23, 2008 at 06:21:02PM +0000, Luciano Rocha wrote:
[...]
Quoted 6 lines
Quoted 3 lines
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?
* Luciano Rocha:
Quoted 5 lines
Quoted 1 line
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.
Quoted 8 lines · Florian Weimer
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
Quoted 10 lines · Theodore Tso
Quoted 8 lines · Florian Weimer
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.
Quoted 7 lines
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...
Quoted 6 lines
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.
Quoted 5 lines
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
Quoted 11 lines · Björn Steinbrink
Quoted 5 lines
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".
Quoted 2 lines
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
Quoted 13 lines · Theodore Tso
Quoted 11 lines · Björn Steinbrink
Quoted 5 lines
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.
Quoted 3 lines
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.
Quoted 10 lines
Quoted 2 lines
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
Quoted 4 lines · Theodore Tso
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.
PATCH 1/1 Documentation/git-checkout: Update summary to reflect current abilities
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.
---
Quoted 9 lines · Junio C Hamano
Quoted 4 lines · Theodore Tso
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.
Quoted 7 lines
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(-)
Documentation/git-checkout.txt +1 -1
@@ -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 --------
Signature · 1 line
1.5.4.4
Re: [PATCH] Documentation/git-checkout: Update summary to reflect current abilities
Quoted 27 lines · Julian Phillips
Quoted 9 lines
Quoted 4 lines · Theodore Tso
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.
Quoted 7 lines
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(-)Documentation/git-checkout.txt +0
-0
Documentation/git-checkout.txt git-checkout(1) · line 6
Quoted 5 lines
Documentation/git-checkout.txt +1
-1@@ -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?
PATCH 1/1 Documentation/git-checkout: Update summary to reflect current abilities
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.
---
Quoted 3 lines · Junio C Hamano
Review
Quoted 1 line · Julian Phillips
(quoted diff) +0
-0
b/Documentation/git-checkout.txt
Quoted 12 lines
Documentation/git-checkout.txt git-checkout(1) · line 6
Quoted 9 lines
index 4014e72..1b8caf1 100644
Documentation/git-checkout.txt +1
-1@@ -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 treeHmm.
Quoted 7 lines
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(-)
Documentation/git-checkout.txt +1 -1
@@ -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 --------
Documentation/glossary.txt +6 -3
@@ -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
Signature · 1 line
1.5.4.4
Quoted 17 lines · Theodore Tso
Quoted 9 lines · H. Peter Anvin
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>"):
Quoted 9 lines
#!/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
Quoted 11 lines · H. Peter Anvin
Quoted 7 lines · Theodore Tso
#!/bin/sh
#
prefix=$(git rev-parse --show-prefix)
for i in $*
do
git show HEAD:$prefix$i > $i
doneFWIW, 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. ;-)
Signature · 3 lines
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
Quoted 6 lines · H. Peter Anvin
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 .....Quoted 7 lines
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?
Quoted 14 lines · Junio C Hamano
Quoted 6 lines · H. Peter Anvin
Native git doesn't have any equivalent, other than:
git clone -n .... tmp
mv tmp/.git .
rm -rf tmp
git checkout HEADOr
git init git add remote -f .....
Quoted 8 lines
Quoted 6 lines
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
Quoted 9 lines · H. Peter Anvin
Junio C Hamano wrote:
...Quoted 7 lines
Quoted 6 lines
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.
Quoted 4 lines
Quoted 1 line
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"?
Quoted 10 lines · 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.
Quoted 6 lines
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*
Quoted 4 lines · Daniel Barkalow
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
Hi,
Quoted 7 lines · H. Peter Anvin
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.
Quoted 6 lines
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