161–170 of 177 posts
Earlier quoted context omitted.
The original commit could be amended to include that information.
The point of using a "proper" merge commit would be to avoid amending/rebasing the original commit and allow the original commit to live as-developed in the final branch.
Earlier quoted context omitted.
And those commits rarely provide useful information because they're of the variety where people fix syntax errors, add missing files, remove changes they didn't mean to commit, etc.
There's plenty of information in all those types of commits even if you personally don't find that information "useful". I've had to do the sort of archeology digs to figure out "what syntax errors did a build tool miss", "why is this type of file often missed to be added, and how often do we miss it", "what was still TODO in this feature effort that got removed at the last minute", etc. All of which needs informatio…
Instead, if you had a commit that explained what the file was for or if some of the lines in that file were added by a commit that explained the change and why it was made, then that would be useful history.
Many times, investigations start with running git blame on a file you plan to make changes to. The usefulness of commit messages associated with each line in a change and whether the diff associated with the commit shows a logical change rather than a fix for a syntax error is the difference between an investigation that leads to results versus one that leads to a dead end.
Earlier quoted context omitted.
> evolve them rapidly with discussion That, in my experience makes it harder to review the change. To me, it's easier to do something like that while pair programming. Code review should be done once a final approach has been taken and only minor changes or factors that the implementation may not have taken into account should be addressed.
Most PR systems have multiple ways to "slice" the changes coming in to specific updates and giving you "bookmarks" for what you've reviewed prior and what is new in the latest update. Just because it may not be your preferred workflow doesn't mean it isn't a useful workflow or that the tools don't already exist to make it a manageable workflow.
And if there are many other such commits addressing different comments, it gets difficult to find the one that specifically addresses the code I commented on.
So, I essentially need to skim through the diff again to find the code that I commented on, open another tab to find my comment and uncollapse it if it's outdated according to Github, and switch back and forth between the tabs to see if my change has been addressed. If it hasn't been addressed, I need to start a new comment thread on the updated diff.
It's certainly not a very efficient workflow.
Earlier quoted context omitted.
The point of using a "proper" merge commit would be to avoid amending/rebasing the original commit and allow the original commit to live as-developed in the final branch.
The only thing changing in the original commit is to include a reference to the PR number in the commit message. There would be no change to the tree referenced by the commit.
Earlier quoted context omitted.
There's plenty of information in all those types of commits even if you personally don't find that information "useful". I've had to do the sort of archeology digs to figure out "what syntax errors did a build tool miss", "why is this type of file often missed to be added, and how often do we miss it", "what was still TODO in this feature effort that got removed at the last minute", etc. All of which needs informatio…
In the instance where a file was missed and added in a later commit, then running git blame would show the sha1 referencing a commit that has a title that says something like "Added missing file". That's not going to tell me anything about why that file was added. Instead, if you had a commit that explained what the file was for or if some of the lines in that file were added by a commit that explained the change and…
Earlier quoted context omitted.
Every merge is a risk of merge conflicts, of bad auto-resolutions (don't get me started on the circle of pain where you need to understand git rerere and its consequences). Just because there are auto-resolutions and they mostly work (most of the time) automatically doesn't mean that all merges are safe. (Fast-forward only merges being an exception, of course.) Rebasing hides the history of those merges, their confli…
If you imagine a VCS where merges didn't exist, then what would you do when the code is updated after you started on a change you were making? You probably would get a copy of the most up to date version of the code and try to apply your changes to it and make sure it still works. That's essentially what rebasing does. What merges do is basically try to have the VCS apply the code changes you made based off an older…
I've certainly used VCSes where merges didn't exist as a first class citizen. They are a huge pain to use, still have to deal with merges and merge conflicts somehow, even if they just push all that work onto the user.
Git presents a DAG as a data structure. Forcing it into a "straight line", in my opinion, is a silly amount of work when you can use the power of a DAG, including filtering/culling your "depth" views into the DAG to manage it.
I understand that a straight line is "cleaner" and often easier to read. I'd rather use the power of the DAG to query straight lines than do a lot of work up front to artificially make straight lines. I understand that this is a difference of opinion you are unlikely to share, that's fine, there's no "one workflow" for everyone.
Earlier quoted context omitted.
If you imagine a VCS where merges didn't exist, then what would you do when the code is updated after you started on a change you were making? You probably would get a copy of the most up to date version of the code and try to apply your changes to it and make sure it still works. That's essentially what rebasing does. What merges do is basically try to have the VCS apply the code changes you made based off an older…
> If you imagine a VCS where merges didn't exist I've certainly used VCSes where merges didn't exist as a first class citizen. They are a huge pain to use, still have to deal with merges and merge conflicts somehow , even if they just push all that work onto the user. Git presents a DAG as a data structure. Forcing it into a "straight line", in my opinion, is a silly amount of work when you can use the power of a DAG…
Earlier quoted context omitted.
The only thing changing in the original commit is to include a reference to the PR number in the commit message. There would be no change to the tree referenced by the commit.
It's an entirely different commit at that point. If work has already started in another branch based on the original commit (for whatever reason), it can cause merge problems down the road. Again, you are likely going to suggest that you can just rebase this other branch on top of the modified commit, but that's still sweeping possible merge commits under the rug, and again just because that rebase is usually automat…
So something like:
git commit --amend
Earlier quoted context omitted.
In the instance where a file was missed and added in a later commit, then running git blame would show the sha1 referencing a commit that has a title that says something like "Added missing file". That's not going to tell me anything about why that file was added. Instead, if you had a commit that explained what the file was for or if some of the lines in that file were added by a commit that explained the change and…
I already mentioned `git blame --first-parent` just a few comments up! You get the sha1 referencing a commit that has a title like "Merged PR #327". You can dig down deeper than that --first-parent level if need be, but you have the power of the git graph to show/hide details if when you do/do not need them.
Earlier quoted context omitted.
It's an entirely different commit at that point. If work has already started in another branch based on the original commit (for whatever reason), it can cause merge problems down the road. Again, you are likely going to suggest that you can just rebase this other branch on top of the modified commit, but that's still sweeping possible merge commits under the rug, and again just because that rebase is usually automat…
I'm talking about a single commit PR in Github or Gitlab. If it's based on the latest version of the base branch, then amending it to include the PR number would allow Github to generate a link to the PR page associated with that commit. That would make the merge commit superfluous at that point. So something like: git commit --amend and editing the commit message. This doesn't introduce any further change to the tre…
For illustration, a minor inconvenience of amending the commit is that `git branch -d my-feature-branch` no longer succeeds for the original branch, because it looks for the actual commit SHA, not the tree.
You may not care about the effects of changing the commit, but those effects are real and other people care.