Use a better graphical Git client ? (instead of Github itself) I personally just do my reviews through "Gitk" from my Git Bash install on Windows. Screenshot: Gitk.PNG<https://docs.google.com/file/d/0B533WzlrxWraX1U5eDJ0S245ZVE/edit?usp=drive_web>
On Linux, you might be better suited with other graphical Git clients, just for your own browsing of auto-merges, etc. Here's a dated article (2012) that covers some of them: http://www.maketecheasier.com/6-useful-graphical-git-client-for-linux/ On Mon, Feb 17, 2014 at 9:34 PM, Palmer Cox <[email protected]> wrote: > 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 > > -- -Thad +ThadGuidry <https://www.google.com/+ThadGuidry> Thad on LinkedIn <http://www.linkedin.com/in/thadguidry/>
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
