threads / discuss / 12820

What I miss from Cogito...

Subject: What I miss from Cogito...

## tl;dr

23 messages between Mar 23, 2008 and Mar 27, 2008.

replies: 22people: 12as markdown or json

H. Peter Anvin· Mar 23, 2008, 17:15 UTC · lore

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

Theodore Tso· Mar 23, 2008, 17:38 UTC · re: H. Peter Anvin · lore

Re: What I miss from Cogito...

On Sun, Mar 23, 2008 at 10:15:48AM -0700, H. Peter Anvin wrote:

Show 9 quoted 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.
>
>    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

H. Peter Anvin· Mar 23, 2008, 17:46 UTC · re: Theodore Tso · lore

Re: What I miss from Cogito...

Theodore Tso wrote:

Show 26 quoted lines

> 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

Petr Baudis· Mar 27, 2008, 02:36 UTC · re: H. Peter Anvin · lore

Re: What I miss from Cogito...

On Sun, Mar 23, 2008 at 10:46:52AM -0700, H. Peter Anvin wrote:

Show 11 quoted lines

> 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

Luciano Rocha· Mar 23, 2008, 18:21 UTC · re: Theodore Tso · lore

Re: What I miss from Cogito...

On Sun, Mar 23, 2008 at 01:38:41PM -0400, Theodore Tso wrote:

Show 25 quoted lines

> 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/>

Mike Hommey· Mar 23, 2008, 19:00 UTC · re: Luciano Rocha · lore

Re: What I miss from Cogito...

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

Show 30 quoted lines

> 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

Bruce Stephens· Mar 23, 2008, 19:07 UTC · re: Mike Hommey · lore

Re: What I miss from Cogito...

Mike Hommey <mh@glandium.org> writes:

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

[...]

Show 6 quoted 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?

Mike Hommey· Mar 23, 2008, 19:07 UTC · re: Mike Hommey · lore

Re: What I miss from Cogito...

On Sun, Mar 23, 2008 at 08:00:17PM +0100, Mike Hommey wrote:

Show 34 quoted lines

> 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

Florian Weimer· Mar 23, 2008, 19:14 UTC · re: Luciano Rocha · lore

Re: What I miss from Cogito...

* 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.

Theodore Tso· Mar 24, 2008, 00:16 UTC · re: Florian Weimer · lore

Re: What I miss from Cogito...

On Sun, Mar 23, 2008 at 08:14:47PM +0100, Florian Weimer wrote:

Show 8 quoted lines

> 
> 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

Björn Steinbrink· Mar 24, 2008, 01:40 UTC · re: Theodore Tso · lore

Re: What I miss from Cogito...

On 2008.03.23 20:16:17 -0400, Theodore Tso wrote:

Show 17 quoted lines

> 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...

Show 6 quoted 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.

Show 5 quoted 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

Theodore Tso· Mar 24, 2008, 02:14 UTC · re: Björn Steinbrink · lore

Re: What I miss from Cogito...

On Mon, Mar 24, 2008 at 02:40:30AM +0100, Björn Steinbrink wrote:

Show 11 quoted 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".

> 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

Junio C Hamano· Mar 24, 2008, 02:53 UTC · re: Theodore Tso · lore

Re: What I miss from Cogito...

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.

Julian Phillips· Mar 24, 2008, 03:06 UTC · re: Junio C Hamano · lore

[PATCH] 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.

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

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

Show 16 quoted lines

> 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

Junio C Hamano· Mar 24, 2008, 16:49 UTC · re: Julian Phillips · lore

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

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

Show 32 quoted lines

>> 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?

Julian Phillips· Mar 24, 2008, 03:06 UTC · re: Junio C Hamano · lore

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

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

Show 19 quoted lines

>> 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

Björn Steinbrink· Mar 24, 2008, 02:57 UTC · re: Theodore Tso · lore

Re: What I miss from Cogito...

On 2008.03.23 22:14:11 -0400, Theodore Tso wrote:

Show 16 quoted lines

> 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.

Show 10 quoted 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

Johannes Schindelin· Mar 23, 2008, 18:31 UTC · re: H. Peter Anvin · lore

Re: What I miss from Cogito...

Hi,

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

Show 13 quoted lines

> 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

Junio C Hamano· Mar 23, 2008, 18:34 UTC · re: H. Peter Anvin · lore

Re: What I miss from Cogito...

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

Show 6 quoted lines

>    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 .....

Show 7 quoted 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?

H. Peter Anvin· Mar 23, 2008, 18:58 UTC · re: Junio C Hamano · lore

Re: What I miss from Cogito...

Junio C Hamano wrote:

Show 22 quoted lines

> "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

Junio C Hamano· Mar 23, 2008, 18:59 UTC · re: H. Peter Anvin · lore

Re: What I miss from Cogito...

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

Show 13 quoted lines

> 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"?

Daniel Barkalow· Mar 23, 2008, 19:16 UTC · re: H. Peter Anvin · lore

Re: What I miss from Cogito...

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

Show 16 quoted lines

> 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*

H. Peter Anvin· Mar 23, 2008, 19:19 UTC · re: Daniel Barkalow · lore

Re: What I miss from Cogito...

Daniel Barkalow wrote:

Show 10 quoted lines

> 
> 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