threads / patch / 16109

patchprepare deprecation of git-revert

Subject: [PATCH] prepare deprecation of git-revert

## tl;dr

16 messages between Oct 31, 2008 and Nov 2, 2008. Diffs are folded; open one to read it.

replies: 15people: 10as markdown or json

Pierre Habouzit· Oct 31, 2008, 15:55 UTC · lore
* Rename builtin-revert.c into builtin-cherry-pick.c
* Add option -R/--revert to git-cherry-pick.
  Document it by taking the current content of git-revert manpage for the
  option.
* get rid of the no_replay initialization, just ignore it when we're in
  the revert case, it makes really no sense to error out.
* put the warning of deprecation in cmd_revert, #if 0-ed out for now.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
 I've not kept the auto-edit feature of git-revert for the git-cherry-pick -R
 case as I don't believe it makes a lot of sense. But if people are unhappy
 with that, I can easily "fix" it.
 Documentation/git-cherry-pick.txt         |   15 +++++++++++++++
 Makefile                                  |    6 +++---
 builtin-revert.c => builtin-cherry-pick.c |   10 ++++------
 3 files changed, 22 insertions(+), 9 deletions(-)
 rename builtin-revert.c => builtin-cherry-pick.c (98%)
Show changes to 4 files +22 −9

Documentation/git-cherry-pick.txt, Makefile, builtin-revert.c, builtin-cherry-pick.c

diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt
index 837fb08..2d92f2d 100644
--- a/Documentation/git-cherry-pick.txt
+++ b/Documentation/git-cherry-pick.txt
@@ -40,6 +40,21 @@ OPTIONS
 	development branch), adding this information can be
 	useful.
 
+-R::
+--revert::
+	Given one existing commit, revert the change the patch introduces, and
+	record a new commit that records it.  This requires your working tree
+	to be clean (no modifications from the HEAD commit).
++
+Note: 'git revert' is used to record a new commit to reverse the
+effect of an earlier commit (often a faulty one).  If you want to
+throw away all uncommitted changes in your working directory, you
+should see linkgit:git-reset[1], particularly the '--hard' option.  If
+you want to extract specific files as they were in another commit, you
+should see linkgit:git-checkout[1], specifically the 'git checkout
+<commit> -- <filename>' syntax.  Take care with these alternatives as
+both will discard uncommitted changes in your working directory.
+
 -r::
 	It used to be that the command defaulted to do `-x`
 	described above, and `-r` was to disable it.  Now the
diff --git a/Makefile b/Makefile
index d6f3695..43eb8e4 100644
--- a/Makefile
+++ b/Makefile
@@ -306,7 +306,7 @@ PROGRAMS += git-var$X
 # builtin-$C.o but is linked in as part of some other command.
 BUILT_INS += $(patsubst builtin-%.o,git-%$X,$(BUILTIN_OBJS))
 
-BUILT_INS += git-cherry-pick$X
+BUILT_INS += git-revert$X
 BUILT_INS += git-cherry$X
 BUILT_INS += git-format-patch$X
 BUILT_INS += git-fsck-objects$X
@@ -508,6 +508,7 @@ BUILTIN_OBJS += builtin-check-attr.o
 BUILTIN_OBJS += builtin-check-ref-format.o
 BUILTIN_OBJS += builtin-checkout-index.o
 BUILTIN_OBJS += builtin-checkout.o
+BUILTIN_OBJS += builtin-cherry-pick.o
 BUILTIN_OBJS += builtin-clean.o
 BUILTIN_OBJS += builtin-clone.o
 BUILTIN_OBJS += builtin-commit-tree.o
@@ -556,7 +557,6 @@ BUILTIN_OBJS += builtin-rerere.o
 BUILTIN_OBJS += builtin-reset.o
 BUILTIN_OBJS += builtin-rev-list.o
 BUILTIN_OBJS += builtin-rev-parse.o
-BUILTIN_OBJS += builtin-revert.o
 BUILTIN_OBJS += builtin-rm.o
 BUILTIN_OBJS += builtin-send-pack.o
 BUILTIN_OBJS += builtin-shortlog.o
