From: Junio C Hamano <hidden> Date: 2016-06-15 22:43:47
Johannes Schindelin [off-list ref] writes:
On Mon, 5 Nov 2007, Junio C Hamano wrote:
quoted
Allowing people to revert or cherry pick partially by using paths
limiter is a very good idea; the whole "it comes from a commit so we
also commit" feels an utter nonsense, though.
No.
When "git revert <commit>" commits the result, "git revert <commit> --
<file>" should, too.
I was not questioning about that part. "If 'git revert <some
other form> foo' does not talk about commit, it should not
commit" was what I was referring to.
From: Pierre Habouzit <hidden> Date: 2016-06-15 22:43:47
On Tue, Nov 06, 2007 at 04:54:02AM +0000, Junio C Hamano wrote:
Johannes Schindelin [off-list ref] writes:
quoted
On Mon, 5 Nov 2007, Junio C Hamano wrote:
quoted
Allowing people to revert or cherry pick partially by using paths
limiter is a very good idea; the whole "it comes from a commit so we
also commit" feels an utter nonsense, though.
No.
When "git revert <commit>" commits the result, "git revert <commit> --
<file>" should, too.
I was not questioning about that part. "If 'git revert <some
other form> foo' does not talk about commit, it should not
commit" was what I was referring to.
Well, I don't really know how closely you read #git, but I'd say that
"how do I undo my local changes in a git repository" is among the top 3
questions. There _IS_ an UI issue for that.
If git revert <commitish> -- path1 path2 path3 is going to work at some
point, I see no harm in saying that git revert HEAD -- path1 path2 path3
work. We can also in that case spit an error message:
error: this works as a courtesy but you really meant git checkout -- path/to/file
On some other issues I'm all about educating people and learning to
them how to "think different". But here it's a pure interface problem,
and git is the sole $scm with a revert commands that doesn't reverts
local changes wrt HEAD.
The next release of master will have tons of UI improvements (terse
output, better options parsing, more builtins hence faster commands …),
I believe it's stopping halfway not thinking about issues like this from
a newcomer point of view.
On the pure theoretical basis I believe you're right, it's a bit
mixing apples and oranges. On the pragmatic usability side I'm quite
sure you're wrong, because everyone is used to that:
$ hg revert --help | head -3 | tail -1
revert files or dirs to their states as of some revision
$ bzr help revert | head -1
Purpose: Revert files to a previous revision.
$ svn help revert | head -1
revert: Restore pristine working copy file (undo most local edits).
$ darcs help revert | head -3 | tail -1
Revert to the recorded version (safe the first time only).
<put your favorite non-git scm with a revert command here>
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
From: Mike Hommey <hidden> Date: 2016-06-15 22:43:47
On Tue, Nov 06, 2007 at 09:49:25AM +0100, Pierre Habouzit [off-list ref] wrote:
On Tue, Nov 06, 2007 at 04:54:02AM +0000, Junio C Hamano wrote:
quoted
Johannes Schindelin [off-list ref] writes:
quoted
On Mon, 5 Nov 2007, Junio C Hamano wrote:
quoted
Allowing people to revert or cherry pick partially by using paths
limiter is a very good idea; the whole "it comes from a commit so we
also commit" feels an utter nonsense, though.
No.
When "git revert <commit>" commits the result, "git revert <commit> --
<file>" should, too.
I was not questioning about that part. "If 'git revert <some
other form> foo' does not talk about commit, it should not
commit" was what I was referring to.
Well, I don't really know how closely you read #git, but I'd say that
"how do I undo my local changes in a git repository" is among the top 3
questions. There _IS_ an UI issue for that.
If git revert <commitish> -- path1 path2 path3 is going to work at some
point, I see no harm in saying that git revert HEAD -- path1 path2 path3
work. We can also in that case spit an error message:
It seems to me git revert HEAD -- path1 path2 path3 should revert the changes
made in the commit pointed to by HEAD, not revert the changes in the working
tree or the index...
Mike
From: Pierre Habouzit <hidden> Date: 2016-06-15 22:43:47
On Tue, Nov 06, 2007 at 09:29:42AM +0000, Mike Hommey wrote:
On Tue, Nov 06, 2007 at 09:49:25AM +0100, Pierre Habouzit [off-list ref] wrote:
quoted
On Tue, Nov 06, 2007 at 04:54:02AM +0000, Junio C Hamano wrote:
quoted
Johannes Schindelin [off-list ref] writes:
quoted
On Mon, 5 Nov 2007, Junio C Hamano wrote:
quoted
Allowing people to revert or cherry pick partially by using paths
limiter is a very good idea; the whole "it comes from a commit so we
also commit" feels an utter nonsense, though.
No.
When "git revert <commit>" commits the result, "git revert <commit> --
<file>" should, too.
I was not questioning about that part. "If 'git revert <some
other form> foo' does not talk about commit, it should not
commit" was what I was referring to.
Well, I don't really know how closely you read #git, but I'd say that
"how do I undo my local changes in a git repository" is among the top 3
questions. There _IS_ an UI issue for that.
If git revert <commitish> -- path1 path2 path3 is going to work at some
point, I see no harm in saying that git revert HEAD -- path1 path2 path3
work. We can also in that case spit an error message:
It seems to me git revert HEAD -- path1 path2 path3 should revert the changes
made in the commit pointed to by HEAD, not revert the changes in the working
tree or the index...
Yes, sorry, the `HEAD` in my sentence was spurious.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:43:47
Hi,
On Mon, 5 Nov 2007, Junio C Hamano wrote:
Johannes Schindelin [off-list ref] writes:
quoted
On Mon, 5 Nov 2007, Junio C Hamano wrote:
quoted
Allowing people to revert or cherry pick partially by using paths
limiter is a very good idea; the whole "it comes from a commit so we
also commit" feels an utter nonsense, though.
No.
When "git revert <commit>" commits the result, "git revert <commit> --
<file>" should, too.
I was not questioning about that part. "If 'git revert <some
other form> foo' does not talk about commit, it should not
commit" was what I was referring to.
Well, I think that _if_ we allow "git revert <path>" to mean "revert the
changes to <path>, relative to the index" (which would be the same as "git
checkout <path>"), then committing that change just does not make sense.
And it is this behaviour that people are seeking, not "git revert <commit>
<path>".
Ciao,
Dscho
From: Robin Rosenberg <hidden> Date: 2016-06-15 22:43:47
tisdag 06 november 2007 skrev Johannes Schindelin:
Hi,
On Mon, 5 Nov 2007, Junio C Hamano wrote:
quoted
Johannes Schindelin [off-list ref] writes:
quoted
On Mon, 5 Nov 2007, Junio C Hamano wrote:
quoted
Allowing people to revert or cherry pick partially by using paths
limiter is a very good idea; the whole "it comes from a commit so we
also commit" feels an utter nonsense, though.
No.
When "git revert <commit>" commits the result, "git revert <commit> --
<file>" should, too.
I was not questioning about that part. "If 'git revert <some
other form> foo' does not talk about commit, it should not
commit" was what I was referring to.
Well, I think that _if_ we allow "git revert <path>" to mean "revert the
changes to <path>, relative to the index" (which would be the same as "git
checkout <path>"), then committing that change just does not make sense.
And it is this behaviour that people are seeking, not "git revert <commit>
<path>".
I'm not convince making every command perform enitrely all kinds of actions
just because other SCMs interpret a name differently. git revert today
creates a *new* commit. Keep it simple. I think its ok that it mentions
another comnand when it detects arguments that does not make sense. There is
no right or wrong with interepreting reset either way, but not both ways
please. The confusion with checkout and reset is enough.
-- robin
From: Mike Hommey <hidden> Date: 2016-06-15 22:43:47
On Tue, Nov 06, 2007 at 09:06:56PM +0100, Robin Rosenberg wrote:
tisdag 06 november 2007 skrev Johannes Schindelin:
quoted
Hi,
On Mon, 5 Nov 2007, Junio C Hamano wrote:
quoted
Johannes Schindelin [off-list ref] writes:
quoted
On Mon, 5 Nov 2007, Junio C Hamano wrote:
quoted
Allowing people to revert or cherry pick partially by using paths
limiter is a very good idea; the whole "it comes from a commit so we
also commit" feels an utter nonsense, though.
No.
When "git revert <commit>" commits the result, "git revert <commit> --
<file>" should, too.
I was not questioning about that part. "If 'git revert <some
other form> foo' does not talk about commit, it should not
commit" was what I was referring to.
Well, I think that _if_ we allow "git revert <path>" to mean "revert the
changes to <path>, relative to the index" (which would be the same as "git
checkout <path>"), then committing that change just does not make sense.
And it is this behaviour that people are seeking, not "git revert <commit>
<path>".
I'm not convince making every command perform enitrely all kinds of actions
just because other SCMs interpret a name differently. git revert today
creates a *new* commit. Keep it simple. I think its ok that it mentions
another comnand when it detects arguments that does not make sense. There is
no right or wrong with interepreting reset either way, but not both ways
please. The confusion with checkout and reset is enough.
Maybe the documentation could emphasise on how to undo things when the
user makes mistakes.
Sometimes, saving your repo can be as simple as git reset --hard HEAD@{1}.
This is not, unfortunately, a works-for-all-cases command.
Mike
From: Robin Rosenberg <hidden> Date: 2016-06-15 22:43:47
tisdag 06 november 2007 skrev Mike Hommey:
Maybe the documentation could emphasise on how to undo things when the
user makes mistakes.
Sometimes, saving your repo can be as simple as git reset --hard HEAD@{1}.
This is not, unfortunately, a works-for-all-cases command.
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:43:47
Hi,
On Tue, 6 Nov 2007, Robin Rosenberg wrote:
tisdag 06 november 2007 skrev Mike Hommey:
quoted
Maybe the documentation could emphasise on how to undo things when the
user makes mistakes.
Sometimes, saving your repo can be as simple as git reset --hard HEAD@{1}.
This is not, unfortunately, a works-for-all-cases command.
Yea, git-undo(7).
In related news, I know a few users who need an un-rm-rf. Anyone?
Ciao,
Dscho
From: Mike Hommey <hidden> Date: 2016-06-15 22:43:48
On Tue, Nov 06, 2007 at 10:25:48PM +0000, Johannes Schindelin [off-list ref] wrote:
Hi,
On Tue, 6 Nov 2007, Robin Rosenberg wrote:
quoted
tisdag 06 november 2007 skrev Mike Hommey:
quoted
Maybe the documentation could emphasise on how to undo things when the
user makes mistakes.
Sometimes, saving your repo can be as simple as git reset --hard HEAD@{1}.
This is not, unfortunately, a works-for-all-cases command.
Yea, git-undo(7).
In related news, I know a few users who need an un-rm-rf. Anyone?
The fact is you can do harm to your repo with things you wouldn't expect to
break things, except maybe you gave bad arguments or so. It's quite easy to
fuck up with git-rebase, or to merge the wrong commits, etc.
Mike
From: David Kastrup <hidden> Date: 2016-06-15 22:43:48
Johannes Schindelin [off-list ref] writes:
On Tue, 6 Nov 2007, Robin Rosenberg wrote:
quoted
tisdag 06 november 2007 skrev Mike Hommey:
quoted
Maybe the documentation could emphasise on how to undo things when the
user makes mistakes.
Sometimes, saving your repo can be as simple as git reset --hard HEAD@{1}.
This is not, unfortunately, a works-for-all-cases command.
Yea, git-undo(7).
In related news, I know a few users who need an un-rm-rf. Anyone?
Most file systems don't have a reflog or other ways to recover from
shooting yourself in the foot. git has, and for good reason.
There is no sense in hiding that facility away because of feeling
macho. Since git already keeps the file space around needed for
recovery (and you really have to exert yourself to make it let go for
good), there is no point in not making it as convenient as feasible to
recover.
--
David Kastrup
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:43:48
Hi,
On Wed, 7 Nov 2007, Mike Hommey wrote:
On Tue, Nov 06, 2007 at 10:25:48PM +0000, Johannes Schindelin [off-list ref] wrote:
quoted
On Tue, 6 Nov 2007, Robin Rosenberg wrote:
quoted
tisdag 06 november 2007 skrev Mike Hommey:
quoted
Maybe the documentation could emphasise on how to undo things when
the user makes mistakes. Sometimes, saving your repo can be as
simple as git reset --hard HEAD@{1}. This is not, unfortunately, a
works-for-all-cases command.
Yea, git-undo(7).
In related news, I know a few users who need an un-rm-rf. Anyone?
The fact is you can do harm to your repo with things you wouldn't expect
to break things, except maybe you gave bad arguments or so. It's quite
easy to fuck up with git-rebase, or to merge the wrong commits, etc.
I don't see how these commands are dangerous. Usually you just look into
the reflog, pick the one commit you started with, and reset --hard.
The _only_ commands I find dangerous are "git stash clear" and "git reflog
--expire=0". Funnily, people want to do that all the time.
Like recently, on the IRC channel, where somebody lost patches "during a
rebase", by "rm -rf .dotest".
There will be a point where nobody can help. But before that, reflogs are
your friend. But you must not do "reset --hard HEAD@{1}" blindly. You
have to look first what the reflogs are.
Ciao,
Dscho
From: Robin Rosenberg <hidden> Date: 2016-06-15 22:43:48
onsdag 07 november 2007 skrev Johannes Schindelin:
Hi,
On Wed, 7 Nov 2007, Mike Hommey wrote:
quoted
On Tue, Nov 06, 2007 at 10:25:48PM +0000, Johannes Schindelin [off-list ref] wrote:
quoted
On Tue, 6 Nov 2007, Robin Rosenberg wrote:
quoted
tisdag 06 november 2007 skrev Mike Hommey:
quoted
Maybe the documentation could emphasise on how to undo things when
the user makes mistakes. Sometimes, saving your repo can be as
simple as git reset --hard HEAD@{1}. This is not, unfortunately, a
works-for-all-cases command.
Yea, git-undo(7).
In related news, I know a few users who need an un-rm-rf. Anyone?
The fact is you can do harm to your repo with things you wouldn't expect
to break things, except maybe you gave bad arguments or so. It's quite
easy to fuck up with git-rebase, or to merge the wrong commits, etc.
I don't see how these commands are dangerous. Usually you just look into
the reflog, pick the one commit you started with, and reset --hard.
Indeed, but you must *know* that and you must know that you *can* do it.
As for undo rm -rf, it's not part of git and outside the scope of git.
-- robin