Re: Question about git log --merge option

[Andrey Hsiao]

Thanks Junio, I understand the option's meaning now :)

On Thu, Apr 14, 2016 at 4:37 AM, Junio C Hamano <gits...@pobox.com> wrote:
> Andrey Hsiao <andreyhs...@gmail.com> writes:
>
>> Dear list:
>>
>> Just encountered the --merge option for git log.
>>
>> In the man page, it has the following explanation:
>> - After a failed merge, show refs that touch files having a conflict
>> and don't exist on all heads to merge.
>
> git log --merge [options] -- $paths
>
> is roughly the same as
>
> git log [options] HEAD...MERGE_HEAD -- $paths'
>
> where $paths' is $paths limited to those with conflicts.  You can
> further think of that as a rough equivalent of
>
> git log [options] ^X HEAD MERGE_HEAD -- $paths'
>
> where X is the merge base between the tips of these two branches:
>
> X---o---o---o---H
>  \
>   o---o---o---M
>
> And the commits among these ('o's, H and M in the picture), the ones
> that change any of the $paths' are shown.  If you further limit the
> output (e.g. with -n, or --since=), you may not see all of
> them, of course.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Question about git log --merge option

[Andrey Hsiao]

Dear list:

Just encountered the --merge option for git log.

In the man page, it has the following explanation:
- After a failed merge, show refs that touch files having a conflict
and don't exist on all heads to merge.

I tried this option and get below results:

1. For a failed merge (with conflicts), if the conflicted file does
not exist on either side of the merge, the --merge option will return
the log from the other side.

2. If the conflicted file exists on both sides of the merge, the
--merge option will return the latest change on either side. (i.e: git
log -1 -- conflict_file / git log -1 --merge -- conflict_file may
return different results, whichever changed the latest)

I'm not sure whether above behavior is the unexpected result (cannot
find detailed explanation for --merge option online).

Thanks
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Git merge commit message issue

[Andrey Hsiao]

It was a bit sad since we use scripts to do the merge, then we can
check the conflict list in the log message, and assign to separate
owners to resolve them.

Would it be possible to make it as an config option?

On Tue, Jul 7, 2015 at 12:08 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
 Andrey Hsiao andreyhs...@gmail.com writes:

 Dear list:

 In the past, when we do the merge in git, if conflicts occurred,
 when we commit, the conflict list will be appended to
 the default commit message automatically.

 eg:
 Conflicts:
 a.java
 b.java

 Today, after using Git 2.3.0 for a merge, it seems now the conflict list
  was commented out by default.

 Yes, this changed here:

 https://github.com/git/git/commit/261f315bebfa9af2d09f20211960100ff06f87cb

 --
 Matthieu Moy
 http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Git merge commit message issue

[Andrey Hsiao]

Dear list:

In the past, when we do the merge in git, if conflicts occurred, when
we commit, the conflict list will be appended to the default commit
message automatically.

eg:
Conflicts:
a.java
b.java

Today, after using Git 2.3.0 for a merge, it seems now the conflict
list was commented out by default.

I just searched a bit in the release notes, don't know whether below
item has to do with this change.


git interpret-trailers learned to properly handle the Conflicts:
block at the end.


We quite rely on the default generated conflict list to reminder us
about the history.

Is this the default behavior now (conflict list commented out)?

Thanks
Best Regards
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Git merge commit message issue

[Andrey Hsiao]

Dear list:

In the past, when we do the merge in git, if conflicts occurred, 
when we commit, the conflict list will be appended to 
the default commit message automatically.

eg:
Conflicts:
a.java
b.java

Today, after using Git 2.3.0 for a merge, it seems now the conflict list
 was commented out by default.

I just searched a bit in the release notes, 
don't know whether below item has to do with this change.


git interpret-trailers learned to properly handle the Conflicts: 
block at the end.


We quite rely on the default generated conflict list 
to reminder us about the history.

Is this the default behavior now (conflict list commented out)?

Thanks
Best Regards

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html