Re: Make gitlab automatically add MR ID to commit message(s)?

[Werner LEMBERG]

> The method I use is to go to
> [https://gitlab.com/lilypond/lilypond/-/commits/master](https://gitlab.com/lilypond/lilypond/-/commits/master)
> and search for the commit's title line using the search box in the
> top right.  For example,

OK, thanks!


Werner

Re: Make gitlab automatically add MR ID to commit message(s)?

[Jean Abou Samra]

Le dimanche 19 mars 2023 à 12:07 +, Werner LEMBERG a écrit :
> ```
> 
> I think it would be beneficial if the original MR ID gets added to the
> commit message(s).  Is this possible?  In many cases there is some
> useful discussion that might help better understand code issues.
> 
> Ideally, the 'merge request' button would do that.

See 
[https://docs.gitlab.com/ee/user/project/merge_requests/commit_templates.html](https://docs.gitlab.com/ee/user/project/merge_requests/commit_templates.html).
 AFAICT, it's only possible when using merging or squash-merging, but not 
fast-forward merging aka rebasing.

The method I use is to go to 
[https://gitlab.com/lilypond/lilypond/-/commits/master](https://gitlab.com/lilypond/lilypond/-/commits/master)
 and search for the commit's title line using the search box in the top right. 
For example,

[https://gitlab.com/lilypond/lilypond/-/commits/master?search=convertrules.py%3A+Whitespace%2C+formatting%2C+minor+typos](https://gitlab.com/lilypond/lilypond/-/commits/master?search=convertrules.py%3A+Whitespace%2C+formatting%2C+minor+typos)

If you click on the commit, you get a link to the MR where it was merged.



signature.asc
Description: This is a digitally signed message part

Make gitlab automatically add MR ID to commit message(s)?

[Werner LEMBERG]

I think it would be beneficial if the original MR ID gets added to the
commit message(s).  Is this possible?  In many cases there is some
useful discussion that might help better understand code issues.

Ideally, the 'merge request' button would do that.


Werner

Re: [RFC] Commit message format

[David Kastrup]

Jonas Hahnfeld via Discussions on LilyPond development
 writes:

> For SHA1, I'd recommend using more than 6 chars to avoid collisions.
> The Linux kernel encourages 12 characters [1], but I think we are good
> with less. $ git log --oneline currently shows 10 chars for the
> LilyPond repo, that should be a safe bet.

It's probably a bit audacious to call the current minimum requirement of
characters a "safe bet" for all future.  That's why we just use full
SHA1 numbers in the issue tracker.  It's certainly overkill, but at
least it also kills the discussion of just where the overkill starts.

> 1:
> https://github.com/torvalds/linux/blob/master/Documentation/process/submitting-patches.rst#2-describe-your-changes
>

-- 
David Kastrup
My replies have a tendency to cause friction.  To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".

Re: [RFC] Commit message format

[Jonas Hahnfeld via Discussions on LilyPond development]

Am Freitag, den 07.02.2020, 12:37 -0500 schrieb Dan Eble:
> On Feb 7, 2020, at 10:39, Han-Wen Nienhuys <
> hanw...@gmail.com
> > wrote:
> > There are a couple of downsides to this format:
> > * The number takes up space in the
> >git log --format=short
> 
> upside: the number appears in git log —format=short
> 
> > * The number is meaningless without the site that hosts the tracker
> 
> exaggerated, but I see your point
> 
> >Link to code review
> >Link to issue
> > 
> > By embedding the links, we offer something clickable to whomever is
> > browsing the commit message.
> 
> -1, maybe.  Will the commit messages be rewritten when we migrate to a 
> different issue tracker or the provider decides to reorganize the URL paths?

No, please don't: It will change all commit ids, making up many dead
references.

> A stale link from which I must extract an ID would annoy me more than a bare 
> ID, I expect.
> 
> (I might have put links in a commit message or two, but please do as I say, 
> not as I do.)
> 
> Also, I've worked with issue trackers that scan commit messages for IDs in a 
> specific format (e.g. "#1234" or "[1234]") and turn them into hyperlinks from 
> the ticket to the related commits in a repository view.  It's probably best 
> to postpone dictating a citation format until we know the constraints of the 
> tools we move to (hoping we do).  We might even be able to configure patterns 
> for recognizing our older citations.

+1

From Han-Wen:
> Somewhat relatedly, I would like to propose to use SHA1s + subject
> lines to refer to previous changes, rather than issue numbers, eg.
> 
>04a0dc ("Disable Python's hash randomization")
> 
> this makes the reference impervious to problems with the issue tracker
> (network outage, renumbering due to server migrations, etc). Including
> the subject line makes it easier to intuitively understand what is going on.

+1, and I might have already started doing so in some places. If the
commit title is too long (see above), I think it's safe to drop the
"Issue " prefix.
For SHA1, I'd recommend using more than 6 chars to avoid collisions.
The Linux kernel encourages 12 characters [1], but I think we are good
with less. $ git log --oneline currently shows 10 chars for the
LilyPond repo, that should be a safe bet.

Jonas


1: 
https://github.com/torvalds/linux/blob/master/Documentation/process/submitting-patches.rst#2-describe-your-changes


signature.asc
Description: This is a digitally signed message part

Re: [RFC] Commit message format

[Janek Warchoł]

+1 to all parts of the proposal from me.

pt., 7 lut 2020 o 16:39 Han-Wen Nienhuys  napisał(a):

> Currently, on push most our commit messages look like:
>
> Issue XXX: Subject
>
> Body
> Body
>
>
> There are a couple of downsides to this format:
>
> * The number takes up space in the
>
> git log --format=short
>
>   output
>
> * The number is meaningless without the site that hosts the tracker
>
> Proposal
> ===
>
> I would like to propose a different format,
>
> Subject
>
> Body
> Body
>
> Link to code review
> Link to issue
>
> By embedding the links, we offer something clickable to whomever is
> browsing the commit message.
>
> Somewhat relatedly, I would like to propose to use SHA1s + subject
> lines to refer to previous changes, rather than issue numbers, eg.
>
>04a0dc ("Disable Python's hash randomization")
>
> this makes the reference impervious to problems with the issue tracker
> (network outage, renumbering due to server migrations, etc). Including
> the subject line makes it easier to intuitively understand what is going
> on.
>
> Finally, I want to encourage everyone to write Why something was
> changed rather What. One can deduce what changed by looking at the
> commit message.  It is much harder to fathom Why some change was
> necessary.
>
> --
> Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
>

Re: [RFC] Commit message format

[Dan Eble]

On Feb 7, 2020, at 10:39, Han-Wen Nienhuys  wrote:
> 
> There are a couple of downsides to this format:
> * The number takes up space in the
>git log --format=short

upside: the number appears in git log —format=short

> * The number is meaningless without the site that hosts the tracker

exaggerated, but I see your point

>Link to code review
>Link to issue
> 
> By embedding the links, we offer something clickable to whomever is
> browsing the commit message.

-1, maybe.  Will the commit messages be rewritten when we migrate to a 
different issue tracker or the provider decides to reorganize the URL paths?  A 
stale link from which I must extract an ID would annoy me more than a bare ID, 
I expect.

(I might have put links in a commit message or two, but please do as I say, not 
as I do.)

Also, I've worked with issue trackers that scan commit messages for IDs in a 
specific format (e.g. "#1234" or "[1234]") and turn them into hyperlinks from 
the ticket to the related commits in a repository view.  It's probably best to 
postpone dictating a citation format until we know the constraints of the tools 
we move to (hoping we do).  We might even be able to configure patterns for 
recognizing our older citations.

> Finally, I want to encourage everyone to write Why something was
> changed rather What. One can deduce what changed by looking at the
> commit message.  It is much harder to fathom Why some change was
> necessary.

+1.  This is good practice for code comments too.  I probably appreciate "why 
it was not done the obvious way" the most.
— 
Dan

[RFC] Commit message format

[Han-Wen Nienhuys]

Currently, on push most our commit messages look like:

Issue XXX: Subject

Body
Body


There are a couple of downsides to this format:

* The number takes up space in the

git log --format=short

  output

* The number is meaningless without the site that hosts the tracker

Proposal
===

I would like to propose a different format,

Subject

Body
Body

Link to code review
Link to issue

By embedding the links, we offer something clickable to whomever is
browsing the commit message.

Somewhat relatedly, I would like to propose to use SHA1s + subject
lines to refer to previous changes, rather than issue numbers, eg.

   04a0dc ("Disable Python's hash randomization")

this makes the reference impervious to problems with the issue tracker
(network outage, renumbering due to server migrations, etc). Including
the subject line makes it easier to intuitively understand what is going on.

Finally, I want to encourage everyone to write Why something was
changed rather What. One can deduce what changed by looking at the
commit message.  It is much harder to fathom Why some change was
necessary.

-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

Doc: CG: itemize section on commit message prefixes (issue 296810043 by paulwmor...@gmail.com)

[paulwmorris]

Reviewers: ,

Message:
Please review, thanks, -Paul

Description:
Doc: CG: itemize section on commit message prefixes

Please review this at https://codereview.appspot.com/296810043/

Affected files (+20, -8 lines):
  M Documentation/contributor/source-code.itexi


Index: Documentation/contributor/source-code.itexi
diff --git a/Documentation/contributor/source-code.itexi  
b/Documentation/contributor/source-code.itexi
index  
19b835a0ef959caac542cedae29d10b82cfa88cb..b961a82cf6c65897090fd5736731974ac19096b4  
100644

--- a/Documentation/contributor/source-code.itexi
+++ b/Documentation/contributor/source-code.itexi
@@ -1235,17 +1235,29 @@ high-res images, fixed cropping on Finale example.
 @end example

 Commit messages often start with a short prefix describing the
-general location of the changes.  If a commit affects the
+general location of the changes.
+
+@itemize
+@item
+Doc: and Doc-@var{**}:  If a commit affects the
 documentation in English (or in several languages simultaneously)
-the commit message should be prefixed with @qq{Doc:@tie{}}.  If
-the commit affects only one of the translations, the commit
+the commit message should be prefixed with @qq{Doc:@tie{}}.  If the
+commit affects only one of the translations, the commit
 message should be prefixed with @qq{Doc-@var{**}:@tie{}}, where
-@var{**} is the two-letter language code.  Commits that affect the
+@var{**} is the two-letter language code.
+
+@item
+Web: and Web-@var{**}:  Commits that affect the
 website should use @qq{Web:@tie{}} for English, and
-@qq{Web-@var{**}:@tie{}} for the other languages.  Also, changes
-to a single file are often prefixed with the name of the file
-involved.  Visit the links listed in @ref{Understanding commits}
-for examples.
+@qq{Web-@var{**}:@tie{}} for other languages.
+
+@item
+Changes to a single file are often prefixed with the name of the file
+involved.
+@end itemize
+
+Visit the links listed in @ref{Understanding commits} for examples.
+


 @node Patches



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Issue number in commit message (Fwd: [testlilyissues:issues] #4704 Improve beam count handling with subdivided beams)

[David Kastrup]

Urs Liska  writes:

> Hi all,
>
> I've just pushed my patch for #4704, having reworked the branch to five
> discrete commits (removing detours but separating work on different
> files/tasks).
>
> However, I somehow managed to mix up the issue number in several commit
> messages, so only one commit out of the list quoted below features the
> right number #4704 while the remaining ones are labeled as belonging to
> #4707.
>
> I'm sorry about the glitch, and I know that this doesn't make a problem
> - technically. However, it may cause confusion at a later point.
>
> What do you think, should this be "fixed" somehow?.
>
> Probably it's not an option to reset staging to c8a49d69 (current
> master) so I could edit the commit messages and push again?

I've reset staging to master: only your commits were in there and patchy
had not yet pushed them to master (even if some patchy instance is
already testing your changes, it will notice my intervention and refrain
from pushing anything to master that does no longer contain staging).

So you may use git rebase -i origin on your feature branch, reword the
commit messages, and push again to staging.

Remember fixing the issue report which now talks about commit ids that
never made it to master.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Issue number in commit message (Fwd: [testlilyissues:issues] #4704 Improve beam count handling with subdivided beams)

[Urs Liska]

Hi all,

I've just pushed my patch for #4704, having reworked the branch to five
discrete commits (removing detours but separating work on different
files/tasks).

However, I somehow managed to mix up the issue number in several commit
messages, so only one commit out of the list quoted below features the
right number #4704 while the remaining ones are labeled as belonging to
#4707.

I'm sorry about the glitch, and I know that this doesn't make a problem
- technically. However, it may cause confusion at a later point.

What do you think, should this be "fixed" somehow?.

Probably it's not an option to reset staging to c8a49d69 (current
master) so I could edit the commit messages and push again?

Urs


 Weitergeleitete Nachricht 
Betreff:[testlilyissues:issues] #4704 Improve beam count handling with
subdivided beams
Datum:  Mon, 28 Dec 2015 15:15:43 +
Von:Urs Liska 
Antwort an: [testlilyissues:issues]
<4...@issues.testlilyissues.p.re.sf.net>
An: [testlilyissues:issues] <4...@issues.testlilyissues.p.re.sf.net>



  * *labels*: --> Fixed_2_19_35
  * *status*: Started --> Fixed
  * *Comment*:

Pushed as

  * 73d4697d
  * b3a0b265
  * 9c09be17
  * 5c8f55f2
  * 5c8f55f2

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Issue number in commit message (Fwd: [testlilyissues:issues] #4704 Improve beam count handling with subdivided beams)

[Urs Liska]

Am 28.12.2015 um 16:33 schrieb David Kastrup:
> Urs Liska  writes:
>
>> Hi all,
>>
>> I've just pushed my patch for #4704, having reworked the branch to five
>> discrete commits (removing detours but separating work on different
>> files/tasks).
>>
>> However, I somehow managed to mix up the issue number in several commit
>> messages, so only one commit out of the list quoted below features the
>> right number #4704 while the remaining ones are labeled as belonging to
>> #4707.
>>
>> I'm sorry about the glitch, and I know that this doesn't make a problem
>> - technically. However, it may cause confusion at a later point.
>>
>> What do you think, should this be "fixed" somehow?.
>>
>> Probably it's not an option to reset staging to c8a49d69 (current
>> master) so I could edit the commit messages and push again?
> I've reset staging to master: only your commits were in there and patchy
> had not yet pushed them to master (even if some patchy instance is
> already testing your changes, it will notice my intervention and refrain
> from pushing anything to master that does no longer contain staging).

Thank you for doing that and sorry once more for the extra work.

>
> So you may use git rebase -i origin on your feature branch, reword the
> commit messages, and push again to staging.

I've done so now and pushed to staging again.

>
> Remember fixing the issue report which now talks about commit ids that
> never made it to master.

Thanks for the hint. I might have forgotten about this.

Urs
>


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Clarification for footnotes push commit message

[m...@apollinemike.com]

Hey all,
In the commit message about the footnote push, you'll see a line about TEST 
ONLY. What I mean here is that it is only 1/2 of the feature and thus should 
not yet be documented or considered complete (as discussed in previous emails). 
There is nothing test-ish about the implementation, however. It is the same one 
that's been going out to the list for a few days w all of the requested fixes.

Also, Graham has informed me that commit messages should start w a one-line 
description followed by something longer. I'll do this for future commits.

Cheers,
Mike



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

commit message

[Han-Wen Nienhuys]

Hi Erlend,


could you be a little more verbose in your messages?

**
Fix issue 558
**


-- 
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: commit message

[Erlend Aasland]

Shure, no problem. I'll try to remember to document my commits better  
from now on.


E

On 30. jan. 2008, at 01:12, Han-Wen Nienhuys wrote:


Hi Erlend,


could you be a little more verbose in your messages?

**
   Fix issue 558
**


--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen




___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel