Rich Freeman posted on Sun, 08 May 2016 08:34:37 -0400 as excerpted:
> merges shouldn't just be used for random pull-requests. However, when
> you're touching multiple packages/etc they should be considered. They
> should also be considered if for some reason you had a bazillion commits
> to a s
Rich Freeman posted on Sun, 08 May 2016 07:57:17 -0400 as excerpted:
> I think that bans are better used for bad attitude than for mistakes.
[Stepping back from the immediate discussion at hand...]
The above is wisdom, arguably, quotable sig-level wisdom!
Certainly wisdom enough to be worth emp
On Sun, May 8, 2016 at 11:25 AM, Kent Fredric wrote:
> The essential idea being to minimise the amount of congnitive effort a
> human has when trying to explore the history and understand what
> "actually happened" from a master perspective.
>
> "Long histories that go for days only to merge one c
Kent Fredric posted on Sun, 08 May 2016 21:25:38 +1200 as excerpted:
> On 8 May 2016 at 20:58, Duncan <1i5t5.dun...@cox.net> wrote:
>> Or to put it a different way, if we're not going to use git's rich
>> distributed branch development and tracking, forcing everything to
>> single chain on the mai
On 8 May 2016 at 20:58, Duncan <1i5t5.dun...@cox.net> wrote:
> Or to put it a different way, if we're not going to use git's rich
> distributed branch development and tracking, forcing everything to single
> chain on the main tree, why did we bother switching to git in the first
> place? That was
cbergstrom posted on Sun, 08 May 2016 13:44:43 +0800 as excerpted:
> Don't be crazy - I know many developer groups which dislike merge
> commits. That nonlinear work flow is just a mess long term.
Said by someone who apparently can't figure out reasonable quote then
reply-in-context, or even app
