preilly at wikimedia
Apr 24, 2012, 12:22 PM
Post #2 of 8
On Tue, Apr 24, 2012 at 12:00 PM, Erik Moeller <erik [at] wikimedia> wrote:
Re: Commits IDs, change IDs, legacy change IDs, oh my!
[In reply to]
> 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
status:merged --patch-sets --format=TEXT limit:1 | grep 'revision:'
and get output like:
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
> - 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.
> 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
Wikitech-l mailing list
Wikitech-l [at] lists