Hi Guille - thanks for taking the time to write this up… in the middle there I finally spotted the crucial bit “clone the original, push to your fork”. I think thats what I’ve been doing wrong - and it leads to all kinds of confusion (at least I’m hoping this is what it is).
As I have cloned from my Fork (and in my defence - its because we were given a repository that collides with the pharo one - exercism/pharo - and P7 doesn’t let us clone from that) - so I’ve had to clone from my fork. It all seemed to work until I started submitting my PR’s and then they seem to include commits going much further back than I think they should need Even wen I thought I was being careful and syncing to master - it still seems to go back to some of my earliest work. Now that we have managed to get the repo renamed - I will try working like you have suggested and make sure that it is working like you describe - as it shouldn’t be as complicated as this to make clean isolated changes and then submit them as a PR. (otherwise Pharo would fall apart). One question I do have however - is what is the best procedure if you realised when making changes that A) you forgot to make changes in a branch (so are working on master) B) you are working in a branch but decide some of your changes should go in another branch itself based on master (how to stash?) These are 2 common scenarios I’ve found when trying to be a good citizen for my little project. Do I have to go to the terminal to do this stuff - or can I cleanly do these kinds of operations in Pharo (which I think you should be able to do, as its so easy to get into either of those states). Thanks in advance. Tim > On 18 Feb 2019, at 08:56, Guillermo Polito <guillermopol...@gmail.com> wrote: > > Hi! > > On Fri, Feb 15, 2019 at 7:06 PM Tim Mackinnon <tim@testit.works> wrote: > Hi guys - I’ve spent a few hours scratching my head trying to understand why > some of my Pull Requests to a project I had forked kept showing my previous > commits when I thought I was all caught up. > > It suddenly dawned on me, that when I had forked, and then done some work and > then submitted a PR, and then applied it upstream that my fork is now no > longer in sync with its upstream counterpart. > > Having not done this in ages, it took me a while to then realise I have to do > some git stuff to get it back in sync e.g. (and I think I’ve got this right) > > git fetch upstream (or whatever name you gave it) > Git checkout master > Git merge upstream/master > > When you did your clone, did you clone the original repository or your fork's? > One way to simplify this workflow is: > - you clone always the original repository > - you create a branch and work there > - then you'll push your branch to your fork + fork > > That way your branch will be always up to date with the original repository, > and no need to sync (actually the sync is done automatically when you push to > your fork). > > Of course this assumes you're doing a new clone every time you work :). > > > So I guess my question is - wouldn’t it be helpful if this was a command in > Iceberg? > > It would, there are several places where we could simplify the workflow for > common cases, I agree. > > It seems quite common to fork a project (I think this is still recommended > for pharo itself isn’t it?) > > I'd say its mandatory :). Otherwise you will not be able to push directly to > it because of permission problems (actually all main dev branches are now > blocked so **nobody**, not even admins, push to them directly). > > - and then at some point you need to catchup with that origin again? Or am I > missing something? > > Well, it really depends on the workflow you use. Above I've explained a > workflow that works when you clone every time. > Git is so complex and so low level that you can do lots of different things > with it. > > First thing is to understand what "catch up with origin" means. In my head it > only means: > - checkout your "to-catchup" branch > - merge the remote "to-catchup" branch and merge it > > All the rest is workflow dependent. Even (!!) I would argue that merging is > not, strictly speaking, a correct way to catch up: If you have made changes > into "to-catchup", then merging will not make both branches the same, but > your "to-catchup" branch may have extra commits that you did not want to > introduce... > > And here I'm not saying you should not merge, actually I do it most of the > times because I know that 90% of the times it will be ok, and I do rollback > when I realize I was in the other 10%... > > I guess lots of stuff can go wrong - but if it does - you’d still get the > same problems on the command line. > > Yes, and no. The "lots of stuff can go wrong" can be translated in most of > the cases to "I had a merge conflict". But this is not git, this is git+pharo. > > The thing is that with Git, your code is dead in files. With Iceberg, your > code is in the files but it also may be alive in your image too. So updating > code for what you have existing instances, or announcement subscriptions or > other could (and probably will) mess up with the running code... > So to the typical merge conflict, you may add breaking your running system. > > It just seems that for normal situations - it would be handy to run this > straight in Pharo. > > Thoughts from the git experts? > > For these cases, you can do exactly as the command line from Iceberg's UI > > - change your branch to your "to-catchup" master > - fetch > - now you can go to the merge option, and choose to merge your remote branch > into your checked-out branch. > - and push > > Of course, this simple workflow works most of the times, but you may find > edge cases. > For those edge cases (typically updating iceberg itself, or trying to update > pharo itself), in the checkout preview you will have the combo with the > checkout strategy: choose the expert mode "do not load the code". This option > will change the branch on git's world, but it will not load the code in your > image. > > That is useful if you have living instances for example. > This option will though make a diff between the checked out version and your > image code and show you differences. (think this as a git reset --soft) > > To me the fact that we are manipulating live code loaded in the image and not > dead files makes a huge difference, and this makes that extrapolating git > commands to iceberg is not so straight forward :). Also, understanding that > git is stateful/context dependant, and applying an operation means changing > your current state (modify your current branch, change your current branch) > is useful to see the consequences. > > In any case, any more concrete suggestions for enhancing this workflow are > welcome. I think that neither Esteban, Pablo, me nor other contributors are > skilled UI designers, and thinking about the best way to present a usecase to > a user is super super hard :). > > Guille, from his vacations >
