On Tue, 19 Apr 2005, David Roundy wrote:
>
> Would a small amount of human-readable change information be acceptable in
> the free-form comment area? In the rename thread I got the impression this
> would be okay for renames. For example,
>
> rename foo bar
Sure. That's human-readable and meaningful, as in "it actually makes sense
as a commit comment regardless of any darcs issues". As does:
> replace [_a-zA-Z0-9] old_variable new_variable file/path
which is almost so (a human would have written "rename old to new", but
the above isn't _that_ different).
HOWEVER, then the requirement would be that we'd never have complex
combinations of the above. Ie having 2-5 lines of something like that is
"human-readable". Having 10+ lines of the above is not. See?
I have this suspicion that the "replace" thing often ends up being done on
dozens of files, and I don't want to have dozens of lines of stuff that
ends up really being machine-readable. But if it's ok to depend on the
content changes (you _do_ see which files changed) together with a single
line of "replace [token-def] xxx yyy", then hell yes - I consider that to
be useful information even outside of git.
(In other words: if it looks like something a careful human _could_ have
written, it's certainly ok. But if it looks like something a careful human
would have used a script to generate 40 entries of, it's bad).
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
