proach (rather that each user having special branches
> on the master).
>
> Have you had a case of having to incoprporate incompatible code that you
> could share?
> Philip
>
> - Original Message -
>
> *Subject:* Re: [git-users] Git branching and merge strategy for merg
hilip
- Original Message -
From: Hugh Gleaves
To: Git for human beings
Cc: philipoak...@iee.org
Sent: Monday, February 06, 2017 7:46 PM
Subject: Re: [git-users] Git branching and merge strategy for merge with lots
of conflicts requiring multiple people
I suspect that you
I suspect that you are perceiving "merging" as a late, final step in the
process. This is where you are erring I think. Merging should be done
frequently, this was conflicts will not accumulate over time and grow in
scale.
Generally "merging" means incorporating changes made outside of some bra
Stephen Morton writes:
> On Thursday, 26 January 2017 16:37:16 UTC-5, Magnus Therning wrote:
>>
>>
>> Stephen Morton > writes:
>>
>> > I'm looking for a git branching and merge strategy for merge with
>> > lots of conflicts requiring multiple people. I can make it work,
>> > and I understand git
Michael writes:
>> Have you looked at git-imerge?
>
> Imerge looks like a really nice tool. How stable/sufficient is it? Why
> is it not part of the normal git distribution?
I've not had any problems with stability, but then I generally try to
avoid ending up in situations where it's needed ;)
On 2017-01-27, at 12:57 AM, Philip Oakley wrote:
>
> It doesn't happen at my work, but one has to ask how / why have we dug the
> hole so deep and wide that this gross merge conflict continues to repeat it
> self as a regular corporate activity, and then how to get out of here/there
> (and so
On Thursday, 26 January 2017 16:37:16 UTC-5, Magnus Therning wrote:
>
>
> Stephen Morton > writes:
>
> > I'm looking for a git branching and merge strategy for merge with lots
> > of conflicts requiring multiple people. I can make it work, and I
> > understand git, but it all seems kind of awkwa
cenarios, and a similar how
> and what for getting out.
>
> Philip
>
> If we don't understand, we won't improve ...
> https://store.xkcd.com/products/try-science
>
> ----- Original Message -----
> From: "Michael"
> To:
> Sent: Friday, Janu
t.
Philip
If we don't understand, we won't improve ...
https://store.xkcd.com/products/try-science
- Original Message -
From: "Michael"
To:
Sent: Friday, January 27, 2017 12:48 AM
Subject: Re: [git-users] Git branching and merge strategy for merge with
lots o
> Have you looked at git-imerge?
Imerge looks like a really nice tool. How stable/sufficient is it? Why is it
not part of the normal git distribution?
I noticed that it was still getting dev work this month, and in the last two
years a bunch of people forked copies of it, and made their own li
On 2017-01-26, at 1:12 PM, Philip Oakley wrote:
>
> Is the project well modularised with no file >100 lines (excepting, maybe,
> well developed libraries that never change),
100 lines per file??
You're joking, right? That's one of those "in theory" things, right?
First, while I might be able
On Thursday, 26 January 2017 16:12:43 UTC-5, Philip Oakley wrote:
>
> - Original Message -
>
> I'm looking for a git branching and merge strategy for merge with lots of
> conflicts requiring multiple people. I can make it work, and I understand
> git, but it all seems kind of awkward and
Stephen Morton writes:
> I'm looking for a git branching and merge strategy for merge with lots
> of conflicts requiring multiple people. I can make it work, and I
> understand git, but it all seems kind of awkward and it feels like
> there must be a better way.
>
> I've got a big git merge to d
- Original Message -
I'm looking for a git branching and merge strategy for merge with lots of
conflicts requiring multiple people. I can make it work, and I understand git,
but it all seems kind of awkward and it feels like there must be a better way.
I've got a big git merge to
I'm looking for a git branching and merge strategy for merge with lots of
conflicts requiring multiple people. I can make it work, and I understand
git, but it all seems kind of awkward and it feels like there must be a
better way.
I've got a big git merge to do. There are lots of conflicts and
15 matches
Mail list logo
