3 ms·

Actually the easiest thing is simply not to care about how your log looks. If you don't then there are ry only two things you need to know how to do: If you d

Actually the easiest thing is simply not to care about how your log looks. If you don't then there are ry only two things you need to know how to do: If you didn't push to origin do an ammend. If you did, revert soft and commit the previous code to revert it (you can also put a stash or patch to apply it back). Which frankly is what the article does, basically.

K0nserv 10y ago
Having a messy and complex git log is not only about the visuals though. It can make it a lot harder to track down when/where/why bugs and problematic code was introduced. It makes both git bisect and git blame less useful.
- eosrei 10y ago
  Exactly. The canonical reference to how a git log should look is the Linux kernel, since git was written for it: https://github.com/torvalds/linux/commits/master https://github.com/torvalds/linux/commits/master Bisect and blame are amazing in that repo.
shandor 10y ago
> Actually the easiest thing is simply not to care about how your log looks. Yes, that sounds as easy as anything that accepts the idea of "let's do this the shitty-but-quick way now, and pay the technical debt later". So yes, it is "easier" to work with in the beginning. On the other hand, if I had to inherit your repository that was developed by "not caring about history", I would probably have to hunt you down and kill you. So there's that.
- Annatar 10y ago
  On the other hand, if I had to inherit your repository that was developed by "not caring about history", I would probably have to hunt you down and kill you. So there's that. Yep. Some people just want to keep taking technical debt on (read: hack-it-'till-it-works), which makes them likely candidates for a good thrashing in some dark blind street in the middle of the night. And some don't even get it after that. Actually, now that you made me think about it, most people in this industry aren't really computer people material, that's the problem.
leejo 10y ago
> Actually the easiest thing is simply not to care about how your log looks. You need to expand on this because i don't quite understand what you mean, are you talking about "fix typo" commits or are we getting to the level of just committing away until things work and then not cleaning up the work later on? The linked article doesn't cover rebasing or squashing commits, which can be pretty powerful when used correctly. Your commit log is the one thing that is immutably linked to your code changes. Your documentation isn't, the comments in your code aren't, you will forget why you made a change, anyone reviewing your logs needs to understand your intention, your bug tracker will probably change several times over the life of a project, and so on. So, make an effort to have a commit log that is clean and comprehensive and commits that don't break tests. I go into this in more detail in a talk i gave last week: https://www.youtube.com/watch?v=9OHAq8dCoS4 https://www.youtube.com/watch?v=9OHAq8dCoS4
- sergiosgc 10y ago
  Develop on feature branches, merge with master only when the feature is done. Always merge with --no-ff. Then, when reviewing history, on the master branch you can use either "git log" or "git log --first-parent master". The first log is the complete log, with exploratory development, mistakes, backtracks and such. The second is the clean log people keep rewriting history to obtain. You get your cake and you can eat it too.
  - leejo 10y ago
    This is pretty much the reason i don't understand people who don't want merge commits (the use case for rebase in the video is modifying commits in a feature branch BTW, not merging to master). You can bend git logs to your will with the various options so there's no problem in being as verbose as possible in commit messages and the concept of a "linear history" is a moot point because, no matter how messy your history actual is, there's a command line option to clear it up. Be verbose in your commit messages and don't worry about merge commits, it will pay dividends later.

K0nserv 10y ago

Having a messy and complex git log is not only about the visuals though. It can make it a lot harder to track down when/where/why bugs and problematic code was introduced. It makes both git bisect and git blame less useful.

eosrei 10y ago
Exactly. The canonical reference to how a git log should look is the Linux kernel, since git was written for it: https://github.com/torvalds/linux/commits/master https://github.com/torvalds/linux/commits/master Bisect and blame are amazing in that repo.

shandor 10y ago

> Actually the easiest thing is simply not to care about how your log looks. Yes, that sounds as easy as anything that accepts the idea of "let's do this the shitty-but-quick way now, and pay the technical debt later". So yes, it is "easier" to work with in the beginning. On the other hand, if I had to inherit your repository that was developed by "not caring about history", I would probably have to hunt you down and kill you. So there's that.

Annatar 10y ago
On the other hand, if I had to inherit your repository that was developed by "not caring about history", I would probably have to hunt you down and kill you. So there's that. Yep. Some people just want to keep taking technical debt on (read: hack-it-'till-it-works), which makes them likely candidates for a good thrashing in some dark blind street in the middle of the night. And some don't even get it after that. Actually, now that you made me think about it, most people in this industry aren't really computer people material, that's the problem.

leejo 10y ago

> Actually the easiest thing is simply not to care about how your log looks. You need to expand on this because i don't quite understand what you mean, are you talking about "fix typo" commits or are we getting to the level of just committing away until things work and then not cleaning up the work later on? The linked article doesn't cover rebasing or squashing commits, which can be pretty powerful when used correctly. Your commit log is the one thing that is immutably linked to your code changes. Your documentation isn't, the comments in your code aren't, you will forget why you made a change, anyone reviewing your logs needs to understand your intention, your bug tracker will probably change several times over the life of a project, and so on. So, make an effort to have a commit log that is clean and comprehensive and commits that don't break tests. I go into this in more detail in a talk i gave last week: https://www.youtube.com/watch?v=9OHAq8dCoS4 https://www.youtube.com/watch?v=9OHAq8dCoS4

sergiosgc 10y ago
Develop on feature branches, merge with master only when the feature is done. Always merge with --no-ff. Then, when reviewing history, on the master branch you can use either "git log" or "git log --first-parent master". The first log is the complete log, with exploratory development, mistakes, backtracks and such. The second is the clean log people keep rewriting history to obtain. You get your cake and you can eat it too.
- leejo 10y ago
  This is pretty much the reason i don't understand people who don't want merge commits (the use case for rebase in the video is modifying commits in a feature branch BTW, not merging to master). You can bend git logs to your will with the various options so there's no problem in being as verbose as possible in commit messages and the concept of a "linear history" is a moot point because, no matter how messy your history actual is, there's a command line option to clear it up. Be verbose in your commit messages and don't worry about merge commits, it will pay dividends later.