Hello,

I personally dislike the focus on "rebase". Faking history is the trend.
People who ever used git are ashamed of committing code as they advance.
They would only make public fake history that shows what they think would
have been a "good development".

Of course, the usage of rebase usually involves the keeping of commit
logs, while they were meant for completely different trees. This, of
course, also destroys any chance of using bisect meaningfully.

I also dislike that branches are not part of the stored history, and
nothing can be checked about old branches (integrated, destroyed, etc).

For me it's also a hell to have to know the multiple heads of what in my
mind would be "one branch". Let's say master. I have the working
directory, the index, the local HEAD, the local version of the remote
HEAD, and the actual remote HEAD.

There are plenty of operations to move file content between any of those
FIVE stages (add, checkout, reset, commit, fetch, push).  In fossil there
is only the working directory and the branch head that you have to care
too.

As for graphical representation, if you look at gitk to have some notion
of branches, merges and forks... you quickly end up with 20 parallel
lines, some appearing some disappearing of multiple colours. Nothing my
brain can grasp easily.

Regards,
Lluís.


On Fri, May 15, 2015 at 02:14:47PM -0400, Richard Hipp wrote:
> I'm scheduled to give a talk in a few weeks at the Southeastern
> Linuxfest (http://www.southeastlinuxfest.org/) titled:  "Git: Just Say
> No!"  I have a good outline, but your input will still be appreciated.
> 
> The published description of the talk is:
> 
> Git is the most widely used version control system (VCS) for
> open-source projects. But it is also the most difficult to use, the
> most confusing, the most brittle, and the most likely to lose or
> mangle your work. This talk will review some of the problems with Git
> and offer suggestions on how those problems might be fixed. The talk
> will explain why developers ought to either use another (any other)
> VCS or else should be hounding the Git maintainers to fix its many
> shortcomings. (Full disclosure: The presenter is the lead programmer
> on a competing VCS.)
> 
> This is not a talk about Fossil, though my work on Fossil will
> certainly inform the talk.  I'm not planning to push or pitch Fossil -
> that would seem rude.  Nor do I intend to offer any criticisms of Git
> for which I will not also present specific solutions.
> 
> Below is a list of problems with Git that I intend to discuss, in
> priority order.  Please offer your help in reprioritizing and also
> suggest additional areas of deficiency.  If you have anecdotes,
> quotes, or case studies that I can share, that would be great too.
> Your help is much appreciated.
> 
> Current Problems With Git:
> 
> (1) Git will not show you the decendents of a check-in.  This seems to
> be a biggie and one that resonates even with staunch Git advocates.
> I'll spend a lot of time on it, getting down into the reasons why this
> is and offering a technical solution that could be added to libgit
> without too much effort.
> 
> (2) Multiple check-outs per repository.  How can you possibly get any
> work done when you can only have one branch open at a time?  Having
> multiple clones of the same project is a work-around, but not a
> particularly appealing one.
> 
> (3) A busybox version of Git - the entire VCS in a single binary that
> you just drop into your $PATH
> 
> (4) The ability to check-out and clone "slices" of a repository.  In
> other words, clone only selected subdirectories of a large project.
> (This is a capability that Fossil lacks too.)
> 
> (5) The ability to check-out from a remote repository.  (Fossil also
> omits this one.  But remember - this is a talk about Git and the
> future of open-source, not a talk about Fossil.)
> 
> (6) Simplified user interface.  Git has the user interface that
> everybody loves to hate.  Nobody except the most shrill Git partisan
> thinks that Git's user interface is good.  How to make it better?
> Start by removing or at least hiding the staging area.  (Readers:
> please offer other suggestions on how to improve the Git interface.
> Incompatible change ideas are welcomed.)
> 
> (7) Need a "git all" command analogous to "fossil all"
> 
> (8) Improved reporting for better situational awareness, in order to
> better serve the needs of agile programming.  Start with a built-in
> "git serve" command, analogous to "hg serve" and/or "fossil serve".
> (I will argue that "fossil serve" works way better than "hg serve"
> though I would love to hear contrary views from mercurial advocates.)
> Also needed is the ability to display a timeline of changes to
> individual files.
> 
> (9) New low-level Object format for Git.  One that is consistent, is
> utf8 text (not binary), easily read by humans and parsed by programs,
> and where the SHA1 hash assigned to files in the repository really is
> a SHA1 hash of the file.
> 
> -- 
> D. Richard Hipp
> d...@sqlite.org
> _______________________________________________
> fossil-dev mailing list
> fossil-dev@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev

-- 
(Escriu-me xifrat si saps PGP / Write ciphered if you know PGP)
PGP key D4831A8A - https://emailselfdefense.fsf.org/
_______________________________________________
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev

Reply via email to