The biggest disappointment here is surely a missed opportunity to shoehorn a git and sap joke into this release. The utility should obviously be called `sap' and not `sl'.
`sl` is in the home row ;)
Sapling: A new source control system with Git-compatible client
111–120 of 543 posts
Re: Sapling: A new source control system with Git-compatible client
#112Earlier quoted context omitted.
Interesting -- I have the opposite impression, and we're both just simply staring at the same pile of distinctions and disagreeing on whether it 'resembles' the workload. I imagine this will be settled by git steamrolling sapling in the market, but I wonder if there's a faster (and less network-effected) way to adjudicate? Both your position and mine seem lodged in a taste/touch/feel context, which seems like a data-…
We know empirically that the staging area is a major pain point for users in practice, as discussed in https://investigating-archiving-git.gitlab.io/ The findings validate the earlier conceptual design analysis in practically all aspects: https://gitless.com/#research Git doesn't support certain workflows well. For example, how do you split the contents of the staging area into two separate groups? Sapling handles th…
Thanks arxanas! This is great empirical research that definitely takes precedence over any hunch, even my own ;D
One of my favourite parts of rationality is simply admitting that the data shows you're wrong
Re: Sapling: A new source control system with Git-compatible client
#113Earlier quoted context omitted.
Disclaimer: I work at Facebook. Your thought process is completely fair, but just to clarify: Phabricator was never open-sourced by Facebook. The main engineer behind Phabricator (Evan Priestley) left Facebook to create Phacility and open-source Phabricator; that was never a Facebook product.
Pretty sure that isn’t true. If memory serves, Evan open sourced Phabricator at Facebook back in 2010 or 2011, then quit to work on it full time. Shortly after (months, years?) the internal version of Phabricator diverged from the now not FB managed or stewarded OSS one. However I think it is fair to say, assuming my memory is correct, that Phabricator was open sourced by Facebook at a very different time, before the…
https://secure.phabricator.com/book/phabflavor/article/proje...
> left Facebook in April [2011], and shortly after, we open sourced Phabricator
Re: Sapling: A new source control system with Git-compatible client
#114Thank god. I have been waiting ten years ( https://www.google.com/url?q=https://stevebennett.me/2012/02... ) for someone to develop a better CLI for git, someone with the scale and clout to do it well and gain mindshare. It's not that useful to learn a new workflow if no one you ever work with will be familiar with it. This looks incredible. A simple command to uncommit or unamend makes you further realise what a dis…
My brain immediately jumped to "but you can just git reflog and then copy the state you want to revert to and then git reset --hard ", but not only is that not simple or obvious, it isn't even correct, since a commit or amend operation can be performed with only some of the changes staged, and a hard reset will wipe out anything unstaged. Ah sigh.
So yes, in short I agree.
Re: Sapling: A new source control system with Git-compatible client
#115Stack of commits seems to be similar to what one would call a patch queue if one is using Git.
The fact that they have concepts like unamend suggests that they have thought about this in a way more turtles all the way down way than the Git designers. A versioning for your history changes—why, of course.
Re: Sapling: A new source control system with Git-compatible client
#116> There is no staging area. That's actually a deal breaker to me. Effectively using Git's staging area has become so integral to the way I work with repositories that I don't think I can ever go back to the old style.
Meh. If it has mercurial's revsets instead of gitrevisions(7) I'm game, I'll happily give up the staging if I don't need to open that manpage ever again. edit: yep, so long git check if a given commit is included in a bookmarked release: sl log -r "a21ccf and ancestor(release_1.9)"
Mercurial revsets and phases are two killer features of mercurial that blows any counterpart git has out of the water.
Phases are a property of revisions that essentially let you know their state. By default, there are three phases: public, draft, and secret. You can't rebase a public revision, nor can you have a public revision with a secret parent. So you get out of this concept things like safe rebasing, or barriers that let you keep internal and external repos separate.
But revsets really shine. This is basically a full-on query language for revisions. So you can define a query alias "wip" that specifies all of the, well, interesting revisions: every revision that is not in the public phase (i.e., not in the upstream repo), the tip of the trunk, the current revision, and sufficient ancestor information of these revisions that you can see where you based all of these WIP branches on. In a single query: "(parents(not public()) or not public() or . or head())".
Sure, composing revsets is definitely a somewhat painful process... but it's possible to describe more or less arbitrary sets with a Mercurial revset, and I've never been able to find a similar workable setup in git.
Re: Sapling: A new source control system with Git-compatible client
#117Interesting execution. I'm not totally sold that Sapling is somehow forcing smaller/(more understandable) commits. Running Sapling restack with the manual step of an `amend` doesn't sound too different than running `git rebase -i` and moving the commits around. ReviewStack is interesting, but nothing new. It seems like it's removing the need to click through the commits page in GH by exposing it in a dropdown. IMO, the real improvement to our workflows will come from using better diff tools to make reviews more intuitive. I am biased of course :) (full disclosure: I work on DiffLens https://marketplace.visualstudio.com/items?itemName=DiffLens... )
Re: Sapling: A new source control system with Git-compatible client
#118Does it support commit signing? I spent a while reading the website and couldn't find anything suggesting it does. Lack of that is a showstopper for me (and frankly, should be a showstopper for anyone).
Re: Sapling: A new source control system with Git-compatible client
#119Earlier quoted context omitted.
It's worth pointing out: React[0]: JavaScript front-end web framework from Facebook. For good or ill, the most widely-used web framework in the world. Not to say that Facebook will maintain Sapling, but React does stand as proof that they're not incapable of carrying an open source project to the finish line. [0] https://github.com/facebook/react
Don't forget projects like PyTorch, Presto, etc.
zstd is fantastic, though I suppose it's not the sort of thing that particularly needs ongoing active maintenance.
Re: Sapling: A new source control system with Git-compatible client
#120Thank god. I have been waiting ten years ( https://www.google.com/url?q=https://stevebennett.me/2012/02... ) for someone to develop a better CLI for git, someone with the scale and clout to do it well and gain mindshare. It's not that useful to learn a new workflow if no one you ever work with will be familiar with it. This looks incredible. A simple command to uncommit or unamend makes you further realise what a dis…
I've been using lazygit[0] for a while, which might not be what you're looking for but I enjoy it a lot.