X-Git-Url: https://git.phdru.name/?a=blobdiff_plain;f=pep-103.txt;h=d11403345a0d6bd24fc863992becc4ac7b907f23;hb=7ba22e6bc0b8a7e77d5c3e26995e458fb2784976;hp=4b5154ae599793fd42e1b81b6c7f15f3caad6e10;hpb=6c4d7fe849430f1f90f91273a740669e5066e459;p=git-wiki.git diff --git a/pep-103.txt b/pep-103.txt index 4b5154a..d114033 100644 --- a/pep-103.txt +++ b/pep-103.txt @@ -62,6 +62,8 @@ many different languages. Download Russian translation from `GArik `Git Wiki `_. +`Git Buch `_ (German). + Offline documentation --------------------- @@ -191,10 +193,28 @@ remote-tracking branches, creates a local branch ``v1``, configure it to track upstream remotes/origin/v1 branch and checks out ``v1`` into the working directory. +Some commands, like ``git status --branch`` and ``git branch --verbose``, +report the difference between local and remote branches. +Please remember they only do comparison with remote-tracking branches +in your local repository, and the state of those remote-tracking +branches can be outdated. To update remote-tracking branches you +either fetch and merge (or rebase) commits from the remote repository +or update remote-tracking branches without updating local branches. + Updating local and remote-tracking branches ------------------------------------------- +To update remote-tracking branches without updating local branches run +``git remote update [$REMOTE...]``. For example:: + + $ git remote update + $ git remote update origin + + +Fetch and pull +'''''''''''''' + There is a major difference between :: @@ -572,10 +592,10 @@ that it is very much recommended not to rebase published commits the question's diminished even further: "whether to use rebase on non-pushed commits?" -That small question is for the team to decide. The author of the PEP -recommends to use rebase when pulling, i.e. always do ``git pull ---rebase`` or even configure automatic setup of rebase for every new -branch:: +That small question is for the team to decide. To preserve the beauty +of linear history it's recommended to use rebase when pulling, i.e. do +``git pull --rebase`` or even configure automatic setup of rebase for +every new branch:: $ git config branch.autosetuprebase always @@ -618,6 +638,18 @@ The topic branch is deleted to avoid cluttering branch namespace with small topic branches. Information on what issue was fixed or what feature was implemented should be in the commit messages. +But even that small amount of rebasing could be too big in case of +long-lived merged branches. Imagine you're doing work in both ``v1`` +and ``master`` branches, regularly merging ``v1`` into ``master``. +After some time you will have a lot of merge and non-merge commits in +``master``. Then you want to push your finished work to a shared +repository and find someone has pushed a few commits to ``v1``. Now +you have a choice of two equally bad alternatives: either you fetch +and rebase ``v1`` and then have to recreate all you work in ``master`` +(reset ``master`` to the origin, merge ``v1`` and cherry-pick all +non-merge commits from the old master); or merge the new ``v1`` and +loose the beauty of linear history. + Null-merges =========== @@ -743,7 +775,7 @@ working tree:: $ git config rerere.autoupdate true You don't need to turn rerere on globally - you don't want rerere in -bare repositories or single-branche repositories; you only need rerere +bare repositories or single-branch repositories; you only need rerere in repos where you often perform merges and resolve merge conflicts. See `Rerere `_ in The @@ -876,7 +908,11 @@ Web interface to browse repositories can be created using `gitweb `_ or `cgit `_. Both are CGI scripts (written in Perl and C). In addition to web interface both provide read-only dumb -http access for git (http(s):// URLs). +http access for git (http(s):// URLs). `Klaus +`_ is a small and simple WSGI web +server that implements both web interface and git smart HTTP +transport; supports Python 2 and Python 3, performs syntax +highlighting. There are also more advanced web-based development environments that include ability to manage users, groups and projects; private, @@ -885,9 +921,11 @@ trackers, wiki pages, pull requests and other tools for development and communication. Among these environments are `Kallithea `_ and `pagure `_, both are written in Python; pagure was written by Fedora developers -and is being used to develop some Fedora projects. `Gogs -`_ is written in Go; there is a fork `Gitea -`_. +and is being used to develop some Fedora projects. `GitPrep +`_ is yet another Github clone, +written in Perl. `Gogs `_ is written in Go. +`GitBucket `_ is written +in Scala. And last but not least, `Gitlab `_. It's perhaps the most advanced web-based development environment for git.