Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sapling: A new source control system with Git-compatible client

engineering.fb.com

Post reply on HN
Print view View original

351–360 of 543 posts

Re: Sapling: A new source control system with Git-compatible client

#351

Post by bjarneh »

jordigh wrote: post #110

Ah, there it is. I was wondering when this would happen. Facebook used to be involved with the Mercurial community, but it was difficult to work with them. They always wanted to do things their way, had their own intentions, and started to demand that the Mercurial project work the way that Facebook wanted. For example, they demanded that we start using Phabricator and started slowly removing sequential revisions fro…

> and there are still those of us who actually use Mercurial

I'm certainly in that camp; and it pains me every time I have to use the hggit extension to convert a mercurial repo to git in order to work with everyone else...

Re: Sapling: A new source control system with Git-compatible client

#352

Post by arxanas »

sa1 wrote: post #339
arxanas wrote: post #35

Earlier quoted context omitted.

In those cases, I find it best to either 1) use the interactive commit tool to not commit debug junk, or 2) put the debug junk in its own commit, which I'll later discard (and, plus, that means you can't accidentally include it in a real commit).

I’ve never used one of the source control systems at these big companies but I use the staging area along with your git-branchless just fine for now. I’m not sure if it’s any less efficient this way.

It's not a big deal either way, but the staging area interacts worse with some operations. For example, if you have staged changes and then get a conflict with `git checkout --merge`, AFAIK there's no way to undo to before the conflict in Git. When using commits, all of the standard merge and undo tactics apply.

Re: Sapling: A new source control system with Git-compatible client

#353

Post by arxanas »

sixstringtheory wrote: post #347
arxanas wrote: post #74

Earlier quoted context omitted.

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…

> how do you split the contents of the staging area into two separate groups What is the workflow behind this ask? I don't understand what the goal is. The basic git workflow: 1. Edit and save a tracked file; the changes appear in the working tree. 2. Select some subset of the changes in the working tree to stage them in the index. 3. Form a commit with the changes in the index. IIUC you want to add a step in between…

To accomplish your workflow, there doesn't seem to be any need for a staging area at all. You can use an interactive commit selector to stage a subset of changes (or select a set of changes some other way), and then if you want to keep adding/"staging" changes, you can amend the commit you just made.

Occasionally, I do run into the situation where I've staged some changes and then realize that I want to start staging another commit first, but don't want to lose the changed I already staged. Unstaging my current changes means I have to remember and select them again later. I could also just commit what I have staged and start staging a new commit (and perhaps reorder the commits later), but that shows that the staging area was unnecessary in the first place, and I could have used commits to accomplish the same workflow without adding a new set of concepts to my VCS.

Re: Sapling: A new source control system with Git-compatible client

#354

Post by elric »

hgomersall wrote: post #118

Does 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).

There is a distinct lack of decent identity management/security in all of the version control systems I've used. It's a hard problem to solve, especially in a distributed/decentralized system (like git). Signing git-style commits is problematic in the face of merge conflicts or rebasing. A patch-style system (like Pijul) probably makes this easier: if everything is a patch, every patch can be signed atomically.

I'd really like to see a DCVS with better signing support and with some form of access control (on the remote), so every change can be traced back to the author, and so that some parts of a repo can only be modified by specific authors. Git hooks (on the remote) can sort of achieve the latter, but it's a bit of a pain.

Re: Sapling: A new source control system with Git-compatible client

#355

Post by physicsguy »

systemicdanna wrote: post #328
xyzzy_plugh wrote: post #294

Earlier quoted context omitted.

But they haven't done that yet. This is just the CLI, the centralized monorepo bits aren't yet available.

You could use Phabricator today.

"Effective June 1, 2021: Phabricator is no longer actively maintained."

Re: Sapling: A new source control system with Git-compatible client

#356

Post by _ZeD_ »

jakear wrote: post #198
stevage wrote: post #87

Thank 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…

Forget the CLI. VSCode implements a ton of git features as commands, which can be bound to any keybindings. For me this is way faster than CLI, as I don’t even need to leave my text editor - I have it set up chorded, so AltG followed by P,U,C,Y, will push (actually sync), pull, commit, undo, respectively. Two keystrokes beats any CLI interaction I’ve seen. (Disclaimer used to make VSCode)

