Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git pretty

justinhileman.info

Post reply on HN
Print view View original

51–60 of 65 posts

Re: Git pretty

#51

Post by pimlottc »

gcb4 wrote: post #16

git is only good for people that was working like Linus. if you didn't have been accepting patches by email but instead had a fluid svn, perforce, etc central repository and people already collaborating with commit powers, then if you move to git "just because" (which is the reason of 99% migrations) you're going to have a bad time. sadly, my company decided to move just to use pull requests as a poor man's code revi…

If working like Linus means using git, then I'd say his is a better way to work. Speaking for myself, there's no reason I can see to ever go back to svn. Even for personal single-dev projects.

It is so simple to create a new git repo on the fly, with no need for a separate repository location. And rebasing plus easy branching has changed the way I work forever. Git allows you to commit early and commit often, safe in the knowledge you can always reorder, combine, remove and/or re-comment your changes later.

This frees you to experiment without worrying about losing the progress you've already made. If you reach a dead-end, it's easy to go back and start working in another direction, while saving the branch in case you change your mind.

Basically, once you get past the learning curve, git makes it extremely easy to remain in that most blessed of version control state of having no uncommitted local changes. And once you've saved with with a commit, it's pretty hard to permanently lose it.

at least, before you push changes to another repo, if you're doing that.

Re: Git pretty

#52

Post by findjashua »

recursive wrote: post #37
findjashua wrote: post #19

Earlier quoted context omitted.

Sounds more like resistance to change than anything wrong with Git. I used perforce at my previous company, and while Git's learning curve was higher, I definitely see the advantages of a distributed version control system over a centralized one: 1. Not having to check out files means I can work offline. 2. When working on multiple features, it's much easier to create a new Git branch than it is to create a new Perfo…

Why would you need to know how to use any version control software at all to use a third party library? I mean, I do both, but haven't really seen a connection.

If you want to look at the commit history or submit a patch, you'll need some sort of version control.

Re: Git pretty

#53

Post by Chetane »

gcb4 wrote: post #16

git is only good for people that was working like Linus. if you didn't have been accepting patches by email but instead had a fluid svn, perforce, etc central repository and people already collaborating with commit powers, then if you move to git "just because" (which is the reason of 99% migrations) you're going to have a bad time. sadly, my company decided to move just to use pull requests as a poor man's code revi…

> my company decided to move just to use pull requests as a poor man's code review tool

Using Git, and using pull requests as code reviews are two very separates things. Many people addressed the first point (e.g. Why git is totally fine), so I'll focus on the second one: code reviews with Git. Pull requests is one of many ways to do it, which I personally find difficult with bigger teams working on non open-source projects. I'd recommend looking at Phabricator as a code review tool that works really well in teams.

Re: Git pretty

#54

Post by ladislas »

burntsushi wrote: post #7
ladislas wrote: post #6

Great tool for young interns! :D I think there is a small mistake though, for the "I accidentally commited something": the answers yes and no for "Has anyone else seen it?" are inverted.

Hmm, I don't think so. The answer for "yes" is to do a `git revert`, which does not modify history. Instead, it creates a new commit. The answers for "no" all involve modifying history, which I think is generally perceived to be quite OK so long as you aren't modifying history that is public.

yep you're right and the question was already answered in the comments. :)

Re: Git pretty

#55

Post by chrisweekly »

michaelmior wrote: post #38
js2 wrote: post #4

This is excellent: opinionated and correct. Guess what happens if you try to git revert a merge? Yeah. Don’t do that. You can, but you really need to understand what happens when you do so, so that you're not confused by future merges from the same branch. Straight from the horse's mouth: https://www.kernel.org/pub/software/scm/git/docs/howto/rever...

While I agree this guide is great, I think opinionated and correct are mutually exclusive.

"...opinionated and correct are mutually exclusive."

TIMTOWTDI.

Re: Git pretty

#56

Post by the_af »

__david__ wrote: post #31
gcb4 wrote: post #16

