On Fri, May 26, 2017 at 2:17 PM, sebb <[email protected]> wrote: > On 26 May 2017 at 17:02, Sam Ruby <[email protected]> wrote: >> On Fri, May 26, 2017 at 11:34 AM, Shane Curcuru <[email protected]> >> wrote: >>> sebb wrote on 5/25/17 3:57 PM: >>>> If someone else has committed since I last synchronised the workspace, >>>> I have found that I can eliminate some commit noise as follows: >>> >>> Are there equivalent buttons in the GitHub Desktop app? >> >> I presume that what Sebb described isn't necessary on the GitHub >> Desktop app as we haven't been seeing any 'noise' from you (read: >> merge commits). > > What about the following [1] ?
That's unavoidable. Squishing things you haven't pushed yet is a good idea. For whatever reason, Shane opted to work on a branch, and push his branch to github. Once pushed, any changes (including merges) will be visible to all, and will result in notifications. Using branches for larger changes is a reasonable thing do to. I try to avoid doing it (preferring a number of smaller, incremental changes), but different people may chose different strategies. >> Note: my workflow is slightly different than Sebb's. I make my >> changes and commit them. If my push fails, I do a pull and rebase >> (with no parameters), and retry the push. In the rare case that I >> have uncommitted changes, I do the stash and apply (with apply being a >> synonym for pop) dance that Sebb described. > > That sounds just like the process I use, so maybe I explained it wrong. > >>> Corollary-wise: are there techniques developers should use in the GH >>> Desktop app to reduce excess commit notifications for people using the >>> command line or other methods? >>> >>> Since whimsy is both a PMC-maintained server environment with many >>> integrations, as well as a host of unrelated tools, any suggestions for >>> how individual developers can respect the rest of the PMC's working >>> style are appreciated. >> >> I gather that Sebb uses Eclipse, and further gather that Eclipse is >> mildly deficient in its Ruby support. While I certainly have no >> intention of going out of my way to make it more difficult to use >> Eclipse, I'm also perfectly fine with leaving the changes that Sebb >> has made to work around some of the Eclipse plugin implementation >> (mostly which seem to revolve around the use of keywords as symbols). > > Also some new syntax such as squiggly heredoc. > > Likewise, if it requires a lot of changes to allow the Eclipse plugin > to work, then I'll leave it alone. Cool. > S > [1] > https://lists.apache.org/thread.html/38b3134e94da85d8bdfd1dd277b21f9d7e93c21431ff667d74896b7b@%3Ccommits.whimsical.apache.org%3E > >>> - Shane, the visual coder >> >> - Sam Ruby >> >>>> $ git pull >>>> $ git rebase -i origin/master >>>> (just accept the suggested action) >>>> >>>> If the workspace has other pending changes, the rebase may complain. >>>> In which case it may be necessary to redo the rebase as follows: >>>> >>>> $ git stash >>>> $ git rebase -i origin/master >>>> (just accept the suggested action) >>>> $ git stash pop >>>> >>>> The changes can then be pushed. >>>> >>>> HTH >>>> >>> >>> >>> -- >>> >>> - Shane >>> https://www.apache.org/foundation/marks/resources
