(H.24/08/20 8:03), Mark Adam wrote:
Yes, that's all decent, but I'm trying to create a habitual methodology
about the documentation of files so that it helps the community as standard
practice.  The perfect place is really on the git add command line.
I don't think it is. "git add" isn't there to add files to the repository; it is there to add content to the staging area. There is a fundamental difference. Firstly, you use it to add modifications to files which already exist, so there is no reason to suppose attaching a note to "git add" means that note belongs to the action, "user added a file". Secondly, git tracks content, not files, so I don't think you will have much luck pushing for special actions related to the addition/removal of files.

The correct approach is to put the note in the log for the commit which adds the file, and then pass parameters to log which will help you find those commits which add files. "git whatchanged" might be a good starting point. Alternatively you could look at the "--name-status" parameter to "git log", which is more or less what "git whatchanged" uses anyway, I think, but might allow you a bit more customisation. Look at the manpages for details.

If you want to get the message for just one file, rather than for all commits where files were added, you could easily write a git alias, say "git purpose", which takes a filename as a parameter, finds the commit in which it was added, and displays the log message for that commit. Something like

    $ git log --pretty=medium --reverse -1

would give you the first commit for a file, which is usually going to be the one in which it was added (unless you need to handle the case where a file is added, later removed, and a different file is then later added which has the same name -- in which case some cleverness with "git whatchanged" should be able to get you the most recent addition).

If you really wanted you could write your logs in a special format which your "git purpose" alias could then parse, so that only the portion of the commit log related to the purpose of that file got printed.

None of this will "help the community as standard practice", but I am not sure how much "the community" wants/needs that help. Maybe worth trying it yourself as proof-of-concept first before trying to push for it to be a mainstream feature. The great thing about git is that it's flexible enough that you *can* adjust it to suit your needs, so styling it to your own workflow is possible and encouraged!


You received this message because you are subscribed to the Google Groups "Git for 
human beings" group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to