I was trying to search the Git for Windows (G4W) history for commits that
touched MSVC.
I've used 'git log -SMSVC --pretty='tformat:%h (%s,
%ad)' --date=short --reverse' to get a nice list of those commits.
However, as the G4W project (https://github.com/git-for-windows/git/)
follows the main git repo and its releases, it needs to rebase it's fixup
patches, while retaining their original series, so has repeated copies of
those fix patches on the second parent path (a technique Dscho called
rebasing merges).
for example:
bf1a7ff (MinGW: disable CRT command line globbing, 2011-01-07)
a05e9a8 (MinGW: disable CRT command line globbing, 2011-01-07)
45cfa35 (MinGW: disable CRT command line globbing, 2011-01-07)
1d35390 (MinGW: disable CRT command line globbing, 2011-01-07)
022e029 (MinGW: disable CRT command line globbing, 2011-01-07)
How can I filter out all the duplicate patches which are identical other
than the commit date?
The --left --right and --cherry don't appear to do what I'd expect/hope. Any
suggestions?
--
Philip
On Tue, May 03, 2016 at 09:11:55PM +0100, Philip Oakley wrote:
However, as the G4W project (https://github.com/git-for-windows/git/)
follows the main git repo and its releases, it needs to rebase it's fixup
patches, while retaining their original series, so has repeated copies of
those fix patches on the second parent path (a technique Dscho called
rebasing merges).
for example:
quoted
bf1a7ff (MinGW: disable CRT command line globbing, 2011-01-07)
a05e9a8 (MinGW: disable CRT command line globbing, 2011-01-07)
45cfa35 (MinGW: disable CRT command line globbing, 2011-01-07)
1d35390 (MinGW: disable CRT command line globbing, 2011-01-07)
022e029 (MinGW: disable CRT command line globbing, 2011-01-07)
How can I filter out all the duplicate patches which are identical other
than the commit date?
The --left --right and --cherry don't appear to do what I'd expect/hope. Any
suggestions?
I don't think there's a good way right now. The option that suppresses
commits is --cherry-pick, but it wants there to be a "left" and "right"
from a symmetric difference, and to cull duplicates from the various
sides.
I think you really just want to keep a running list of all of the
commits you've seen and cull any duplicates. I guess you'd want this as
part of the history simplification step, so that whole uninteresting
side-branches are culled.
The obvious choice for matching two commits is patch-id, though it can
be expensive to generate. There have been patches playing around with
caching in the past, but nothing merged. For your purposes, I suspect
matching an "(author, authordate, subject)" tuple would be sufficient
and fast.
-Peff
Hi Philip,
On Tue, 3 May 2016, Philip Oakley wrote:
I was trying to search the Git for Windows (G4W) history for commits that
touched MSVC.
I've used 'git log -SMSVC --pretty='tformat:%h (%s, %ad)' --date=short
--reverse' to get a nice list of those commits.
However, as the G4W project (https://github.com/git-for-windows/git/)
follows the main git repo and its releases, it needs to rebase it's
fixup patches, while retaining their original series, so has repeated
copies of those fix patches on the second parent path (a technique Dscho
called rebasing merges).
Actually, I no longer use rebasing merges, but instead merging rebases.
The difference is a little subtle:
Rebasing merge:
- upstream ----- rebased-A - rebased-B - rebasing-merge (-s ours)
/
- old-A - old-B -----------------------
Merging rebase:
- upstream ----- merging-rebase (-s ours) - rebased-A - rebased-B
/
- old-A - old-B
Of course both diagrams are drastically simplified, as I do not only
rebase mere patches, but topic branches, including merge structure
(currently 44 IIRC), to make it easier to break out the topic branches for
easy submission later.
It turned out that the rebasing-merge strategy actually made things
harder, as it was not quite as easy to figure out *which* commits needed
rebasing (remember, new commits were added after rebasing-merges).
With merging-rebases, at least, one knows that the tree of the merge
commit starting the whole shebang is identical to upstream's tree. All of
the patches that come on top of that merge commit need to be rebased the
next time round, including new patches.
Fittingly, the commit message of said merge commit begins with the
following text: "Start the merging-rebase ..."
BTW The reason for this rather unwieldy setup is that we historically had
a hard time getting our patches into upstream Git (there was some degree
of resistance in the past, and also a quite limiting lack of time on my
part).
for example:
quoted
bf1a7ff (MinGW: disable CRT command line globbing, 2011-01-07)
a05e9a8 (MinGW: disable CRT command line globbing, 2011-01-07)
45cfa35 (MinGW: disable CRT command line globbing, 2011-01-07)
1d35390 (MinGW: disable CRT command line globbing, 2011-01-07)
022e029 (MinGW: disable CRT command line globbing, 2011-01-07)
How can I filter out all the duplicate patches which are identical other
than the commit date?
I would go about it in a completely different manner. Remember that the
merging rebase starts with a merge that integrates the previous history,
but also resets the tree to upstream's. Therefore all the commits merged
at the start of the merging-rebase are the ones in which you are *not*
interested.
In other words, this command-line will yield the output you desire:
git log -SMSVC --pretty='tformat:%h (%s, %ad)' --date=short \
HEAD^{/Start.the.merging-rebase}^2..
Ciao,
Dscho