{"thread":{"id":"17717","subject":"[PATCH] Fix file mark handling and sort side-effects in git.el","startedAt":"2009-02-11T06:12:28Z","lastAt":"2009-02-16T00:04:09Z","messageCount":7,"participants":["Brent Goodrick","Alexandre Julliard"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"104149","messageId":"18834.27724.991388.339214@hungover.brentg.com","threadId":"17717","inReplyTo":null,"subject":"[PATCH] Fix file mark handling and sort side-effects in git.el","fromName":"Brent Goodrick","fromEmail":"bgoodr@gmail.com","sentAt":"2009-02-11T06:12:28Z","receivedAt":"2009-02-11T06:12:28Z","isPatch":true,"sender":{"key":"bgoodr@gmail.com","avatar":"https://gravatar.com/avatar/2399bf5a3468b3516a892183edfd43a7fa0300a2e9d5072189020186961150bc?d=mp&s=160"},"body":"\nThe `sort' Elisp function works destructively, causing anomalies where\noperations on multiple files would be performed on one file. This\ncheckin works around that by doing a deep copy with `append'.\n\nAlso, git-add-file needed to pass 'modified to git-marked-files-state,\nas otherwise, files that are modified but not yet in the index would\nnot show up in the git-marked-files-state return value, which would\nthen cause a prompt for file to show up when the files are clearly\nmarked in the status buffer.\n\nSigned-off-by: Brent Goodrick \n---\n contrib/emacs/git.el | 6 +++---\n 1 files changed, 3 insertions(+), 3 deletions(-)\n\ndiff --git a/contrib/emacs/git.el b/contrib/emacs/git.el\nindex fcbe2d9..93e47c1 100644\n--- a/contrib/emacs/git.el\n+++ b/contrib/emacs/git.el\n@@ -532,7 +532,7 @@ Each entry is a cons of (SHORT-NAME . FULL-NAME).\"\n (defun git-status-filenames-map (status func files &rest args)\n \"Apply FUNC to the status files names in the FILES list.\"\n (when files\n- (setq files (sort files #'string-lessp))\n+ (setq files (sort (append files nil) #'string-lessp))\n (let ((file (pop files))\n (node (ewoc-nth status 0)))\n (while (and file node)\n@@ -773,7 +773,7 @@ Return the list of files that haven't been handled.\"\n \"Update the status of FILES from the index.\"\n (unless git-status (error \"Not in git-status buffer.\"))\n ;; set the needs-update flag on existing files\n- (if (setq files (sort files #'string-lessp))\n+ (if (setq files (sort (append files nil) #'string-lessp))\n (git-status-filenames-map\n git-status (lambda (info) (setf (git-fileinfo->needs-update info) t)) files)\n (ewoc-map (lambda (info) (setf (git-fileinfo->needs-update info) t) nil) git-status)\n@@ -1041,7 +1041,7 @@ Return the list of files that haven't been handled.\"\n (defun git-add-file ()\n \"Add marked file(s) to the index cache.\"\n (interactive)\n- (let ((files (git-get-filenames (git-marked-files-state 'unknown 'ignored))))\n+ (let ((files (git-get-filenames (git-marked-files-state 'modified 'unknown 'ignored))))\n ;; FIXME: add support for directories\n (unless files\n (push (file-relative-name (read-file-name \"File to add: \" nil nil t)) files))\n-- \n1.6.2.rc0.10.gf6b9.dirty\n"},{"id":"104172","messageId":"87hc31kzrb.fsf@wine.dyndns.org","threadId":"17717","inReplyTo":"18834.27724.991388.339214@hungover.brentg.com","subject":"Re: [PATCH] Fix file mark handling and sort side-effects in git.el","fromName":"Alexandre Julliard","fromEmail":"julliard@winehq.org","sentAt":"2009-02-11T10:56:56Z","receivedAt":"2009-02-11T10:56:56Z","isPatch":true,"sender":{"key":"julliard@winehq.org","avatar":null},"body":"Brent Goodrick writes:\n\n> The `sort' Elisp function works destructively, causing anomalies where\n> operations on multiple files would be performed on one file. This\n> checkin works around that by doing a deep copy with `append'.\n\nThis shouldn't be necessary, it's OK for git-status-update-files to\ndestroy the list. If there are callers that want the list to be\npreserved they should save it themselves.\n\n> Also, git-add-file needed to pass 'modified to git-marked-files-state,\n> as otherwise, files that are modified but not yet in the index would\n> not show up in the git-marked-files-state return value, which would\n> then cause a prompt for file to show up when the files are clearly\n> marked in the status buffer.\n\nNot sure what you mean here, it should not be possible for a file to be\nin modified state but not in the index. If you mean using git-add-file\nto do an update-index on an already tracked file, that's not what it's\nmeant to do.\n\n-- \nAlexandre Julliard\njulliard@winehq.org\n"},{"id":"104399","messageId":"18836.22386.987021.484807@hungover.brentg.com","threadId":"17717","inReplyTo":"e38bce640902120738h7b9bb75o42e1524cbfd95169@mail.gmail.com","subject":"Re: [PATCH] Fix file mark handling and sort side-effects in git.el","fromName":"Brent Goodrick","fromEmail":"bgoodr@gmail.com","sentAt":"2009-02-12T17:08:02Z","receivedAt":"2009-02-12T17:08:02Z","isPatch":true,"sender":{"key":"bgoodr@gmail.com","avatar":"https://gravatar.com/avatar/2399bf5a3468b3516a892183edfd43a7fa0300a2e9d5072189020186961150bc?d=mp&s=160"},"body":"\nHi Alexandre (Warning: Incoming long-in-the-tooth email),\n\nSee my comments below:\n\n > From: Alexandre Julliard \n > \n > Brent> The `sort' Elisp function works destructively, causing anomalies where\n > Brent> operations on multiple files would be performed on one file. This\n > Brent> checkin works around that by doing a deep copy with `append'.\n > \n Alexandre> This shouldn't be necessary, it's OK for git-status-update-files to\n Alexandre> destroy the list. If there are callers that want the list to be\n Alexandre> preserved they should save it themselves.\n\nLet me demonstrate the issue with the destructive sort showing that it\nis a problem (but only part of the problem). This long sequence shows\nmy reasoning as to what led me to make this patch:\n\n1. I created a scratch throwaway branch called\n bg/scratch-elisp-testing off of master in my git repo. In Emacs I\n executed M-x git-statux of my work area showing a couple of files\n that I do not want to git-add which I will leave alone, but\n otherwise there are no edits applied yet on the\n bg/scratch-elisp-testing throw away branch:\n\n,----\n| git status\n| # On branch bg/scratch-elisp-testing\n| # Untracked files:\n| # (use \"git add ...\" to include in what will be committed)\n| #\n| #\tDocumentation/share/\n| #\tpatch\n| nothing added to commit but untracked files present (use \"git add\" to track)\n`----\n\n2. I make editing changes to git.c and progress.c, but will refrain\n from executing git-add on those edits at this point. Then I\n execute M-x git-status from within Emacs and see:\n\n,----\n| Directory: ~/git_from_source/git/\n| Branch: bg/scratch-elisp-testing\n| Head: f6b98e46bd - git-web--browse: Fix check for /bin/start\n| \n| Unknown Documentation/share/\n| Modified git.c\n| Unknown patch\n| Modified progress.c\n| \n`----\n\nThis corresponds to git status output that looks like this:\n\n,----\n| git status\n| # On branch bg/scratch-elisp-testing\n| # Changed but not updated:\n| # (use \"git add ...\" to update what will be committed)\n| # (use \"git checkout -- ...\" to discard changes in working directory)\n| #\n| #\tmodified: git.c\n| #\tmodified: progress.c\n| #\n| # Untracked files:\n| # (use \"git add ...\" to include in what will be committed)\n| #\n| #\tDocumentation/share/\n| #\tpatch\n| no changes added to commit (use \"git add\" and/or \"git commit -a\")\n`----\n\n3. I would like those changes to be a part of the commit that I make,\n so I position the Emacs point onto \"git.c\" and type \"m\" to mark\n git.c, and do the same for progress.c. At this point, the\n *git-status* buffer shows as:\n\n,----\n| Directory: ~/git_from_source/git/\n| Branch: bg/scratch-elisp-testing\n| Head: f6b98e46bd - git-web--browse: Fix check for /bin/start\n| \n| Unknown Documentation/share/\n| * Modified git.c\n| Unknown patch\n| * Modified progress.c\n| \n`----\n\n4. I now type \"a\" to add the marked files (my expectation is that\n git-add will be executed on \"git.c\" and \"progress.c\" but not the\n other two files which I did not mark). But instead I see in the\n minibuffer a prompt asking about which files to apply the git-add:\n\n,----\n| File to add: ~/git_from_source/git/\n`----\n\n5. I debugged a bit and thought all I needed to do was add the\n 'modified symbol to the call to git-marked-files-state as this diff\n shows:\n\n--- cut here ---\ndiff --git a/contrib/emacs/git.el b/contrib/emacs/git.el\nindex fcbe2d9..b8c268b 100644\n--- a/contrib/emacs/git.el\n+++ b/contrib/emacs/git.el\n@@ -1041,7 +1041,7 @@ Return the list of files that haven't been handled.\"\n (defun git-add-file ()\n \"Add marked file(s) to the index cache.\"\n (interactive)\n- (let ((files (git-get-filenames (git-marked-files-state 'unknown 'ignored))))\n+ (let ((files (git-get-filenames (git-marked-files-state 'modified 'unknown 'ignored))))\n ;; FIXME: add support for directories\n (unless files\n (push (file-relative-name (read-file-name \"File to add: \" nil nil t)) files))\n--- cut here ---\n\n6. I ran \"git reset git.c progress.c\" to reset the state in git. So\n now git status reports similar to what it was when I started (but\n git.el is modified to add the 'modified symbol to the call to\n git-marked-fiels-state above):\n\n,----\n| git status\n| # On branch bg/scratch-elisp-testing\n| # Changed but not updated:\n| # (use \"git add ...\" to update what will be committed)\n| # (use \"git checkout -- ...\" to discard changes in working directory)\n| #\n| #\tmodified: contrib/emacs/git.el\n| #\tmodified: git.c\n| #\tmodified: progress.c\n| #\n| # Untracked files:\n| # (use \"git add ...\" to include in what will be committed)\n| #\n| #\tDocumentation/share/\n| #\tpatch\n| no changes added to commit (use \"git add\" and/or \"git commit -a\")\n`----\n\n7. Kill the *git-status* buffer to get a clean slate (hopefully, that\n is all one has to do to reset git.el's state).\n\n8. I ran M-x git-status again and saw:\n\n,----\n| Directory: ~/git_from_source/git/\n| Branch: bg/scratch-elisp-testing\n| Head: f6b98e46bd - git-web--browse: Fix check for /bin/start\n| \n| Unknown Documentation/share/\n| Modified contrib/emacs/git.el\n| Modified git.c\n| Unknown patch\n| Modified progress.c\n| \n`----\n\n9. I marked git.c and progress.c using \"m\" again and saw:\n\n,----\n| Directory: ~/git_from_source/git/\n| Branch: bg/scratch-elisp-testing\n| Head: f6b98e46bd - git-web--browse: Fix check for /bin/start\n| \n| Unknown Documentation/share/\n| Modified contrib/emacs/git.el\n| * Modified git.c\n| Unknown patch\n| * Modified progress.c\n| \n`----\n\n10. I then saw only one message output:\n\n,----\n| Added progress.c\n`----\n\nI should see two messages here, one for git.c and another for\nprogress.c. This is the reason for the addition of the append function\ncalls to copy the files list before sort sees it, as that is how they\nare reported. But that is not the whole story, as I show below.\n\n11. Looking at the *git-status* buffer, I do not see any status change\n for the files I have just added:\n\n,----\n| Directory: ~/git_from_source/git/\n| Branch: bg/scratch-elisp-testing\n| Head: f6b98e46bd - git-web--browse: Fix check for /bin/start\n| \n| Unknown Documentation/share/\n| Modified contrib/emacs/git.el\n| * Modified git.c\n| Unknown patch\n| * Modified progress.c\n| \n`----\n\nThat seems confusing (but see my response to your comment below about\nthe three conceptual states that git has that the other SCM's I've\nused (CVS, Perforce) don't seem to have).\n\n12. I ran git status outside of Emacs and saw that the files were\nindeed added:\n\n,----\n| # On branch bg/scratch-elisp-testing\n| # Changes to be committed:\n| # (use \"git reset HEAD ...\" to unstage)\n| #\n| #\tmodified: git.c\n| #\tmodified: progress.c\n| #\n| # Changed but not updated:\n| # (use \"git add ...\" to update what will be committed)\n| # (use \"git checkout -- ...\" to discard changes in working directory)\n| #\n| #\tmodified: contrib/emacs/git.el\n| #\n| # Untracked files:\n| # (use \"git add ...\" to include in what will be committed)\n| #\n| #\tDocumentation/share/\n| #\tpatch\n`----\n\nMy rationale for adding append function calls to the sort calls is to\nleave the callers value alone since the caller needs to make use of\nthe list value in subsequent operations, especially for issuing\nmessages.\n\n > \n > > Also, git-add-file needed to pass 'modified to git-marked-files-state,\n > > as otherwise, files that are modified but not yet in the index would\n > > not show up in the git-marked-files-state return value, which would\n > > then cause a prompt for file to show up when the files are clearly\n > > marked in the status buffer.\n > \n > Not sure what you mean here, it should not be possible for a file to be\n > in modified state but not in the index.\n\nYep. Shouldn't be but I think I have demonstrated that was the case\nabove. Let me know what I missed in my reasoning.\n\n > If you mean using git-add-file to do an update-index on an already\n > tracked file, that's not what it's meant to do.\n\nThat would be fine in, say, Perforce where once a file is added it\nstays added even if the user mades additional edits. I don't agree\nthat is the best approach in the case the Emacs interface to git in\ngit.el, since there is that \"third\" state where I could have added the\nfile, then edited it, then forgot that I had edited it and proceeded\nnaively to commit, only to be surprised later that the subsequent edit\nto the file was not committed. \n\nIn my view, there are three conceptual states that a file in git can\nhave:\n\n - The file is modified in the working tree but not yet added to the\n index (Locally-modified in my sample view below),\n\n - The file is modified, but also added to the index for the next\n commit and does not have any subsequent edits in the working tree\n (Ready-for-commit in my sample view below),\n\n - The file is added to the index previously, but the user made\n additional changes to the file that are not yet in the index, which\n means it potentially needs another add (Modified-but-has-edits in\n my sample view below).\n\nI need have the *git-status* buffer to visually reflect those three\nconceptual states. Otherwise there isn't much point to having M-x\ngit-status when I have to constantly run \"git status\" from the shell\nto double-check what the *git-status* buffer should have been telling\nme all along.\n\n,----\n| Directory: ~/git_from_source/git/\n| Branch: bg/scratch-elisp-testing\n| Head: f6b98e46bd - git-web--browse: Fix check for /bin/start\n| \n| Unknown Documentation/share/\n| Locally-modified contrib/emacs/git.el\n| * Modified-but-has-edits git.c\n| Unknown patch\n| * Ready-for-commit progress.c\n| \n`----\n\nI'm not insisting that the names \"Locally-modified\",\n\"Modified-but-has-edits\", and \"Ready-for-commit\" be the ones actually\nused (perhaps you can come up with names that better befit the git\nenvironment), but something like the above would be better than just\nhaving them all show up as \"modified\" for all three states.\n\nThanks,\nBrent\n"},{"id":"104789","messageId":"87ocx3hbkq.fsf@wine.dyndns.org","threadId":"17717","inReplyTo":"18836.22386.987021.484807@hungover.brentg.com","subject":"Re: [PATCH] Fix file mark handling and sort side-effects in git.el","fromName":"Alexandre Julliard","fromEmail":"julliard@winehq.org","sentAt":"2009-02-15T17:08:53Z","receivedAt":"2009-02-15T17:08:53Z","isPatch":true,"sender":{"key":"julliard@winehq.org","avatar":null},"body":"Brent Goodrick writes:\n\n> My rationale for adding append function calls to the sort calls is to\n> leave the callers value alone since the caller needs to make use of\n> the list value in subsequent operations, especially for issuing\n> messages.\n\nMy point is that the callers that need it should take care of it\nthemselves, instead of forcing a copy even in cases where it's not\nnecessary. And the copy can most likely be avoided completely by\nchanging how the success message is printed.\n\n> > If you mean using git-add-file to do an update-index on an already\n> > tracked file, that's not what it's meant to do.\n>\n> That would be fine in, say, Perforce where once a file is added it\n> stays added even if the user mades additional edits. I don't agree\n> that is the best approach in the case the Emacs interface to git in\n> git.el, since there is that \"third\" state where I could have added the\n> file, then edited it, then forgot that I had edited it and proceeded\n> naively to commit, only to be surprised later that the subsequent edit\n> to the file was not committed. \n\nThe design of git.el is that the index is not exposed directly, it's\ntreated as an implementation detail. So \"add\" in git.el is only for\nadding an untracked file, it's not for updating the index contents of an\nalready tracked file; that's an unnecessary operation since git.el uses\nthe file marks to determine what gets committed.\n\nIt does get a bit confusing if you constantly mix command-line and\ngit.el commands, but you are not supposed to do that, you should be able\nto do everything from the git.el buffer. I'm sure hiding the index\noffends the git purists, but IMHO it makes things more Emacs-ish and\neasier to use, especially if you are used to things like dired or\npcl-cvs or vc-dir with other VC systems.\n\n-- \nAlexandre Julliard\njulliard@winehq.org\n"},{"id":"104795","messageId":"e38bce640902151035s18e374e6j25e3887728722700@mail.gmail.com","threadId":"17717","inReplyTo":"87ocx3hbkq.fsf@wine.dyndns.org","subject":"Re: [PATCH] Fix file mark handling and sort side-effects in git.el","fromName":"Brent Goodrick","fromEmail":"bgoodr@gmail.com","sentAt":"2009-02-15T18:35:38Z","receivedAt":"2009-02-15T18:35:38Z","isPatch":true,"sender":{"key":"bgoodr@gmail.com","avatar":"https://gravatar.com/avatar/2399bf5a3468b3516a892183edfd43a7fa0300a2e9d5072189020186961150bc?d=mp&s=160"},"body":"On Sun, Feb 15, 2009 at 9:08 AM, Alexandre Julliard wrote:\n>\n> Brent Goodrick writes:\n>\n> > My rationale for adding append function calls to the sort calls is to\n> > leave the callers value alone since the caller needs to make use of\n> > the list value in subsequent operations, especially for issuing\n> > messages.\n>\n> My point is that the callers that need it should take care of it\n> themselves, instead of forcing a copy even in cases where it's not\n> necessary. And the copy can most likely be avoided completely by\n> changing how the success message is printed.\n>\n> > > If you mean using git-add-file to do an update-index on an already\n> > > tracked file, that's not what it's meant to do.\n> >\n> > That would be fine in, say, Perforce where once a file is added it\n> > stays added even if the user mades additional edits. I don't agree\n> > that is the best approach in the case the Emacs interface to git in\n> > git.el, since there is that \"third\" state where I could have added the\n> > file, then edited it, then forgot that I had edited it and proceeded\n> > naively to commit, only to be surprised later that the subsequent edit\n> > to the file was not committed.\n>\n> The design of git.el is that the index is not exposed directly, it's\n> treated as an implementation detail. So \"add\" in git.el is only for\n> adding an untracked file, it's not for updating the index contents of an\n> already tracked file; that's an unnecessary operation since git.el uses\n> the file marks to determine what gets committed.\n\nOk, now that makes sense to me. Part of the problem here is that there\nis no statement in the user manual about git.el's intent to hide the\nindex. Perhaps something to the effect of \"If you are new to using\nEmacs but not new to git, then you need to know that bla bla ...\".\nOtherwise, I think users may get tripped up by this as I was. Was\nthere a manual in the works for git.el or did I just miss it in recent\ncheckins?\n\n>\n> It does get a bit confusing if you constantly mix command-line and\n> git.el commands, but you are not supposed to do that, you should be able\n> to do everything from the git.el buffer. I'm sure hiding the index\n> offends the git purists, but IMHO it makes things more Emacs-ish and\n> easier to use, especially if you are used to things like dired or\n> pcl-cvs or vc-dir with other VC systems.\n\nThat makes sense to me from the Emacs standpoint.\n\nHowever, there is still a minor bug: If you edit two new files (not\nknown to git), then run M-x git-status, those two new files will show\nup as Unknown as expected. But, mark both of them, and type \"a\" will\nshow a message in the minibuffer for only one of the files. If you\nthen look in the *Messages* buffer, you will find that a message for\nonly one of the files.\n\nHowever, the *git-status* buffer does properly reflect the two added\nfiles by their state being changed to \"Added\". Since you may have a\nton of files that are being added, it probably doesn't make a whole\nlot of sense to dump a long message into the minibuffer with all of\nthose names. By the same token, it doesn't make sense to emit one\nmessage per file either. Instead, would you be willing to change that\nmessage to just state \"Added n files\" where \"n\" is the number of files\nadded? I would provide a patch, but that patch would necessitate the\nfix to the \"files\" variable being damaged by the sort function, since\nthe git.el code seems to not even to take that into account (and is\nthe root cause of why only one message is emitted AFAIK). The other\nalternative is to take the length of the files list before calling the\nlist-damaging functions, but that just seems so not in the spirit of\ncurrent Elisp coding practice.\n\nThanks,\nbg\n"},{"id":"104800","messageId":"87k57rh5qe.fsf@wine.dyndns.org","threadId":"17717","inReplyTo":"e38bce640902151035s18e374e6j25e3887728722700@mail.gmail.com","subject":"Re: [PATCH] Fix file mark handling and sort side-effects in git.el","fromName":"Alexandre Julliard","fromEmail":"julliard@winehq.org","sentAt":"2009-02-15T19:15:05Z","receivedAt":"2009-02-15T19:15:05Z","isPatch":true,"sender":{"key":"julliard@winehq.org","avatar":null},"body":"Brent Goodrick writes:\n\n> Ok, now that makes sense to me. Part of the problem here is that there\n> is no statement in the user manual about git.el's intent to hide the\n> index. Perhaps something to the effect of \"If you are new to using\n> Emacs but not new to git, then you need to know that bla bla ...\".\n> Otherwise, I think users may get tripped up by this as I was. Was\n> there a manual in the works for git.el or did I just miss it in recent\n> checkins?\n\nThere's no manual, and I'm not going to write one, I suck at writing\ndocumentation. If you would like to contribute one it would certainly be\nwelcome.\n\n> However, the *git-status* buffer does properly reflect the two added\n> files by their state being changed to \"Added\". Since you may have a\n> ton of files that are being added, it probably doesn't make a whole\n> lot of sense to dump a long message into the minibuffer with all of\n> those names. By the same token, it doesn't make sense to emit one\n> message per file either. Instead, would you be willing to change that\n> message to just state \"Added n files\" where \"n\" is the number of files\n> added?\n\nThat's exactly what git-success-message already does. The only problem\nis that the list isn't always preserved properly (and that's only a\ncosmetic bug, the operations get carried out correctly).\n\n-- \nAlexandre Julliard\njulliard@winehq.org\n"},{"id":"104865","messageId":"e38bce640902151604k6bc24ad1gd0986df9abf52f02@mail.gmail.com","threadId":"17717","inReplyTo":"87k57rh5qe.fsf@wine.dyndns.org","subject":"Re: [PATCH] Fix file mark handling and sort side-effects in git.el","fromName":"Brent Goodrick","fromEmail":"bgoodr@gmail.com","sentAt":"2009-02-16T00:04:09Z","receivedAt":"2009-02-16T00:04:09Z","isPatch":true,"sender":{"key":"bgoodr@gmail.com","avatar":"https://gravatar.com/avatar/2399bf5a3468b3516a892183edfd43a7fa0300a2e9d5072189020186961150bc?d=mp&s=160"},"body":"> There's no manual, and I'm not going to write one, I suck at writing\n> documentation. If you would like to contribute one it would certainly be\n> welcome.\n\nIt's apparent that you are quite articulate in your emails, so I don't\nbuy the argument that you suck at writing documentation. ;)\n\nActually, there isn't enough functionality in git.el to write up in a\nmanual yet. Once there is, then perhaps having a manual might make\nsense.\n\nLet's just leave it as adding additional commentary at the top of\ngit.el that warns future users of the intent behind the user interface\nso that you don't have to keep answering this question later on. To\nthat end, here is a patch of my attempt at adding an explanatory\ncomment at the top of git.el (in lieu of a full-blown manual):\n\ndiff --git a/contrib/emacs/git.el b/contrib/emacs/git.el\nindex fcbe2d9..b383f51 100644\n--- a/contrib/emacs/git.el\n+++ b/contrib/emacs/git.el\n@@ -23,8 +23,33 @@\n\n ;; This file contains an interface for the git version control\n ;; system. It provides easy access to the most frequently used git\n-;; commands. The user interface is as far as possible identical to\n-;; that of the PCL-CVS mode.\n+;; commands. The user interface intensionally hides some of the full\n+;; interface provided by the git command. This was done in order to\n+;; keep the user interface similar to other Emacs SCM interface\n+;; modes, such as the PCL-CVS mode. For example, it is possible using\n+;; git directly from the command-line to do partial checkins such as:\n+;;\n+;; - Make a first edit to an git-controlled file\n+;;\n+;; - Add the file to the git index with the \"git add\" command.\n+;;\n+;; - Make a second edit to that same file\n+;;\n+;; - Checkin the change using the \"git commit\" command, which\n+;; results in the first edit being committed, but not the second.\n+;;\n+;; The Emacs Git interface as provided by the git-status command\n+;; herein simplifies the checkin sequence by hiding the git index\n+;; from the user. Instead, the buffer git-status shows will only show\n+;; that the file has been modified, even if some of the modifications\n+;; are not yet added to the git index. Only files not yet known to\n+;; git have to be added using the \"a\" keybinding one time (i.e., you\n+;; don't have to remember to re-add the second change as required by\n+;; git in the example above). To commit, you mark multiple files in\n+;; the git-status buffer using the \"m\" keybinding, and then commit\n+;; those files with the \"c\" binding. Then git-status will insure that\n+;; all edits made to those marked files are silently added to the git index\n+;; before git commit is executed.\n ;;\n ;; To install: put this file on the load-path and place the following\n ;; in your .emacs file:\n\n\n>\n>> However, the *git-status* buffer does properly reflect the two added\n>> files by their state being changed to \"Added\". Since you may have a\n>> ton of files that are being added, it probably doesn't make a whole\n>> lot of sense to dump a long message into the minibuffer with all of\n>> those names. By the same token, it doesn't make sense to emit one\n>> message per file either. Instead, would you be willing to change that\n>> message to just state \"Added n files\" where \"n\" is the number of files\n>> added?\n>\n> That's exactly what git-success-message already does. The only problem\n> is that the list isn't always preserved properly (and that's only a\n> cosmetic bug, the operations get carried out correctly).\n\nAgreed. Thanks for your help!\n\nbg\n"}]}