Mailing List Archive: Wikipedia: Wikitech

Commits IDs, change IDs, legacy change IDs, oh my!

Index | Next | Previous | View Threaded

erik at wikimedia

Apr 24, 2012, 12:00 PM

Post #1 of 8 (139 views)
Permalink

Commits IDs, change IDs, legacy change IDs, oh my!

Hi all,

can we agree on how we want to identify changes

- when deploying code
- when merging follow-ups
- when commenting on bugzilla?

Take a look at http://wikitech.wikimedia.org/view/Server_admin_log to
see an example of a mix between Gerrit legacy change IDs (integers, as
URLs) and commit IDs. For commit messages the recommendation is to use
change IDs (as hashes). So this means constant back and forth between
different ID types, which is confusing to developers and users.

I'm personally not a fan of the Gerrit change-IDs in plain form,
because I can't use them with commands like 'git log' or 'git show'
without grepping through commit messages. They tie us pretty heavily
to Gerrit as the gateway to all info as opposed to using Git's native
lookup capabilities.

One proposal:
- Gerrit URLs for links on Bugzilla, links on wikis, follow-up to
un-merged commits
- Commit SHA-1s for deployment log entries and follow-ups to merged commits

Rationale:

- A Gerrit URL helps others skip past the fragile Gerrit search and go
right to the relevant change. This gives them access to change-ID,
SHA-1s, and anything else they may need. It's appropriate when you're
likely to need to go into the full context of a change.

- A SHA-1 gives you instant visibility to the code in your repo
without having to use Gerrit as an intermediary, or having to do slow
searches of your commit messages for a change-ID. Just do 'git show'.
Git intelligently parses abbreviated hashes as well. It's appropriate
when you're past the point of code review and are just referring to a
change that's sitting somewhere in the repo.

This is just one possible approach, and I'm sure this is something we
can argue about endlessly. I don't much care what pattern we adopt, as
long as it's reasonably consistent, especially for deployment log
entries and follow-ups.

Thanks,
Erik

--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

preilly at wikimedia

Apr 24, 2012, 12:22 PM

Post #2 of 8 (137 views)
Permalink

Re: Commits IDs, change IDs, legacy change IDs, oh my! [In reply to]

On Tue, Apr 24, 2012 at 12:00 PM, Erik Moeller <erik [at] wikimedia> wrote:
> Hi all,
>
> can we agree on how we want to identify changes
>
> - when deploying code
> - when merging follow-ups
> - when commenting on bugzilla?
>
> Take a look at http://wikitech.wikimedia.org/view/Server_admin_log to
> see an example of a mix between Gerrit legacy change IDs (integers, as
> URLs) and commit IDs. For commit messages the recommendation is to use
> change IDs (as hashes). So this means constant back and forth between
> different ID types, which is confusing to developers and users.
>
> I'm personally not a fan of the Gerrit change-IDs in plain form,
> because I can't use them with commands like 'git log' or 'git show'
> without grepping through commit messages.

Well, you can always do something like:
ssh -p 29418 gerrit.wikimedia.org gerrit query
change:I1744438cbee58f149e1105e7856d00343f04d55a
status:merged --patch-sets --format=TEXT limit:1 | grep 'revision:'

and get output like:
revision: 782ab823d7ab672ef5e849631a47cdf8eae49410

They tie us pretty heavily
> to Gerrit as the gateway to all info as opposed to using Git's native
> lookup capabilities.
>
> One proposal:
> - Gerrit URLs for links on Bugzilla, links on wikis, follow-up to
> un-merged commits
> - Commit SHA-1s for deployment log entries and follow-ups to merged commits
>
> Rationale:
>
> - A Gerrit URL helps others skip past the fragile Gerrit search and go
> right to the relevant change. This gives them access to change-ID,
> SHA-1s, and anything else they may need. It's appropriate when you're
> likely to need to go into the full context of a change.
>
> - A SHA-1 gives you instant visibility to the code in your repo
> without having to use Gerrit as an intermediary, or having to do slow
> searches of your commit messages for a change-ID. Just do 'git show'.
> Git intelligently parses abbreviated hashes as well. It's appropriate
> when you're past the point of code review and are just referring to a
> change that's sitting somewhere in the repo.
>
> This is just one possible approach, and I'm sure this is something we
> can argue about endlessly. I don't much care what pattern we adopt, as
> long as it's reasonably consistent, especially for deployment log
> entries and follow-ups.
>
> Thanks,
> Erik
>
> --
> Erik Möller
> VP of Engineering and Product Development, Wikimedia Foundation
>
> Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l [at] lists
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

