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

I kind of killed Mercurial at Mozilla

glandium.org

Post reply on HN
Print view View original

221–230 of 250 posts

Re: I kind of killed Mercurial at Mozilla

#221

Post by aseipp »

llbeansandrice wrote: post #141
aseipp wrote: post #69

Earlier quoted context omitted.

Most of the projects that dislike GitHub's review UI want the functional equivalent of `git range-diff`. Code review systems like Phabricator and Gerrit basically revolve around this as basis of thinking about diffs, their evolution, and how code review progresses. You want to write 3 patches to a project, that are committed in series, based off of `X` A ---> B ---> C X---/ Let's say A cleans up some code, getting it…

This is an incredible workflow as someone who has only ever used git and GitHub (and poorly at that). I presume there isn’t really any way to have this kind of workflow using git and GitHub? I’d be interested in something like this at my company but we’re sorta locked in to GitHub already.

There are third party tools like Graphite, CodeApprove, and Reviewable that will basically add these workflows on top of the existing GitHub API.

There's a much more detailed and complex answer to this question (TL;DR you can kind of fake it in various weird ways without too much effort) but that's probably the best approach if you're willing to fork over some money. Graphite in particular seems pretty well reviewed.

You may also want to look into Sapling and tools like git-branchless, which will change your workflow to better accommodate this kind of thinking.

Re: I kind of killed Mercurial at Mozilla

#222

Post by IshKebab »

dig1 wrote: post #188
IshKebab wrote: post #183

Earlier quoted context omitted.

> Git is very good with large repos Not really. It only very recently got support for partial clones, sparse checkouts (still experimental!) `git status` daemon (only on Windows and Mac!), etc. And that's only because Microsoft is pushing it. > My guess is that people adopt monorepos because they aspire to be Google-scale, but it usually doesn't make sense for their workflow. Rubbish, it's nothing to do with wanting…

> Not really. It only very recently got support for partial clones, sparse checkouts (still experimental!) `git status` daemon (only on Windows and Mac!), etc. And that's only because Microsoft is pushing it. Which only proves my comment that git is not designed for bigcorp view of monorepos. Kernel is monorepo and works fine. > The reason people like monorepos is because they don't have the downsides of multirepos:…

> Which only proves my comment that git is not designed for bigcorp view of monorepos. Kernel is monorepo and works fine.

Not really; it just means you misunderstood what I meant by "large projects". The Linux kernel is not nearly as large as most company codebases.

> The reason people like monorepos is that they are lazy to properly organize development process. If you update library in one repo but test it in another, I'd say you need to reconsider your pipeline.

Sounds like you just don't have any experience of this sort of thing so don't appreciate the problems. You update the library in one repo and test it in another because that other repo is using the library. You want to make sure your library update doesn't break it.

If you don't test all of the dependants of your library then you're massively increasing the risk of breakage (plus all the other downsides) just so you can use separate repos. That isn't worth it.

Re: I kind of killed Mercurial at Mozilla

#223

Post by cmrdporcupine »

WorldMaker wrote: post #218
cmrdporcupine wrote: post #110

Earlier quoted context omitted.

Git functionality is great. But the CLI just kind of grew in a nonsensical way. No serious effort seems to have been made on UX consistency and verb/noun names. People who've been using it for years don't notice, they don't even think about it. But when coming from scratch, it's anything but intuitive. The CLI is not discoverable in a reasonable way. That and there's so many ways to use it. Mercurial had the advantag…

> Mercurial was never trying to "replace" git. All of these guys came out at the same time. Mercurial even had a couple weeks' head start on git, and git partly happened trying to replace Mercurial in early experimentation. The name "git" was always an interesting self-deprecating choice because it was (intentionally) "stupider" than its competition that it knew about, which included Mercurial (and also darcs/Monoton…

It's a bummer that Graydon didn't stick with monotone.

Re: I kind of killed Mercurial at Mozilla

#224

Post by shepherdjerred »

steveklabnik wrote: post #216
shepherdjerred wrote: post #65

Earlier quoted context omitted.

I've found that Graphite [0] has solved this issue for me. It's makes the experience of shipping stacked diffs about the same as the CR tool within AWS [0]: https://graphite.dev/

Thanks for this. I admittedly still don't really grok it, but maybe if I play around with the tooling, something will click.

I think that this page gives a decent overview of what the tool aims to accomplish: https://graphite.dev/docs/how-stacking-works

This page covers some of the more advanced functionality: https://graphite.dev/docs/manage-stacks

Either way, I hope you like it! I've tried many other tools that aim to implement stacked diffs for GitHub PRs, and Graphite is _by far_ the best. They have their own Web UI but I skip that completely and just use their CLI + GH's UI.

Re: I kind of killed Mercurial at Mozilla

#225

Post by alex_smart »

G3rn0ti wrote: post #165
alex_smart wrote: post #133

Earlier quoted context omitted.

Essentially, the problem with git is - it is a tool that is simple in its internals, but with a complex/confusing UI. The only way for someone to feel somewhat in comfortable with git is to have a good conceptual model for how it works internally. Once you have that mental model, you feel like a magician with git, but for beginners, it is a source of endless confusion and fear.

GIT is a tool. Like a swiss army knife, it looks tricky and you need some experience to master all what it provides. But you never actually need everything and, surely, you should also shy away from features if you do not really need them. In this respect GIT is a bit like Perl or C++. You have to apply some discipline to avoid unnecessary complexity. Personally, I have never used GIT's "octopus" merge support but I…

