Jonathan Nieder [off-list ref] writes:
Ramkumar Ramachandra wrote:
...
quoted
Good idea. I'll write a patch. Do we also want people to be able to
turn off `--no-merges`?
I don't see a need for it.
However, if you can think of good names for --undo-no-merges and
--undo-merges options to "git log", that might be a nice independent
change for the revision option parser.
Wait a bit. How would you represent a merge in a patch form that can be
read by "git apply" (and "patch") in the first place?
Hi Junio,
Junio C Hamano writes:
Jonathan Nieder [off-list ref] writes:
quoted
Ramkumar Ramachandra wrote:
...
quoted
Good idea. I'll write a patch. Do we also want people to be able to
turn off `--no-merges`?
I don't see a need for it.
However, if you can think of good names for --undo-no-merges and
--undo-merges options to "git log", that might be a nice independent
change for the revision option parser.
Wait a bit. How would you represent a merge in a patch form that can be
read by "git apply" (and "patch") in the first place?
Oh, I'm not attempting that. I merely wanted people to be able to turn
off `--no-merges` so they can get the current functionality.
As far as represeting merge commits go, I'm still thinking about it. I
talked to Thomas about it briefly on IRC. The main issues:
1. What's the point? When there's no conflict resolution, a merge
commit would be empty.
2. How do we uniquely specify what to merge? We can't use branch names
or commit SHA1s, because they can change.
-- Ram