Re: [PATCH 3/3] git checkout --nodwim

Johannes Schindelin [off-list ref] writes:

Hi,

On Thu, 22 Oct 2009, Nanako Shiraishi wrote:

quoted

Quoting Avery Pennarun [off-list ref]

quoted

On Sun, Oct 18, 2009 at 3:53 PM, Junio C Hamano [off-list ref] wrote:

quoted

Helping hands in polishing it up is very welcome.

I find the idea of an option for "don't do what I mean" to be pretty
entertaining.  Or maybe just misleading :)

Have fun,

Avery

As Junio asked for helping hands, let's try to be helpful and constructive.

Maybe "don't second-guess" explains it better?

My take on it:

1) --no-porcelain

2) we all are bike-shedding, not being constructive at all

You are right about (2), regarding the option name. I've queued one that
uses --no-guess.

Regarding the correct use of parse_options(), I had to figure it out
myself, and helping hand would have, eh, helped me.

On Sat, Oct 24, 2009 at 2:35 AM, Junio C Hamano [off-list ref] wrote:

quoted

My take on it:

1) --no-porcelain

2) we all are bike-shedding, not being constructive at all

You are right about (2), regarding the option name. I've queued one that
uses --no-guess.

Perhaps a universal --plumbing flag would be handy? It'd be nice to be
able to pass any command --plumbing and it'll either behave in a
stable, predictable, plumbing-like way, or die with an error message
stating that it isn't a plumbing command.  Right now, it's sort of
hard to figure out what is plumbing and what is porcelain.  Some
commands are clear, but other commands labelled as plumbing in git(1)
are deprecated in favor of commands labelled as porcelain.

David

David Roundy [off-list ref] writes:

Perhaps a universal --plumbing flag would be handy?

Yes in general but it is unclear what aspect of its behaviour we will
be casting in stone with a generic --plumbing option in this case.  I
also think that "checkout" Porcelain is not yet mature enough for us
to do this right now. For example, I am reasonably sure that somebody
motivated enough will teach it to touch submodule trees when switching
to another branch by default, and it is unclear if we should turn off
these expected additions when --plumbing is seen.

Hi,

On Sat, 24 Oct 2009, David Roundy wrote:

On Sat, Oct 24, 2009 at 2:35 AM, Junio C Hamano [off-list ref] wrote:

quoted

quoted

My take on it:

1) --no-porcelain

2) we all are bike-shedding, not being constructive at all

You are right about (2), regarding the option name. I've queued one that
uses --no-guess.

Perhaps a universal --plumbing flag would be handy?

No.  Older Git versions do not know about it, so you cannot Just Modify 
Your Scripts.  So the benefit of --plumbing is dubitable.

FWIW the same goes for --no-porcelain.

Ciao,
Dscho

On Mon, Oct 26, 2009 at 4:12 PM, Johannes Schindelin
[off-list ref] wrote:

On Sat, 24 Oct 2009, David Roundy wrote:

quoted

Perhaps a universal --plumbing flag would be handy?

No.  Older Git versions do not know about it, so you cannot Just Modify
Your Scripts.  So the benefit of --plumbing is dubitable.

FWIW the same goes for --no-porcelain.

I suppose that, three years down the road, the existence of such an
option would be useful.  Until then, any change at all to any
command's interface seems to have the same problem as you describe.

That said, as a person who maintains a bunch of git-wrapping scripts
at work, it seems more straightforward to me to continue the
separation between plumbing vs. porcelain commands, rather than giving
each command two subtly incompatible modes.  It's much easier for me
to remember "don't use git checkout" than to remember "when you call
git checkout, make sure to use --plumbing, even though *today* it
works just fine without it."

I don't think there's actually a plumbing alternative to git-checkout,
however.  My git-subtree script (and another script at work) have
already had some bugs because of this (specifically, the differing
behaviour of git-checkout with and without a path specified).  Is
there something else I should be using in my scripts to be maximally
safe?

Have fun,

Avery

On Mon, Oct 26, 2009 at 04:40:41PM -0400, Avery Pennarun wrote:

I don't think there's actually a plumbing alternative to git-checkout,
however.  My git-subtree script (and another script at work) have
already had some bugs because of this (specifically, the differing
behaviour of git-checkout with and without a path specified).  Is
there something else I should be using in my scripts to be maximally
safe?

It's git-update-ref. Which highlights one problem with the
porcelain/plumbing distinction. Our plumbing building blocks work at a
very low level, but often when scripting you want to use higher level
building blocks. So porcelain gets used in scripts, and gets an
ambiguous state. Consider "git commit", for example. Does anyone
actually script around "write-tree" and "commit-tree" these days, or do
they just script around "git commit"?

