> On 14 Apr 2016, at 8:44 AM, Alex Tweedly <a...@tweedly.net> wrote: > > > > On 13/04/2016 22:45, Monte Goulding wrote: >> GitHub <> git and you are using GitHub which has hacked on a web interface >> for working on stuff. I honestly think that if folks spent the same amount >> of time working out the web interface as working out how to use git locally >> using a good git gui then they would be finding things much simpler. The >> main issue is locally you need to actively switch branches so you always >> know where you are but on the web it is much easier to jump between branches >> and get confused. > Monte, I'm probably just caffeine-deprived,
You and me both ;-) > but I have trouble parsing that first sentence. Sorry, hopefully my comments below will clarify > I *think* you're recommending using a git gui, and not using the web > interface - but it could be just the inverse. Yes, I think a good git gui would be about the same size learning curve but the end result would be a much faster and easier to understand procedure. > > Which do you recommend? > If it's a git gui - any favourite(s) ? SourceTree sourcetreeapp.com for Windows and Mac. > > Being old-fashioned, I started with the command-line interface :-) But even > then, Ali's document switched into the web interface at a couple of crucial > points. If you are comfortable on the command line I would stay there as there’s stuff you can do on the command line that no git-gui will do for you. I tend to jump back and forth because I like to use the gui for more of an overview of what’s going on in the repo. I’m suggesting this more for folks struggling with the web interface. Yes you will need to use GitHubs UI to send a patch for review. > > I do think there are some errors or omissions in the "git gui" section of his > document, but I don't know enough to be sure, far less to fix them …. The biggest issue i see with it is there’s no upstream remote setup which is required in order to fetch changes that have been merged into the main repo but push changes to your fork. Probably the reason for this is unless the document talks specifically about a single git gui (possibly not a bad idea) then the process for adding a remote will be different. Alternatively we could just steal the command line from the command line section. > > For example >> >> Make sure both the docs change and the bugfix note are ready for commit in >> the GUI client. >> >> In the summary and description section, >> >> The title should be along the lines of >> > > and later ... >> >> Click commit to >> >> Then click "Submit pull request" >> > >> There is a way for others to work on things together and given that’s the >> point of git that’s a good thing! The way to do it is to go to your patch-4 >> branch, edit and then submit a PR to you which you then incorporate and >> which would reflect the changes in your PR. In the past I have sent PRs to >> branches on other people’s forks on the team and had team members send PRs >> to my branches that I have had in review. >> > What's a "patch-4 branch" ? > I've only got as far as submitting a couple of trivial changes - but I'm > pretty sure I didn't have a patch-4 branch ? OK, sorry for the confusion. This was specifically targeting Mike’s patch to the send command docs which on his fork github.com/macmikey/livecode is in a branch named patch-4. To do what I was suggesting on a git gui or command line you would add his fork as a remote, checkout the patch-4 branch, make a change, push to your fork then send a PR to his fork. This isn’t a normal part of the contribution process so I wouldn’t worry about it for now I just wanted to clarify that yes, people can collaborate outside the normal PR review process and their work can be combined into the one PR submitted to the team. _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
