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

31–40 of 65 posts

Re: Git pretty

#31

Post by __david__ »

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.

Boy was I wrong. Even that change was refreshing. I find Git to be an absolute pleasure to use (and as a plus it stole all the good Darcs interface features). Git made managing our release branch fun again. The thing I like about Git is that it's low level enough that you can make it do anything.

Like the time I foolishly changed the EOLs on upstream code after I committed it—Git let me track my changes and merge in new upstreams, despite every line in the new upstream being different. Yay, git.

Re: Git pretty

#32

Post by LandonAB »

As a one person web design/development studio, it's charts like this and threads like this that keep me off git. I've played with it, used it on a project but the fact that I am always reading about the messes people get in with git...I really don't have time to deal with versioning messes.

Re: Git pretty

#33

Post by chunkstuntman »

LandonAB wrote: post #32

As a one person web design/development studio, it's charts like this and threads like this that keep me off git. I've played with it, used it on a project but the fact that I am always reading about the messes people get in with git...I really don't have time to deal with versioning messes.

I think any version control software needs to address the simple fact that humans will rush through writing and committing code in a way that they may later regret. Dealing with an ugly git log is less trouble than not having versioning software at all.

Re: Git pretty

#34

Post by krallja »

Mercurial Changeset Evolution is going to solve the "It's safest to let it stay ugly then" and "Send them a note, let 'em know you're changing history" problems. No more force pushes or lost data! The new version of history applies on top of the old version. Immutable data structures, flexible workflow.

Re: Git pretty

#35

Post by apinstein »

LandonAB wrote: post #32

As a one person web design/development studio, it's charts like this and threads like this that keep me off git. I've played with it, used it on a project but the fact that I am always reading about the messes people get in with git...I really don't have time to deal with versioning messes.

I'd counter that these messes aren't caused by git; rather they are messes that without git you wouldn't even bother cleaning up.

However, git lets you fix the mess in such a way that you'll have a clean commit history. This is really helpful if you're trying to keep your codebase clean so that `git bisect` will always work nicely, and if you just want to keep your codebase history really grokkable.

Re: Git pretty

#36

Post by adestefan »

adregan wrote: post #14
christop wrote: post #11

"Split off a logical chunk from your mess, stage it" should really be another box with "git add -p". Being able to pick and choose (and even edit) individual chunks to be staged is enormously useful. Quite possibly my favourite feature of git.

git add -p has absolutely changed my work flow and commit histories for the better.

I find that git add -p is a crutch and everytime I need to use it I scold myself for not committing more often.

Re: Git pretty

#37

Post by recursive »

findjashua wrote: post #19
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…

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.

Re: Git pretty

#38

Post by michaelmior »

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.

Re: Git pretty

#39

Post by rwallace »

JoshTriplett wrote: post #15

Nice chart, at least for a reminder of the command you're likely to need. However, "Is it already on GitHub" should be "have you already pushed it publically". Reminder: git is distributed.

Git is distributed indeed, but good writing style prefers specifics to abstract generalities. It's better to use Github as your example and expect the reader to understand - or if appropriate, explain in a separate paragraph - that there are other options for public repositories.

Re: Git pretty

#40

Post by pjungwir »

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

I've read that doc and other warnings about reverting a merge. But I've found that if you revert the revert, then you avoid the problems they mention. I guess the worry is that you still have to remember to do that, or you'll have commits that silently never merge. But if you do remember, then reverting the revert makes things okay. But I'm no expert. Can anyone else confirm this for me?
Post reply on HN