git is only good for people that was working like Linus. if you didn't have been accepting patches by email but instead had a fluid svn, perforce, etc central repository and people already collaborating with commit powers, then if you move to git "just because" (which is the reason of 99% migrations) you're going to have a bad time. sadly, my company decided to move just to use pull requests as a poor man's code revi…

Man, sounds like the complete opposite experience to me. Going from SVN to even a centrally controlled Git repo is a breath of fresh air. I recently switched a project from Darcs to git. It was (again) mostly centrally contained, despite being a DVCS. And Darcs being DVCS, we held out on switching to Git since it seemed like it wouldn't really be that much of an improvement. In other words, change for change sake. Bo…

What are the improvements of using git over darcs? Do you miss anything from darcs?

Re: Git pretty

#57

Post by recursive »

findjashua wrote: post #52
recursive wrote: post #37

Earlier quoted context omitted.

Why would you need to know how to use any version control software at all to use a third party library? I mean, I do both, but haven't really seen a connection.

If you want to look at the commit history or submit a patch, you'll need some sort of version control.

That is by far a minority of my uses of third party libraries.

Re: Git pretty

#58

Post by recursive »

smt88 wrote: post #41
recursive wrote: post #37

Earlier quoted context omitted.

Why would you need to know how to use any version control software at all to use a third party library? I mean, I do both, but haven't really seen a connection.

Before git-based package managers became the norm, it wasn't uncommon to track/update dependencies manually using command-line git. Also "using" a third-party library hopefully results in finding bugs, fixing them, and submitting a pull request to the project.

I wasn't aware that git-based package managers were the norm, but I've used third party libraries in two different ways.

1. Nuget packages inside Visual Studio 2. Download the library using a web browser, and just put it where it needs to be.

I'm sure some people would scoff at this list, but it does demonstrate that you can certainly use third party libraries without using git.

Re: Git pretty

#59

Post by smt88 »

recursive wrote: post #58
smt88 wrote: post #41

Earlier quoted context omitted.

Before git-based package managers became the norm, it wasn't uncommon to track/update dependencies manually using command-line git. Also "using" a third-party library hopefully results in finding bugs, fixing them, and submitting a pull request to the project.

I wasn't aware that git-based package managers were the norm, but I've used third party libraries in two different ways. 1. Nuget packages inside Visual Studio 2. Download the library using a web browser, and just put it where it needs to be. I'm sure some people would scoff at this list, but it does demonstrate that you can certainly use third party libraries without using git.

> 2. Download the library using a web browser, and just put it where it needs to be.

That might work for certain projects, but let's say you're using 10 third-party libraries. If they're under active development, you can expect at least a few security updates between the time you first import them and the time you ship your own product.

It's not very practical (especially for a programmer!) to keep manually checking your dependencies' product pages for updates.

Re: Git pretty

#60

Post by smt88 »

pimlottc wrote: post #48
smt88 wrote: post #41

Earlier quoted context omitted.

Before git-based package managers became the norm, it wasn't uncommon to track/update dependencies manually using command-line git. Also "using" a third-party library hopefully results in finding bugs, fixing them, and submitting a pull request to the project.

> Before git-based package managers became the norm When did using git-based package managers become the norm? > it wasn't uncommon to track/update dependencies manually using command-line git. Are you saying you normally update your third-party libs with the latest from HEAD instead of using versioned release artifacts? (I'm guessing you're speaking from a JS dev perspective?)

> When did using git-based package managers become the norm?

I'm a web developer, so my response was hastily written thinking about my own narrow scope. I'm sure that non-web developers can go their whole lives without interacting with git, but it's impossible for web developers.

Npm (Node), Composer (PHP), and Bower (web) package managers all use git (and often GitHub itself) pretty religiously. I know that one or more of those may support other VCS repos, but git is the de facto flavor.

> Are you saying you normally update your third-party libs with the latest from HEAD instead of using versioned release artifacts?

Not exactly. First of all, that's what I _used_ to do before every language had its own package manager.

Second, I do use versioned releases. However, I use the tagged versions that are determined by the author(s) of the library. I'm not just pulling down a bleeding-edge, un-tested library, and I don't get every single commit.

Post reply on HN