4 ms·

You are implying the original branch holding that history will be deleted when squashed into a single commit for a PR. That's not the case (granted, that's base

by _hao 5y ago

You are implying the original branch holding that history will be deleted when squashed into a single commit for a PR. That's not the case (granted, that's based on settings on GitHub, Azure DevOps whatever you're using, but the option is there) because in the PR you still see which branch the changes come from. If you're not deleting the branches you're good. Even if you delete the branch when merging I think most PR views nowadays will keep that info (the commits) in perpetuity. Again, I don't think this is a problem.

Double_a_92 5y ago
Are you sure? My common usecase when debugging something is "Why is this line of code like this, and who might know something about it?". So then I git blame that file and see when exactly that line was modified. If that line is inside some huge blob of changes (from weeks of work) inside one commit, that is less useful to me. Even if the original branch is still floating around somewhere, that would still be an extra hassle.
- _hao 5y ago
  > If that line is inside some huge blob of changes (from weeks of work) inside one commit, that is less useful to me. Yes, that's true. My original point still stands though. That commit will have a PR associated with it. You can go to it and see the details of all commits that were used for the merge commit that went into master. Not really a lot of extra work to go to the PR if you're investigating that deep. > Even if the original branch is still floating around somewhere, that would still be an extra hassle. If the branch deletion setting when merging a PR is selected, then only the origin branch will be deleted. If you're the one doing the PR and you don't delete your local branches you'll be able to see it locally. In the other case where is someone else's then it becomes harder, and I agree it's an extra hassle. In my work I try to mandate PR's to be as small as possible, but not smaller. Big PR's do happen, but that and resorting to git blame or bisect happens maybe 2-3 times a year. I think the general rules for source control followed by the team are more important than the implementation details and git magic.

by _hao 5y ago

Double_a_92 5y ago

Are you sure? My common usecase when debugging something is "Why is this line of code like this, and who might know something about it?". So then I git blame that file and see when exactly that line was modified. If that line is inside some huge blob of changes (from weeks of work) inside one commit, that is less useful to me. Even if the original branch is still floating around somewhere, that would still be an extra hassle.

_hao 5y ago
> If that line is inside some huge blob of changes (from weeks of work) inside one commit, that is less useful to me. Yes, that's true. My original point still stands though. That commit will have a PR associated with it. You can go to it and see the details of all commits that were used for the merge commit that went into master. Not really a lot of extra work to go to the PR if you're investigating that deep. > Even if the original branch is still floating around somewhere, that would still be an extra hassle. If the branch deletion setting when merging a PR is selected, then only the origin branch will be deleted. If you're the one doing the PR and you don't delete your local branches you'll be able to see it locally. In the other case where is someone else's then it becomes harder, and I agree it's an extra hassle. In my work I try to mandate PR's to be as small as possible, but not smaller. Big PR's do happen, but that and resorting to git blame or bisect happens maybe 2-3 times a year. I think the general rules for source control followed by the team are more important than the implementation details and git magic.