Changes between Version 45 and Version 46 of WorkingWithGit

Timestamp:

Aug 26, 2016, 6:07:16 PM (8 years ago)

Author:

neverpanic (Clemens Lang)

Comment:

move push.default setting to pushing section and remove it from the global setup; we don't want to dictate user's configuration settings

WorkingWithGit

@@ -21 +21 @@
 Additionally one should define a few (very likely not necessarily global) presets for working with your clone of the MacPorts repository:
 {{{
-git config --global push.default nothing
 git config --global branch.autosetuprebase always
 git config --global core.excludesfile ~/.gitignore_global
 git config --global commit.template ~/.git-commit-template
 }}}
-which avoids that you accidentally push changes into a wrong branch at {{{origin}}}, makes sure that your current changes get always auto-rebased ontop of the pulled changes from {{{origin}}} and adds an excludes file as well as a commit template.
+which makes sure that your current changes get always auto-rebased ontop of the pulled changes from {{{origin}}} and adds an excludes file as well as a commit template.
 
 '''T.B.D.:''' A MacPorts'ish ignore file {{{.gitignore_global}}} should be supplied here, perhaps based on [https://quickgit.kde.org/?p=macports-kde.git&a=blob&h=bb618b30d4daba183823b797fa56ae65b207c569&hb=120899f859eefbe0bf669685352e7c44a834e23f&f=contrib%2Fgit-setup%2F.gitignore_global this]?!!
@@ -108 +107 @@
 Because of Git's distributed nature, a commit on your local machine is not immediately available on the central server, like it was the case with Subversion. This means that you can continue to prepare further changes in additional commits before you publish your changes as a set. In fact, it is a very common practice in Git to do many small changes that are logically consistent in themselves and then publish them in one step.
 
-If you have commit access, you can publish your commits using `git push <remote-name> <branch-name>`. `<remote-name>` is the name of the repository to which you want to push. The most common push target is the location you initially cloned, which is automatically named `origin`. `<branch-name>` is the name of the branch you want to push. The Git equivalent to Subversion's `trunk` is called `master`. In most cases you do not need to specify `<remote-name>` or `<branch-name>`:
-{{{
-git push
+If you have commit access, you can publish your commits using `git push <remote-name> <branch-name>`. `<remote-name>` is the name of the repository to which you want to push. The most common push target is the location you initially cloned, which is automatically named `origin`. `<branch-name>` is the name of the branch you want to push. The Git equivalent to Subversion's `trunk` is called `master`. It is considered best practice to always specify your push target and the branch you are pushing, since git's default is pushing all branches that have a remote equivalent when you run `git push`, which might publish changes that you do not consider final yet (you can disable this behavior by changing the `push.default` git config setting to `nothing`, see `man 1 git-config`).
+{{{
+git push origin master
 }}}
 
 Note that the push will fail if the remote repository has new changes. Contrary to Subversion, it does not matter whether your changes conflict with the remote ones. If this happens, you must update your local working copy as described in the [#updating section on fetch the latest changes] and re-try the push.
-
-'''T.B.D.:''' See config setting for {{{push.default}}} [#Initialsetup above], which requires the user to explicitly state the target branch, i.e. it should now be e.g. {{{git push origin master}}}.
-
 
 === Merge a single change from master into a release branch === #cherrypick