From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9678 invoked by alias); 27 Oct 2007 17:48:34 -0000 Received: (qmail 9670 invoked by uid 22791); 27 Oct 2007 17:48:34 -0000 X-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,DK_POLICY_SIGNSOME,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 27 Oct 2007 17:48:31 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.1) with ESMTP id l9RHmT5a012726 for ; Sat, 27 Oct 2007 13:48:29 -0400 Received: from pobox.stuttgart.redhat.com (pobox.stuttgart.redhat.com [172.16.2.10]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l9RHmSdX010672 for ; Sat, 27 Oct 2007 13:48:29 -0400 Received: from [IPv6:::1] (sebastian-int.corp.redhat.com [172.16.52.221]) by pobox.stuttgart.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id l9RHmQi8009660 for ; Sat, 27 Oct 2007 19:48:27 +0200 Message-ID: <472379E9.4050806@redhat.com> Date: Sat, 27 Oct 2007 17:48:00 -0000 From: Tim Moore User-Agent: Thunderbird 1.5.0.12 (X11/20070719) MIME-Version: 1.0 To: frysk Subject: git pull vs git rebase X-Enigmail-Version: 0.94.3.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2007-q4/txt/msg00086.txt.bz2 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm glad to see everyone git-ing away. The tip of the master branch is looking a bit convoluted with merges, so I thought I might remind you of the difference between "git pull" and "git rebase". Your tree has to be up-to-date with respect to the remote master branch before you push, so it's natural to "git pull" after you've made local commits in preparation for a push. Unfortunately this often results in a merge conflict, especially with the ChangeLog files. So you resolve that, but then your pushed commits include the merge commits, which confuses the history. Instead, you can rebase your local commits to the tip of the master tree before doing the push. "git fetch origin" updates your local copy of the remote branches on sourceware; then "git rebase origin" will "replay" your local, new commits on top of the current remote branch. If there are merge conflicts in this process you resolve them and continue the "playback," but the resolution doesn't appear as a merge commit in the history. Now, when you push your new work, it's all clean; no merges in sight. So, read the man page on "git-rebase" and give it a try. Tim - -- Red Hat France SARL, 171 Avenue Georges Clemenceau 92024 Nanterre Cedex, France. Siret n° 421 199 464 00056 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHI3npeDhWHdXrDRURArAkAJ0U8/1PlKuwGbFCUTtPloAhzhjBAQCeL0Q9 2+47vugUbDmr7a7d2V6EHOc= =vCsu -----END PGP SIGNATURE-----