rethinking patch management with GIT / topgit

[Manoj Srivastava]

On Sun, Mar 28 2010, Petr Baudis wrote:

> On Sun, Mar 28, 2010 at 09:40:45AM -0700, Manoj Srivastava wrote:
>> On Sun, Mar 28 2010, Enrico Weigelt wrote:
>> > Usually, you have only one person or very few ones working very
>> > closely together per package. So that shouldnt hurt so much that
>> > it's worth all the complexity.
>> 
>>         False assumption: it might be the case for you that you work in
>>  a small team, and know all people who base their work on yours, and
>>  perhaps you package for a leaf distribution.
>> 
>>         None of those hold in my case.
>
> My original motivation for TopGit development was that I actually was
> the _only_ developer, but I needed to maintain and develop in multiple
> clones in a sensible way.
>
> Maybe you are happy doing things your way, but I'm trying to explain why
> many people aren't.

        I have no objection to people preferring different workflows than
 the one I use, as long as they do not tell me that mine is irrelevant,
 obsolete, or otherwise incorrect. (and I am missing the email that I
 have commented on in the thread where you, and not Enrico, is
 explaining their workflow, so I might be somewhat off base here).

        To come to your email, are you stating that TopGit is designed
 for people working alone, or in small teams, and not publishing their
 branches for other people to work on? If that is the case, it is
 certainly a valid use case, but certainly not universal; and might not
 be suited for a chain of repositories where several distribution
 package maintainers derive from the work on their immediate upstream
 distribution.

        manoj
-- 
Quote from the Boss..."I didn't say it was your fault.  I said I was
going to blame it on you."
Manoj Srivastava <srivasta at acm.org> <http://www.golden-gryphon.com/>  
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C