Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes:
> Ok, so I have a practice of occasionally doing octopus merges when I have
> two branches with trivial fixes from the same person.
>
> That all works fine when they use the "multiple branches in the same
> repository" approach (eg x86 "tip" tree), but other people tend to prefer
> to use multiple repositories for different features, rather than branches.
> And git generally lets you do things either way with no real difference.
>
> But for the octopus case, it does make a difference. You can easily make
> octopus merges only from one repository.
>
> Which is kind of sad.
>
> So I did kernel commit c6223048259006759237d826219f0fa4f312fb47 by
> basically doing the 'git pull" logic by hand, and while this was just a
> trial and maybe I'll never feel the urge to do it again, I'm wondering it
> maybe we should make it easier to do.
Every once in a while I have this urge to see how it feels to be Linus
by pretending to be him, trying what he did.
(1) So where is he?
$ git pull
...
From git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
f234012..28d0325 master -> linus
* [new tag] v2.6.31-rc1 -> v2.6.31-rc1
Updating f234012..28d0325
Fast forward
...
(2) Let's pretend to be Linus, just before he made this merge.
$ git checkout c62230^
(3) Let's see what he did with that thing.
$ git show c62230
commit c6223048259006759237d826219f0fa4f312fb47
Merge: bd453cd d5bb68a 3a6a6c1
Author: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Date: Wed Jun 24 14:17:14 2009 -0700
Merge branches 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/{vfs-2.6,audit-current}
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6:
another race fix in jfs_check_acl()
Get "no acls for this inode" right, fix shmem breakage
inline functions left without protection of ifdef (acl)
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/audit-current:
audit: inode watches depend on CONFIG_AUDIT not CONFIG_AUDIT_SYSCALL
Ah, so we know the two repositories and branches involved.
(4) Let's pretend to be Linus. Fetch the first branch and drop the
necessary information in FETCH_HEAD.
$ git fetch \
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6 \
for-linus
(5) Continue pretending to be Linus, complete the octopus. The key is to
let the "fetch" phase of this to append to the FETCH_HEAD, not
replacing it.
$ git pull --append \
git://git.kernel.org/pub/scm/linux/kernel/git/viro/audit-current \
for-linus
(6) Did I succeed? Let's see.
$ git diff c62230
Yay, identical tree.
(7) How does the log message look?
$ git show
commit cb1e4198421091ea5844d93624d5d5499537dbe0
Merge: bd453cd d5bb68a 3a6a6c1
Author: Junio C Hamano <gitster@xxxxxxxxx>
Date: Wed Jun 24 17:45:09 2009 -0700
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6; branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/audit-current into HEAD
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6:
another race fix in jfs_check_acl()
Get "no acls for this inode" right, fix shmem breakage
inline functions left without protection of ifdef (acl)
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/audit-current:
audit: inode watches depend on CONFIG_AUDIT not CONFIG_AUDIT_SYSCALL
Hmm, Linus's combined notation on the summary line that uses {} is
much nicer.
> Right now the "git pull" syntax is
>
> git pull <repo> <branch>*
>
> and you cannot specify multiple repositories, only multiple branches.
>
> But at the same time, it should be pretty unambiguous whether an argument
> is a repository or a branch (':' in a remote repository, or "/" or ".." at
> the beginning of a local one - all invalid in branch names).
>
> So it _should_ be syntactically unambiguous to allow
>
> git pull (<repo> <branch>*)+
>
> for the octopus case. Hmm?
Strictly speaking, you are not quite correct. Arguments after <repo> can
be storing refspecs and they do come with colon.
Conclusion. git-fmt-merge-msg may need to learn the trick of using {}.
No other changes needed.
Side note.
People sometimes say, and I am certain I agreed to them on more than one
occasions, that Octopus hurt bisectability and does not have much value in
real life. I've always thought this bisectability issue was a downside of
Octopus merges, but now I think about it, perhaps "git bisect" can be
taught to dynamically decompose an Octopus merges into a sequence of
two-head virtual merges while bisecting. We strongly discourage and do
not allow conflicting Octopus merges, so when you need to bisect a history
with an Octopus that looks like this:
---o---A
\
---o---B---M---o
/
---o---C
it should be able to mechanically decompose it, without conflicts, into
---o---A
\
---o---B---M1--M2--o
/
---o---C
where the tree of M and the tree of M2 are identical.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html