* Feature request: Add --no-edit to git tag command @ 2019-04-03 14:38 Robert Dailey 2019-04-04 1:57 ` Jeff King 0 siblings, 1 reply; 13+ messages in thread From: Robert Dailey @ 2019-04-03 14:38 UTC (permalink / raw) To: Git Similar to git commit, it would be nice to have a --no-edit option for git tag. Use case is when I force-recreate a tag: $ git tag -af 1.0 123abc An editor will be prompted with the previous annotated tag message. I would like to add --no-edit to instruct it to use any previously provided message and without prompting the editor: $ git tag --no-edit -af 1.0 123abc ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Feature request: Add --no-edit to git tag command 2019-04-03 14:38 Feature request: Add --no-edit to git tag command Robert Dailey @ 2019-04-04 1:57 ` Jeff King 2019-04-04 3:26 ` Taylor Blau 2019-04-04 9:13 ` Junio C Hamano 0 siblings, 2 replies; 13+ messages in thread From: Jeff King @ 2019-04-04 1:57 UTC (permalink / raw) To: Robert Dailey; +Cc: Git On Wed, Apr 03, 2019 at 09:38:02AM -0500, Robert Dailey wrote: > Similar to git commit, it would be nice to have a --no-edit option for > git tag. Use case is when I force-recreate a tag: > > $ git tag -af 1.0 123abc > > An editor will be prompted with the previous annotated tag message. I > would like to add --no-edit to instruct it to use any previously > provided message and without prompting the editor: > > $ git tag --no-edit -af 1.0 123abc Yeah, that sounds like a good idea. I think it wouldn't be very hard to implement, either. Maybe a good starter project or #leftoverbits for somebody. -Peff ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Feature request: Add --no-edit to git tag command 2019-04-04 1:57 ` Jeff King @ 2019-04-04 3:26 ` Taylor Blau 2019-04-04 12:06 ` Jeff King 2019-04-04 9:13 ` Junio C Hamano 1 sibling, 1 reply; 13+ messages in thread From: Taylor Blau @ 2019-04-04 3:26 UTC (permalink / raw) To: Jeff King; +Cc: Robert Dailey, Git Hi Peff, On Wed, Apr 03, 2019 at 09:57:44PM -0400, Jeff King wrote: > On Wed, Apr 03, 2019 at 09:38:02AM -0500, Robert Dailey wrote: > > > Similar to git commit, it would be nice to have a --no-edit option for > > git tag. Use case is when I force-recreate a tag: > > > > $ git tag -af 1.0 123abc > > > > An editor will be prompted with the previous annotated tag message. I > > would like to add --no-edit to instruct it to use any previously > > provided message and without prompting the editor: > > > > $ git tag --no-edit -af 1.0 123abc > > Yeah, that sounds like a good idea. Agreed. I think that the implement is a little different than "add a --no-edit" flag, though. 'git tag' already has a OPT_BOOL for '--edit', which means that '--no-edit' exists, too. But, when we look and see how the edit option is passed around, we find that the check whether or not to launch the editor (again, in builtin/tag.c within 'create_tag()') is: if (!opt->message_given || opt->use_editor) So, it's not that we didn't take '--no-edit', it's that we didn't get a _message_, so we'll open the editor to get one (even if '--no-edit' was given). This makes me think that we should do two things: 1. Make !opt->message_give && !opt->use_editor an invalid invocation. If I (1) didn't give a message but I did (2) give '--no-edit', I'd expect a complaint, not an editor window. 2. Then, do what Robert suggests, which is to "make opt->message_given true", by re-using the previous tag's message. > I think it wouldn't be very hard to implement, either. Maybe a good > starter project or #leftoverbits for somebody. Maybe. I think that it's made a little more complicated by the above, but it's certainly doable. Maybe good for GSoC? > -Peff Thanks, Taylor ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Feature request: Add --no-edit to git tag command 2019-04-04 3:26 ` Taylor Blau @ 2019-04-04 12:06 ` Jeff King 2019-04-04 13:56 ` Robert Dailey 0 siblings, 1 reply; 13+ messages in thread From: Jeff King @ 2019-04-04 12:06 UTC (permalink / raw) To: Taylor Blau; +Cc: Robert Dailey, Git On Wed, Apr 03, 2019 at 08:26:06PM -0700, Taylor Blau wrote: > Agreed. > > I think that the implement is a little different than "add a --no-edit" > flag, though. 'git tag' already has a OPT_BOOL for '--edit', which means > that '--no-edit' exists, too. > > But, when we look and see how the edit option is passed around, we find > that the check whether or not to launch the editor (again, in > builtin/tag.c within 'create_tag()') is: > > if (!opt->message_given || opt->use_editor) > > So, it's not that we didn't take '--no-edit', it's that we didn't get a > _message_, so we'll open the editor to get one (even if '--no-edit' was > given). Yeah, I think the fundamental issue with --no-edit is that it is not a tristate, so we cannot tell the difference between --edit, --no-edit, and nothing. I think regardless of the "re-use message bits", we'd want something like: diff --git a/builtin/tag.c b/builtin/tag.c index 02f6bd1279..260adcaa60 100644 --- a/builtin/tag.c +++ b/builtin/tag.c @@ -196,7 +196,7 @@ static int build_tag_object(struct strbuf *buf, int sign, struct object_id *resu struct create_tag_options { unsigned int message_given:1; - unsigned int use_editor:1; + int use_editor; unsigned int sign; enum { CLEANUP_NONE, @@ -227,7 +227,7 @@ static void create_tag(const struct object_id *object, const char *tag, tag, git_committer_info(IDENT_STRICT)); - if (!opt->message_given || opt->use_editor) { + if ((!opt->message_given && opt->use_editor != 0) || opt->use_editor > 0) { int fd; /* write the template message before editing: */ @@ -380,7 +380,7 @@ int cmd_tag(int argc, const char **argv, const char *prefix) static struct ref_sorting *sorting = NULL, **sorting_tail = &sorting; struct ref_format format = REF_FORMAT_INIT; int icase = 0; - int edit_flag = 0; + int edit_flag = -1; struct option options[] = { OPT_CMDMODE('l', "list", &cmdmode, N_("list tag names"), 'l'), { OPTION_INTEGER, 'n', NULL, &filter.lines, N_("n"), which even does the right thing with "git tag --no-edit -a foo" (it dies with "fatal: no tag message?" > This makes me think that we should do two things: > > 1. Make !opt->message_give && !opt->use_editor an invalid invocation. > If I (1) didn't give a message but I did (2) give '--no-edit', I'd > expect a complaint, not an editor window. > > 2. Then, do what Robert suggests, which is to "make opt->message_given > true", by re-using the previous tag's message. I think I misunderstood Robert's proposal. I thought it was just about fixing --no-edit, but it's actually about _adding_ (2). Which I think we'd want to do differently. See Junio's reply elsewhere in the thread (and my reply there). > > I think it wouldn't be very hard to implement, either. Maybe a good > > starter project or #leftoverbits for somebody. > > Maybe. I think that it's made a little more complicated by the above, > but it's certainly doable. Maybe good for GSoC? I was thinking it was just the --no-edit fix. :) Even with the "--amend" thing, though, it's probably a little light for a 3-month-long GSoC project. :) -Peff ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: Feature request: Add --no-edit to git tag command 2019-04-04 12:06 ` Jeff King @ 2019-04-04 13:56 ` Robert Dailey 2019-04-04 13:57 ` Robert Dailey 2019-04-05 22:21 ` Jeff King 0 siblings, 2 replies; 13+ messages in thread From: Robert Dailey @ 2019-04-04 13:56 UTC (permalink / raw) To: Jeff King; +Cc: Taylor Blau, Git On Thu, Apr 4, 2019 at 7:06 AM Jeff King <peff@peff.net> wrote: > > On Wed, Apr 03, 2019 at 08:26:06PM -0700, Taylor Blau wrote: > > > Agreed. > > > > I think that the implement is a little different than "add a --no-edit" > > flag, though. 'git tag' already has a OPT_BOOL for '--edit', which means > > that '--no-edit' exists, too. > > > > But, when we look and see how the edit option is passed around, we find > > that the check whether or not to launch the editor (again, in > > builtin/tag.c within 'create_tag()') is: > > > > if (!opt->message_given || opt->use_editor) > > > > So, it's not that we didn't take '--no-edit', it's that we didn't get a > > _message_, so we'll open the editor to get one (even if '--no-edit' was > > given). > > Yeah, I think the fundamental issue with --no-edit is that it is not a > tristate, so we cannot tell the difference between --edit, --no-edit, > and nothing. > > I think regardless of the "re-use message bits", we'd want something > like: > > diff --git a/builtin/tag.c b/builtin/tag.c > index 02f6bd1279..260adcaa60 100644 > --- a/builtin/tag.c > +++ b/builtin/tag.c > @@ -196,7 +196,7 @@ static int build_tag_object(struct strbuf *buf, int sign, struct object_id *resu > > struct create_tag_options { > unsigned int message_given:1; > - unsigned int use_editor:1; > + int use_editor; > unsigned int sign; > enum { > CLEANUP_NONE, > @@ -227,7 +227,7 @@ static void create_tag(const struct object_id *object, const char *tag, > tag, > git_committer_info(IDENT_STRICT)); > > - if (!opt->message_given || opt->use_editor) { > + if ((!opt->message_given && opt->use_editor != 0) || opt->use_editor > 0) { > int fd; > > /* write the template message before editing: */ > @@ -380,7 +380,7 @@ int cmd_tag(int argc, const char **argv, const char *prefix) > static struct ref_sorting *sorting = NULL, **sorting_tail = &sorting; > struct ref_format format = REF_FORMAT_INIT; > int icase = 0; > - int edit_flag = 0; > + int edit_flag = -1; > struct option options[] = { > OPT_CMDMODE('l', "list", &cmdmode, N_("list tag names"), 'l'), > { OPTION_INTEGER, 'n', NULL, &filter.lines, N_("n"), > > which even does the right thing with "git tag --no-edit -a foo" (it dies > with "fatal: no tag message?" > > > This makes me think that we should do two things: > > > > 1. Make !opt->message_give && !opt->use_editor an invalid invocation. > > If I (1) didn't give a message but I did (2) give '--no-edit', I'd > > expect a complaint, not an editor window. > > > > 2. Then, do what Robert suggests, which is to "make opt->message_given > > true", by re-using the previous tag's message. > > I think I misunderstood Robert's proposal. I thought it was just about > fixing --no-edit, but it's actually about _adding_ (2). Which I think > we'd want to do differently. See Junio's reply elsewhere in the thread > (and my reply there). > > > > I think it wouldn't be very hard to implement, either. Maybe a good > > > starter project or #leftoverbits for somebody. > > > > Maybe. I think that it's made a little more complicated by the above, > > but it's certainly doable. Maybe good for GSoC? > > I was thinking it was just the --no-edit fix. :) Even with the "--amend" > thing, though, it's probably a little light for a 3-month-long GSoC > project. :) I apologize for the confusion. I'm not fully aware of any per-option philosophies in Git, so I may be unaware of the misunderstanding my request is causing. Let me attempt to clarify. My goal as a user is to correct a tag. If I point a tag at the wrong commit, I simply want to move that tag to point to another commit. At the moment, the only way I know to do this is the -f option, which I just treat as a "move" for the tag. I realize that may not be its intent in the implementation, but from a user perspective that's the end result I get. So if I treat -f as a "move this tag", I also want to say "reuse the existing commit message". So again, in my mind, that means -f --no-edit. Which means "I'm moving this tag and I want to keep the previous commit message". I hope this makes more sense. If getting this means not using -f or --no-edit at all, and is instead a whole different set of options, I'm OK with that as long as the end result is achievable. It's impossible to write a script to "move" (-f) a bunch of annotated tags without an editor prompting me on each one. So this "--no-edit" addition would assist in automation, and also making sure that we simply want to correct a tag, but not alter the message. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Feature request: Add --no-edit to git tag command 2019-04-04 13:56 ` Robert Dailey @ 2019-04-04 13:57 ` Robert Dailey 2019-04-05 22:21 ` Jeff King 1 sibling, 0 replies; 13+ messages in thread From: Robert Dailey @ 2019-04-04 13:57 UTC (permalink / raw) To: Jeff King; +Cc: Taylor Blau, Git On Thu, Apr 4, 2019 at 8:56 AM Robert Dailey <rcdailey.lists@gmail.com> wrote: > > On Thu, Apr 4, 2019 at 7:06 AM Jeff King <peff@peff.net> wrote: > > > > On Wed, Apr 03, 2019 at 08:26:06PM -0700, Taylor Blau wrote: > > > > > Agreed. > > > > > > I think that the implement is a little different than "add a --no-edit" > > > flag, though. 'git tag' already has a OPT_BOOL for '--edit', which means > > > that '--no-edit' exists, too. > > > > > > But, when we look and see how the edit option is passed around, we find > > > that the check whether or not to launch the editor (again, in > > > builtin/tag.c within 'create_tag()') is: > > > > > > if (!opt->message_given || opt->use_editor) > > > > > > So, it's not that we didn't take '--no-edit', it's that we didn't get a > > > _message_, so we'll open the editor to get one (even if '--no-edit' was > > > given). > > > > Yeah, I think the fundamental issue with --no-edit is that it is not a > > tristate, so we cannot tell the difference between --edit, --no-edit, > > and nothing. > > > > I think regardless of the "re-use message bits", we'd want something > > like: > > > > diff --git a/builtin/tag.c b/builtin/tag.c > > index 02f6bd1279..260adcaa60 100644 > > --- a/builtin/tag.c > > +++ b/builtin/tag.c > > @@ -196,7 +196,7 @@ static int build_tag_object(struct strbuf *buf, int sign, struct object_id *resu > > > > struct create_tag_options { > > unsigned int message_given:1; > > - unsigned int use_editor:1; > > + int use_editor; > > unsigned int sign; > > enum { > > CLEANUP_NONE, > > @@ -227,7 +227,7 @@ static void create_tag(const struct object_id *object, const char *tag, > > tag, > > git_committer_info(IDENT_STRICT)); > > > > - if (!opt->message_given || opt->use_editor) { > > + if ((!opt->message_given && opt->use_editor != 0) || opt->use_editor > 0) { > > int fd; > > > > /* write the template message before editing: */ > > @@ -380,7 +380,7 @@ int cmd_tag(int argc, const char **argv, const char *prefix) > > static struct ref_sorting *sorting = NULL, **sorting_tail = &sorting; > > struct ref_format format = REF_FORMAT_INIT; > > int icase = 0; > > - int edit_flag = 0; > > + int edit_flag = -1; > > struct option options[] = { > > OPT_CMDMODE('l', "list", &cmdmode, N_("list tag names"), 'l'), > > { OPTION_INTEGER, 'n', NULL, &filter.lines, N_("n"), > > > > which even does the right thing with "git tag --no-edit -a foo" (it dies > > with "fatal: no tag message?" > > > > > This makes me think that we should do two things: > > > > > > 1. Make !opt->message_give && !opt->use_editor an invalid invocation. > > > If I (1) didn't give a message but I did (2) give '--no-edit', I'd > > > expect a complaint, not an editor window. > > > > > > 2. Then, do what Robert suggests, which is to "make opt->message_given > > > true", by re-using the previous tag's message. > > > > I think I misunderstood Robert's proposal. I thought it was just about > > fixing --no-edit, but it's actually about _adding_ (2). Which I think > > we'd want to do differently. See Junio's reply elsewhere in the thread > > (and my reply there). > > > > > > I think it wouldn't be very hard to implement, either. Maybe a good > > > > starter project or #leftoverbits for somebody. > > > > > > Maybe. I think that it's made a little more complicated by the above, > > > but it's certainly doable. Maybe good for GSoC? > > > > I was thinking it was just the --no-edit fix. :) Even with the "--amend" > > thing, though, it's probably a little light for a 3-month-long GSoC > > project. :) > > I apologize for the confusion. I'm not fully aware of any per-option > philosophies in Git, so I may be unaware of the misunderstanding my > request is causing. Let me attempt to clarify. > > My goal as a user is to correct a tag. If I point a tag at the wrong > commit, I simply want to move that tag to point to another commit. At > the moment, the only way I know to do this is the -f option, which I > just treat as a "move" for the tag. I realize that may not be its > intent in the implementation, but from a user perspective that's the > end result I get. > > So if I treat -f as a "move this tag", I also want to say "reuse the > existing commit message". So again, in my mind, that means -f > --no-edit. Which means "I'm moving this tag and I want to keep the > previous commit message". > > I hope this makes more sense. If getting this means not using -f or > --no-edit at all, and is instead a whole different set of options, I'm > OK with that as long as the end result is achievable. It's impossible > to write a script to "move" (-f) a bunch of annotated tags without an > editor prompting me on each one. So this "--no-edit" addition would > assist in automation, and also making sure that we simply want to > correct a tag, but not alter the message. Sorry I said "commit message" but I meant "annotated tag message". ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Feature request: Add --no-edit to git tag command 2019-04-04 13:56 ` Robert Dailey 2019-04-04 13:57 ` Robert Dailey @ 2019-04-05 22:21 ` Jeff King 2019-04-11 18:20 ` Bárbara de Castro Fernandes 1 sibling, 1 reply; 13+ messages in thread From: Jeff King @ 2019-04-05 22:21 UTC (permalink / raw) To: Robert Dailey; +Cc: Taylor Blau, Git On Thu, Apr 04, 2019 at 08:56:16AM -0500, Robert Dailey wrote: > > I was thinking it was just the --no-edit fix. :) Even with the "--amend" > > thing, though, it's probably a little light for a 3-month-long GSoC > > project. :) > > I apologize for the confusion. I'm not fully aware of any per-option > philosophies in Git, so I may be unaware of the misunderstanding my > request is causing. Let me attempt to clarify. I think most of the confusion was just bad reading on my part. :) > My goal as a user is to correct a tag. If I point a tag at the wrong > commit, I simply want to move that tag to point to another commit. At > the moment, the only way I know to do this is the -f option, which I > just treat as a "move" for the tag. I realize that may not be its > intent in the implementation, but from a user perspective that's the > end result I get. > > So if I treat -f as a "move this tag", I also want to say "reuse the > existing commit message". So again, in my mind, that means -f > --no-edit. Which means "I'm moving this tag and I want to keep the > previous commit message". > > I hope this makes more sense. If getting this means not using -f or > --no-edit at all, and is instead a whole different set of options, I'm > OK with that as long as the end result is achievable. It's impossible > to write a script to "move" (-f) a bunch of annotated tags without an > editor prompting me on each one. So this "--no-edit" addition would > assist in automation, and also making sure that we simply want to > correct a tag, but not alter the message. Yeah, I think what you want to do is perfectly reasonable. The only reason not to use "-f" is because it already means other things, and we don't want to overload it. Calling it "--amend" would make perfect sense (and then fixing "--no-edit" so it lets you avoid opening the editor). So I think there are two bits of work: 1. Add an "--amend" option, which allows overwriting an existing tag and pre-populates the message with the existing tag's message. 2. Make --no-edit work like the patch I showed earlier (assuming that your --amend still opens an editor by default). -Peff ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Feature request: Add --no-edit to git tag command 2019-04-05 22:21 ` Jeff King @ 2019-04-11 18:20 ` Bárbara de Castro Fernandes 2019-04-11 18:29 ` Jeff King 0 siblings, 1 reply; 13+ messages in thread From: Bárbara de Castro Fernandes @ 2019-04-11 18:20 UTC (permalink / raw) To: Jeff King; +Cc: Robert Dailey, Taylor Blau, Git Em sex, 5 de abr de 2019 às 19:21, Jeff King <peff@peff.net> escreveu: > > On Thu, Apr 04, 2019 at 08:56:16AM -0500, Robert Dailey wrote: > > > > I was thinking it was just the --no-edit fix. :) Even with the "--amend" > > > thing, though, it's probably a little light for a 3-month-long GSoC > > > project. :) > > > > I apologize for the confusion. I'm not fully aware of any per-option > > philosophies in Git, so I may be unaware of the misunderstanding my > > request is causing. Let me attempt to clarify. > > I think most of the confusion was just bad reading on my part. :) > > > My goal as a user is to correct a tag. If I point a tag at the wrong > > commit, I simply want to move that tag to point to another commit. At > > the moment, the only way I know to do this is the -f option, which I > > just treat as a "move" for the tag. I realize that may not be its > > intent in the implementation, but from a user perspective that's the > > end result I get. > > > > So if I treat -f as a "move this tag", I also want to say "reuse the > > existing commit message". So again, in my mind, that means -f > > --no-edit. Which means "I'm moving this tag and I want to keep the > > previous commit message". > > > > I hope this makes more sense. If getting this means not using -f or > > --no-edit at all, and is instead a whole different set of options, I'm > > OK with that as long as the end result is achievable. It's impossible > > to write a script to "move" (-f) a bunch of annotated tags without an > > editor prompting me on each one. So this "--no-edit" addition would > > assist in automation, and also making sure that we simply want to > > correct a tag, but not alter the message. > > Yeah, I think what you want to do is perfectly reasonable. The only > reason not to use "-f" is because it already means other things, and we > don't want to overload it. This new proposed --amend option, although semantically different, would have a very similar functionality to the already existing -f option. So should we, perhaps, change -f's behavior to treat the tag as a new one, treating the old one as if it never existed (as I think Junio was saying)? By this I mean the command should fail if the user doesn't give a SHA-1 and the previous message wouldn't be preloaded. --amend, on the other hand, would give the user an opportunity to revise the tag by opening, by default, the editor with the pre-existing message unless given the '--no-edit' option, and if not given a SHA-1 it would keep on using the previous one. > Calling it "--amend" would make perfect > sense (and then fixing "--no-edit" so it lets you avoid opening the > editor). So I think there are two bits of work: > > 1. Add an "--amend" option, which allows overwriting an existing tag > and pre-populates the message with the existing tag's message. > > 2. Make --no-edit work like the patch I showed earlier (assuming that > your --amend still opens an editor by default). > > -Peff ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Feature request: Add --no-edit to git tag command 2019-04-11 18:20 ` Bárbara de Castro Fernandes @ 2019-04-11 18:29 ` Jeff King 2019-04-12 2:32 ` Junio C Hamano 0 siblings, 1 reply; 13+ messages in thread From: Jeff King @ 2019-04-11 18:29 UTC (permalink / raw) To: Bárbara de Castro Fernandes; +Cc: Robert Dailey, Taylor Blau, Git On Thu, Apr 11, 2019 at 03:20:52PM -0300, Bárbara de Castro Fernandes wrote: > This new proposed --amend option, although semantically different, > would have a very similar functionality to the already existing -f > option. So should we, perhaps, change -f's behavior to treat the tag > as a new one, treating the old one as if it never existed (as I think > Junio was saying)? By this I mean the command should fail if the user > doesn't give a SHA-1 and the previous message wouldn't be preloaded. > --amend, on the other hand, would give the user an opportunity to > revise the tag by opening, by default, the editor with the > pre-existing message unless given the '--no-edit' option, and if not > given a SHA-1 it would keep on using the previous one. Yes, that's what I'd expect it to do (so yes, it's also different from "-f" in that it defaults to the existing tag destination instead of HEAD). -Peff ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Feature request: Add --no-edit to git tag command 2019-04-11 18:29 ` Jeff King @ 2019-04-12 2:32 ` Junio C Hamano 2019-04-12 2:33 ` Jeff King 0 siblings, 1 reply; 13+ messages in thread From: Junio C Hamano @ 2019-04-12 2:32 UTC (permalink / raw) To: Jeff King Cc: Bárbara de Castro Fernandes, Robert Dailey, Taylor Blau, Git Jeff King <peff@peff.net> writes: > On Thu, Apr 11, 2019 at 03:20:52PM -0300, Bárbara de Castro Fernandes wrote: > >> This new proposed --amend option, although semantically different, >> would have a very similar functionality to the already existing -f >> option. So should we, perhaps, change -f's behavior to treat the tag >> as a new one, treating the old one as if it never existed (as I think >> Junio was saying)? By this I mean the command should fail if the user >> doesn't give a SHA-1 and the previous message wouldn't be preloaded. >> --amend, on the other hand, would give the user an opportunity to >> revise the tag by opening, by default, the editor with the >> pre-existing message unless given the '--no-edit' option, and if not >> given a SHA-1 it would keep on using the previous one. > > Yes, that's what I'd expect it to do (so yes, it's also different from > "-f" in that it defaults to the existing tag destination instead of > HEAD). Do you mean you'd expect "--amend" to do that, which is different from what "-f" does, so they should not be conflated into one? If so, I think that makes sense and changing the behaviour of "-f" is too confusing. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Feature request: Add --no-edit to git tag command 2019-04-12 2:32 ` Junio C Hamano @ 2019-04-12 2:33 ` Jeff King 0 siblings, 0 replies; 13+ messages in thread From: Jeff King @ 2019-04-12 2:33 UTC (permalink / raw) To: Junio C Hamano Cc: Bárbara de Castro Fernandes, Robert Dailey, Taylor Blau, Git On Fri, Apr 12, 2019 at 11:32:25AM +0900, Junio C Hamano wrote: > Jeff King <peff@peff.net> writes: > > > On Thu, Apr 11, 2019 at 03:20:52PM -0300, Bárbara de Castro Fernandes wrote: > > > >> This new proposed --amend option, although semantically different, > >> would have a very similar functionality to the already existing -f > >> option. So should we, perhaps, change -f's behavior to treat the tag > >> as a new one, treating the old one as if it never existed (as I think > >> Junio was saying)? By this I mean the command should fail if the user > >> doesn't give a SHA-1 and the previous message wouldn't be preloaded. > >> --amend, on the other hand, would give the user an opportunity to > >> revise the tag by opening, by default, the editor with the > >> pre-existing message unless given the '--no-edit' option, and if not > >> given a SHA-1 it would keep on using the previous one. > > > > Yes, that's what I'd expect it to do (so yes, it's also different from > > "-f" in that it defaults to the existing tag destination instead of > > HEAD). > > Do you mean you'd expect "--amend" to do that, which is different > from what "-f" does, so they should not be conflated into one? > > If so, I think that makes sense and changing the behaviour of "-f" > is too confusing. Yes, sorry to be unclear. The "it" in my sentence was "--amend". -Peff ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Feature request: Add --no-edit to git tag command 2019-04-04 1:57 ` Jeff King 2019-04-04 3:26 ` Taylor Blau @ 2019-04-04 9:13 ` Junio C Hamano 2019-04-04 12:01 ` Jeff King 1 sibling, 1 reply; 13+ messages in thread From: Junio C Hamano @ 2019-04-04 9:13 UTC (permalink / raw) To: Jeff King; +Cc: Robert Dailey, Git Jeff King <peff@peff.net> writes: > On Wed, Apr 03, 2019 at 09:38:02AM -0500, Robert Dailey wrote: > >> Similar to git commit, it would be nice to have a --no-edit option for >> git tag. Use case is when I force-recreate a tag: >> >> $ git tag -af 1.0 123abc >> >> An editor will be prompted with the previous annotated tag message. I >> would like to add --no-edit to instruct it to use any previously >> provided message and without prompting the editor: >> >> $ git tag --no-edit -af 1.0 123abc > > Yeah, that sounds like a good idea. I am not so sure this is a good idea, especially if the plan is to do this alone without necessary associated change to make things consistent. The part that bothers me most is use of "-f". The mentalitly behind "-f" is "I am creating a new and tag that is totally unrelated to any existing tag, but since the command refuses to reuse the ref to point at my new tag, I am giving an '-f' to force (1) unpointing the existing unrelated tag and (2) pointing the enwly created tag with that tagname". The proposed change still uses "-f" but wants to somehow take the tag message from the unrelated tag that happens to sit at the same place as the new tag wants to go. That breaks the mental model a big way. If this were a new option that is spelled "--amend", I won't be complaining, though. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Feature request: Add --no-edit to git tag command 2019-04-04 9:13 ` Junio C Hamano @ 2019-04-04 12:01 ` Jeff King 0 siblings, 0 replies; 13+ messages in thread From: Jeff King @ 2019-04-04 12:01 UTC (permalink / raw) To: Junio C Hamano; +Cc: Robert Dailey, Git On Thu, Apr 04, 2019 at 06:13:16PM +0900, Junio C Hamano wrote: > >> Similar to git commit, it would be nice to have a --no-edit option for > >> git tag. Use case is when I force-recreate a tag: > >> > >> $ git tag -af 1.0 123abc > >> > >> An editor will be prompted with the previous annotated tag message. I > >> would like to add --no-edit to instruct it to use any previously > >> provided message and without prompting the editor: > >> > >> $ git tag --no-edit -af 1.0 123abc > > > > Yeah, that sounds like a good idea. > > I am not so sure this is a good idea, especially if the plan is to > do this alone without necessary associated change to make things > consistent. I think I may have misunderstood the request. I thought it was "we already do this re-use the tag message thing, but --no-edit is broken". And the proposal was to fix --no-edit. Which is definitely broken, and it seems like a no-brainer to fix. But looking at the code, yeah, I see that we do not do that. The proposal is to implement both halves. And... > The part that bothers me most is use of "-f". The mentalitly behind > "-f" is "I am creating a new and tag that is totally unrelated to > any existing tag, but since the command refuses to reuse the ref to > point at my new tag, I am giving an '-f' to force (1) unpointing the > existing unrelated tag and (2) pointing the enwly created tag with > that tagname". > > The proposed change still uses "-f" but wants to somehow take the > tag message from the unrelated tag that happens to sit at the same > place as the new tag wants to go. That breaks the mental model a > big way. > > If this were a new option that is spelled "--amend", I won't > be complaining, though. Yes, I agree with all of this. Calling it "--amend" is much better (and/or adding the equivalent of "commit -c" to pick up the message from an existing tag, though maybe "--amend existing-name new-target" would be enough to repoint a tag with the same name). -Peff ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2019-04-12 2:33 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-04-03 14:38 Feature request: Add --no-edit to git tag command Robert Dailey 2019-04-04 1:57 ` Jeff King 2019-04-04 3:26 ` Taylor Blau 2019-04-04 12:06 ` Jeff King 2019-04-04 13:56 ` Robert Dailey 2019-04-04 13:57 ` Robert Dailey 2019-04-05 22:21 ` Jeff King 2019-04-11 18:20 ` Bárbara de Castro Fernandes 2019-04-11 18:29 ` Jeff King 2019-04-12 2:32 ` Junio C Hamano 2019-04-12 2:33 ` Jeff King 2019-04-04 9:13 ` Junio C Hamano 2019-04-04 12:01 ` Jeff King
Code repositories for project(s) associated with this public inbox https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).