On Sat, Dec 29, 2012 at 9:20 AM, Lluís Batlle i Rossell
<vi...@viric.name> wrote:
> (top post, due to the complexity of the previous post)
>
> I've found many git-fans that are completely ashamed of how they develop. And
> they would never make public how they commit things (how they use the VCS), so
> they don't accept other VCS that hasn't git rebasing capabilities.
If yoiu manage a *large* project, something on the order of OS/Net
(the core of Solaris), say, then you need a clean tree for various
reasons:
- so maintenance of older releases is easier
The maintainers of older releases can pull and merge specific
fixes for specific bugs from the next-release branch.
Without clean trees this is a disaster: you've lost organization of
history, thus finding specific fixes -complete sets of commits for them-
is often then as hard as just re-doing the work of fixing the bug in
the first place.
- to make it easier for *other* developers to find what happened
later, when you're no longer around to ask questions of, or when
you've forgotten the details.
- to make it easier for reviewers to understand just what the heck
your patches are about ("this one fixes this one bug", "that one
adds this minor feature", ...)
And so on. Really. Large projects need order, they need process.
They need clean trees in official repos.
Project repos? Let them have whatever ugly, dirty history. Official
repos? No way.
Without a way to clean history prior to pushing to / pulling into
official repos a VCS is just hard to use effectively.
That's my last word on this for a while. Take. Or leave it.
Nico
--
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
