1 Thanks, Joey! This is awesome...I had to try it out :)
4 I am really happy to hear of this new feature, that I was (more or less)
5 secretly dreaming of. But - and that's why I'm still insanely editing
6 this wiki inside a web browser - I wonder how I'll use it for real: my
7 own master branch contains a few dozens merge commits, and one is created
8 every time I `git pull` ikiwiki repository (or another clone of it, living
9 on one of my other boxes that by chance had Internet access more recently).
10 I do not want to clutter Joey's repository with these commits, so I guess
11 I have to learn some more of Git everything-is-possible world (a nice thing
12 is: I am not limited anymore to "Emacs can do it", and I'm now in a position
13 to say "Git can do it" or "ikiwiki already does it", depending on the
14 situation). Well, let's focus. Git wizards amongst us (let's use this wiki
15 as if it were users@ikiwiki.info, ok?), what would you suggest? I was thinking
16 of having a new branch in my cloned repository, dedicated to editing this wiki;
17 I could use `rebase` instead of `fetch+merge` to get the new upstream commits
18 into this special-purpose branch. I guess it would work nicely if I had only
19 one offline box with not-yet-pushed changes at the same time, but would break
20 in awful and various ways when it is not the case. Any alternative idea?
23 > Not that I'm very careful to avoid pushing merge commits (see git log ;-),
24 > but I sometimes use `git pull --rebase` to pull changes from a repo. That
25 > will rebase your local changes on top of the changes pulled, avoiding the
26 > merge commits. I'm sure more involved solutions are possible. --[[Joey]]
28 > I decided to use my local `master` branch as a copy of `origin/master`
29 > (kitenet) and move my local modifications to a separate branch. I'm using
30 > `master` to edit the wiki but there is still the problem of new upstream
31 > commits since the last pull. I already had this problem as Joey had pushed
32 > some changes while I was editing locally. Not knowing about
33 > `pull --rebase`, I took the long way out: branch, roll back HEAD, rebase,
34 > and merge. That was too much work...It looks like `pull --rebase` is the
35 > way to go. --[[JasonBlevins]]