On Tue, Dec 8, 2020 at 8:18 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Elijah Newren <newren@xxxxxxxxx> writes: > > >> If I can run "git log --some-options master..next" (or more > >> realistically, over the range ko/next..next) to get individual > >> commits (without patch) and merges (only when --cc gives some > >> interesting nearby-changes), I would be very happy. But is there a > >> set of options that lets me do so? > > > > So, you're saying you changed your mind since five years ago?[1] Or > > that what you said five years ago is still valid, but you'd appreciate > > more/different options that allow this new thing? > > > > [1] https://lore.kernel.org/git/1440110591-12941-1-git-send-email-gitster@xxxxxxxxx/ > > Sorry, but I am not seeing in [1] anything that relates to the above > "want to see --cc patch for merge but just log message for single > parent commit". 5 years is a long time even in Git timescale, so I > would not be surprised if I changed my mind over time, but I am not > sure what opinion on the matter you think I expressed back then. > > "git log --cc master..next" shows all commits' log messages, patch > for each single-parent commit, and combined-dense patch for each > merge. There is no option to squelch the patch for only single > parent commits. It may not be such a bad thing to have as an extra > option. > > So, I think what I am saying is that ... > > > > ... As I said, I'm not sure why > > > anyone would ever want to see diffs for merges and not for normal > > > commits, the closest useful thing I can imagine is commit messages + > > > diffs for just merges, stripping the normal commits. > > ... I see use for such a feature (assuming that you didn't mean by > "diffs for merges" a regular "--first-parent -p" patch, but meant to > say "--cc" patch) in my workflow. I'd review "log ko/next..next" > before deciding to push out the day's integration of 'next', and at > that point, I trust individual commits that came from contributors > well enough (otherwise I wouldn't be merging them to 'next'), but I > would appreciate the last chance to re-examine conflict resolutions > in merges. > > It does not mean that I do not like the current behaviour that > "--cc" always implies "-p"; it is convenient. It's just I find the > lack of feature slightly less than ideal, but I do not care deeply > enough to design how to express such a feature from the command > line. Okay, thanks for clarifying. It sounds like you were focusing on the tangentially related comment I made (diffs for merges and not for normal commits) while I was focusing on Sergey's question (should we revert --cc implies -p). I was having a hard time understanding if you were answering his question or not. This last paragraph of yours acknowledges the question, though you still avoid answering it. :-) However, even my focus was on a secondary question. His real original question is: -m and --cc are inconsistent -- one requires -p, while the other doesn't. Should that be fixed...and which option(s) should change? He gave two possibilities I didn't like. I added a third that you didn't like. So...
