Re: [PATCH] Support tags in uncommit - use git_id instead of rev_parse

Previous thread: [PATCH] rebase: add --signoff option by Steffen Prohaska on Sunday, September 30, 2007 - 12:15 pm. (6 messages)

Next thread: suggestion for git stash by Bruno Haible on Sunday, September 30, 2007 - 2:50 pm. (6 messages)
To: Catalin Marinas <catalin.marinas@...>, <git@...>
Date: Sunday, September 30, 2007 - 1:26 pm

Signed-off-by: Pavel Roskin <proski@gnu.org>
---

stgit/commands/uncommit.py | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/stgit/commands/uncommit.py b/stgit/commands/uncommit.py
index 0cd0fb0..c22d3ea 100644
--- a/stgit/commands/uncommit.py
+++ b/stgit/commands/uncommit.py
@@ -65,7 +65,7 @@ def func(parser, options, args):
if len(args) != 0:
parser.error('cannot specify patch name with --to')
patch_nr = patchnames = None
- to_commit = git.rev_parse(options.to)
+ to_commit = git_id(options.to)
elif options.number:
if options.number <= 0:
parser.error('invalid value passed to --number')
-

To: Pavel Roskin <proski@...>
Cc: <git@...>
Date: Monday, October 1, 2007 - 6:00 pm

With this patch, uncommit can take patch names (with modifiers) as the
--to argument. When would this be needed?

To allow tags, maybe just pass something like
"git.rev_parse(options.to + '^{commit}')" or just modify git.rev_parse
to do it (and git_id to avoid it).

--
Catalin
-

To: Catalin Marinas <catalin.marinas@...>
Cc: <git@...>
Date: Tuesday, October 2, 2007 - 6:03 pm

I prefer to work with software that understands what I mean and tells me
that I cannot do it. It makes it easier to understand what is possible
and how the command is working.

Recognizing patch names in some commands but not others would be
annoying and inconsistent. Dumbing downs interactive software on
purpose is probably not worth the trouble.

--
Regards,
Pavel Roskin

-

To: Pavel Roskin <proski@...>
Cc: <git@...>
Date: Wednesday, October 3, 2007 - 4:35 pm

Without this patch, the 'stg uncommit -t patch' fails with 'Unknown
revision: patch'. With the patch applied, it still fails but with
'Commit ... does not have exactly one parent'. I don't say that the
first one is good but I don't think the latter is clearer. The 'stg
uncommit --help' states that the '--to' option takes a commit argument
but if one passes a patch name the error message gets pretty
confusing.

--
Catalin
-

To: Catalin Marinas <catalin.marinas@...>
Cc: <git@...>
Date: Wednesday, October 3, 2007 - 5:44 pm

Actually, 'Commit ... does not have exactly one parent' means that stg
misinterpreted the patch name as some non-existing hash and started
iterating back until it hit the first merge.

Perhaps stgit should make sure that the hash is valid before walking the
commit tree. If it's not, stgit could provide a better message.

--
Regards,
Pavel Roskin

-

To: Pavel Roskin <proski@...>
Cc: <git@...>
Date: Sunday, October 7, 2007 - 5:06 pm

OK, I applied your patch but I'll have to look into the error message
to make it more meaningful. Thanks.

--
Catalin
-

To: Pavel Roskin <proski@...>
Cc: Catalin Marinas <catalin.marinas@...>, <git@...>
Date: Monday, October 1, 2007 - 7:16 am

Sounds like a good idea. Test? :-)

--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
-

Previous thread: [PATCH] rebase: add --signoff option by Steffen Prohaska on Sunday, September 30, 2007 - 12:15 pm. (6 messages)

Next thread: suggestion for git stash by Bruno Haible on Sunday, September 30, 2007 - 2:50 pm. (6 messages)