greg at endpoint

Apr 25, 2012, 11:49 AM

Post #3 of 8 (130 views)
Permalink

Re: Commits IDs, change IDs, legacy change IDs, oh my! [In reply to]

Wikitech-l Digest, Vol 105, Issue 105
Reply-To:
In-Reply-To: <mailman.190579.1335293572.15574.wikitech-l [at] lists>
X-PGP-Key: http://www.gtsm.com/Greg_Sabino_Mullane.key.html

Erik Moeller asked:
> can we agree on how we want to identify changes
...
> One proposal:
> - Gerrit URLs for links on Bugzilla, links on wikis, follow-up to
> un-merged commits
> - Commit SHA-1s for deployment log entries and follow-ups to merged commits

+1. SHA-1 should be the rule, anything else should be the exception.

--
Greg Sabino Mullane greg [at] endpoint
End Point Corporation
PGP Key: 0x14964AC8

innocentkiller at gmail

Apr 25, 2012, 11:53 AM

Post #4 of 8 (126 views)
Permalink

Re: Commits IDs, change IDs, legacy change IDs, oh my! [In reply to]

On Tue, Apr 24, 2012 at 3:00 PM, Erik Moeller <erik [at] wikimedia> wrote:
> I'm personally not a fan of the Gerrit change-IDs in plain form,
> because I can't use them with commands like 'git log' or 'git show'
> without grepping through commit messages. They tie us pretty heavily
> to Gerrit as the gateway to all info as opposed to using Git's native
> lookup capabilities.
>

I personally like them, but your concerns are valid.

> One proposal:
> - Gerrit URLs for links on Bugzilla, links on wikis, follow-up to
> un-merged commits

Sounds fine. That's why we have the "gerrit 123" linking
in BZ.

> - Commit SHA-1s for deployment log entries and follow-ups to merged commits
>

We'd have to come up with an auto-linking regex for this.
Right now the I... hashes (gerrit change-ids) will auto-link
in the Gerrit UI.

-Chad

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

hashar+wmf at free

Apr 25, 2012, 1:50 PM

Post #5 of 8 (127 views)
Permalink

Re: Commits IDs, change IDs, legacy change IDs, oh my! [In reply to]

Le 24/04/12 21:00, Erik Moeller wrote:
> One proposal:
> - Gerrit URLs for links on Bugzilla, links on wikis, follow-up to
> un-merged commits
> - Commit SHA-1s for deployment log entries and follow-ups to merged commits

Hi,

That is more or less what I have empirically adopted. Gerrit change
number and commit sha1 are the most human friendly and most useful
in their context.

--
Antoine "hashar" Musso

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

krinklemail at gmail

Apr 25, 2012, 2:37 PM

Post #6 of 8 (129 views)
Permalink

Re: Commits IDs, change IDs, legacy change IDs, oh my! [In reply to]

Also note that there are 2 kinds of SHA-1 hashes, there is the Change-ID sha-1 hash of the merge request that is pushed to gerrit (afaik stays persisent after amending patches), and then there is the sha-1 hash of the commit itself into the repository.

Quick overview of my observations:

== Gerrit change numbers ==
- Specific to gerrit, requires gerrit to get/resolve them (might become problematic in long-term if we drop gerrit)
- Not usable in git cli
* One id per change set, not per patch/commit/amend
+ Easy to link in bugzilla ("gerrit( change) #")
+ Link to it can be copied from the address bar in Gerrit

