3 ms·

You've just described the problem that rebasing fixes. Because your git history is a mess you have to look up PRs in Jira rather than having your git history be

You've just described the problem that rebasing fixes. Because your git history is a mess you have to look up PRs in Jira rather than having your git history be something useful by itself.

mcv 7y ago
How does rebasing fix any of that? Rebasing changes your history, and can just as easily make a mess of your history as it can make it prettier. I use it sparingly, but I don't mind people avoiding it altogether. Rebasing fixes nothing.
hvidgaard 7y ago
What he says is that they can achieve what they want, by other means than looking at the git history by itself, and it sounds like it's less work and scales better with the number of committers.
- etripe 7y ago
  Except for when you change from JIRA to some other project tracking tool. I think this is worth considering since project and people management trends tend to suffer from more churn than version control systems. In my book, it's easier to auto-import sensible git logs into JIRA than trying to do the reverse. Then again, I'm of the opinion that git history matters, specifically for commit messages. Otherwise, you might as well create a pre-commit hook pointing to http://whatthecommit.com http://whatthecommit.com
- tremon 7y ago
  ...until you change your organisation tools. If you keep your development rationale with the code, you can always change or rearrange the rest of your tooling without losing vital information. If you put your edit history in a loosely-coupled system, you've now made that system as essential to your codebase's survival as the code itself.
trixie_ 7y ago
It's not a mess at all, very clear actually. We enforce commit messages to be prefixed with the ticket number which makes it easy to query git log for all changes related to any PR with full history of who, when, and why each change was made.

3 ms·

You've just described the problem that rebasing fixes. Because your git history is a mess you have to look up PRs in Jira rather than having your git history be

by plorkyeran 7y ago

You've just described the problem that rebasing fixes. Because your git history is a mess you have to look up PRs in Jira rather than having your git history be something useful by itself.

mcv 7y ago
How does rebasing fix any of that? Rebasing changes your history, and can just as easily make a mess of your history as it can make it prettier. I use it sparingly, but I don't mind people avoiding it altogether. Rebasing fixes nothing.
hvidgaard 7y ago
What he says is that they can achieve what they want, by other means than looking at the git history by itself, and it sounds like it's less work and scales better with the number of committers.
- etripe 7y ago
  Except for when you change from JIRA to some other project tracking tool. I think this is worth considering since project and people management trends tend to suffer from more churn than version control systems. In my book, it's easier to auto-import sensible git logs into JIRA than trying to do the reverse. Then again, I'm of the opinion that git history matters, specifically for commit messages. Otherwise, you might as well create a pre-commit hook pointing to http://whatthecommit.com http://whatthecommit.com
- tremon 7y ago
  ...until you change your organisation tools. If you keep your development rationale with the code, you can always change or rearrange the rest of your tooling without losing vital information. If you put your edit history in a loosely-coupled system, you've now made that system as essential to your codebase's survival as the code itself.
trixie_ 7y ago
It's not a mess at all, very clear actually. We enforce commit messages to be prefixed with the ticket number which makes it easy to query git log for all changes related to any PR with full history of who, when, and why each change was made.