Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
github_best_practices [2018/09/01 11:43] – [Recovery From a Failed Stash] Traumflug | github_best_practices [2019/10/05 14:00] (current) – [File Permissions] Clarify link. Traumflug | ||
---|---|---|---|
Line 11: | Line 11: | ||
* [[https:// | * [[https:// | ||
- | * [[https:// | + | * [[https:// |
For refreshing the repository view in Gitk, menu -> //File// -> //Update// (F5) is often incomplete. Menu -> //File// -> //Reload// (Shift-F5) is the much better choice. | For refreshing the repository view in Gitk, menu -> //File// -> //Update// (F5) is often incomplete. Menu -> //File// -> //Reload// (Shift-F5) is the much better choice. | ||
Line 89: | Line 89: | ||
=== Editing the Last Commit === | === Editing the Last Commit === | ||
- | Editing a commit in place is trivial in case it's the last commit. One does code fixes as usual, then commit the same way as when creating a new commit, but add the '' | + | Editing a commit in place is trivial in case it's the last commit. One does code fixes as usual, then commit the same way as when creating a new commit, but add the '' |
<code none> | <code none> | ||
git commit --amend | git commit --amend | ||
Line 122: | Line 122: | ||
* No review possible. Well, one can stare at the commit, of course, but not edit or test it. | * No review possible. Well, one can stare at the commit, of course, but not edit or test it. | ||
- | * Potential to write a nonlinear history. Drawbacks see [[#Merging is Evil]]. | + | * Potential to write a nonlinear history. Drawbacks see [[#Merging is Evil]] |
* Pointless work for those creating the pull request. A simple link to a commit in another repository works just as well. | * Pointless work for those creating the pull request. A simple link to a commit in another repository works just as well. | ||
- | Picking pull requests, or any commit on Github, is pretty trivial: | + | One can easily ignore this button. |
- Find the commit on Github. It's an URL like '' | - Find the commit on Github. It's an URL like '' | ||
Line 133: | Line 133: | ||
curl -L <URL> | git am -3 | curl -L <URL> | git am -3 | ||
</ | </ | ||
- | That's it! After this simple oneliner, one has this commit on top of the local branch, in all it's glory, including author info and commit timestamp. Now one can review this commit, run the local shop installation with it, add remarks in the commit message, push it on a topic branch for a Travis CI run, and so on. Easy, and much more reliable. | + | That's it! After this simple oneliner, one has this commit on top of the local branch, including author info and commit timestamp. Now one can review this commit, run the local shop installation with it, add remarks in the commit message, push it on a topic branch for a Travis CI run, and so on. Easy, and much more reliable. |
+ | |||
+ | ===== Dealing with Github Issues ===== | ||
+ | |||
+ | Here are some hints on good practices when dealing with Github issues. | ||
+ | |||
+ | == Issue reports are of value == | ||
+ | As unfortunate as it is, code has inevitably flaws. Now think of a given set of code, and the same set of code, together with a description of its flaws. The latter is undoubtly of more value. | ||
+ | |||
+ | The only situation even better than code together with a description of its flaws is code with these flaws actually fixed. | ||
+ | |||
+ | == Steps to reproduce == | ||
+ | Good Github issues come with a list of steps to reproduce. Like: | ||
+ | |||
+ | - Have a fresh shop installation. | ||
+ | - Install this. | ||
+ | - Change this setting to that. | ||
+ | - Expected behavior: [...] | ||
+ | - Actual behavior: [...] | ||
+ | - Screenshot, showing the flaw. | ||
+ | |||
+ | First thing when attempting to fix a flaw is to reproduce the issue. If there is no list of steps to reproduce the bug, add it in a comment. This way everybody participating knows what's going on. If the issue appears to be not reproducible, | ||
+ | |||
+ | == Talk == | ||
+ | If an issue can get fixed immediately, | ||
+ | |||
+ | == Issue reporters close issues == | ||
+ | Many projects have the habit to close issue reports quickly. Sometimes by writing some magic words into the commit message. | ||
+ | |||
+ | Closing a Github issue doesn' | ||
+ | |||
+ | == Issues get reported for a reason == | ||
+ | One can often see issues getting closed within minutes with //' | ||
+ | |||
+ | It's a good idea to keep in mind that people usually don't write issue reports because they' | ||
===== This and That ===== | ===== This and That ===== | ||
Line 141: | Line 176: | ||
==== Recovery From a Failed Stash Pop ==== | ==== Recovery From a Failed Stash Pop ==== | ||
- | In some situations a '' | + | In some situations a '' |
Knowing the secret, recovery is simple: | Knowing the secret, recovery is simple: | ||
Line 149: | Line 184: | ||
</ | </ | ||
+ | ==== File Permissions ==== | ||
+ | |||
+ | A typical problem of developer installations is trouble with file permissions. While the Git repository is owned by the developer, the web server runs as another user. Result: developer can't edit files created by the web server and vice versa. | ||
+ | |||
+ | Solution is to use extended file permissions. First, move //.git// aside: | ||
+ | |||
+ | $ mv <git repository>/ | ||
+ | |||
+ | Then follow instructions at [[Developer Installation# | ||
+ | |||
+ | That done, move //.git// back: | ||
+ | |||
+ | $ mv /tmp/.git <git repository>/ | ||
===== References ===== | ===== References ===== |
github_best_practices.1535795009.txt.gz · Last modified: 2018/09/01 11:43 by Traumflug