You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Benoit Chesneau <bc...@gmail.com> on 2013/10/27 14:28:15 UTC
[PROPOSAL] tag our commits
Hi all,
I would like to propose that we start to tag our commits. The reasonning
behind that is to distinct easily the changes concerning the doc, the ui
and the core and filter them immediately and force us to make a change
atomic. So I would like to propose that we tag the commit line with
[DOC]
[UI]
[CORE]
other ? Another way to distinct the changes would also be to have all of
these as subprojects eventually but it may require too much changes.
Thoughts?
- benoit
Re: [PROPOSAL] tag our commits
Posted by Adam Kocoloski <ko...@apache.org>.
I'm with Jason on this one, but won't stand in the way if others want to move forward on the proposal.
Adam
On Dec 4, 2013, at 11:24 AM, Jason Smith <jh...@apache.org> wrote:
> -1
>
> We do this at Nodejitsu and I find it tedious and unhelpful. It's a bit of
> ceremony with little benefit. For me at least, I never want to see "only
> [foo] commits" I want to see "only commits in subdirectory foo/". Otherwise
> I see the commits through `git blame`.
>
> That's my opinion, but I am comfortable being overruled.
>
>
> On Sun, Oct 27, 2013 at 8:28 PM, Benoit Chesneau <bc...@gmail.com>wrote:
>
>> Hi all,
>>
>> I would like to propose that we start to tag our commits. The reasonning
>> behind that is to distinct easily the changes concerning the doc, the ui
>> and the core and filter them immediately and force us to make a change
>> atomic. So I would like to propose that we tag the commit line with
>>
>> [DOC]
>> [UI]
>> [CORE]
>>
>> other ? Another way to distinct the changes would also be to have all of
>> these as subprojects eventually but it may require too much changes.
>>
>> Thoughts?
>>
>> - benoit
>>
Re: [PROPOSAL] tag our commits
Posted by Jason Smith <jh...@apache.org>.
I am happy to try it in the spirit of trying things.
I agree with Noah: I'd love if this were documented in a Git workflow
procedure. In particular, which tags should we use, and why.
On Thu, Dec 5, 2013 at 12:40 AM, Benoit Chesneau <bc...@gmail.com>wrote:
> On Wed, Dec 4, 2013 at 6:33 PM, Noah Slater <ns...@apache.org> wrote:
>
> > That's why I said "optional". If people want too use "[docs] Add foo
> > docs" then be my guest. But requiring it seems like trouble. (It
> > effectively means we can never accept squashed changes.)
> >
>
> hrmmm, generally you're squashing only related commits so it should work.
> It works in the linux project at least.
>
>
>
> >
> > On 4 December 2013 17:58, Alexander Shorin <kx...@gmail.com> wrote:
> > > Yea, same tag, but as word (:
> > > --
> > > ,,,^..^,,,
> > >
> > >
> > > On Wed, Dec 4, 2013 at 8:56 PM, Dale Harvey <da...@arandomurl.com>
> wrote:
> > >> "Document foo/bar config option"
> > >>
> > >>
> > >> On 4 December 2013 16:54, Alexander Shorin <kx...@gmail.com> wrote:
> > >>
> > >>> On other hand when you see commit message:
> > >>>
> > >>> Add foo/bar config option
> > >>>
> > >>> What is your first though? Oh, new config option! But no, that was
> > >>> missed option description in docs. To resolve such collision I may
> tag
> > >>> my commit message:
> > >>>
> > >>> Docs: add foo/bar config option // now you know what have changed!
> > >>>
> > >>> or imagine something like:
> > >>>
> > >>> Add missed foo/bar/config option description in docs // too long
> > >>>
> > >>> How I could solve this problem?
> > >>>
> > >>> --
> > >>> ,,,^..^,,,
> > >>>
> > >>>
> > >>> On Wed, Dec 4, 2013 at 8:24 PM, Jason Smith <jh...@apache.org> wrote:
> > >>> > -1
> > >>> >
> > >>> > We do this at Nodejitsu and I find it tedious and unhelpful. It's a
> > bit
> > >>> of
> > >>> > ceremony with little benefit. For me at least, I never want to see
> > "only
> > >>> > [foo] commits" I want to see "only commits in subdirectory foo/".
> > >>> Otherwise
> > >>> > I see the commits through `git blame`.
> > >>> >
> > >>> > That's my opinion, but I am comfortable being overruled.
> > >>> >
> > >>> >
> > >>> > On Sun, Oct 27, 2013 at 8:28 PM, Benoit Chesneau <
> > bchesneau@gmail.com
> > >>> >wrote:
> > >>> >
> > >>> >> Hi all,
> > >>> >>
> > >>> >> I would like to propose that we start to tag our commits. The
> > reasonning
> > >>> >> behind that is to distinct easily the changes concerning the doc,
> > the
> > >>> ui
> > >>> >> and the core and filter them immediately and force us to make a
> > change
> > >>> >> atomic. So I would like to propose that we tag the commit line
> with
> > >>> >>
> > >>> >> [DOC]
> > >>> >> [UI]
> > >>> >> [CORE]
> > >>> >>
> > >>> >> other ? Another way to distinct the changes would also be to have
> > all of
> > >>> >> these as subprojects eventually but it may require too much
> changes.
> > >>> >>
> > >>> >> Thoughts?
> > >>> >>
> > >>> >> - benoit
> > >>> >>
> > >>>
> >
> >
> >
> > --
> > Noah Slater
> > https://twitter.com/nslater
> >
>
Re: [PROPOSAL] tag our commits
Posted by Benoit Chesneau <bc...@gmail.com>.
On Wed, Dec 4, 2013 at 6:33 PM, Noah Slater <ns...@apache.org> wrote:
> That's why I said "optional". If people want too use "[docs] Add foo
> docs" then be my guest. But requiring it seems like trouble. (It
> effectively means we can never accept squashed changes.)
>
hrmmm, generally you're squashing only related commits so it should work.
It works in the linux project at least.
>
> On 4 December 2013 17:58, Alexander Shorin <kx...@gmail.com> wrote:
> > Yea, same tag, but as word (:
> > --
> > ,,,^..^,,,
> >
> >
> > On Wed, Dec 4, 2013 at 8:56 PM, Dale Harvey <da...@arandomurl.com> wrote:
> >> "Document foo/bar config option"
> >>
> >>
> >> On 4 December 2013 16:54, Alexander Shorin <kx...@gmail.com> wrote:
> >>
> >>> On other hand when you see commit message:
> >>>
> >>> Add foo/bar config option
> >>>
> >>> What is your first though? Oh, new config option! But no, that was
> >>> missed option description in docs. To resolve such collision I may tag
> >>> my commit message:
> >>>
> >>> Docs: add foo/bar config option // now you know what have changed!
> >>>
> >>> or imagine something like:
> >>>
> >>> Add missed foo/bar/config option description in docs // too long
> >>>
> >>> How I could solve this problem?
> >>>
> >>> --
> >>> ,,,^..^,,,
> >>>
> >>>
> >>> On Wed, Dec 4, 2013 at 8:24 PM, Jason Smith <jh...@apache.org> wrote:
> >>> > -1
> >>> >
> >>> > We do this at Nodejitsu and I find it tedious and unhelpful. It's a
> bit
> >>> of
> >>> > ceremony with little benefit. For me at least, I never want to see
> "only
> >>> > [foo] commits" I want to see "only commits in subdirectory foo/".
> >>> Otherwise
> >>> > I see the commits through `git blame`.
> >>> >
> >>> > That's my opinion, but I am comfortable being overruled.
> >>> >
> >>> >
> >>> > On Sun, Oct 27, 2013 at 8:28 PM, Benoit Chesneau <
> bchesneau@gmail.com
> >>> >wrote:
> >>> >
> >>> >> Hi all,
> >>> >>
> >>> >> I would like to propose that we start to tag our commits. The
> reasonning
> >>> >> behind that is to distinct easily the changes concerning the doc,
> the
> >>> ui
> >>> >> and the core and filter them immediately and force us to make a
> change
> >>> >> atomic. So I would like to propose that we tag the commit line with
> >>> >>
> >>> >> [DOC]
> >>> >> [UI]
> >>> >> [CORE]
> >>> >>
> >>> >> other ? Another way to distinct the changes would also be to have
> all of
> >>> >> these as subprojects eventually but it may require too much changes.
> >>> >>
> >>> >> Thoughts?
> >>> >>
> >>> >> - benoit
> >>> >>
> >>>
>
>
>
> --
> Noah Slater
> https://twitter.com/nslater
>
Re: [PROPOSAL] tag our commits
Posted by Noah Slater <ns...@apache.org>.
That's why I said "optional". If people want too use "[docs] Add foo
docs" then be my guest. But requiring it seems like trouble. (It
effectively means we can never accept squashed changes.)
On 4 December 2013 17:58, Alexander Shorin <kx...@gmail.com> wrote:
> Yea, same tag, but as word (:
> --
> ,,,^..^,,,
>
>
> On Wed, Dec 4, 2013 at 8:56 PM, Dale Harvey <da...@arandomurl.com> wrote:
>> "Document foo/bar config option"
>>
>>
>> On 4 December 2013 16:54, Alexander Shorin <kx...@gmail.com> wrote:
>>
>>> On other hand when you see commit message:
>>>
>>> Add foo/bar config option
>>>
>>> What is your first though? Oh, new config option! But no, that was
>>> missed option description in docs. To resolve such collision I may tag
>>> my commit message:
>>>
>>> Docs: add foo/bar config option // now you know what have changed!
>>>
>>> or imagine something like:
>>>
>>> Add missed foo/bar/config option description in docs // too long
>>>
>>> How I could solve this problem?
>>>
>>> --
>>> ,,,^..^,,,
>>>
>>>
>>> On Wed, Dec 4, 2013 at 8:24 PM, Jason Smith <jh...@apache.org> wrote:
>>> > -1
>>> >
>>> > We do this at Nodejitsu and I find it tedious and unhelpful. It's a bit
>>> of
>>> > ceremony with little benefit. For me at least, I never want to see "only
>>> > [foo] commits" I want to see "only commits in subdirectory foo/".
>>> Otherwise
>>> > I see the commits through `git blame`.
>>> >
>>> > That's my opinion, but I am comfortable being overruled.
>>> >
>>> >
>>> > On Sun, Oct 27, 2013 at 8:28 PM, Benoit Chesneau <bchesneau@gmail.com
>>> >wrote:
>>> >
>>> >> Hi all,
>>> >>
>>> >> I would like to propose that we start to tag our commits. The reasonning
>>> >> behind that is to distinct easily the changes concerning the doc, the
>>> ui
>>> >> and the core and filter them immediately and force us to make a change
>>> >> atomic. So I would like to propose that we tag the commit line with
>>> >>
>>> >> [DOC]
>>> >> [UI]
>>> >> [CORE]
>>> >>
>>> >> other ? Another way to distinct the changes would also be to have all of
>>> >> these as subprojects eventually but it may require too much changes.
>>> >>
>>> >> Thoughts?
>>> >>
>>> >> - benoit
>>> >>
>>>
--
Noah Slater
https://twitter.com/nslater
Re: [PROPOSAL] tag our commits
Posted by Alexander Shorin <kx...@gmail.com>.
Yea, same tag, but as word (:
--
,,,^..^,,,
On Wed, Dec 4, 2013 at 8:56 PM, Dale Harvey <da...@arandomurl.com> wrote:
> "Document foo/bar config option"
>
>
> On 4 December 2013 16:54, Alexander Shorin <kx...@gmail.com> wrote:
>
>> On other hand when you see commit message:
>>
>> Add foo/bar config option
>>
>> What is your first though? Oh, new config option! But no, that was
>> missed option description in docs. To resolve such collision I may tag
>> my commit message:
>>
>> Docs: add foo/bar config option // now you know what have changed!
>>
>> or imagine something like:
>>
>> Add missed foo/bar/config option description in docs // too long
>>
>> How I could solve this problem?
>>
>> --
>> ,,,^..^,,,
>>
>>
>> On Wed, Dec 4, 2013 at 8:24 PM, Jason Smith <jh...@apache.org> wrote:
>> > -1
>> >
>> > We do this at Nodejitsu and I find it tedious and unhelpful. It's a bit
>> of
>> > ceremony with little benefit. For me at least, I never want to see "only
>> > [foo] commits" I want to see "only commits in subdirectory foo/".
>> Otherwise
>> > I see the commits through `git blame`.
>> >
>> > That's my opinion, but I am comfortable being overruled.
>> >
>> >
>> > On Sun, Oct 27, 2013 at 8:28 PM, Benoit Chesneau <bchesneau@gmail.com
>> >wrote:
>> >
>> >> Hi all,
>> >>
>> >> I would like to propose that we start to tag our commits. The reasonning
>> >> behind that is to distinct easily the changes concerning the doc, the
>> ui
>> >> and the core and filter them immediately and force us to make a change
>> >> atomic. So I would like to propose that we tag the commit line with
>> >>
>> >> [DOC]
>> >> [UI]
>> >> [CORE]
>> >>
>> >> other ? Another way to distinct the changes would also be to have all of
>> >> these as subprojects eventually but it may require too much changes.
>> >>
>> >> Thoughts?
>> >>
>> >> - benoit
>> >>
>>
Re: [PROPOSAL] tag our commits
Posted by Dale Harvey <da...@arandomurl.com>.
"Document foo/bar config option"
On 4 December 2013 16:54, Alexander Shorin <kx...@gmail.com> wrote:
> On other hand when you see commit message:
>
> Add foo/bar config option
>
> What is your first though? Oh, new config option! But no, that was
> missed option description in docs. To resolve such collision I may tag
> my commit message:
>
> Docs: add foo/bar config option // now you know what have changed!
>
> or imagine something like:
>
> Add missed foo/bar/config option description in docs // too long
>
> How I could solve this problem?
>
> --
> ,,,^..^,,,
>
>
> On Wed, Dec 4, 2013 at 8:24 PM, Jason Smith <jh...@apache.org> wrote:
> > -1
> >
> > We do this at Nodejitsu and I find it tedious and unhelpful. It's a bit
> of
> > ceremony with little benefit. For me at least, I never want to see "only
> > [foo] commits" I want to see "only commits in subdirectory foo/".
> Otherwise
> > I see the commits through `git blame`.
> >
> > That's my opinion, but I am comfortable being overruled.
> >
> >
> > On Sun, Oct 27, 2013 at 8:28 PM, Benoit Chesneau <bchesneau@gmail.com
> >wrote:
> >
> >> Hi all,
> >>
> >> I would like to propose that we start to tag our commits. The reasonning
> >> behind that is to distinct easily the changes concerning the doc, the
> ui
> >> and the core and filter them immediately and force us to make a change
> >> atomic. So I would like to propose that we tag the commit line with
> >>
> >> [DOC]
> >> [UI]
> >> [CORE]
> >>
> >> other ? Another way to distinct the changes would also be to have all of
> >> these as subprojects eventually but it may require too much changes.
> >>
> >> Thoughts?
> >>
> >> - benoit
> >>
>
Re: [PROPOSAL] tag our commits
Posted by Alexander Shorin <kx...@gmail.com>.
On other hand when you see commit message:
Add foo/bar config option
What is your first though? Oh, new config option! But no, that was
missed option description in docs. To resolve such collision I may tag
my commit message:
Docs: add foo/bar config option // now you know what have changed!
or imagine something like:
Add missed foo/bar/config option description in docs // too long
How I could solve this problem?
--
,,,^..^,,,
On Wed, Dec 4, 2013 at 8:24 PM, Jason Smith <jh...@apache.org> wrote:
> -1
>
> We do this at Nodejitsu and I find it tedious and unhelpful. It's a bit of
> ceremony with little benefit. For me at least, I never want to see "only
> [foo] commits" I want to see "only commits in subdirectory foo/". Otherwise
> I see the commits through `git blame`.
>
> That's my opinion, but I am comfortable being overruled.
>
>
> On Sun, Oct 27, 2013 at 8:28 PM, Benoit Chesneau <bc...@gmail.com>wrote:
>
>> Hi all,
>>
>> I would like to propose that we start to tag our commits. The reasonning
>> behind that is to distinct easily the changes concerning the doc, the ui
>> and the core and filter them immediately and force us to make a change
>> atomic. So I would like to propose that we tag the commit line with
>>
>> [DOC]
>> [UI]
>> [CORE]
>>
>> other ? Another way to distinct the changes would also be to have all of
>> these as subprojects eventually but it may require too much changes.
>>
>> Thoughts?
>>
>> - benoit
>>
Re: [PROPOSAL] tag our commits
Posted by Benoit Chesneau <bc...@gmail.com>.
On Wed, Dec 4, 2013 at 5:42 PM, Jason Smith <jh...@apache.org> wrote:
> While I'm whining about tags:
>
> Tagging is most useful by having multiple tags per target. My blog post can
> be tagged [vacation] [swaziland] [photos] [family], and then later I can
> find all posts about family.
>
> Git messages are forced to one tag. That's unhelpful because commits
> ideally update code, tests, and documentation. A useful tag might be [ui]
> but I could get the same thing by looking at the history of src/fauxton/.
>
> It is marginally useful at a very dear cost: 4-10 characters per commit
> message.
>
>
Generally a commit should be atomic. And by that I don't mean it has to be
only for doc, tests or some code. a tag named [code] would be useless
indeed. However, in the same vein we are tagging issues on jira we could
have tags describing the feature it attempts to patch. Even the english
allows people to present a idea in a concise way, in 1-2 words.
http:
btree
db api
couch_mrview
couch_index
couch_replicator
couch_http
couch_changes
couch_os
installation
and doc, tests for the one that are only touching these parts are useful.
It helps to have a quick glance among all the commits.
I am seeing many advantages to tag the commits
Having tag helps to have a quick glance on the commits, and raises the
attention of the developer that is interested in such part so you don't
have to watch each commit to figure if he's interested or not. And
naturally people will start to review, and we will stop to see people
committing in master without having at least a formal review (irc is not
formal).
Having tags force naturally people to be atomic and resist to the
temptation to change every part of the code. (The "while I am here do...")
Having tags force people to reread themselves before committing. So will
have less commits fixing the previous commit that was fixing the previous
one....
Having tags improve the visibility of the code in search engines.
So far all communities around that are serious about the code quality are
tagging their commit. Do we care about the code quality?
So I don't think it is not "marginally useful" imo and hopefully you will
reconsider the advantages it can give.
Re: [PROPOSAL] tag our commits
Posted by Dale Harvey <da...@arandomurl.com>.
Also a reasonably weak -1, atomic updates to tests / docs / code is a good
thing, the tags are pretty much always inconsistent, they arent actually
useful for anything and additional steps are just another barrier
I have been asking people to avoid it on any codebases I review for
On 4 December 2013 16:47, Noah Slater <ns...@apache.org> wrote:
> Jason makes a compelling argument.
>
> Let's say you do three commits on a feature branch:
>
> [code] Add foo widget to core
> [tests] Add tests for foo widget
> [docs] Add docs for foo widget
>
> What do you then use as a commit message when you squash and merge into
> master?
>
> And let's say we want to accept a pull request on Github that adds foo
> atomically. Are we really going to send the person away and ask them
> to decompose the commit into many commits, each one with a tag?
>
> I think I've convinced myself that this should, at the most, be optional.
>
> On 4 December 2013 17:42, Jason Smith <jh...@apache.org> wrote:
> > While I'm whining about tags:
> >
> > Tagging is most useful by having multiple tags per target. My blog post
> can
> > be tagged [vacation] [swaziland] [photos] [family], and then later I can
> > find all posts about family.
> >
> > Git messages are forced to one tag. That's unhelpful because commits
> > ideally update code, tests, and documentation. A useful tag might be [ui]
> > but I could get the same thing by looking at the history of src/fauxton/.
> >
> > It is marginally useful at a very dear cost: 4-10 characters per commit
> > message.
> >
> >
> > On Wed, Dec 4, 2013 at 11:24 PM, Jason Smith <jh...@apache.org> wrote:
> >
> >> -1
> >>
> >> We do this at Nodejitsu and I find it tedious and unhelpful. It's a bit
> of
> >> ceremony with little benefit. For me at least, I never want to see "only
> >> [foo] commits" I want to see "only commits in subdirectory foo/".
> Otherwise
> >> I see the commits through `git blame`.
> >>
> >> That's my opinion, but I am comfortable being overruled.
> >>
> >>
> >> On Sun, Oct 27, 2013 at 8:28 PM, Benoit Chesneau <bchesneau@gmail.com
> >wrote:
> >>
> >>> Hi all,
> >>>
> >>> I would like to propose that we start to tag our commits. The
> reasonning
> >>> behind that is to distinct easily the changes concerning the doc, the
> ui
> >>> and the core and filter them immediately and force us to make a change
> >>> atomic. So I would like to propose that we tag the commit line with
> >>>
> >>> [DOC]
> >>> [UI]
> >>> [CORE]
> >>>
> >>> other ? Another way to distinct the changes would also be to have all
> of
> >>> these as subprojects eventually but it may require too much changes.
> >>>
> >>> Thoughts?
> >>>
> >>> - benoit
> >>>
> >>
> >>
>
>
>
> --
> Noah Slater
> https://twitter.com/nslater
>
Re: [PROPOSAL] tag our commits
Posted by Benoit Chesneau <bc...@gmail.com>.
On Wed, Dec 4, 2013 at 6:45 PM, Noah Slater <ns...@apache.org> wrote:
> Consolidating my replies to a single email so as to limit mail churn. :)
>
> On 4 December 2013 18:33, Benoit Chesneau <bc...@gmail.com> wrote:
>
> > Having tags force naturally people to[...]
> > Having tags force people to[...]
>
> > If the system if it's optional it lost any interest. People that don't
> want
> > to use it won't use it and we will stay with the same soup and
> meaningless
> > commit messages forcing people to read the full change to figure.
>
> Guidelines do not force anything. If something is confusing or people
> don't like it, it will be ignored.
>
If you ignore a guideline then it should be discussed rather than being
ignored. By forcing here I am just expecting that people really take care
about guidelines and their spirit and then pay attention to it even if they
don't follow them strictly.
>
> > a tag should be related to the feature it patches
>
> I think this sounds like a good idea. But we should recommend that
> people tag the one-line comment with any major system that is
> effected. But it should not be compulsory to do so.
>
Actually it should be good that we tag the commits. I can still see a lot
of commits that force me to look at the code because the description is
vague or lack of the context to see if I should backport it in a test
branch or not. Which is to say less a big time killer. I agree that
sometimes a tag is too much restrictive anyway so it may be just a matter
of having for rule to make the first line really descriptive (a tag most of
the time will figure what is the comment context).
If we are speaking of guideline I really think that a code should go in a
review branch before landing in the master so eventually the comment could
be corrected and some patches rebased. It's really painful to handle a
change is that is fixing a change that was fixing a change that was fixing
another.... Each time you backport it (for tests or productions) it imply
that you relaunch tests. And I am pretty sure that most of the time such
commits could be skipped in the master if the code was reviewed.
> >> And let's say we want to accept a pull request on Github that adds foo
> >> atomically. Are we really going to send the person away and ask them
> >> to decompose the commit into many commits, each one with a tag?
> >>
> >
> > yes. This is a good practice.
>
> This is the opposite of every pull request I've ever seen. (Which is,
> admittedly, not many.)
>
You can see on github that a lot of PR are composed of many commits, most
of the time corresponding to one change that can affect the code deeply. It
is really a good practice to separate commits in an atomic way, so a
serious review can be done so that the accepted changes (if any) don't
imply to have to review another big patch.
- benoit
Re: [PROPOSAL] tag our commits
Posted by Noah Slater <ns...@apache.org>.
Consolidating my replies to a single email so as to limit mail churn. :)
On 4 December 2013 18:33, Benoit Chesneau <bc...@gmail.com> wrote:
> Having tags force naturally people to[...]
> Having tags force people to[...]
> If the system if it's optional it lost any interest. People that don't want
> to use it won't use it and we will stay with the same soup and meaningless
> commit messages forcing people to read the full change to figure.
Guidelines do not force anything. If something is confusing or people
don't like it, it will be ignored.
> a tag should be related to the feature it patches
I think this sounds like a good idea. But we should recommend that
people tag the one-line comment with any major system that is
effected. But it should not be compulsory to do so.
>> And let's say we want to accept a pull request on Github that adds foo
>> atomically. Are we really going to send the person away and ask them
>> to decompose the commit into many commits, each one with a tag?
>>
>
> yes. This is a good practice.
This is the opposite of every pull request I've ever seen. (Which is,
admittedly, not many.)
--
Noah Slater
https://twitter.com/nslater
Re: [PROPOSAL] tag our commits
Posted by Benoit Chesneau <bc...@gmail.com>.
On Wed, Dec 4, 2013 at 5:47 PM, Noah Slater <ns...@apache.org> wrote:
> Jason makes a compelling argument.
>
> Let's say you do three commits on a feature branch:
>
> [code] Add foo widget to core
> [tests] Add tests for foo widget
> [docs] Add docs for foo widget
>
if the tag would be code it would be indeed useless. But it was not what I
suggested. Instead a tag should be related to the feature it patches. I
gave more examples in another mail.
> What do you then use as a commit message when you squash and merge into
> master?
>
> And let's say we want to accept a pull request on Github that adds foo
> atomically. Are we really going to send the person away and ask them
> to decompose the commit into many commits, each one with a tag?
>
yes. This is a good practice. Like we should have unit tests, a commit
should be enough atomic to not touch many parts of the repository. And
hopefully coming with a test.
>
> I think I've convinced myself that this should, at the most, be optional.
>
If the system if it's optional it lost any interest. People that don't want
to use it won't use it and we will stay with the same soup and meaningless
commit messages forcing people to read the full change to figure.
Re: [PROPOSAL] tag our commits
Posted by Noah Slater <ns...@apache.org>.
Jason makes a compelling argument.
Let's say you do three commits on a feature branch:
[code] Add foo widget to core
[tests] Add tests for foo widget
[docs] Add docs for foo widget
What do you then use as a commit message when you squash and merge into master?
And let's say we want to accept a pull request on Github that adds foo
atomically. Are we really going to send the person away and ask them
to decompose the commit into many commits, each one with a tag?
I think I've convinced myself that this should, at the most, be optional.
On 4 December 2013 17:42, Jason Smith <jh...@apache.org> wrote:
> While I'm whining about tags:
>
> Tagging is most useful by having multiple tags per target. My blog post can
> be tagged [vacation] [swaziland] [photos] [family], and then later I can
> find all posts about family.
>
> Git messages are forced to one tag. That's unhelpful because commits
> ideally update code, tests, and documentation. A useful tag might be [ui]
> but I could get the same thing by looking at the history of src/fauxton/.
>
> It is marginally useful at a very dear cost: 4-10 characters per commit
> message.
>
>
> On Wed, Dec 4, 2013 at 11:24 PM, Jason Smith <jh...@apache.org> wrote:
>
>> -1
>>
>> We do this at Nodejitsu and I find it tedious and unhelpful. It's a bit of
>> ceremony with little benefit. For me at least, I never want to see "only
>> [foo] commits" I want to see "only commits in subdirectory foo/". Otherwise
>> I see the commits through `git blame`.
>>
>> That's my opinion, but I am comfortable being overruled.
>>
>>
>> On Sun, Oct 27, 2013 at 8:28 PM, Benoit Chesneau <bc...@gmail.com>wrote:
>>
>>> Hi all,
>>>
>>> I would like to propose that we start to tag our commits. The reasonning
>>> behind that is to distinct easily the changes concerning the doc, the ui
>>> and the core and filter them immediately and force us to make a change
>>> atomic. So I would like to propose that we tag the commit line with
>>>
>>> [DOC]
>>> [UI]
>>> [CORE]
>>>
>>> other ? Another way to distinct the changes would also be to have all of
>>> these as subprojects eventually but it may require too much changes.
>>>
>>> Thoughts?
>>>
>>> - benoit
>>>
>>
>>
--
Noah Slater
https://twitter.com/nslater
Re: [PROPOSAL] tag our commits
Posted by Jason Smith <jh...@apache.org>.
While I'm whining about tags:
Tagging is most useful by having multiple tags per target. My blog post can
be tagged [vacation] [swaziland] [photos] [family], and then later I can
find all posts about family.
Git messages are forced to one tag. That's unhelpful because commits
ideally update code, tests, and documentation. A useful tag might be [ui]
but I could get the same thing by looking at the history of src/fauxton/.
It is marginally useful at a very dear cost: 4-10 characters per commit
message.
On Wed, Dec 4, 2013 at 11:24 PM, Jason Smith <jh...@apache.org> wrote:
> -1
>
> We do this at Nodejitsu and I find it tedious and unhelpful. It's a bit of
> ceremony with little benefit. For me at least, I never want to see "only
> [foo] commits" I want to see "only commits in subdirectory foo/". Otherwise
> I see the commits through `git blame`.
>
> That's my opinion, but I am comfortable being overruled.
>
>
> On Sun, Oct 27, 2013 at 8:28 PM, Benoit Chesneau <bc...@gmail.com>wrote:
>
>> Hi all,
>>
>> I would like to propose that we start to tag our commits. The reasonning
>> behind that is to distinct easily the changes concerning the doc, the ui
>> and the core and filter them immediately and force us to make a change
>> atomic. So I would like to propose that we tag the commit line with
>>
>> [DOC]
>> [UI]
>> [CORE]
>>
>> other ? Another way to distinct the changes would also be to have all of
>> these as subprojects eventually but it may require too much changes.
>>
>> Thoughts?
>>
>> - benoit
>>
>
>
Re: [PROPOSAL] tag our commits
Posted by Jason Smith <jh...@apache.org>.
-1
We do this at Nodejitsu and I find it tedious and unhelpful. It's a bit of
ceremony with little benefit. For me at least, I never want to see "only
[foo] commits" I want to see "only commits in subdirectory foo/". Otherwise
I see the commits through `git blame`.
That's my opinion, but I am comfortable being overruled.
On Sun, Oct 27, 2013 at 8:28 PM, Benoit Chesneau <bc...@gmail.com>wrote:
> Hi all,
>
> I would like to propose that we start to tag our commits. The reasonning
> behind that is to distinct easily the changes concerning the doc, the ui
> and the core and filter them immediately and force us to make a change
> atomic. So I would like to propose that we tag the commit line with
>
> [DOC]
> [UI]
> [CORE]
>
> other ? Another way to distinct the changes would also be to have all of
> these as subprojects eventually but it may require too much changes.
>
> Thoughts?
>
> - benoit
>
Re: [PROPOSAL] tag our commits
Posted by Alexander Shorin <kx...@gmail.com>.
+1
I'm trying to do the same, but within commit message and sometimes it
looks weird or hard to make a correct phrase.
P.S. I wonder, is there any guidelines or standard solutions for this
problem. Idea of tags as prefix of commit message looks simple and
good, but also it looks as some hack of using VCS. Like tagging in SVN
with copy-paste whole project for some commit.
--
,,,^..^,,,
On Sun, Oct 27, 2013 at 5:28 PM, Benoit Chesneau <bc...@gmail.com> wrote:
> Hi all,
>
> I would like to propose that we start to tag our commits. The reasonning
> behind that is to distinct easily the changes concerning the doc, the ui
> and the core and filter them immediately and force us to make a change
> atomic. So I would like to propose that we tag the commit line with
>
> [DOC]
> [UI]
> [CORE]
>
> other ? Another way to distinct the changes would also be to have all of
> these as subprojects eventually but it may require too much changes.
>
> Thoughts?
>
> - benoit
Re: [PROPOSAL] tag our commits
Posted by Garren Smith <ga...@apache.org>.
On 28 Oct 2013, at 5:22 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
> On 28 Oct 2013, at 16:07 , Alexander Shorin <kx...@gmail.com> wrote:
>
>> On Mon, Oct 28, 2013 at 1:19 AM, Alexander Shorin <kx...@gmail.com> wrote:
>>> On Mon, Oct 28, 2013 at 1:12 AM, Dirkjan Ochtman <di...@ochtman.nl> wrote:
>>>> On Sun, Oct 27, 2013 at 10:00 PM, Alexander Shorin <kx...@gmail.com> wrote:
>>>>> There is no worry about since it's standard feature for git and
>>>>> supported by gitweb and github[1] as well.
>>>>
>>>> How about the IRC bots? And the email messages (both commit
>>>> notifications and PR notifications)?
>>>
>>> Hm..let's try to figure their support status(: I suppose nobody mind
>>> if I push one commit with notes?
>>
>> Ok, there are three problems with notes:
>> 1. Additional commit event without explicit association with related commit
>> 2. GitWeb and GitHub doesn't[1][2] show any notices. However, if you
>> push notes to GitHub repo - it will
>> 3. You should fetch notices in additional to regular clone/pull command
>>
>> They are looks fine for automatic assignment build status, bug-id,
>> making notes on commit like postfactum review, forward references or
>> something else, but probably not for our case: tagging each commit
>> with affected component(s).
>>
>> On other hand, tags inside commit message looks more weird[3] since
>> not everyone may follow this convention. These tags couldn't be
>> changed without editing commit message, so it will be easy to create
>> duplicate tags like [doc], [docs], [man], [manual] or [futon],
>> [fauxton], [webui], [ui]. Also,
>> the perfect spherical commit in a vacuum should contains multiple
>> tags: docs, tests, affected component - with limitation of 54 chars
>> for first commit line tags would eat a lot of space, making left short
>> description useless.
>>
>> The solution I see quite simple: commit as we doing now. Additionally,
>> setup some bot that will "tag" our commits with notes (hi, ASFBot!) -
>> it should be easy since each component has his own path prefix (docs
>> is in share/docs, tests are in tests/, replicator is in
>> src/couch_replicator etc.) so we'll be free from this manual work. The
>> only things we need to do, is update .git/config file with fetch =
>> +refs/notes/*:refs/notes/* to getting notes from server without
>> execution of additional git command.
>>
>> Thoughts?
>
> I like Dirkjan’s idea of using `tag:` instead of `[tag]` even more.
> I don’t think it is very bad if get multiple tags for the same thing.
> `doc: foo` and `manual: foo` is equally easy to skip over and grep
> out. But of course we should try to set a standard set and maintain
> that on the wiki or in the docs.
>
> To help with this, we could have pre-commit hooks locally that ensures
> we use one of the defined tags.
>
> Best
> Jan
> --
I thought we decided to do the tag in the commit a while ago. I try and remember to tag all the Fauxton commits with `Faxuton: ....`
Re: [PROPOSAL] tag our commits
Posted by Noah Slater <ns...@apache.org>.
>From a procedural perspective, the way this should work is that things
which reach a broad consensus via discussion should be added to the
draft workflow doc. Anything that seems contentious should be
discussed until it looks like we have consensus. Once the draft is
finished, we do one vote to tie a bow on it, and the whole thing
becomes official.
If someone wants to run with this, please reach out to me and I can
guide you personally on how to approach this from a project
perspective.
On 4 December 2013 13:34, Noah Slater <ns...@apache.org> wrote:
> Hi folks,
>
> This sounds like a good idea, but I have a request.
>
> We are still waiting for someone to run with the idea of writing up
> our Git workflow. This should document how we use Git on the project.
> How to make feature branches. How to manage release branches. And...
> *drumroll* how to tag commits.
>
> There's a lot of undocumented rules and I have heard first hand from
> people that it is intimidating trying to figure out how to contribute
> to the project. So this work would be very valuable for the community.
>
> On 30 November 2013 10:45, Dave Cottlehuber <dc...@jsonified.com> wrote:
>> Great, let's do it. Before merging, all we'll need to do is get a +1
>> from another dev & we're good to go.
>>
>> On 30 November 2013 10:23, Benoit Chesneau <bc...@gmail.com> wrote:
>>> On Tue, Oct 29, 2013 at 9:29 AM, Benoit Chesneau <bc...@gmail.com>wrote:
>>>
>>>>
>>>>>
>>>> My only objection to the `tag:` fomat is that this is not the way you tag
>>>> an email generally. Since the first line of the commit is generally the
>>>> subject of the message and the patch you get with format-patch, I think
>>>> that using a common way to tag the subject may be better.
>>>>
>>>> I really don't think that's weird for those who are mainly using the mail
>>>> to handle the git commits and some are.
>>>>
>>>> Maybe that worth to take it in consideration?
>>>>
>>>
>>>
>>> I just rad last changelog fron the linux kernel [1], and as you can see the
>>> tags are <tag>: ... on the firstline, in lowercase or uppercase. So let's
>>> go for that indeed.
>>>
>>>
>>> Also I quite like their changelog. Much more precise than our changelog.
>>> Maybe we could follow such idea.
>>>
>>> - benoit
>>>
>>> [1] https://lkml.org/lkml/2013/11/29/335
>
>
>
> --
> Noah Slater
> https://twitter.com/nslater
--
Noah Slater
https://twitter.com/nslater
Re: [PROPOSAL] tag our commits
Posted by Noah Slater <ns...@apache.org>.
Hi folks,
This sounds like a good idea, but I have a request.
We are still waiting for someone to run with the idea of writing up
our Git workflow. This should document how we use Git on the project.
How to make feature branches. How to manage release branches. And...
*drumroll* how to tag commits.
There's a lot of undocumented rules and I have heard first hand from
people that it is intimidating trying to figure out how to contribute
to the project. So this work would be very valuable for the community.
On 30 November 2013 10:45, Dave Cottlehuber <dc...@jsonified.com> wrote:
> Great, let's do it. Before merging, all we'll need to do is get a +1
> from another dev & we're good to go.
>
> On 30 November 2013 10:23, Benoit Chesneau <bc...@gmail.com> wrote:
>> On Tue, Oct 29, 2013 at 9:29 AM, Benoit Chesneau <bc...@gmail.com>wrote:
>>
>>>
>>>>
>>> My only objection to the `tag:` fomat is that this is not the way you tag
>>> an email generally. Since the first line of the commit is generally the
>>> subject of the message and the patch you get with format-patch, I think
>>> that using a common way to tag the subject may be better.
>>>
>>> I really don't think that's weird for those who are mainly using the mail
>>> to handle the git commits and some are.
>>>
>>> Maybe that worth to take it in consideration?
>>>
>>
>>
>> I just rad last changelog fron the linux kernel [1], and as you can see the
>> tags are <tag>: ... on the firstline, in lowercase or uppercase. So let's
>> go for that indeed.
>>
>>
>> Also I quite like their changelog. Much more precise than our changelog.
>> Maybe we could follow such idea.
>>
>> - benoit
>>
>> [1] https://lkml.org/lkml/2013/11/29/335
--
Noah Slater
https://twitter.com/nslater
Re: [PROPOSAL] tag our commits
Posted by Dave Cottlehuber <dc...@jsonified.com>.
Great, let's do it. Before merging, all we'll need to do is get a +1
from another dev & we're good to go.
On 30 November 2013 10:23, Benoit Chesneau <bc...@gmail.com> wrote:
> On Tue, Oct 29, 2013 at 9:29 AM, Benoit Chesneau <bc...@gmail.com>wrote:
>
>>
>>>
>> My only objection to the `tag:` fomat is that this is not the way you tag
>> an email generally. Since the first line of the commit is generally the
>> subject of the message and the patch you get with format-patch, I think
>> that using a common way to tag the subject may be better.
>>
>> I really don't think that's weird for those who are mainly using the mail
>> to handle the git commits and some are.
>>
>> Maybe that worth to take it in consideration?
>>
>
>
> I just rad last changelog fron the linux kernel [1], and as you can see the
> tags are <tag>: ... on the firstline, in lowercase or uppercase. So let's
> go for that indeed.
>
>
> Also I quite like their changelog. Much more precise than our changelog.
> Maybe we could follow such idea.
>
> - benoit
>
> [1] https://lkml.org/lkml/2013/11/29/335
Re: [PROPOSAL] tag our commits
Posted by Benoit Chesneau <bc...@gmail.com>.
On Tue, Oct 29, 2013 at 9:29 AM, Benoit Chesneau <bc...@gmail.com>wrote:
>
>>
> My only objection to the `tag:` fomat is that this is not the way you tag
> an email generally. Since the first line of the commit is generally the
> subject of the message and the patch you get with format-patch, I think
> that using a common way to tag the subject may be better.
>
> I really don't think that's weird for those who are mainly using the mail
> to handle the git commits and some are.
>
> Maybe that worth to take it in consideration?
>
I just rad last changelog fron the linux kernel [1], and as you can see the
tags are <tag>: ... on the firstline, in lowercase or uppercase. So let's
go for that indeed.
Also I quite like their changelog. Much more precise than our changelog.
Maybe we could follow such idea.
- benoit
[1] https://lkml.org/lkml/2013/11/29/335
Re: [PROPOSAL] tag our commits
Posted by Benoit Chesneau <bc...@gmail.com>.
On Mon, Oct 28, 2013 at 4:22 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
> On 28 Oct 2013, at 16:07 , Alexander Shorin <kx...@gmail.com> wrote:
>
> > On Mon, Oct 28, 2013 at 1:19 AM, Alexander Shorin <kx...@gmail.com>
> wrote:
> >> On Mon, Oct 28, 2013 at 1:12 AM, Dirkjan Ochtman <di...@ochtman.nl>
> wrote:
> >>> On Sun, Oct 27, 2013 at 10:00 PM, Alexander Shorin <kx...@gmail.com>
> wrote:
> >>>> There is no worry about since it's standard feature for git and
> >>>> supported by gitweb and github[1] as well.
> >>>
> >>> How about the IRC bots? And the email messages (both commit
> >>> notifications and PR notifications)?
> >>
> >> Hm..let's try to figure their support status(: I suppose nobody mind
> >> if I push one commit with notes?
> >
> > Ok, there are three problems with notes:
> > 1. Additional commit event without explicit association with related
> commit
> > 2. GitWeb and GitHub doesn't[1][2] show any notices. However, if you
> > push notes to GitHub repo - it will
> > 3. You should fetch notices in additional to regular clone/pull command
> >
> > They are looks fine for automatic assignment build status, bug-id,
> > making notes on commit like postfactum review, forward references or
> > something else, but probably not for our case: tagging each commit
> > with affected component(s).
> >
> > On other hand, tags inside commit message looks more weird[3] since
> > not everyone may follow this convention. These tags couldn't be
> > changed without editing commit message, so it will be easy to create
> > duplicate tags like [doc], [docs], [man], [manual] or [futon],
> > [fauxton], [webui], [ui]. Also,
> > the perfect spherical commit in a vacuum should contains multiple
> > tags: docs, tests, affected component - with limitation of 54 chars
> > for first commit line tags would eat a lot of space, making left short
> > description useless.
> >
> > The solution I see quite simple: commit as we doing now. Additionally,
> > setup some bot that will "tag" our commits with notes (hi, ASFBot!) -
> > it should be easy since each component has his own path prefix (docs
> > is in share/docs, tests are in tests/, replicator is in
> > src/couch_replicator etc.) so we'll be free from this manual work. The
> > only things we need to do, is update .git/config file with fetch =
> > +refs/notes/*:refs/notes/* to getting notes from server without
> > execution of additional git command.
> >
> > Thoughts?
>
> I like Dirkjan’s idea of using `tag:` instead of `[tag]` even more.
> I don’t think it is very bad if get multiple tags for the same thing.
> `doc: foo` and `manual: foo` is equally easy to skip over and grep
> out. But of course we should try to set a standard set and maintain
> that on the wiki or in the docs.
>
> To help with this, we could have pre-commit hooks locally that ensures
> we use one of the defined tags.
>
>
>
My only objection to the `tag:` fomat is that this is not the way you tag
an email generally. Since the first line of the commit is generally the
subject of the message and the patch you get with format-patch, I think
that using a common way to tag the subject may be better.
I really don't think that's weird for those who are mainly using the mail
to handle the git commits and some are.
Maybe that worth to take it in consideration?
Re: [PROPOSAL] tag our commits
Posted by Jan Lehnardt <ja...@apache.org>.
On 28 Oct 2013, at 16:07 , Alexander Shorin <kx...@gmail.com> wrote:
> On Mon, Oct 28, 2013 at 1:19 AM, Alexander Shorin <kx...@gmail.com> wrote:
>> On Mon, Oct 28, 2013 at 1:12 AM, Dirkjan Ochtman <di...@ochtman.nl> wrote:
>>> On Sun, Oct 27, 2013 at 10:00 PM, Alexander Shorin <kx...@gmail.com> wrote:
>>>> There is no worry about since it's standard feature for git and
>>>> supported by gitweb and github[1] as well.
>>>
>>> How about the IRC bots? And the email messages (both commit
>>> notifications and PR notifications)?
>>
>> Hm..let's try to figure their support status(: I suppose nobody mind
>> if I push one commit with notes?
>
> Ok, there are three problems with notes:
> 1. Additional commit event without explicit association with related commit
> 2. GitWeb and GitHub doesn't[1][2] show any notices. However, if you
> push notes to GitHub repo - it will
> 3. You should fetch notices in additional to regular clone/pull command
>
> They are looks fine for automatic assignment build status, bug-id,
> making notes on commit like postfactum review, forward references or
> something else, but probably not for our case: tagging each commit
> with affected component(s).
>
> On other hand, tags inside commit message looks more weird[3] since
> not everyone may follow this convention. These tags couldn't be
> changed without editing commit message, so it will be easy to create
> duplicate tags like [doc], [docs], [man], [manual] or [futon],
> [fauxton], [webui], [ui]. Also,
> the perfect spherical commit in a vacuum should contains multiple
> tags: docs, tests, affected component - with limitation of 54 chars
> for first commit line tags would eat a lot of space, making left short
> description useless.
>
> The solution I see quite simple: commit as we doing now. Additionally,
> setup some bot that will "tag" our commits with notes (hi, ASFBot!) -
> it should be easy since each component has his own path prefix (docs
> is in share/docs, tests are in tests/, replicator is in
> src/couch_replicator etc.) so we'll be free from this manual work. The
> only things we need to do, is update .git/config file with fetch =
> +refs/notes/*:refs/notes/* to getting notes from server without
> execution of additional git command.
>
> Thoughts?
I like Dirkjan’s idea of using `tag:` instead of `[tag]` even more.
I don’t think it is very bad if get multiple tags for the same thing.
`doc: foo` and `manual: foo` is equally easy to skip over and grep
out. But of course we should try to set a standard set and maintain
that on the wiki or in the docs.
To help with this, we could have pre-commit hooks locally that ensures
we use one of the defined tags.
Best
Jan
--
Re: [PROPOSAL] tag our commits
Posted by Alexander Shorin <kx...@gmail.com>.
On Mon, Oct 28, 2013 at 1:19 AM, Alexander Shorin <kx...@gmail.com> wrote:
> On Mon, Oct 28, 2013 at 1:12 AM, Dirkjan Ochtman <di...@ochtman.nl> wrote:
>> On Sun, Oct 27, 2013 at 10:00 PM, Alexander Shorin <kx...@gmail.com> wrote:
>>> There is no worry about since it's standard feature for git and
>>> supported by gitweb and github[1] as well.
>>
>> How about the IRC bots? And the email messages (both commit
>> notifications and PR notifications)?
>
> Hm..let's try to figure their support status(: I suppose nobody mind
> if I push one commit with notes?
Ok, there are three problems with notes:
1. Additional commit event without explicit association with related commit
2. GitWeb and GitHub doesn't[1][2] show any notices. However, if you
push notes to GitHub repo - it will
3. You should fetch notices in additional to regular clone/pull command
They are looks fine for automatic assignment build status, bug-id,
making notes on commit like postfactum review, forward references or
something else, but probably not for our case: tagging each commit
with affected component(s).
On other hand, tags inside commit message looks more weird[3] since
not everyone may follow this convention. These tags couldn't be
changed without editing commit message, so it will be easy to create
duplicate tags like [doc], [docs], [man], [manual] or [futon],
[fauxton], [webui], [ui]. Also,
the perfect spherical commit in a vacuum should contains multiple
tags: docs, tests, affected component - with limitation of 54 chars
for first commit line tags would eat a lot of space, making left short
description useless.
The solution I see quite simple: commit as we doing now. Additionally,
setup some bot that will "tag" our commits with notes (hi, ASFBot!) -
it should be easy since each component has his own path prefix (docs
is in share/docs, tests are in tests/, replicator is in
src/couch_replicator etc.) so we'll be free from this manual work. The
only things we need to do, is update .git/config file with fetch =
+refs/notes/*:refs/notes/* to getting notes from server without
execution of additional git command.
Thoughts?
[1]: https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commit;h=7fe76c9
[2]: https://github.com/apache/couchdb/commit/7fe76c9
[3]: https://github.com/dscape/nano/commits/master
--
,,,^..^,,,
Re: [PROPOSAL] tag our commits
Posted by Alexander Shorin <kx...@gmail.com>.
On Mon, Oct 28, 2013 at 1:12 AM, Dirkjan Ochtman <di...@ochtman.nl> wrote:
> On Sun, Oct 27, 2013 at 10:00 PM, Alexander Shorin <kx...@gmail.com> wrote:
>> There is no worry about since it's standard feature for git and
>> supported by gitweb and github[1] as well.
>
> How about the IRC bots? And the email messages (both commit
> notifications and PR notifications)?
Hm..let's try to figure their support status(: I suppose nobody mind
if I push one commit with notes?
--
,,,^..^,,,
Re: [PROPOSAL] tag our commits
Posted by Dirkjan Ochtman <di...@ochtman.nl>.
On Sun, Oct 27, 2013 at 10:00 PM, Alexander Shorin <kx...@gmail.com> wrote:
> There is no worry about since it's standard feature for git and
> supported by gitweb and github[1] as well.
How about the IRC bots? And the email messages (both commit
notifications and PR notifications)?
Sorry, I really don't see the value here.
Cheers,
Dirkjan
Re: [PROPOSAL] tag our commits
Posted by Alexander Shorin <kx...@gmail.com>.
On Mon, Oct 28, 2013 at 12:45 AM, Dirkjan Ochtman <di...@ochtman.nl> wrote:
> I.e. I think the "notes" thing is too non-standard and probably not
> supported as well by tooling.
There is no worry about since it's standard feature for git and
supported by gitweb and github[1] as well.
[1]: https://github.com/blog/707-git-notes-display
--
,,,^..^,,,
Re: [PROPOSAL] tag our commits
Posted by Dirkjan Ochtman <di...@ochtman.nl>.
On Sun, Oct 27, 2013 at 2:28 PM, Benoit Chesneau <bc...@gmail.com> wrote:
> other ? Another way to distinct the changes would also be to have all of
> these as subprojects eventually but it may require too much changes.
I like it, I'd vote for a minimally invasive/complex notation, like:
"docs: shizzle the wizzle"
"ui: flavor the widgets"
"http: response code galore"
I.e. I think the "notes" thing is too non-standard and probably not
supported as well by tooling.
Cheers,
Dirkjan
Re: [PROPOSAL] tag our commits
Posted by Andy Wenk <an...@nms.de>.
On 27 October 2013 18:05, Benoit Chesneau <bc...@gmail.com> wrote:
> On Sun, Oct 27, 2013 at 3:19 PM, Andy Wenk <an...@nms.de> wrote:
>
> > +1 for Benoits proposal.
> >
> > Regarding "best practices" or "subprojects" mentioned, I would like to
> > share what we do at work. We have destroyed the master branch from our
> main
> > applications. Our customer has around 5 bigger releases each year. So we
> > started to create the branches, 2013_april, 2013_july, 2013_september and
> > so on. These are our "main" branches we create feature branches from.
> > Merging is always possible from lower to higher month.
> >
> > So deriving from this scenario (what is surely different from CouchDB's
> > requirements) it "could" be an idea to create three main branches like
> > doc_master, ui_master and core_master in the same repository. On the
> other
> > hand, I guess most of the contributors to a git based project expect to
> > have a master branch.
> >
>
> mmm would work if we make different release for each components imo (which
> isn't bad idea - having a version for the doc and the ui - ). If we go for
> this path I would go for a different repo though. no need for submodules
> imo, a script that collect the result of each repo during a formal couchdb
> release would be enough.
>
that's maybe the better choice for the project
> > One thing to mention: please, don't use "submodules" because a lot of
> > people do not understand to handle them ;-)
> >
>
> uhu
at least this is the most misunderstood feature when new colleagues are
joining the team ;-)
git notes are ok for me but require an extra "git task after an commit"
(git notes add -m 'bla' 231a45e64)
Re: [PROPOSAL] tag our commits
Posted by Alexander Shorin <kx...@gmail.com>.
On Sun, Oct 27, 2013 at 9:05 PM, Benoit Chesneau <bc...@gmail.com> wrote:
> On Sun, Oct 27, 2013 at 3:19 PM, Andy Wenk <an...@nms.de> wrote:
>
>> +1 for Benoits proposal.
>>
>> Regarding "best practices" or "subprojects" mentioned, I would like to
>> share what we do at work. We have destroyed the master branch from our main
>> applications. Our customer has around 5 bigger releases each year. So we
>> started to create the branches, 2013_april, 2013_july, 2013_september and
>> so on. These are our "main" branches we create feature branches from.
>> Merging is always possible from lower to higher month.
>>
>> So deriving from this scenario (what is surely different from CouchDB's
>> requirements) it "could" be an idea to create three main branches like
>> doc_master, ui_master and core_master in the same repository. On the other
>> hand, I guess most of the contributors to a git based project expect to
>> have a master branch.
>>
>
> mmm would work if we make different release for each components imo (which
> isn't bad idea - having a version for the doc and the ui - ). If we go for
> this path I would go for a different repo though. no need for submodules
> imo, a script that collect the result of each repo during a formal couchdb
> release would be enough.
This approach looks fine until these components number is small and
you keeps their backward-compatibility well. Otherwise this will
create versions hell and makes users support very hard. A bit
experience from another open source project: Miranda IM/NG. This is
highly configurable multiprotocol IM with rich plugins system, but
Windows-only.
In Miranda IM there was used same version both for core and main
plugins. That was fine for a first sight, but since each module had
his own development history, that created versions mess: some modules
received massive version bump for several minor versions, some were
downgraded (as by version number). Also, this version now was used not
to track modules development history, but to bind them for specific
project release. In other words, plugin may receive minor version bump
while nothing had changed for him. Fake upgrades sometimes makes users
cry.
In Miranda NG project (new fork that keeps alive and rocks) we solved
this problem very nice: all plugins are stored within same repository
as main project itself and while plugins uses their own version
history, main project uses X.Y.Z.revision (it's svn thing) version to
easily figure for what repository state (aka commit) you have issues.
Also, we strongly do recommend to update plugins with core modules to
negotiate any possible problems. This really solves a lot problems
with compatibility and not only.
TL;DR to go on this path there is need to think twice for all possible
problems and how they could be solved with easy (e.g. plugins updater
helps much!).
P.S. s/plugins/submodules/ is you'd like to. I feel that after Rcouch
merge this question will be raised again.
--
,,,^..^,,,
Re: [PROPOSAL] tag our commits
Posted by Benoit Chesneau <bc...@gmail.com>.
On Sun, Oct 27, 2013 at 3:19 PM, Andy Wenk <an...@nms.de> wrote:
> +1 for Benoits proposal.
>
> Regarding "best practices" or "subprojects" mentioned, I would like to
> share what we do at work. We have destroyed the master branch from our main
> applications. Our customer has around 5 bigger releases each year. So we
> started to create the branches, 2013_april, 2013_july, 2013_september and
> so on. These are our "main" branches we create feature branches from.
> Merging is always possible from lower to higher month.
>
> So deriving from this scenario (what is surely different from CouchDB's
> requirements) it "could" be an idea to create three main branches like
> doc_master, ui_master and core_master in the same repository. On the other
> hand, I guess most of the contributors to a git based project expect to
> have a master branch.
>
mmm would work if we make different release for each components imo (which
isn't bad idea - having a version for the doc and the ui - ). If we go for
this path I would go for a different repo though. no need for submodules
imo, a script that collect the result of each repo during a formal couchdb
release would be enough.
>
> One thing to mention: please, don't use "submodules" because a lot of
> people do not understand to handle them ;-)
>
uhu
>
> Cheers
>
> Andy
>
> On 27 October 2013 14:58, Jan Lehnardt <ja...@apache.org> wrote:
>
> > +1
> >
> > Excuse the bikeshed, I’d prefer lowercase tags.
> >
> > Best
> > Jan
> > --
> >
> > On 27 Oct 2013, at 13:28 , Benoit Chesneau <bc...@gmail.com> wrote:
> >
> > > Hi all,
> > >
> > > I would like to propose that we start to tag our commits. The
> reasonning
> > > behind that is to distinct easily the changes concerning the doc, the
> ui
> > > and the core and filter them immediately and force us to make a change
> > > atomic. So I would like to propose that we tag the commit line with
> > >
> > > [DOC]
> > > [UI]
> > > [CORE]
> > >
> > > other ? Another way to distinct the changes would also be to have all
> of
> > > these as subprojects eventually but it may require too much changes.
> > >
> > > Thoughts?
> > >
> > > - benoit
> >
> >
>
>
> --
> Andy Wenk
> Hamburg - Germany
> RockIt!
>
Re: [PROPOSAL] tag our commits
Posted by Alexander Shorin <kx...@gmail.com>.
They are not only greppable, but also have builtin grouping:
git log --show-notes=component
will show only notes marked as "component" or
git log --show-notes=*
to show all available notes
--
,,,^..^,,,
On Sun, Oct 27, 2013 at 9:01 PM, Benoit Chesneau <bc...@gmail.com> wrote:
> On Sun, Oct 27, 2013 at 5:57 PM, Alexander Shorin <kx...@gmail.com> wrote:
>
>> On Sun, Oct 27, 2013 at 8:49 PM, Florian Westreicher Bakk.techn.
>> <st...@meredrica.org> wrote:
>> > How about using git notes? Messing up the commit message is a bad idea.
>>
>> Looks really good and better than [stuff]! Thanks for *note* (:
>>
>> Some related links about that I found interesting:
>> http://git-scm.com/2010/08/25/notes.html
>> https://www.kernel.org/pub/software/scm/git/docs/git-notes.html
>> http://alblue.bandlem.com/2011/11/git-tip-of-week-git-notes.html
>
>
> git notes look good if they are greppable (didn't test it yet). I thought
> to have this in the commit msg to make it visible but why not. Both methods
> are OK for me.
Re: [PROPOSAL] tag our commits
Posted by Benoit Chesneau <bc...@gmail.com>.
On Sun, Oct 27, 2013 at 5:57 PM, Alexander Shorin <kx...@gmail.com> wrote:
> On Sun, Oct 27, 2013 at 8:49 PM, Florian Westreicher Bakk.techn.
> <st...@meredrica.org> wrote:
> > How about using git notes? Messing up the commit message is a bad idea.
>
> Looks really good and better than [stuff]! Thanks for *note* (:
>
> Some related links about that I found interesting:
> http://git-scm.com/2010/08/25/notes.html
> https://www.kernel.org/pub/software/scm/git/docs/git-notes.html
> http://alblue.bandlem.com/2011/11/git-tip-of-week-git-notes.html
git notes look good if they are greppable (didn't test it yet). I thought
to have this in the commit msg to make it visible but why not. Both methods
are OK for me.
Re: [PROPOSAL] tag our commits
Posted by Alexander Shorin <kx...@gmail.com>.
On Sun, Oct 27, 2013 at 8:49 PM, Florian Westreicher Bakk.techn.
<st...@meredrica.org> wrote:
> How about using git notes? Messing up the commit message is a bad idea.
Looks really good and better than [stuff]! Thanks for *note* (:
Some related links about that I found interesting:
http://git-scm.com/2010/08/25/notes.html
https://www.kernel.org/pub/software/scm/git/docs/git-notes.html
http://alblue.bandlem.com/2011/11/git-tip-of-week-git-notes.html
--
,,,^..^,,,
Re: [PROPOSAL] tag our commits
Posted by "Florian Westreicher Bakk.techn." <st...@meredrica.org>.
How about using git notes? Messing up the commit message is a bad idea.
Jan Lehnardt <ja...@apache.org> wrote:
>Let’s not branch out the code just yet :)
>
>But tags are a good idea!
>
>Best
>Jan
>--
>
>On 27 Oct 2013, at 14:19 , Andy Wenk <an...@nms.de> wrote:
>
>> +1 for Benoits proposal.
>>
>> Regarding "best practices" or "subprojects" mentioned, I would like
>to
>> share what we do at work. We have destroyed the master branch from
>our main
>> applications. Our customer has around 5 bigger releases each year. So
>we
>> started to create the branches, 2013_april, 2013_july, 2013_september
>and
>> so on. These are our "main" branches we create feature branches from.
>> Merging is always possible from lower to higher month.
>>
>> So deriving from this scenario (what is surely different from
>CouchDB's
>> requirements) it "could" be an idea to create three main branches
>like
>> doc_master, ui_master and core_master in the same repository. On the
>other
>> hand, I guess most of the contributors to a git based project expect
>to
>> have a master branch.
>>
>> One thing to mention: please, don't use "submodules" because a lot of
>> people do not understand to handle them ;-)
>>
>> Cheers
>>
>> Andy
>>
>> On 27 October 2013 14:58, Jan Lehnardt <ja...@apache.org> wrote:
>>
>>> +1
>>>
>>> Excuse the bikeshed, I’d prefer lowercase tags.
>>>
>>> Best
>>> Jan
>>> --
>>>
>>> On 27 Oct 2013, at 13:28 , Benoit Chesneau <bc...@gmail.com>
>wrote:
>>>
>>>> Hi all,
>>>>
>>>> I would like to propose that we start to tag our commits. The
>reasonning
>>>> behind that is to distinct easily the changes concerning the doc,
>the ui
>>>> and the core and filter them immediately and force us to make a
>change
>>>> atomic. So I would like to propose that we tag the commit line with
>>>>
>>>> [DOC]
>>>> [UI]
>>>> [CORE]
>>>>
>>>> other ? Another way to distinct the changes would also be to have
>all of
>>>> these as subprojects eventually but it may require too much
>changes.
>>>>
>>>> Thoughts?
>>>>
>>>> - benoit
>>>
>>>
>>
>>
>> --
>> Andy Wenk
>> Hamburg - Germany
>> RockIt!
--
Sent from Kaiten Mail. Please excuse my brevity.
Re: [PROPOSAL] tag our commits
Posted by Jan Lehnardt <ja...@apache.org>.
Let’s not branch out the code just yet :)
But tags are a good idea!
Best
Jan
--
On 27 Oct 2013, at 14:19 , Andy Wenk <an...@nms.de> wrote:
> +1 for Benoits proposal.
>
> Regarding "best practices" or "subprojects" mentioned, I would like to
> share what we do at work. We have destroyed the master branch from our main
> applications. Our customer has around 5 bigger releases each year. So we
> started to create the branches, 2013_april, 2013_july, 2013_september and
> so on. These are our "main" branches we create feature branches from.
> Merging is always possible from lower to higher month.
>
> So deriving from this scenario (what is surely different from CouchDB's
> requirements) it "could" be an idea to create three main branches like
> doc_master, ui_master and core_master in the same repository. On the other
> hand, I guess most of the contributors to a git based project expect to
> have a master branch.
>
> One thing to mention: please, don't use "submodules" because a lot of
> people do not understand to handle them ;-)
>
> Cheers
>
> Andy
>
> On 27 October 2013 14:58, Jan Lehnardt <ja...@apache.org> wrote:
>
>> +1
>>
>> Excuse the bikeshed, I’d prefer lowercase tags.
>>
>> Best
>> Jan
>> --
>>
>> On 27 Oct 2013, at 13:28 , Benoit Chesneau <bc...@gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> I would like to propose that we start to tag our commits. The reasonning
>>> behind that is to distinct easily the changes concerning the doc, the ui
>>> and the core and filter them immediately and force us to make a change
>>> atomic. So I would like to propose that we tag the commit line with
>>>
>>> [DOC]
>>> [UI]
>>> [CORE]
>>>
>>> other ? Another way to distinct the changes would also be to have all of
>>> these as subprojects eventually but it may require too much changes.
>>>
>>> Thoughts?
>>>
>>> - benoit
>>
>>
>
>
> --
> Andy Wenk
> Hamburg - Germany
> RockIt!
Re: [PROPOSAL] tag our commits
Posted by Andy Wenk <an...@nms.de>.
+1 for Benoits proposal.
Regarding "best practices" or "subprojects" mentioned, I would like to
share what we do at work. We have destroyed the master branch from our main
applications. Our customer has around 5 bigger releases each year. So we
started to create the branches, 2013_april, 2013_july, 2013_september and
so on. These are our "main" branches we create feature branches from.
Merging is always possible from lower to higher month.
So deriving from this scenario (what is surely different from CouchDB's
requirements) it "could" be an idea to create three main branches like
doc_master, ui_master and core_master in the same repository. On the other
hand, I guess most of the contributors to a git based project expect to
have a master branch.
One thing to mention: please, don't use "submodules" because a lot of
people do not understand to handle them ;-)
Cheers
Andy
On 27 October 2013 14:58, Jan Lehnardt <ja...@apache.org> wrote:
> +1
>
> Excuse the bikeshed, I’d prefer lowercase tags.
>
> Best
> Jan
> --
>
> On 27 Oct 2013, at 13:28 , Benoit Chesneau <bc...@gmail.com> wrote:
>
> > Hi all,
> >
> > I would like to propose that we start to tag our commits. The reasonning
> > behind that is to distinct easily the changes concerning the doc, the ui
> > and the core and filter them immediately and force us to make a change
> > atomic. So I would like to propose that we tag the commit line with
> >
> > [DOC]
> > [UI]
> > [CORE]
> >
> > other ? Another way to distinct the changes would also be to have all of
> > these as subprojects eventually but it may require too much changes.
> >
> > Thoughts?
> >
> > - benoit
>
>
--
Andy Wenk
Hamburg - Germany
RockIt!
Re: [PROPOSAL] tag our commits
Posted by Jan Lehnardt <ja...@apache.org>.
+1
Excuse the bikeshed, I’d prefer lowercase tags.
Best
Jan
--
On 27 Oct 2013, at 13:28 , Benoit Chesneau <bc...@gmail.com> wrote:
> Hi all,
>
> I would like to propose that we start to tag our commits. The reasonning
> behind that is to distinct easily the changes concerning the doc, the ui
> and the core and filter them immediately and force us to make a change
> atomic. So I would like to propose that we tag the commit line with
>
> [DOC]
> [UI]
> [CORE]
>
> other ? Another way to distinct the changes would also be to have all of
> these as subprojects eventually but it may require too much changes.
>
> Thoughts?
>
> - benoit