-Peff

On Mon, Oct 26, 2009 at 5:26 PM, Jeff King [off-list ref] wrote:

On Mon, Oct 26, 2009 at 04:40:41PM -0400, Avery Pennarun wrote:

quoted

I don't think there's actually a plumbing alternative to git-checkout,
however.  My git-subtree script (and another script at work) have
already had some bugs because of this (specifically, the differing
behaviour of git-checkout with and without a path specified).  Is
there something else I should be using in my scripts to be maximally
safe?

It's git-update-ref.

That would be similar to git commit, not git checkout, right?  Oh
wait, I see the confusion: git checkout does two things.  It switches
branches, and it checks out files from the index into the work tree.
I meant the latter meaning.

Consider "git commit", for example. Does anyone
actually script around "write-tree" and "commit-tree" these days, or do
they just script around "git commit"?

Oh, I use those all the time.  They're awesome!  It allows you to
create commits without having a working tree, which lets me do very
interesting tricks.  git-subtree uses this heavily.

I'm probably a weirdo, though.

Have fun,

Avery

On Mon, Oct 26, 2009 at 06:01:29PM -0400, Avery Pennarun wrote:

quoted

It's git-update-ref.

That would be similar to git commit, not git checkout, right?  Oh
wait, I see the confusion: git checkout does two things.  It switches
branches, and it checks out files from the index into the work tree.
I meant the latter meaning.

Er, sorry, yes. It should be "git symbolic-ref", of course, to change
HEAD, and then probably read-tree and checkout-index. I was just not
thinking when I wrote the other message (hopefully I am doing so now).

quoted

Consider "git commit", for example. Does anyone
actually script around "write-tree" and "commit-tree" these days, or do
they just script around "git commit"?

Oh, I use those all the time.  They're awesome!  It allows you to
create commits without having a working tree, which lets me do very
interesting tricks.  git-subtree uses this heavily.

I'm probably a weirdo, though.

OK, I should have phrased my statement differently (see, I told you I
wasn't thinking). Yes, there are reasons to script around low-level
building blocks, when you don't want the assumptions associated with the
higher level. But I'm sure there are tons of scripts that munge some
files in a worktree, followed by "git add -A; git commit -m 'automagic
update'". And in that case, nobody would script around "commit-tree"
because it's a lot more work.

-Peff

On Mon, Oct 26, 2009 at 6:14 PM, Jeff King [off-list ref] wrote:

On Mon, Oct 26, 2009 at 06:01:29PM -0400, Avery Pennarun wrote:

quoted

quoted

It's git-update-ref.

That would be similar to git commit, not git checkout, right?  Oh
wait, I see the confusion: git checkout does two things.  It switches
branches, and it checks out files from the index into the work tree.
I meant the latter meaning.

Er, sorry, yes. It should be "git symbolic-ref", of course, to change
HEAD, and then probably read-tree and checkout-index. I was just not
thinking when I wrote the other message (hopefully I am doing so now).

Wow, I've browsed through the git manpages repeatedly and never found
checkout-index.  It was exactly the missing building block I was
looking for.  Thanks!

quoted

quoted

Consider "git commit", for example. Does anyone
actually script around "write-tree" and "commit-tree" these days, or do
they just script around "git commit"?

Oh, I use those all the time.  They're awesome!  It allows you to
create commits without having a working tree, which lets me do very
interesting tricks.  git-subtree uses this heavily.

I'm probably a weirdo, though.

OK, I should have phrased my statement differently (see, I told you I
wasn't thinking). Yes, there are reasons to script around low-level
building blocks, when you don't want the assumptions associated with the
higher level. But I'm sure there are tons of scripts that munge some
files in a worktree, followed by "git add -A; git commit -m 'automagic
update'". And in that case, nobody would script around "commit-tree"
because it's a lot more work.

Unfortunately this is pretty tricky to get perfect; perhaps there's no
way to do it.

In git-subtree, for example, I *mostly* use write-tree and
commit-tree, but when I do the final merge operation (to take the
synthetic history and merge it into your "real" history) I use commit.
 This is because I wanted the default merge handling, commit message,
etc for that part.  Unfortunately, it's possible that this dragged in
a bunch of stuff I *didn't* want.  It also makes git-subtree, which
otherwise could be used as plumbing, effectively into a porcelain.

I don't really know what to do about that.  You could introduce an
abstraction level somewhere between commit-tree and commit, but surely
someone would eventually find a case where that abstraction level is
still not right.  To bring this around to the original topic of this
thread, such an extra level of abstraction is equivalent to the
suggested --plumbing (or whatever) option, whether it's presented as
an option or a separate command.

Have fun,

Avery