All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jacob Keller <jacob.keller@gmail.com>
To: Carl Baldwin <carl@ecbaldwin.net>
Cc: "Theodore Ts'o" <tytso@mit.edu>, Git Mailing List <git@vger.kernel.org>
Subject: Re: Bring together merge and rebase
Date: Tue, 26 Dec 2017 00:40:26 -0800	[thread overview]
Message-ID: <CA+P7+xpvuCjdnjyQxQg3B5iMwbnx-CerQMAP+bDQHR_-ALJOkQ@mail.gmail.com> (raw)
In-Reply-To: <20171226060229.GB18783@Carl-MBP.ecbaldwin.net>

On Mon, Dec 25, 2017 at 10:02 PM, Carl Baldwin <carl@ecbaldwin.net> wrote:
> On Mon, Dec 25, 2017 at 05:47:55PM -0800, Jacob Keller wrote:
>> On Mon, Dec 25, 2017 at 5:16 PM, Carl Baldwin <carl@ecbaldwin.net> wrote:
>> > Anyway, now I am compelled to use github which is also a fine tool and I
>> > appreciate all of the work that has gone into it. About 80% of the time,
>> > I rebase and force push to my branch to update a pull request. I've come
>> > to like the end product of the rebase workflow. However, github doesn't
>> > excel at this approach. For one, it doesn't preserve older revisions
>> > which were already reviewed which makes it is difficult for reviewers to
>> > pick up where they left off the last time. If it preserved them, as
>> > gerrit does, the reviewer can compare a new revision with the most
>> > recent older revision they reviewed to see just what has been addressed
>> > since then.
>>
>> A bit of a tangent here, but a thought I didn't wanna lose: In the
>> general case where a patch was rebased and the original parent pointer
>> was changed, it is actually quite hard to show a diff of what changed
>> between versions.
>>
>> The best I've found is to do something like a 4-way --cc merge diff,
>> which mostly works, but has a few awkward cases, and ends up usually
>> showing double ++ and -- notation.
>>
>> Just something I've thought about a fair bit, trying to come up with
>> some good way to show "what changed between A1 and A2, but ignore all
>> changes between parent P1 and P2 which you don't care that much about
>> in this context.
>
> I ran into this all the time with gerrit. I wrote a script that you'd
> run on a working copy (with no local changes). I'd fetch and checkout
> the latest patchset that I want to review(say, for example, its patchset
> 5) from gerrit. Then, say I wanted to compare it with patch set 3 which
> has a different parent. I'd run this from the top level of my working
> copy.
>
>     compare-to-previous-patchset 3
>
> It would fetch patch set 3 from gerrit, rebase it to the same parent as
> the current patch set on a detached HEAD and then git diff it with the
> current patch set. If there were conflicts, it would just commit the
> conflict markers to the commit. There is no attempt to resolve the
> conflicts. The script was crude but it helped me out many times and it
> was nice to be able to review how conflicts were resolved when those
> came up.
>
> Carl
>

Interesting. That could work fairly well. I usually do something along
the lines of:

git diff patch-new patch-old patch-base-new patch-base-old --cc, which
produces a combined diff format patch which usually works ok.

My biggest gripes are that the gerrit web interface doesn't itself do
something like this (and jgit does not appear to be able to generate
combined diffs at all!)

