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

291–300 of 550 posts

Re: New in Git: switch and restore

#291

Post by cain »

alisonkisk wrote: post #254
indymike wrote: post #203

Earlier quoted context omitted.

> First of all, using "noob" like that is offensive. Everyone's a "noob" at some point. And if that's how you talk and treat people, I probably wouldn't want your help. Unfortunately, a word needs to exist that stands in for this: "Person, who isn't so different than myself when I started, with little experience who is mistake prone due to the lack of experience, who's mistakes creates disruption and often great expe…

Newbie is a nicer word.

Noob is just a contraction of Newbie. Newbie -> Newb -> Noob. It's still used interchangeably with Newb.

Re: New in Git: switch and restore

#292

Post by chris_j »

pjmlp wrote: post #55

It is ironic that Linus hates C++ so much, and then proceeds to create what is for all practical purposes, the C++ of source control systems.

What would you recommend using instead of git?

(Myself, I've been heard complaining that git is overly complex, but the source code control systems that I used to use before git include Subversion, CVS and various Rational products and I have no desire to go back to any of them.)

Re: New in Git: switch and restore

#293

Post by MarkSweep »

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

What about staging lines to the index? I tried ‘git add -i’, but it feels pretty clunky compared to selecting some lines with a mouse in git-gui.

Re: New in Git: switch and restore

#295

Post by samatman »

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

I'm mildly amused that your set of commands can't actually commit anything other than a brand-new file!

I will admit that I'm a lazy git user, and do most of my commits with `git commit -a`, rather than `-am` since I do try and give a short paragraph explaining the reasoning behind whatever the title message claims is the purpose of the commit.

I do run `git diff` first to see what I've changed, and if the diff has unrelated changes in different files I'll usually break it up into separate commits.

Decent introductory list, though. It won't surprise you that I think diff should be learned immediately; whether or not you need rebase depends on the conventions of the codebase, and if someone can learn it later they should, it can get tricky.

Re: New in Git: switch and restore

#296

Post by paulddraper »

nerfbatplz wrote: post #279
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…

Except for 99% of all git day to day tasks are done with like 7 commands. Git commit Git checkout Git merge Git pull Git push Git rebase Git stash I can’t remember I needed a command that wasn’t one of those and I exclusively use the cli.

I've used git for over a decade, and I can't think of anything new I've learned in the past 4 years.

And that last new thing was when git added worktree, which I don't actually use, but I learned about.

Contrast that with almost any other program....it's impressive.

Re: New in Git: switch and restore

#297

Post by akamoonknight »

jbverschoor wrote: post #185
jamesmontalvo3 wrote: post #147

Earlier quoted context omitted.

If I need to visualize the network of commits I use this alias in .gitconfig: network = log --graph --abbrev-commit --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold cyan)%aD%C(reset) %C(bold green)(%ar)%C(reset)%C(bold yellow)%d%C(reset)%n'' %C(white)%s%C(reset) %C(dim white)- %an%C(reset)' --all

I'd rather use a "visual tool" to visualize

And that's totally valid. gitk is my main experience with visual git tools and using it gives a ton of information that is not only visually nice to look at, but also pretty easy to navigate. But gitk isn't always the most available and sometimes I just need a quick look at the history. They're all just tools in the toolbox, but even knowing the tool exists is a first step.

Re: New in Git: switch and restore

#298

Post by hrishi »

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.

Re: New in Git: switch and restore

#299

Post by DangitBobby »

agilob wrote: post #156
nicoburns wrote: post #128

Earlier quoted context omitted.

Sublime merge would have been a good suggestion in this scenario. It's UI uses standard git terminology and concepts, so you'd have been sneakily trainig them in the command line whilst they used the UI!

It was in a very old fashion and regulated working environment where developers and testers aren't allowed to install whatever they want. Software installers can be whitelisted after a review is done. It included things like: licence OSS vs enterprise, support, community, or even more banal things like stars on github. Adding new software to a list could take literally months - like in case of git GUI client. Sublime…

The git GUI in Intellij and related products is really quite good. The diff view that shows three adjacent panes for conflict resolution (|theirs ->|merge|<-yours|) is so much better than the normal conflict resolution flow (not least because you still get the normal code highlighting in it), and separate checkboxes for each changed section of the diff makes it so easy to chunk large changes into logical commits. I wish they offered it as a standalone product.

Re: New in Git: switch and restore

#300

Post by samatman »

yakubin wrote: post #32
Freak_NL wrote: post #28

Earlier quoted context omitted.

How do you end up with that many branches? It sounds like you keep every feature branch around forever. Keeping one around for a few months I get (although personally the sooner they're gone after rebasing or cherry-picking them the better), but this sounds like a full on history of every branch ever.

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

You may not have much choice in the matter, but this level of complexity is where I would strongly recommend a (slightly) more complex architecture.

It's apparently a business requirement to keep every branch around forever, and I'll just take your word for that. At that point, you can have an `origin` remote where work happens, and the CI can include a push to an `archive` remote which is append-only.

Lets you have a development environment where the existence of a branch on origin means that it's in-play, and everything exists on archive if it proves needful.

Post reply on HN