[ Added Junio and git to the recipients, and leaving a lot of stuff
quoted due to that... ]
On Mon, Mar 11, 2013 at 9:16 PM, Theodore Ts'o ty...@mit.edu wrote:
On Tue, Mar 12, 2013 at 03:10:53PM +1100, James Morris wrote:
On Tue, 12 Mar 2013, Stephen Rothwell wrote:
The top commit in the
On Tue, Mar 12, 2013 at 6:13 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
Why not just force the head of the security tree to be v3.9-rc2? Then
you don't end up creating a completely unnecessary merge commit, and
users who were at the previous head of the security tree will
Linus Torvalds torva...@linux-foundation.org writes:
One is simple:
git config alias.sync=pull --ff-only
Heh, I just wrote that myself after reading the early part of this
message ;-)
which works fine, but forces submaintainers to be careful when doing
things like this, and using a
Junio C Hamano gits...@pobox.com writes:
Then under the --no-ff activates the magic rule:
git merge v3.9-rc2
will fast-forward, but this
git merge --no-ff v3.9-rc2
creates a real merge with the mergetag signature block. The one
that caused trouble in the security tree, i.e.
What if we added the ability to do something like this:
[remote origin]
url =
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
fetch = +refs/heads/master:refs/heads/master
mergeoptions = --ff-only
This would be an analog to branch.name.mergeoptions,
On Tue, Mar 12, 2013 at 2:20 PM, Theodore Ts'o ty...@mit.edu wrote:
What if we added the ability to do something like this:
[remote origin]
url =
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
fetch = +refs/heads/master:refs/heads/master
Theodore Ts'o ty...@mit.edu writes:
What if we added the ability to do something like this:
[remote origin]
url =
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
fetch = +refs/heads/master:refs/heads/master
mergeoptions = --ff-only
This would be an
Linus Torvalds torva...@linux-foundation.org writes:
- I do think that we might want a --no-signatures for the specific
case of merging signed tags without actually taking the signature
(because it's a upstream repo). The --ff-only thing is *too*
strict. Sometimes you really do want to merge
On Tue, Mar 12, 2013 at 2:47 PM, Junio C Hamano gits...@pobox.com wrote:
I agree that --ff-only thing is too strict and sometimes you would
want to allow back-merges, but when you do allow such a back-merge,
is there a reason you want it to be --no-signatures merge? When a
subtree maintainer
Linus Torvalds torva...@linux-foundation.org writes:
That said, adding the signature from an upstream tag doesn't really
seem to be hugely useful. I'm not seeing much of an upside, in other
words. I'd *expect* that people would pick up upstream tags
regardless, no?
Yes, their git fetch will
On Tue, Mar 12, 2013 at 02:30:04PM -0700, Junio C Hamano wrote:
Theodore Ts'o ty...@mit.edu writes:
[remote origin]
url =
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
fetch = +refs/heads/master:refs/heads/master
mergeoptions = --ff-only
Is
Theodore Ts'o ty...@mit.edu writes:
On Tue, Mar 12, 2013 at 02:30:04PM -0700, Junio C Hamano wrote:
Theodore Ts'o ty...@mit.edu writes:
[remote origin]
url =
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
fetch = +refs/heads/master:refs/heads/master
12 matches
Mail list logo
