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

[Simon Josefsson]

Thien-Thi Nguyen <address@hidden> writes:

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

You could push your fork to some git host like repo.or.cz, or setup
gitweb on your own site, although it doesn't strike me as ideal (what if
everyone creates their own gnulib fork on repo.or.cz?).

Alternatively, maybe you could get commit access to the gnulib project
and publish your work on a separate branch?  I'm not sure this is a good
idea, as it would lead to junk branches in the "official" repository.
Branches aren't costly to maintain, but there are limits to have large
the 'git-branch -a' output can get before people become annoyed.

However, git has git-format-patch which prepares patches in a way that
is easy to apply on the other side.  It might be simpler to fix the
MTA/ttn problem that munge diff's than working around that problem.

I'm also interested in the answer to your question, so if anyone else
has better ideas than mine I'm also curious.

/Simon