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

New in Git: switch and restore

banterly.net

Post reply on HN
Print view View original

541–550 of 550 posts

Re: New in Git: switch and restore

#541

Post by greatgib »

Denvercoder9 wrote: post #463
greatgib wrote: post #168

Earlier quoted context omitted.

Thank you very much for this info. From the article, I was thinking that it was again a stupid confusing design for the cli to requires the -- even with a dedicated command. One main issue with git is to not be consistent and logic with the comments. Always to use different way or option abbreviation for different command. For example having a space or a slash between repo and a branch in a command.

> For example having a space or a slash between repo and a branch in a command. Actually, this one makes sense, once you understand the underlying model of how git works with remote repositories, which (imo) is fairly fundamental to a distributed VCS. They're different arguments (in your words, having a space) when you're accessing remote repositories and have to specify the location it should access. You can always…

I think you give a general explanation of what you would like the reason to be but it does not match the commands:

git fetch origin main

git rebase -i origin/main

Git push origin localBranch:remoteBranch

For example, why not:

git push origin/remoteBranch localBranch

(And if you want to preserve saying that slash is just for local, you could say: origin:remoteBranch)

Re: New in Git: switch and restore

#542

Post by vasergen »

bspammer wrote: post #123
yunohn wrote: post #78

Earlier quoted context omitted.

This is an unnecessarily antagonistic rant, which boils down to “I know git from scratch, I’m so smart, why isn’t everyone else doing this”. Git is a very complicated, bloated command line. Frankly, most of the day-to-day can easily be done with a high level understanding and a GUI. There is no shame in not knowing the minutiae of git. The goal of being a programmer is to produce cool things, not to duel with your to…

The irony with git is that the underlying data model is far simpler than the user interface implies. People assume git is complicated because the user interface is complicated, but it really is very simple under the hood. So much so that you can write your own basic version of git in a couple of hours: https://wyag.thb.lt/

Thanks for the link, really interesting

Re: New in Git: switch and restore

#543

Post by sheen »

void_mint wrote: post #539
ivanbakel wrote: post #534

Earlier quoted context omitted.

>I don't really align with the "Developers must learn the internals of all of the technology they are required to touch" The DAG, commits, refs, etc. are not the "internals" of git - they are the basic building blocks of its mental model. Without them, there is no way to understand what git is doing - so it's no surprise many people think git is unintuitive, because they aren't taught what those concepts are. The thi…

> The thing I'm saying is counter to the hacker mentality is using a tool as a black box, without understanding what it does and what it is trying to do. You don't have to read the code and know all the technical details. And I'm saying that this statement is just hustle culture nonsense. > A hacker should be happy to play around with various man pages and commands to build an understanding of what each command reall…

Love the attitude. I also print out my man pages.

Re: New in Git: switch and restore

#544

Post by sharken »

CRConrad wrote: post #516
sharken wrote: post #335

Earlier quoted context omitted.

As someone about to migrate from Mercurial to Git i absolutely agree that Git is the superior tool. Pull Requests were never going to happen with Mercurial and it's also not possible to delete a branch without some black magic server-side. And with Git hopefully it will be possible to move to Trunk-based development, although that requires a lot more than just switching to Git.

> Pull Requests were never going to happen with Mercurial TBF, AIUI they're not, strictly speaking, happening with git either: They're an external addition, invented by GitHub or some such, and not actually part of git itself.

That is correct, but an important part of pull requests is that the pull request branch can be deleted afterwards.

Re: New in Git: switch and restore

#545

Post by CrazyPyroLinux »

IgorPartola wrote: post #487
CrazyPyroLinux wrote: post #229

Earlier quoted context omitted.

Yup - Every darn time. Reminds me of "How it feels to learn JavaScript in 2016" https://news.ycombinator.com/item?id=12628921

Nothing has changed in 5 years, has it?

The more things change, the more they stay the same

Re: New in Git: switch and restore

#546

Post by void_mint »

sheen wrote: post #543
void_mint wrote: post #539

Earlier quoted context omitted.

> The thing I'm saying is counter to the hacker mentality is using a tool as a black box, without understanding what it does and what it is trying to do. You don't have to read the code and know all the technical details. And I'm saying that this statement is just hustle culture nonsense. > A hacker should be happy to play around with various man pages and commands to build an understanding of what each command reall…

Love the attitude. I also print out my man pages.

I love that my comment was meaningful to you enough to make an account and comment.

Re: New in Git: switch and restore

#547

Post by chungy »

greatgib wrote: post #540
chungy wrote: post #311

Earlier quoted context omitted.

-- is typically to end argument processing and to treat all further ones as files. With git-restore, it's probably only relevant if you happen to have files in your repo that begin with hyphens. A fairly unusual situation, granted, but not forbidden.

Still does not really make sense. Because you can still quote the - if ever you had such a file, and most Unix tools have the -- optional only if you would need it. Not systematic!

How would you quote it, exactly? You have to remember that quotation marks are processed by the shell, not the program.

  ls -file
  ls "-file"
Both of these commands to ls will have an argv comprised of: ls, -file

Re: New in Git: switch and restore

#548

Post by CRConrad »

sharken wrote: post #544
CRConrad wrote: post #516

Earlier quoted context omitted.

> Pull Requests were never going to happen with Mercurial TBF, AIUI they're not, strictly speaking, happening with git either: They're an external addition, invented by GitHub or some such, and not actually part of git itself.

That is correct, but an important part of pull requests is that the pull request branch can be deleted afterwards.

How does that work; is it something technical built into it? Or do you mean just because after that one knows that it's incorporated upstream, so not needed as a separate entity any more? Because that would also go for a "pull request" by, say, e-mail or whatever.

Re: New in Git: switch and restore

#549

Post by dotancohen »

Shacklz wrote: post #493
dotancohen wrote: post #482

Earlier quoted context omitted.

I've never understood - or used - rebase as a standard part of a workflow. And I've been using git for nine years. What is wrong with a master branch whose history reads "Merged feature foo" after "Merged feature bar"? If you need more detail then check out the feature branch and git bisect to your heart's content. I do wish that we could "archive" branches from the output of `git branch -a` but really it's not a big…

I had this opinion for the longest of times as well, but me and all the other devs I know who started using a rebase-based approach just don't want to go back. I think it's also a bit a question of team size. If your project has just a handful of devs working on it, merge-commits really don't matter all that much. If there are a few dozen with a good amount of juniors on the repo (a bit over 40 devs in my case), the…

Sorry to beat a dead horse, but I'd love to be convinced. Could you give me an actual example where you were able to review a commit log that had been rebased easier than it would have been had been merged? Or an actual example where a merged commit log was a pain where it would have been easier had it been rebased?

Maybe the advantage is for people who use graphical tools? I'm still in the stone age using Git in bash.

Thanks.

Re: New in Git: switch and restore

#550

Post by neolefty »

quickthrower2 wrote: post #383
samatman wrote: post #295

Earlier quoted context omitted.

I'm mildly amused that your set of commands can't actually commit anything other than a brand-new file! I will admit that I'm a lazy git user, and do most of my commits with `git commit -a`, rather than `-am` since I do try and give a short paragraph explaining the reasoning behind whatever the title message claims is the purpose of the commit. I do run `git diff` first to see what I've changed, and if the diff has u…

I’m interested in how many people double check their changes before committing as I’ve done this since the days of sourcesafe, and a decent number of bugs I’ve seen are people just not checking what they committed (some stray change got in that they never intended)

Yes! I find that if I don't comment my PRs, my coworkers avoid them. But then in commenting them, I find quite a few ... not always errors, but cleanups at least.
Post reply on HN