> you should also shy away from features if you do not really need them

>Learn those and you'll mostly good to go.

I wasn't really talking about "fancy" features of git, like rebasing history to try to make your history pretty or using things like git bisect. You need to develop basic understanding of git internals, even in the most basic workflow.

I would argue that your list of commands is not in any way complete for being "mostly good to go". At the minimum, you also need to know `git clone`, `git push`, `git pull`, `git fetch`, `git diff`, `git log`, `git blame`, and `git reset` as well. You need to save progress on your current feature branch to context switch to review some PR or analyze some production bug, well add `git stash` to the list. Your boss asked you to hotfix your recent commits onto the release branch? Better not forget `git cherry-pick`.

That brings us to 17 commands (up from the 7 you listed). Fine, it is still a finite number. Can you at least use them as a black box without bothering about the internals? NOPE. You also have to learn a lot of concepts to even understand the help and error messages for these commands - the worktree, the index, the stash, HEAD, ours vs theirs, conflicts, remotes, tracking branches.

Besides, so many commands come with their own gotchas (git checkout will happily overwrite your local changes - without any warning). Some have bad defaults, so you need to figure out which of the hundreds of options that command supports to make it do what you actually want (e.g. git log --oneline and git diff -w -b). Still others have overloaded semantics and do two completely different things (git checkout switches branches but also restores files).

Re: I kind of killed Mercurial at Mozilla

#226

Post by steveklabnik »

shepherdjerred wrote: post #224
steveklabnik wrote: post #216

Earlier quoted context omitted.

Thanks for this. I admittedly still don't really grok it, but maybe if I play around with the tooling, something will click.

I think that this page gives a decent overview of what the tool aims to accomplish: https://graphite.dev/docs/how-stacking-works This page covers some of the more advanced functionality: https://graphite.dev/docs/manage-stacks Either way, I hope you like it! I've tried many other tools that aim to implement stacked diffs for GitHub PRs, and Graphite is _by far_ the best. They have their own Web UI but I skip that com…

I watched their product overview video last night, but like, I don't grok what the difference between rebasing a branch and rebasing a stack is, and they said something like "if there are conflicts, this is when you'd fix them." but I thought the point was reducing conflicts. It sounds to me like short lived feature branches with a lot of extra terminology.

I really think I just need to actually try the tooling and then examine the git repo. I am very bottom-up brained when it comes to git, and so I need to visualize what commands actually do to the DAG to really grok what's going on.

Re: I kind of killed Mercurial at Mozilla

#227

Post by happymellon »

crdrost wrote: post #90
interroboink wrote: post #41

I liked the thorough article, but my goodness did they beat around the bush w/regard to their actual contribution to this process (per the title). I think the short version is: they made `git-cinnabar`, which is a git-to-hg translator, to help git users interact with the Mozilla repos. ---- One contribution I can make: > For reasons I don't know, Mozilla decided to use separate Mercurial repositories as "branches". O…

> Aside: I prefer Mercurial myself, and I hope to keep using it for personal projects until I die (: One of my favorite stories happened three or four jobs ago... at this job I kept a giant whiteboard that I had swiped from a conf room, behind my cubicle. And whenever anybody asked questions we put it up on the board. We were an SVN shop and someone had asked how Git worked and I was like "do you want me to explain G…

There are plenty of nice GUIs for got as well.

TortoiseGit works, Fork is pretty good but it's a shame that GitKraken is so expensive.

Re: I kind of killed Mercurial at Mozilla

#228

Post by guenthert »

meindnoch wrote: post #214
guenthert wrote: post #174

Earlier quoted context omitted.

> There’s a meme that Git is hard to use but I think it’s conflating the challenges of getting used to version control at all Not sure about that. Git certainly doesn't make it easier by idiosyncratic use of terms and behavior. Why does 'pull' imply 'checkout'?

>Why does 'pull' imply 'checkout'? ??? It doesn't.

It sadly clobbers your working tree. Not calling that checkout doesn't make it any better. Nothing other than checkout ought to change the working tree -- is that too much to ask?

Re: I kind of killed Mercurial at Mozilla

#229

Post by yjftsjthsd-h »

sys_64738 wrote: post #56

Solaris source control moved to Mercurial so if you want to know if it scales then the answer is yes. I miss SCCS.

Didn't Sun have Gatekeepers carefully controlling what commits were made to any given gate, thereby ensuring that the actual source control would never be the limiting factor in scaling things out? (Don't get me wrong, I love mercurial, I just don't think this particular example demonstrates much because it always sounded like they'd sidestepped the issue.)

Re: I kind of killed Mercurial at Mozilla

#230

Post by glandium »

guenthert wrote: post #228
meindnoch wrote: post #214

Earlier quoted context omitted.

>Why does 'pull' imply 'checkout'? ??? It doesn't.

It sadly clobbers your working tree. Not calling that checkout doesn't make it any better. Nothing other than checkout ought to change the working tree -- is that too much to ask?

There are plenty other commands that change the working tree. rebase, cherry-pick, revert, merge, etc. Are you suggesting that all these should be done by checkout?

pull is fetch + rebase or merge. You can use fetch instead of pull if you prefer. Or `git remote update`, for that matter.

Post reply on HN