Re: New sync'd branch

[Stefan Monnier <monnier@iro.umontreal.ca>]

Can we please stop rehyashing this dicussion and get back to the
question at hand, which is about an Emacs-24 branch and how to do it?
Anyway, it seems that if we can get git-cvsserver, the main problem will
be solved.


        Stefan


>>>>> "Óscar" == Óscar Fuentes <ofv@wanadoo.es> writes:

> David Kastrup <dak@gnu.org> writes:
>> Óscar Fuentes <ofv@wanadoo.es> writes:
>> 
>>> Finally, git's UI is horrid: complex, barroque, with plenty of
>>> opportunities for shooting yourself on the feet.
>> 
>> But there is the reflog.  After shooting yourself in the foot, you
>> always have the option of going back to before the shot.
>> 
>> Yes, it is reasonably easy to blow up some operation terribly if you
>> don't know what you are doing.  Because git has lots of power.  But you
>> always can tell it: "Ok, this was a complete messup.  Give me back what
>> I had 20 minutes ago".

> I'll really apreciate a tool that does not make me waste those 20
> minutes.

> It's true that bzr is appreciably slower than git doing common
> operations: diff and annotate is intantaneous in git (on GNU/Linux),
> takes a few seconds on bzr. But when I screw my git setup, the time that
> takes me to fix it is much longer than the time I lost waiting for bzr.

>> It is very hard to actually do something which can't be undone.  You
>> have to really try.

> And this is different from other VCSs how?

>>> Those kernel guys are not the right people for designing UIs.
>> 
>> Which is why there are different user interfaces on top of the raw git.
>> git-gui does quite a few nice things, various Emacs modes as well.

> Agreed.

>>> Some day people will recognize this and will see today's massive
>>> leaning towards git as a mistake originated on juvenile reverence
>>> towards its original author and on simplistic metrics like raw speed,
>>> putting aside a critical and objetive assessment of its merits
>>> compared against the alternatives.
>> 
>> You underestimate git.  And you underestimate "people".  Torvalds
>> usually does several hundreds of merges a day.

> The typical Emacs developer is not like Torvads. Emacs has a development
> style that is very far from Linux's. Every example about how well git
> works specifically for Torvalds is moot.

>> And that's not just because of "raw speed", but also because of
>> high-quality merging strategies.

> git's mergin strategies are possibly superior to bzr, but do we (Emacs
> and most other Free projects) really need them? I think not.

>> Moving Emacs towards Bazaar was a real stress test for
>> Bazaar, and still is.

> This will be fixed over time. git's problems (mostly UI and poor support
> for non-POSIX environments) will not be solved anytime soon.

> [snip]

> -- 
> Óscar