On Thursday, 9 February 2017 17:31:38 UTC-5, Philip Oakley wrote:
>
> Hi Stephen,
>
> There is another approach to merging, that is the 'imerge' tool [1], which
> does consider every commit on both sides of the merge.
>
> It was developed for the cases where the two branches have diverged in
I just successfully merged a pull request branch to our master branch, but
our release branch, which was branched from master a couple of weeks ago
(bad sign already) also needs those changes. The changes were small, so I
could easily do all this manually, but what are some reasonable technique
Hi Stephen,
There is another approach to merging, that is the 'imerge' tool [1], which does
consider every commit on both sides of the merge.
It was developed for the cases where the two branches have diverged in many
places.
The 'i' in 'imerge' is a reference to it creating an incremental i
On Thursday, February 9, 2017 at 5:58:56 PM UTC+1, Stephen Morton wrote:
>
> Thu, Feb 9, 2017 at 11:53 AM, Stephen Morton > wrote:
>>
>> On Thu, Feb 9, 2017 at 10:48 AM, Igor Djordjevic > > wrote:
>>
>>> On Thursday, February 9, 2017 at 3:47:09 PM UTC+1, Stephen Morton wrote:
On Thu, Fe
Thu, Feb 9, 2017 at 11:53 AM, Stephen Morton
wrote:
>
>
> On Thu, Feb 9, 2017 at 10:48 AM, Igor Djordjevic <
> igor.d.djordje...@gmail.com> wrote:
>
>> On Thursday, February 9, 2017 at 3:47:09 PM UTC+1, Stephen Morton wrote:
>>>
>>> On Thu, Feb 9, 2017 at 9:16 AM, Igor Djordjevic
>>> wrote:
>>>
On Thu, Feb 9, 2017 at 10:48 AM, Igor Djordjevic <
igor.d.djordje...@gmail.com> wrote:
> On Thursday, February 9, 2017 at 3:47:09 PM UTC+1, Stephen Morton wrote:
>>
>> On Thu, Feb 9, 2017 at 9:16 AM, Igor Djordjevic
>> wrote:
>>
>>> For example, single (resolved) merge commit (M):
>>>
>>> 1) A---
On Thursday, February 9, 2017 at 3:47:09 PM UTC+1, Stephen Morton wrote:
>
> On Thu, Feb 9, 2017 at 9:16 AM, Igor Djordjevic > wrote:
>
>> For example, single (resolved) merge commit (M):
>>
>> 1) A---B---C---D branchA
>> \ \
>> V---W---*M*---E branchB
>>
>> ... and conflicting merg
On Thu, Feb 9, 2017 at 9:16 AM, Igor Djordjevic wrote:
> On Thursday, February 9, 2017 at 2:31:33 AM UTC+1, Stephen Morton wrote:
>>
>> ... (My time is better spent perhaps helping answer other people's
>> questions on stackoverflow than helping somebody who, in a somewhat snarky
>> tone, asks me
On Thursday, February 9, 2017 at 2:31:33 AM UTC+1, Stephen Morton wrote:
>
> ... (My time is better spent perhaps helping answer other people's
> questions on stackoverflow than helping somebody who, in a somewhat snarky
> tone, asks me to explain my own question back to them.)
>
Please excuse m
Stephen Morton writes:
> - So, the question is: what is the best git-like way to a) record the
> merge in a proper way that will allow any subsequent merges to occur
> properly (most important) and additionally b) record the intermediate
> conflict fixing if possible.
You are aware of `rerere`
Cecil Westerhof writes:
> I had a talk yesterday with a company where they are using Subversion.
> The reason is that all there suppliers use Subversion. I understood it
> should be quit easy to communicate from Git with Subversion
> repositories. Is that true? Does anyone has any experiences to
Sharan Basappa writes:
> I have created a local branch, added few files and pushed them onto remote.
> When
> I pushed my changes for the first time, I used:
>
> #git push origin test1 - where test1 is the name of my branch
>
> Hereafter, I have made additional changes and just doing #git push.
12 matches
Mail list logo
