Re: [PATCH] Update doc "UPDATED" machinery.

[Thien-Thi Nguyen]

() Simon Josefsson <address@hidden>
() Thu, 19 Jun 2008 11:06:04 +0200

   > BTW, what is the prevailing advice if i want to publish a git
   > repo containing only diffs between upstream gnulib my
   > branches?  The goal is to make these branches available w/
   > minimal space/bandwidth cost.

   Do you really need to fork gnulib to do this?

I don't want to fork anything, unless that's the only way to
provide a lightweight gnulib-origin git repo for others to pull
from.  I would like to do my (ugly, not for polite company)
hacking locally and then publish only when things clear up.

   Gnulib supports project-specific changes using the --local-dir
   parameter. [...tips...] Thus, if you want to change gnulib for
   just one particular project, you are better of using the
   up-stream gnulib and having a local --local-dir directory with
   your local changes.

I don't want to change gnulib for just one particular project.
Thanks for those tips, but i don't think they are applicable to
what i want to do.

   Of course, it is better to merge your changes into the real
   gnulib.  If you've noticed a real problem, report that and it
   would hopefully be fixed.

Yes, that is what i want to do.  At the moment, to do so means:

- identify problem
- fix locally on a ttn-specific branch
- send email w/ diff
- loop:
  - get feedback
  - refix
  - send new email w/ new diff

I seek hints on how to modify that to be:

- identify problem
- fix locally on a ttn-specific branch
- push branch to (small footprint) public repo
- send email w/ pointer to repo, optionally w/ diff
- loop:
  - get feedback
  - refix
  - update public repo
  - send new email w/ notification of repo update

The motivation is to reduce errors and/or misunderstandings due to
some MTA (or, more likely, ttn) improperly munging the diff(s).
Supposedly git is amenable to this kind of interaction, so i'm
asking for help from experienced git users.

thi