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

31–40 of 64 posts

Re: My Git Habits

#31

Post by Vitaly »

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…

this is a lot of work if you are OCD and print out your diffs to mark with a highlighter. A decent git gui like GitX on mac will let you do it with almost no effort at all.

Re: My Git Habits

#32

Post by gchpaco »

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…

Here are some of the situations I run into on a regular basis at my current company, which is Perforce based, where I wish we were git based instead. This would be as true in Subversion. They might be maybe less true in Mercurial or Bzr, I'm not as familiar with those ones.

* I am hacking on some bit of code, so I set up a Perforce branch. While I'm at it I notice some ugliness and want to refactor it. I could make a new Perforce branch and put it there and then do some horrible merging apparatus but it's complicated and they live forever and it takes me out of the flow state, so I just make a commit. It is now very difficult to extract that commit from its context so that I could apply it independently.

* I make a mistake on a commit that is on a private Perforce branch, or maybe I did something out of order. The Perforce way is "you shouldn't have done that, then." and so my commit logs are full of "fix stupid typo" type commits that are basically just noise.

* I forget to add a file to Perforce and nothing tells me about it, ever, until we get to testing (or sometimes to production!) and Puppet won't run because it can't find some file . This is fixed with the 2012 betas and p4 status, but those require a server upgrade (because the p4 client is a thin wrapper around what the p4d server understands) and that isn't in the cards yet. This alone is enough to make me want to use git-p4 for everything.

* You can really tell that Perforce is built around a file system of RCS files sometimes. While it has atomic commits, many, many operations are based on individual file revisions (labelling, cherry picking, merging). This leads to the following:

* Cherry picking in Perforce is hard, because it's hard to get handle on the content of a changeset, as opposed to individual upticks in each of the files referenced. It can be done but it is a lot of effort, way more so than in git.

This is not the entirety of my complaints about Perforce, by any means, but they're the most visible UI limitations compared to what I'm used to from git.

Re: My Git Habits

#34

Post by 6ren »

I think in part he's documenting modules. Because modules often crosscut the primary hierarchy of files/classes/methods, it's awkward to document in the source itself, and so usually isn't documented at all.

Git allows documentation across files; and because commits are naturally associated with specific revisions, it can't get out of date.

{ Still, it does seem a lot of work, and it would be nice to document within the source itself; and in a way that helps and is needed by the code (so it can't get out of date). A bad example: specifically requiring/importing another class before being able to use it. This documents dependencies, and remains current or your code stops working (it would need to be an error to require a class without using it). It is a "bad example" because it doesn't help you, just raises a barrier then "helps" you cross it, like a stand-over man in an extortion racket.

What's needed is some immediate benefit (e.g. reduce code) to associating files/classes/methods in a crosscutting "module". }

Re: My Git Habits

#35

Post by kderbe »

Tibbes wrote: post #25
pja wrote: post #9

Earlier quoted context omitted.

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

The author runs his tests after his partial commits. He does this by stashing the remaining changes, testing the newly-committed code, and then continuing to make partial commits. Here's the example in the article:

        % git stash
        % make test
        ...
        OK
        % git stash pop
Also keep in mind that the initial tree contains WIP commits that are unlikely to work or pass tests, so reordering commits can hardly make things worse.

Re: My Git Habits

#36

Post by snprbob86 »

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 care very little about the cleanliness of my history. I mean, I care that it's not horrendous, but a bunch of extra merge commits or a few random fix-up commits don't make me think twice. However, I've found a the tools for maintaining clean history to be extremely useful for getting real work done.

My typical workflow with Git is one of incrementally appending commits to a branch, and then using git rebase --interactive to bubble sort commits by impact.

For example, let's say I am working on a feature and I stumble across an unrelated bug that's easy to fix. I fix it. Then I commit just that fix. And then I go about my day. Sometimes, my fix may depend on a small refactor or ancillary change that's not finished. So I make the change anyway, and commit it, completely broken. After finishing the ancillary dependency, I use rebase to reorder the commits so that I can test the change in absence of the bug fix, and then again with it applied.

I've had feature branches grow up to 20 or 30 commits, where 10+ of them are totally borked or otherwise need to be re-ordered. By the time I've made sense of it all, I send it out to my team as 2 or 3 pull requests with 1 to 5 commits each. In the process, I look at my code diff over, and over, and over again. I find lots of bugs by inspection this way. I enjoy writing code this way.

This way my code can be reviewed as a series of logical transformations. It's much easier to review this way. I really appreciate it when my co-workers send me clean patches to review, so I respond in kind.

In summary: It's not about a clean history (although that's a nice side effect). It's about using Git as a tool to help you and your team reason about changes.

Re: My Git Habits

#37

Post by snprbob86 »

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.

Re: My Git Habits

#38

Post by batista »

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 cases you need it to be. But it could probably use a facade that makes the common use cases more intuitive (there are some half-baked attempts that I'm aware of).

Personally, I use mercurial.

Re: My Git Habits

#39

Post by encoderer »

gchpaco wrote: post #32
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…

Here are some of the situations I run into on a regular basis at my current company, which is Perforce based, where I wish we were git based instead. This would be as true in Subversion. They might be maybe less true in Mercurial or Bzr, I'm not as familiar with those ones. * I am hacking on some bit of code, so I set up a Perforce branch. While I'm at it I notice some ugliness and want to refactor it. I could make a…

Mercurial is more like Git than not. It differs in the way it stores revision history (Git stores files, Mercurial stores deltas, basically).

And branching is Mercurial isn't nearly as neatly implemented as it is in Git.

But it would seem to address the issues you listed here. For example, you can rollback a commit if you did the "stupid typo" mistake. And you have a lot of power to "change history" and modify the DAG anyway you wish.

Re: My Git Habits

#40

Post by msbarnett »

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…

It's not exactly hard to find people discussing different best practices and their own individual workflows in Mercurial, either[1].

The existence of these articles doesn't tell us anything negative about Mercurial, or Git, it merely tells us that these tools are powerful enough to be used for Real Work in Real Workflows, and that there are few things people love more than talking about their workflows.

[1]: Random examples: http://stackoverflow.com/questions/448567/best-practices-in-... http://mercurial.selenic.com/wiki/WorkingPractices http://stevelosh.com/blog/2010/08/a-git-users-guide-to-mercu... https://blogs.oracle.com/kto/entry/mercurial_best_practices http://mercurial.808500.n3.nabble.com/Best-practices-for-mer... http://www.stevestreeting.com/2010/04/22/mercurial-queues-ju...

Post reply on HN