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

Oh Shit, Git?

ohshitgit.com

Post reply on HN
Print view View original

171–180 of 275 posts

Re: Oh Shit, Git?

#171

Post by greazy »

gmueckl wrote: post #147
dgfitz wrote: post #144

I’m pumped a search for hg+mercurial had hits in this thread. I am and will continue to be completely blown that hg lost the dvcs wars. It’s a better tool.

It is the unquestioningly better tool right now. It's available, stable, battle-tested and it's actively supported. It's a case of "being the change you want to see". Just use it. Claims that it lost are counterproductive. The implicit deterrence from those statements is what is actively keeping Mercurial's adoption low. Hosting is available at least from Sourcehut and heptapod.host. I'm running a private Heptapod in…

Are there any public forges that support hg?

Re: Oh Shit, Git?

#172

Post by [deleted] »

snafferty wrote: post #158
ajross wrote: post #131

Earlier quoted context omitted.

> 1. Always use `git switch` instead of `git checkout` Even harder: always use "git reset --hard". Basically don't use local branches. The correct workflow for almost every task these days is "all branches are remote". Fetch from remotes. Reset to whatever remote branch you want to work above. Do your work. Push back to a remote branch (usually a pull request branch in common usage) when you're done. If you need to m…

This is a workflow I’ve never seen on any team or project I’ve worked on. Another commenter already mentioned the remote branch for everything preference, but usage of tags is especially interesting to me. I think that’s how most people use branches, and tags tend to be more permanent. What do you do when you come back to the commit with the tag, cherry pick it over and delete the tag? It sounds like an overly compli…

[deleted]

Re: Oh Shit, Git?

#175

Post by mardifoufs »

jimbob45 wrote: post #97
phtrivier wrote: post #89

This will feel very weird in April 2025, when we celebrate the 20th anniversary of git. I was there. And at some point I wondered if I should learn git, darcs, or bazaar, to replace SVN or CVS. Or did I try mercurial too ? I wonder if the "GitHub" effect has basically killed the need for a newcomer in the space of VCS. Maybe at some point, the yak is shaved enough ?

SVN has always worked for me. You don’t have to “teach” people SVN because it’s intuitive and works just fine for the 99% case. I wish we would all stop larping as 1337 hackerz and just admit that git is overkill for the vast majority of people.

SVN is more alien to me than git. Does that make you a LARPing epic hacker?

Re: Oh Shit, Git?

#177

Post by ajross »

snafferty wrote: post #158
ajross wrote: post #131

Earlier quoted context omitted.

> 1. Always use `git switch` instead of `git checkout` Even harder: always use "git reset --hard". Basically don't use local branches. The correct workflow for almost every task these days is "all branches are remote". Fetch from remotes. Reset to whatever remote branch you want to work above. Do your work. Push back to a remote branch (usually a pull request branch in common usage) when you're done. If you need to m…

This is a workflow I’ve never seen on any team or project I’ve worked on. Another commenter already mentioned the remote branch for everything preference, but usage of tags is especially interesting to me. I think that’s how most people use branches, and tags tend to be more permanent. What do you do when you come back to the commit with the tag, cherry pick it over and delete the tag? It sounds like an overly compli…

Local branches aren't names for anything other humans beings care about. All "branches" discussed in a team are remote. But because branches have "history" and "state", keeping your local names around is just inviting them to get out of sync with identically or similarly-named branches out there in the rest of the world.

> It sounds like an overly complicated process compared to having a branch and rebasing onto the current branch when you finally go to make the change for real.

Not sure I understand the problem here? The rebase is the hard part. It doesn't help you to have a name for the code you're coming "from". If it collides it collides and you have to resolve it.

What I said about tags was just as short term memory "This commit right here worked on this date", stored in a way that (unless I delete or force-update the tag) I can't forget or pollute. Branches don't have that property. And again local branches don't have any advantages.

Re: Oh Shit, Git?

#178

Post by gmueckl »

greazy wrote: post #171
gmueckl wrote: post #147

Earlier quoted context omitted.

It is the unquestioningly better tool right now. It's available, stable, battle-tested and it's actively supported. It's a case of "being the change you want to see". Just use it. Claims that it lost are counterproductive. The implicit deterrence from those statements is what is actively keeping Mercurial's adoption low. Hosting is available at least from Sourcehut and heptapod.host. I'm running a private Heptapod in…

Are there any public forges that support hg?

Have a look at heptapost.host for paid hosting and foss.heptapod.net for free public hosting for OSS. Is that what you are looking for?

Re: Oh Shit, Git?

#179

Post by dijksterhuis »

harrall wrote: post #170
nuancebydefault wrote: post #83

Earlier quoted context omitted.

The cli is faster if you know by heart but a real disadvantage is that it is hard to "see" what you did or what happened in the past. Good look finding where/whether an old branch got merged and find out if it is part of a release, using cli.

Is this really true? When I want to reorder commits, I just drag & drop in a GUI and I’m done. Or if I want to switch branch or manage a complex mix of rebases or cherry picks, it’s just 2 or 3 clicks. In CLI, by the time I’ve typed out the commit hash or locator, it’s already taken longer. And I type 130 words per minute.

> by the time I’ve typed out the commit hash

i don’t think i’ve typed out a full hash in … years? if i have i’ve used the short 8 character hash.

git rev-parse might be something useful to have a look at, especially when combined with aliases.

Re: Oh Shit, Git?

#180

Post by hooper »

stouset wrote: post #121
pitaj wrote: post #3

Some changes I would make: 1. Always use `git switch` instead of `git checkout` 2. Avoid `reset --hard` at all costs. So for the "accidentally committed something to master that should have been on a brand new branch" issue, I would do this instead: # create a new branch from the current state of master git branch some-new-branch-name # switch to the previous commit git switch -d HEAD~ # overwrite master branch to th…

Rewriting these for jj users. I'm prefering long option names and full command names for clarity here, but all the commands have shortened aliases and all the option names have single-letter alternatives. `@` means "the current revision", `x+` means "the revision just after `x`", `x-` means "the revision just before `x`". 2. "Accidentally committed something to master that should have been on a brand new branch". Thi…

One thing I really appreciate is that you can run `jj new master` at _any_ time to drop what you're doing and start a new change. The way jj handles the working copy, conflicts, and visible heads means there's just no need to think about uncommitted changes, unfinished conflict resolution, detached head, etc.. So many things that would get in your way just can't happen.
Post reply on HN