@@ -1261,7 +1261,7 @@ git-http-push$X: revision.o http.o http-push.o $(GITLIBS)
 
 $(LIB_OBJS) $(BUILTIN_OBJS): $(LIB_H)
 $(patsubst git-%$X,%.o,$(PROGRAMS)): $(LIB_H) $(wildcard */*.h)
-builtin-revert.o wt-status.o: wt-status.h
+builtin-cherry-pick.o wt-status.o: wt-status.h
 
 $(LIB_FILE): $(LIB_OBJS)
 	$(QUIET_AR)$(RM) $@ && $(AR) rcs $@ $(LIB_OBJS)
diff --git a/builtin-revert.c b/builtin-cherry-pick.c
similarity index 98%
rename from builtin-revert.c
rename to builtin-cherry-pick.c
index 4038b41..d1a7188 100644
--- a/builtin-revert.c
+++ b/builtin-cherry-pick.c
@@ -57,6 +57,7 @@ static void parse_args(int argc, const char **argv)
 		OPT_BOOLEAN('r', NULL, &noop, "no-op (backward compatibility)"),
 		OPT_BOOLEAN('s', "signoff", &signoff, "add Signed-off-by:"),
 		OPT_INTEGER('m', "mainline", &mainline, "parent number"),
+		OPT_SET_INT('R', "revert", &action, "cherry-pick a reverted patch", REVERT),
 		OPT_END(),
 	};
 
@@ -261,10 +262,6 @@ static int revert_or_cherry_pick(int argc, const char **argv)
 	setenv(GIT_REFLOG_ACTION, me, 0);
 	parse_args(argc, argv);
 
-	/* this is copied from the shell script, but it's never triggered... */
-	if (action == REVERT && !no_replay)
-		die("revert is incompatible with replay");
-
 	if (read_cache() < 0)
 		die("git %s: failed to read the index", me);
 	if (no_commit) {
@@ -439,16 +436,17 @@ static int revert_or_cherry_pick(int argc, const char **argv)
 
 int cmd_revert(int argc, const char **argv, const char *prefix)
 {
+#if 0
+	warning("git revert is deprecated, please use git cherry-pick --revert/-R instead");
+#endif
 	if (isatty(0))
 		edit = 1;
-	no_replay = 1;
 	action = REVERT;
 	return revert_or_cherry_pick(argc, argv);
 }
 
 int cmd_cherry_pick(int argc, const char **argv, const char *prefix)
 {
-	no_replay = 0;
 	action = CHERRY_PICK;
 	return revert_or_cherry_pick(argc, argv);
 }
-- 
1.6.0.3.790.ga4dd7.dirty
Pierre Habouzit· Oct 31, 2008, 15:57 UTC · re: Pierre Habouzit · lore

Re: [PATCH] prepare deprecation of git-revert

On Fri, Oct 31, 2008 at 03:55:27PM +0000, Pierre Habouzit wrote:
Show 39 quoted lines
> * Rename builtin-revert.c into builtin-cherry-pick.c
> 
> * Add option -R/--revert to git-cherry-pick.
>   Document it by taking the current content of git-revert manpage for the
>   option.
> 
> * get rid of the no_replay initialization, just ignore it when we're in
>   the revert case, it makes really no sense to error out.
> 
> * put the warning of deprecation in cmd_revert, #if 0-ed out for now.
> 
> Signed-off-by: Pierre Habouzit <madcoder@debian.org>
> ---
> 
>  I've not kept the auto-edit feature of git-revert for the git-cherry-pick -R
>  case as I don't believe it makes a lot of sense. But if people are unhappy
>  with that, I can easily "fix" it.
> 
>  Documentation/git-cherry-pick.txt         |   15 +++++++++++++++
>  Makefile                                  |    6 +++---
>  builtin-revert.c => builtin-cherry-pick.c |   10 ++++------
>  3 files changed, 22 insertions(+), 9 deletions(-)
>  rename builtin-revert.c => builtin-cherry-pick.c (98%)
> 
> diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt
> index 837fb08..2d92f2d 100644
> --- a/Documentation/git-cherry-pick.txt
> +++ b/Documentation/git-cherry-pick.txt
> @@ -40,6 +40,21 @@ OPTIONS
>  	development branch), adding this information can be
>  	useful.
>  
> +-R::
> +--revert::
> +	Given one existing commit, revert the change the patch introduces, and
> +	record a new commit that records it.  This requires your working tree
> +	to be clean (no modifications from the HEAD commit).
> ++
> +Note: 'git revert' is used to record a new commit to reverse the
         ^ this was supposed to spell out 'git cherry-pick -R' of course :/
Show 7 quoted lines
> +effect of an earlier commit (often a faulty one).  If you want to
> +throw away all uncommitted changes in your working directory, you
> +should see linkgit:git-reset[1], particularly the '--hard' option.  If
> +you want to extract specific files as they were in another commit, you
> +should see linkgit:git-checkout[1], specifically the 'git checkout
> +<commit> -- <filename>' syntax.  Take care with these alternatives as
> +both will discard uncommitted changes in your working directory.
-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org
Jakub Narebski· Oct 31, 2008, 16:36 UTC · re: Pierre Habouzit · lore

Re: [PATCH] prepare deprecation of git-revert

Pierre Habouzit <madcoder@debian.org> writes:
Show 10 quoted lines
> * Rename builtin-revert.c into builtin-cherry-pick.c
> 
> * Add option -R/--revert to git-cherry-pick.
>   Document it by taking the current content of git-revert manpage for the
>   option.
> 
> * get rid of the no_replay initialization, just ignore it when we're in
>   the revert case, it makes really no sense to error out.
> 
> * put the warning of deprecation in cmd_revert, #if 0-ed out for now.
> +#if 0
> +	warning("git revert is deprecated, please use git cherry-pick --revert/-R instead");
> +#endif
By the way, Mercurial names this command IIRC 'hg backout'. 

But I think that adding '-R' option to git-cherry-pick is a good idea even if we don't go deprecating git-revert.

-- 
Jakub Narebski
Poland
ShadeHawk on #git
Pierre Habouzit· Oct 31, 2008, 16:54 UTC · re: Jakub Narebski · lore

Re: [PATCH] prepare deprecation of git-revert

On Fri, Oct 31, 2008 at 04:36:33PM +0000, Jakub Narebski wrote:
Show 21 quoted lines
> Pierre Habouzit <madcoder@debian.org> writes:
> 
> > * Rename builtin-revert.c into builtin-cherry-pick.c
> > 
> > * Add option -R/--revert to git-cherry-pick.
> >   Document it by taking the current content of git-revert manpage for the
> >   option.
> > 
> > * get rid of the no_replay initialization, just ignore it when we're in
> >   the revert case, it makes really no sense to error out.
> > 
> > * put the warning of deprecation in cmd_revert, #if 0-ed out for now.
> 
> > +#if 0
> > +	warning("git revert is deprecated, please use git cherry-pick --revert/-R instead");
> > +#endif
> 
> By the way, Mercurial names this command IIRC 'hg backout'. 
> 
> But I think that adding '-R' option to git-cherry-pick is a good idea
> even if we don't go deprecating git-revert.

Actually part of the "Git UI sucks at time"-talk by pasy, we somehow decided that git-revert would probably be deprecated in the future to avoid the clash between what people coming from other's SCM worlds expect it to be.

I don't remember what the tentative schedule was, that's why I left the warning commented out for now.

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org
Theodore Tso· Oct 31, 2008, 19:01 UTC · re: Jakub Narebski · lore

Re: [PATCH] prepare deprecation of git-revert

On Fri, Oct 31, 2008 at 09:36:33AM -0700, Jakub Narebski wrote:
Show 5 quoted lines
> > +#if 0
> > +	warning("git revert is deprecated, please use git cherry-pick --revert/-R instead");
> > +#endif
> 
> By the way, Mercurial names this command IIRC 'hg backout'. 

By the way, BitKeeper names this command "bk undo" (which is another reason why I would advocate against "git undo" as a syntatic sugar for "git checkout HEAD -- $*") --- not that I think there are too many BK refugees that might want to switch to git, but it shows that "undo" has its own ambiguities; gk uses "undo" the same way we currently use "git revert".

For people who argue that "git cherry-pick --revert" or "git cherry-pick -R" is too long, I'd argue that for most people its not a common command, and for those for which it is common, they can always make in alias for "git pick".

						- Ted
Andreas Ericsson· Nov 1, 2008, 11:53 UTC · re: Theodore Tso · lore

Re: [PATCH] prepare deprecation of git-revert

Theodore Tso wrote:
Show 18 quoted lines
> On Fri, Oct 31, 2008 at 09:36:33AM -0700, Jakub Narebski wrote:
>>> +#if 0
>>> +	warning("git revert is deprecated, please use git cherry-pick --revert/-R instead");
>>> +#endif
>> By the way, Mercurial names this command IIRC 'hg backout'. 
> 
> By the way, BitKeeper names this command "bk undo" (which is another
> reason why I would advocate against "git undo" as a syntatic sugar for
> "git checkout HEAD -- $*") --- not that I think there are too many BK
> refugees that might want to switch to git, but it shows that "undo"
> has its own ambiguities; gk uses "undo" the same way we currently use
> "git revert".
> 
> For people who argue that "git cherry-pick --revert" or "git
> cherry-pick -R" is too long, I'd argue that for most people its not a
> common command, and for those for which it is common, they can always
> make in alias for "git pick".
> 
Probably "git unpick" in that case.
-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231
Alex Riesen· Oct 31, 2008, 16:50 UTC · re: Pierre Habouzit · lore

Re: [PATCH] prepare deprecation of git-revert

Pierre Habouzit, Fri, Oct 31, 2008 16:55:27 +0100:
Show 7 quoted lines
> @@ -439,16 +436,17 @@ static int revert_or_cherry_pick(int argc, const char **argv)
>  
>  int cmd_revert(int argc, const char **argv, const char *prefix)
>  {
> +#if 0
> +	warning("git revert is deprecated, please use git cherry-pick --revert/-R instead");
> +#endif

"git revert" is much shorter to type than "git cherry-pick -R". How about renaming "cherry-pick" into something short, like "pick"?

Pierre Habouzit· Oct 31, 2008, 16:58 UTC · re: Alex Riesen · lore

Re: [PATCH] prepare deprecation of git-revert

On Fri, Oct 31, 2008 at 04:50:03PM +0000, Alex Riesen wrote:
Show 11 quoted lines
> Pierre Habouzit, Fri, Oct 31, 2008 16:55:27 +0100:
> > @@ -439,16 +436,17 @@ static int revert_or_cherry_pick(int argc, const char **argv)
> >  
> >  int cmd_revert(int argc, const char **argv, const char *prefix)
> >  {
> > +#if 0
> > +	warning("git revert is deprecated, please use git cherry-pick --revert/-R instead");
> > +#endif
> 
> "git revert" is much shorter to type than "git cherry-pick -R".
> How about renaming "cherry-pick" into something short, like "pick"?

Do you really use git revert _that_ often ? I don't. And cherry-pick is a really usual name for the tool.

FWIW the basic idea is to deprecate revert in a (not so ?) long time, and leave git revert unimplemented for ever so that people that would like it to be 'git checkout HEAD --' alias it to that, and the ones that want to keep the current behaviour alias it to 'git cherry-pick -R'

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org
Alex Riesen· Oct 31, 2008, 23:24 UTC · re: Pierre Habouzit · lore

Re: [PATCH] prepare deprecation of git-revert

Pierre Habouzit, Fri, Oct 31, 2008 17:58:14 +0100:
Show 15 quoted lines
> On Fri, Oct 31, 2008 at 04:50:03PM +0000, Alex Riesen wrote:
> > Pierre Habouzit, Fri, Oct 31, 2008 16:55:27 +0100:
> > > @@ -439,16 +436,17 @@ static int revert_or_cherry_pick(int argc, const char **argv)
> > >  
> > >  int cmd_revert(int argc, const char **argv, const char *prefix)
> > >  {
> > > +#if 0
> > > +	warning("git revert is deprecated, please use git cherry-pick --revert/-R instead");
> > > +#endif
> > 
> > "git revert" is much shorter to type than "git cherry-pick -R".
> > How about renaming "cherry-pick" into something short, like "pick"?
> 
> Do you really use git revert _that_ often ? I don't. And cherry-pick is
> a really usual name for the tool.
Have it 5 times in my bash history of 20k lines. 4 recent, one relatively old.
> FWIW the basic idea is to deprecate revert in a (not so ?) long time,
> and leave git revert unimplemented for ever so that people that would
> like it to be 'git checkout HEAD --' alias it to that, and the ones that
> want to keep the current behaviour alias it to 'git cherry-pick -R'

Well, I kind of got used to it. And it makes sense (as does -R by cherry-pick, I have to admit). I have no other argument against the change.

Johannes Schindelin· Oct 31, 2008, 23:13 UTC · re: Alex Riesen · lore

Re: [PATCH] prepare deprecation of git-revert

Hi,
On Fri, 31 Oct 2008, Alex Riesen wrote:
Show 11 quoted lines
> Pierre Habouzit, Fri, Oct 31, 2008 16:55:27 +0100:
> > @@ -439,16 +436,17 @@ static int revert_or_cherry_pick(int argc, const char **argv)
> >  
> >  int cmd_revert(int argc, const char **argv, const char *prefix)
> >  {
> > +#if 0
> > +	warning("git revert is deprecated, please use git cherry-pick --revert/-R instead");
> > +#endif
> 
> "git revert" is much shorter to type than "git cherry-pick -R". How 
> about renaming "cherry-pick" into something short, like "pick"?

I thought we agreed that we should _never_ remove support for "git revert"? I mean, we can deprecate it, but I find it pretty strong, and unnecessary, to break existing users' expectations.

Ciao, Dscho

Junio C Hamano· Oct 31, 2008, 23:20 UTC · re: Johannes Schindelin · lore

Re: [PATCH] prepare deprecation of git-revert

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 17 quoted lines
> On Fri, 31 Oct 2008, Alex Riesen wrote:
>
>> Pierre Habouzit, Fri, Oct 31, 2008 16:55:27 +0100:
>> > @@ -439,16 +436,17 @@ static int revert_or_cherry_pick(int argc, const char **argv)
>> >  
>> >  int cmd_revert(int argc, const char **argv, const char *prefix)
>> >  {
>> > +#if 0
>> > +	warning("git revert is deprecated, please use git cherry-pick --revert/-R instead");
>> > +#endif
>> 
>> "git revert" is much shorter to type than "git cherry-pick -R". How 
>> about renaming "cherry-pick" into something short, like "pick"?
>
> I thought we agreed that we should _never_ remove support for "git 
> revert"?  I mean, we can deprecate it, but I find it pretty strong, and 
> unnecessary, to break existing users' expectations.
Likewise.

The current state of affairs is that there is no remedy if teachers find "git checkout -- path" or "git revert HEAD~24" is confusing to new people. By introducing "git unstage path" or "git cherry-pick -r HEAD~24", teachers can choose to teach what they feel less confusing, and they do not have to teach "git checkout -- path" or "git revert HEAD~24". We should stop there.

Matthieu Moy· Nov 1, 2008, 23:01 UTC · re: Junio C Hamano · lore

Re: [PATCH] prepare deprecation of git-revert

Junio C Hamano <gitster@pobox.com> writes:
Show 6 quoted lines
> The current state of affairs is that there is no remedy if teachers find
> "git checkout -- path" or "git revert HEAD~24" is confusing to new people.
> By introducing "git unstage path" or "git cherry-pick -r HEAD~24",
> teachers can choose to teach what they feel less confusing, and they do
> not have to teach "git checkout -- path" or "git revert HEAD~24".  We
> should stop there.

I think you should go half a step further: officially deprecate "revert", but keep it supported forever. The reason is just to help documentation to be homogeneous (I foresee questions of users having read here about "cherry-pick -R" and there about "revert" and asking "should I use one or the other"). At least, the man page for "revert" should state explicitly "this is a convenience alias for ...".

But I agree that removing support for "revert" is probably useless and somehow harmfull.

(my 2 cents ...)
-- 
Matthieu
Nguyen Thai Ngoc Duy· Nov 2, 2008, 09:32 UTC · re: Alex Riesen · lore

Re: [PATCH] prepare deprecation of git-revert

On Fri, Oct 31, 2008 at 05:50:03PM +0100, Alex Riesen wrote:
Show 11 quoted lines
> Pierre Habouzit, Fri, Oct 31, 2008 16:55:27 +0100:
> > @@ -439,16 +436,17 @@ static int revert_or_cherry_pick(int argc, const char **argv)
> >  
> >  int cmd_revert(int argc, const char **argv, const char *prefix)
> >  {
> > +#if 0
> > +	warning("git revert is deprecated, please use git cherry-pick --revert/-R instead");
> > +#endif
> 
> "git revert" is much shorter to type than "git cherry-pick -R".
> How about renaming "cherry-pick" into something short, like "pick"?

Maybe a patch like this can help? With it you can type "git cp" for cherry-pick. If someday "git cp" is added, you can type "git c-p", much shorter.

--<--
commit dce5cad329390905bb91115a9de0153772be57d8
Author: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Date:   Sat Nov 1 17:12:04 2008 +0700
    Add git command expansion
    
    This allows git commands to be typed shorter (in shells that do not
    support autocompletion). There are three types of expansion:
    
     - "foo" matches "foo*" commands (bi -> bisect)
     - "foo" also matches "f*-oo*" (fim -> fast-import)
     - "foo-bar" (with dash) matches "foo*-bar*" (fo-p -> format-patch)
    
    This feature is only enabled if core.commandexpansion is true. It
    may work better if we can limit the command set (to porcelain
    only for example) but I have yet to find a way to pull
    commands-list.txt to help.c.
Show changes to 3 files +79 −1

builtin.h, git.c, help.c

diff --git a/builtin.h b/builtin.h
index 1495cf6..9fb0fef 100644
--- a/builtin.h
+++ b/builtin.h
@@ -12,6 +12,7 @@ extern const char git_more_info_string[];
 
 extern void list_common_cmds_help(void);
 extern const char *help_unknown_cmd(const char *cmd);
+extern const char *expand_command(const char *cmd);
 extern void prune_packed_objects(int);
 extern int read_line_with_nul(char *buf, int size, FILE *file);
 extern int fmt_merge_msg(int merge_summary, struct strbuf *in,
diff --git a/git.c b/git.c
index 89feb0b..1bbe340 100644
--- a/git.c
+++ b/git.c
@@ -14,6 +14,7 @@ struct pager_config {
 	const char *cmd;
 	int val;
 };
+static int command_expansion;
 
 static int pager_command_config(const char *var, const char *value, void *data)
 {
@@ -415,6 +416,13 @@ static void execv_dashed_external(const char **argv)
 	strbuf_release(&cmd);
 }
 
+static int git_command_expansion_config(const char *var, const char *value, void *cb)
+{
+	if (!strcmp(var, "core.commandexpansion"))
+		command_expansion = git_config_bool(var, value);
+
+	return git_default_config(var, value, cb);
+}
 
 int main(int argc, const char **argv)
 {
@@ -501,6 +509,15 @@ int main(int argc, const char **argv)
 				cmd, argv[0]);
 			exit(1);
 		}
+		git_config(git_command_expansion_config, NULL);
+		if (command_expansion) {
+			const char *expand_cmd = expand_command(cmd);
+			if (expand_cmd) {
+				argv[0] = expand_cmd;
+				handle_internal_command(argc, argv);
+				execv_dashed_external(argv);
+			}
+		}
 		argv[0] = help_unknown_cmd(cmd);
 		handle_internal_command(argc, argv);
 		execv_dashed_external(argv);
diff --git a/help.c b/help.c
index fd87bb5..4f0e5a0 100644
--- a/help.c
+++ b/help.c
@@ -359,6 +359,67 @@ const char *help_unknown_cmd(const char *cmd)
 	exit(1);
 }
 
+const char *expand_command(const char *cmd)
+{
+	int i, n, len;
+	struct cmdnames main_cmds, other_cmds;
+	char *src, *dst;
+
+	memset(&main_cmds, 0, sizeof(main_cmds));
+	memset(&other_cmds, 0, sizeof(main_cmds));
+
+	load_command_list("git-", &main_cmds, &other_cmds);
+
+	add_cmd_list(&main_cmds, &aliases);
+	add_cmd_list(&main_cmds, &other_cmds);
+	qsort(main_cmds.names, main_cmds.cnt,
+	      sizeof(main_cmds.names), cmdname_compare);
+	uniq(&main_cmds);
+
+	len = strlen(cmd);
+	n = -1;
+	src = strchr(cmd, '-');
+	for (i = 0;i < main_cmds.cnt; i++) {
+		const char *gitcmd = main_cmds.names[i]->name;
+
+		/* match prefix */
+		if (!strncmp(cmd, gitcmd, len))
+			goto ok_expand;
+
+		if (*cmd != *gitcmd)
+			continue;
+		dst = strchr(gitcmd, '-');
+		if (!dst)
+			continue;
+
+		/* cmd is foo-bar, match foo*-bar* */
+		if (src &&
+		    !strncmp(cmd, gitcmd, src-cmd) &&
+		    !strncmp(src+1, dst+1, cmd+len-src-1))
+			goto ok_expand;
+
+		/* cmd is foobar,match f*-oobar* */
+		if (!src && !strncmp(cmd+1, dst+1, len-1))
+			goto ok_expand;
+
+		continue;
+ok_expand:
+		trace_printf("expand: %s\n", main_cmds.names[i]->name);
+		if (n != -1)
+			return NULL;
+		n = i;
+	}
+
+	if (n != -1) {
+		const char *assumed = main_cmds.names[n]->name;
+		main_cmds.names[n] = NULL;
+		clean_cmdnames(&main_cmds);
+		return assumed;
+	}
+	else
+		return NULL;
+}
+
 int cmd_version(int argc, const char **argv, const char *prefix)
 {
 	printf("git version %s\n", git_version_string);
--<--
-- 
Duy
Johannes Schindelin· Nov 2, 2008, 16:12 UTC · re: Nguyen Thai Ngoc Duy · lore

Re: [PATCH] prepare deprecation of git-revert

Hi,
On Sun, 2 Nov 2008, Nguyen Thai Ngoc Duy wrote:
Show 8 quoted lines
>     Add git command expansion
>     
>     This allows git commands to be typed shorter (in shells that do not
>     support autocompletion). There are three types of expansion:
>     
>      - "foo" matches "foo*" commands (bi -> bisect)
>      - "foo" also matches "f*-oo*" (fim -> fast-import)
>      - "foo-bar" (with dash) matches "foo*-bar*" (fo-p -> format-patch)

I'd rather have the soft-alias code back to perform this expansion, but only for a limited and explicit set of abbreviations.

Ciao, Dscho

Jeff King· Nov 2, 2008, 04:41 UTC · re: Pierre Habouzit · lore

Re: [PATCH] prepare deprecation of git-revert

On Fri, Oct 31, 2008 at 04:55:27PM +0100, Pierre Habouzit wrote:
>  I've not kept the auto-edit feature of git-revert for the git-cherry-pick -R
>  case as I don't believe it makes a lot of sense. But if people are unhappy
>  with that, I can easily "fix" it.
I disagree. I write a new commit message for every revert I do.

When you cherry-pick, you are pulling a good commit from somewhere else. So its commit message should suffice to explain why you are making the change (and infrequently, you might want to give more context or say "and here is where this comes from").

But when you revert, you are saying "this other commit was bad, so let's reverse it." So you can look at the other commit to see what it did, but you still don't know _why_ it was bad. A revert should always give information about what you know _now_ that you didn't know when you made the commit originally.

-Peff
Pierre Habouzit· Nov 2, 2008, 09:30 UTC · re: Jeff King · lore

Re: [PATCH] prepare deprecation of git-revert

On Sun, Nov 02, 2008 at 04:41:59AM +0000, Jeff King wrote:
Show 18 quoted lines
> On Fri, Oct 31, 2008 at 04:55:27PM +0100, Pierre Habouzit wrote:
> 
> >  I've not kept the auto-edit feature of git-revert for the git-cherry-pick -R
> >  case as I don't believe it makes a lot of sense. But if people are unhappy
> >  with that, I can easily "fix" it.
> 
> I disagree. I write a new commit message for every revert I do.
> 
> When you cherry-pick, you are pulling a good commit from somewhere else.
> So its commit message should suffice to explain why you are making the
> change (and infrequently, you might want to give more context or say
> "and here is where this comes from").
> 
> But when you revert, you are saying "this other commit was bad, so let's
> reverse it." So you can look at the other commit to see what it did, but
> you still don't know _why_ it was bad. A revert should always give
> information about what you know _now_ that you didn't know when you
> made the commit originally.

Indeed that makes sense, I'll update the patch then, and be lighter on the deprecation side since it seems I misunderstood what people agreed on.

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

← back to recent threads