Git commit methodology

Git commit methodology

[Lars Magne Ingebrigtsen]

I haven't been paying all that much attention to how people are supposed
to commit stuff to Gnus and/or Emacs after the changeover to git/bzr.
Are we still supposed to update the ChangeLog?  Are lots of small
commits OK, or should it be in larger chunks?  Should I push often, or
less often?  Or what?

Let me know whether I'm doing something wrong...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Git commit methodology

[Ted Zlatanov]

On Sun, 29 Aug 2010 16:41:01 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> I haven't been paying all that much attention to how people are supposed
LMI> to commit stuff to Gnus and/or Emacs after the changeover to git/bzr.
LMI> Are we still supposed to update the ChangeLog?  Are lots of small
LMI> commits OK, or should it be in larger chunks?  Should I push often, or
LMI> less often?  Or what?

LMI> Let me know whether I'm doing something wrong...

Do your work in logical chunks, like with CVS.  When ready, do a commit
(or ammend as needed).  Do a push when you need to, there's no problem
with pushing once or several times, but it's more of a pain to revert.

The ChangeLog format is the same.  The *commit message* should be

--cut--
short-description-of-change

normal-commit-message
--cut--

which produces nice one-line summaries in the condensed git log (and
Bazaar).

The sync with Emacs is done by Yamaoka-san.  I don't know how often.
It's not hard to set up apparently; he posted some explanations.  I had
planned to set up a smart sync process with add/delete/move support but
it hasn't been necessary so far.

Ted

Re: Git commit methodology

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> The ChangeLog format is the same.  The *commit message* should be
>
> --cut--
> short-description-of-change
>
> normal-commit-message
> --cut--
>
> which produces nice one-line summaries in the condensed git log (and
> Bazaar).

Ah, right.  Has anybody done any ChangeLog/vc log integration?  I mean,
if I'm checking in a change set that includes the ChangeLog, then it
would make sense to default the text to text extracted from the
ChangeLog.

That is, if the ChangeLog text about to be checked in is:

-------
2010-08-29  Lars Magne Ingebrigtsen  <larsi@gnus.org>

	* gnus-start.el (gnus-dribble-read-file): Ensure that the directory
	where the dribbel file lives exists.
-------

then the vc log buffer could be populated with:

-------
Ensure that the directory where the dribble file lives exists.
-------

(Note how the code also fixed up the typo automatically.  :-)


-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Git commit methodology

[Ted Zlatanov]

On Mon, 30 Aug 2010 15:38:33 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> The ChangeLog format is the same.  The *commit message* should be
>> 
>> --cut--
>> short-description-of-change
>> 
>> normal-commit-message
>> --cut--
>> 
>> which produces nice one-line summaries in the condensed git log (and
>> Bazaar).

LMI> Ah, right.  Has anybody done any ChangeLog/vc log integration?  I mean,
LMI> if I'm checking in a change set that includes the ChangeLog, then it
LMI> would make sense to default the text to text extracted from the
LMI> ChangeLog.

LMI> That is, if the ChangeLog text about to be checked in is:

LMI> -------
LMI> 2010-08-29  Lars Magne Ingebrigtsen  <larsi@gnus.org>

LMI> 	* gnus-start.el (gnus-dribble-read-file): Ensure that the directory
LMI> 	where the dribbel file lives exists.
LMI> -------

LMI> then the vc log buffer could be populated with:

LMI> -------
LMI> Ensure that the directory where the dribble file lives exists.
LMI> -------

This works for a one-sentence commit, but generally it doesn't.  The
summary should be very succinct and ChangeLog messages tend to be
explicit and long.  I think it's better to type the summary manually,
unless the one-sentence match works.  I don't think anyone has done work
on this but it does sound useful.

LMI> (Note how the code also fixed up the typo automatically.  :-)

I'd rather see it introduce typos automatically.  Then no one will ever
know you screwed up :)

Ted

Re: Git commit methodology

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I don't think anyone has done work on this but it does sound useful.

Actually, `C-c C-a' in the vc log buffer does some of this.  It pulls in
the ChangeLog texts, but it doesn't really massage them into git/bzr
format. 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Git commit methodology

[Lars Magne Ingebrigtsen]

This is really annoying.  Every time I'm checking stuff inn with vc-dir,
I get a buffer like this:

----------
VC backend : Git
Working dir: ~/pgnus/lisp/
Branch     : master
Remote     : https://git.gnus.org/gnus.git
Stash      : Nothing stashed

                         ./
     edited              ChangeLog
     ignored             TAGS
     edited              mml.el
----------

And I can't just tap `v' on the ./ line, because of the ignored file.
If I kill the buffer and restart vc-dir, the TAGS file disappears, but
after every checkin, it reappears.

How do I make it go away forever and ever and ever?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Git commit methodology

[Leo]

On 2010-08-30 18:03 +0100, Lars Magne Ingebrigtsen wrote:
> How do I make it go away forever and ever and ever?

There is another interface to git: http://philjackson.github.com/magit/,
which is used by everyone using git and emacs.

Leo

Re: Git commit methodology

[Lars Magne Ingebrigtsen]

Leo <sdl.web@gmail.com> writes:

> There is another interface to git: http://philjackson.github.com/magit/,
> which is used by everyone using git and emacs.

Heh.

Well, I'd prefer using vc-mode, since I interface to other SCMs, too,
and I want to use the same mode for everything...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Git commit methodology

[Leo]

On 2010-08-30 18:12 +0100, Lars Magne Ingebrigtsen wrote:
> Well, I'd prefer using vc-mode, since I interface to other SCMs, too,
> and I want to use the same mode for everything...

I forgot there are other SCMs than git ;)

Leo

-- 
Any Emacs contains an ad hoc, informally-specified, bug-ridden, slow
implementation of half of Common Lisp.

