* Re: [PATCH] Have git-revert, git-cherry-pick cleanup ./.msg upon successful completion.
2007-05-04 14:32 ` [PATCH] Have git-revert, git-cherry-pick cleanup ./.msg upon successful completion Gerrit Pape
@ 2007-05-04 15:28 ` Alex Riesen
2007-05-05 3:46 ` Shawn O. Pearce
2007-05-07 10:53 ` [PATCH] Have git-revert, git-cherry-pick use $GIT_DIR/COMMIT_MSG instead of ./.msg Gerrit Pape
2 siblings, 0 replies; 10+ messages in thread
From: Alex Riesen @ 2007-05-04 15:28 UTC (permalink / raw)
To: git
On 5/4/07, Gerrit Pape <pape@smarden.org> wrote:
> git-revert and git-cherry-pick left behind the commit message file ./.msg,
> have them use the -f option to git-commit to properly cleanup the
> automatically created file.
Could we also have the files in $GIT_DIR instead of in working directory?
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] Have git-revert, git-cherry-pick cleanup ./.msg upon successful completion.
2007-05-04 14:32 ` [PATCH] Have git-revert, git-cherry-pick cleanup ./.msg upon successful completion Gerrit Pape
2007-05-04 15:28 ` Alex Riesen
@ 2007-05-05 3:46 ` Shawn O. Pearce
2007-05-06 6:49 ` Junio C Hamano
2007-05-07 7:46 ` Gerrit Pape
2007-05-07 10:53 ` [PATCH] Have git-revert, git-cherry-pick use $GIT_DIR/COMMIT_MSG instead of ./.msg Gerrit Pape
2 siblings, 2 replies; 10+ messages in thread
From: Shawn O. Pearce @ 2007-05-05 3:46 UTC (permalink / raw)
To: Gerrit Pape; +Cc: git, Alex Riesen
Gerrit Pape <pape@smarden.org> wrote:
> git-revert and git-cherry-pick left behind the commit message file ./.msg,
> have them use the -f option to git-commit to properly cleanup the
> automatically created file.
I'm actually sort of against changing the behavior of git-commit
-f to mean "delete the file". We never did that before. Users
might get surprised when their file goes away!
What about this change instead? We make cherry-pick/revert
use the same temporary file as merge, which is under .git/
(something Alex mentioned he wanted). I think the use of ".msg"
in cherry-pick/revert has always just been a bug, and not a feature,
so I'm really not against changing things around like this.
diff --git a/builtin-revert.c b/builtin-revert.c
index 4ba0ee6..67c13a3 100644
--- a/builtin-revert.c
+++ b/builtin-revert.c
@@ -237,6 +237,7 @@ static int revert_or_cherry_pick(int argc, const char **argv)
int i;
char *oneline, *reencoded_message = NULL;
const char *message, *encoding;
+ const char *defmsg = git_path("MERGE_MSG");
git_config(git_default_config);
me = action == REVERT ? "revert" : "cherry-pick";
@@ -280,7 +281,7 @@ static int revert_or_cherry_pick(int argc, const char **argv)
* reverse of it if we are revert.
*/
- msg_fd = hold_lock_file_for_update(&msg_file, ".msg", 1);
+ msg_fd = hold_lock_file_for_update(&msg_file, defmsg, 1);
encoding = get_encoding(message);
if (!encoding)
@@ -330,7 +331,6 @@ static int revert_or_cherry_pick(int argc, const char **argv)
sha1_to_hex(head), "HEAD",
sha1_to_hex(next->object.sha1), oneline) ||
write_tree(head, 0, NULL)) {
- const char *target = git_path("MERGE_MSG");
add_to_msg("\nConflicts:\n\n");
read_cache();
for (i = 0; i < active_nr;) {
@@ -345,10 +345,7 @@ static int revert_or_cherry_pick(int argc, const char **argv)
}
}
if (close(msg_fd) || commit_lock_file(&msg_file) < 0)
- die ("Error wrapping up .msg");
- unlink(target);
- if (rename(".msg", target))
- die ("Could not move .msg to %s", target);
+ die ("Error wrapping up %s", defmsg);
fprintf(stderr, "Automatic %s failed. "
"After resolving the conflicts,\n"
"mark the corrected paths with 'git-add <paths>'\n"
@@ -362,7 +359,7 @@ static int revert_or_cherry_pick(int argc, const char **argv)
exit(1);
}
if (close(msg_fd) || commit_lock_file(&msg_file) < 0)
- die ("Error wrapping up .msg");
+ die ("Error wrapping up %s", defmsg);
fprintf(stderr, "Finished one %s.\n", me);
/*
@@ -376,11 +373,9 @@ static int revert_or_cherry_pick(int argc, const char **argv)
if (!no_commit) {
if (edit)
- return execl_git_cmd("commit", "-n", "-F", ".msg",
- "-e", NULL);
+ return execl_git_cmd("commit", "-n", NULL);
else
- return execl_git_cmd("commit", "-n", "-F", ".msg",
- NULL);
+ return execl_git_cmd("commit", "-n", "-F", defmsg, NULL);
}
if (reencoded_message)
free(reencoded_message);
--
Shawn.
^ permalink raw reply related [flat|nested] 10+ messages in thread* Re: [PATCH] Have git-revert, git-cherry-pick cleanup ./.msg upon successful completion.
2007-05-05 3:46 ` Shawn O. Pearce
@ 2007-05-06 6:49 ` Junio C Hamano
2007-05-08 1:35 ` Shawn O. Pearce
2007-05-07 7:46 ` Gerrit Pape
1 sibling, 1 reply; 10+ messages in thread
From: Junio C Hamano @ 2007-05-06 6:49 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Gerrit Pape, git, Alex Riesen
"Shawn O. Pearce" <spearce@spearce.org> writes:
> What about this change instead? We make cherry-pick/revert
> use the same temporary file as merge, which is under .git/
> (something Alex mentioned he wanted). I think the use of ".msg"
> in cherry-pick/revert has always just been a bug, and not a feature,
> so I'm really not against changing things around like this.
While I would not say this is not an improvement, this makes
MERGE_MSG even less about merges and pushes us away from a
sensible "git whatnow".
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] Have git-revert, git-cherry-pick cleanup ./.msg upon successful completion.
2007-05-06 6:49 ` Junio C Hamano
@ 2007-05-08 1:35 ` Shawn O. Pearce
2007-05-08 1:42 ` Junio C Hamano
0 siblings, 1 reply; 10+ messages in thread
From: Shawn O. Pearce @ 2007-05-08 1:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Gerrit Pape, git, Alex Riesen
Junio C Hamano <junkio@cox.net> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> > What about this change instead? We make cherry-pick/revert
> > use the same temporary file as merge, which is under .git/
> > (something Alex mentioned he wanted). I think the use of ".msg"
> > in cherry-pick/revert has always just been a bug, and not a feature,
> > so I'm really not against changing things around like this.
>
> While I would not say this is not an improvement, this makes
> MERGE_MSG even less about merges and pushes us away from a
> sensible "git whatnow".
I think that ship has already sailed. Look at builtin-revert.c
on:
333 const char *target = git_path("MERGE_MSG");
We're already using MERGE_MSG to prep the message for a conflicted
cherry-pick or revert that the user needs to resolve by hand. I
think we do the same thing in git-rebase, don't we?
Gerrit's patch to try and use COMMIT_MSG feels wrong to me, as
git-commit overwrites that file with what it gets from its "input".
I agree my patch steps us further from a "git whatnow", but we're
already in deep with MERGE_MSG. We might as well keep that existing
convention that it can be used to prep the commit message for the
next git-commit invocation, and record other data somehow for the
"git whatnow" case.
--
Shawn.
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH] Have git-revert, git-cherry-pick cleanup ./.msg upon successful completion.
2007-05-08 1:35 ` Shawn O. Pearce
@ 2007-05-08 1:42 ` Junio C Hamano
0 siblings, 0 replies; 10+ messages in thread
From: Junio C Hamano @ 2007-05-08 1:42 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Gerrit Pape, git, Alex Riesen
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Gerrit's patch to try and use COMMIT_MSG feels wrong to me, as
> git-commit overwrites that file with what it gets from its "input".
Yes.
> I agree my patch steps us further from a "git whatnow", but we're
> already in deep with MERGE_MSG. We might as well keep that existing
> convention that it can be used to prep the commit message for the
> next git-commit invocation, and record other data somehow for the
> "git whatnow" case.
Fair enough.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] Have git-revert, git-cherry-pick cleanup ./.msg upon successful completion.
2007-05-05 3:46 ` Shawn O. Pearce
2007-05-06 6:49 ` Junio C Hamano
@ 2007-05-07 7:46 ` Gerrit Pape
1 sibling, 0 replies; 10+ messages in thread
From: Gerrit Pape @ 2007-05-07 7:46 UTC (permalink / raw)
To: git
On Fri, May 04, 2007 at 11:46:15PM -0400, Shawn O. Pearce wrote:
> Gerrit Pape <pape@smarden.org> wrote:
> > git-revert and git-cherry-pick left behind the commit message file ./.msg,
> > have them use the -f option to git-commit to properly cleanup the
> > automatically created file.
>
> I'm actually sort of against changing the behavior of git-commit
> -f to mean "delete the file". We never did that before. Users
> might get surprised when their file goes away!
-f never was documented AFAICS, only -F, and even though the file is
gone, the commit message is available through git show then. I
personally would like to have such an option to git commit regardless of
revert and cherry-pick.
I concur with Alex that the teporary file should be in the git directory
and not working directory.
Regards, Gerrit.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH] Have git-revert, git-cherry-pick use $GIT_DIR/COMMIT_MSG instead of ./.msg.
2007-05-04 14:32 ` [PATCH] Have git-revert, git-cherry-pick cleanup ./.msg upon successful completion Gerrit Pape
2007-05-04 15:28 ` Alex Riesen
2007-05-05 3:46 ` Shawn O. Pearce
@ 2007-05-07 10:53 ` Gerrit Pape
2007-05-07 10:54 ` [PATCH] git-commit: fix usage to show (-F|-f) <logfile> Gerrit Pape
2 siblings, 1 reply; 10+ messages in thread
From: Gerrit Pape @ 2007-05-07 10:53 UTC (permalink / raw)
To: git
On Fri, May 04, 2007 at 05:28:21PM +0200, Alex Riesen wrote:
> On 5/4/07, Gerrit Pape <pape@smarden.org> wrote:
> >git-revert and git-cherry-pick left behind the commit message file ./.msg,
> >have them use the -f option to git-commit to properly cleanup the
> >automatically created file.
>
> Could we also have the files in $GIT_DIR instead of in working directory?
Yes, .git/COMMIT_MSG is already used by git-commit and git-svn, and can be
used here too.
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
builtin-revert.c | 24 +++++++++++++-----------
1 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/builtin-revert.c b/builtin-revert.c
index 9acdf47..5aff283 100644
--- a/builtin-revert.c
+++ b/builtin-revert.c
@@ -126,14 +126,15 @@ char *get_encoding(const char *message)
return NULL;
}
-struct lock_file msg_file;
+static const char* msg_file;
+struct lock_file msg_file_lock;
static int msg_fd;
static void add_to_msg(const char *string)
{
int len = strlen(string);
if (write_in_full(msg_fd, string, len) < 0)
- die ("Could not write to .msg");
+ die ("Could not write to %s", msg_file);
}
static void add_message_to_msg(const char *message)
@@ -280,7 +281,8 @@ static int revert_or_cherry_pick(int argc, const char **argv)
* reverse of it if we are revert.
*/
- msg_fd = hold_lock_file_for_update(&msg_file, ".msg", 1);
+ msg_file = git_path("COMMIT_MSG");
+ msg_fd = hold_lock_file_for_update(&msg_file_lock, msg_file, 1);
encoding = get_encoding(message);
if (!encoding)
@@ -344,11 +346,11 @@ static int revert_or_cherry_pick(int argc, const char **argv)
i++;
}
}
- if (close(msg_fd) || commit_lock_file(&msg_file) < 0)
- die ("Error wrapping up .msg");
+ if (close(msg_fd) || commit_lock_file(&msg_file_lock) < 0)
+ die ("Error wrapping up %s", msg_file);
unlink(target);
- if (rename(".msg", target))
- die ("Could not move .msg to %s", target);
+ if (rename(msg_file, target))
+ die ("Could not move %s to %s", msg_file, target);
fprintf(stderr, "Automatic %s failed. "
"After resolving the conflicts,\n"
"mark the corrected paths with 'git-add <paths>'\n"
@@ -361,8 +363,8 @@ static int revert_or_cherry_pick(int argc, const char **argv)
}
exit(1);
}
- if (close(msg_fd) || commit_lock_file(&msg_file) < 0)
- die ("Error wrapping up .msg");
+ if (close(msg_fd) || commit_lock_file(&msg_file_lock) < 0)
+ die ("Error wrapping up %s", msg_file);
fprintf(stderr, "Finished one %s.\n", me);
/*
@@ -376,10 +378,10 @@ static int revert_or_cherry_pick(int argc, const char **argv)
if (!no_commit) {
if (edit)
- return execl_git_cmd("commit", "-n", "-f", ".msg",
+ return execl_git_cmd("commit", "-n", "-f", msg_file,
"-e", NULL);
else
- return execl_git_cmd("commit", "-n", "-f", ".msg",
+ return execl_git_cmd("commit", "-n", "-f", msg_file,
NULL);
}
if (reencoded_message)
--
1.5.1.2
^ permalink raw reply related [flat|nested] 10+ messages in thread