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

151–160 of 275 posts

Re: Oh Shit, Git?

#151

Post by Nullabillity »

WorldMaker wrote: post #127
javier_e06 wrote: post #53

Lately I've been asked to avoid merge-commits. They pollute the logs? If my push is blocked I am too far behind I create a new temp branch of master and do a "merge --squash" to it and then a "reset --hard" from temp branch back to my original branch. Heck sometimes I rather keep my changes in patches to void does darn merge CONFLICTS...specially when rebasing.

I think that people that think merge commits "pollute the logs" are missing key git features such as `--first-parent`. Git is natively a graph . It gets a lot of powers from that. If you don't want to see all the details of the "subway diagram", add `--first-parent` as a default and focus on the higher level. Merge commits help avoid later conflicts by saving how earlier conflicts were solved. Three-way merging in ge…

On top of this, integration is an "interesting" step on its own! When trying to diagnose an issue it can be super valuable to be able to understand whether it was broken from the start or broken by the merge. Rebasing throws all of that valuable information away!

Re: Oh Shit, Git?

#152

Post by Nullabillity »

nuancebydefault wrote: post #92
javier_e06 wrote: post #53

Lately I've been asked to avoid merge-commits. They pollute the logs? If my push is blocked I am too far behind I create a new temp branch of master and do a "merge --squash" to it and then a "reset --hard" from temp branch back to my original branch. Heck sometimes I rather keep my changes in patches to void does darn merge CONFLICTS...specially when rebasing.

The thing is if you merge immediately into master and have conflicts, you solve the conflict and only then you can merge. But then the conflict resolution sits at the merge point with a weird default commit message and is hard to decipher. A nicer way is merge master into your branch, with the rebase option (you can set that option as the default). This will put your changes on top of the master changes that happened…

Merge main into your branch, then merge --no-ff your branch into main. No need to rebase or squash anything.

Re: Oh Shit, Git?

#153

Post by FractalHQ »

SebastianKra wrote: post #46

We should start recommending UIs as the default way to learn Git. It would solve a third of these problems and another third wouldn't even come up. If you later decide that the CLI is faster, go ahead. But first, people need to see visually how they can interact with the tree. I like fork.dev, but most clients are pretty similar at this point.

lazygit ! Just needed to throw out a mention because it’s an amazing tui for visual orientation, is super fast, and can be used with a mouse and keyboard (or just keyboard) from the terminal. I saw it mentioned on a thread here last year and have preferred it as a fast “oh crap I think I made a mess lets back up” tool over the more complex gui apps I’ve tried (almost all of them).

Re: Oh Shit, Git?

#154

Post by amanwithnoplan »

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…

Please kindly write one for a jj-specific issue: "my build vomitted out a bunch of files and I used any jj command before editing my .gitignore"

I've found myself using git to fix the mess in this particular instance.

Re: Oh Shit, Git?

#155

Post by dijksterhuis »

SebastianKra wrote: post #46

We should start recommending UIs as the default way to learn Git. It would solve a third of these problems and another third wouldn't even come up. If you later decide that the CLI is faster, go ahead. But first, people need to see visually how they can interact with the tree. I like fork.dev, but most clients are pretty similar at this point.

disagree, with a caveat.

to summarise: use the desktop apps now, but thou shalt need to learn the CLI.

—

when i’ve taught absolute development beginners how to use git and how to do PRs i show them both the CLI and GitHub desktop. not every single thing. but i at least show them add/commit/push and creating/checking out branches in the CLI.

why?

1) this CLI thing is what power users / experienced folks use. this is your long term goal.

2) oh look, the terminal is typing things out instead of clicking on buttons which have slightly different names (target audience has never seen a terminal)

3a) some things cannot be unfucked in a desktop app. i don’t have to explain what the CLI is to show them how to unfuck it. i might have to remind them. but it’s not totally alien to them. they’re only seeing the fix for the first time, not the fix and the CLI.

3b) they might feel more comfortable trying to use the CLI when they’ve already been shown it before. ideally in tandem with 3a — “hey i need to do this thing to unfuck it, could you sit with me while i go through to avoid fucking it even more”

4) maybe they go “screw it, i want the pain because i really want to be a magician at this”. it’s nice for them to have the option of the easier, simpler path when they’re having a bad day with it.

