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

471–480 of 550 posts

Re: New in Git: switch and restore

#471

Post by oauea »

quietbritishjim wrote: post #100
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.

> I say "just rebase your branch" and I can see the panic grow in their eyes. The irony of that is that resolving conflicts in a complicated multi-commit rebase is much more easily/efficiently done in a good GUI than on the command line. Not all GUIs support it though (I think SourceTree gives up if there's a conflict), in fact it's a bit of an acid test for a Git GUI. The Jetbrains IDEs (PyCharm, CLion, IDEA, etc.)…

I actually agree, using a nice GUI to handle your merges is a godsend. If you know how to use it properly, and still know how to do more advanced operations as well.

Re: New in Git: switch and restore

#472

Post by Shacklz »

mixmastamyk wrote: post #435
Shacklz wrote: post #131

Earlier quoted context omitted.

> Figuring out what "properly" means is the whole problem with git. I think you've missed OPs point by focusing too much on a single word ('properly'). Yes, there's no clear-cut way on how to use git, no silver bullet, but the main problem with git is that most devs simply panic when they have to do anything that goes beyond the bog-standard commit/pull/push/merge. Rebase? Squash? Reset? Rebase interactively? I think…

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 not exist with merge.

What I've found for myself is that it's very important to create "atomic commits", which do not rely on other commits to make sense or "be complete". For example, a very common thing that I see is "fix formatting", "fix tests" commits, because some build was complaining about something being broken. And it's often these kind of commits that create weird conflicts (especially the formatting ones) because just a lot of code is moved/refactored/added/removed etc.

But do these commits make sense on their own? For example, if you have a history as follows:

     Introduce new fancy feature
     Fix formatting
     Fix tests
Does it make sense to ever check out ? No, right, because that commit is broken - wrong formatting, broken tests. What you want is always . So why not just adding those changes directly to commit-1 by using commit --amend when committing or by using fixup in an interactive rebase.

This was of course just an example, but in my experience, if people follow these kinds of trains of thoughts - what can be in a separate commit, what should be together, etc., there is an inherently smaller conflict-cascade-potential, which pays off a lot when rebasing. On top of that, it also makes history generally more readable and individual commits more meaningful and easier to cherry-pick.

Re: New in Git: switch and restore

#473

Post by nathias »

_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 really don't know what you are getting at. I find it really intuitive and it seems like one of the best pieces of software created.

Re: New in Git: switch and restore

#474

Post by eevilspock »

alkonaut wrote: post #464
Denvercoder9 wrote: post #462

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

You don't find it interesting you are armchair quarterbacking the most successful VCS software in existence, disregarding that it evolved, that its API reflects that? You assume there is no design process. You're making a lot of assumptions and simplifications. Concern or worry even "fear" are fine, but your language has been more judgmental than concern.

There are plenty of git wrappers that offer a cleaner API; you are totally free to use any of those, write your own, or to ditch Git altogether. Or is your beef with all of programmerdom, for choosing git as the platform for open source dev?

Re: New in Git: switch and restore

#475

Post by Emanation »

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…

I think the point is is that it's worth learning it, subjectively speaking. People tell me to learn vim properly, but I really dont believe I'll gain much based on the sunk cost.

Re: New in Git: switch and restore

#476

Post by planb »

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…

Thank you . I guess this is obvious, but I never thought about it and was never sure when to use which one. Now it makes sense.

Re: New in Git: switch and restore

#477

Post by alkonaut »

eevilspock wrote: post #474
alkonaut wrote: post #464

Earlier quoted context omitted.

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…

You don't find it interesting you are armchair quarterbacking the most successful VCS software in existence, disregarding that it evolved, that its API reflects that? You assume there is no design process. You're making a lot of assumptions and simplifications. Concern or worry even "fear" are fine, but your language has been more judgmental than concern. There are plenty of git wrappers that offer a cleaner API; you…

> You don't find it interesting you are armchair quarterbacking

This is hacker news. It’s basically a few thousand armchairs. Welcome.

> You assume there is no design process.

I’m not saying that. I was just a few minutes ago explaining how I have tried to see traces of it. From the software itself there aren’t any obvious signs of (long term) UX design.

> the most successful VCS software in existence

Lots of stuff is wildly successful despite being an aggregated ball of mud (php, js, unix, c++…). Good (intuitive, consistent) UX is in no way required for popularity or success.

> There are plenty of git wrappers that offer a cleaner API; you are totally free to use any of those, write your own, or to ditch Git altogether. Or is your beef with all of programmerdom, for choosing git as the platform for open source dev?

The fact that none of them are popular I think is due to the problem with such extensions, that soon enough you have to write something portable (a CI script for example) that runs on vanilla git.

> Or is your beef with all of programmerdom, for choosing git as the platform for open source dev?

I like git, and I hate git. Git is simultaneusky hideous and awesome. I really really hope git isn’t the end of VCS, even though it’s now one of the better ones.

> your language has been more judgmental than concern

Fair point. I do enjoy pissing on things that look or feel Unix-y

Re: New in Git: switch and restore

#479

Post by Lutger »

papaf wrote: post #44
thecupisblue wrote: post #36

Earlier quoted context omitted.

> but I'm seriously falling behind due to jetbrains integration This IntelliJ integration is the source of quite a lot of git problems in teams I worked with. I'm quite flabbergasted by this - devs claim to know git on their CV, come in and know what "commit" is and how to use the IntelliJ UI, but don't even understand what its doing. And everyone is acting like it's OK and learning git is a "hard thing ill never nee…

How do we allow our culture to be so lazy that people resist using one of the basic tools because "oh its hard I gotta remember 5 commands" and we find it OK? No wonder the plane is burning. Its probably a rhetorical question but I think its worth answering anyway. Experienced developers had the luxury of learning git, say, over a 10 year period. I certainly know a lot more git than 10 years ago. If you are a new dev…

Most of the experienced developers you mention probably also don't know really know assembly - unless they are specialists, something which the generation before them think shows their lack of understanding. Assembly used to be canon, now it's a speciality. I don't know a single developer in my company who is able to write it.

We'll see if JHipster and their ilk are really the new building blocks. A lot of the older RAD development tools have also gone the way of the dinosaur. For sure the new primitives will be higher level and allow us to build more complex applications, it's just a matter of time before we'll find our which ones have to most expressive power and ergonomics, and which turn out to be giant hairballs.

Re: New in Git: switch and restore

#480

Post by quietbritishjim »

quietbritishjim wrote: post #378
filoeleven wrote: post #204

Earlier quoted context omitted.

SourceTree doesn’t give up. It tells you that you have conflicts to resolve. Once you do, “continue rebase” does what it says, either until the rebase completes or until it hits another conflict.

Does it show a GUI, analogous to [1], or tell me to sort it out myself on the command line? I'd it's the latter then that's very much giving up. On the other hand, it's possible I'm mixing it up with some other GUI I tried.

[1] was meant to be this, which is the TortoiseHg merge conflicts window:

https://i.stack.imgur.com/kaFNz.png

Post reply on HN