Re: [PATCH v3 00/33] Add directory rename detection to git

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Elijah Newren <newren@xxxxxxxxx> writes:

> Interesting; tbdiff looks cool.  Junio hasn't queued this series yet,
> but it's easy enough to reconstruct the old one.  It does weigh in
> pretty heavy, and I'm slighly worried about gmail mangling all the
> lines, but I'm going to give it a shot anyway.  If it's too mangled,
> I'll try to repost using git-send-email.  It does weigh in at over
> 1600 lines, so it's not small.

It seems that you have installed tbdiff correctly.  The below seems
to match what I saw when I queued this round, relative to the
previous one.

What I often do when I see a new round of patches is:

    $ git checkout en/rename-directory
    $ git checkout master... ;# detach at the base of the old
    $ git am -s mbox ;# take the new 
    $ git tbdiff ..@{-1} @{-1}..

to compare the old and new.  Often (but not with this topic) earlier
parts of the topic are identical between the old and the new, so I
may rebase the new to preserve the commit timestamp of the old one
when it happens after the above sequence of commands.  For example,
if I see these in tbdiff

    1: 7893bf1720 = 1: f17207893b commit #1
    2: c291293b2e = 2: 93b2ec2912 commit #2
    3: a7d3c870a3 ! 3: 87b5e236a1 commit #3
        @@ ... @@@

then we know up to commit #2 are the same as before, so I'd do

    $ git rebase --onto c29129eb2e 93b2ec2912

by using the two commit object names on the last "=" line in the
output.  Then, running the same tbdiff again:

    $ git tbdiff ..@{-1} @{-1}..

would now show the output starting from "commit #3".



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux