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

371–380 of 550 posts

Re: New in Git: switch and restore

#371

Post by tkuraku »

solarkraft wrote: post #365
tkuraku wrote: post #145

I think sublime merge is pretty close to the optimal git GUI, https://www.sublimemerge.com/ . It uses standard git commands and terminology and allows you to add custom git commands to the GUI. Unlike Sourcetree is cross platform for Windows/Linux/Mac and includes a merge tool. I think command line git and Sublime Merge git translate back and pretty easily.

I tried to use it and ended up back with Fork for some reason. I think basic tasks like merging were unnecessarily cumbersome and reliability wasn’t perfect.

Ive never had a problem, but use whatever works best for you!

Re: New in Git: switch and restore

#372

Post by cryptonector »

Lordarminius wrote: post #228

As a helpful aside, in my experience, there are only about a dozen or so Git commands you need to do ninety percent of your work. You don't need to become a git zen master right away. 1. git init: to start a new repository 2. git status: checks your current state 3. git add -A: To begin tracking files 4. git commit -am: Commit all changes in the working directory with a message added on 5. git switch -c [branch name]…

You're missing out. You need rebase and cherry-pick. Merging sucks.

Re: New in Git: switch and restore

#373

Post by jen20 »

Nursie wrote: post #349
jen20 wrote: post #148

Earlier quoted context omitted.

They’re not really in conflict at all. The workflow I’ve been using for ~11 years is: - Make a branch for my work. - Commit early, often and with often meaningless commit messages like “WIP” or “try x” or “nope x doesn’t work, do y instead” - in other words, what the work was. - Push this branch to a remote (either personal or shared depending on policy) largely to synchronise between machines, but also as a backup.…

You still lose your real commit history though, and I’ve found it useful to have that in the past. A dead end or experimental avenue that turned out not to have use at the time turns out to be a real timesaver later. I’m fact I’ve found that far more useful than a well curated history. Having both would be a good thing. Having both in a not-ridiculously overcomplex system even better… I wonder if there even is a swee…

I agree that having both would be preferable - and to some extent GitHub gives you that (via the "squash and merge" button). Unfortunately it doesn't appear that workflow is usable in a lot of cases since the commit message cannot be reviewed independently in this model, unlike in Gerrit.

You can always keep your working branches on a personal remote, or interesting sets of changes in gists, however.

Re: New in Git: switch and restore

#374

Post by quietbritishjim »

chipotle_coyote wrote: post #338
quietbritishjim wrote: post #100

Earlier quoted context omitted.

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

> 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. This is an argument for a good GUI diff/merge tool, which is not necessarily the same thing as an argument for a GUI Git client; I think the two uses are being conflated a lot throughout this comment thread. I have Kaleidoscope set as my default mergetool an…

You're right that there are two different parts to a these, but I think they both benefit from graphical tools.

I'm talking about a VCS tool telling me that the rebase had got to commit n of m and a conflict has been encountered, and which files have conflicts resolved (either automatically or I've manually resolved then so far in this tool), and which other files have conflicts outstanding. Then I can invoke the three way merge tool from there (which is indeed hugely better than a command line tool). Something like this (except this is for Hg):

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

Re: New in Git: switch and restore

#375

Post by laumars »

tehbeard wrote: post #357
laumars wrote: post #187

Earlier quoted context omitted.

I get you disagree with the GPs post but “noob” isn’t offensive. What’s offensive is their lack of support for colleagues (which reads like a potential issue with their own ego: where they didnt want to be shown up in an unfamiliar UI). But their post reads exactly the same if you substituted “noob” for “newbie”, “junior”, “inexperience” etc. What we need to do is get passed this ridiculous mindset some have that not…

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

Re: New in Git: switch and restore

#376

Post by saagarjha »

politician wrote: post #310
voakbasda wrote: post #136

Earlier quoted context omitted.

Any developer demonstrating that level of daily incompetence with their basic tools of the trade should never be allowed to write code. The fact that this level of incompetence seems the rule rather than the exception speaks to the rather terrifyingly pathetic state of software, where badly engineered systems end up killing people. Source: firmware engineering consultant that cleans up messes like these for some of t…

We ask candidates the most ridiculous algorithm and data structure design questions when we should be asking them to describe the git data structures. Let’s fix interviews and kill two birds with one stone.

Git is mostly one (clever) data structure.

Re: New in Git: switch and restore

#377

Post by dmz73 »

intellix wrote: post #83
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…

I wouldn't say I'm an expert but I've got about 10 years experience using git via CLI and whenever a noob does something weird and he's using an IDE I'm like... Sorry I have zero idea what this is trying to do and cannot help you

If you are using a command line tool for 10 years and don't consider yourself an expert then either you are not using the tool very often or the tool is not well designed. In case of git I would say it is the latter. I mostly use git via tortoise interface and that works well 95% of the time. Other 5% is split between git mv, git branch -D, and trying various commands in order to make git do something simple that can't be done and then giving up. At this stage I see git as necessary evil rather than something that helps me with source version control.

Re: New in Git: switch and restore

#378

Post by quietbritishjim »

filoeleven wrote: post #204
quietbritishjim wrote: post #100

Earlier quoted context omitted.

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

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.

Re: New in Git: switch and restore

#379

Post by Dudeman112 »

tehbeard wrote: post #352
BlueTemplar wrote: post #264

Earlier quoted context omitted.

Yeah, hence see the criticisms of git from completely different sides from fossil devs on one hand and pijul dev(s?) on the other. Git probably has its place, but only on very specific, large scale projects, with a crack core team and hundreds of drive-by contributors ?

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

Re: New in Git: switch and restore

#380

Post by crazygringo »

kangalioo wrote: post #341
b3morales wrote: post #301

Earlier quoted context omitted.

Why?

"Noob" has a negative connotation. https://www.urbandictionary.com/define.php?term=Noob > Contrary to the belief of many, a noob/n00b and a newbie/newb are not the same thing. Newbs are those who are new to some task* and are very beginner at it, possibly a little overconfident about it, but they are willing to learn and fix their errors to move out of that stage. n00bs, on the other hand, know little and have no wil…

Indeed, and it should be clear that "noob" is intentionally/cleverly spelled like "boob" in the sense of "idiot". That's the whole point of the word -- that's the joke.

Now it's fine to joke around and call yourself a noob, that's just self-deprecating.

But if you're talking about other people and don't want to inadvertently offend, stick to "newbie" in speech or "newbie/newb" in writing, which have a connotation entirely of "beginner" as opposed to "idiot".

(Of course, if you're among friends where you enjoy making fun of each other, say whatever you want!)

Post reply on HN