GNU/Linux Desktop Survival Guide by Graham Williams
Desktop Survival Project Home Preface Advocacy History Distributions Installing GNU/Linux Basic Survival Wajig Applications AI, Machine Learning, Data Science Android - GNU/Linux Devices Audio Backup Booting CD Chinese ChRoot Clock Command Line Databases DIA Directories Disks EcoSysL Emacs Email Evolution Files File Systems Firewalls Floppy Disks FreedomBox Glade GNOME Graphics, Images, Photos Hardware Initialisations on Booting Installation Examples Internet IOT Java KDE Kernels Keyboard Konqueror KVM Switch LATEX Log System Login Magellan MATE Mathematics Memory Modems Mounting Devices MS/Windows Music MySQL Nautilus Networks Nextcloud Network File System NFS NT File System Oracle Packages Partitions Passwords PDF Power Management PPP Presentations Printing Python R Remote Desktops Rsync Samba Scanning Science Screens Security Spreadsheet SSH Swap Teradata Data Warehouse Themes TV Unity USB Version Control Video Virtualization Voice over IP WebCam WordPress Web Sites Word Processing and Printing X XML Troubleshooting Index

CLICK HERE TO VISIT THE UPDATED SURVIVAL GUIDE

Git Pull

20201117 The default pull behaviour is to perform a merge which can also then create a merge commit, and thus can result in changes being made to the commit history. Whilst this is the original default behaviour of git it is often argued not to be the optional approach.

A pull performs a fetch, to update the local repository with changes to the origin (remote) main repository, and then a merge to reconcile divergent branches.

$ git pull           => git fetch; git merge

A rebase is often prefered whan your local changes are not so significant as to require a separate branch off of whatever branch is currently active (e.g. main or dev). A rebase can be used to reconcile a divergent branch, rather than using a merge, to commit over the remote branch and so as to maintain a single branch both locally and remotely. This avoids the sometime confusion of createing minor branches of branches, and works nicely in team development.

$ git pull --rebase => git fetch; git rebase

There are diverse opinions as to whether to do a merge or a rebase. A rebase is more like the update of earlier version control systems (like Subversion and CVS). It reduces the number of minor branches being merged and so leaves merging as an operation on major branches of activity.

To set the default behaviour (globally) to be a rebase use the config command:

$ git config --global pull.rebase true

The default is:

$ git config --global pull.rebase false

Some recommend the dafault to simply be an attempt at a fast forward over the upstream commits and to fail if that is not possible.

$ git config --global pull.ff only

Further explanations are available from:

• https://salferrarello.com/git-warning-pulling-without-specifying-how-to-reconcile-divergent-branches-is-discouraged/
• https://stackoverflow.com/questions/2472254/when-should-i-use-git-pull-rebase
• https://stackoverflow.com/questions/62653114/how-to-deal-with-this-git-warning-pulling-without-specifying-how-to-reconcile