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

Oh shit, git (2016)

ohshitgit.com

Post reply on HN
Print view View original

261–270 of 280 posts

Re: Oh shit, git (2016)

#261

Post by thatoneuser »

phaemon wrote: post #205
thatoneuser wrote: post #24

Earlier quoted context omitted.

OK hot shot. Tell everyone here how you've never fucked up commands and had to blow out a repo and start over and how were all idiots for having done that. It's a tool. Any tool can be confusing if the person isn't taught how to use it. Git requires teaching so there's a lot of room for misunderstanding.

> never fucked up commands and had to blow out a repo and start over You never have to do this, because it's virtually impossible to screw up a git repo with git commands, to the point it can't be easily fixed. And I'll tell you why and how. As you no doubt know, all commits in git are hashed. This means that you can't change a commit in any way, only ever add a new one. Neither can you insert a commit into an existi…

It's called sarcasm /s

Re: Oh shit, git (2016)

#262

Post by luxcem »

> I use reflog A LOT

If you need to reset with reflog a lot you're probably using git wrong.

Sure it can be useful but I don't see why it should be in a workflow.

Re: Oh shit, git (2016)

#263

Post by lmm »

mehrdadn wrote: post #253
lmm wrote: post #251

Earlier quoted context omitted.

> But then if they communicated to you (during stand-up of whatever) their branch is ready to be used to build on, then they've made that code public and would avoid force-pushing Every morning everyone mentions what they're working on (and so implicitly what their current branches are about). Most of the time there's no particular reason to pick their branch up, but sometimes there is. The only way that can work is…

> Anything that's pushed to the repo is presumed good to pick up, that's what the repo is for. If it's not ready for others to pick up then why push it to the repo at all? You push... because you have 2+ repos you want to sync? Because you don't want to lose data if you mess things up locally? Because the remote repo runs tests on push that you want to run before you've finished the entire branch? Because someone els…

> You push... because you have 2+ repos you want to sync? Because you don't want to lose data if you mess things up locally? Because the remote repo runs tests on push that you want to run before you've finished the entire branch? Because someone else needs to be able to pick up your code if you get hit by a bus tomorrow? Because your boss or coworkers might need to be able to look at your code in an emergency? There are a million reasons to push that don't imply every commit on every pushed branch being suitable for splitting into another branch...

They pretty much do though? If your team isn't in the habit of force-pushing then almost all commits are suitable for pulling into another branch, it's not some big deal that requires special preparation. If it's good enough to run remote tests on, it's compiling and presumably working locally. If it's good enough for someone else to pick up if you were hit by a bus, someone might want to pull from it anyway. If it's worth your boss or coworkers looking at in an emergency, it's worth them looking at in a non-emergency.

Of course pulling a co-worker's branch before it's made it into master will (generally) get you less polished code, with some risk that the remote tests will be broken, there will be code that would fail code review, etc.. That's understood and that's the price you pay for getting immediate access to their work-in-progress. It's still very worthwhile as a way to understand the direction of their changes and avoid a lot of unnecessary conflicts in the cases where you know you're working in the same area.

> What I was doing was explaining how/when it can be useful while avoiding the problems you're hoping to avoid if you haven't already dogmatically rejected the rebase workflow from the start.

You didn't explain anything! I gave a specific explanation of how rebasing will cause more conflicts than non-forcefully pushing new commits (and FWIW that comes from direct personal experience of both workflows). You went straight from arguing about terminology to accusing me of dogmatism.

Re: Oh shit, git (2016)

#264

Post by bicolao »

fouronnes3 wrote: post #189
bicolao wrote: post #97

Earlier quoted context omitted.

