On 08/11/13 08:48, Vincent van Ravesteijn wrote:
> In general it is better to not rewrite history if you're
> collaborating. I don't completely agree with the "_Never_".
>
> If you're sure you are the only one working on the feature, you can
> rewrite history every time you update. For example, if you want to
> have your feature merged with master, you want to have a nice series
> of commits. The maintainer won't agree with the merge if the series
> is full of rubbish commits just because you're not allowed to rewrite
> history because you once shared your work so that others can try it.
I was expecting something like that, indeed I've seen people publishing
patches through push -f even though there were many followers, and I ran
all the time into the hell of having to reset and can't remember what
else, in order to pull updates from the feature again. However, I also
understood that, as far as there's just one who is sharing a patch, this
seemed acceptable after all, to reach progressively a polished patch.
But, if others are contributing to the patch directly committing to the
repo, then it's not possible any more, unless you synch-up on rewriting
and polishing points with others, as you suggest.
In the case of the chat, there's a *minimum* set of changes to LyX,
whilst most of the stuff comes in separate files, so I guess we can
always squeeze the whole feature branch into a single patch at some point.
Otherwise, imagine we progressively add a few more features, such as:
-) automatic store and retrieve of user's password
-) better (more secure, i.e., encrypted) store and retrieve of user's password
-) minimum support for adding buddies
-) yes/no question for when others add you as a buddy, and accept/reject request
-) client-side encrypted chat messages
-) ...
and all of these end-up just into the new file(s), then what's the added value
of keeping these as separate patches ?
T.
