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

461–470 of 550 posts

Re: New in Git: switch and restore

#461

Post by afiori »

Arch-TK wrote: post #440
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 don't know, most people I've seen "scared" by merge/rebase conflicts have simply been scared by the UI provided to resolve them. It's just a matter of spending a bit of time familiarising yourself with what you're seeing and understanding what the tools are doing. There's a bunch of resources on that and once you wrap your head around what git is doing it shouldn't be too hard to figure out how to navigate conflict…

Merge conflicts in a rebase can propagate through every commit in your feature branch (suppose that you modify a boilerplate line in 10 commits, and you get a conflict on that line in the rebase, you now have to solve that conflict 10 times possibly with some interference with nearby conflicts)

In many cases also there are problems with git being line oriented rather than token oriented, IMHO I would have expected language aware diffs (for definition of "words" and maybe parenthesis) for common languaged to be common place by now (maybe even with a language server support)

In my team we are lucky as most conflict are a matter of simply choosing a side and overwriting the other.

Re: New in Git: switch and restore

#462

Post by Denvercoder9 »

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.

You're expecting the impossible. The current set of commands isn't great, everyone agrees on that, but they're too engraved in the minds of millions of developers to change. Thus, to solve the problem, the git developers come up with a new set of commands. By definition they won't be consistent with the current set of commands, as they're meant to solve the problems the current set has.

You have an issue with the new commands not being compatible, but you also have an issue with the old commands, that the new commands would replicate if they were compatible. What do you actually expect the developers to do?

Re: New in Git: switch and restore

#463

Post by Denvercoder9 »

greatgib wrote: post #168
bicolao wrote: post #4

You don't need -- as much in the "git restore" example. With git checkout it may be necessary to separate the branch and the paths with "--" but since "git restore" does not take a branch (except with -s), doing this is totally fine git restore test.txt

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 substitute an URL for a repo in this case, and they fail if you cannot connect to the remote repository.

In all other cases (having a slash), you're referencing a ref in your local repository. This is a local copy of the remote repository. That means that it always works offline, but also that it doesn't sync with the remote repository. You can also substitute another ref, such as a "local" branch.

Re: New in Git: switch and restore

#464

Post by alkonaut »

Denvercoder9 wrote: post #462
alkonaut wrote: post #460

Earlier quoted context omitted.

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. You're expecting the impossible. The current set of commands isn't great, everyone agrees on that, but they're too engraved in the minds of millions of developers to change. Thus, to solve the problem, the git developers come up with a new set of commands. By defini…

I think the idea of a new set is great, but then I think it needs to have a bigger scope than this pair of commands. Perhaps a whole new suite that is consistent and can replace most if not all typical tasks. If this pair of commands is part of a larger suite of porcelain that is internally consistent that’s great. Or at least part of a design or plan for such a “new toolset” where more commands will follow - that’s also a good solution. The important bit is the design process and long term plans so it isn’t just more slow aggregating which was how git got into the current state in the first place.

If there is more to this retooling project than meets the eye (in this article) then great. My fear is that it’s more inconsistent aggregation, again - but it’s not obviously the case of course.

Re: New in Git: switch and restore

#465

Post by oauea »

toxik wrote: post #99
oauea wrote: post #82

Earlier quoted context omitted.

All visual git tools I've used suck and wound up eventually corrupting the repo. Also I've noticed that all of my colleagues who learned git using these visual tools didn't actually learn git, and have no idea how to anything other than add/commit/push. I say "just rebase your branch" and I can see the panic grow in their eyes.

For these people, I think a manual backup is what they actually want. “If I fuck up so bad I have to roll back.” I don’t think it’s wrong necessarily either, and GitHub actually encourages this behavior with the easy Web file uploads. Many repositories are now 99% automatically created commits by drag and drop. I think these people would be better served by a backup system where you can pin snapshots. They don’t real…

Too bad for them, because they're (supposedly) professional software developers hired to work on this project and the project uses git.

Re: New in Git: switch and restore

#466

Post by ExtraE »

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)

Re: New in Git: switch and restore

#467

Post by Denvercoder9 »

layoutIfNeeded wrote: post #112
leephillips wrote: post #90

Earlier quoted context omitted.

Me too. The checkout command makes sense and seems consistent to me: check out branches or files. Why do I need two other different commands for this?

Exactly. The way I see it is that “checkout” has two arguments: - the commit you want to checkout, which defaults to HEAD - the files you want to checkout, which defaults to everything Simple as.

The problem is that this breaks down when you specify both arguments. Doing `git checkout branch file` checks out file from branch to the working tree, but doesn't change HEAD.

Re: New in Git: switch and restore

#468

Post by Shacklz »

pdimitar wrote: post #441
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…

LOL. :D I really am not sure if you were being sarcastic or are really that unaware what a mish-mash of specialized jargon you just threw at the guy. Don't think you the proponents actually understand the problem. It's not that programmers are unwilling to learn (something that many elitistic people love to pretend so they look smarter), it's something called tool fatigue. You just want your tools to do their job and…

> I really am not sure if you were being sarcastic

I was not :P But the commenter also said in the linked comment that they "understand how git works", so I took the liberty to make a few assumptions ;)

> But the fact that GIT imposes its internal data model on you

It does, to some degree, but once you get a grip of "everyday commands" that go beyond commit/merge (cherry-pick, rebase, reset, reflog), it's actually almost surprising how little you have to know about gits internals. It does help to have an idea about them, though.

My main complaint about git is that most commands have too many options that make it do too many different things. And that resolving conflicts via command line is absolutely atrocious (something I actively avoid and discourage).

> I know that one day I'll get completely sick of GIT and will research and learn it to the bone

I can only recommend it! It's really not that hard as many people suspect (as I've mentioned, I have a bit of a habit of teaching people git at work). If you had any exposure to something computer science in the past, the puzzle pieces probably start to come together after some hours.

And it's probably one of the longer-lasting constants in our industry, so in my opinion, it's really worth it to know how to make good use of it.

Re: New in Git: switch and restore

#469

Post by papito »

_6pvr wrote: post #428
lisper wrote: post #94

Earlier quoted context omitted.

> Other than that, I recommend that people learn to use git properly. Sorry to be harsh here, but that is completely useless advice. It's a tautology. Of course people should learn to use git "properly". What's the alternative, that they should learn to use it improperly? Everyone should learn to use everything properly. It's like telling someone dealing with a crisis that they should "take appropriate action", as if…

I've always found it interesting that Git gets a pass for its horrible UX by so many devs. The programming community wants to provide too many options for _everything_. If there's a tool you don't like, there are probably 10 other versions that do similar enough things that you can just switch. Devs are harshly critical of tools. And yet, with Git, the response just seems to be "if you don't like it you must just not…

I use SmartGit (there are many other visual tools), as I have no interest in untangling the utterly hostile Git command-line interface. Using the terminal to stage chunks of a file? No thanks.

I feel no embarrassment about it either. You may pride yourself in using Vim, while working on a multi-thousand-file project. You are a power user, good for you. Now go collect other time-wasting useless accolades, like Pokemons.

Re: New in Git: switch and restore

#470

Post by papito »

lisper wrote: post #94
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…

> Other than that, I recommend that people learn to use git properly. Sorry to be harsh here, but that is completely useless advice. It's a tautology. Of course people should learn to use git "properly". What's the alternative, that they should learn to use it improperly? Everyone should learn to use everything properly. It's like telling someone dealing with a crisis that they should "take appropriate action", as if…

The alternative may be Mercurial?
Post reply on HN