341–350 of 543 posts
Earlier quoted context omitted.
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.
From the build instructions for sapling: "It can be built by running make oss in the eden/scm directory"
> When used with our Sapling-compatible server and virtual file system (we hope to open-source these in the future) Sorry, I just can't take an "open-source" project seriously that uses "we hope to open-source these in the future" in its pitch.
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).
Please stop signing commits
Earlier quoted context omitted.
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...
In git you do this like git commit --fixup hashtofix && git rebase -i --autosquash hashtofix^ Hard to discover and remember but once you do it usually works smoothly.
Earlier quoted context omitted.
I switched from git to Mercurial and was absolutely gobsmacked by how much better it is. The only comparison was switching from a Blackberry to an iPhone - everything just works exactly the way I want it to. Yes, I read the manual for git, but I never needed to for Mercurial.
I guess you didn't start from cvs or svn, because the experience moving to git was otherworldly. If git was your first versioning system than you had to learn some concepts first, which you already internalized when you switched to Mercurial.
I feel like the Mercurial fanbase is just another loud fanbase. I did start with CVS and SVN and git was absolutely fantastic when I started using it. On the other hand I could never get the hang of Mercurial. From MY PERSONAL perspective it has a terrible UX(which is the exact opposite experience of the loud hg fan git critics on HN). I absolutely cannot relate to the people who say that Mercurial has the better UX, but I don't remember myself constantly bashing mercurial either like the other side does. From my perspective `git add -p` is an important essential functionality that hg does not provide. I believe there was some sort of plugin but it was no where near as polished.
Yes, there are a handful of nice features in mercurial, but none which are actually necessarily needed inside of the git core.
I do faintly remember that my biggest problem with git was understanding that a commit doesn't push automatically. But then again that's just a difference between a DVCS and whatever was there before.
Earlier 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…
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 2 and 3? But the way I see it, 2 is doing what you want. I can split the set of current changes by selectively adding them to the index in preparation for a commit. I can also selectively un-stage changes if I decide I don't want them to become part of the commit.
Between the changes to a file in whatever editor buffer I'm writing in, saving those to disk, moving changes from unstaged to staged, and forming a commit in any of a variety of ways (plain ol' commit, amending a commit, a fixup commit) I can't imagine what other way I need to slice and dice changes. Maybe it's just a failure of my imagination since I've been using Git for so long now and only more basic things like SVN/TFS/CVS before that.
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…
Fossil is a pretty great alternative to git. https://www.fossil-scm.org/home/doc/trunk/www/index.wiki
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
I guess you didn't start from cvs or svn, because the experience moving to git was otherworldly. If git was your first versioning system than you had to learn some concepts first, which you already internalized when you switched to Mercurial.
I think the problem arises from when you switched to hg from those older systems and grew accustomed to it and then were FORCED to switch to git because of work or whatever. I feel like the Mercurial fanbase is just another loud fanbase. I did start with CVS and SVN and git was absolutely fantastic when I started using it. On the other hand I could never get the hang of Mercurial. From MY PERSONAL perspective it has…
Mercurial has an interactive commit mode (hg ci -i) with a slick TUI for navigating and selecting chunks to commit.