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 <palmer...@gmail.com> 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 <byt...@gmail.com> 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 <st...@steveklabnik.com >>> >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 >> Rust-dev@mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
