Jeff King writes:
> On Mon, Mar 25, 2019 at 09:43:09AM +0300, Sergey Organov wrote:
>
>> How about changing "git show -p M" to output "diff -p M^ M" rather than
>> "diff-tree --cc M" for merge commits? It's really surprising specifying
>> -p has no visible effect.
>
> That's because "-p" is alrea
On Tue, Mar 26, 2019 at 3:20 PM Jeff King wrote:
>
> On Tue, Mar 26, 2019 at 03:07:42PM -0700, Elijah Newren wrote:
>
> > On Tue, Mar 26, 2019 at 9:35 AM Jeff King wrote:
> > >
> > > On Mon, Mar 25, 2019 at 09:43:09AM +0300, Sergey Organov wrote:
> > >
> > > > How about changing "git show -p M" t
On Tue, Mar 26, 2019 at 03:07:42PM -0700, Elijah Newren wrote:
> On Tue, Mar 26, 2019 at 9:35 AM Jeff King wrote:
> >
> > On Mon, Mar 25, 2019 at 09:43:09AM +0300, Sergey Organov wrote:
> >
> > > How about changing "git show -p M" to output "diff -p M^ M" rather than
> > > "diff-tree --cc M" for
On Tue, Mar 26, 2019 at 9:35 AM Jeff King wrote:
>
> On Mon, Mar 25, 2019 at 09:43:09AM +0300, Sergey Organov wrote:
>
> > How about changing "git show -p M" to output "diff -p M^ M" rather than
> > "diff-tree --cc M" for merge commits? It's really surprising specifying
> > -p has no visible effec
On Mon, Mar 25, 2019 at 09:43:09AM +0300, Sergey Organov wrote:
> How about changing "git show -p M" to output "diff -p M^ M" rather than
> "diff-tree --cc M" for merge commits? It's really surprising specifying
> -p has no visible effect.
That's because "-p" is already the default, and the forma
Junio C Hamano writes:
> Sergey Organov writes:
>
>> I think that "first-parent is special" is the way to go indeed for
>> porcelain, as it does make many thing easier and more convenient[*].
>
> Perhaps. However ...
>
>> [*] One example that immediately comes to mind is "git log -p" for a
>> m
On Wed, Mar 20, 2019 at 09:38:57AM +0900, Junio C Hamano wrote:
> "git log -p --first-parent" that requires "-m" to show the single
> ball of wax diff for a merge is a separate matter. When the user
> explicitly says "log --first-parent", it is a clear indication that
> the user does not want to
Sergey Organov writes:
> I think that "first-parent is special" is the way to go indeed for
> porcelain, as it does make many thing easier and more convenient[*].
Perhaps. However ...
> [*] One example that immediately comes to mind is "git log -p" for a
> merge commit. I doesn't currently (as
Hi Junio,
[It's been a while since this discussion, and recently I've got some
thoughts and questions about "first-parent" issues in general, below.]
Junio C Hamano writes:
> Sergey Organov writes:
>
>> When cherry-picking multiple commits, it's impossible to have both
>> merge- and non-merge
Sergey Organov writes:
> I came up with the following as a preparatory change. Looks acceptable?
>
> -- 8< --
>
> t3510: stop using '-m 1' to force failure mid-sequence of cherry-picks
>
> We are going to allow 'git cherry-pick -m 1' for non-merge commits, so
> this method to for
Sergey Organov writes:
> Junio C Hamano writes:
>
>> Sergey Organov writes:
>>
[...]
>>
>> The change to the code itself looks sane, but applying this patch
>> alone will break existing tests whose expectations must be updated,
>> and this new behaviour must be protected by a new test (or two
Junio C Hamano writes:
> Sergey Organov writes:
>
>> When cherry-picking multiple commits, it's impossible to have both
>> merge- and non-merge commits on the same command-line. Not specifying
>> '-m 1' results in cherry-pick refusing to handle merge commits, while
>> specifying '-m 1' fails on
Sergey Organov writes:
> When cherry-picking multiple commits, it's impossible to have both
> merge- and non-merge commits on the same command-line. Not specifying
> '-m 1' results in cherry-pick refusing to handle merge commits, while
> specifying '-m 1' fails on non-merge commits.
>
> This patc
Junio C Hamano writes:
> Sergey Organov writes:
>
>> When cherry-picking multiple commits, it's impossible to have both
>> merge- and non-merge commits on the same command-line. Not specifying
>> '-m 1' results in cherry-pick refusing to handle merge commits, while
>> specifying '-m 1' fails on n
Junio C Hamano writes:
> Sergey Organov writes:
>
>> When cherry-picking multiple commits, it's impossible to have both
>> merge- and non-merge commits on the same command-line. Not specifying
>> '-m 1' results in cherry-pick refusing to handle merge commits, while
>> specifying '-m 1' fails on
Sergey Organov writes:
> When cherry-picking multiple commits, it's impossible to have both
> merge- and non-merge commits on the same command-line. Not specifying
> '-m 1' results in cherry-pick refusing to handle merge commits, while
> specifying '-m 1' fails on non-merge commits.
Allowing "-m
When cherry-picking multiple commits, it's impossible to have both
merge- and non-merge commits on the same command-line. Not specifying
'-m 1' results in cherry-pick refusing to handle merge commits, while
specifying '-m 1' fails on non-merge commits.
This patch allows '-m 1' for non-merge commit
When cherry-picking multiple commits, it's impossible to have both
merge- and non-merge commits on the same command-line. Not specifying
'-m 1' results in cherry-pick refusing to handle merge commits, while
specifying '-m 1' fails on non-merge commits.
This patch allows '-m 1' for non-merge commit
18 matches
Mail list logo
