"git pull -r" to avoid merge commits

"git pull -r" to avoid merge commits

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 818 bytes --]

In the ELPA repo, i see "Merge branch 'master' of git+ssh://...",
which are merge commits IIUC.  I suspect this event confused the
admin scripts and so prevented the (recently released) xpm 1.0.2
From auto-generating a post to info-gnu-emacs.  Is that correct?

On the contributor side, i regularly use "git pull -r" because i
believe doing so avoids creating merge commits.  (This is based
on git-push(1) section "NOTE ABOUT FAST-FORWARDS", primarily.)
Am i missing something?  Is there a better way to avoid merge
commits?  Is there a better way to ensure announcement trigger?

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: "git pull -r" to avoid merge commits

[Eli Zaretskii]

> From: Thien-Thi Nguyen <ttn@gnu.org>
> Date: Sat, 31 May 2014 15:22:26 +0200
> 
> In the ELPA repo, i see "Merge branch 'master' of git+ssh://...",
> which are merge commits IIUC.  I suspect this event confused the
> admin scripts and so prevented the (recently released) xpm 1.0.2
> From auto-generating a post to info-gnu-emacs.  Is that correct?
> 
> On the contributor side, i regularly use "git pull -r" because i
> believe doing so avoids creating merge commits.  (This is based
> on git-push(1) section "NOTE ABOUT FAST-FORWARDS", primarily.)
> Am i missing something?  Is there a better way to avoid merge
> commits?

Why would you need to avoid merge commits?  If they confuse the admin
scripts, then perhaps fixing those scripts is a better way.

Re: "git pull -r" to avoid merge commits

[David Kastrup]

Thien-Thi Nguyen <ttn@gnu.org> writes:

> In the ELPA repo, i see "Merge branch 'master' of git+ssh://...",
> which are merge commits IIUC.  I suspect this event confused the
> admin scripts and so prevented the (recently released) xpm 1.0.2
> From auto-generating a post to info-gnu-emacs.  Is that correct?
>
> On the contributor side, i regularly use "git pull -r" because i
> believe doing so avoids creating merge commits.  (This is based
> on git-push(1) section "NOTE ABOUT FAST-FORWARDS", primarily.)
> Am i missing something?  Is there a better way to avoid merge
> commits?  Is there a better way to ensure announcement trigger?

man git-config contains all of those:

       branch.autosetuprebase

           When a new branch is created with git branch or git checkout
           that tracks another branch, this variable tells Git to set up
           pull to rebase instead of merge (see
           "branch.<name>.rebase"). When never, rebase is never
           automatically set to true.  When local, rebase is set to true
           for tracked branches of other local branches.  When remote,
           rebase is set to true for tracked branches of remote-tracking
           branches. When always, rebase will be set to true for all
           tracking branches. See "branch.autosetupmerge" for details on
           how to set up a branch to track another branch. This option
           defaults to never.

       branch.<name>.rebase

           When true, rebase the branch <name> on top of the fetched
           branch, instead of merging the default branch from the
           default remote when "git pull" is run. See "pull.rebase" for
           doing this in a non branch-specific manner.

               When preserve, also pass `--preserve-merges` along to
               'git rebase' so that locally committed merge commits will
               not be flattened by running 'git pull'.


       pull.rebase

           When true, rebase branches on top of the fetched branch,
           instead of merging the default branch from the default remote
           when "git pull" is run. See "branch.<name>.rebase" for
           setting this on a per-branch basis.

               When preserve, also pass `--preserve-merges` along to
               'git rebase' so that locally committed merge commits will
               not be flattened by running 'git pull'.

-- 
David Kastrup

Re: "git pull -r" to avoid merge commits

[Stefan Monnier]

> which are merge commits IIUC.  I suspect this event confused the
> admin scripts and so prevented the (recently released) xpm 1.0.2
> From auto-generating a post to info-gnu-emacs.  Is that correct?

No, the message-posting machinery doesn't look at the VCS data at all.


        Stefan

Re: "git pull -r" to avoid merge commits

[Eric Hanchrow]

> Why would you need to avoid merge commits?  If they confuse the admin
> scripts, then perhaps fixing those scripts is a better way.

Merge commits confuse humans.  If someone's contribution is just one
or two commits, then the history is much easier to understand if they
rebase instead of merging.

Merges make sense, though, when the new work is a long series of commits.

Re: "git pull -r" to avoid merge commits

[David Kastrup]

Eric Hanchrow <eric.hanchrow@gmail.com> writes:

>> Why would you need to avoid merge commits?  If they confuse the admin
>> scripts, then perhaps fixing those scripts is a better way.
>
> Merge commits confuse humans.  If someone's contribution is just one
> or two commits, then the history is much easier to understand if they
> rebase instead of merging.
>
> Merges make sense, though, when the new work is a long series of commits.

The length of the series is marginal.  What makes a difference is
parallel ongoing work in both branches touching the same files.  In that
case, disentangling the intertwined histories may be more expensive than
it is worth.

-- 
David Kastrup

Re: "git pull -r" to avoid merge commits

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 542 bytes --]

() Eric Hanchrow <eric.hanchrow@gmail.com>
() Sat, 31 May 2014 21:14:57 -0700

   Merge commits confuse humans.

Right (me foremost!).  I see the announcement finally appeared, so
it was confusion from impatience in this case.  Sorry for the noise.

(Thanks dak for the other "git rebase" doc fragments.)

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]