{"thread":{"id":"39449","subject":"[RFC/PATCH v2] create a skeleton for the command git rebase --status","startedAt":"2015-05-28T14:20:37Z","lastAt":"2015-05-29T15:44:08Z","messageCount":10,"participants":["Guillaume Pagès","Matthieu Moy","Guillaume Pages","Junio C Hamano"],"isPatch":true,"patchVersion":2,"patchTotal":null},"messages":[{"id":"262332","messageId":"1432822837-10320-1-git-send-email-guillaume.pages@ensimag.grenoble-inp.fr","threadId":"39449","inReplyTo":null,"subject":"[RFC/PATCH v2] create a skeleton for the command git rebase --status","fromName":"Guillaume Pagès","fromEmail":"guillaume.pages@ensimag.grenoble-inp.fr","sentAt":"2015-05-28T14:20:37Z","receivedAt":"2015-05-28T14:20:37Z","isPatch":true,"sender":{"key":"guillaume.pages@ensimag.grenoble-inp.fr","avatar":null},"body":"Preparatory commit for a git rebase --status command. This command\nwill indicate the state of the process in the rebase, and the reason\nwhy it stopped.\n\nSigned-off-by: Guillaume Pagès \n---\n\nThe observations from Matthieu Moy have been taken into account \n\nIt is an almost empty code sent to validate the global architecture of\nthis command. It is written in C because git status is already in C\nand it seems that it is the current tendency to port shell code to\nC. Moreover will likely use code from wt_status to implement this\nfunctionnality. The command calls a helper from a shell script, as it\nis made in bisect (bisect--helper.c).\n\n Makefile | 2 ++\n builtin.h | 1 +\n builtin/rebase--status--helper.c | 23 +++++++++++++++++++++++\n git-rebase.sh | 6 +++++-\n git.c | 1 +\n rebase--status.c | 6 ++++++\n rebase--status.h | 7 +++++++\n 7 files changed, 45 insertions(+), 1 deletion(-)\n create mode 100644 builtin/rebase--status--helper.c\n create mode 100644 rebase--status.c\n create mode 100644 rebase--status.h\n\ndiff --git a/Makefile b/Makefile\nindex e0caec3..e3b3e63 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -853,6 +853,7 @@ LIB_OBJS += prompt.o\n LIB_OBJS += quote.o\n LIB_OBJS += reachable.o\n LIB_OBJS += read-cache.o\n+LIB_OBJS += rebase--status.o\n LIB_OBJS += reflog-walk.o\n LIB_OBJS += refs.o\n LIB_OBJS += remote.o\n@@ -969,6 +970,7 @@ BUILTIN_OBJS += builtin/prune-packed.o\n BUILTIN_OBJS += builtin/prune.o\n BUILTIN_OBJS += builtin/push.o\n BUILTIN_OBJS += builtin/read-tree.o\n+BUILTIN_OBJS += builtin/rebase--status--helper.o\n BUILTIN_OBJS += builtin/receive-pack.o\n BUILTIN_OBJS += builtin/reflog.o\n BUILTIN_OBJS += builtin/remote.o\ndiff --git a/builtin.h b/builtin.h\nindex c47c110..5071a08 100644\n--- a/builtin.h\n+++ b/builtin.h\n@@ -99,6 +99,7 @@ extern int cmd_prune(int argc, const char **argv, const char *prefix);\n extern int cmd_prune_packed(int argc, const char **argv, const char *prefix);\n extern int cmd_push(int argc, const char **argv, const char *prefix);\n extern int cmd_read_tree(int argc, const char **argv, const char *prefix);\n+extern int cmd_rebase_status__helper(int argc, const char **argv, const char *prefix);\n extern int cmd_receive_pack(int argc, const char **argv, const char *prefix);\n extern int cmd_reflog(int argc, const char **argv, const char *prefix);\n extern int cmd_remote(int argc, const char **argv, const char *prefix);\ndiff --git a/builtin/rebase--status--helper.c b/builtin/rebase--status--helper.c\nnew file mode 100644\nindex 0000000..efda29c\n--- /dev/null\n+++ b/builtin/rebase--status--helper.c\n@@ -0,0 +1,23 @@\n+#include \"builtin.h\"\n+#include \"cache.h\"\n+#include \"parse-options.h\"\n+#include \"rebase--status.h\"\n+\n+static const char * const git_rebase_status_helper_usage[] = {\n+\tN_(\"git rebase--status--helper\"),\n+\tNULL\n+};\n+\n+int cmd_rebase_status__helper(int argc, const char **argv, const char *prefix)\n+{\n+\tstruct option options[] = {\n+\t\t\n+\t};\n+\n+\targc = parse_options(argc, argv, prefix, options,\n+\t\t\t git_rebase_status_helper_usage, 0);\n+\n+\n+\t/* next-all */\n+\treturn rebase_status();\n+}\ndiff --git a/git-rebase.sh b/git-rebase.sh\nindex 47ca3b9..4e1f3e1 100755\n--- a/git-rebase.sh\n+++ b/git-rebase.sh\n@@ -43,6 +43,7 @@ continue! continue\n abort! abort and check out the original branch\n skip! skip current patch and continue\n edit-todo! edit the todo list during an interactive rebase\n+status! show the status of the current rebase\n \"\n . git-sh-setup\n . git-sh-i18n\n@@ -238,7 +239,7 @@ do\n \t--verify)\n \t\tok_to_skip_pre_rebase=\n \t\t;;\n-\t--continue|--skip|--abort|--edit-todo)\n+\t--continue|--skip|--abort|--edit-todo|--status)\n \t\ttest $total_argc -eq 2 || usage\n \t\taction=${1##--}\n \t\t;;\n@@ -401,6 +402,9 @@ abort)\n edit-todo)\n \trun_specific_rebase\n \t;;\n+status)\n+\texec git rebase--status--helper\n+\t;;\n esac\n \n # Make sure no rebase is in progress\ndiff --git a/git.c b/git.c\nindex 9efd1a3..3ebc144 100644\n--- a/git.c\n+++ b/git.c\n@@ -410,6 +410,7 @@ static struct cmd_struct commands[] = {\n \t{ \"prune-packed\", cmd_prune_packed, RUN_SETUP },\n \t{ \"push\", cmd_push, RUN_SETUP },\n \t{ \"read-tree\", cmd_read_tree, RUN_SETUP },\n+\t{ \"rebase--status--helper\", cmd_rebase_status__helper, RUN_SETUP },\n \t{ \"receive-pack\", cmd_receive_pack },\n \t{ \"reflog\", cmd_reflog, RUN_SETUP },\n \t{ \"remote\", cmd_remote, RUN_SETUP },\ndiff --git a/rebase--status.c b/rebase--status.c\nnew file mode 100644\nindex 0000000..1962349\n--- /dev/null\n+++ b/rebase--status.c\n@@ -0,0 +1,6 @@\n+#include \"rebase--status.h\"\n+\n+int rebase_status(){\n+\tprintf(\"git rebase --status is not yet implemented\\n\");\n+\treturn 0;\n+}\ndiff --git a/rebase--status.h b/rebase--status.h\nnew file mode 100644\nindex 0000000..17d22a1\n--- /dev/null\n+++ b/rebase--status.h\n@@ -0,0 +1,7 @@\n+#ifndef REBASE__STATUS_H\n+#define REBASE__STATUS_H\n+\n+\n+extern int rebase_status();\n+\n+#endif\n-- \n2.0.5.6.g818b3fd\n"},{"id":"262335","messageId":"vpqpp5k1zjz.fsf@anie.imag.fr","threadId":"39449","inReplyTo":"1432822837-10320-1-git-send-email-guillaume.pages@ensimag.grenoble-inp.fr","subject":"Re: [RFC/PATCH v2] create a skeleton for the command git rebase --status","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2015-05-28T15:39:44Z","receivedAt":"2015-05-28T15:39:44Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Guillaume Pagès writes:\n\n> It is an almost empty code sent to validate the global architecture of\n> this command. It is written in C because git status is already in C\n> and it seems that it is the current tendency to port shell code to\n> C. Moreover will likely use code from wt_status to implement this\n> functionnality. The command calls a helper from a shell script, as it\n> is made in bisect (bisect--helper.c).\n\nI think this paragraph makes sense in the commit message. My previous\nremark was about the wording, not about the relevance of the arguments.\n\n> +static const char * const git_rebase_status_helper_usage[] = {\n> +\tN_(\"git rebase--status--helper\"),\n> +\tNULL\n> +};\n> +\n> +int cmd_rebase_status__helper(int argc, const char **argv, const char *prefix)\n> +{\n> +\tstruct option options[] = {\n> +\t\t\n> +\t};\n\nYou need to tell parse_options when the array is over (that's C ...) =>\nOPT_END().\n\n> +\targc = parse_options(argc, argv, prefix, options,\n> +\t\t\t git_rebase_status_helper_usage, 0);\n\nActually, you don't need option-parsing at all since you don't pass\narguments to the helper, but why not have this in case we need it later.\n\nNo need to resend now, you'll send a new version when you have something\nto build on top (or if someone has more important remarks).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"262336","messageId":"1141577560.115469.1432827789020.JavaMail.zimbra@ensimag.grenoble-inp.fr","threadId":"39449","inReplyTo":"CACRoPnRa1wrOJr=wGnR4NayZfe2yJ4F7Abv_sjqRpgQnicxm1g@mail.gmail.com","subject":"Re: [RFC/PATCH v2] create a skeleton for the command git rebase --status","fromName":"Guillaume Pages","fromEmail":"guillaume.pages@ensimag.grenoble-inp.fr","sentAt":"2015-05-28T15:43:09Z","receivedAt":"2015-05-28T15:43:09Z","isPatch":true,"sender":{"key":"guillaume.pages@ensimag.grenoble-inp.fr","avatar":null},"body":"\nHi, \n\n\"Paul Tan\" : \n> I haven't kept up with the discussion, but I'm wondering: since you \n> need the functionality in wt-status.c, why not implement it in git \n> status? In fact, git-status already shows if there is a rebase in \n> progress, so why not extend it to say which patch/todo line the rebase \n> stopped on? It feels much more natural to me to use git-status to \n> check the status of the rebase, instead of git rebase --status. \n> Thanks, Paul \n\nIt's a question I have asked myself but since git rebase --status will \ncertainly display more information maybe it's better to separate the \ntwo commands, and to indicate the user that git rebase --status exists \nin git status during a rebase. If we choose to use git status, it \ncould be an option to display the full information since it currently \ngives very few information. I'm not sure what -verbose does but it \ncould be its role. \n\nThanks, \n\nGuillaume Pagès \n"},{"id":"262337","messageId":"vpqiobcy9yt.fsf@anie.imag.fr","threadId":"39449","inReplyTo":"1141577560.115469.1432827789020.JavaMail.zimbra@ensimag.grenoble-inp.fr","subject":"Re: [RFC/PATCH v2] create a skeleton for the command git rebase --status","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2015-05-28T15:53:46Z","receivedAt":"2015-05-28T15:53:46Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Guillaume Pages writes:\n\n> Hi, \n>\n> \"Paul Tan\" : \n>> I haven't kept up with the discussion, but I'm wondering: since you \n>> need the functionality in wt-status.c, why not implement it in git \n>> status? In fact, git-status already shows if there is a rebase in \n>> progress, so why not extend it to say which patch/todo line the rebase \n>> stopped on? It feels much more natural to me to use git-status to \n>> check the status of the rebase, instead of git rebase --status. \n>> Thanks, Paul \n>\n> It's a question I have asked myself but since git rebase --status will \n> certainly display more information \n\nHistorically, I had the idea of \"git rebase --status\" and Ensimag\nstudents started working on it 2 years ago. The same question came back\nthen during the discussion: why not just in status? This lead to the\nheader in the output of \"git status\" (\"You are currently ...\", for\nrebase/am/bisect/...).\n\nBut I think there are more relevant information to show (e.g. list of\nalready applied commits, remaining list of commits, possibly truncated\nif the list is overly long, and information that rebase gave you when\nstopping like the path to the file being applied). Having them all in\n\"git status\" would make the output really long, for little benefit in\nday-to-day use.\n\nSo, to me, it makes sense to have a separate command \"tell me everything\nyou know about the current state of the rebase\".\n\n> If we choose to use git status, it could be an option to display the\n> full information since it currently gives very few information. I'm\n> not sure what -verbose does but it could be its role.\n\n\"git status --verbose\" is already taken for \"show me the diff together\nwith status\".\n\n(I'm also dreaming of a \"git status --tutor\" that would show detailed\nexplanations with pointers to the documentation & all for each section\nof \"status\". Useless for non-beginners, but could be a nice way to teach\nGit to beginners)\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"262356","messageId":"xmqqtwuwh8fv.fsf@gitster.dls.corp.google.com","threadId":"39449","inReplyTo":"vpqiobcy9yt.fsf@anie.imag.fr","subject":"Re: [RFC/PATCH v2] create a skeleton for the command git rebase --status","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-05-28T18:18:44Z","receivedAt":"2015-05-28T18:18:44Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> But I think there are more relevant information to show (e.g. list of\n> already applied commits, remaining list of commits, possibly truncated\n> if the list is overly long, and information that rebase gave you when\n> stopping like the path to the file being applied). Having them all in\n> \"git status\" would make the output really long, for little benefit in\n> day-to-day use.\n\nSorry, I do not quite agree with this reasoning.\n\nIsn't \"git status\" during a rebase that shows \"really long\"\ninformation to help the rebase operation a good thing? In\nday-to-day use when you are not in the middle of rebase, the command\nwould not show what remains to be done, would it?\n\nI may be biased, because I rarely use 'git status' while running\n'git rebase' (with or without interactive). But to me, 'git diff'\nwould be a more appropriate tool to help me unstuck in managing the\ncurrent step of conflict resolution than 'git status' gives me\nduring either a rebase or a merge as \"Unmerged paths\" anyway.\n\nIf this topic enhances 'git status' with the in-progress rebase\ninformation, I'd view it as turning 'git status' from 'a more or\nless useless command during rebase' to 'a useful command'.\n"},{"id":"262366","messageId":"vpqlhg8pk1o.fsf@anie.imag.fr","threadId":"39449","inReplyTo":"xmqqtwuwh8fv.fsf@gitster.dls.corp.google.com","subject":"Re: [RFC/PATCH v2] create a skeleton for the command git rebase --status","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2015-05-28T19:40:51Z","receivedAt":"2015-05-28T19:40:51Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> If this topic enhances 'git status' with the in-progress rebase\n> information, I'd view it as turning 'git status' from 'a more or\n> less useless command during rebase' to 'a useful command'.\n\nFor day-to-day operations, what we already have in status already\nqualifies as 'useful command' to me:\n\n$ git status\nrebase in progress; onto 7f9a792\nYou are currently rebasing branch 'master' on '7f9a792'.\n (fix conflicts and then run \"git rebase --continue\")\n (use \"git rebase --skip\" to skip this patch)\n (use \"git rebase --abort\" to check out the original branch)\n\nI like the output of \"git status\" to be concise. OTOH, there are tons of\ninformation in .git/rebase-merge/ that could be displayed to the user.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"262368","messageId":"xmqq382gh465.fsf@gitster.dls.corp.google.com","threadId":"39449","inReplyTo":"vpqlhg8pk1o.fsf@anie.imag.fr","subject":"Re: [RFC/PATCH v2] create a skeleton for the command git rebase --status","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-05-28T19:50:58Z","receivedAt":"2015-05-28T19:50:58Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> Junio C Hamano writes:\n>\n>> If this topic enhances 'git status' with the in-progress rebase\n>> information, I'd view it as turning 'git status' from 'a more or\n>> less useless command during rebase' to 'a useful command'.\n>\n> For day-to-day operations, what we already have in status already\n> qualifies as 'useful command' to me:\n>\n> $ git status\n> rebase in progress; onto 7f9a792\n> You are currently rebasing branch 'master' on '7f9a792'.\n> (fix conflicts and then run \"git rebase --continue\")\n> (use \"git rebase --skip\" to skip this patch)\n> (use \"git rebase --abort\" to check out the original branch)\n\nNot really. How would you decide if 7f9a792 is worth keeping or\nrebase is better be aborted without knowing where you are?\n\n> I like the output of \"git status\" to be concise.\n\nSure, as long as concise and useful, I am all for it. The above\nhowever does not show anything I already know in my prompt. I would\nsay no thanks to \"concise and useless\".\n\n> OTOH, there are tons of information in .git/rebase-merge/ that\n> could be displayed to the user.\n\nSurely, that is why \"git status\" during a rebase should show them.\n"},{"id":"262403","messageId":"12496325.145058.1432896023146.JavaMail.zimbra@ensimag.grenoble-inp.fr","threadId":"39449","inReplyTo":"xmqq382gh465.fsf@gitster.dls.corp.google.com","subject":"Re: [RFC/PATCH v2] create a skeleton for the command git rebase --status","fromName":"Guillaume Pages","fromEmail":"guillaume.pages@ensimag.grenoble-inp.fr","sentAt":"2015-05-29T10:40:23Z","receivedAt":"2015-05-29T10:40:23Z","isPatch":true,"sender":{"key":"guillaume.pages@ensimag.grenoble-inp.fr","avatar":null},"body":"After this discussion I eventually agree that it would be better\nupgrading git status than creating a new command.When people use git\nstatus, it means that they need information to continue their work, so\nif you don't even know that you are in a rebase, you will very likely\nneed information about the current rebase.\n\nDuring a classic rebase we could have output like:\n\nrebase in progress; onto d9d448a You are currently rebasing branch\n'branche1' on 'd9d448a'. (fix conflicts and then run \"git rebase\n--continue\") (use \"git rebase --skip\" to skip this patch) (use \"git\nrebase --abort\" to check out the original branch) (5 commits applied,\n3 remainings) Failed to apply:\n\n252c273 commit message\n\nUnmerged paths: (use \"git reset HEAD ...\" to unstage) (use \"git\nadd ...\" to mark resolution)\n\nboth modified: file1\n\n\nAnd during an interactive rebase:\n\nrebase in progress; onto 247c883 You are currently editing a commit\nwhile rebasing branch 'b1.1' on '247c883'. (use \"git commit --amend\"\nto amend the current commit) (use \"git rebase --continue\" once you are\nsatisfied with your changes)\n\nLast commands done (5 commands done) :\n\npick 62609785 commit message1 reword 85ae9001 new commit message2\n\n(See more at .git/rebase-merge/done)\n\nNext commands to do (3 remainings commands) :\n\nsquash 62609785 commit message3 pick 85ae9001 commit message4\n\n(See more at .git/rebase-merge/git-rebase-todo)\n\nChanges not staged for commit: (use \"git add ...\" to update what\nwill be committed) (use \"git checkout -- ...\" to discard changes\nin working directory)\n\nmodified: file1 ...\n\nIs it a good practice to send the user find information in the .git\ndirectory?\n\nThanks\n\nGuillaume\n"},{"id":"262422","messageId":"vpq4mmvv37f.fsf@anie.imag.fr","threadId":"39449","inReplyTo":"12496325.145058.1432896023146.JavaMail.zimbra@ensimag.grenoble-inp.fr","subject":"Re: [RFC/PATCH v2] create a skeleton for the command git rebase --status","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2015-05-29T15:00:20Z","receivedAt":"2015-05-29T15:00:20Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Guillaume Pages writes:\n\n> rebase in progress; onto d9d448a You are currently rebasing branch\n> 'branche1' on 'd9d448a'. (fix conflicts and then run \"git rebase\n> --continue\") (use \"git rebase --skip\" to skip this patch) (use \"git\n> rebase --abort\" to check out the original branch) (5 commits applied,\n> 3 remainings) Failed to apply:\n>\n> 252c273 commit message\n\nYou messed-up something with the formatting, but I agree that this would\nbe nice. I'd reverse order between the hints (\"(use ... to ...)\") and\nthe \"Failed to apply: ...\".\n\n> And during an interactive rebase:\n>\n> rebase in progress;\n\nThis could even become \"interactive rebase in progress\".\n\nMost of the time, you're supposed to remember whether you ran \"git\nrebase\" with -i, but a typical use-case is when a newbie requests help\nlike \"I don't know what I did, but can you fix it?\", and then any\ninformation can be valuable.\n\n> Last commands done (5 commands done) :\n>\n> pick 62609785 commit message1 reword 85ae9001 new commit message2\n>\n> (See more at .git/rebase-merge/done)\n>\n> Next commands to do (3 remainings commands) :\n>\n> squash 62609785 commit message3 pick 85ae9001 commit message4\n>\n> (See more at .git/rebase-merge/git-rebase-todo)\n\nNot sure the blank lines are meant to be there, but I wouldn't put them\nin the actual output. I'd format it as\n\nLast commands done (5 commands done) :\n pick 62609785 commit message1\n (see more at .git/rebase-merge/done)\n\n(lower-case \"see\" to be consistant with other hints)\n\n> Is it a good practice to send the user find information in the .git\n> directory?\n\nWe usually avoid doing that and provide commands to do this (e.g. \"git\nrebase --edit-todo\" instead of asking the user to do $EDITOR\n.git/rebase-merge/git-rebase-todo), but the ones you show seem OK to me.\n\nThere's already at least one instance of this when a rebase fails:\n\n Patch failed at 0001 foo\n The copy of the patch that failed is found in:\n /tmp/clone/.git/rebase-apply/patch\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"262427","messageId":"xmqqoal3e6d3.fsf@gitster.dls.corp.google.com","threadId":"39449","inReplyTo":"vpq4mmvv37f.fsf@anie.imag.fr","subject":"Re: [RFC/PATCH v2] create a skeleton for the command git rebase --status","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-05-29T15:44:08Z","receivedAt":"2015-05-29T15:44:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> Guillaume Pages writes:\n> ...\n>> And during an interactive rebase:\n>>\n>> rebase in progress;\n>\n> This could even become \"interactive rebase in progress\".\n>\n> Most of the time, you're supposed to remember whether you ran \"git\n> rebase\" with -i, but a typical use-case is when a newbie requests help\n> like \"I don't know what I did, but can you fix it?\", and then any\n> information can be valuable.\n\nYeah, I like that.\n\n> Not sure the blank lines are meant to be there, but I wouldn't put them\n> in the actual output. I'd format it as\n>\n> Last commands done (5 commands done) :\n> pick 62609785 commit message1\n> (see more at .git/rebase-merge/done)\n>\n> (lower-case \"see\" to be consistant with other hints)\n\nNice.\n\n>> Is it a good practice to send the user find information in the .git\n>> directory?\n>\n> We usually avoid doing that and provide commands to do this (e.g. \"git\n> rebase --edit-todo\" instead of asking the user to do $EDITOR\n> .git/rebase-merge/git-rebase-todo), but the ones you show seem OK to me.\n\nYeah, I think it is OK to suggest peeking into (not writing) files\nlike this. We may update the internal implementation but then the\nsuggestion can and should be updated when that happens.\n"}]}