Thien-Thi Nguyen <[EMAIL PROTECTED]> 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
