Re: [gpsd-dev] [PATCH 1/2] More 13-bit week number corrections.

[Fred Wright]

On Fri, 15 Jul 2016, Gary E. Miller wrote:
> On Fri, 15 Jul 2016 13:47:28 -0700 (PDT)
> Fred Wright <address@hidden> wrote:
>
> > > > Please consider using "git am" to apply emailed patches generated
> > > > with "git format-patch" (all of mine, at least).  This takes the
> > > > commit message directly from the email, which is both less work
> > > > and less error-prone than creating a new commit message from
> > > > scratch.  One can still add an SOB line with "-s" if desired.
> > > > This is the way Eric does it.
> > >
> > > Gack.  Email mungs patchs.  Which is why I had to manually apply.
> > > I like format-patch, but to really work it needs to be sent as an
> > > attachment.  Send you patchs as attachments and maybe I'll apply
> > > them as-is.
> >
> > It must be your email client that's doing the munging.
>
> At a minimum we know the gpsd-dev mail server is munging the
> subject.  The subject gets sucked into the git commit comment.

I thought it filtered out that portion.  I'll have to check.

BTW, the one time I have been screwed by email involved excessively long
lines, but "git send-email" (or maybe "git format-patch", I forget) was
smart enough to complain.  I just got Jon to fetch from my GitHub and push
the change(s).  It had to do with some regression-test data with humongous
lines.

> > An even cleaner approach is to fetch directly from my GitHub repo
> > (which doesn't require having a GitHub account).  Patches via email
> > are just sooo twentieth-century. :-) But so far the only one who's
> > taken patches that way is Jon.
>
> I guess I better learn how..
>
> >     git fetch https://github.com/fhgwright/gpsd +doc-fixes:fwpatch
>
> I did that:
>
>     pi2 gpsd # git fetch https://github.com/fhgwright/gpsd +doc-fixes:fwpatch
>     remote: Counting objects: 4, done.
>     remote: Compressing objects: 100% (3/3), done.
>     remote: Total 4 (delta 1), reused 1 (delta 1), pack-reused 0
>     Unpacking objects: 100% (4/4), done.
>     From https://github.com/fhgwright/gpsd
>      * [new branch]      doc-fixes  -> fwpatch
>     pi2 gpsd # git diff
>
> But nothing in the diff, nothing in git status, and nothing in git log.
>
> What did I do wrong?

You now have it in a new branch called fwpatch (and your working
directory and index are untouched so far).  It happens in this case
that there's only one new commit, so "git show fwpatch" will show you the
diff.  More generally, you can do things like "git log master...fwpatch",
"git show master...fwpatch", etc., provided that the tip of master is the
starting point.

The version of git here always reports the range of commits that it just
fetched, though I don't see that in your output.  That's handy since you
can just paste that commit range into "git log" or "git show" (or "git log
--oneline" for a compact version) to see what changes you fetched.

BTW, when merging changes of this form, it's usually preferable to use
"git cherry-pick" rather than "git merge", for a couple of reasons:

1) If the changes aren't fast-forwardable, "git merge" will create a merge
commit, which is usually not what's wanted in this context.  That can be
suppressed by using the --ff-only" option, in which case a
non-fast-forwardable merge will simply fail.

2) If the changes *are* fast-forwardable, then there's no opportunity to
add a SOB line, since the commits are taken verbatim.

However, "git cherry-pick" takes the specified commit(s) and applies
it/them as patches to the current HEAD, so it's just like "git am" but
with the source being commits instead of emails.  Adding "-s" includes the
SOB line in the process.  And it doesn't matter whether the patches are
referenced to the current HEAD, as long as they apply cleanly.

In this particular case, since there's only one new commit, you can simply
say (with the "master" branch checked out) "git cherry-pick -s fwpatch",
though in the more general case you might need a commit range.

After doing it, a simple "git show" will show what you just did, though
you'd need a range if you added multiple commits.  And if it's screwed up
in some fashion, you can undo the latest commit with "git reset --hard
HEAD~1" (replace the ~1 with a different number to drop multiple commits).

You can delete the new branch once the change is merged if you like.  It
needs "-D" rather than "-d" if it was merged via cherry-pick, since it
doesn't know that the reconsitituted changes were merged (it only allows
"-d" if it thinks that deleting the branch won't orphan any commits).

Also note that you can always make sure patches in this form are
referenced to the current "master" by, e.g., "git rebase master fwpatch".
That's a NOP if the patches are already based on the current master tip,
but otherwise updates all patches in the branch to the new master base,
and fails if the patches don't merge cleanly.  The nice thing about this
approach is that you can now refer to the entire patchset as
"master...fwpass" (for diffing, cherrypicking, or whatever), regardless of
how many commits it includes, or whether it was based on the latest master
at the time you fetched it.

> > That will give you a new branch "fwpatch" derived from my doc-fixes
> > branch (where the missing patch lives).  Then you can diff and/or
> > merge as usual.
>
> Well, maybe usual for you, I'm a bit lost...
>
> > If that doesn't work, I'll send an attachment, though the
> > non-attachment approach seems to be better for most people
> > (particularly when the sending email client insists on encoding the
> > attachment in a way that isn't directly viewable in some clients).
>
> The value to sending to the list is that more eyes get to see the patch.
> This is a lot more work for the casual lurker, and I don't have it
> working yet.

Usually when I've posted GitHub references, I've also posted the GitHub
diff URL, though I didn't do that this time.  The GitHub web interface
lets you see the combined diff or individual by-commit diffs, with or
without the full commit messages in the former case.  E.g.:

https://github.com/fhgwright/gpsd/compare/master...doc-fixes

This is kind of a degenerate case since it's only one commit, but note
that the ellipsis gadget to the right of the summary line is a toggle to
display the full commit message, and clicking on the commit ID at the
right of any summary line takes you to the single-commit view.

Fred Wright