> You are right, it is about convenient access to the info, not the lack of > info. I often wish I could conveniently find this information--far too often it's hard to identify the PR when a breaking feature came in. Often I end up waiting for Corey to publish TWiR, with all the relevant issue numbers in it... but this makes it hard for me to include references in commit messages in my own repositories. More often than not, it's an issue in the clarity and distinctness of the pull requests rather than the code, but often finding the changeset is easy and the PR hard.
> 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? It is not uncommon to base one's work upon another branch (one's own or another's), depending on that landing before the aforementioned work can land, or alternatively landing the depended-upon feature as part of said work. What is at present approximately automatic there would become a manual rebasing-- certainly not insurmountable, but an added inconvenience. _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
