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

My Git Habits

blog.plover.com

Post reply on HN
Print view View original

21–30 of 64 posts

Re: My Git Habits

#21

Post by julian37 »

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 agree that in many cases this meticulous approach is overkill. But what it demonstrates nicely is, as the man says, 'Git means never having to say "If only I'd realized sooner."'

When you do need your commit history to be as neat as possible, git gives you plenty of tools to make it happen. Imagine the nightmare a task like this would be with Subversion. (I haven't used Hg a lot so can't say how it compares in this regard--I'd be curious to know.)

Re: My Git Habits

#23

Post by raju »

tomdeakin wrote: post #2

git-add -p is new to me, but looks like something I'd wish I'd known about for a long while. The number of times I end up copying changes (like a new function) into some temp file while I commit is more than I'd care to admit.

If you are on a mac, Gitx works nicely too. You can see each file, and state "hunks" as you go.

Re: My Git Habits

#24

Post by Davertron »

telemachos wrote: post #18
brown9-2 wrote: post #17

Often I'll be in the middle of something, with a dirty work tree, when it's time to leave for the day. Then I'll just commit everything with the subject WIP ("work-in-progress"). First thing the next morning I'll git-reset HEAD^ and continue where I left off. Curious, what is the advantage of doing this? Why commit something locally just to reset it out the next morning?

He explains here: > Such commits rarely survive beyond the following morning, but if I didn't make them, I wouldn't be able to continue work from home if the mood took me to do that.

I think the underlying assumption here is that he commits and pushes these changes somewhere accessible from home and not taking it with him on his laptop or something. Otherwise there really isn't a good reason for committing it.

Re: My Git Habits

#25

Post by Tibbes »

pja wrote: post #9
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…

There's a few advantages to doing things this way. If you ever want to git-bisect your code-base to track down when you introduced a bug then you'll be very thankful that every commit is functional and passes your test-suite (apart from the tests relevant to new features on a topic branch of course). Having to hop forwards and backwards from each git-bisect point looking for a functional commit is a huge waste of tim…

"If you ever want to git-bisect your code-base to track down when you introduced a bug then you'll be very thankful that every commit is functional and passes your test-suite"

I agree that this property is very useful, but I disagree that it it is necessarily implied by the workflow as described in the article. By using "git add -p", he is constructing a tree that probably never actually existed during development - hence there is no guarantee that it works and passes the tests.

I strongly agree with you that a clean logical progression of commits is a good thing (especially for code review). However, making sure that each stage works and passes the tests takes extra discipline.

Re: My Git Habits

#26

Post by gcb »

mcknz wrote: post #12
mdehaan wrote: post #10

Maybe it's just me, but using short lived topic/feature branches and squash merges seems much easier than remembering all of these steps to "fix up" all these things. I think it becomes some what of a game to use all the more obscure corners of git when a good 20-30% of it goes a long way. Using less commands is more.

I agree, but that also requires a discipline/foresight not all of us have. :) I try to keep my feature branches as atomic as possible, but sometimes I get ahead of myself and work on multiple things that really shouldn't be in the same commit. I wouldn't use this model as my main workflow, but it's definitely useful in certain scenarios.

if your code is 'live' and you plan ahead a few features: feature branches.

if you are running as fast as you can for the first releases, what i do is use feature prefixes on the commits. And of course, a commit can have several prefixes.

of course, if i have to cherry pick something, i still have to look at each commit, but with prefixes it's easy. And i have the time i didn't spend thinking ahead for something i don't even know i will need.

Re: My Git Habits

#27

Post by jlarocco »

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.

Re: My Git Habits

#28

Post by helpbygrace »

By the way, that article page is too hard to read comfortably. Shortened the width of each paragraph and upsize the font will be really good for me to read it.

tl;dr , I didn't read that page. :(

Re: My Git Habits

#29

Post by phzbOx »

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 find this to be over kill but I see the point.. as if you're always trying to make "good" commits you kind of lose the "get all the shit done" mentality as you have to separate everything in smaller ideas.. whereas it's faster sometime to really hack lots of thing and commit, and then at the end cleaning stuff.

Re: My Git Habits

#30

Post by Vitaly »

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.
Post reply on HN