avoid force push when deploy to git repository

[wizicer]

Here is the disadvantage of force push

• Losing history. (less important as we don't care in this deploy branch)
• Increasing pushing time which always pushing all assets.

So suggest avoid force push when deploy to git repository.

[Xuanwo]

from i known, only the first time will push force

Icer [email protected]于2016年5月21日 周六 17:23写道：

Here is the disadvantage of force push

• Losing history. (less important as we don't care in this deploy branch)
• Increasing pushing time which always pushing all assets.

So suggest avoid force push when deploy to git repository.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/hexojs/hexo-deployer-git/issues/33

[wizicer]

There are two clues for me to deem it will always force push:

• refer to readme which wrote force push
• from my usage, every time it force push to github branch.

[Xuanwo]

Well, I got your idea. And we can't simply remove the --force because this will increase the error occurrence rate, maybe we can add a condition judge before that.

[wizicer]

thanks for taking this into consideration.

[ottobonn]

Can I ask what the rationale is for force-pushing? Is it just to avoid merge conflicts? If so, it might be worthwhile to pull the remote site, then attempt to commit the new version on top of it, then check for merge conflicts. If there are conflicts, we could revert to forcing the changes, but if there aren't any (which I would suspect is usually the case for a small site), we could save all the bandwidth of uploading every image again (which becomes untenable for sites with many images).

I'm happy to work on this once I feel like I understand the caveats you've encountered that lead to the decision to use force pushes all the time.

[madnight]

Maybe the best history is no history. https://github.com/hexojs/hexo-deployer-git/compare/master...madnight:master This approach always publish exactly one commit, so there will be no commit history for the deploy branch. At least this fixes my problems.

[twang2218]

It's even worse if you are using CI for build and deploy, there will be no history at all. 😭

[NoahDragon]

@ottobonn Agree. I will add a flag for this plugin, which will omit the force push. However, the user will need to have the knowledge of using git to handle the merge conflicts, or simply turn on the force push.

Update: I underestimated this issue. If there is a post deleted, we need to identify the deleted file and remove it from .git_deploy folder. It may take time to come a proper solution.

Update: I may overthink about it. Let me try to implement first.

Update: As the git deployer supports multiple repo/branches, it's hard to decide which repo to compare with. Finally, I understand the reason why nobody implements this. I give up.

[NoahDragon]

Anyone have tried this #47 ?

[madnight]

Auto git merge conflict resolving sounds like a hack

[NoahDragon]

@madnight True. If it is easy, I think git would already implement it.

[wizicer]

Let me suggest:

1. if branch not exist, create with no history: git checkout --orphan <branch name>
2. if branch exist, check out latest, remove all files/folders, put all expected files in, and commit all: git add -A && git commit -am "<something>"

[NoahDragon]

@wizicer As the git deployer supports multiple repos, which repos should use to check out?

Let's say we have two repos, but they are on different commits. We have to check which commit is more forward. Even worse, if both repos contain the commits that not included in another, which one to use is really debatable.

[madnight]

How did they https://github.com/shinnn/gulp-gh-pages solved that problem?

[twang2218]

'gulp-gh-pages' seems only support a single repo.

[twang2218]

@NoahDragon , I don't think multiple repo would be a problem. We can check them out in separate directory. I improved the @wizicer 's procedure to support the multi-repo:

• If .deploy_git not exist, then create .deploy_git
• For each repo:
  • Create a directory under .deploy_git for the repo, if it's not exists. The name can be the key of the repo, or default. Such as, .deploy_git/github and .deploy_git/gitlab.
  • Check whether the directory is a Git directory with right repo, If it's correct, then git fetch --all, otherwise, clean the directory and git clone the repo.
  • Check the whether the specified repo exist. If exists, then checkout the branch, otherwise create an orphan branch.
  • Remove all the files in the directory (of course, except .git directory), and copy all generated static file in this folder, and run git add -A && git commit -am <message> to add everything and commit it.
  • Finally, git push the repo. At this point, I think the --force or not will not affect the branch history, and we have latest remote branch already, so without --force, it should works without any problem.

[NoahDragon]

@twang2218 You are right, it is doable, but need to devote a block of time to rewrite most parts of this plugin. For now, the only advantage of doing so is to reduce the upload time.

[wololock]

There is even simpler solution to this problem. Pushing all assets takes place if you run hexo deploy from a fresh copy that does not contain .deploy_git folder. It's a common scenario when you build your blog using continuous integration server. In this case running hexo deploy creates a .deploy_git folder and initializes a fresh repository inside it, so when you push it back to your repository, the branch you have pushed to gets recreated from scratch and you can see only 2 commits - First commit and Site updated: {{curent date}}.

I have found a simple solution to this problem. Whenever I run hexo deploy in continuous integration environment (Travis CI in my case) I do clone master branch (the branch that stores generated HTML in my case) to .deploy_git to keep the previous history.

[stevenjoezhang]

I will close this issue. I've noticed that the issue with git commit history primarily occurs in CI environments. The CI machines that execute the Hexo compile commands generally do not have a local .deploy_git folder, so hexo-deployer-git is unable to correctly preserve the original commit history. Nowadays, GitHub has started supporting website deployment directly through GitHub Actions (rather than through code repositories with gh-pages branch), which will greatly simplify the workflow while also preventing users from encountering similar issues.