Example links:
* https://gerrit.wikimedia.org/r/5852
* https://gerrit.wikimedia.org/r/#q,5852,n,z
* https://gerrit.wikimedia.org/r/#change,5852

== Gerrit Change-Id (SHA-1) ==
- Specific to gerrit, requires gerrit to get/resolve them (might become problematic in long-term if we drop gerrit)
- Not usable in git cli
* One id per change set, not per patch/commit/amend
+ Are included in the commit message
+ Link to it can be copied from the parsed commit message in Gerrit
+ Allows easy tracking of merges of the same change to a different branch, for example:
https://gerrit.wikimedia.org/r/#q,Icc924785cdb394adc723666bf9f6a67e9d6a4d0d,n,z
(same Change-Id sha1 for the merge from master to wmf/1.20wmf1, but different git commit sha-1)

Example link:
* https://gerrit.wikimedia.org/r/#q,I18752aa0fe21dd3c5bc5bd4a830faaa4c836f9cd,n,z

== Git commit sha-1 ==
* Specific to each commit, changes after each amend. But all are tracable to the change numbers
+ Not dependant on Gerrit, but gerrit can handle them fine with the #q search
+ Usable in git cli
+ Link to it can be copied from the patch set on the gerrit change page "Patch set # <hash>"

Example links:
* https://gerrit.wikimedia.org/r/#q,8d6b19d8c2ed041443b9433298aa08a187ad1d83,n,z
* https://gerrit.wikimedia.org/r/gitweb?p=mediawiki%2Fcore.git;a=commit;h=8d6b19d8c2ed041443b9433298aa08a187ad1d83

- Krinkle

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Platonides at gmail

Apr 26, 2012, 9:55 AM

Post #7 of 8 (124 views)
Permalink

Re: Commits IDs, change IDs, legacy change IDs, oh my! [In reply to]

On 25/04/12 23:37, Krinkle wrote:
> == Gerrit change numbers ==
> - Specific to gerrit, requires gerrit to get/resolve them (might become problematic in long-term if we drop gerrit)
> - Not usable in git cli
> * One id per change set, not per patch/commit/amend
> + Easy to link in bugzilla ("gerrit( change) #")
> + Link to it can be copied from the address bar in Gerrit
>
> Example links:
> * https://gerrit.wikimedia.org/r/5852
> * https://gerrit.wikimedia.org/r/#q,5852,n,z
> * https://gerrit.wikimedia.org/r/#change,5852

git config --add alias.showc '!git show changes/${1: -2}/$1/${2:-1} #'

Then git showc 5596 works as
git show 07326ad522ea520e7ab71c84d2ab520b63451656, showing the contents
of patchset 1 of https://gerrit.wikimedia.org/r/#change,5596

You need to fetch changes, though. That means a line
fetch = +refs/changes/*:refs/changes/*
in the [remote "origin"] section of your config.

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

dzahn at wikimedia

Apr 27, 2012, 12:31 PM

Post #8 of 8 (122 views)
Permalink

Re: Commits IDs, change IDs, legacy change IDs, oh my! [In reply to]

On Wed, Apr 25, 2012 at 4:30 AM, Erik Moeller <erik [at] wikimedia> wrote:
> Take a look at http://wikitech.wikimedia.org/view/Server_admin_log to
> see an example of a mix

wikitech has interwiki prefixes including:

bugs or (bugzilla) and RT so when logging to SAL from IRC you can
directly use something like [[RT:1234]] in your !log message.

I did not see a gerrit one though. I just added it.

mysql> insert into mw_interwiki (iw_prefix,iw_url) values
("gerrit","https://gerrit.wikimedia.org/r/#change,$1");

< mutante> !log test - added new gerrit interwiki prefix for
SAL/wikitech - [[gerrit:6002]]

and it creates working links in SAL

--
--
Daniel Zahn <dzahn [at] wikimedia>

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads