hive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergio Pena <sergio.p...@cloudera.com>
Subject Re: [Discuss] Patch submission and commit format
Date Mon, 13 Jul 2015 16:43:04 GMT
I like this idea of the commit format.

Maybe we could use some git hooks to enforce a commit to be in a specific
format and to have a contributor too.

I found this article about git hooks we can use on the server-side to
enforce this:
https://www.atlassian.com/git/tutorials/git-hooks
https://git-scm.com/book/en/v2/Customizing-Git-An-Example-Git-Enforced-Policy

- Sergio

On Fri, Jul 10, 2015 at 1:59 PM, Sergey Shelukhin <sergey@hortonworks.com>
wrote:

> The existing approach appears to be “HIVE-XXXXX : fix the bugs (John Doe,
> reviewed by John Smith)” or something like that in the commit message.
> I think the new approach is better… +1
> Can you create a detailed instruction?
> Is it enforceable in git?
>
> On 15/7/10, 11:08, "Ashutosh Chauhan" <hashutosh@apache.org> wrote:
>
> >There was a problem of attributing contributions correctly back when we
> >were using svn, now that we are on git, that problem can be addressed.
> >This
> >email is an effort to solicit feedback for it.
> >
> >Problem: In svn, there is only a committer field, so when committer was
> >committing someone else's patch there was no way in svn to record original
> >contributor. We used to workaround this by putting name of contributor in
> >commit message.
> >
> >Git offers a better solution for this, since it makes a distinction
> >between
> >committer and author of the patch. However, to do this git needs patch to
> >be formatted (with git format-patch) and committed (using git am) in
> >certain way. I myself is using following flags to generate and commit
> >patches for some time now:
> >
> >git format-patch --stdout -1 > HIVE-XXXXX.patch
> >git am --signoff HIVE-XXXXX.patch
> >
> >I propose we follow these conventions to generate and commit patches.
> >Thoughts?
> >
> >Ashutosh
> >
> >PS: Motivation for this came while lurking on linux kernel mailing list,
> >where I found Linux devs follow similar process.
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message