Re: Git commit methodology

[Lars Magne Ingebrigtsen]

I don't understand what's so special about lisp/TAGS.  It's in
.gitignore with all the rest of the ignorable stuff, but it's the only
thing that vc-mode shows as ignored.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Git commit methodology

[Leo]

On 2010-08-30 18:22 +0100, Lars Magne Ingebrigtsen wrote:
> I don't understand what's so special about lisp/TAGS. It's in
> .gitignore with all the rest of the ignorable stuff, but it's the only
> thing that vc-mode shows as ignored.

I just tried it in my emacs-23 and it has the same problem as yours.
Maybe it is a bug? I was hoping typing x should hide them but no.

Leo

Re: Git commit methodology

[Lars Magne Ingebrigtsen]

Leo <sdl.web@gmail.com> writes:

> I just tried it in my emacs-23 and it has the same problem as yours.
> Maybe it is a bug? I was hoping typing x should hide them but no.

Perhaps it's something special about the TAGS file?  It got so annoying
that I just deleted it.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Git commit methodology

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> Well, I'd prefer using vc-mode, since I interface to other SCMs, too,
> and I want to use the same mode for everything...

Well for both CVS and SVN I've used a different mode for the entire
workspace (to do updates and merges and checkins), and vc-mode to edit
individual files, and look at logs and annotate and diff and stuff.

For CVS it was something called `M-x cvs-examine RET' (I think... it's
been a while).  For svn it's `M-x svn-status RET'.

This vc-dir you were talking about it's a new one to me.

Re: Git commit methodology

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Perhaps it's something special about the TAGS file?  It got so annoying
> that I just deleted it.

AAARGH!!!!

Now the buffer is:

----------
                         ./
     up-to-date          ChangeLog
     unregistered        TAGS
     up-to-date          gnus-art.el
     unregistered        gnus-load.el
----------

TAGS came back even though it doesn't exist!  And now gnus-load.el is
there, too!!!

!!1!

!

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Git commit methodology

[Ted Zlatanov]

On Mon, 30 Aug 2010 18:16:24 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> I don't think anyone has done work on this but it does sound useful.

LMI> Actually, `C-c C-a' in the vc log buffer does some of this.  It pulls in
LMI> the ChangeLog texts, but it doesn't really massage them into git/bzr
LMI> format. 

It's really "Gnus commit" format.  It's sort of becoming standard (Emacs
has a similar format) but there's no requirement to use it in Gnus
commits, just my gentle nudges.  So I don't know if it needs to be
codified.  Do you have a preference?  Looking at `git log --oneline' do
you see a better way?

Ted

Re: Git commit methodology

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> It's really "Gnus commit" format.  It's sort of becoming standard (Emacs
> has a similar format) but there's no requirement to use it in Gnus
> commits, just my gentle nudges.  So I don't know if it needs to be
> codified.  Do you have a preference?  Looking at `git log --oneline' do
> you see a better way?

I think the format you describe makes a lot of sense.  So it'd be nice
if `C-c C-a' codified it.

And `C-c C-a' pulls in changes to files that aren't going to be
committed, so it's kinda not optimal.  It should be fixed.  By
somebody.  :-)

I mean, when I'm doing development, the commits just kinda spurt out.
Having to spend a second more than necessary on the vc formalities is a
downer, so Emacs should just get this right...

I'll probably take a whack at hacking `C-c C-a' to DWIM.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Git commit methodology

[Ted Zlatanov]

On Tue, 31 Aug 2010 20:51:37 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> It's really "Gnus commit" format.  It's sort of becoming standard (Emacs
>> has a similar format) but there's no requirement to use it in Gnus
>> commits, just my gentle nudges.  So I don't know if it needs to be
>> codified.  Do you have a preference?  Looking at `git log --oneline' do
>> you see a better way?

LMI> I think the format you describe makes a lot of sense.  So it'd be nice
LMI> if `C-c C-a' codified it.

But that's an Emacs-wide shortcut.  I think we need a "Gnus C-c C-a"
function.  It can take advantage of Git in particular, using 
"git log" to generate a nice summary, which is not as easy with the
general VC+ChangeLog interface.

LMI> And `C-c C-a' pulls in changes to files that aren't going to be
LMI> committed, so it's kinda not optimal.  It should be fixed.  By
LMI> somebody.  :-)

Ditto as above: use Git directly.

LMI> I'll probably take a whack at hacking `C-c C-a' to DWIM.

OK.  You may also want to look at providing a Git-specialized `C-x 4 a'
ChangeLog appender for Gnus, since you're in that area...

Ted

Re: Git commit methodology

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> But that's an Emacs-wide shortcut.  I think we need a "Gnus C-c C-a"
> function.  It can take advantage of Git in particular, using 
> "git log" to generate a nice summary, which is not as easy with the
> general VC+ChangeLog interface.

I don't quite follow you.  Doesn't "git log" just show the git commit
messages? 

> OK.  You may also want to look at providing a Git-specialized `C-x 4 a'
> ChangeLog appender for Gnus, since you're in that area...

Since we have to update the ChangeLog files, I think it might make most
sense to work in the opposite direction.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Git commit methodology

[Ted Zlatanov]

On Wed, 01 Sep 2010 16:42:39 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> But that's an Emacs-wide shortcut.  I think we need a "Gnus C-c C-a"
>> function.  It can take advantage of Git in particular, using 
>> "git log" to generate a nice summary, which is not as easy with the
>> general VC+ChangeLog interface.

LMI> I don't quite follow you.  Doesn't "git log" just show the git commit
LMI> messages? 

Sorry, I meant "git diff" and parsing the raw format to do a summary
when possible.  But that's probably too much work for the benefit.

Ted