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

531–540 of 550 posts

Re: New in Git: switch and restore

#531

Post by schlupa »

mixmastamyk wrote: post #506
ivanche wrote: post #491

Earlier quoted context omitted.

> I've tried the "rebase into a feature branch" workflow, which I think you are alluding to. Unfortunately, it always results in scary conflicts. You never rebase something into something else, you rebase onto something. I suppose you meant you want to rebase feature branch onto master. If you have conflicts, you'll have them anyway, regardless if you're merging feature branch into master, merging master into feature…

I'm working in a feature branch, and after a day or three changes have landed in the main branch. Which I need to incorporate or my merge request will be behind. When I pull from main (git pull origin develop) there are rarely conflicts. When there are they are easy to understand and fix. Clicking squash on my request hides all intermediate commits so history stays clear in any case. When I try to rebase from main (g…

That's not how you do it.

    git checkout master     
    git pull             => fetch and merge the new things on master
    git checkout develop => go back to your work branch
    git rebase master    => simple rebase, no squash, no nothing. The conflicts are the same as you'd get with git merge
do not forget to force push the changes of your branch

    git push origin --force develop => to update your branch on the server

Re: New in Git: switch and restore

#532

Post by juped »

bicolao wrote: post #448
juped wrote: post #294

They're several years old, but Duy Nguyen who invented them hasn't been around that much recently, which is why they're still marked "experimental".

Well, I'm him :) I actually left Git. And it looks like nobody has picked it up since. So it's going to be forever "experimental" [1] until either someone starts doing something, or deletes the whole thing [1] The experimental status is not because it's unstable but rather to allow us (or now, them) to change the UI design based on feedback if we got it wrong (again!).

They are good features! I think they should just be made stable. Most of the help messages direct you to them anyway.

Re: New in Git: switch and restore

#533

Post by Shacklz »

schlupa wrote: post #531
mixmastamyk wrote: post #506

Earlier quoted context omitted.

I'm working in a feature branch, and after a day or three changes have landed in the main branch. Which I need to incorporate or my merge request will be behind. When I pull from main (git pull origin develop) there are rarely conflicts. When there are they are easy to understand and fix. Clicking squash on my request hides all intermediate commits so history stays clear in any case. When I try to rebase from main (g…

That's not how you do it. git checkout master git pull => fetch and merge the new things on master git checkout develop => go back to your work branch git rebase master => simple rebase, no squash, no nothing. The conflicts are the same as you'd get with git merge do not forget to force push the changes of your branch git push origin --force develop => to update your branch on the server

You can skip the "checkout master + pull" part by using "git fetch origin master:master", or by using just "git fetch origin" and then "git rebase origin/master". Other than that, that's pretty much my workflow too :)

Re: New in Git: switch and restore

#534

Post by ivanbakel »

void_mint wrote: post #496
ivanbakel wrote: post #455

Earlier quoted context omitted.

>And yet, with Git, the response just seems to be "if you don't like it you must just not _get it_." Which, I guess is fair, but I don't particularly understand why everyone has to "get it"? Why can't we expect a tool that's used by so many be intuitive? There are lots of UIs for git - many people on this forum will advocate for using one. My personal experience is that a UI manages to over-simplify the git workflow.…

> And that's a problem with lots of technical teaching, not just git. Since the focus is on getting immediate observable results, and not on conceptual understanding, users tend to learn how to use tools instead of how they work. That creates a culture of "I don't know what this is doing, and I'm too scared to mess with it" - basically the anti-hacker mentality. yeah I guess I don't really align with the "Developers…

>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 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.

Lots of users treat git as a small set of known commands that they execute in sequence until the repo is in the state they want; and any deviation from that happy path is met with a repo wipe and re-clone. A hacker should be happy to play around with various man pages and commands to build an understanding of what each command really does - and then be able to fearlessly mix and match commands, because they know how they are affecting the repo at each step.

Re: New in Git: switch and restore

#535

Post by schlupa »

Shacklz wrote: post #533
schlupa wrote: post #531

Earlier quoted context omitted.

That's not how you do it. git checkout master git pull => fetch and merge the new things on master git checkout develop => go back to your work branch git rebase master => simple rebase, no squash, no nothing. The conflicts are the same as you'd get with git merge do not forget to force push the changes of your branch git push origin --force develop => to update your branch on the server

You can skip the "checkout master + pull" part by using "git fetch origin master:master", or by using just "git fetch origin" and then "git rebase origin/master". Other than that, that's pretty much my workflow too :)

Yes, I know. I just wanted to keep it at the simplest form.

Re: New in Git: switch and restore

#536

Post by djmips »

nerfbatplz wrote: post #279
aetherspawn wrote: post #73

A lot of comments along the lines of ‘why do people use instead of learning the commands’. For me, I used to use the terminal git, and I still do occasionally. But I use Sourcetree now for most things because I make less mistakes seeing the tree visually all the time. My job isn’t to use git, it’s to write specialist software. If I get the software written and the customer is happy, it doesn’t matter whether I use or…

Except for 99% of all git day to day tasks are done with like 7 commands. Git commit Git checkout Git merge Git pull Git push Git rebase Git stash I can’t remember I needed a command that wasn’t one of those and I exclusively use the cli.

It's funny but I forgot that Git restore was a new command, it only came in 2019 but I use it all the time.

Re: New in Git: switch and restore

#537

Post by mschout »

adwww wrote: post #336
nerfbatplz wrote: post #279

Earlier quoted context omitted.

Except for 99% of all git day to day tasks are done with like 7 commands. Git commit Git checkout Git merge Git pull Git push Git rebase Git stash I can’t remember I needed a command that wasn’t one of those and I exclusively use the cli.

I seem to use cherry-pick at least monthly, as well as log and diff.

I was gonna say cherry-pick is farily frequent for me. Also I seem to learn new variations once in a blue moon for common commands. E.g. recently I learned about the --cherry option for git-log and it changed my life.

Re: New in Git: switch and restore

#538

Post by mixmastamyk »

schlupa wrote: post #535
Shacklz wrote: post #533

Earlier quoted context omitted.

You can skip the "checkout master + pull" part by using "git fetch origin master:master", or by using just "git fetch origin" and then "git rebase origin/master". Other than that, that's pretty much my workflow too :)

Yes, I know. I just wanted to keep it at the simplest form.

Ok, thanks. Although making a one step process into five, doesn’t sound like a big win. Perhaps the shorter version is workable.

Re: New in Git: switch and restore

#539

Post by void_mint »

ivanbakel wrote: post #534
void_mint wrote: post #496

Earlier quoted context omitted.

> And that's a problem with lots of technical teaching, not just git. Since the focus is on getting immediate observable results, and not on conceptual understanding, users tend to learn how to use tools instead of how they work. That creates a culture of "I don't know what this is doing, and I'm too scared to mess with it" - basically the anti-hacker mentality. yeah I guess I don't really align with the "Developers…

>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 really does - and then be able to fearlessly mix and match commands, because they know how they are affecting the repo at each step.

No true scotsman would use git without reading books about it!

This is just nonsense. Gatekeeping holier than thou nonsense.

Re: New in Git: switch and restore

#540

Post by greatgib »

chungy wrote: post #311
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.

-- 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!
Post reply on HN