ill always suggest that absolute beginners use the desktop apps because it does reduce early fuck ups. and part of that involves showing them the desktop apps.

but i feel they need to be made aware the desktop apps are not the be end and end all. they can try the CLI a few times if they want. at some point, they will have to use it.

they also need to learn to fuck it up. making mistakes is how human beings really learn.

both making mistakes and demo-ing the CLI early, often and safely; rather than later and rarely; gets people to “magician” level faster in my experience.

essentially, you have more to learn buddy. keep working on it if you want to be one of the magicians in the team. if you don’t, that’s fine. but at some point you’ll need to deal with this CLI thing.

—

> people need to see visually how they can interact with the tree.

i’ve got a whole diagram thing i draw live showing them how everything is based on commits or a collection of commits, moving the commits around in front of them.

seems to be a better way to cover remotes, branches and eventually PRs than leaving them to work it out with some history visualisation which is usually a bit hard to read.

Re: Oh Shit, Git?

#156

Post by ryandrake »

ajross wrote: post #148
smrq wrote: post #139

Earlier quoted context omitted.

This sounds like the correct Git workflow if you think the correct VCS to use is SVN.

And that sounds like you failed to understand me. I didn't say "don't use branches". I said "all branches are remote". Pushing to a branch is communication with other human beings. Mixing your own private state into that is confusing and needless in 99% of situations (and the remaining 1% is isomorphic to "you're a maintainer curating branches for pushing to other people at a well-known location"). All branches are p…

I have quite a few projects that do not have a "remote" and will probably never have a remote repo. Should I not be using branches at all?

Re: Oh Shit, Git?

#157

Post by recursive »

baobun wrote: post #150
ajross wrote: post #134

Earlier quoted context omitted.

True enough, but it does make for good practice with the index and splitting workflows later on when you need to clean it up. I think there's space for "git add ." as a didactic step. It maps cleanly to the most obvious way to understand a commit, as "here's what I've done". Bootstrapping from that to an understanding of "commits as communication with other developers" will naturally happen over time.

Is not very compatible with printlog-debugging. I'd rather encourage devs to prod around as they go if it benefits them, which causes grief for either them or reviewers in the end if they've internalized what you just said. Explicitly adding internalizes a personal review process as inherent part of the push process, instead of something you attempt to force on top later. It's better with a collaboration workflow tha…

You can have both. Make sure the whole diff is what you want it to be before invoking `add .`

Re: Oh Shit, Git?

#158

Post by snafferty »

ajross wrote: post #131
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…

> 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 complicated process compared to having a branch and rebasing onto the current branch when you finally go to make the change for real.

Re: Oh Shit, Git?

#159

Post by simoncion »

ajross wrote: post #148
smrq wrote: post #139

Earlier quoted context omitted.

This sounds like the correct Git workflow if you think the correct VCS to use is SVN.

And that sounds like you failed to understand me. I didn't say "don't use branches". I said "all branches are remote". Pushing to a branch is communication with other human beings. Mixing your own private state into that is confusing and needless in 99% of situations (and the remaining 1% is isomorphic to "you're a maintainer curating branches for pushing to other people at a well-known location"). All branches are p…

> All branches are public.

What actual problem does this solve? For me, WIP branches only ever get pushed up if at least one of two things are true about them:

1) They're actually worth preserving, and not some experimental garbage that ended up being totally pointless.

2) I need to get them off of my local machine for disaster-recovery purposes.

> If you need to manage local state, do it manually with tags (or stash, but IMHO I never remember what I stashed and will always make a dummy commit and tag it).

I don't see the benefit one gets from putting work that's not fit for publication in a dummy commit on a public branch. That's just asking for garbage that noone should concern themselves with to accidentally get pushed up at the end of a long-ass day.

Re: Oh Shit, Git?

#160

Post by stouset »

amanwithnoplan wrote: post #154
stouset wrote: post #121

Earlier quoted context omitted.

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…

Please kindly write one for a jj-specific issue: "my build vomitted out a bunch of files and I used any jj command before editing my .gitignore" I've found myself using git to fix the mess in this particular instance.

    $ jj file untrack {paths-or-pattern}
Alternatively if you have a bunch of files spewed everywhere with no rhyme or reason which can't be globbed or enumerated reasonably:

    $ jj status | grep '^A' | awk '{print $2}' | xargs jj file untrack
Post reply on HN