1

So I've been trying to use the following post-commit hook to keep my gh-pages branch up to date with master:

#!/bin/sh
git checkout gh-pages
git rebase master
git checkout master

Per suggestion here

Here is some output from my git lg command which is this (I found it somewhere here on SO, thanks whoever posted it)

[alias]
    lg = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative

It produces a nice readable dump in the terminal:

*   463703d - (HEAD, gh-pages) Merge branch 'gh-pages' of github.com:unphased/ply into gh-pages (2 minutes ago) <Ste
|\  
| *   ef1a304 - (origin/gh-pages) Merge branch 'gh-pages' of github.com:unphased/ply into gh-pages (8 minutes ago) <
| |\  
| | *   2d0c8a1 - Merge branch 'gh-pages' of github.com:unphased/ply into gh-pages (26 minutes ago) <Steven Lu>
| | |\  
| | | *   840df78 - Merge branch 'master' into gh-pages (68 minutes ago) <Steven Lu>
| | | |\  
| | | * \   7db37cc - Merge branch 'master' into gh-pages (7 hours ago) <Steven Lu>
| | | |\ \  
| | | * | | 17f3dbc - Create gh-pages branch via GitHub (24 hours ago) <Steven Lu>
| | |  / /  
| | * | | 48bdf22 - Create gh-pages branch via GitHub (31 minutes ago) <Steven Lu>
| * | | | d15c161 - Create gh-pages branch via GitHub (9 minutes ago) <Steven Lu>
* | | | | 7024a62 - Create gh-pages branch via GitHub (4 minutes ago) <Steven Lu>
* | | | | f61b62d - (master) hopefully stuff calms down (4 minutes ago) <Steven Lu>
|/ / / /  
* | | | 05c26a5 - (origin/master, origin/HEAD) some more progress (9 minutes ago) <Steven Lu>
|/ / /  
* | | 20c6bdb - some progess on the touchmove event handler finally. hopefully this one will run the post-commit hoo
* | | d1ab53e - commented out touchmove log.. testing the auto-rebase on gh-pages (45 minutes ago) <Steven Lu>
| |/  
|/|   
* | 15fe88d - small update to js (70 minutes ago) <Steven Lu>
|/  
* 6b5ee18 - updating note about mutation events' (7 hours ago) <Steven Lu>
* 1b43564 - okay now about ready to start assembling offsets. [snip]

The rest of the history is pretty uninteresting (here is a github network graph representation which may be somewhat less headachy), and I was hoping to keep the new bits (the updating of gh-pages) to also be uninteresting, but it is clear to me right now that there are a buttload of non-fast-forward merges that are happening that shouldn't be happening if rebase is correctly occurring.

So, since I have absolutely no idea where to even begin diagnosing the problem of what goes wrong when the rebase happens I'll show you the output of the last time I committed, which produced this (I commit to master):

$ git commit -a -m"hopefully stuff calms down"
Switched to branch 'gh-pages'
First, rewinding head to replay your work on top of it...
gApplying: Create gh-pages branch via GitHub
iApplying: Create gh-pages branch via GitHub
Using index info to reconstruct a base tree...
<stdin>:985: trailing whitespace.

<stdin>:1019: trailing whitespace.
article, aside, canvas, details, embed, 
<stdin>:1020: trailing whitespace.
figure, figcaption, footer, header, hgroup, 
<stdin>:1031: trailing whitespace.
article, aside, details, figcaption, figure, 
<stdin>:1055: trailing whitespace.
  line-height: 1.5; 
warning: squelched 27 whitespace errors
warning: 32 lines add whitespace errors.
Falling back to patching base and 3-way merge...
No changes -- Patch already applied.
Applying: Create gh-pages branch via GitHub
Using index info to reconstruct a base tree...
<stdin>:985: trailing whitespace.

<stdin>:1019: trailing whitespace.
article, aside, canvas, details, embed, 
<stdin>:1020: trailing whitespace.
figure, figcaption, footer, header, hgroup, 
<stdin>:1031: trailing whitespace.
article, aside, details, figcaption, figure, 
<stdin>:1055: trailing whitespace.
  line-height: 1.5; 
warning: squelched 27 whitespace errors
warning: 32 lines add whitespace errors.
Falling back to patching base and 3-way merge...
No changes -- Patch already applied.
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 1 commit.
[master f61b62d] hopefully stuff calms down
 1 files changed, 2 insertions(+), 1 deletions(-)

Out of the many things here that look out of the ordinary one i'm curious about is why commits labeled with "Create gh-pages branch via GitHub" keep getting added. That is indeed the most up to date commit on the gh-pages branch and which presumably gets re-appended upon performing the rebase, but the issue seems to be that something is causing the requirement of merging when they should be fast-forwards.

I am pretty sure that if I've got this right that using rebase I can produce a log where each commit to master is duplicated in gh-pages (rather than using merge where a merge commit is created in gh-pages for each commit in master), but right now I have to do merging without rebasing or I get this unholy mess.

Steven Lu
  • 41,389
  • 58
  • 210
  • 364
  • 1
    A rebase in a post-commit hook seems like a terrible idea. Why would you want this and why would you think it would always make fast-forwardable commits? – Ilion Jan 08 '13 at 09:01
  • Like I said I'm not sure: it's pretty clear that I'm not supposed to rebase an already-pushed branch. So I have no idea why people would suggest to have this be the method to keep `gh-pages` up to date. I had simply assumed that these people making the blog posts know what they are doing. – Steven Lu Jan 08 '13 at 14:10
  • Here's where I found the advice: http://oli.jp/2011/github-pages-workflow/ – Steven Lu Jan 08 '13 at 14:12
  • [This](http://stackoverflow.com/a/9074343/1084945) might be where you found the `alias`, in case you were looking for it. :) – simont Jan 08 '13 at 14:32
  • I think [this question](http://stackoverflow.com/questions/559917/git-rebase-and-git-push-non-fast-forward-why-use) is probably relevant. If `gh-pages` is always *behind* `master` (that is, a `merge` of `master` **into** `gh-pages` will always be a `fast-forward` merge), perhaps changing the hook to `merge` rather than `rebase` would work. – simont Jan 08 '13 at 14:39
  • Could the original `rebase` workflow work if I was doing my work in the `gh-pages` branch instead? But I think that means the command would have to be `git rebase gh-pages` from the `master` branch instead. Makes no sense. – Steven Lu Jan 08 '13 at 15:32
  • [This answer](http://stackoverflow.com/a/10591668/1290731) (it's mine) might be helpful. – jthill Jan 08 '13 at 18:34
  • I appreciate the comments! I hope someone can elaborate on where the suggestion to do this rebase process post-commit to master fails. Because it clearly fails to do a reasonable thing for me. At first I assumed it is because I had done something wrong setting things up. But maybe that isn't the case. So then I don't get why Lea Verou, Oli and Paul Irish seem to think it's a good idea to use `rebase`. And also, @jthill, your answer might work but it looks so enigmatic to me that I don't dare run it. – Steven Lu Jan 08 '13 at 20:34

0 Answers0