undefined | Better HN

0 pointsbjones2210y ago0 comments

I remember when I first got started with git I committed at an absurd frequency. I don't think it's that unreasonable for someone straight out of college to be relatively new to git, and thus do the same thing.

I remember later on I wrote a script that listened to git hooks and rebuilt my project on a remote server. I was still testing manually at that time, as we all do in the beginning, which resulted in a large number of commits so that I could view the results on the server.

I think it's ok to ask "why do you have so many commits?" but not "why do you have so many commits?!?!?!". It's also not ok to ASSUME that a large number of commits is a bad thing automatically, unless you have reasons far better then any submitted in this thread.

0 comments

monksy10y ago

Well I can't say too much without exposing the problem.

But there were about 16 files in total. All of the comparators that were written had multiple tests. (I shot for nearly 100% coverage..although I wasn't going to force stdin emulation, and mock out system.exits) All of the commits that were performed were done in small amounts. (Also, a few were just for transferring work space to other computers) The task in hand would have represented approximately 4 tickets at the bare minimum.

Besides, the number of commits: That problem is resolved by merging a branch back down.

The feedback was written in a way "How do you consider that reasonable in a professional environment?"

(Another thing... I wasn't required to submit via a git repo I was required to submit via a zip file, but I did because I hoped it'd give me a leg up.... Turns out: You're better off not trying)

nilkn10y ago

66 commits sounds perfectly fine for complete unit test coverage, 16 files, etc. Sounds like this was not the sort of person anybody would want to work with if he phrased the question in that condescending way. He'd probably end up being an insane micromanager.

j / k navigate · click thread line to collapse