If bors rewrites the commit messages, it means that if someone approves commit ABC, what actually gets merged will be commit XYZ. This seems potentially confusing to me and might also make it more difficult to start with a reviewed commit on Github, such as https://github.com/gentlefolk/rust/commit/37bf97a0f9cc764a19dfcff21d62384b2445dcbc, and then track back to the actually merged commit in the history.
I'm also not 100% sure, but I think git might have some issues with it as well. If I do my work on a throwaway branch, after merging, will git know that the changes in that branch were merged? Or, will git require me to do a git branch -D to delete that branch? Are there other projects that rewrite commit messages before merging? It seems to me that the ideal case would be for Github to add a link on the commit view page back to the PR that merged that commit. I'd be concerned that if Github adds support for such a feature in the future that it might not work if we've re-written all of the commit messages in the meantime. -Palmer Cox On Mon, Feb 17, 2014 at 9:28 PM, Nick Cameron <[email protected]> wrote: > You are right, it is about convenient access to the info, not the lack of > info. > > What is problematic about bors rewriting commit messages and changing > hashes? My workflow is to always work on throw away branches and merge back > into master. Is it common to work on master and merge back on top of your > PR? Or are there other problems with changing the hash? > > > On Tue, Feb 18, 2014 at 3:22 PM, Palmer Cox <[email protected]> wrote: > >> The PR# and who reviewed it is already available in the merge commit and >> its already possible to take any arbitrary commit and to see which merge >> commit merged it into master. So, I don't see any benefit in changing >> anything about the merge commit. Unless I'm missing something, this isn't a >> question of information not being available; its a question of that >> information being inconvenient to get to. I think having bors rewrite the >> commit messages would be somewhat problematic since it would change all the >> hashes. So, I think the only solution would be to manually put the issue >> number into the messages. However, many PRs aren't related to issues. So, >> if some large percentages of commits are just annotated with "no issue" or >> the like, it seems to really impact the utility of this change. Thus, I >> think it would really have to be the PR# instead of an issue # since every >> commit is related to a PR. However, I think it isn't a zero impact >> procedure. I always right the changes I want to merge before opening the >> PR. So, when I'm making my changes, I don't know what the eventual PR# is >> going to be. Only after I open the PR with the commits already created, I >> find out the PR#. So, then I'd have to rewrite all of the commit messages >> and force push back into the branch to get the numbers right. Its not the >> worst thing in the world, but it is an extra few steps. >> >> So, I strongly agree that the current procedure for finding the github >> discussion is fairly unpleasant and I very much wish that Github had a >> button that would take me to the PR that merged it. However, I don't think >> there is a 100% consistent, zero impact workaround for that missing feature >> in Github. >> >> My vote would be to leave things as they are. A little scripting could >> improve the situation quite a bit, although it still won't be as nice as >> being able to click on a link in Github. >> >> -Palmer Cox >> >> >> >> >> >> >> >> On Mon, Feb 17, 2014 at 9:02 PM, Scott Lawrence <[email protected]> wrote: >> >>> What about having bors place the hash of each commit merged into the >>> auto-merge message? Then finding the PR, and any closed issues, consists of >>> backwards-searching in git-log. (Having bors modify commit messages would >>> probably cause major problems with hashes changing.) >>> >>> >>> On Tue, 18 Feb 2014, Nick Cameron wrote: >>> >>> Adding a few chars to a commit is not onerous and it is useful. You may >>>> not >>>> want it now, but perhaps you would if you had it to use. _I_ certainly >>>> want >>>> it, and I think others would find it useful if it was there to use. >>>> >>>> >>>> On Tue, Feb 18, 2014 at 1:37 PM, Steve Klabnik <[email protected] >>>> >wrote: >>>> >>>> Yeah, I'm not into modifying every single commit, I basically only >>>>> want what bors already (apparently....) already does. >>>>> >>>>> >>>> >>> -- >>> Scott Lawrence >>> >>> _______________________________________________ >>> Rust-dev mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/rust-dev >>> >> >> >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
