(H.24/08/20 8:03), Mark Adam wrote:
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.
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.
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.
$ 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 email@example.com.
To unsubscribe from this group, send email to
For more options, visit this group at