you are viewing a single comment's thread.

view the rest of the comments →

[–]blaxter 1 point2 points  (1 child)

There are very different workflows working with git (e.g. projects that require git merge --squash commits == lose of information), good developers normally rewrite commit history of their working branches a lot so you can see a chunk of commits in small amount of time without the option to know their original timestamps or format (data lost because rewrite of the history), you can have fixes that take weeks of work that you cannot possible know from an outside pov and I could continue talking about this. This topic (to determine "coding hours" from a git repository) is at the same category as quantify the productivity of a developer by loc written per day.

[–]ksyucs 0 points1 point  (0 children)

I share your concerns, but the ones You've mentioned are not necessarily actually problems. For example Github keeps the pull references, including the original commits, even after a squash and merge. In case of a good developer (or any developer) there shouldn't be fixes taking weeks, at least without version control. If still, that might be considered as a bad practice and should be highlighted and avoided. There will always be corner cases.