Spending $17 million to replace git

Phishfry said:
As a user Subversion did all I ever needed..
Click to expand...

Ya I used SVN, RCS, CVS and others....

At the moment I think GIT solves more problems than others.

But I also agree that there is (a lot) of GLUE being added to GIT functionality in a lot of places. Not sure if GIT should be the "bottom basement" of everyone else's "Grand House of Cards" application/system :cool:
 
The fatal issue of git is that it cannot have world monotonic commit serial (or version number) per project (repo). It makes unneededly tooooo hard to bisect things, unlike RCS, CVS and SVN (maybe oldest SCCS would be, too).

Yes, it would be "by design" to make distributed development easier.

But a functionality to assign single repo as "original upstream" and allow the exsitence of backup repos that cannot accept commits directly but keep 100% in sync with "original upstream" and can promote once current "original upstream" dissappears would allow assigning monotonic serial number by the "original upstream".
I've commented something alike this before.

Before, I've proposed to have external database that receives commit emails (or other notifications), assign monotonic version number (per repo or per branch) and keep the pair of monotonic version number and commit hash, but cannot find it in my "sent" email box. Possibly somewhere in Bugzilla PR or Phabricator review.
But "n*" for src was implemented differently. IIRC, it is based on git rev-list --count --first-parent.
This is clearly simpler, but having a drawback.
If any non-committer downstream (i.e., me) missingly commit to officially existing branch locally, the n-number should become different as upstream.
This should make interactions with others confusing.
 
I'm all for people who are capable of raising so much money. Good for them. I couldn't raise $0.50 to buy a loaf of bread if a were starving. Besides, this quote from the money-raisers is very interesting:
There was a tagline at GitHub that I always loved, but I never felt like we lived up to the promise of: “Social Coding”.
Click to expand...

That's what coding needs. It needs to be social. Let's code in group! Let's chill and code! Let's add selfies as comments!
 
It's funny that people now write frontends for git. At google we had git as a frontend for another VCS because it was much more convenient.
 
drhowarddrfine said:
A lot of people prefer mercurial, too.
Click to expand...
I used for a while Sapling that is a tool used in production from Meta and inspired to Mercurial, and I liked it a lot. Many features of Gitbutler seems present also in Sapling.

Meta has a rather complete approach: Sapling for the code; EdenFS for caching locally only the used parts of the code; Buck2 for rebuilding the code.
 
Phishfry said:
I still use portsnap auto because I don't want my ports tree overwritten.. I do lots of custom ports.

How to do that with git?
Click to expand...

You make a branch for your local changes and when main updates you rebase. You might have conflicts, but there is no method to avoid that.

If you never want to push changes anywhere you can also do it without branching and just committing to main. Rebase would be the same as in a branch.
 
Phishfry said:
I still use portsnap auto because I don't want my ports tree overwritten.. I do lots of custom ports.

How to do that with git?
Click to expand...
For customizing a mine old repo of Guix, I used Stacked Git and I liked it. Useful because you can: enable/disable various patches; reorder them; fold them; send upstream; signal when a patch is merged upstream; manage conflicts with upstream; etc..

The history of changes in your patches is kept in a log, so it is not so first-class citizen as having a Git branch, but all other aspects of patch management are very natural to use.

The paradigm of Stacked Git is similar (in some ways) to the mentioned Gitbutler tool and Sapling. You move patches in the stack.
 
Having used a bunch of different "code configuration things" over the years, they all suck at some (most) things and are tolerable at others. Size/scale/scope tends to bring out the bad things. Terminology also gets confusing when switching (that's why pictures of mainline, branching, merging, rebasing rule).
For me at $WORK git/gitlab is tolerable. Lots of lines of code, but few people working on it so it's easy to talk to each other.

I think one of the worst I've ever used (don't recall the name) was basically overlay filesystems based on what you checked out. Pain in the butt to try and actually look and compare things.

GitButler: sounds like a translation layer that makes it easier for a specific class (classes) of use cases. If they can get paid for it, good for them. Tech has always been full of vaporware
 
You must log in or register to reply here.
Back
Top