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

441–450 of 550 posts

Re: New in Git: switch and restore

#441

Post by pdimitar »

Shacklz wrote: post #289
lisper wrote: post #138

Earlier quoted context omitted.

See my earlier comment here: https://news.ycombinator.com/item?id=27580478

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 move out of the way which GIT absolutely does not do.

I know that one day I'll get completely sick of GIT and will research and learn it to the bone. Sure, it's bound to happen. But the fact that GIT imposes its internal data model on you and doesn't attempt to solve more problems for you from the get go is what many of us are ticked off about.

Re: New in Git: switch and restore

#442

Post by Arch-TK »

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…

So putting aside your argument that I completely disagree with but a lot of people have already voiced my concerns.

> The guy who knows every command of git backwards is welcome to apply for a job managing a git repo or something if such a thing exists?

Yes, this is the job of a maintainer in fact. They exist in a variety of organisations but maybe not enough. The best example is the linux kernel. Developers are expected to maintain their own local tree. When it comes to contributing code to the kernel, the patches are sent in a standardised manner to a mailing list and a maintainer then handles dealing with branches, rebases and merges. This means that developers don't need to know any more git than they really want to learn, aside from how to use git-format-patch and git-send-email which are really quite simple tools with an incredibly vast number of tutorials out there explaining them.

This means that people who insist that it's "not their job" to learn git can achieve the requirements of "patches which build at every step and contain isolated step by step changes" using a GUI or doing something really stupid like copying the code aside, deleting and re-cloning the repository and then pasting and committing each step. It also means that people who actually know how to use git can get the job done in a fraction of the time.

It also means that a carpenter^Wdeveloper's insistence to not learn how to use a claw hammer^W^W^Wgit will not affect their fellow coworkers/cocontributors.

Re: New in Git: switch and restore

#443

Post by tehbeard »

laumars wrote: post #375
tehbeard wrote: post #357

Earlier quoted context omitted.

> which reads like a potential issue with their own ego: where they didn't want to be shown up in an unfamiliar UI > What there should be is shame ... those who don’t offer up their help to others I read it more as, I don't want to be become L1 Tech Support for something I don't know either.

What happens when the GP runs into an issue themselves. Do their colleagues help him or return the same cold shoulder? Computers are sufficiently advanced that there will always be blind spots in your team. Sometimes that means working together as a team to figure them out. Which is the kind of behaviour a good manager should encourage and the sort of attitude a good senior engineer should have already learned.

The issue isn't the technical complexity, it's the office politics.

If they fix it, do they then become responsible for fixing it in future? Is this now a "responsibility" the "company" (coworkers) expects of them, with no compensation? In addition to their existing responsibilities?

I introduced git to the company I'm at (previously on SVN running on an old beige box in the corner). It made collaboration easier. I accepted the fact I'll get pinged whenever someone makes git do a weird thing, but I'm lucky that for the most part coworkers learn from these incidents rather than coming back each time with the same issues.

Re: New in Git: switch and restore

#444

Post by mikro2nd »

a-dub wrote: post #281
cannabis_sam wrote: post #240

Earlier quoted context omitted.

This is my main gripe about git, it’s literally a tool created to suit the guy managing the linux kernel development via mailing lists… What proportion of junior developers are even tangentially working on anything resembling that? Even if it’s exceptionally wonky, I have absolutely no problem introducing git to new devs, as long as it’s alongside a graphical representation (sourcetree or some ide-extension), and as…

> This is my main gripe about git, it’s literally a tool created to suit the guy managing the linux kernel development via mailing lists… What proportion of junior developers are even tangentially working on anything resembling that? always did give me a chuckle how it took off the way it did for projects that don't come even remotely close to the scalability (like tree sizes) it provides. the facts that it's free, f…

I view it as a sort of hero-worship/cargo-cult thing... "Linus uses it (wrote it) so it must be the best!"

Re: New in Git: switch and restore

#445

Post by adrianN »

_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…

It's not like there aren't more than ten different tools that do approximately what git does, but a little differently. There are also dozens of UIs on top of git. So the response to git's UI is not uniformly "RTFM", many people tried to provide alternatives.

Re: New in Git: switch and restore

#446

Post by alkonaut »

awestroke wrote: post #431
alkonaut wrote: post #421

Earlier quoted context omitted.

Probably. But choosing the wrong-but-consistent flag would have been easier to learn and remember. I don’t think anyone will consider different git commands as old/new, or core/porcelain or whatever it is. I just want semantical “delete” to have the same switch name, for example.

-c is for create. Very easy to remember.

Yes. But when I remember to git checkout -c to “create” it doesn’t help me much.

Re: New in Git: switch and restore

#447

Post by mikro2nd »

Dudeman112 wrote: post #379
tehbeard wrote: post #352

Earlier quoted context omitted.

> Git probably has its place, but only on very specific, large scale projects, with a crack core team and hundreds of drive-by contributors ? So, hypothetically, if that were the case, what is the recommendation for Small/Medium web agencies?

No versioning at all, of course. On a more serious note, I wonder if GP ever worked on projects outside of large enterprises and is just gatekeeping it. Git is useful on solo projects, for God's sake.

Useful? Yes. Way overkill? Also yes (imho).

HG is simpler to understand, has a more consistent CLI, and way better error messaging. Just a pity that it's been so sorely overshadowed by the Swiss Army Chainsaw of VCS.

Git can certainly do almost anything/everything anybody might want from a VCS, but, just like a chainsaw, it'll cut your leg off just as soon as it'll cut off the branch you're pruning if you're not fully expert in using it.

Re: New in Git: switch and restore

#448

Post by bicolao »

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

Re: New in Git: switch and restore

#449

Post by yakubin »

danw1979 wrote: post #434
yakubin wrote: post #32

Earlier quoted context omitted.

If someone pushed a branch to remote, then there is a chance that they made a CI build for a customer based on that branch. Later you may need that branch to look at the source code, when you get a coredump, or logs or something. (Every non-official build is made from a separate branch.)

tags might be a more suitable way of... tagging those releases for future reference ?

https://news.ycombinator.com/item?id=28025573

Re: New in Git: switch and restore

#450

Post by bicolao »

leephillips wrote: post #90
layoutIfNeeded wrote: post #46

No thanks, I will keep using checkout.

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?

The two are added with some extra protections. Something that cannot be done with git-checkout without breaking scripts.

I believe git-checkout could silently overwrite data in one case (can't remembe the details). And git-swith will stop you from moving the branch when you're in a middle of a rebase or other multi-command operations. It also tries to avoid entering detached HEAD mode by default.

It's definitely geared towards newcomers. But even I'm glad it catches me from doing stupid things from time to time.

Post reply on HN