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

501–510 of 550 posts

Re: New in Git: switch and restore

#501

Post by cryptonector »

quickthrower2 wrote: post #453
cryptonector wrote: post #403

Earlier quoted context omitted.

Merging makes life harder for others , and easier for you . Rebasing does the opposite, but has other benefits.

It only makes a difference if everything is fast forwarded onto master. If branches are squash merged in (as is common), keeping those merged in branches up to date via merges or rebasing doesn't make much difference to others. If you are chucking all your commits onto master - power to you. That's probably a good pattern (I prefer as much historical data as possible to a 'neat' commit history), but I never see it do…

Master or any branch you're aiming to integrate into.

Squashing everything is bad because it makes code review and backports harder. Maybe you don't care about backports, but if you care about code reviews...

Re: New in Git: switch and restore

#502

Post by CRConrad »

lisper wrote: post #337
Shacklz wrote: post #289

Earlier quoted context omitted.

Regarding your first point (and I think some of the commenters in that thread also address this already) is that as long you don't have uncommitted changes, you're safe. You're right that a lot of git-commands mess with uncommitted changes in hard-to-recoverable ways, but once changes are committed, there's almost no way to mess anything up, you can always go back to the previous state (git reflog telling you which c…

Yeah. That clarified everything.

Honestly, if you were less busy sulking about it you might have had some capacity left to be receptive, in stead... And then it might actually have helped clarify a lot.

Also: In a discussion where one party is being helpful and the other sullenly sarcastic, it's not the helpful one that comes off as an asshole.

Re: New in Git: switch and restore

#503

Post by CRConrad »

cush wrote: post #154
hkopp wrote: post #49

My git productivity hack is `git diff --color-words`. Instead of showing the line-by-line diff, it shows only the words that changed. Especially useful if you have long sentences where only a comma changed or some other typo. With git diff, the two lines are shown, with --color-words, only the changed symbol is highlighted. The option --color-words also works with git show. I even made aliases for them: git cshow and…

> properly Or maybe just don't shame people for not working the way you do.

If one guy says "This shit doesn't work!" and the other says "This is how it works", then it seems more like knowing how it works, well, properly than "shaming".

Re: New in Git: switch and restore

#504

Post by quickthrower2 »

cryptonector wrote: post #501
quickthrower2 wrote: post #453

Earlier quoted context omitted.

It only makes a difference if everything is fast forwarded onto master. If branches are squash merged in (as is common), keeping those merged in branches up to date via merges or rebasing doesn't make much difference to others. If you are chucking all your commits onto master - power to you. That's probably a good pattern (I prefer as much historical data as possible to a 'neat' commit history), but I never see it do…

Master or any branch you're aiming to integrate into. Squashing everything is bad because it makes code review and backports harder. Maybe you don't care about backports, but if you care about code reviews...

We code review unsquashed branches.

Honestly I just diff the whole thing from where they branched to the tip anyway I rarely find the individual commits useful as there is usually a process of their discovery in that with backtracks etc. that’s a waste of time to review.

For example I could review a new class that they heavily refactored in the next commit.

I’ve not had an issue with code reviews or backporting. I suspect this is because either out units of work are smaller than usual (no long feature branches)

But maybe you are onto something here and I’m missing out on a better way but I’ve not experienced enough pain in squashing on merge to master to contemplate switching to a rebase workflow (which means convincing team members too)

Re: New in Git: switch and restore

#505

Post by CRConrad »

alkonaut wrote: post #422
eevilspock wrote: post #405

Earlier quoted context omitted.

The purpose of `git switch` is to switch branches, and its normal argument is a branch ref. Thus -b for "branch" would be redundant and confusing. -c is for "create", i.e. create the branch that i want to switch to. The whole point of adding git switch and git restore is to come up with more user friendly porcelain. Otherwise we might as well stick with git checkout. git checkout is maximally consistent with git chec…

How does -b mean “create” in checkout? I get that it means “branch” but why is “branch” what I use to create a new one? The problem here is obviously the choice made for checkout, not switch. But consistency is more important so it’s better to keep consistency than “correctness” here imo. This problem already happened in the past with -d (delete).

> How does -b mean “create” in checkout? I get that it means “branch” but why is “branch” what I use to create a new one?

Because you can "checkout" other stuff too, not just branches.

> But consistency is more important so it’s better to keep consistency than “correctness” here imo.

Huh? I thought the whole point of these new commands was to try and fix the old illogical command line interface. Since one of the main problems -- probably the main problem -- is precisely the lack of consistency, the new ones logically just cannot be consistent with all the old ones, because then they would be just as inconsistent among themselves as the old ones. Something somewhere has to give. (And IMO this "-b" seems as good a candidate for the chop as any.)

Re: New in Git: switch and restore

#506

Post by mixmastamyk »

ivanche wrote: post #491
mixmastamyk wrote: post #435

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. So I go back to merging the main branch into my feature branch workflow, which works every time. I then hit squash in gitlab for my merge request, and no one is the wiser. Should I be doing something different? As I said, rebase in that situation is disastrous. Many folks rec…

> 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 (git pull --rebase origin develop) often almost every file in the project is in conflict, and the conflicts themselves are incomprehensible. I then run rebase --abort and go back to the merge strategy.

I've tried this about four times in the last few years; no one is able to explain what went wrong. If I had to guess it may have something to do with me pushing the branch when creating it.

Re: New in Git: switch and restore

#507

Post by mixmastamyk »

Shacklz wrote: post #472
mixmastamyk wrote: post #435

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. So I go back to merging the main branch into my feature branch workflow, which works every time. I then hit squash in gitlab for my merge request, and no one is the wiser. Should I be doing something different? As I said, rebase in that situation is disastrous. Many folks rec…

> Unfortunately, it always results in scary conflicts. I think you're referring to what I call "conflict cascades"? E.g., you're 4 commits ahead of "master", and want to rebase on top of it - but you have a conflict with your first commit, and after you resolve it, this results in conflicts in the second one, etc.? It's a very interesting question because it's one of the main pain points of rebase that simply does no…

Not really. I give up on the first conflict, because dozens of files are in conflict and they are often incomprehensible.

Re: New in Git: switch and restore

#508

Post by CRConrad »

alkonaut wrote: post #460
eevilspock wrote: post #438

Earlier quoted context omitted.

Keep in mind this is your opinion. Unless you've done a poll of users (my comment is getting a lot of upvotes), you have no idea what most people prefer. I can come up with more reasons why -c is better, why consistency in this case is not an issue, and why -b makes sense for checkout, but it's not worth the time debating opinions on a done deal . The only reason I bothered commenting is your comment pretty much call…

I don’t have as much issue with this particular switch as I do with the taped together ball of aggregated mud that is the existing set of git commands. Those are the reason I found this particular one amusing. I would have preferrec consistency over intuitive (or allowing both!) but as you say I have no idea what a majority of users would prefer. I’m pretty sure whoever chose this doesn’t either (another problem with…

> I don’t have as much issue with this particular switch as I do with the taped together ball of aggregated mud that is the existing set of git commands. Those are the reason I found this particular one amusing. I would have preferrec consistency over intuitive

Seems unreasonable:

* The problem with the "taped together ball of aggregated mud" is that commands and switches are illogical and inconsistent.

* These new commands are an attempt to fix that by introducing a set of (AIUI) parallel commands with better internal consistency.

* And now your complaint is that the new ones aren't consistent with the old ones?

No, of fucking course they aren't consistent with the old inconsistent ones. That's the whole point: If they were consistent with the inconsistent ones, they would also be inconsistent.

Re: New in Git: switch and restore

#509

Post by alkonaut »

CRConrad wrote: post #505
alkonaut wrote: post #422

Earlier quoted context omitted.

How does -b mean “create” in checkout? I get that it means “branch” but why is “branch” what I use to create a new one? The problem here is obviously the choice made for checkout, not switch. But consistency is more important so it’s better to keep consistency than “correctness” here imo. This problem already happened in the past with -d (delete).

> How does -b mean “create” in checkout? I get that it means “branch” but why is “branch” what I use to create a new one? Because you can "checkout" other stuff too, not just branches. > But consistency is more important so it’s better to keep consistency than “correctness” here imo. Huh? I thought the whole point of these new commands was to try and fix the old illogical command line interface. Since one of the main…

Yes - if this is meant to be a whole new set of commands which are internally consistent and can be used without using the others, then it makes sense to do it right.

But is that the case? Won’t this just be used in addition to the old commands (except checkout)?

The worst case would be adding commands that attempt to fix an UX but which don’t replace it, creating two separate UXes you must use at the same time. Anyone who uses the Windows control panel knows.

Re: New in Git: switch and restore

#510

Post by CRConrad »

ExtraE wrote: post #466
hrishi wrote: post #298

I have taken git apart and learned it three times now, and it all makes sense to me. The commands however, never clicked. The terminology never felt intuitive, nor predictably applied. So I can explain how git works in great detail, but ask me how to perform an action I haven't in a month, and it's a lot like figuring our a tar command.

Is there space in the world for an all new (v2) set of porcelain commands? (IMO yes)

Is this perhaps exactly what "switch" and "restore" are -- the first of that new set? (I think they may be.)
Post reply on HN