> PS In case you're curious, here's my script...
>
> #!/bin/bash
>
> remote=gerrit
> previous_patchset=$1; shift
>
> # Assumes we're sitting on the latest patch set.
> new_patch_set_id=$(git rev-parse HEAD)
>
> branch=$(git branch | awk '/^\*/ {print$2}')
> [ "$branch" = "(no" ] && branch=
>
> # set user, host, port, and project from git config
> eval $(echo "$(git config remote.$remote.url)" |
>        sed 's,ssh://\(.*\)@\(.*\):\([[:digit:]]*\)/\(.*\).git,user=\1 host=\2 p<
>
> gerrit() {
>     ssh $user@$host -p $port gerrit ${1+"$@"}
> }
>
> # Grabs a bunch of information from gerrit about the current patch
> eval $(gerrit query --current-patch-set $new_patch_set_id |
>     awk '
>         BEGIN {mode="main"}
>         / currentPatchSet:/ { mode="currentPatchSet" }
>         / ref:/ { printf "new_patch_ref=%s\n", $2 }
>         / number:/ {
>             if (mode=="main") {
>                 printf "review_num=%s\n", $2
>             }
>             if (mode=="currentPatchSet") {
>                 printf "new_patchset=%s\n", $2
>             }
>         }
>     ')
>
> # Fetch the old patch set
> old_patch_ref=${new_patch_ref%$new_patchset}$previous_patchset
> git fetch $remote $old_patch_ref && git checkout FETCH_HEAD
>
> # Rebase the old patch set to the parent of the new patch set.
> if ! git rebase HEAD^ --onto ${new_patch_set_id}^
> then
>     git diff --name-only --diff-filter=U -z | xargs -0 git add
>     git rebase --continue
> fi
>
> previous_patchset_rebased=$(git rev-parse HEAD)
>
> # Go back to the new patch set and diff it against the rebased old one.
> if [ "$branch" ]
> then
>     git checkout $branch
> else
>     git checkout $new_patch_set_id
> fi
> git diff $previous_patchset_rebased

One thing you might do is have it create a temporary worktree in order
to avoid problems with being in the local checkout.

Thanks,
Jake

  reply	other threads:[~2017-12-26  8:40 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-23  6:10 Bring together merge and rebase Carl Baldwin
2017-12-23 18:59 ` Ævar Arnfjörð Bjarmason
2017-12-23 21:01   ` Carl Baldwin
2017-12-23 22:09     ` Ævar Arnfjörð Bjarmason
2017-12-26  0:16       ` Carl Baldwin
2017-12-26  1:28         ` Jacob Keller
2017-12-26 23:30           ` Igor Djordjevic
2017-12-26 17:49         ` Ævar Arnfjörð Bjarmason
2017-12-26 19:44           ` Carl Baldwin
2017-12-26 20:19             ` Paul Smith
2017-12-26 21:07               ` Carl Baldwin
2017-12-23 22:19     ` Randall S. Becker
2017-12-25 20:05       ` Carl Baldwin
2017-12-23 23:01     ` Johannes Schindelin
2017-12-24 14:13       ` Alexei Lozovsky
2018-01-04 15:44         ` Johannes Schindelin
2017-12-25 23:43       ` Carl Baldwin
2017-12-26  0:01         ` Randall S. Becker
2018-01-04 19:49       ` Martin Fick
2017-12-23 22:30   ` Johannes Schindelin
2017-12-25  3:52 ` Theodore Ts'o
2017-12-26  1:16   ` Carl Baldwin
2017-12-26  1:47     ` Jacob Keller
2017-12-26  6:02       ` Carl Baldwin
2017-12-26  8:40         ` Jacob Keller [this message]
2018-01-04 19:19           ` Martin Fick
2018-01-05  0:31             ` Martin Fick
2018-01-05  5:09             ` Carl Baldwin
2018-01-05  5:20               ` Carl Baldwin
2017-12-26 18:04     ` Theodore Ts'o
2017-12-26 20:31       ` Carl Baldwin
2018-01-04 20:06         ` Martin Fick
2018-01-05  5:06           ` Carl Baldwin
2018-01-04 19:54     ` Martin Fick
2018-01-05  4:08       ` Carl Baldwin
2018-01-05 20:14       ` Junio C Hamano
2018-01-06 17:29         ` Carl Baldwin
2018-01-06 17:32           ` Carl Baldwin
2018-01-06 21:38           ` Theodore Ts'o
2017-12-27  4:35   ` Carl Baldwin
2017-12-27 13:35     ` Alexei Lozovsky
2017-12-28  5:23       ` Carl Baldwin
2017-12-26  4:08 ` Mike Hommey
2017-12-27  2:44   ` Carl Baldwin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CA+P7+xpvuCjdnjyQxQg3B5iMwbnx-CerQMAP+bDQHR_-ALJOkQ@mail.gmail.com \
    --to=jacob.keller@gmail.com \
    --cc=carl@ecbaldwin.net \
    --cc=git@vger.kernel.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.