My Git Habits • Hacker News Board

Re: My Git Habits

#11

Post by pja » Thu, Mar 15, 2012, 8:40 PM UTC

DavidWoof wrote: post #8

This seems like a pretty terrible workflow to me, do others here actually work like this? I only use git-add -p when I've screwed up and didn't commit when I should have, so I have to split the current commit into two. It seems to me that rebase -i and merge --squash are better suited to re-writing history in the way that's being done here. I'm especially distrustful of any workflow that includes the line "I eyeball…

It means you keep your original history around & build a new one which breaks the code changes into functional chunks.

Rewriting your existing history with git rebase -i is fine until it goes horribly wrong & you have to go groveling through the reflog to work out which commits you need to rescue in order to retrieve your lost work.

Re: My Git Habits

#12

Post by mcknz » Thu, Mar 15, 2012, 9:05 PM UTC

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.

Re: My Git Habits

#13

Post by Kiro » Thu, Mar 15, 2012, 9:28 PM UTC

baq wrote: post #7

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.

you can use git gui (included) for a mouse-friendly way of doing this.

Since I first tried the Git GUI I can't see myself using Git Bash ever again (and this article reminds me of why).

Re: My Git Habits

#14

Post by krupan » Thu, Mar 15, 2012, 9:32 PM UTC

Wow. I've written about how powerful revision control tools become not just a place to stash diffs, but a full-on code editing tool (http://bryan-murdock.blogspot.com/2010/09/mercurial-is-teh-a...), but this is very impressive.

I think he mentions that he does test these new commits that he creates as he goes about re-arranging history, but I think that should be emphasized more. I'd rather have a messy looking commit that passes tests than some nice looking commit that doesn't. bisect is powerful command that shouldn't be broken.

Re: My Git Habits

#15

Post by DavidWoof » Thu, Mar 15, 2012, 9:40 PM UTC

pja wrote: post #11

DavidWoof wrote: post #8

This seems like a pretty terrible workflow to me, do others here actually work like this? I only use git-add -p when I've screwed up and didn't commit when I should have, so I have to split the current commit into two. It seems to me that rebase -i and merge --squash are better suited to re-writing history in the way that's being done here. I'm especially distrustful of any workflow that includes the line "I eyeball…

It means you keep your original history around & build a new one which breaks the code changes into functional chunks. Rewriting your existing history with git rebase -i is fine until it goes horribly wrong & you have to go groveling through the reflog to work out which commits you need to rescue in order to retrieve your lost work.

I don't see that. Keeping your original history around is a function of doing cleanup on a separate branch. It has nothing to do with how that cleanup is achieved.

Rewriting your existing history with git reset can also go horribly wrong, which is why it's done on a separate branch here.

Re: My Git Habits

#16

Post by philwelch » Thu, Mar 15, 2012, 9:42 PM UTC

DavidWoof wrote: post #8

This seems like a pretty terrible workflow to me, do others here actually work like this? I only use git-add -p when I've screwed up and didn't commit when I should have, so I have to split the current commit into two. It seems to me that rebase -i and merge --squash are better suited to re-writing history in the way that's being done here. I'm especially distrustful of any workflow that includes the line "I eyeball…

I have to shift my brain into totally different modes between programming and reviewing/testing/version-controlling, and git add -p is an important tool. Maybe you're disciplined enough to keep a queue of everything you'd like to do in your head at once, and only stick to one task at a time, and shift into review/test/commit mode between quantized chunks. Me, I just go in, hack for a bit, and when I run out of ideas, I shift modes, read the git diff, break out my work into chunks, and then add -p/stash/test/review/commit chunk by chunk.

If you want all of my commits to be functionally and semantically separate and individually tested, I can give that to you. git-add -p is just an interface between that well-disciplined software-engineering expectation and what my brain actually does when it gets into flow.

Re: My Git Habits

#17

Post by brown9-2 » Thu, Mar 15, 2012, 9:58 PM UTC

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?

Re: My Git Habits

#18

Post by telemachos » Thu, Mar 15, 2012, 10:05 PM UTC

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.

Re: My Git Habits

#19

Post by telemachos » Thu, Mar 15, 2012, 10:07 PM UTC

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.

Another good post that talks about git add -p is Ryan Tomayko's The Thing About Git[1].

[1]: http://tomayko.com/writings/the-thing-about-git

Re: My Git Habits

#20

Post by PaulAnunda » Thu, Mar 15, 2012, 10:13 PM UTC

all i use:

  git add . && git status

  git diff --cached | mate

  git commit -am "this is what i did"

  git push

and when it hits the fan...

  git reset --hard