mozilla :: #mozreview

18 May 2017
15:00bytesizedIs it now possible to post multiple patches on one bug via Review Board? How is this done?
15:29mcotebytesized: you need to specify a new reviewid with a different "nick". see http://mozilla-version-control-tools.readthedocs.io/en/latest/mozreview/commits.html#bug-references-review-identifiers-and-grouping-commits
15:30* bytesized looks
15:45bytesizedmcote: This documentation is very confusing to me. "Most of the time, Review IDs are hidden and silently enable grouping of commits without issue." makes it sound like I can just |hg push review| a second commit and it will just be grouped correctly with any previous ones and (presumably) the bug will be updated to reflect that.
15:45bytesizedBut "Since Review IDs are derived from your username and the first bug number referenced in the submitted commits, a duplicate Review ID can be automatically selected. This can lead to problems such as overwriting an existing group of review requests with unrelated commits." sounds like it is warning me against doing exactly that.
15:45bytesizedAnd you are saying I need to specify a new reviewid with a different nick, which I do not see information about in the documentation. Could I get a bit more clarification please?
15:49mcotebytesized: let me get back to you in a few minutes (in a meeting)
15:49bytesizedok, np
15:49bytesizedno hurry
18:18mcotebytesized: so, depends on what you are trying to do
18:18bytesizedwell
18:18mcotebytesized: if you have one (or more) commits, and you want to add a new one to that series, then yeah, just push them up again
18:19bytesizedoh, alright. that's easy
18:19mcoteif you want to start a whole new series, then you need to provide a new reviewid, which defines a series of commits
18:19bytesizedwhat's the difference?
18:19mcotea series is basically a logical set of commits
18:19mcotewe enable this to encourage breaking up a work item into a small number of atomic commits
18:20mcotee.g. if you have to write a new function but refactor another one first, best to do the refactor in one commit, then the new function in another commit, rather than mashing them together
18:20mcotemakes it easier to test and review
18:20bytesizedah, that sounds like what I want
18:20mcoteoccasionally you'd need a whole new series, for example, if your first series has landed (you can't add commits to a landed series)
18:20bytesizedso I can simply push again, and it will all figure it out for me?
18:20bytesizedthat is easy
18:20mcoteyup!
18:20bytesizedgreat, thanks
18:20mcoteyou'll see a new commit in the table at the top
18:21mcotehowever
18:21mcoteif you are *fixing* up something (addressing a review comment), you'll want to amend your current commit and push it up
18:21bytesizedright
18:21mcotenot the GitHub-style "fix-up" commit workflow
18:21mcotethat's discouraged because the fix-up commit can't be logically separated from the original
18:22bytesizedmcote: so what if I am changing a commit that is not the most recent?
18:22mcoteyou can use histedit and/or rebasee
18:22mcoteto edit the target commit
18:24bytesizedmcote: so I want to commit (creating a new head) to the target commit, then rebase future changes on that, then histedit to combine the commit that I wanted to amend?
18:24bytesizedthen push?
18:25mcoteyou could, although it's easier to go to your current head, then do a histedit
18:26mcotemark the commit you want to update as "edit"
18:26mcotemake your changes, then do histedit --continue
18:26mcotewhich will automatically rebase dependent commits
18:27mcoteI actually have an hg alias that does a histedit for the current commit and all history down to where I branched off
18:27bytesizedoh, I don't think I've used the "edit" feature before, but that sounds straightforward
18:27mcotehistedit 'first(ancestors(.) & draft())'
18:27mcotethat will include every commit that is in the "draft" phase, starting with the currently checked-out one
18:28mcoteyeah it's pretty neat :)
18:28mcotejust don't do "hg commit" unless you want to insert a new commit
18:28mcote(sometimes you might, to split up a commit into further pieces, but generally you don't)
18:28bytesizedok, I think this all sounds good. It would be nice if this process was documented somewhere though, since it is a bit complicated
18:28mcoteI think it might be
18:28mcoteone sec
18:29mcotebytesized: http://mozilla-version-control-tools.readthedocs.io/en/latest/hgmozilla/workflows.html and subsequent sections
18:29mcotenot sure if it has everything I just mentioned but it's got a lot there
18:30* bytesized bookmarks
18:30bytesizedthanks!
18:30mcotelots of good stuff in that doc in general, for working with mecurial in a firefoxy way :)
18:31mcotemercurial actually has a lot really useful, powerful features, but they are sort of buried because many people still use mercurial in an old-fashioned way, more like svn
22:12pulsebotCheck-in: https://hg.mozilla.org/hgcustom/version-control-tools/rev/70fe96d2e44b - Mike Hommey - Bug 1365841 - Adapt cinnabar-debug-push script to upcoming changes to cinnabar, part 2. r=gps
19 May 2017
No messages
   
Last message: 5 days and 12 hours ago