0

I have a blog based on a clone of the eleventy-base-blog repo. When I cloned it, I left the original code untouched in the master branch, and have made all my customisations and content changes in my own blog branch (so I could easily start from scratch by making a new branch from pristine master, if I made a mess of things).

Obviously I customise and make changes to my version, and over time it diverges from the upstream version, as well as from my local master branch.

I recently realised that I might be missing important bug fixes, improvements and new features from upstream, so I looked into how I could update my fork so as to keep up to date.

The answer I found, after much searching and trying to get clarity from all the range of advice out there (1, 2, 3), seemed to be to use git rebase, so I tried doing:

git checkout master
git pull upstream master
git checkout blog
git rebase master

(this suggests I should have done fetch && reset --hard instead of pull)

but this ended up with a load of merge conflicts that I had to painstakingly wade through and manually fix. It seemed like my whole commit history needed yet another round of editing followed by

git rebase --continue

or whatever (see scenario #1 here). I really don't want to have to do all that every time I want to get upstream updates. I didn't realise there would be so many conflicts.

So, what's a better way, if any, of getting a more seamless upgrade to the latest eleventy-base-blog, without having to manually preserve all my own customisations and edits? I feel like I am missing something, and it would be good to know how to do this better. Then I can maybe contribute a good updating procedure to be included in the docs for eleventy-base-blog.

tripleee
  • 139,311
  • 24
  • 207
  • 268
Francis Barton
  • 305
  • 1
  • 13
  • 2
    If you and upstream both changed a particular line, the really isn't a way to avoid manual reconciliation. If you get conflicts in places you hadn't modified, something fundamental is wrong. – tripleee Jan 04 '20 at 16:08
  • Thanks. Some of the conflicts were where I had made edits - that makes sense, at least, though it would be lovely if there were a more user-friendly way of ignoring or accepting the changes... Other conflicts were in files like package-lock.json where all the lines with new file version numbers etc had to be accepted by me going through and manually editing out the older lines. – Francis Barton Jan 04 '20 at 16:12
  • 2
    You can specify a specific merge strategy for those types of files, i.e. https://stackoverflow.com/questions/173919/is-there-a-theirs-version-of-git-merge-s-ours – tripleee Jan 04 '20 at 16:17
  • I just found this similar advice https://stackoverflow.com/a/39771096/5168907, as well the suggestion of `git mergetool` which I think would be helpful for my situation. – Francis Barton Jan 04 '20 at 16:21
  • Does this answer your question? [How to resolve merge conflicts in Git](https://stackoverflow.com/questions/161813/how-to-resolve-merge-conflicts-in-git) – tripleee Jan 04 '20 at 16:22
  • The link I posted in previous comment was to one of the answers of that question :-). Helpful stuff! I am new to this particular way of using git, as you can tell. I think sometimes one doesn't know quite what question one is asking, until one asks it... I think a more friendly way of navigating merge conflicts is a big part of the answer I was looking for, and I have got that answer now I think. – Francis Barton Jan 04 '20 at 16:27
  • 2
    If one of the answers there solved your problem, please accept the duplicate nomination. – tripleee Jan 04 '20 at 16:28
  • The other part of the question is specific to eleventy, and I suppose I'm wondering if updating my fork from upstream is actually of any use; does it give me anything significant beyond what doing `npm update` in the eleventy folder gives me anyway. – Francis Barton Jan 04 '20 at 16:31

0 Answers0