← Back to context

Comment by cryptonector

1 day ago

By having a naming convention for your tags and branches, then you can always identify the upstream "base" upon which the Debian "patches" are based, and then you can trivially use `git log` to list them.

Really, Git has a solution to this. If you insist that it doesn't without looking, you'll just keep re-inventing the wheel badly.

7 comments

cryptonector

Reply
blibble  1 day ago

but then if I want to see the history for a specific patch, or bisect them?

mercurial has a patch queue extension that married it and quilt, which was very easy to use

  • cryptonector  1 day ago

    Do you ever really want this? I don't recall wanting this. But you can still get this: just list the ${base_ref}..${deb_ref} commit ranges, select the commit you want, and diff the `git show` of the selected commits. It helps here to keep the commit synopsis the same.

    E.g.,

      c0=$(git log --oneline ${base_ref0}..${deb_ref0} |
         grep "^[^ ] The subject in question" |
         cut -d' ' -f1)
  c1=$(git log --oneline ${base_ref1}..${deb_ref1} |
         grep "^[^ ] The subject in question" |
         cut -d' ' -f1)
  if [[ -z $c0 || -z $c1 ]]; then
    echo "Error: commits not found"
  else
    diff -ubw <(git show $c0) <(git show c1)
  fi

    See also the above commentary about Gerrit and commit IDs.

    (Honestly I don't need commit IDs. What happens if I eventually split a commit in a patch series into two? Which one, if either, gets the old commit ID? So I just don't bother.)

  • IshKebab  9 hours ago

    I don't know that I've ever wanted to diff a diff, but you could do that still. And bisecting would still be possible, especially if you use merges instead of rebases.

    • cryptonector  1 hour ago

      Bisect rebases... you mean that you have two release branches based on divergent upstream branches and you want to quickly test where a bug was introduced on the way from the one to the other? What I would do in a rebase workflow is find the merge base (`git merge-base`) of the two release branches, and bisect from that to the release branch I'm interested in.