Earlier quoted context omitted.
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.
Isn’t this just git reset —soft HEAD~1? Put my stuff from the last commit back into working directory? Very unintuitive (soft?) and I’ve just memorized this for the past 10 years.
Sapling: A new source control system with Git-compatible client
441–450 of 543 posts
Re: Sapling: A new source control system with Git-compatible client
#442Hi Hacker News! Author of the Sapling blog post here. I'm happy to answer any questions you might have.
Thank you for answering questions. I was poking around Sapling and got thrown off track pretty quickly. Just wanted to init an empty repo but on an Intel MBP I just get an error: `abort: please use 'sl init --git .' for a better experience` What's going on here? I couldn't find info in the `sl init --help --verbose` output or in the Sapling website.
Because we haven't released the server yet, the open source client currently only really supports git right now, so sl init --git is the only way to init a local repo for now. Perhaps we could make that message clearer.
I'll take a look at the help later to see what we're missing here.
Re: Sapling: A new source control system with Git-compatible client
#443Earlier quoted context omitted.
Does sapling support hooks like pre and post commit? My workflow leans on pre-commit (the framework) heavily and it would be hard to give that up. I’d still be keen to take this for a drive though, nice work!
Technically the mercurial pre and post hooks are mostly still there, but I'm not certain we want to support them long term. The existing hook design has some problems. I'd be curious about your use case, since we don't actually use hooks internally all that much.
Not the OP, but I've worked on a bunch of projects which use https://pre-commit.com/ that ties into git pre-commit hooks (or https://typicode.github.io/husky/#/ is another)
usually to run linters and validators, speeding up the feedback loop (otherwise it's annoying to push changes to a PR and then get a CI failure minutes later for trivial linting issue)
Re: Sapling: A new source control system with Git-compatible client
#444Its interesting how these threads about Git simultaneously have (a) People arguing git is fine, and shouldn't be simplified (b) People arguing about the right way to use git, and flame wars about best git workflows I mean most people simply see (b) and conclude "this is a huge hassle, I don't want to annoy some git-workflow-purist, I'm just going to walk on eggshells on this tool and hope I don't break anything" It's…
obtuse software makes obtuse experts who hate obtuse newbies.
Re: Sapling: A new source control system with Git-compatible client
#445Earlier quoted context omitted.
> git and sap joke Non native here, could you explain? I know git is a slur and sap is the "tree blood", but are there other meanings I'm missing?
alternative meaning "a foolish gullible person" https://www.merriam-webster.com/dictionary/sap
Thanks!
Re: Sapling: A new source control system with Git-compatible client
#446Hi Hacker News! Author of the Sapling blog post here. I'm happy to answer any questions you might have.
A minor question...
https://sapling-scm.com/docs/introduction/installation/#maco...
The "download via curl and then install with homebrew" method struck me as unusual
Were there problems getting Homebrew bottle building/publishing work as you needed?
Re: Sapling: A new source control system with Git-compatible client
#447Earlier quoted context omitted.
Yes I’m well aware of the problems. I just seems to me that being PHP-like but incompatible is much more confusing than useful.
“PHP-like but incompatible” isn’t in itself a useful feature — it is the thing which unlocks a bunch of useful features (a sensible standard library, sensible list/dict datatypes, typed collections, XHP, async functions, generics)
I get that. A superset could be interesting. Downright incompatible seems to tip the balance the wrong way.
Re: Sapling: A new source control system with Git-compatible client
#448To use a similar featureset but in the same Git repository you normally use, you can try my https://github.com/arxanas/git-branchless . Then, you can use your usual staging workflows if desired, or use regular Git commands directly. Its design is inspired by Sapling, and, in fact, it uses some of the same code, such as the segmented changelog implementation. Possibly some of its ideas made their way back to Meta, suc…
> conflicts are stored in commits (so rebases always succeed)
Is this pushed to the remote when running as a git porcelain?
Re: Sapling: A new source control system with Git-compatible client
#449Hi Hacker News! Author of the Sapling blog post here. I'm happy to answer any questions you might have.
A minor question... https://sapling-scm.com/docs/introduction/installation/#maco... The "download via curl and then install with homebrew" method struck me as unusual Were there problems getting Homebrew bottle building/publishing work as you needed?
Yea, that's on our list to fix. The homebrew packaging was the last package to be done, and we were busy tidying up other things in the lead up to launch.
Re: Sapling: A new source control system with Git-compatible client
#450Earlier quoted context omitted.
My experience is the opposite. Most of the staunch Mercurial supporters came from CVS or SVN and found Mercurial to fit better into their preexisting mental model of source control. Users that started with Git are more likely to internalize Git's concepts as "the natural way to do version control", and more likely to find Mercurial counterintuitive.
Not my experience. As it happens, Mercurial and Git are very similar in terms of the "mental model" required to use them: history is just a DAG, and common operations consist of navigating the history and creating/editing/re-organizing commits. But where mercurial shines with a clean, consistent and simple UX, git is a mess where storage-layer abstractions leak to the user and where single commands serve multiple unr…
I really love git for the way it has taught me so many things by being so exposed. I love that you can easily use it as p2p, via email as a server or client, as a ci/cd solution. I love that you can easily inspect its model with cat. I love that while “branches” and “tags” seem special, you could just as easily use its “notes” or even just tack on your own ref system willy-nilly.
All this to say, I love git, and as a versioning system, it seems obvious to me that we can do better than git for 90% of workflows. Just yesterday I was surprised by how `git push --tags` worked and had to read the man page for `git-push` to see I wanted `git push --follow-tags`. Just reading this forum today I see that I alternately probably(?) could have figured out what I wanted with `git help push` which I didn’t even really realize was a thing.
But do I want to use an easier versioning system? I’m not sure. git has a kind of forcing function for a growth mindset. I value it for its creative expressivity.
Edit for sibling comment: Stockholm Syndrome, quite possibly. But as the “victim,” I still love git!