On Mon, 4 Aug 2008 13:29:47 +0200, "Bernd Jendrissek"
<[EMAIL PROTECTED]> wrote:
> On Mon, Aug 4, 2008 at 11:55 AM, Patrick Bernaud <[EMAIL PROTECTED]>
> wrote:
>> - The point of reviewing code before integrating it in the main tree
>> is to avoid "modify-then-fix" has much as possible. Until the
>> changes are integrated you are free to tweak your patches, in this
>> case to take into account the comments from my message.
>>
>> As a result, what we are expecting is a single 'perfect' patch for
>> your patches 1 and 2.
>
> Is this really necessary now that the repository is in git? You could
> have a mini-branch of patches no matter how egregious each individual
> change, as long as the final result is "perfect", and then *merge*
> that into master. This way master moves atomically from one "perfect"
> state to another "perfect" state, but the diff between the two states
> can still be decomposed into individual contributor patches (unlike
> CVS where you get only one big kilo-patch).
>
> Or is this use pattern discouraged (in gEDA)?
It's not discouraged, but it makes code reviews harder.
> My concern is that the flip side of the request for "perfect" patches
> is that it's quite inconvenient for the contributor to have to engage
> in the sort of Leninist rewriting of history that's required.
I agree -- patch revision can be quite hard with plain git. That's where
stgit comes in very handy!
Peter
_______________________________________________
geda-dev mailing list
[email protected]
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
