[HN Gopher] Sapling: A new source control system with Git-compat...
___________________________________________________________________
Sapling: A new source control system with Git-compatible client
Author : bolinfest
Score : 361 points
Date : 2022-11-15 17:39 UTC (5 hours ago)
(HTM) web link (engineering.fb.com)
(TXT) w3m dump (engineering.fb.com)
| ianlevesque wrote:
| It's hard to overstate how much better this workflow is UX-wise
| than the git(hub) default. I'm super excited to see it open
| sourced.
| 1attice wrote:
| I'm not interested in a simplification of git, sorry.
|
| Git's major value proposition is that they _added moving parts
| until the system worked great_. If you don 't want named
| branches, staging, or any other piece of the ideology, then
| subversion is a fine choice.
|
| But most folks moved on from svn for reasons
| pjmlp wrote:
| Reasons being the projects that found cool to use git, because
| Linus made it, and now regardless of my opinion, I have to deal
| with git.
| 1attice wrote:
| Despite the greytexting of this comment, I'm still really
| interested in the discussion around it -- and I'm really
| curious to hear from people that have the opposite experience.
|
| Moving from SVN to git felt like liberation because there were
| suddenly idiomatic ways of expressing states that were sort of
| smushed together by SVN -- stuff like, "I have some changes in
| my branch I want to line up for commit" which, became the handy
| one-word concept, "staging".
|
| The before-times were marked by a lack of these fine
| distinctions. While they existed in fact, they were obscured
| in-system.
|
| Like a map, any tool should 'resemble' the sphere of human
| activity it potentiates, and git resembles our diverse
| workflows better _because it has so many asinine distinctions_.
|
| This was always its strength, and indeed, likely the reason the
| platform is called 'git' in the first place, as 'smarmy git'
| (English idiom for 'smartass') implies an insufferable drawer-
| of-distinctions.
|
| And like a smarmy git, it's easier to complain about git than
| it is to replace it.
| arxanas wrote:
| In my opinion, Git added _too many_ moving parts in a poorly-
| designed way. Commits, the staging area, and stashes all
| implement the same sort of idea, but interact poorly and
| considerably complicate workflows. Having them is better than
| not having them, but Git would have been better off if they
| consolidated into a single idea and concentrated their
| efforts on that. If you can remove a concept from Git and
| still support the same workflows equally well, then surely
| that concept was unnecessary. (Whether the staging area is
| actually better served by other concepts is a matter of
| judgment.)
| 1attice wrote:
| 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-poor place to make good decisions.
|
| On the other hand, I'd say that absent sufficient data, one
| should pick the most flexible tool, which I'll bet in this
| context is the one with the most moving parts, i.e. git.
| arxanas wrote:
| 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 this the same way it
| handles splitting commits in general. Essentially, it has
| a greater set of verbs that act on a smaller set of
| nouns, where Git has a medium set of verbs that act on a
| medium set of nouns.
| 1attice wrote:
| 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
| yumraj wrote:
| I find it interesting that this is open sourced a few days after
| 11K were laid off.
|
| Was bulk of the team behind this laid off wherein it made sense
| to open source it to involve the community to take it forward
| rather than paid resources?
|
| To be clear: I'm NOT criticizing them open sourcing this.
| ak67 wrote:
| The open sourcing schedule was completely unrelated to the
| layoffs.
|
| The team working on Sapling has been planning this release for
| a very long time and will continue working on Sapling to
| support our internal engineering efforts.
| boberoni wrote:
| I doubt that the FB people involved with the layoffs are the
| same FB people who decided to open source the Sapling project.
| Many FB engineering managers were not aware that the layoffs
| were being planned. Moreover, it takes up-front planning and
| design decisions (by more than just a few days) for a private
| company to open source their internal projects.
| eisbaw wrote:
| Major pain point of monorepos: Merge-conflicts. When a merge-
| conflict happens YOU need to be expert and resolve all conflicts
| the right way, across the many unrelated domains mixed together.
|
| How does sapling solve that? It can't...
|
| IMHO Sapling looks like "Git for dummies". And Git teaches some
| pretty useful concepts, which are worth it.
| matthews2 wrote:
| If you get a merge conflict in a piece of code, you must have
| touched that code. And if you were capable enough to modify the
| code to begin with, you should be able to solve a merge
| conflict around it.
| mitrandir77 wrote:
| I don't see why merge conflicts would be a pain specific to
| monorepos. The merge conflict arises when you and some other
| person modify the same parts of the same file. No matter the
| repo size the correct solution here is figuring out the
| intention of the other person by reading their change or
| talking to them and deciding how to combine it with your
| change.
|
| The only reason which may make merge conflicts happen slightly
| more often in monorepo (vs constellation of small repos) is
| that not having the repo cloned locally is an obstacle to make
| the change. So some folks won't bother contributing repo that
| they'd have to clone first and instead they'd file a bug to the
| owners.
| ArchOversight wrote:
| I use the staging area to allow me to more easily break larger
| changes into smaller commits. I am usually all over the place
| while writing/refactoring code and making commits as I go along
| doesn't work well.
|
| How does sapling let me take a long list of commits and break
| them into larger but more manageable chunks?
|
| git add -p allows me to add chunks easily and create commits, git
| commit --fixup allows me to mark a commit as fixing a previous
| commit, and with git rebase -i --autosquash I get to easily take
| those fixup commits and meld them into the previous commits.
|
| Also reviewing a stack of patches is annoying in many cases as I
| care more about the end result vs each individual commit. But
| that may just be my experience talking in open source where I am
| working on smaller but better well defined projects vs a large
| mono-repo where there may be a lot of changes across many
| disparate parts of the code base that make it difficult to look
| at the "whole" vs a patch that is more localized.
| arxanas wrote:
| 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 is
| quite difficult in Git. (I miss that feature in Git quite a
| lot.) You can also use the `sl absorb` command to automagically
| merge local changes into the previous patches where they seem
| to belong (roughly speaking, commute changes backwards until
| they would cause a merge conflict, but it's a little smarter
| about avoiding certain merge conflicts).
| andrewshadura wrote:
| Consider also trying git-crecord, which is a port of he's
| curses-based partial commit interface.
| ArchOversight wrote:
| If I switch to a previous commit to amend it, then I would
| temporarily lose all the other changes I made, and means I
| can't easily run tests on that particular commit to validate
| nothing else broke.
|
| It sounds like I would need to:
|
| - switch - amend the commit - restack? - switch back to the
| HEAD?
|
| Fold based upon the documentation seems to move older commits
| into the current commit? vs the other way around?
| https://sapling-scm.com/docs/commands/fold
|
| This doesn't seem analogous to git rebase --autosquash which
| merges the mixup into the old commit.
| arxanas wrote:
| Yes, in my preferred workflow, I usually create a temporary
| commit and then switch away. Sapling also has `sl shelve`
| as `git stash`.
|
| If you want to run tests on commits without checking them
| out, you might want to try my `git test` command:
| https://github.com/arxanas/git-branchless/discussions/643
|
| You can use `sl fold --exact` to combine arbitrary commits
| without including the current one. (To be honest, I just
| always used `sl histedit`.)
| mitrandir77 wrote:
| `sl histedit` is very similar to `git rebase -i` if you're
| famiilar with that interface which works just fine.
|
| Other commands useful for amending changes to previous
| commits:
|
| * `sl goto --merge <hash>` - if theres no conflicts you can
| just switch commits with pending changes and those pending
| changes would be applied on top of other commit. If there
| are conflicts this command would fail https://sapling-
| scm.com/docs/commands/goto
|
| * `sl absorb` - this automagically finds the last commit
| that touched the lines that are pending and amends that
| commit with them https://sapling-
| scm.com/docs/commands/absorb
| tchebb wrote:
| `sl absorb` can turn that workflow into a single command in
| many cases: it automatically looks at what hunks you've
| changed and tries to propagate them back to earlier commits
| in the stack that touched those same hunks. It's not
| perfect, but in my experience using this at Meta, it does
| what you want 90% of the time.
| kobalsky wrote:
| > git add -p allows me to add chunks easily and create commits
|
| your workflow resembles mine so I'm in the obligation of
| mentioning https://github.com/jesseduffield/lazygit which
| allows you to stage individual lines among other features.
| https://www.youtube.com/watch?v=CPLdltN7wgE
| thijser wrote:
| https://sapling-scm.com/docs/introduction/differences-git#sa...
| says: "If you want to commit/amend just part of your changes
| you can use commit/amend -i to interactively choose which
| changes to commit/amend. Alternatively, you can simulate a
| staging area by making a temporary commit and amending to it as
| if it was the staging area, then use fold to collapse it into
| the real commit."
| mitrandir77 wrote:
| Nobody commented on the web interface yet which I think it's one
| of our coolest features: https://sapling-scm.com/docs/addons/isl
| feep wrote:
| https://sapling-scm.com/
|
| https://github.com/facebook/sapling
| Dowwie wrote:
| Would the team consider discussing the architecture of this
| system? Seems like a whole lot of Rust was used. I'm sure the
| team has a lot to share.
| quark12 wrote:
| Yes. Right now we are adding more documents about how internal
| components (like the commit graph) work. We hope others in the
| industry find them useful. Feel free to ask questions in GitHub
| too.
| loeg wrote:
| FYI, as-shared at Meta:
|
| > First things first, please go to your phone and turn off wifi
| to avoid voter ring detection and upvote us on Hacker News!
| [deleted]
| alexb_ wrote:
| Do you have any actual evidence of this, or is it a baseless
| accusation?
| loeg wrote:
| I didn't make it up, if that's what you're asking. Any Meta
| employee can confirm:
| fb.workplace.com/groups/scm.fyi/posts/2705323112933543
| camdat wrote:
| It's an internal post. Can confirm.
| dilap wrote:
| Good example of the "naughtiness" pg so prizes.
| conradludgate wrote:
| The interactive tool looks amazing. I do interactive rebases
| quite often and a drag-drop setup is wonderful
|
| However, I don't understand why I would want 1 PR per commit. I
| feel like that's a non-starter for me.
|
| Is the idea that no one should use branches - so there's only 3
| points of interest: HEAD, main, and origin/main? And then is the
| idea that it's only 1 commit per feature to merge?
|
| So I would work on something, make a PR, continue working on
| something else without making any git checkouts and then make a
| new PR?
| arxanas wrote:
| Generally, you "stack" your commits/PRs and review them in
| small units (which I think is what you mean by working on
| something else without making any Git checkouts).
|
| But you can certainly create new "branches" of development
| which aren't stacked on top of each other. They just don't have
| to have names. You can consider them to be "anonymous"
| branches.
|
| The main advantage of 1 commit per PR is to review and commit
| smaller changes (a single commit at a time).
| elischleifer wrote:
| the number of projects that require the scaling factor of
| something like this is very small. git with lfs scales very well
| for most repositories. That said the actual flow of git is pretty
| raw. There are other pretty solid projects out there that support
| undo commands into git.
|
| Stacked PRs are a blessing and a curse - still not convinced they
| are the correct way to build software as a team.
| benreesman wrote:
| Eh, it's pretty hard to make a case that you don't want stacked
| diff _sometimes_.
|
| Obviously life is simpler if all your work is sufficiently non-
| intersecting that you can send separate diffs/PRs and e.g.
| rebase them separately, but if you have Big Feature X and you
| still want small, single thesis diffs, where else do you turn?
| IshKebab wrote:
| _Public_ projects, sure. But plenty of companies have very
| large codebases that would benefit from this. Even if Git can
| handle it it can get very slow with largish repos.
| softwaredoug wrote:
| Its 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 as much a social problem around conventions, and lack of
| opinions in the tool itself, then anything about the underlying
| technology (which is rock solid IMO)
| tikhonj wrote:
| I dunno, there's a lot of value in having a tool that's
| flexible and lets you work the way you want--even if that
| fundamentally means there is no one blessed way to do things.
|
| Git has a lot of incidental complexity and unforced design
| problems, but the fact that it's inherently flexible is not
| one.
| indymike wrote:
| I remember when git was new, and the subversion crowd didn't
| jump on. Same discussion, different subjects. Git is/was
| awesome... but there is certainly room for improvement.
| 0cf8612b2e1e wrote:
| I would argue that camp a) is more diehard than your
| description. Some people will argue to their death how perfect
| a tool git is and it would be impossible to operate without a
| tool that exposed so much low level power.
|
| I use git begrudgingly because that's where the world is, but I
| long for an improvement in this space.
| msarnoff wrote:
| Command name conflicts with the `sl` utility that has existed for
| decades.
|
| https://github.com/mtoyoda/sl
| thijser wrote:
| "It's just a joke command, and not useful at all." with the
| last release 8 years ago. I understand that Meta didn't mind
| conflicting with that.
| IshKebab wrote:
| Doesn't matter. If anyone used a name at any point in time
| before you can never use it again. Apparently.
| ajkjk wrote:
| Seems fine.
| ripa wrote:
| What is the argument against having a staging area? The Git
| staging area is crucial in my mind.
| somnium_sn wrote:
| It stems from the original Mercurial implementation. The goal
| here is that every operation leaves the repository in a good
| state that can be pushed/pulled. That's why Mercurial and
| Sapling rely on commit/amend/uncommit, etc and for example
| usually discourage the use of interactive rebasing in favor of
| restack and other operations that add another "state". It
| facilitates the mental model for developers without actually
| removing workflows (they are just different).
| IshKebab wrote:
| As I understand it restacking _is_ rebasing no?
| mitrandir77 wrote:
| Yup, it's automatic rebase of a commit on top of the newer
| (amended) version of its parent.
| mitrandir77 wrote:
| It's simply not necessary to have that feature. Sapling
| encourages regularly committing and amending commits rather
| than staging changes.
|
| It's also easy to commit / amend part of your work by selecting
| the lines to include in nice curses interface (--interactive).
| ripa wrote:
| I guess each to their own. I want to stage my commit with
| regular commands, and then have the staging area work with
| (diff, add/remove etc).
|
| I don't care for an interactive tool, IMHO I prefer using
| commands that are repeatable and learnable instead of
| stepping through some interactive workflow all the time.
| ISL wrote:
| How do you construct a commit, in order to commit regularly,
| without having a staging environment in which to compose that
| commit?
|
| Is the branch-tip simply the staging area? What if you're
| only half-done with that final commit?
| mitrandir77 wrote:
| You `sl commit` that half-done work anyway and then iterate
| by running `sl amend` many times until your commit is
| finished. In case you want to amend just part of changes us
| `sl amend -i`
|
| https://sapling-scm.com/docs/commands/amend
| lijogdfljk wrote:
| I agree it's not necessary, but i like having it because it
| lets me separate what's going to be added before i actually
| commit.
|
| I still commit small, frequent. But i like `git add -p` to
| skip debug lines, hardcoded conditions, etc. I don't want to
| mistakenly auto commit a whole pile of lines and then have to
| remove debugs/hacks/etc from things i've committed.
|
| Stage + Unstaged is my working area, and the two live
| together quite nicely to me personally. I could live without
| it, definitely.. but i'm not sure i'd want to.
| arxanas wrote:
| 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).
| masklinn wrote:
| > Stage + Unstaged is my working area, and the two live
| together quite nicely to me personally. I could live
| without it, definitely.. but i'm not sure i'd want to.
|
| You can just use the tip as your staging. Use interactive
| amending to move changes from the working copy to the
| commit, and when you want to "commit", finish up the
| message.
|
| hg actually has an "unamend" command (part of the
| "uncommit" standard extension) which... reverts the last
| amend. Rather than having to remember how to contort reset
| into the right shape to move changes back out of staging
| without destroying everything.
| halter73 wrote:
| `git reset HEAD~` doesn't feel like that much of a
| contortion to me. It's the destructive change that
| requires more contortion (`--hard`) which feels fair.
| Maybe this is stockholm syndrome though.
| jcranmer wrote:
| The way I think of it, there's basically three copies of
| the file in play: in HEAD, in staging area, and on disk.
| I cannot trust my memory to remember which variant of
| "git reset" copies the file in HEAD to the staging area,
| which variant copies staging area to disk, and which
| variant copies HEAD to disk (in all cases, the third copy
| remains uninvolved). Getting it wrong potentially creates
| unrecoverable data loss. And, unfortunately, this is one
| of those cases where reading git's documentation is less
| than helpful.
|
| Combine this with the case where "I want to break one
| commit into two commits," where now I have to worry about
| making sure I know if the command is going to change the
| revision HEAD points to. At least there, the old commit
| will still exist as backup in the invariable scenario I
| screw something up.
| Shish2k wrote:
| I've been using FB's mercurial fork for years, wishing for all
| that time that I could have the joy of the fb-hg CLI while
| remaining compatible with github because that's where 99+% of the
| code lives - from my brief experimentation, sapling appears to be
| that. I look forward to never using the git CLI again :D
| feep wrote:
| I felt the same joy on reading the overview. Cleans up the git
| workflow so nicely.
|
| ...until I got to pull requests (Granted, that is github, not
| git). But it looks like you cannot generate a standard pull
| request with it.
|
| https://sapling-scm.com/docs/git/intro#pull-requests
|
| Haven't tried it yet, looking forward to it.
| jcranmer wrote:
| Reading the documentation quickly, it looks like you can
| generate a standard pull request, it's just that the PR may
| not conform to expectations if there are multiple commits.
|
| Of course, when it comes to github PRs, there are so many
| different "styles" of pull request, I'm not even sure which
| one should be considered "standard".
| Shish2k wrote:
| I actually just created my first PR from a sapling repo now -
| not sure why it's not documented, but you can push your local
| development branch to a remote server, and in the case of
| github, you even get the "it looks like you've just pushed a
| local branch, would you like to turn this branch into a PR?"
| prompt, and it appears indistinguishable from a branch
| created with the Git CLI.
| chungy wrote:
| > 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.
| Shish2k wrote:
| I use HEAD as my staging area, and do all the normal staging-
| area things, but without the weirdness that comes from the
| staging area being a different concept to a commit (ie, the
| diff command Just Works, no need for a separate `--staged` flag
| to enable special behaviour for that case)
| [deleted]
| masklinn wrote:
| 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)"
| quark12 wrote:
| You can also do `sl/hg log -Gr a21ccf+release_1.9`. The graph
| tells you the relation of selected commits. Last time I
| checked, git does not have the same --graph rendering yet -
| it only considers direct parents not ancestors.
| jcranmer wrote:
| 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.
| oorza wrote:
| Why do you want to? Not trying to be snarky, but I've been
| using various source control tools for closer to 20 years
| than 10 and I can't remember when I've ever needed or would
| have benefited from revsets. I'm genuinely curious what
| problem this solves and whether I've just never experienced
| or have made my own hodge podge solution for it
| incidentally.
| alwillis wrote:
| No disrespect but you're kidding, right?
|
| We often (a.k.a. constantly) want to see a subset of
| commits that meet some criteria.
|
| The way Git handles this is by adding more flags, which
| doesn't scale.
|
| Just look at the man page for git log... it's nuts.
|
| Having a concise functional query language [1] is one of
| Mercurial's and I guess Sapling's killer features.
|
| [1]: https://hg.mozilla.org/mozilla-central/help/revsets
| jcranmer wrote:
| I am used to working in large repos (>100 commits/day),
| which generally means that something like 'git log
| --graph' contains a lot of extraneous information.
|
| The most common workflow I have is that I've got a couple
| of old working branches (like featurea and featureb), and
| I want to see if I need to update featureb to a newer
| head or not, or if featureb was based on featurea or
| featurea-v2. A demonstration of this kind of thing is 'hg
| wip' here:
| http://jordi.inversethought.com/blog/customising-
| mercurial-l....
|
| Another thing I would use revsets for is answering
| queries like "which of these changes that's on the public
| repository made its way into the internal repository
| (which periodically merges from the public repo)?"
| chungy wrote:
| Is it really that confusing for Git? I had basically that
| entire manpage memorized early on (even before the manpage
| existed....)
| masklinn wrote:
| > Is it really that confusing for Git?
|
| Complete shit is what it is.
|
| It's awkward, messy, inconsistent, and hard to compose.
| IshKebab wrote:
| The CLI and nomenclature for the staging area (what
| should be called "draft commit") is awful, but the actual
| concept is very easy to understand.
|
| I seriously doubt anyone who uses a sane interface to Git
| (e.g. a GUI) has any trouble with clicking + to add
| changes to the draft commit before committing it.
|
| Most GUI tools let you automatically add all changes
| before committing anyway so you don't have to know
| anything about it if you don't want to.
|
| They just needed to name things better (what is a "soft
| reset" again?).
| jcranmer wrote:
| The main problem I have with the staging area is that it
| amounts to being something that's like a commit except
| for, you know, not actually being a commit, and therefore
| things that normally work on commits don't necessarily
| work on the staging area.
|
| A better fix would be to make the staging area an
| _actual_ commit, and then reframe everything as easy ways
| to edit the latest commit. (This meshes well with adding
| features like Mercurial 's phases or changeset evolution
| that make commit editing somewhat safer).
| still_grokking wrote:
| A "draft commit" (I really like that name!) is not a
| commit, and should not be handled as such. This would
| make this feature more or less useless.
|
| The whole point of the "draft commit" is that you can
| easily see changes against your (uncommited!) changes.
| That helps to build up a commit step by step.
|
| Committing WIP stuff (and maybe even pushing that) makes
| the history useless. Branches don't help as you end up
| with millions of WIP branches that are all incompatible
| to each other (and the evolution that happened
| elsewhere). Only keeping WIP branches up to date is a
| full time job than.
|
| Git has already a means to edit the latest commit easily:
| `git commit --amend`.
| thijser wrote:
| It's really just a matter of habit and getting used to no
| staging area takes short and has huge benefits.
|
| We develop HighFlux[1] which also gets rid of the staging area.
| It simplifies your mental model of what's going on a lot.
|
| Because everything you save is automatically committed,
| switching to a different task/branch is also always instant
| without needing stash.
|
| Because what you're testing locally is what you're committing,
| I also never have CI failures anymore (with the staging area I
| frequently had unexpected interactions with unstaged changes
| and sometimes even accidentally forgotten added files).
|
| 1: https://highflux.io/
| still_grokking wrote:
| Sounds like saying bye-bye to any meaningful history.
|
| Rebasing, cheery-picking, or reverting of commits becomes
| impossible when every save of a file is pushed.
|
| You could just publish local IDE history... Would be equally
| "good" I think. (My IDE is saving files every few key strokes
| btw; the resulting history would be a bloody mess).
|
| Why not go one step farther: Just make an automatic block
| image of the whole systems of every developer machine every
| few seconds. You could than just deliver the image. No docker
| setup needed any more. Just write code. And when the local
| version works, ship the whole local system just as it is. ;-)
| chungy wrote:
| > It's really just a matter of habit and getting used to no
| staging area takes short and has huge benefits.
|
| Sorry, but no. "No staging area" is what VCSes were like
| before Git and it was worse, much worse.
| still_grokking wrote:
| Would support that. The staging area is one of the things
| that make Git shine, imho.
|
| It would be very difficult to handle quite some "WIP
| situations" without the staging area.
| sggutier wrote:
| ajkjk wrote:
| Weird, it's one of my favorite changes. Finally I might get a
| version of Git which works without a bunch of extra crap
| getting in my way!
|
| you can always just use another commit as a staging area, I
| figure, and it'll make all the commands simpler and more
| intuitive so it wins in my book.
| still_grokking wrote:
| > you can always just use another commit as a staging area,
|
| And than you have to do gymnastics with rebasing and
| rewriting history afterwards. Using the staging area upfront
| is _much_ simpler!
| ajkjk wrote:
| Oh well, I don't have any problem with that. I like having
| all my changes always committed though.
| arxanas wrote:
| It has an interactive commit staging command which accomplishes
| the same thing. In that case, it unifies the staging area with
| regular commits, which means you can also manipulate them the
| same way as regular commits.
|
| AFAICT there are only two workflows involving the staging area:
| staging partial commits and resolving conflicts. The first case
| is taken care of by partial commit support, and the second case
| presumably has its own dedicated mechanism.
| saghm wrote:
| My favorite example of the staging area being super weird is
| `git diff` behavior. By default, git diff will show unstaged
| changes as well as committed changes, but _not_ staged
| changes; to see staged changes, you need to use `--cached`.
| This is especially weird when diffing between a fixed point
| (e.g. a commit hash) while going through the motions. If it's
| not clear why this would be weird, try out the following:
|
| * get the hash of the HEAD commit * run `git diff <hash>` and
| see that there are no changes * make some change to a file *
| run `git diff <hash>` again and see the change you made *
| stage the change with `git add` * run `git diff <hash>` again
| and no changes are show! * commit the change * run `git diff
| <hash>` again and the changes are back
|
| It's super bizarre to me that there would be some sort of
| intermediate state where changes aren't visible. I feel like
| it would make more sense to have some sort of formatting
| difference indicating unstaged versus staged but not
| committed versus committed, but I imagine changing that now
| would break all sorts of scripts, so we're stuck with it.
| sdiacom wrote:
| Not to subtract from your point at all, but newer versions
| of Git allow you to use `--staged` as a synonym for
| `--cached`. That this is the default behaviour still makes
| no sense, but at least the name does.
| saghm wrote:
| Ah, that is a better name! I'll have to add that to my
| mental list of git UX improvements (I'm also a big
| proponent of `git switch`)
| ajkjk wrote:
| That's good to know, but one has to wonder why that
| didn't change 15 years ago. It's representative of the
| general problem with Git: no particular problem with
| having bad UX for a long time without improving it. It
| seems like things started to get better in the last few
| years, but seriously it's not like the problems weren't
| obvious for a long time.
| still_grokking wrote:
| To be honest, I think this behavior is quite useful.
|
| Staging just means "I'm happy with the changes so far but
| didn't finish everything I want in my commit; let's ignore
| this changes for now".
|
| What `git diff` does by default becomes useful when you
| touch the staged changes _again_. _Then_ you see _only_ the
| new changes compared to the staged stuff. This helps
| building up a commit step by step, with some trail and
| error in between.
|
| Think for example about something like: You use some tool
| to do some automatic changes. This creates hundreds of
| changed files. But the result isn't working. You could
| commit that, sure. But than you would need to rewrite
| history before pushing because creating not working commits
| is a terrible idea. Or you could just stage the changes for
| now. Than you can change / repair the still missing parts.
| Git diff will helpfully show you only the new changes but
| ignore the staged stuff as long as it's untouched. You
| would now for example easily see changes that you made to
| the automatic rewrites. Without the staging behavior you
| could only compare with a committed state, and drown in
| hundreds of changes that are unrelated.
|
| The main problem with the staging area is that quite some
| GUI tools don't use it correctly. The tools try to
| "simplify" Git by ignoring how the stating area is supposed
| to work, or ignore it completely like the infamous
| JetBrains IDEs. (IDEA is the tool that needed almost 10
| years to implement Git sub-modules...). I think the VCS
| handling in IDEA is on the surface very polished. But when
| it comes to something like the staging area the UI-wise
| very crappy VS Code Git support beats that by far. Sublime
| Merge does also the "right thing"(tm) and hides the staged
| changes at the bottom so you see only the the changes to
| the changes. Exactly as the staging area is meant to be
| used!
| yuvadam wrote:
| Yet another tool from Facebook that maybe serves their internal
| needs well, but is totally useless to anyone else.
| bolinfest wrote:
| Originally started as an extension to Mercurial, but grew into
| its own SCM with a cross-platform virtual filesystem in C++ and a
| distributed server in Rust.
| jordigh wrote:
| 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 from Mercurial in
| favour of always using node hashes everywhere, arguing that for
| their gigantic repos, sequential revisions were so big as to be
| useless.
|
| Eventually the disagreements were too great, and Facebook just
| stopped publicly talking about Mercurial.
|
| I figured they would emerge a few years later with their fork of
| it. They love doing this. HipHop VM for PHP, Apache Hive, MyRock;
| these are examples of Facebook forking off their development in
| private and then later emerging with some thing they built on top
| of it.
|
| The Mercurial project is surprisingly still chugging along, and
| there are still those of us who actually use Mercurial. I doubt
| I'll switch over to Sapling, because I disagreed with the things
| that made Facebook fork off in the first place. But if others
| like Sapling and this manages to put the slightest dent into the
| git monoculture, I'm happy for the change and innovation. I
| really hope that git is not the final word in version control. I
| want to see more ideas be spread and that people can see that
| there can be a world beyond git.
| layer8 wrote:
| > I disagreed with the things that made Facebook fork off in
| the first place.
|
| Could you elaborate on what these things are and why you
| disagree with them?
| ravi-delia wrote:
| Presumably the things listed in the second paragraph
| (Phabricator, node hashes)
| alwillis wrote:
| I certainly recognized several Mercurial features and concepts
| in Sapling.
|
| For example, I use Mercurial's absorb command [1] and was
| pleased to see it in Sapling.
|
| Overall this looks promising.
|
| [1]: https://gregoryszorc.com/blog/2018/11/05/absorbing-commit-
| ch...
| jordigh wrote:
| Absorb is fantastic and one of Jun Wu's (seen in this thread
| as quark12) best contributions to Mercurial. I want everyone
| to know about this tool, it's amazing. I had fun trying to
| come up with a name for the feature:
|
| https://lobste.rs/s/nws1uj/help_us_name_new_mercurial_featur.
| ..
| IshKebab wrote:
| I was going to say that they already had started their own
| successor to Mercurial called Eden, but it seems like Sapling
| is just a renaming of Eden. Maybe anyway. It's a bit unclear.
| mitrandir77 wrote:
| https://news.ycombinator.com/item?id=33615077
| sheepscreek wrote:
| From the repo readme:
|
| > The Sapling CLI, sl, was originally based on Mercurial, and
| shares various aspects of the UI and features of Mercurial.
| aseipp wrote:
| Yeah, the old Eden repository redirects directly to Sapling
| now: https://github.com/facebookexperimental/eden
| TazeTSchnitzel wrote:
| As someone who used to be intimately involved in the
| development of PHP, HHVM was an interesting project because for
| a long time it supported standard PHP (alongside Facebook's
| custom language, Hack), so it brought competition to the
| implementation space! But eventually Facebook lost interest in
| that part, probably because they had no use for it.
| Shish2k wrote:
| If Sapling encourages a Git-usability renaissance the same
| way HHVM encouraged PHP to get good performance and typing,
| even if it eventually gets abandoned, I will be thankful for
| it :)
| CPUTranslator wrote:
| Neat! I hope this is a step in the right direction towards and
| not-so-bespoke SCM.
|
| I do wonder:
|
| 1) How it handles large (binary) files. This is a major pain
| point when using git and even the standard solution (git-lfs)
| leaves *a lot* to be desired.
|
| 2) How does server hosting currently work? I didn't see any
| mention and am assuming it's not an option currently? (two
| dependencies of Sapling are currently closed source)
| fhd2 wrote:
| 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 (like
| me). But I'm still happy Sapling is out there, I might use it or
| learn from it if I ever run into the problems it solves.
| bogwog wrote:
| 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
| that I've run into more abandonware from FB than Google?
| pjmlp wrote:
| There is plenty of abandonware on the Android world.
|
| Whatever is cool at Google IO XYWX is already abandoned by
| the time we reach into Google IO XYWX + 1.
| loudmax wrote:
| Fortunately, zstd seems to be in active development:
| https://github.com/facebook/zstd
|
| As far as I can tell, most of zstd's development is still by
| Facebook employees, though not all of it. I tend to think
| zstd has enough traction that development would continue even
| if FB were to abandon the project.
| 0cf8612b2e1e wrote:
| This is probably a naive take, but I think of compression
| software as something that can be "done". Unlikely to be a
| lot of code churn required for such a project to be
| relevant for a very long time.
| still_grokking wrote:
| Regarding zstd: I've just discovered bzip3.
|
| https://github.com/kspalaiologos/bzip3
| Agingcoder wrote:
| I think zstd is originally not a Facebook project.
| https://fastcompression.blogspot.com/2015/01/zstd-
| stronger-c...
|
| I believe Yann Collet, author of lz4, eventually went on to
| work for Facebook and finished it there.
| Agingcoder wrote:
| https://www.wired.com/2016/08/facebook-just-proved-isnt-
| hool... He was hired by Facebook during the 2015 summer,
| but the zstd announcement is dated jan 2015.
| procrastinatus wrote:
| I wonder what the folks at graphite.dev think about this
| announcement.
| andrewmcwatters wrote:
| 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'.
| mzr4141 wrote:
| `sl` is in the home row ;)
| avgcorrection wrote:
| Stack 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.
| davidpfarrell wrote:
| > There is no staging area.
|
| I don't actually want "No" staging area.
|
| What I want is, once I "add" something, the file stays added.
|
| Currently, I have `git st` alias setup : st =
| !git add -u && git status
|
| This auto-updates the staging area for files that were previously
| staged.
|
| So I get `git add` but also don't have to re-add anything
| manually from there ...
|
| Since I do `git st` quite frequently, this works out for me ...
| masklinn wrote:
| That seems like the worst possible use of the staging there is,
| it creates overhead and complicates diffing for no value
| whatsoever.
|
| If you want that behaviour, you can just `git commit -a` when
| you create your commit, then you only have to "git add" brand
| new unknown files.
| ArchOversight wrote:
| This would break the workflow of using the staging area to
| break a larger change into smaller commits.
|
| git add -p
|
| Allows you to select hunks of changes and stage them for
| committing...
| shagie wrote:
| For GP's use case, its "added some stuff, want to stage the
| stuff I modified since then to those files"... which I feel
| is a perfectly normal workflow.
|
| There's nothing saying that one can't add chunks to the
| staging area and then immediately commit it without invoking
| that alias afterwards (since it is a very deliberate "add
| these things" rather than "adding a bunch of things and keep
| adding."
| victoryanus wrote:
| jedberg wrote:
| In the argument of monorepo vs not, the usual argument goes like
| this:
|
| - It's too hard to scale for a large monorepo!
|
| - Google does it just fine!
|
| - But I don't have access to Google's tools!
|
| So kudos to Meta for both solving the problem and making it
| available to others. It will be interesting to see how useable it
| is outside of Meta. I know for example that while Netflix open
| sourced a lot of tools, most of them weren't useable unless you
| ran all of them together. So far Meta has been good at avoiding
| that, so hopefully that remains the case.
| durham_meta wrote:
| Hi Hacker News! Author of the Sapling blog post here. I'm happy
| to answer any questions you might have.
| thijser wrote:
| 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?
| durham_meta wrote:
| 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.
| chadaustin wrote:
| EdenFS builds (and probably runs?) from GitHub, but we have
| done no work to make it usable and hook it up to an existing
| checkout. It may not be much effort, and we're hoping to
| demonstrate that workflow in the future.
| jcranmer wrote:
| Is it possible to use git commands on an sl checked out
| repository, or vice versa? Or at least get something close
| enough to a git repository that I could run git commands on it,
| so I can fake it for internal tooling?
| durham_meta wrote:
| Unfortunately you can't run git commands directly right now,
| since there is no .git directory at the root of the repo.
| Under the hood there is a .git directory hidden away
| somewhere under the .sl directory, but we consider that an
| implementation detail and are likely to change how we store
| the actual git data in the future. So we don't support people
| running git commands in there.
| yewenjie wrote:
| I believe at some point the GitHub project used to be called
| Eden, right? When was the name changed and why?
| durham_meta wrote:
| Good memory! Internally Eden eventually became synonymous
| with our virtual filesystem, so we decided it was better to
| choose a new name to avoid that confusion.
| thijser wrote:
| I'm curious about the tech stack. It seems to be a combination
| of Rust and Python? How does that exactly work?
| durham_meta wrote:
| Sapling originated from the Mercurial open source project,
| which was largely Python (at the time). To make things faster
| and more maintainable, we started rewriting portions of it in
| Rust, and going through a binding layer to interact with
| Python. Critical pieces like the storage layer, parts of the
| wire protocol, and various others are all in Rust at this
| point, while a lot of the high level business logic remains
| in Python. We'll continue to shift more to Rust over time
| though, especially since pure-Rust Sapling commands feel way
| more snappy and pleasant to use.
| arxanas wrote:
| To 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, such as
| interactive undo?
|
| Jujutsu also supports colocated Git repositories:
| https://github.com/martinvonz/jj. It also has the working-copy-
| as-a-commit idea and conflicts are stored in commits (so rebases
| always succeed). I think it's a step forward compared to
| git/hg/sl.
| kbd wrote:
| I'm glad you mentioned Jujutsu. Given that it's also a git-
| compatible SCM my first thought upon seeing this post was how
| Sapling and Jujutsu compare.
| sequoia wrote:
| Phabricator[0]: code review/CI solution from Facebook. My company
| uses it, open development has since been halted by Facebook and
| we're effectively on abandonware.
|
| Flow[1]: JavaScript typing system from Facebook. My company uses
| it, open development has since been halted by Facebook so we're
| effectively on abandonware.
|
| EDIT: React: Javascript framework from Facebook, my company uses
| it, and while it has its warts it works pretty well all things
| considered and Facebook has continued to support and evolve it
| over time!
|
| For all I know Sapling is fantastic and will be developed for
| years to come. But personally I can't help but feel "once burnt,
| twice shy" (or in this case, twice burnt once shy). I'd be happy
| to be wrong here because ergonomics of Git are really frustrating
| in many places.
|
| 0: https://www.phacility.com/phabricator/ 1: https://flow.org/
| combyn8tor wrote:
| For me it was Parse.
| smeenai wrote:
| 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.
| mitrandir77 wrote:
| Phabricator was opensourced by Facebook. But most of it life
| as an opensource product is was actively maintained by
| Phacility.
| tomelliott wrote:
| 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 company really committed to
| supporting open source projects. At that time it was more 'if
| an individual engineer wanted to then go for it' rather than
| there being any formal process or consideration of longer
| term commitments.
|
| That changed fairly shortly afterwards with the creation of
| the OSS team.
|
| I remember someone transitioning to the newly formed team and
| moving from Dublin to London to do so in ~2012, as we became
| housemates :)
| lelandfe wrote:
| https://secure.phabricator.com/book/phabflavor/article/proj
| e...
|
| > _left Facebook in April [2011], and shortly after, we
| open sourced Phabricator_
| tomelliott wrote:
| Fair enough!
|
| Although if Evan had access to the codebase after he was
| an employee and if it was the Facebook codebase that was
| open sourced then Facebook were involved. The original
| post sounded (to me) like the OSS code wasn't the same as
| the FB code.
|
| I think that just backs up my point that it was the Wild
| West back then in terms of individual decision making.
| golergka wrote:
| To be fair, Flow wasn't abandoned just out of the blue, it was
| surpassed by Typescript to the point of becoming completely
| pointless.
| vfclists wrote:
| If you think Facebook are bad when it comes to abandoning
| software projects, try Microsoft.
| mariusmg wrote:
| Still missing Clippy ?
| xctr94 wrote:
| Google isn't far behind either. Perhaps corporate-owned open-
| source ecosystems weren't a great idea.
| palisade5132 wrote:
| I thought one of the main open-source's selling point is
| the fact you can fork it and maintain it even when the
| original author abandons it. Any alternative I can think of
| is a community-owned open-source, which probably wouldn't
| often work due to limited resources and no initial funding
| or a corporate-owned closed-source, which once abandoned is
| dead for good.
| jsiepkes wrote:
| Phabricator has a fork which is still developed:
| https://phorge.it/
| renewiltord wrote:
| Interesting. FB also open-sourced Thrift and then promptly had
| fbthrift diverge instantly.
|
| Overall, I'm glad they do these things, though since it is
| better to have this code accessible than absent. Good on them!
| Shish2k wrote:
| HHVM is an interesting data point too - kept PHP
| compatibility for as long as there were significant open-
| source users (eg wikipedia), but after PHP7 caught up with a
| lot of the performance gains, meaning there was little reason
| to use HHVM in PHP-compatibility mode, they then went off in
| their own direction with Hacklang (which is still actively
| developed) to get all the benefits of being PHP-like without
| the drawbacks of being PHP-compatible.
| tambourine_man wrote:
| >get all the benefits of being PHP-like without the
| drawbacks of being PHP-compatible
|
| I have a hard time understanding the benefit of using a
| language that's almost like a very popular one, but not
| quite.
| Shish2k wrote:
| PHP has some benefits to its design that the vast
| majority of other languages don't -- deployment is as
| simple as "stick a .php file on in your website folder",
| hitting the "refresh" button gets you the latest code
| with no "build" or "restart server" step, it's all
| stateless shared-nothing so you won't have data from one
| request changing the behaviour of another request, etc.
|
| But the implementation has a lot of drawbacks - the
| language is painful, typing is bolted-on and still
| incomplete after years of work (eg there are no typed
| arrays), the standard library is an inconsistent mess
| thanks to its origins of "take several other language's
| standard libraries and duct-tape them together", etc.
| shp0ngle wrote:
| It's not that hard to convert Flow code to TypeScript code.
| lolinder wrote:
| 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
| aliveli wrote:
| Don't forget projects like PyTorch, Presto, etc.
| lolinder wrote:
| Oh, right! I forgot PyTorch was originally Facebook (and
| it's not under their umbrella anymore).
| voz_ wrote:
| We still work on it tho :)
| TillE wrote:
| zstd is fantastic, though I suppose it's not the sort of
| thing that particularly needs ongoing active maintenance.
| [deleted]
| xctr94 wrote:
| I have my doubts as to whether they can be a good citizen of
| the open-source community and respect the developers relying
| on their tools. I routinely see bugs marked "won't fix" and
| nonsensical new features in the React Native ecosystem.
| [deleted]
| Shish2k wrote:
| The nice thing is that this is a client that works with vanilla
| git servers - if you switch to using it now, best case, you get
| a lifetime of good ergonomics; worst case, you get a few months
| of good ergonomics before something breaks that upstream
| doesn't want to fix, and you go back to using the vanilla git
| client.
| difflens wrote:
| Interesting 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... )
| hgomersall wrote:
| 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).
| dkasper wrote:
| As a Meta employee for almost 4 years what I will say is I was
| skeptical at first coming from git, but the sapling system works
| very well in practice in my experience. I still use git for
| everything outside of work, but I may consider sapling now.
| optymizer wrote:
| Can confirm. I like sapling better than git. Who needs
| branches? Why stress about detached heads? Working with a stack
| of commits is a breeze too.
|
| absorb split histedit uncommit unamend revert metaedit
|
| Once you use them, it's hard to go back.
| stevage wrote:
| 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 disaster the Git CLI is.
| terminal_d wrote:
| mjsir911 wrote:
| Maybe I'm misunderstanding, but isn't this what `git revert` is
| for?
|
| Harder with an amend due to having to get the difference of
| commits within the reflog, sure.
| zeroonetwothree wrote:
| That's actually not what git revert does, hence the poor
| usability of its API.
| mikepurvis wrote:
| git revert doesn't undo a commit though-- it creates a new
| commit that undoes it. That might be what you want under some
| circumstances, but most of the time that I want to revert
| it's a commit I _just_ made and haven 't pushed yet, so I
| just want to pretend it never existed.
| pooper wrote:
| I don't know much about git but I just do
| git reset --soft HEAD~n
|
| where n is the number of commits I want to undo.
|
| Known issue: can't undo all the commits.
| still_grokking wrote:
| What's wrong with just working on and when the changes
| finally look like they should just do a `git commit
| --amend`?
|
| Or if the commit should for some strange reasons really
| never exist just move HEAD one commit back. You could even
| get the changes back by merging the "bad" commit back
| without committing the merge (using the `--no-commit`
| switch).
| [deleted]
| waynesonfire wrote:
| 10 years? Maybe try RTFM. Then a few command aliases and you're
| on your way. Takes way less time.
| somehnguy wrote:
| Lol. Orrr we could just do things sensibly in the first
| place.
| sixstringtheory wrote:
| I always chuckle when things like "sensible", "user-
| friendly" or "sane" get thrown around as if they are
| anything more than that person's opinion.
|
| When are developers going to learn that they actually have
| to learn and familiarize themselves with preexisting
| systems, instead of endlessly reinventing them, and that
| there is no such thing as the perfect system?
| Shish2k wrote:
| Nothing is perfect, but some things are clearly better
| than others - hence why we're nearly-all using git rather
| than "learning and familiarising ourselves" with CVS :)
| mikepurvis wrote:
| 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 <commit>", 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.
| latifk wrote:
| Well in that situation you can stash unstaged, reset, then
| pop. But that just reinforces the OP's point. Not the most
| ergonomic or discoverable path for something that should be
| simple to do.
| sli wrote:
| I've been using lazygit[0] for a while, which might not be what
| you're looking for but I enjoy it a lot.
|
| [0]: https://github.com/jesseduffield/lazygit
| Sk012 wrote:
| Add Comment
| nailer wrote:
| This won't go anywhere even if its 20% better than git. To
| replace git's network effects, you need to be 10x better.
|
| How I think that will happen is using CRDTs against an AST to
| remove most merge conflicts.
| itslennysfault wrote:
| Somehow that doesn't matter for FB. Yarn is not 10x better than
| NPM and it took off. React is.... ugh... React and it took over
| the whole dang industry.
| ajkjk wrote:
| I think a lot of people see this and think "I'm switching as
| soon as possible". It might be the 10x you need (although IMO
| 2x would do).
|
| People are SUPER over dealing with using Git on large repos.
| noahchumsky wrote:
| You may find https://pijul.org/ interesting.
| softjobs wrote:
| And https://github.com/martinvonz/jj.
| justinsaccount wrote:
| Does network effect even apply if it's compatible with existing
| git repositories?
| nailer wrote:
| Looking back when the last change happened: there was a
| subversion integration with git, but people actually switched
| to git for proper decentralised version control rather than
| use it. Then switched to GitHub to recentralise but that's
| off topic.
| rhdunn wrote:
| Not everything that uses GitHub/BitBucket/GitLab etc. is
| (re)centralized. You can have an internal company hosting
| service and a public hosting solution, for example. I've
| also used the decentralized capabilities to synchronize
| between two computers.
|
| There are many reasons why GitHub (or something like it)
| are popular, such as:
|
| 1) not having to host the infrastructure yourself (incl.
| hosting it on AWS/Azure/etc.)
|
| 2) discoverability -- being able to follow
| people/organizations creating projects you are interested
| in; being able to search for projects ~ having these on
| various websites makes it harder to discover them
|
| 3) additional functionality/capabilities like static web
| page hosting (great for things like personal projects), and
| CI/CD workflows
| koreth1 wrote:
| I remember git-svn being pretty commonly used back in the
| day (circa 2007). At that point a lot of open-source
| projects were still using svn and if you wanted to use git
| locally, git-svn or something similar was how you did it.
|
| My first experience with git was using git-svn to work with
| my company's internal svn repository, which I did for a
| couple years before the company stopped using svn. There
| was no internal desire for decentralized version control
| (rather the opposite, in fact; they wanted centralized
| permission management and such).
| tkanarsky wrote:
| This is simply unusable. If I type `sl`, I expect an animated
| choo-choo train to appear, not a newfangled Git client!
|
| /s :)
| [deleted]
| noamelf wrote:
| Trying to use it on existing git repo doesn't work... At least
| not out of the box, I wonder why is that? Makes it less fun to
| work with as you can't easily switch
| Shish2k wrote:
| It needs its own client-side data, but it will work with
| existing git servers - so switching is as hard as running
| "(git|sl) clone https://github.com/..."
___________________________________________________________________
(page generated 2022-11-15 23:00 UTC)