From: Philip Oakley philipoak...@iee.org
From: Junio C Hamano gits...@pobox.com, Saturday, December 14,
2013 7:39 PM
Philip Oakley philipoak...@iee.org 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
Philip Oakley philipoak...@iee.org writes:
From: Philip Oakley philipoak...@iee.org
From: Junio C Hamano gits...@pobox.com, Saturday, December 14,
2013 7:39 PM
Philip Oakley philipoak...@iee.org writes:
Would this be a good use of the
* Magic pathspecs like :(icase)
that was recently
From: Junio C Hamano gits...@pobox.com, Saturday, December 14, 2013
7:39 PM
Philip Oakley philipoak...@iee.org 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
- Original Message -
From: Antoine Pelisse apeli...@gmail.com
snip
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
Antoine Pelisse apeli...@gmail.com 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
Philip Oakley philipoak...@iee.org 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
On Sat, Dec 14, 2013 at 8:33 PM, Junio C Hamano gits...@pobox.com wrote:
Antoine Pelisse apeli...@gmail.com 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
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
On Wed, Dec 11, 2013 at 11:04 AM, Paulo Matos pa...@matos-sorge.com 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
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
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
Paulo Matos pa...@matos-sorge.com 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,
12 matches
Mail list logo