This particular pattern should be fixed in a future git (hopefully). There's a new command that supports all these git restore --staged file # reset the index from HEAD git restore --worktree file # reset the worktree from the index git restore --source=HEAD --staged --worktree file # reset both the index and worktree from HEAD Still in development [1] so if you think something can be improved, I'd love to hear it. […

Two things I don't like in your examples: First, the default source changes depending on the target. In my opinion it would be more intuitive and simple if the default source is always HEAD. The documentation for --source in your link probably makes sense for a git developer, but not at all for a user. (Especially the part about its default value if absent). Second, rename "--staged" to "--index". So in summary, to u…

Since this is posted on Git mailing list, the reply is here https://public-inbox.org/git/20190515103031.GA29149@ash/

Re: Oh shit, git (2016)

#265

Post by bicolao »

jnbiche wrote: post #147
bicolao wrote: post #97

Earlier quoted context omitted.

This particular pattern should be fixed in a future git (hopefully). There's a new command that supports all these git restore --staged file # reset the index from HEAD git restore --worktree file # reset the worktree from the index git restore --source=HEAD --staged --worktree file # reset both the index and worktree from HEAD Still in development [1] so if you think something can be improved, I'd love to hear it. […

imho the natural default for any of these types of commands should be to reset the worktree, never the index. In my experience, people almost always want to review a file before they stage it, even if it's coming from HEAD. So `git restore file` should reset the worktree, if you allow an unflagged version of that command.

"git restore file" does reset worktree. Sorry I didn't mention it. If neither --worktree or --staged is present, the default target is the worktree.

It still restores worktree from the index though. But if your workflow ignores the index, then index should be the same as HEAD. "restoring from index" and "restoring from HEAD" will mean the same thing.

Re: Oh shit, git (2016)

#266

Post by bicolao »

erik_seaberg wrote: post #232
jnbiche wrote: post #147

Earlier quoted context omitted.

imho the natural default for any of these types of commands should be to reset the worktree, never the index. In my experience, people almost always want to review a file before they stage it, even if it's coming from HEAD. So `git restore file` should reset the worktree, if you allow an unflagged version of that command.

I can't test the index. If the index and workspace are different, the index is wrong. I would like an option to make the index go away (or else become a buildable filesystem dir), and stash whatever I don't want to commit yet.

> I would like an option to make the index go away

By Git design, you will have to face the index when you have merge conflicts. I don't know how to avoid that (and now is not the time for fundamentally change how conflict resolution is done).

But yeah, the other times, I think you can just live just fine without knowing or touching the index.

> I can't test the index.

I'm not trying to convince you to use the index. But to me, the way I test the index is commit it. Then I could use "rebase -i" to revisit the old commits (i.e. the index content) and test or make more fixes if needed.

Re: Oh shit, git (2016)

#267

Post by bicolao »

mleonard wrote: post #153
bicolao wrote: post #113

Earlier quoted context omitted.

"git restore --staged" should be the same as "git reset -- file" (--mixed, --soft and --hard cannot be used with individual files). "git restore --worktree" is the same as "git checkout -- file". "git restore --source..." should be the same as "git reset --hard -- file" if --hard was made to work with individual files. Though "git restore" should make it clear (or clearer) to the user what they want to restore withou…

Thanks really very helpful! When you hoping to have git restore in the official git release?

> When you hoping to have git restore in the official git release?

If things go well, maybe v2.23.0, unless we find serious UX flaws and scrape the whole thing.

Re: Oh shit, git (2016)

#268

Post by bicolao »

mehrdadn wrote: post #100
bicolao wrote: post #98

Earlier quoted context omitted.

In a near future, hopefully we will have two new commands, git-switch and git-restore. The former is only about switching branches, the latter restoring files. Then you can stay away from the overloaded git-checkout. See https://github.com/git/git/blob/pu/Documentation/git-switch.... https://github.com/git/git/blob/pu/Documentation/git-restore...

That's awesome :) though this is just one way to lose files.

Yeah some of those ways are known and there may be a way to recover those lost changes. It's still too early to see if something will materialize.

Re: Oh shit, git (2016)

#269

Post by crispyambulance »

rstuart4133 wrote: post #255
sirsuki wrote: post #187

Earlier quoted context omitted.

The reason "the commands are so [messed]-up, inconsistent and counter-intuitive" is most likely that you expect the commands to represent your mental model of the system when in fact they represent the mental model of the system designers. I once felt it was weird till I dove in and looked at the underlying data model. Then It struck me and all the awkwardness evaporated and the commands actually make sense to me now…

> when in fact they represent the mental model of the system designers. It sure doesn't feel like that. Instead it feels rather like a lump of code I'm dealing with now. The needed to add feature X, so they did a brief look for the easiest place to bolt it on. In the code I'm dealing with now that meant y2k stuff was placed in with the tracing code, I presume because the trace headers were used everywhere y2k was nee…

That's the best and most plausible explanation I've heard for why the git CLI is the way it is.

IDE's do try to smooth the edges of working with git, but it's never optimal, I know because I do occasionally have to drop into the git commandline with visual studio. I think IDE integrations just plaster over the mess and cut-off access to stuff you actually need to use from time to time. In other words, I don't think it's feasible, for instance, to only use git through the visual studio IDE.

Every once in a while people will talk about "porcelain" in the git commandline-- it's the notion of creating "ergonomic" command line semantics that behind the scenes are just compositions of the traditional shitty git commands. While I appreciate the pun, it still seems like it is avoiding the root problem.

Ultimately, I just can't understand: why isn't it possible to "clean up" the git CLI so that it's coherent and semantically compatible with how people use the thing? A million or so people use this tool for countless numbers of projects. How much time and effort could be saved by making it so that people can just remember commands, use them effectively, and stop having to throw away work again and again by blowing away folders and starting over with a "fresh" clone... simply because it's easier to start-over than to figure out the correct incantations when you're under time pressure?

Re: Oh shit, git (2016)

#270

Post by phaemon »

thatoneuser wrote: post #261
phaemon wrote: post #205

Earlier quoted context omitted.

> never fucked up commands and had to blow out a repo and start over You never have to do this, because it's virtually impossible to screw up a git repo with git commands, to the point it can't be easily fixed. And I'll tell you why and how. As you no doubt know, all commits in git are hashed. This means that you can't change a commit in any way, only ever add a new one. Neither can you insert a commit into an existi…

It's called sarcasm /s

Yes, I'm aware you were attempting sarcasm, but it wasn't very good, was it? I thought it would be kinder to ignore it and post something useful. The phrase you're looking for is, "thank you".

Cheers!

Post reply on HN