I have made the same change to several files in a Git repository. I created a commit for each file and submitted it to Github. In this case, one commit would have been sufficient. Now how can I merge the relevant commits into one commit afterwards?
First, run git rebase -i HEAD~X in the local working directory. Instead of X, enter the number of the latest commits you want to merge.
Now an editor should open automatically and in the first lines you should find, for example, the following.
pick 67426ab Commit-Message pick 56432tz Commit-Message pick 45643io Commit-Message
To make one commit out of these three, replace the pick in lines 2 and 3 with squash. The “pick” in the first line remains unchanged. Finally, save the file.
Now an editor should be reopened in which you can adjust the commit message if necessary. Because I used the same message for all three commits, I did not make any changes.
Finally, run git push –force origin HEAD to send the changes to Github. If you used a different alias for the repository (origin is the default) you have to change the command accordingly. If you are not sure, you can check the config file in the .git directory in your local working directory.
If you are not the only person making changes to the files, it is better to use –force-with-lease instead of –force.
If you now look at the history of the repository, the relevant commits have been combined into one commit.
It often happens that someone switches from one version control system to Git. Sometimes, however, someone wants to switch from Git to another solution. Recently I had such a request. Mercurial was wanted.
The relevant git repository was still quite fresh, but there were already commits in the low three-digit range. Too many to create manually in Mercurial.
Which is not necessary. Mercurial offers the possibility to convert.
Let’s assume that the home directory contains the directory repository. In this directory there is the directory blog.git where the Git repository is located.
First you have to create the subdirectory blog.hg in the repository directory and switch to it. There you create a Mercurial repository with “hg init”. This creates the directory .hg. In this directory you create the file hgrc with the following content.
This enables the extension with which the conversion can be performed.
Now execute the following command in the directory blog.hg.
hg convert --datesort ~/repository/blog.git ~/repository/blog.hg
It’ll take a while. But if everything goes as planned, you should get a Mercurial repository with all commits, files, etc. as in the Git repository. If you look at the directory blog.hg, you will still only see the subdirectory .hg. The problem can be solved by executing the command “hg update”. If you then look in the directory blog.hg you can also see all the files you originally added to the Git repository.
So far I have used the CMS Bolt for fryboyter.de. Basically I am satisfied with it. But somehow I have lately less and less desire to install the updates.
Therefore I looked at various tools in the last weeks, with which one can create static web pages. So you don’t need PHP, no database, etc. Thus also the annoying updating of the side is unnecessary.
Finally I ended up with Hugo . There are basically two reasons for this. On the one hand Hugo consists of only one file and on the other hand the static pages are created very fast.
But what kept me busy was how to create the website when I added new articles and how to upload it to the webspace.
In the Lab of Uberspace there is a manual how to install Hugo. Hugo runs as a service in the background and recreates the page as soon as something has changed. But as a consequence I have to take care of possible updates as soon as possible. It would be better if Hugo is started only to create the page and then shut down again. The easiest way would be to connect to the webspace via SSH, create the new article and then run Hugo manually. Simple? Yes. Cumbersome? Definitely. So it’s out of the question.
The solution is, as so often, Git. First you create a directory on the webspace outside the document root. In this directory you create a so called bare-respository with " git init –bare". In comparison to a normal repository, this has no working tree. If you now look at the directory again, you will find the subdirectory “hooks” there. With these hooks certain tasks can be automated. For example, commands can be executed when the repository has received new data. For this you create the file post-receive in the directory “hooks” and add the following data and make it executable.
GIT_REPO=$HOME/repository/fryboyter.git TMP_GIT_CLONE=$HOME/tmp/git/fryboyter PUBLIC_WWW=/var/www/virtual/$USER/html/fryboyter git clone $GIT_REPO $TMP_GIT_CLONE ~/bin/hugo -s $TMP_GIT_CLONE --cleanDestinationDir -d $PUBLIC_WWW rm -Rf $TMP_GIT_CLONE exit
This clones the contents of the repository into a temporary directory. Then Hugo deletes the already published website and recreates it. Then the temporary directory is deleted.
What is still missing is the data with which the website is created. These are created on your own computer. When this is done, you change to the respective directory and execute the following commands.
git init git add . git commit -m "Beschreibung des Commit"
With this you create a local repository, add all files of the directory and create a commit. If you upload it with “git push $adresse_des_repository” the file post-receive will be executed and the website will be created automatically. To update the page in the future, create / change the file in the local repository, create a new commit and upload the changes using git push.