On Wed, Dec 4, 2013 at 6:45 PM, Noah Slater wrote:
> Consolidating my replies to a single email so as to limit mail churn. :)
>
> On 4 December 2013 18:33, Benoit Chesneau wrote:
>
> > Having tags force naturally people to[...]
> > Having tags force people to[...]
>
> > If the system if it's opt
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 wrote:
> On Wed, Dec 4, 2013 at 6:33 PM, Noah Slater wrote:
>
Consolidating my replies to a single email so as to limit mail churn. :)
On 4 December 2013 18:33, Benoit Chesneau 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
On Wed, Dec 4, 2013 at 6:33 PM, Noah Slater 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
On Wed, Dec 4, 2013 at 5:47 PM, Noah Slater 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 usel
On Wed, Dec 4, 2013 at 5:42 PM, Jason Smith 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
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 wrote:
> Yea, same tag, but as word (:
> --
> ,,,^..^,,,
>
>
>
Yea, same tag, but as word (:
--
,,,^..^,,,
On Wed, Dec 4, 2013 at 8:56 PM, Dale Harvey wrote:
> "Document foo/bar config option"
>
>
> On 4 December 2013 16:54, Alexander Shorin wrote:
>
>> On other hand when you see commit message:
>>
>> Add foo/bar config option
>>
>> What is your first thou
"Document foo/bar config option"
On 4 December 2013 16:54, Alexander Shorin 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 m
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!
o
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
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
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,
-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 com
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 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 ne
>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 ti
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 commit
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 wrote:
> On Tue, Oct 29, 2013 at 9:29 AM, Benoit Chesneau wrote:
>
>>
>>>
>> My only objection to the `tag:` fomat is that this is not the way you t
On Tue, Oct 29, 2013 at 9:29 AM, Benoit Chesneau 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
On Mon, Oct 28, 2013 at 4:22 PM, Jan Lehnardt wrote:
>
> On 28 Oct 2013, at 16:07 , Alexander Shorin wrote:
>
> > On Mon, Oct 28, 2013 at 1:19 AM, Alexander Shorin
> wrote:
> >> On Mon, Oct 28, 2013 at 1:12 AM, Dirkjan Ochtman
> wrote:
> >>> On Sun, Oct 27, 2013 at 10:00 PM, Alexander Shorin
On 28 Oct 2013, at 5:22 PM, Jan Lehnardt wrote:
>
> On 28 Oct 2013, at 16:07 , Alexander Shorin wrote:
>
>> On Mon, Oct 28, 2013 at 1:19 AM, Alexander Shorin wrote:
>>> On Mon, Oct 28, 2013 at 1:12 AM, Dirkjan Ochtman wrote:
On Sun, Oct 27, 2013 at 10:00 PM, Alexander Shorin
wro
On 28 Oct 2013, at 16:07 , Alexander Shorin wrote:
> On Mon, Oct 28, 2013 at 1:19 AM, Alexander Shorin wrote:
>> On Mon, Oct 28, 2013 at 1:12 AM, Dirkjan Ochtman wrote:
>>> On Sun, Oct 27, 2013 at 10:00 PM, Alexander Shorin wrote:
There is no worry about since it's standard feature for g
On Mon, Oct 28, 2013 at 1:19 AM, Alexander Shorin wrote:
> On Mon, Oct 28, 2013 at 1:12 AM, Dirkjan Ochtman wrote:
>> On Sun, Oct 27, 2013 at 10:00 PM, Alexander Shorin wrote:
>>> There is no worry about since it's standard feature for git and
>>> supported by gitweb and github[1] as well.
>>
>>
On Mon, Oct 28, 2013 at 1:12 AM, Dirkjan Ochtman wrote:
> On Sun, Oct 27, 2013 at 10:00 PM, Alexander Shorin 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
> no
On Sun, Oct 27, 2013 at 10:00 PM, Alexander Shorin 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
On Mon, Oct 28, 2013 at 12:45 AM, Dirkjan Ochtman 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/7
On Sun, Oct 27, 2013 at 2:28 PM, Benoit Chesneau 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
On Sun, Oct 27, 2013 at 9:05 PM, Benoit Chesneau wrote:
> On Sun, Oct 27, 2013 at 3:19 PM, Andy Wenk 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
>>
On 27 October 2013 18:05, Benoit Chesneau wrote:
> On Sun, Oct 27, 2013 at 3:19 PM, Andy Wenk 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
> >
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 wrote:
> On Sun, Oct 27, 2013 at 5:57 P
On Sun, Oct 27, 2013 at 3:19 PM, Andy Wenk 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
On Sun, Oct 27, 2013 at 5:57 PM, Alexander Shorin wrote:
> On Sun, Oct 27, 2013 at 8:49 PM, Florian Westreicher Bakk.techn.
> 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 li
On Sun, Oct 27, 2013 at 8:49 PM, Florian Westreicher Bakk.techn.
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
How about using git notes? Messing up the commit message is a bad idea.
Jan Lehnardt 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 wrote:
>
>> +1 for Benoits proposal.
>>
>> Regarding "best practices" or
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 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 fro
+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
+1
Excuse the bikeshed, I’d prefer lowercase tags.
Best
Jan
--
On 27 Oct 2013, at 13:28 , Benoit Chesneau 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 a
+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 u
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
[DO
39 matches
Mail list logo