dude, vscode git interface is ... not really good. I really continue to keep a copy of eclipse around just to use the egit client. That is a good UI ihmo

Re: Sapling: A new source control system with Git-compatible client

#357

Post by bmitc »

bogwog wrote: post #58
fhd2 wrote: post #24

Not a big fan of FB as a company, but I think their open source work is pretty impressive. Various other large companies have the problem of giant monorepos that they constantly need to onboard new developers to, but I can't think of anyone other than FB who consistently released their solutions. Sure, most people are probably fine with Git once they learned it and if they only work with small to mid sized code bases…

Facebook has a lot of interesting open source projects, but they tend to abandon them. As far as oss goes, I think Google is the best. As long as you don't mind dealing with 3 different custom build systems within the same codebase, their projects usually have dedicated teams maintaining them. ...and yes, I realize it's weird to say this considering Google is known for abandoning things. Maybe it's just coincidence t…

> As far as oss goes, I think Google is the best.

Better than Microsoft? I don't think I've ever been able to talk to a human at Google, whereas with Microsoft, I get feedback very quickly on issues and pull requests. Does Google even interact with people with open source? For example, I am using Skia via SkiaSharp, and the only place I know of to go for Skia help and issues is their Google Groups page, a website out of the 2000s. And very few seem to actually monitor the group. I'm not even really sure what Google does in open source. Even the things that are released to the public, like Skia, are well known to come with a huge amount of internal baggage.

Whereas Microsoft has dozens of active projects on GitHub where you can talk directly with the people working on it at Microsoft.

Re: Sapling: A new source control system with Git-compatible client

#358

Post by wocram »

durham_meta wrote: post #104
thijser wrote: post #96

Earlier quoted context omitted.

The GitHub repo says that Mononoke and EdenFS is "not yet supported publicly". The code seems to be all in the open source repository though, what does the "not supported" mean here?

The code is available to see, but they don't necessarily build in an external environment yet and even if they did we aren't ready to support them being used externally. Hopefully we can support them one day, but for now we're just starting with the client.

'one day' is not very reassuring!

Improved UX is nice and all, but why would anyone migrate without getting killer performance features like the virtual file system?

Re: Sapling: A new source control system with Git-compatible client

#359

Post by throwaway2037 »

anyfactor wrote: post #218
bogwog wrote: post #58

Earlier quoted context omitted.

Facebook has a lot of interesting open source projects, but they tend to abandon them. As far as oss goes, I think Google is the best. As long as you don't mind dealing with 3 different custom build systems within the same codebase, their projects usually have dedicated teams maintaining them. ...and yes, I realize it's weird to say this considering Google is known for abandoning things. Maybe it's just coincidence t…

How to not abondon a project? I would love to know that. This is my naive understanding. A for profit company open sources a project that they have been using and developing internally. The have built a philosophy and understanding of the project as they use and develop it. Most of their action regarding the project is that they must use it and they usually don't have any other options. Because the foundation is alre…

I like your post. It raises practical issues.

Idea for projects not owned by mega-corps (half real, half fantasy):

1. Get the project added as a package to one or more major commercial Linux distros, e.g., RedHat, etc.

2. Grant commit access to one or more devs at the same Linux vendor. Allow them to do whatever they want. You might not like their direction, but it should survive.

3. Retire from the project whenever you like.

4. Also, you could post a note in README about retiring. If people want to add features, ask them to fork, or just grant them commit access and let them go wild.

Re: Sapling: A new source control system with Git-compatible client

#360

Post by andrewshadura »

andrewshadura wrote: post #152
arxanas wrote: post #41

Earlier quoted context omitted.

Instead of `git add -p`, you would use `sl commit -i` (whose interface I much prefer). To amend into a previous commit, I prefer to switch to it and then just use `sl amend` (+ `sl restack` if necessary), but you can also use `sl fold` IIRC. Instead of `git rebase -i`, you can use `sl histedit` (not a direct replacement for autosquashing, but worth mentioning). To split a single commit, you can use `sl split`, which…

Consider also trying git-crecord, which is a port of he's curses-based partial commit interface.

Oh, I didn’t notice a typo — hg’s.
Post reply on HN