[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gpsd-dev] [PATCH 1/2] More 13-bit week number corrections.
From: |
Gary E. Miller |
Subject: |
Re: [gpsd-dev] [PATCH 1/2] More 13-bit week number corrections. |
Date: |
Fri, 15 Jul 2016 18:23:33 -0700 |
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
- [gpsd-dev] [PATCH 2/2] Fixes typo in logfile comment., (continued)
- [gpsd-dev] [PATCH 2/2] Fixes typo in logfile comment., Fred Wright, 2016/07/10
- Re: [gpsd-dev] [PATCH 1/2] More 13-bit week number corrections., Gary E. Miller, 2016/07/14
- Re: [gpsd-dev] [PATCH 1/2] More 13-bit week number corrections., Fred Wright, 2016/07/15
- Re: [gpsd-dev] [PATCH 1/2] More 13-bit week number corrections., Fred Wright, 2016/07/15
- Re: [gpsd-dev] [PATCH 1/2] More 13-bit week number corrections., Gary E. Miller, 2016/07/15
- Re: [gpsd-dev] [PATCH 1/2] More 13-bit week number corrections., Fred Wright, 2016/07/15
- Re: [gpsd-dev] [PATCH 1/2] More 13-bit week number corrections.,
Gary E. Miller <=
- Re: [gpsd-dev] [PATCH 1/2] More 13-bit week number corrections., Fred Wright, 2016/07/15
- Re: [gpsd-dev] [PATCH 1/2] More 13-bit week number corrections., Hal Murray, 2016/07/15
- Re: [gpsd-dev] [PATCH 1/2] More 13-bit week number corrections., Frank Nicholas, 2016/07/16
- Re: [gpsd-dev] [PATCH 1/2] More 13-bit week number corrections., Fred Wright, 2016/07/17