Opened 4 years ago

Closed 4 years ago

#21781 closed enhancement (fixed)

Document workflow for maintaining spkg patch sets using "git format-patch"

Reported by: mkoeppe Owned by:
Priority: major Milestone: sage-7.5
Component: documentation Keywords:
Cc: dimpase, jdemeyer, vbraun, leif, fbissey, embray, tscrim, jpflori, jakobkroeker Merged in:
Authors: Matthias Koeppe Reviewers: Erik Bray
Report Upstream: N/A Work issues:
Branch: 67c6c0a (Commits) Commit: 67c6c0a1a51f5efbd2b41d0c1f33055e3bdbe1ec
Dependencies: Stopgaps:

Description (last modified by mkoeppe)

This patch extends the developers' manual with instructions on how to maintain a set of patches using git. It also explains when to patch, when to repackage.

Change History (17)

comment:1 follow-ups: Changed 4 years ago by dimpase

My biggest issue on #18920 was that git produces patches per commit, not per file (the latter was the original structure of patches in Sage, it seems).

A sane workflow in this case would be to maintain Sage patches as a branch for the Maxima git repo, that can be rebased against their updates. This would be then (semi)automatic to produce a new set of patches.

comment:2 in reply to: ↑ 1 Changed 4 years ago by mkoeppe

Replying to dimpase:

My biggest issue on #18920 was that git produces patches per commit, not per file (the latter was the original structure of patches in Sage, it seems).

Nothing wrong with that as far as I can see.

A sane workflow in this case would be to maintain Sage patches as a branch for the Maxima git repo, that can be rebased against their updates. This would be then (semi)automatic to produce a new set of patches.

Yes. Actually create a new branch before rebasing, so that the old branch is kept.

comment:3 in reply to: ↑ 1 Changed 4 years ago by jdemeyer

Replying to dimpase:

My biggest issue on #18920 was that git produces patches per commit, not per file (the latter was the original structure of patches in Sage, it seems).

One patch per file really makes no sense. One patch per commit makes a lot more sense.

comment:4 Changed 4 years ago by mkoeppe

  • Branch set to u/mkoeppe/document__git_format_patch__workflow

comment:5 Changed 4 years ago by mkoeppe

  • Authors set to Matthias Koeppe
  • Cc vbraun leif fbissey embray tscrim added
  • Commit set to 11bad093171defa9db0721b4b26fd2d8751bde1e
  • Description modified (diff)
  • Status changed from new to needs_review

New commits:

11bad09developer manual: Explain when and how to patch

comment:6 Changed 4 years ago by mkoeppe

  • Summary changed from Document "git format-patch" workflow to Document workflow for maintaining spkg patch sets using "git format-patch"

comment:7 Changed 4 years ago by mkoeppe

  • Cc jpflori jakobkroeker added

comment:8 Changed 4 years ago by mkoeppe

Needs review.

comment:9 follow-ups: Changed 4 years ago by jdemeyer

Please apply #21793 when writing documentation :-) You left some TABs.

Is there any package which actually uses the procedure explained in "How to maintain a set of patches"? It would be strange to document that as if it is standard practice, when in reality it is never done.

comment:10 in reply to: ↑ 9 Changed 4 years ago by dimpase

Replying to jdemeyer:

Please apply #21793 when writing documentation :-) You left some TABs.

Is there any package which actually uses the procedure explained in "How to maintain a set of patches"? It would be strange to document that as if it is standard practice, when in reality it is never done.

I am trying to follow this as I work on Maxima update in #18920, as we bring a number of upstream patches in.

comment:11 Changed 4 years ago by git

  • Commit changed from 11bad093171defa9db0721b4b26fd2d8751bde1e to 67c6c0a1a51f5efbd2b41d0c1f33055e3bdbe1ec

Branch pushed to git repo; I updated commit sha1. New commits:

67c6c0auntabify

comment:12 in reply to: ↑ 9 Changed 4 years ago by mkoeppe

Replying to jdemeyer:

Please apply #21793 when writing documentation :-) You left some TABs.

Done.

Is there any package which actually uses the procedure explained in "How to maintain a set of patches"? It would be strange to document that as if it is standard practice, when in reality it is never done.

Not fully yet.

  • I've created the SCIPoptsuite patches like this -- but I cannot use a public github for the changed SCIP sources because of its licensing.

comment:13 Changed 4 years ago by embray

Look good to me, thanks!

comment:14 Changed 4 years ago by mkoeppe

Is this a "positive review"?

comment:15 Changed 4 years ago by embray

  • Status changed from needs_review to positive_review

From me, yes, but I was going to wait for someone like Jeroen or Volker to sign off on this.

comment:16 Changed 4 years ago by embray

  • Reviewers set to Erik Bray

comment:17 Changed 4 years ago by vbraun

  • Branch changed from u/mkoeppe/document__git_format_patch__workflow to 67c6c0a1a51f5efbd2b41d0c1f33055e3bdbe1ec
  • Resolution set to fixed
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.