Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Post History
Here's the problem: Wednesday I make the changes, git commit --amend them Just do a normal commit. You are trying to re-write, or cover up, history. That's generally bad. The record should ref...
Answer
#3: Post edited
- Here's the problem:
- <blockquote>Wednesday I make the changes, <code>git commit --amend</code> them</blockquote>
- Just do a normal commit. You are trying to re-write, or cover up, history. That's generally bad.
- The record should reflect what really happened: You submitted a patch, it was rejected for xxx reason, you changed the patch, it was accepted. You have no way of knowing what part of that might be useful information a month, a year, or years in the future. The cost is tiny. Do it right.
- <blockquote>I haven't altered anything that has been pushed</blockquote>
- Actually you are. You are changing the comments for the commit.
It seems the overall problem is that your group uses commit comments poorly, and therefore values them less.
- Here's the problem:
- <blockquote>Wednesday I make the changes, <code>git commit --amend</code> them</blockquote>
- Just do a normal commit. You are trying to re-write, or cover up, history. That's generally bad.
- The record should reflect what really happened: You submitted a patch, it was rejected for xxx reason, you changed the patch, it was accepted. You have no way of knowing what part of that might be useful information a month, a year, or years in the future. The cost is tiny. Do it right.
- <blockquote>I haven't altered anything that has been pushed</blockquote>
- Actually you are. You are changing the comments for the commit.
- It seems the overall problem is that your group uses commit comments poorly, and therefore values them less.
- <blockquote>I should be able to read all the drafts, right down to the first one, rather than just the final printed edition</blockquote>
- Yes. That's rather the basis of source control. Remember also that this is for the people the write the software, not the public that just uses the software.
#2: Post edited
- Here's the problem:
- <blockquote>Wednesday I make the changes, <code>git commit --amend</code> them</blockquote>
- Just do a normal commit. You are trying to re-write, or cover up, history. That's generally bad.
- The record should reflect what really happened: You submitted a patch, it was rejected for xxx reason, you changed the patch, it was accepted. You have no way of knowing what part of that might be useful information a month, a year, or years in the future. The cost is tiny. Do it right.
- Here's the problem:
- <blockquote>Wednesday I make the changes, <code>git commit --amend</code> them</blockquote>
- Just do a normal commit. You are trying to re-write, or cover up, history. That's generally bad.
- The record should reflect what really happened: You submitted a patch, it was rejected for xxx reason, you changed the patch, it was accepted. You have no way of knowing what part of that might be useful information a month, a year, or years in the future. The cost is tiny. Do it right.
- <blockquote>I haven't altered anything that has been pushed</blockquote>
- Actually you are. You are changing the comments for the commit.
- It seems the overall problem is that your group uses commit comments poorly, and therefore values them less.
#1: Initial revision
Here's the problem: <blockquote>Wednesday I make the changes, <code>git commit --amend</code> them</blockquote> Just do a normal commit. You are trying to re-write, or cover up, history. That's generally bad. The record should reflect what really happened: You submitted a patch, it was rejected for xxx reason, you changed the patch, it was accepted. You have no way of knowing what part of that might be useful information a month, a year, or years in the future. The cost is tiny. Do it right.