doc/news/git_push_to_this_wiki/discussion.mdwn

   1 Thanks, Joey!  This is awesome...I had to try it out :)
   2 --[[JasonBlevins]]
   3
   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?
  21 --[[intrigeri]]
  22
  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]]
  27
  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]]
  36
  37 Awesome ! --[[xma]]