"Philip Oakley" writes:
> From: "Philip Oakley"
>> From: "Junio C Hamano" , Saturday, December 14,
>> 2013 7:39 PM
>>> "Philip Oakley" writes:
>>>
Would this be a good use of the
* Magic pathspecs like ":(icase)
that was recently released (v1.8.5 2Dec13) so that the merge
>>
From: "Philip Oakley"
From: "Junio C Hamano" , Saturday, December 14,
2013 7:39 PM
"Philip Oakley" writes:
Would this be a good use of the
* Magic pathspecs like ":(icase)
that was recently released (v1.8.5 2Dec13) so that the merge
stages
can be named.
Because the pathspec mechahis
From: "Junio C Hamano" , Saturday, December 14, 2013
7:39 PM
"Philip Oakley" writes:
Would this be a good use of the
* Magic pathspecs like ":(icase)
that was recently released (v1.8.5 2Dec13) so that the merge stages
can be named.
Because the pathspec mechahism is for you to tell an op
On Sat, Dec 14, 2013 at 8:33 PM, Junio C Hamano wrote:
> Antoine Pelisse writes:
>
>> If you only want to see the diff applied to master, you
>> should run:
>>
>> $ git diff --ours
>
> Does "git diff HEAD" have the same/similar effect?
Yes, it does produce the same output as --ours.
>> You
"Philip Oakley" writes:
> Would this be a good use of the
>* Magic pathspecs like ":(icase)
> that was recently released (v1.8.5 2Dec13) so that the merge stages
> can be named.
Because the pathspec mechahism is for you to tell an operation that
works on a collection of paths (e.g. "all th
Antoine Pelisse writes:
> If you only want to see the diff applied to master, you
> should run:
>
> $ git diff --ours
Does "git diff HEAD" have the same/similar effect?
> You can also have a look at what is currently being applied:
>
> $ git diff :1:gcc/tree-ssa-threadedge.c :3:gcc/tree
- Original Message -
From: "Antoine Pelisse"
You can also have a look at what is currently being applied:
$ git diff :1:gcc/tree-ssa-threadedge.c
:3:gcc/tree-ssa-threadedge.c
By the way, does anybody know a better way to do that ? I happen to do
that quite a lot when fixing c
On Wed, Dec 11, 2013 at 12:19 PM, Paulo Matos wrote:
> On 11/12/2013 11:09, Antoine Pelisse wrote:
>>>
>>>
>>> I don't know how to interpret the fact that the line you sent (with the
>>> obvious --conflicts being --conflict) outputs nothing...
>>
>>
>> That is expected. git-checkout with this opti
On 11/12/2013 11:09, Antoine Pelisse wrote:
I don't know how to interpret the fact that the line you sent (with
the
obvious --conflicts being --conflict) outputs nothing...
That is expected. git-checkout with this option [1] will reset the
conflict on gcc/tree-ssa-threadedge.c file to the in
On Wed, Dec 11, 2013 at 11:04 AM, Paulo Matos wrote:
> On 10/12/2013 19:34, Junio C Hamano wrote:
>>
>> Perhaps immediately after "cherry-pick" stopped and asked your help
>> to resolve the conflicts, running
>>
>> $ git checkout --conflicts=diff3 gcc/tree-ssa-threadedge.c
>>
>> and lookin
On 10/12/2013 19:34, Junio C Hamano wrote:
Perhaps immediately after "cherry-pick" stopped and asked your help
to resolve the conflicts, running
$ git checkout --conflicts=diff3 gcc/tree-ssa-threadedge.c
and looking at the file again may show you what is going on better.
I don't know
Paulo Matos writes:
> Note how there are changes that are not part of the cherry-picked
> patch outside of the conflicting zone. This is trouble some because it
> means that when I go in to fix a patch and look only at the
> conflicting zone, I will have code outside the zone, that are _not_
> pa
Hi,
I have installed latest 1.8.5.1 git to confirm the behaviour I had seen
in previous versions.
What I see is that when I cherry-pick a patch across two branches
(source and destination) in a repository, cherry-pick picks changes from
the source branch which do not exist in the cherry-pick
13 matches
Mail list logo
