My Git Habits • Hacker News Board

Re: My Git Habits

#61

Post by crusso » Fri, Mar 16, 2012, 1:29 PM UTC

batista wrote: post #38

The proliferation of "git tips", and "my git habits", "git best practices" articles, make me think that Git is too complicated for its own good to need all those. (Maybe "need" is a bad choice of words: maybe it doesn't need those articles, but it's too complicated if it gets to have them. You don't get such avalanche of advice for a simple, no BS, tool). Now, the complicated part means it's flexible --in the rare ca…

Not sure why you were downvoted, gitfanbois I guess.

I've used both git and mercurial. I would tend to agree that git has more of a feel of non-conformity when it comes to best practices and default ways that it behaves.

That said, mercurial has an equally bewildering array of choices when it comes to all the different add-ons that you can install to do similar things.

I think they're both great tools and I love the way that they've both innovated ahead of each other and copied the best of each other.

Re: My Git Habits

#62

Post by Feoh » Fri, Mar 16, 2012, 3:06 PM UTC

jlarocco wrote: post #27

Osiris wrote: post #4

I'm fairly new to git. I've only been using it for about two months. It seems like this is a lot of work with the end result only being that the commit log is cleaner and perhaps makes cherry-picking a feature/fix a bit easier. I can understand the need for this kind of cleanup when pushing a fix to an open-source repository that needs pull requests to be self-contained, but for an internal company repo, how importan…

I also don't see the point. If I need to experiment, I'll create a branch, mess around there, and merge it back when I've figured things out and have everything working. The workflow in the article seems like it's trying to be clever for the sake of being clever. I guess it works for him, but I think most people would find it too confusing to be practical.

I'm a release engineer, and I couldn't agree more with the sentiment of this post. I have immense respect for mjd's work (His articles on Perl saved my bacon more than once - _Suffering with Buffering_ and _Coping with Scoping_ in particular) but this workflow just plain stinks and feels like building a house, then demolishing it and picking through the rubble to build a better house you're satisfied with, rather than (as git was designed to do) experimenting off to the side in a branch and only commiting Good Stuff to your 'for real' branch (master or otherwise.)

Re: My Git Habits

#63

Post by Feoh » Fri, Mar 16, 2012, 6:55 PM UTC

I said this in a reply, but lest it get lost in the shuffle, here goes. I have a tremendous amount of respect for mjd. His seminal articles on Perl, particularly "Suffering with Buffering" and "Coping with Scoping" saved my bacon more than once. However, I'm a release engineer, and this is an awful, awful Git work flow. As others have noted, Git was designed so that you can make wacky wild experimental changes off to the side in branches, and only when you're happy, merge them back to your working branch and eventually into master. This approach needlessly complicates things and seems incredibly error prone, especially the bit about having to do house cleaning on the morass of broken commits.

Re: My Git Habits

#64

Post by Vitaly » Sun, Mar 18, 2012, 12:13 PM UTC

snprbob86 wrote: post #37

Vitaly wrote: post #30

I just use gitx when I'm on OS X or tig when I'm on a terminal for per chunk or per line (gitx only) staging. git -p is too user unfriendly.

Once you get used to reading diffs in your terminal, git -p (and -i) turn out to be very useful friendly. It's really easy to just slam y or n a bunch of times, rather than click around a lot.

big just uses text diffs as well, only color coded which really adds to the readability of it. I don't need guis for most of the things. The benefit of GitX over tig or git -p is that it easily allows to stage a single line instead of the whole chunk