[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: git history tracking across renames (and emacs support)

From: Eli Zaretskii
Subject: Re: git history tracking across renames (and emacs support)
Date: Thu, 12 Jul 2018 20:37:46 +0300

> From: Radon Rosborough <address@hidden>
> Date: Thu, 12 Jul 2018 11:03:09 -0600
> Cc: Ted Zlatanov <address@hidden>, Lars Ingebrigtsen <address@hidden>, 
> emacs-devel <address@hidden>
> > But if you have suggestions for clarifying CONTRIBUTE, please tell.
> I think that CONTRIBUTE needs to give a step-by-step guide for how to
> generate a commit message with Magit, since Magit is certainly either
> the most popular or second most popular version-control frontend for
> Emacs.

Is it really an issue with magit?  And if it is, why isn't it
documented in magit's documentation?

> It should probably also provide a step-by-step guide for doing this
> with VC.

It is: in the Emacs manual.

> As soon as I am linked to documentation about editing
> ChangeLog files, I will assume I've gone astray, unless it's explained
> why editing ChangeLog files is necessary in order to generate a commit
> message.

I don't understand why.  How about providing detailed critique of what
CONTRIBUTE says under "Generating ChangeLog entries"?

> > I guess it depends on the projects. I contribute to several other
> > projects, like GDB, Gawk, and Texinfo
> Well, those are all GNU projects. So I think that's the difference. It
> seems to me that ChangeLog is a "GNU thing". As are mailing lists,
> avoidance of GitLab, using debbugs, etc.

Well, we are talking about Emacs, and Emacs will always be a GNU

> > Like I said: free text log messages leave a lot of space for
> > disagreement about what is and what isn't a good message.
> This is true, but it seems to me that we already have this problem.

Not IME, no.

> After all, the current format doesn't say anything about how to
> actually describe your change. It just tells you how to replicate the
> diff in your commit message.

Nevertheless, log messages provided by contributors are pretty close
to what I'd like to see, after a couple of initial submissions, where
we generally need to point out some minor nits.

> By dropping the format, we would only be losing the replicated diff
> information; we wouldn't be losing any directions on how to
> communicate useful information that *can't* be auto-generated,
> because there are no such instructions now.

I guess you never had to deal with contributors who ask "where's that
written" right away when you make some comment about their submission.
That's how CONTRIBUTE was born in the first place.

> > IME, new contributors want clear and concise instructions; telling
> > them to read a long blog will definitely turn off many of them.
> I think the blog does a much better job of getting across its
> information clearly, concisely, and understandably:

It's too long, IMO.

> Plus, everybody knows this already, since virtually every open-source
> project follows more or less these guidelines for commit messages.

If so, why would someone need to write a blog, and why would we need
to point to it?  Evidently not everybody knows that.

> I only wish to push for an agreement that "if somebody were willing to
> do the work to remove the ChangeLog format, then the patch would be
> accepted". Otherwise, who is going to write a patch?

I cannot answer that because I don't think I understand what is being
proposed here.  If the proposal is to let people write what they want,
then I don't think I'd agree, for reasons I tried to explain.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]