On Wed, May 11, 2016 at 10:34 AM, Kent Fredric wrote:
>
> There's an added security measure that exists /outside/ the gentoo
> source control.
>
It also fails differently.
If I find out that somebody compromised ssh in some way, doubt is cast
on any commit during the period in which the ssh serv
On 11 May 2016 at 22:21, Alexis Ballier wrote:
>
> yes, and it was meant to be :)
>
>
> my point was more that if we want signed commits, then better have
> author sign it, and thus use merge
Eh, I see it more a "signed commits don't really add any value to this
discussion".
Both signing on mast
On Wed, 11 May 2016 02:18:03 +1200
Kent Fredric wrote:
> On 11 May 2016 at 00:04, Alexis Ballier wrote:
> > well, then I can commit crap with --author m...@gentoo.org and claim
> > he made me rebase it :)
>
>
> Well, if you're going down that line ...
>
> You don't rebase it, you just merge
On 11 May 2016 at 00:04, Alexis Ballier wrote:
> well, then I can commit crap with --author m...@gentoo.org and claim he
> made me rebase it :)
Well, if you're going down that line ...
You don't rebase it, you just merge it, than then mrp claims obama
forced his hand to write the commit at gunp
On Mon, 9 May 2016 05:07:45 +1200
Kent Fredric wrote:
> On 9 May 2016 at 05:03, Alexis Ballier wrote:
> > I was under the impression that merging is needed in order to
> > preserve commit signatures when e.g. merging someone else's work.
>
>
> Correct, but if the person applying the commits
On Mon, May 9, 2016 at 8:36 AM, Kent Fredric wrote:
>
> While you can in theory rebase merge commits with rebase --preserve,
> my experience has shown me that its very difficult to get right, and
> the presence of merge collisions in the "preserved" rebase risks
> getting the conflict resolution l
On 10 May 2016 at 00:23, Rich Freeman wrote:
> which introduces some of the uncleanliness of non-rebased
> merge commits. In general I'm a fan of rebasing merge commits.
Non-rebased merge commits are worst when the merge involves a
collision resolution.
While you can in theory rebase merge co
On Mon, May 9, 2016 at 7:27 AM, Kristian Fiskerstrand wrote:
> On 05/08/2016 07:07 PM, Kent Fredric wrote:
>> On 9 May 2016 at 05:03, Alexis Ballier wrote:
>>> I was under the impression that merging is needed in order to preserve
>>> commit signatures when e.g. merging someone else's work.
>>
>>
On 05/08/2016 07:07 PM, Kent Fredric wrote:
> On 9 May 2016 at 05:03, Alexis Ballier wrote:
>> I was under the impression that merging is needed in order to preserve
>> commit signatures when e.g. merging someone else's work.
>
>
> Correct, but if the person applying the commits to tree is in fa
On 05/08/2016 05:53 AM, Brian Dolbec wrote:
> On Sun, 08 May 2016 11:06:09 +0100
> Amadeusz Żołnowski wrote:
>
>> I am working at the moment on debundling ejabberd. It will come with
>> ~30 packages and I will do "git merge --no-ff ejabberd-debundled"
>> because it will actually look less messy.
On 9 May 2016 at 05:03, Alexis Ballier wrote:
> I was under the impression that merging is needed in order to preserve
> commit signatures when e.g. merging someone else's work.
Correct, but if the person applying the commits to tree is in fact
reviewing them as they go, then the fact they re-si
On Sun, 8 May 2016 01:52:22 +0200
Patrice Clement wrote:
> After yet another discussion about git in the #gentoo-dev channel
> tonight, the topic of merge commits came up for the umpteenth time.
>
> We all seem to agree merge commits are really bad design, add clutter
> to the log graph after a
On Sun, 8 May 2016 05:53:42 -0700
Brian Dolbec wrote:
> It is these
> larger commit branches that are much more difficult to "git pull
> --rebase && git push --signed" successfully without some other pushes
> in between causing a rejected non-fast forward push.
You mean doing
until ; do ; done
On Sun, 08 May 2016 11:06:09 +0100
Amadeusz Żołnowski wrote:
> I am working at the moment on debundling ejabberd. It will come with
> ~30 packages and I will do "git merge --no-ff ejabberd-debundled"
> because it will actually look less messy.
>
> Thanks,
> -- Amadeusz Żołnowski
Yes, this is e
On 5/8/16 8:34 AM, Rich Freeman wrote:
> On Sun, May 8, 2016 at 8:18 AM, Kent Fredric wrote:
>> On 9 May 2016 at 00:09, Anthony G. Basile wrote:
>>> 1. announce to gentoo-dev@ the intention to start a branch intending to
>>> merge
>>>
>>> 2. hack hack hack
>>>
>>> 3. test the merge for any confli
On Sun, May 8, 2016 at 8:18 AM, Kent Fredric wrote:
> On 9 May 2016 at 00:09, Anthony G. Basile wrote:
>> 1. announce to gentoo-dev@ the intention to start a branch intending to
>> merge
>>
>> 2. hack hack hack
>>
>> 3. test the merge for any conflicts etc,
>>
>> 4. announce to the list a date/ti
On Sun, May 8, 2016 at 2:00 PM, Michał Górny wrote:
> No, he didn't. He stated an imaginary fact ('we all seem to agree...'), and
> asked how to *enforce* that formally. That's not how you request differing
> opinions.
He used "seem to" to state that it was his perspective, and asked
"What is t
On 9 May 2016 at 00:09, Anthony G. Basile wrote:
> 1. announce to gentoo-dev@ the intention to start a branch intending to
> merge
>
> 2. hack hack hack
>
> 3. test the merge for any conflicts etc,
>
> 4. announce to the list a date/time to merge
>
> 5. if okay, ermge
I think that's a bit excess
On 5/8/16 7:25 AM, Andreas K. Hüttel wrote:
> Am Sonntag, 8. Mai 2016, 01:52:22 schrieb Patrice Clement:
>>
>> What is the correct course of action? I would very much like it to be
>> worded in a document (GLEP and/or Wiki page) so that confusion is avoided
>> and we all are on the same page on thi
On 8 May 2016 at 23:57, Rich Freeman wrote:
> How does a merge make it any easier/harder to mess up the entire tree?
> I can see how they can make the history easier/harder to read but in
> the end I believe the content of the tree itself ends up being
> whatever was in the index when you made th
Dnia 8 maja 2016 12:30:15 CEST, Dirkjan Ochtman napisał(a):
>On Sun, May 8, 2016 at 7:09 AM, Michał Górny wrote:
>>> What is the correct course of action? I would very much like it to
>be worded in
>>> a document (GLEP and/or Wiki page) so that confusion is avoided and
>we all are
>>> on the same
On Sun, May 8, 2016 at 7:25 AM, Andreas K. Hüttel wrote:
>
> * However... as the past months have shown, when using merges it is much
> easier to accidentally mess up the entire tree than using rebases alone.
>
How does a merge make it any easier/harder to mess up the entire tree?
I can see how
Am Sonntag, 8. Mai 2016, 01:52:22 schrieb Patrice Clement:
>
> What is the correct course of action? I would very much like it to be
> worded in a document (GLEP and/or Wiki page) so that confusion is avoided
> and we all are on the same page on this topic.
>
OK here's my 2ct:
* I'm not opposed
On 08/05/16 12:13, Andreas K. Hüttel wrote:
> Am Sonntag, 8. Mai 2016, 07:09:31 schrieb Michał Górny:
>>> What is the correct course of action? I would very much like it to be
>>> worded in a document (GLEP and/or Wiki page) so that confusion is
>>> avoided and we all are on the same page on this t
Am Sonntag, 8. Mai 2016, 07:09:31 schrieb Michał Górny:
> > What is the correct course of action? I would very much like it to be
> > worded in a document (GLEP and/or Wiki page) so that confusion is
> > avoided and we all are on the same page on this topic.
>
> You start by accepting my retiremen
On Sun, May 8, 2016 at 7:09 AM, Michał Górny wrote:
>> What is the correct course of action? I would very much like it to be worded
>> in
>> a document (GLEP and/or Wiki page) so that confusion is avoided and we all
>> are
>> on the same page on this topic.
>
> You start by accepting my retireme
I am working at the moment on debundling ejabberd. It will come with ~30
packages and I will do "git merge --no-ff ejabberd-debundled" because it
will actually look less messy.
Thanks,
-- Amadeusz Żołnowski
signature.asc
Description: PGP signature
On 05/08/2016 01:21 AM, Greg KH wrote:
> On Sun, May 08, 2016 at 01:44:43PM +0800, cbergst...@pathscale.com wrote:
>> Don't be crazy - I know many developer groups which dislike merge
>> commits. That nonlinear work flow is just a mess long term.
>
> Really? What "mess" does it cause?
>
> Are th
Hi all,
On Sun, 8 May 2016 01:52:22 +0200 Patrice Clement wrote:
> Hi gents
>
> After yet another discussion about git in the #gentoo-dev channel tonight, the
> topic of merge commits came up for the umpteenth time.
>
> We all seem to agree merge commits are really bad design, add clutter to the
On Sun, May 08, 2016 at 01:44:43PM +0800, cbergst...@pathscale.com wrote:
> Don't be crazy - I know many developer groups which dislike merge
> commits. That nonlinear work flow is just a mess long term.
Really? What "mess" does it cause?
Are things harder to bisect? Harder to determine what ca
bject: Re: [gentoo-dev] On banning merge commits
On Sun, 8 May 2016 01:52:22 +0200
Patrice Clement wrote:
> Hi gents
>
> After yet another discussion about git in the #gentoo-dev channel tonight, the
> topic of merge commits came up for the umpteenth time.
>
> We all seem to
On Sun, 8 May 2016 01:52:22 +0200
Patrice Clement wrote:
> Hi gents
>
> After yet another discussion about git in the #gentoo-dev channel tonight, the
> topic of merge commits came up for the umpteenth time.
>
> We all seem to agree merge commits are really bad design, add clutter to the
> log
Hi gents
After yet another discussion about git in the #gentoo-dev channel tonight, the
topic of merge commits came up for the umpteenth time.
We all seem to agree merge commits are really bad design, add clutter to the
log graph after a while and should be banned altogether from reaching the
cen
33 matches
Mail list logo
