Theodore Ts'o writes:
> On Tue, Mar 12, 2013 at 02:30:04PM -0700, Junio C Hamano wrote:
>> Theodore Ts'o 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
>> >mergeo
On Tue, Mar 12, 2013 at 02:30:04PM -0700, Junio C Hamano wrote:
> Theodore Ts'o 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
Linus Torvalds 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 auto-follow, but mergeta
On Tue, Mar 12, 2013 at 2:47 PM, Junio C Hamano 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 decides to
Linus Torvalds 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 in new code, disall
Theodore Ts'o 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 an
On Tue, Mar 12, 2013 at 2:20 PM, Theodore Ts'o 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
> mergeoption
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..mergeoptions, but
Junio C Hamano 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.
>
Linus Torvalds 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 special command to do back
On Tue, Mar 12, 2013 at 6:13 PM, Linus Torvalds
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
>> experience a fast forward whe
[ 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 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 security tre
12 matches
Mail list logo
