From: Sam Vilain <hidden> Date: 2016-08-13 23:16:46
From: Sam Vilain <redacted>
For cross-command CLI changes to be effective, they need to be
cohesively planned. Add a planning document for this next set of
changes.
Signed-off-by: Sam Vilain <redacted>
---
Some suggestions, which have been briefly scanned over by some of the
(remaining @4pm) GitTogether attendees.
Please keep it constructive! :)
Documentation/cli-revamp.txt | 135 ++++++++++++++++++++++++++++++++++++++++++
1 files changed, 135 insertions(+), 0 deletions(-)
create mode 100644 Documentation/cli-revamp.txt
@@ -0,0 +1,135 @@+GIT command line revamp+=======================++This design document is designed for review and critique over planned+direction for changing the command set used by git, rather than+reviewing and critiquing individual changes.++In general, old commands will be grandfathered for a year or longer,+and all plumbing commands will still work as originally designed.++Please bear in mind when critiquing that each of these changes might+themselves have a progressive implementation, for instance the new+behaviour being optional initially.++Please try to be positive with your comments; let's try to come up+with solutions and not argue about the details of the solutions+presented until those details are submitted. In particular, critical+comments that do not acknowledge the presence of a problem are+worthless at this stage.++Add/rm/reset/checkout/revert+----------------------------++Many find these confusing.++ * 'git stage' would do what 'git add' does now.++ * 'git unstage' would do what 'git reset --' does now++ * 'git status' would encourage the user to use+ 'git diff --staged' to see staged changes as a patch++ * 'git commit' with no changes should give useful information about+ using 'git stage', 'git commit -a' or 'git commit filename ...'++ * 'git add' and 'git rm': no change++ * 'git update-index' considered plumbing, not changed++ * 'git revert' deprecated in favour of 'git cherry-pick --revert'++ * 'git undo' would do what 'git checkout HEAD --' does now++ * 'git checkout branch' would, if there is a remote branch called+ 'branch' on exactly one remote, do what+ 'git checkout -b branch thatremote/branch' does now. If it is+ ambiguous, it would be an error, forcing the explicit notation.++ * 'git branch --switch' : alternative to checkout+++Push/pull+---------++These commands are asymmetric, and this seems mostly historical.++ * 'git push --matching' does what 'git push' does today (without+ explicit configuration)++ * 'git push' with no ref args and no 'push =' configuration does+ what:+ 'git push origin $(git symbolic-ref HEAD | sed "s!refs/heads/!!")'+ does today. ie, it only pushes the current branch.+ If a branch was defined in branch.<name>.push, push to that ref+ instead of the matching one. If there is no matching ref, and+ there is a branch.<name>.merge, push back there.++ * 'git pull' behaviour unchanged++ * 'git push' to checked out branch of non-bare repository not+ allowed without special configuration. Configuration available+ that allows working directory to be updated, known caveats+ notwithstanding. Ideally, it would refuse only in situations+ where a broken working copy would be left (because you couldn't+ fix it), and work when it can be known to be safe.+++Informational+-------------++ * 'git branch' should default to '--color=auto -v'++ * 'git tag -l' should show more information+++Working with patches+--------------------++ * 'git send-email' should prompt for all SMTP-related information+ about sending e-mail when it is running with no configuration.+ Because these days /usr/lib/sendmail is rarely configured+ correctly.++ * other git send-email functionality which has bitten people -+ particularly building the recipient list - should prompt for+ confirmation until configured to be automatic.++ * 'git am -3' the default; with global option to make it not the+ default for those that prefer the speed of -2+++Submodules+----------++ * submodules should be able to refer to symbolic ref names, svn+ style - in the .gitmodules file. The actual commit used is still+ recorded in the index.++ * when switching branches, if the checked out revision of a submodule+ changes, then it should be switched as well++ * 'git submodule update' should be able to be triggered when+ switching branches (but not be the default behaviour)+++Others+------++ * 'git export' command that does what+ 'git archive --format=tar --prefix=dir | tar x' does now++ * conflicted merges should point the user immediately to+ 'git mergetool' and mention you need to use 'git stage' to mark+ resolved files and 'git commit' when done.++ * 'git init --server' (or similar) should do everything required for+ exporting::+----+chmod -R a+rX+touch git-daemon-export-ok+git gc+git update-server-info+chmod u+x .git/hooks/post-update+git config core.sharedrepository=1+----
From: Stefan Karpinski <hidden> Date: 2016-06-15 22:45:33
These proposed changes look great.
On Wed, Oct 29, 2008 at 8:48 PM, Sam Vilain [off-list ref] wrote:
+ * 'git unstage' would do what 'git reset --' does now
Would it make sense to deprecate using "git reset --" for this then?
It's always seemed confusing to me to have such disparate
functionality in the reset command.
+ * 'git export' command that does what
+ 'git archive --format=tar --prefix=dir | tar x' does now
It would be nice if the "git export" command could "checkout" a
non-repo copy of a remote repo at a specific version. This would be as
simple as calling archive on the remote size and then unarchiving it
locally. But would of course take care of all the plumbing.
(Sorry for the resend, Sam.)
From: Pierre Habouzit <hidden> Date: 2016-06-15 22:45:33
On Thu, Oct 30, 2008 at 03:48:05AM +0000, Sam Vilain wrote:
+Add/rm/reset/checkout/revert
+----------------------------
+
+Many find these confusing.
+
+ * 'git stage' would do what 'git add' does now.
-> git stage -i/-p shall do what git add -i/-p does.
+
+ * 'git unstage' would do what 'git reset --' does now
-> likely we need a git unstage -i/-p to interactively unstage some
bits.
* 'git track' would do what git add -N does now.
* 'git untrack' would do what 'git rm --cached' does now.
+ * 'git undo' would do what 'git checkout HEAD --' does now
I'm not really a fan of this one. Undo is too unspecific (I know at
least 2 people using that for git reset --hard HEAD~1 and 1 other for an
alias to git reset --hard HEAD@{1}).
I have no constructive proposal to replace it though, but I believe git
undo would cause lots of harm. Would it be for another command, it
wouldn't be a problem, but git undo *LOSES* information by design (the
local changes on a file), and it would override aliases that people
could have done on it. Choosing it has consequences.
+Working with patches
+--------------------
+
+ * 'git send-email' should prompt for all SMTP-related information
+ about sending e-mail when it is running with no configuration.
+ Because these days /usr/lib/sendmail is rarely configured
+ correctly.
And when the user answer them, it should set them (a bit like zsh does
when it's run from the first time e.g.)
+
+ * other git send-email functionality which has bitten people -
+ particularly building the recipient list - should prompt for
+ confirmation until configured to be automatic.
+
* git-send-email should be either more interactive, or less: either
just use the damn configuration, or propose a mode where it spawns
an editor for each patch so that you can add further comments.
* git-send-email should be able to format-patches by himself (IOW
accept most of format-patch arguments and deal with the patch list
by himself, which is usable if the previous point is implemented).
+ * 'git am -3' the default; with global option to make it not the
+ default for those that prefer the speed of -2
+
+
+Submodules
+----------
+
+ * submodules should be able to refer to symbolic ref names, svn
+ style - in the .gitmodules file. The actual commit used is still
+ recorded in the index.
+
+ * when switching branches, if the checked out revision of a submodule
+ changes, then it should be switched as well
+
+ * 'git submodule update' should be able to be triggered when
+ switching branches (but not be the default behaviour)
Actually on this one, I'd say that a submodule is either non initialized
(in which case we don't care) or it is. If it is, switching branches
should probably trigger a submodule update if the switch isn't possible
(because the dereferenced sha1 doesn't exists). Or alternatively it
should make the whole branch switch fail.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
From: Nicolas Pitre <hidden> Date: 2016-06-15 22:45:33
On Wed, 29 Oct 2008, Sam Vilain wrote:
From: Sam Vilain <redacted>
For cross-command CLI changes to be effective, they need to be
cohesively planned. Add a planning document for this next set of
changes.
Signed-off-by: Sam Vilain <redacted>
[...]
+ * 'git checkout branch' would, if there is a remote branch called
+ 'branch' on exactly one remote, do what
+ 'git checkout -b branch thatremote/branch' does now. If it is
+ ambiguous, it would be an error, forcing the explicit notation.
I can't do otherwise but disagree with this. Currently, when a remote
branch is checked out, the commit corresponding to that remote branch is
put on a detached head which is IMHO completely sane and coherent. It
even tells you how to create a local branch from there if that's what
you wanted to do. So if it is still too confusing at that point then
more explanations are needed and not the removal of a perfectly fine
feature. Please don't change that behavior.
Nicolas
On Wed, Oct 29, 2008 at 08:48:05PM -0700, Sam Vilain wrote:
From: Sam Vilain <redacted>
For cross-command CLI changes to be effective, they need to be
cohesively planned. Add a planning document for this next set of
changes.
Here are my favorites:
* Add the command "git revert-file <files>" which is syntactic sugar for:
git checkout HEAD -- <files>
Rationale: Many other SCM's have a way of undoing local edits to a
file very simply, i.e."hg revert <file>" or "svn revert <file>", and
for many developers's workflow, it's useful to be able to undo local
edits to a single file, but not to everything else in the working
directory. And "git checkout HEAD -- <file>" is rather cumbersome
to type, and many beginning users don't find it intuitive to look in
the "git-checkout" man page for instructions on how to revert a
local file.
* Change the argument handling for "git format-patch" so it is
consistent with everything else which takes a set of commits. Yes,
it means that where people have gotten used to typing "git
format-patch origin", they'll have to type instead: "git
format-patch origin..", but's much more consistent. We've done the
best we can by documenting the existing behavior, but if'we re going
to make major, potentially incompatible, CLI changes, this is
something to at least consider. Maybe with a config file for people
who really don't want to retrain their fingers to type the two extra
periods?
- Ted
From: Pierre Habouzit <hidden> Date: 2016-06-15 22:45:33
On Thu, Oct 30, 2008 at 02:39:18PM +0000, Theodore Tso wrote:
On Wed, Oct 29, 2008 at 08:48:05PM -0700, Sam Vilain wrote:
quoted
From: Sam Vilain <redacted>
For cross-command CLI changes to be effective, they need to be
cohesively planned. Add a planning document for this next set of
changes.
Here are my favorites:
* Add the command "git revert-file <files>" which is syntactic sugar for:
git checkout HEAD -- <files>
Rationale: Many other SCM's have a way of undoing local edits to a
file very simply, i.e."hg revert <file>" or "svn revert <file>", and
for many developers's workflow, it's useful to be able to undo local
edits to a single file, but not to everything else in the working
directory. And "git checkout HEAD -- <file>" is rather cumbersome
to type, and many beginning users don't find it intuitive to look in
the "git-checkout" man page for instructions on how to revert a
local file.
This is what is currently proposed for undo, but yeah, revert-file or
maybe rather revert-changes may be suitable.
* Change the argument handling for "git format-patch" so it is
consistent with everything else which takes a set of commits. Yes,
it means that where people have gotten used to typing "git
format-patch origin", they'll have to type instead: "git
format-patch origin..", but's much more consistent. We've done the
best we can by documenting the existing behavior, but if'we re going
to make major, potentially incompatible, CLI changes, this is
something to at least consider. Maybe with a config file for people
who really don't want to retrain their fingers to type the two extra
periods?
git format-patch origin/next.. works already. I'm used to the asymetric
git format-patch origin/next syntax, and I would be sorry if it
disappeared though, and I see no really good reason to get rid of it.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:45:33
Nicolas Pitre [off-list ref] wrote:
On Wed, 29 Oct 2008, Sam Vilain wrote:
quoted
From: Sam Vilain <redacted>
For cross-command CLI changes to be effective, they need to be
cohesively planned. Add a planning document for this next set of
changes.
Signed-off-by: Sam Vilain <redacted>
[...]
quoted
+ * 'git checkout branch' would, if there is a remote branch called
+ 'branch' on exactly one remote, do what
+ 'git checkout -b branch thatremote/branch' does now. If it is
+ ambiguous, it would be an error, forcing the explicit notation.
I can't do otherwise but disagree with this. Currently, when a remote
branch is checked out, the commit corresponding to that remote branch is
put on a detached head which is IMHO completely sane and coherent. It
even tells you how to create a local branch from there if that's what
you wanted to do. So if it is still too confusing at that point then
more explanations are needed and not the removal of a perfectly fine
feature. Please don't change that behavior.
+1 to Nico's NAK.
Although I was at the GitTogether I don't remember this change to
checkout being discussed. I must have been asleep reading email
or something. I am _NOT_ in favor of this change; I think the
current behavior of "git checkout origin/master" is correct and as
sane as we can make it.
--
Shawn.
From: Mike Hommey <hidden> Date: 2016-06-15 22:45:33
On Thu, Oct 30, 2008 at 07:52:53AM -0700, Shawn O. Pearce [off-list ref] wrote:
Nicolas Pitre [off-list ref] wrote:
quoted
On Wed, 29 Oct 2008, Sam Vilain wrote:
quoted
From: Sam Vilain <redacted>
For cross-command CLI changes to be effective, they need to be
cohesively planned. Add a planning document for this next set of
changes.
Signed-off-by: Sam Vilain <redacted>
[...]
quoted
+ * 'git checkout branch' would, if there is a remote branch called
+ 'branch' on exactly one remote, do what
+ 'git checkout -b branch thatremote/branch' does now. If it is
+ ambiguous, it would be an error, forcing the explicit notation.
I can't do otherwise but disagree with this. Currently, when a remote
branch is checked out, the commit corresponding to that remote branch is
put on a detached head which is IMHO completely sane and coherent. It
even tells you how to create a local branch from there if that's what
you wanted to do. So if it is still too confusing at that point then
more explanations are needed and not the removal of a perfectly fine
feature. Please don't change that behavior.
+1 to Nico's NAK.
Although I was at the GitTogether I don't remember this change to
checkout being discussed. I must have been asleep reading email
or something. I am _NOT_ in favor of this change; I think the
current behavior of "git checkout origin/master" is correct and as
sane as we can make it.
Except he was talking about 'git checkout branch', not 'git checkout
origin/branch'. And I would be fine with 'git checkout branch' doing
what 'git checkout -b branch $remote/branch' does if $remote is unique
(i.e. there is no other 'branch' branch in any other remote) and the
'branch' branch doesn't already exist.
Mike
From: Pierre Habouzit <hidden> Date: 2016-06-15 22:45:33
On Thu, Oct 30, 2008 at 02:59:28PM +0000, Mike Hommey wrote:
On Thu, Oct 30, 2008 at 07:52:53AM -0700, Shawn O. Pearce [off-list ref] wrote:
quoted
+1 to Nico's NAK.
Although I was at the GitTogether I don't remember this change to
checkout being discussed. I must have been asleep reading email
or something. I am _NOT_ in favor of this change; I think the
current behavior of "git checkout origin/master" is correct and as
sane as we can make it.
Except he was talking about 'git checkout branch', not 'git checkout
origin/branch'. And I would be fine with 'git checkout branch' doing
what 'git checkout -b branch $remote/branch' does if $remote is unique
(i.e. there is no other 'branch' branch in any other remote) and the
'branch' branch doesn't already exist.
Seconded.
Having git-checkout $foo being a shorthand for git checkout -b $foo
origin/$foo when origin/$foo exists and $foo doesn't is definitely handy.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:45:33
Theodore Tso wrote:
On Wed, Oct 29, 2008 at 08:48:05PM -0700, Sam Vilain wrote:
quoted
From: Sam Vilain <redacted>
For cross-command CLI changes to be effective, they need to be
cohesively planned. Add a planning document for this next set of
changes.
Here are my favorites:
* Add the command "git revert-file <files>" which is syntactic sugar for:
git checkout HEAD -- <files>
Rationale: Many other SCM's have a way of undoing local edits to a
file very simply, i.e."hg revert <file>" or "svn revert <file>", and
for many developers's workflow, it's useful to be able to undo local
edits to a single file, but not to everything else in the working
directory. And "git checkout HEAD -- <file>" is rather cumbersome
to type, and many beginning users don't find it intuitive to look in
the "git-checkout" man page for instructions on how to revert a
local file.
I like it, although I guess one would have to add a "--staged" flag to
git revert-file to be able to checkout files from index as well, or people
will wonder why that can't be done.
* Change the argument handling for "git format-patch" so it is
consistent with everything else which takes a set of commits. Yes,
it means that where people have gotten used to typing "git
format-patch origin", they'll have to type instead: "git
format-patch origin..", but's much more consistent. We've done the
best we can by documenting the existing behavior, but if'we re going
to make major, potentially incompatible, CLI changes, this is
something to at least consider. Maybe with a config file for people
who really don't want to retrain their fingers to type the two extra
periods?
"git format-patch" does exactly the same thing as other commit-range handling
commands do, which is assume that the missing commit end-point is HEAD, so it
actually is consistent, although it doesn't quite look as if it is.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
On Thu, Oct 30, 2008 at 03:48:05AM +0000, Sam Vilain wrote:
quoted
+Working with patches
+--------------------
+
+ * 'git send-email' should prompt for all SMTP-related information
+ about sending e-mail when it is running with no configuration.
+ Because these days /usr/lib/sendmail is rarely configured
+ correctly.
And when the user answer them, it should set them (a bit like zsh does
when it's run from the first time e.g.)
quoted
+
+ * other git send-email functionality which has bitten people -
+ particularly building the recipient list - should prompt for
+ confirmation until configured to be automatic.
+
* git-send-email should be either more interactive, or less: either
just use the damn configuration, or propose a mode where it spawns
an editor for each patch so that you can add further comments.
* git-send-email should be able to format-patches by himself (IOW
accept most of format-patch arguments and deal with the patch list
by himself, which is usable if the previous point is implemented).
This gets my vote ...
These are two of the reasons that I ended up ignoring git-send-email and
writing my own replacement. I found the whole format-patch/send-email
dance too cumbersome and confusing - particularly for sending a single
patch. To send a single patch I ended up with the command:
git mail-commmits --edit HEAD~1
It would be nice if I could replace this with:
git send-email --edit HEAD~1
;)
quoted
+ * 'git am -3' the default; with global option to make it not the
+ default for those that prefer the speed of -2
+
+
--
Julian
---
Blessed be those who initiate lively discussions with the hopelessly mute,
for they shall be know as Dentists.
On Thu, Oct 30, 2008 at 03:43:21PM +0100, Pierre Habouzit wrote:
git format-patch origin/next.. works already. I'm used to the asymetric
git format-patch origin/next syntax, and I would be sorry if it
disappeared though, and I see no really good reason to get rid of it.
The reason why it annoys me is because I often what to cherry-pick a
single patch to send to someone, and so while "git show 332d2e78"
shows me the patch, but if I want to use git-send-email for that
particular patch, "git format-patch 332d2e78" doesn't DTRT. I have to
type "git format-patch 332d2e78^..332d2e78" instead. I've learned to
live with it, but it's annoying each time I have to do it.
More generally, the fact that the CLI has different ways the same set
of arguments can be decoded can be quite confusing. The most obvious
way this turns up is to consider which set of commits are
displayed/formatted via these three commands:
git format-patch 332d2e78
git show 332d2e78
git log -p 332d2e78
The first formats all patches that follow commit 332d2e78 (not
including commit 332d2e78), the second shows just commit 332d2e78, and
the last prints all commits starting at 332d2e78 and before it.
For many workflows, the default way a single commit-id is interpreted
makes a lot of sense. But for a newcomer, it's very confusing. I'm
not saying that we should collapse everything down to a single way of
doing things, but git format-patch is an exception, and I don't think
anything else actually works that way; looking at the man page makes
it clear that it treats its argument as a revision range EXCEPT when
only a single commit is specified.
It can be justified, and maybe it's convenient enough that this is one
of those places where tutorials should just explicitly call this out
as one of those exceptions that make sense given common workflows.
But just as English can be heard to learn because "though", "through",
"plough", "cough", and "tough" don't rhyme even though they look like
they should (even though native speakers have no problem with it),
similarly this is one of those inconsistencies that makes git hard to
learn.
(And I get annoyed when I want to run git format-patch on a single
patch not at the tip of the tree; but if it's just me, I can write a
"git format-single-patch" wrapper script to get around it.)
- Ted
From: Pierre Habouzit <hidden> Date: 2016-06-15 22:45:33
On Thu, Oct 30, 2008 at 04:30:56PM +0000, Theodore Tso wrote:
On Thu, Oct 30, 2008 at 03:43:21PM +0100, Pierre Habouzit wrote:
quoted
git format-patch origin/next.. works already. I'm used to the asymetric
git format-patch origin/next syntax, and I would be sorry if it
disappeared though, and I see no really good reason to get rid of it.
The reason why it annoys me is because I often what to cherry-pick a
single patch to send to someone, and so while "git show 332d2e78"
shows me the patch, but if I want to use git-send-email for that
particular patch, "git format-patch 332d2e78" doesn't DTRT. I have to
type "git format-patch 332d2e78^..332d2e78" instead. I've learned to
live with it, but it's annoying each time I have to do it.
[...]
(And I get annoyed when I want to run git format-patch on a single
patch not at the tip of the tree; but if it's just me, I can write a
"git format-single-patch" wrapper script to get around it.)
In fact I believe that what we lack is a shorthand for:
$sha1^..$sha1 because that would solve both of your issues, and it's
something that has bothered me in the past too for other commands.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
From: Nicolas Pitre <hidden> Date: 2016-06-15 22:45:33
On Thu, 30 Oct 2008, Pierre Habouzit wrote:
On Thu, Oct 30, 2008 at 02:59:28PM +0000, Mike Hommey wrote:
quoted
On Thu, Oct 30, 2008 at 07:52:53AM -0700, Shawn O. Pearce [off-list ref] wrote:
quoted
+1 to Nico's NAK.
Although I was at the GitTogether I don't remember this change to
checkout being discussed. I must have been asleep reading email
or something. I am _NOT_ in favor of this change; I think the
current behavior of "git checkout origin/master" is correct and as
sane as we can make it.
Except he was talking about 'git checkout branch', not 'git checkout
origin/branch'. And I would be fine with 'git checkout branch' doing
what 'git checkout -b branch $remote/branch' does if $remote is unique
(i.e. there is no other 'branch' branch in any other remote) and the
'branch' branch doesn't already exist.
Seconded.
Having git-checkout $foo being a shorthand for git checkout -b $foo
origin/$foo when origin/$foo exists and $foo doesn't is definitely handy.
No. This is only the first step towards insanity.
In many cases origin/$foo == origin/master so this can't work in that
case which is, after all, the common case. Therefore I think this is
wrong to add magic operations which are not useful for the common case
and actively _hide_ how git actually works. Not only will you have to
explain how git works anyway for that common origin/master case, but
you'll also have to explain why sometimes the magic works and sometimes
not. Please keep such convenience shortcuts for your own scripts and/or
aliases.
Nicolas
From: Nicolas Pitre <hidden> Date: 2016-06-15 22:45:33
On Thu, 30 Oct 2008, Theodore Tso wrote:
On Thu, Oct 30, 2008 at 03:43:21PM +0100, Pierre Habouzit wrote:
quoted
git format-patch origin/next.. works already. I'm used to the asymetric
git format-patch origin/next syntax, and I would be sorry if it
disappeared though, and I see no really good reason to get rid of it.
The reason why it annoys me is because I often what to cherry-pick a
single patch to send to someone, and so while "git show 332d2e78"
shows me the patch, but if I want to use git-send-email for that
particular patch, "git format-patch 332d2e78" doesn't DTRT. I have to
type "git format-patch 332d2e78^..332d2e78" instead.
From: Sam Vilain <hidden> Date: 2016-06-15 22:45:33
On Thu, 2008-10-30 at 12:53 -0400, Nicolas Pitre wrote:
quoted
Seconded.
Having git-checkout $foo being a shorthand for git checkout -b $foo
origin/$foo when origin/$foo exists and $foo doesn't is definitely handy.
No. This is only the first step towards insanity.
In many cases origin/$foo == origin/master so this can't work in that
case which is, after all, the common case.
I don't understand that argument at all, can you explain further?
Therefore I think this is
wrong to add magic operations which are not useful for the common case
and actively _hide_ how git actually works. Not only will you have to
explain how git works anyway for that common origin/master case, but
you'll also have to explain why sometimes the magic works and sometimes
not. Please keep such convenience shortcuts for your own scripts and/or
aliases.
It's not about magic, it's about sensible defaults. Currently this use
case is an error, and the resultant command is very long to type, and
involves typing the branch name twice. I end up writing things like:
git checkout -b {,origin/}wr34251-do-something
For the user who doesn't know to use the ksh-style {} blocks this is
voodoo. The longer form is cumbersome.
For the case where the thing you type is a resolvable reference, it
would just check it out, as now.
Sam.
From: Sam Vilain <hidden> Date: 2016-06-15 22:45:33
On Thu, 2008-10-30 at 17:43 +0100, Pierre Habouzit wrote:
In fact I believe that what we lack is a shorthand for:
$sha1^..$sha1 because that would solve both of your issues, and it's
something that has bothered me in the past too for other commands.
There is already a shorthand for that;
$sha1^!
Indeed passing that to git-format-patch has the intended effect; it
causes it to save a patch for just the commit in question.
I agree that it would make more sense for the current behaviour to be
changed;
git format-patch origin/master..
Isn't that much more to type than:
git format-patch origin/master
And it makes the case where you just want to format a single patch work
better.
However, I worry about the backwards incompatibility. The other changes
I listed didn't really violate existing expectations.
That being said, the case where a single commit reference is passed,
with no range, should be relatively easy to detect. In this situation
it could return an error, and encourage the user to use "--since" or
"--only"; or to configure one of those to be the default.
I'm wondering whether it's worth building some kind of mechanism to
notice that settings like this have not been set, and to print a warning
like "warning: you are using a git that introduced minor command
changes; use 'git config --new' to pick your defaults" - that way,
changes to command operation could be introduced that would not annoy
older users so much.
Sam.
From: Sam Vilain <hidden> Date: 2016-06-15 22:45:33
On Thu, 2008-10-30 at 10:39 -0400, Theodore Tso wrote:
* Add the command "git revert-file <files>" which is syntactic sugar for:
git checkout HEAD -- <files>
Rationale: Many other SCM's have a way of undoing local edits to a
file very simply, i.e."hg revert <file>" or "svn revert <file>", and
for many developers's workflow, it's useful to be able to undo local
edits to a single file, but not to everything else in the working
directory. And "git checkout HEAD -- <file>" is rather cumbersome
to type, and many beginning users don't find it intuitive to look in
the "git-checkout" man page for instructions on how to revert a
local file.
Well, I don't have strong feelings on the exact command name used; I
suggested "undo", probably also ambiguous. But still, a significant
number of users are surprised when they type 'git revert' and they get a
backed out patch. It's such an uncommon operation, it doesn't deserve
to be triggered so easily. And reverting files to the state in the
index and/or HEAD is a common operation that deserves being short to
type.
Making it plain "revert" would violate expectations of existing users;
it seems a better idea to just deprecate it, and point the users to the
new method - cherry-pick --revert - or the command they might have meant
- whatever that becomes.
Sam.
From: Nicolas Pitre <hidden> Date: 2016-06-15 22:45:33
On Thu, 30 Oct 2008, Sam Vilain wrote:
On Thu, 2008-10-30 at 12:53 -0400, Nicolas Pitre wrote:
quoted
quoted
Seconded.
Having git-checkout $foo being a shorthand for git checkout -b $foo
origin/$foo when origin/$foo exists and $foo doesn't is definitely handy.
No. This is only the first step towards insanity.
In many cases origin/$foo == origin/master so this can't work in that
case which is, after all, the common case.
I don't understand that argument at all, can you explain further?
By default, git creates a branch called "master. Hence, by default, if
you clone that repository, this branch will be called origin/master. So
by default $foo is already ambiguous.
quoted
Therefore I think this is
wrong to add magic operations which are not useful for the common case
and actively _hide_ how git actually works. Not only will you have to
explain how git works anyway for that common origin/master case, but
you'll also have to explain why sometimes the magic works and sometimes
not. Please keep such convenience shortcuts for your own scripts and/or
aliases.
It's not about magic, it's about sensible defaults. Currently this use
case is an error, and the resultant command is very long to type, and
involves typing the branch name twice. I end up writing things like:
git checkout -b {,origin/}wr34251-do-something
For the user who doesn't know to use the ksh-style {} blocks this is
voodoo. The longer form is cumbersome.
This is no excuse for promoting semantics only useful in such special
cases.
For the case where the thing you type is a resolvable reference, it
would just check it out, as now.
As long as it checks it out with a detached head if it is a remote
branch then I have no issue.
Nicolas
On Thu, Oct 30, 2008 at 02:28:35PM -0400, Nicolas Pitre wrote:
quoted
It's not about magic, it's about sensible defaults. Currently this use
case is an error, and the resultant command is very long to type, and
involves typing the branch name twice. I end up writing things like:
git checkout -b {,origin/}wr34251-do-something
For the user who doesn't know to use the ksh-style {} blocks this is
voodoo. The longer form is cumbersome.
This is no excuse for promoting semantics only useful in such special
cases.
It is really not so rare to have an upstream repo with branches such
as "stable", "next" and the like. This syntax extension would make is
as straightforward to work on "stable" as it is on remote HEAD
(usually master, which has already been magically setup for you).
BTW this use case reminds me that the remote HEAD has its own special
treatment for "clone", which AFAIK cannot be overriden from
command-line (I still sometimes lack what cogito provided as "cg clone
URL#branch").
As long as it checks it out with a detached head if it is a remote
branch then I have no issue.
Yes it is possible, but that does not necessarily make a UI
improvement worthless.
Best regards,
--
Yann
On Thu, Oct 30, 2008 at 10:51:08AM -0700, Sam Vilain wrote:
Well, I don't have strong feelings on the exact command name used; I
suggested "undo", probably also ambiguous. But still, a significant
number of users are surprised when they type 'git revert' and they get a
backed out patch.
Yeah, that's why I suggested "git revert-file". It's less ambiguous
than "undo", and it's easier for people used to "hg revert" and "svn
revert" to find "git revert-file". And, it won't be run accidentally
by old-timers who are used to the old (to be deprecated) "git revert".
But I'm not that picky about the name; I just missed the "git undo"
proposal in your patch.
Making it plain "revert" would violate expectations of existing users;
it seems a better idea to just deprecate it, and point the users to the
new method - cherry-pick --revert - or the command they might have meant
- whatever that becomes.
Yup, I agree; that's why I suggested "git revert-file".
- Ted
From: Sam Vilain <hidden> Date: 2016-06-15 22:45:33
On Thu, 2008-10-30 at 14:28 -0400, Nicolas Pitre wrote:
quoted
For the case where the thing you type is a resolvable reference, it
would just check it out, as now.
As long as it checks it out with a detached head if it is a remote
branch then I have no issue.
Absolutely - if you've already got a branch "master", then
"git checkout master" should definitely give it to you. If you go
"git checkout origin/master", you get a floating head. But I quite often
find myself wanting to check out a remote branch, and give it a name just
like on the remote. I want "git checkout blah" to assume that's
what I mean, until I make a local branch "blah".
By default, git creates a branch called "master. Hence, by default, if
you clone that repository, this branch will be called origin/master. So
by default $foo is already ambiguous.
Right - 'master' in this case resolves to something. The ambiguity is
resolved by defaulting to the thing that resolves. The fall-back
behaviour is only triggered if you asked for something that is currently
an error. Because breaking expectations sucks.
Sam.
From: Jakub Narebski <hidden> Date: 2016-06-15 22:45:33
Sam Vilain wrote:
It's not about magic, it's about sensible defaults. Currently this use
case is an error, and the resultant command is very long to type, and
involves typing the branch name twice. I end up writing things like:
git checkout -b {,origin/}wr34251-do-something
Can't you use currently
git checkout --track origin/wr34251-do-something
P.S. Somehow I don't see first message in this thread on GMane...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
From: Jeff King <hidden> Date: 2016-06-15 22:45:33
On Thu, Oct 30, 2008 at 02:24:53PM +0100, Pierre Habouzit wrote:
quoted
+ * 'git stage' would do what 'git add' does now.
-> git stage -i/-p shall do what git add -i/-p does.
Yes, and that is obviously easy.
quoted
+ * 'git unstage' would do what 'git reset --' does now
-> likely we need a git unstage -i/-p to interactively unstage some
bits.
Agreed, though this is a bit harder. But I think this should go hand in
hand with "git stash -i" and "git stash apply -i" (as I mentioned in my
other mail in this thread).
-Peff
From: Sam Vilain <hidden> Date: 2016-06-15 22:45:33
On Fri, 2008-10-31 at 00:55 +0100, Jakub Narebski wrote:
quoted
involves typing the branch name twice. I end up writing things like:
git checkout -b {,origin/}wr34251-do-something
Can't you use currently
git checkout --track origin/wr34251-do-something
Ah, that's a new feature. Still, I think it's poorly Huffman coded; far
too verbose.
But let's resume this discussion after I dig up the old thread about
pushing and pulling too... I think it makes sense to look at this as a
whole.
Cheers,
Sam.
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:45:33
Hi,
On Thu, 30 Oct 2008, Pierre Habouzit wrote:
On Thu, Oct 30, 2008 at 02:59:28PM +0000, Mike Hommey wrote:
quoted
On Thu, Oct 30, 2008 at 07:52:53AM -0700, Shawn O. Pearce [off-list ref] wrote:
quoted
+1 to Nico's NAK.
Although I was at the GitTogether I don't remember this change to
checkout being discussed. I must have been asleep reading email
or something. I am _NOT_ in favor of this change; I think the
current behavior of "git checkout origin/master" is correct and as
sane as we can make it.
Except he was talking about 'git checkout branch', not 'git checkout
origin/branch'. And I would be fine with 'git checkout branch' doing
what 'git checkout -b branch $remote/branch' does if $remote is unique
(i.e. there is no other 'branch' branch in any other remote) and the
'branch' branch doesn't already exist.
Seconded.
Having git-checkout $foo being a shorthand for git checkout -b $foo
origin/$foo when origin/$foo exists and $foo doesn't is definitely handy.
Have you guys actually checked out what
git checkout -t origin/foo
does?
Ciao,
Dscho
Hi,
Good list.. I agree with others that the 'undo' name doesn't sound
right (and will discuss other issues with it in response to another
email) but otherwise nice work.
On Wed, Oct 29, 2008 at 9:48 PM, Sam Vilain [off-list ref] wrote:
+ * 'git push' to checked out branch of non-bare repository not
+ allowed without special configuration. Configuration available
+ that allows working directory to be updated, known caveats
+ notwithstanding. Ideally, it would refuse only in situations
+ where a broken working copy would be left (because you couldn't
+ fix it), and work when it can be known to be safe.
Configuration of remote repository, special command-line override, or both?
Some food for thought: One thing I did in EasyGit was to disallow
pushes to non-bare repositories* unless both source and destinations
references were explicitly specified. For example:
$ eg push origin master # or 'eg push', in this case
Aborting: You are trying to push to a repository with an associated working
copy, which will leave its working copy out of sync with its repository.
Rather than pushing changes to that repository, you should go to where that
repository is located and pull changes into it (using eg pull). If you
know what you are doing and know how to deal with the consequences, you can
override this check by explicitly specifying source and destination
references, e.g.
eg push REMOTE BRANCH:REMOTE_BRANCH
Please refer to
eg help topic refspecs
to learn what this syntax means and what the consequences of overriding this
check are.
$ eg push origin master:master
Counting objects: 5, done.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 260 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
To /home/newren/testing/dumb/.git
852ffee..f5596e4 master -> master
This seems to prevent errors for new users, while still allowing
people to work around firewall issues.
* The big problem was that I was only able to detect if a remote
repository was bare or not if it was accessed via the local filesystem
or via ssh; for git:// (or rsync://) repositories I didn't know how to
perform such a check and so I simply omitted it.
Elijah
Hi,
On Thu, Oct 30, 2008 at 8:39 AM, Theodore Tso [off-list ref] wrote:
Here are my favorites:
* Add the command "git revert-file <files>" which is syntactic sugar for:
git checkout HEAD -- <files>
Rationale: Many other SCM's have a way of undoing local edits to a
file very simply, i.e."hg revert <file>" or "svn revert <file>", and
for many developers's workflow, it's useful to be able to undo local
edits to a single file, but not to everything else in the working
directory. And "git checkout HEAD -- <file>" is rather cumbersome
to type, and many beginning users don't find it intuitive to look in
the "git-checkout" man page for instructions on how to revert a
local file.
I agree with the rationale, but the suggested implementation (as with
the original suggestion for "git undo") is somewhat problematic. I
have a write-up somewhere documenting the ways various individual git
commands fail to be an appropriate replacement for svn/hg/bzr
revert[1], but in short the "git checkout HEAD -- <file>"
implementation for svn/hg/bzr-like revert fails in the following ways:
* It does not work for the initial commit
* It won't untrack or remove files (this is related to the previous
and following items)
* It doesn't allow reverting a file or directory to a revision prior
to HEAD (making it like svn; note though that both bzr and hg have
such an option and I have found it handy a few times)
* It's inappropriate to use during an incomplete merge.
The incomplete merge case is particularly interesting. If the user
specifies a file or subdirectory, they should also specify a branch to
revert relative to (and it should be an error if they don't). If the
user specifies "." then there's the question of whether they are
attempting to undo the merge (meaning that .git/MERGE_MSG and
.git/MERGE_HEAD should be removed).
Just as food for thought, here's what eg does in the incomplete merge case:
$ eg revert foo
Aborting: Cannot revert the changes since the last commit, since you are in
the middle of a merge and there are multiple last commits. Please add
--since BRANCH
to your flags to eg revert, where BRANCH is one of
master, devel
If you simply want to abort your merge and undo its conflicts, run
eg revert --since HEAD
There's a couple more issues here that I could go on about, but I'll
mention just one more thing for this email: Since users often get
confused between different kinds of "reverting" or "undoing", a plain
'eg revert' is also pretty helpful in a wide variety of circumstances
(it always aborts with an error message, but one that detects what the
user might want and suggests appropriate commands in the various
cases.)
Elijah
[1] There are a number of different commands that people suggest for
new users to replace other systems' revert behavior, but each has
areas in which it will fail to do what users expect or do additional
things users don't want (including discarding data) Interestingly,
I've tried four different alternative git porcelains and each one
implemented their svn/hg/bzr-like revert incorrectly. One of these
was EasyGit, in which I got it wrong not once but three separate
times. (And if alternative porcelain authors can't easily get it
right, we clearly can't expect normal users to know how to do so; I
think this is a pretty good argument for providing a function for this
behavior in core git.) I think I finally have it implemented
correctly now in EasyGit, after my fourth try...
Hi,
On Thu, Oct 30, 2008 at 9:02 AM, Andreas Ericsson [off-list ref] wrote:
I like it, although I guess one would have to add a "--staged" flag to
git revert-file to be able to checkout files from index as well, or people
will wonder why that can't be done.
Ew. 'git revert-file --staged foo'? If you want to revert the
*unstaged* changes of a file, it should be 'git revert-file --unstaged
foo'.
I would expect 'git revert-file --staged foo' to revert the staged
changes in foo, i.e. it should do what 'git reset -- foo' does (except
that it should also work for the initial commit). Thus, there'd be
little need for a --staged flag to revert-file, unless we allowed
reverting individual files back to some revision prior to HEAD (like
bzr and hg do)...
Hi,
(Sorry for sending so many emails, and being late to the conversation.
There's a couple others that I wanted to respond to but I'll wait off
on those and finish with this email to avoid spamming everyone any
more right now.)
On Thu, Oct 30, 2008 at 11:51 AM, Sam Vilain [off-list ref] wrote:
Well, I don't have strong feelings on the exact command name used; I
suggested "undo", probably also ambiguous. But still, a significant
number of users are surprised when they type 'git revert' and they get a
backed out patch. It's such an uncommon operation, it doesn't deserve
to be triggered so easily. And reverting files to the state in the
index and/or HEAD is a common operation that deserves being short to
type.
Making it plain "revert" would violate expectations of existing users;
it seems a better idea to just deprecate it, and point the users to the
new method - cherry-pick --revert - or the command they might have meant
- whatever that becomes.
There is another option, though it has its own problems too. There
are basically two kinds of reverting here -- reverting all the changes
*in* a given revision (which I'll called 'revert-in') and reverting
all the changes *since* a given revision (typically HEAD; I'll call
this 'revert-since'). These two operations can be supported from the
same command, though their use cases are different enough that it may
seem slightly weird:
revert-since revert-in
* is usually used in a dirty tree * is typically used in a clean tree
* specific paths are usually * specific paths are not often
specified specified
* it is rare to want to commit * making a commit after reverting
immediately after reverting is what you usually want
* it is uncommon to need to
specify a revision
I decided to combine them in EasyGit, simply because that made things
the most discoverable for both existing git and svn/bzr/hg users. The
big problem here is that --commit is turned on by default when --in is
specified, and --no-commit is the default when --since is specified.
Anyway, some examples:
eg revert REVISION => Error -- you must specify either --since or
--in when specifying a revision
eg revert --in REVISION => Same as git revert REVISION
eg revert --since HEAD FILE1 FILE2 => Same as svn revert FILE1 FILE2
eg revert FILE1 FILE2 => shorthand for the previous command; --since
HEAD is default when no revision is specified
eg revert --since HEAD~3 SUBDIRECTORY => should be clear; an extension
over what svn revert can do
Then there's also the possibility that users only want to revert
unstaged changes, or only want to revert staged changes...
Anyway, just some food for thought. I've spammed the list enough in
this thread, so I'll break for now. Thanks for listening.
Elijah
On Sat, Nov 01, 2008 at 02:27:03PM -0600, Elijah Newren wrote:
There is another option, though it has its own problems too. There
are basically two kinds of reverting here -- reverting all the changes
*in* a given revision (which I'll called 'revert-in') and reverting
all the changes *since* a given revision (typically HEAD; I'll call
this 'revert-since'). These two operations can be supported from the
same command, though their use cases are different enough that it may
seem slightly weird:
In my opinion, that is a Really Bad Idea from a usability and UI
design point of view. Each command should do one and only one thing,
and not do different things depending on what options you give it.
Git violates this rules in a number of places already, What you call
"revert-since" and "revert-in" are so different that using the same
subcommand is just going to horribly confuse users.
Better to have "git revert" print a message explining that it is
deprecated, and to tell users that they probably want either "git
cherry-pick --revert" or "git revert-file", depending on whether they
are an experienced git user (in which case they probably want git
cherry-pick --revert"), or if that person who is familiar svn or hg's
"svn revert" or "hg revert", they probably want "git revert-file".
- Ted
On Sat, Nov 1, 2008 at 7:06 PM, Theodore Tso [off-list ref] wrote:
In my opinion, that is a Really Bad Idea from a usability and UI
design point of view. Each command should do one and only one thing,
and not do different things depending on what options you give it.
Git violates this rules in a number of places already, What you call
"revert-since" and "revert-in" are so different that using the same
subcommand is just going to horribly confuse users.
Better to have "git revert" print a message explining that it is
deprecated, and to tell users that they probably want either "git
cherry-pick --revert" or "git revert-file", depending on whether they
are an experienced git user (in which case they probably want git
cherry-pick --revert"), or if that person who is familiar svn or hg's
"svn revert" or "hg revert", they probably want "git revert-file".
Yeah, good points. I guess I could just make --no-commit the default
in all cases to remove the "magic", but then it's too much typing for
the revert-in case ("eg revert --commit --in REVISION" vs. "git revert
REVISION"). Two separate commands may make more sense, but then
there's the naming issue (I had difficulty coming up with a different
name that I liked, and it appears others are having a little trouble
with the naming too). Tough nut to crack from any angle. :-(
From: Sam Vilain <hidden> Date: 2016-06-15 22:45:34
On Fri, 2008-10-31 at 08:36 +0100, Jakub Narebski wrote:
quoted
quoted
git checkout --track origin/wr34251-do-something
Ah, that's a new feature. Still, I think it's poorly Huffman coded; far
too verbose.
Well, either you have a little bit more verbose, or you have to have
some DWIM-mery, which (as usual with DWIM) can go wrong.
That's right, you need to choose when to assume that the user meant
something that they didn't write very carefully.
But look at this:
git checkout origin/master
git checkout -t origin/master
The option is called "--track", yet in this case what it actually means
in the default situation where you have autosetupmerge (or whatever it's
really called) set to true, is that it modifies the command to imply "-b
master". So, in this situation, that is clearly what was meant.
Perhaps you can give an example of why this particular piece of DWIM
might not be WYM?
Sam.
From: Jakub Narebski <hidden> Date: 2016-06-15 22:45:34
Dnia poniedziałek 3. listopada 2008 09:43, Sam Vilain napisał:
On Fri, 2008-10-31 at 08:36 +0100, Jakub Narebski wrote:
quoted
quoted
quoted
git checkout --track origin/wr34251-do-something
Ah, that's a new feature. Still, I think it's poorly Huffman coded; far
too verbose.
Well, either you have a little bit more verbose, or you have to have
some DWIM-mery, which (as usual with DWIM) can go wrong.
That's right, you need to choose when to assume that the user meant
something that they didn't write very carefully.
But look at this:
git checkout origin/master
git checkout -t origin/master
The option is called "--track", yet in this case what it actually means
in the default situation where you have autosetupmerge (or whatever it's
really called) set to true, is that it modifies the command to imply "-b
master". So, in this situation, that is clearly what was meant.
Perhaps you can give an example of why this particular piece of DWIM
might not be WYM?
I was not talking about "git checkout -t origin/master" being shortcut
for "git checkout -b master -t origin/master", but about proposed
DWIM-mery for "git checkout -b <branch>" which would be
{ git checkout -b <branch> -t <remote>/<branch>
git checkout -b <branch> = { if there exists <remote>/<branch>
{
{ git checkout -b <branch> HEAD
{ otherwise
--
Jakub Narebski
Poland
On Thu, Oct 30, 2008 at 6:55 AM, Stefan Karpinski
[off-list ref] wrote:
On Wed, Oct 29, 2008 at 8:48 PM, Sam Vilain [off-list ref] wrote:
quoted
+ * 'git export' command that does what
+ 'git archive --format=tar --prefix=dir | tar x' does now
It would be nice if the "git export" command could "checkout" a
non-repo copy of a remote repo at a specific version. This would be as
simple as calling archive on the remote size and then unarchiving it
locally. But would of course take care of all the plumbing.
I'm not sure whether the "git archive | tar" or the following is more efficient:
export GIT_INDEX_FILE="$(mktemp .git/export-index.XXXXXX)"
git read-tree -i "$1"
git checkout-index -f -a --prefix="$2/"
Cheers,
Kyle Moffett