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

[Gary E. Miller]

Yo Fred!

You make it sound so simple.  :-)

Only 10 paragraphs on how to grab your patch, on top of what's already
been said.

As for the merges, I have been listening to Eric's rants on botched merges,
so I'm gonna go real slow on this...

Wouldn't it have been a lot easier to jsut resend the patch?

On Fri, 15 Jul 2016 18:14:39 -0700 (PDT)
Fred Wright <address@hidden> wrote:

> 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
> 




RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1 541 382 8588

pgpiRoRDzA9rp.pgp
Description: OpenPGP digital signature