Michael S. Tsirkin wrote:
> On Tue, Sep 24, 2013 at 02:31:16PM -0700, Jonathan Nieder wrote:
>> Michael S. Tsirkin wrote:
>>> Just making sure: is it correct that there's no requirement to use same
>>> algorithm between patch-ids.c and builtin/patch-id.c ?
>>
>> I think so,
[...]
>> (They already
On Tue, Sep 24, 2013 at 02:31:16PM -0700, Jonathan Nieder wrote:
> Michael S. Tsirkin wrote:
> >>> On Mon, Sep 23, 2013 at 02:37:29PM -0700, Jonathan Nieder wrote:
>
> Then start over with sorted hunks (for example
> building a table of offsets within the patch
Michael S. Tsirkin wrote:
>>> On Mon, Sep 23, 2013 at 02:37:29PM -0700, Jonathan Nieder wrote:
Then start over with sorted hunks (for example
building a table of offsets within the patch for each hunk to
support this).
[...]
> Well, then the result is n
On Tue, Sep 24, 2013 at 12:36:10PM -0700, Jonathan Nieder wrote:
> Michael S. Tsirkin wrote:
> > On Mon, Sep 23, 2013 at 02:37:29PM -0700, Jonathan Nieder wrote:
>
> >> a) When asked to compute the patch-id of a seekable file, use the
> >> current streaming implementation until you notice a f
Michael S. Tsirkin wrote:
> On Mon, Sep 23, 2013 at 02:37:29PM -0700, Jonathan Nieder wrote:
>> a) When asked to compute the patch-id of a seekable file, use the
>> current streaming implementation until you notice a filename that
>> is out of order. Then start over with sorted hunks (fo
On Mon, Sep 23, 2013 at 02:37:29PM -0700, Jonathan Nieder wrote:
> Hi,
>
> Michael S. Tsirkin wrote:
> >> On Tue, Sep 17, 2013 at 04:56:16PM -0400, Jeff King wrote:
>
> > A problem with both schemes, though, is that they are not
> > backwards-compatible with existing git-patch-id implemen
On Mon, Sep 23, 2013 at 02:37:29PM -0700, Jonathan Nieder wrote:
> >> Add --order-sensitive to get historical unstable behaviour.
>
> The --order-sensitive option seems confusing. How do I use it to
> replicate a historical patch-id? If I record all options that might
> have influenced ordering
Hi,
Michael S. Tsirkin wrote:
>> On Tue, Sep 17, 2013 at 04:56:16PM -0400, Jeff King wrote:
> A problem with both schemes, though, is that they are not
> backwards-compatible with existing git-patch-id implementations.
[...]
>>> It may be esoteric enough not to worry about, though.
Yeah,
On Fri, Sep 20, 2013 at 12:32:26AM +0300, Michael S. Tsirkin wrote:
> On Tue, Sep 17, 2013 at 04:56:16PM -0400, Jeff King wrote:
> > On Tue, Sep 17, 2013 at 11:38:07PM +0300, Michael S. Tsirkin wrote:
> >
> > > > A problem with both schemes, though, is that they are not
> > > > backwards-compatibl
On Tue, Sep 17, 2013 at 10:24:19AM -0700, Junio C Hamano wrote:
> "Michael S. Tsirkin" writes:
>
> > So might it not be useful to tweak patch id to
> > sort the diff, making it a bit more stable?
>
> That is one thing that needs to be done, I think. But it would be
> unfortunate if we have to d
On Tue, Sep 17, 2013 at 04:56:16PM -0400, Jeff King wrote:
> On Tue, Sep 17, 2013 at 11:38:07PM +0300, Michael S. Tsirkin wrote:
>
> > > A problem with both schemes, though, is that they are not
> > > backwards-compatible with existing git-patch-id implementations.
> >
> > Could you clarify?
> >
Jeff King writes:
> I am mostly thinking of the problems we had with the "kup" tool, which
> expected stability across diffs that would be signed by both kernel.org.
> But as far as I know, they do not use patch-id. More details in case you
> are curious (including me arguing that we should not c
On Tue, Sep 17, 2013 at 04:56:16PM -0400, Jeff King wrote:
> On Tue, Sep 17, 2013 at 11:38:07PM +0300, Michael S. Tsirkin wrote:
>
> > > A problem with both schemes, though, is that they are not
> > > backwards-compatible with existing git-patch-id implementations.
> >
> > Could you clarify?
> >
On Tue, Sep 17, 2013 at 11:38:07PM +0300, Michael S. Tsirkin wrote:
> > A problem with both schemes, though, is that they are not
> > backwards-compatible with existing git-patch-id implementations.
>
> Could you clarify?
> We never send patch IDs on the wire - how isn't this compatible?
I meant
On Wed, Sep 18, 2013 at 12:03:25AM +0300, Michael S. Tsirkin wrote:
> > It may be esoteric enough not to worry about, though. By far the most
> > common use of patch-ids is going to be in a single "rev-list
> > --cherry-pick" situation where you are trying to omit commits during
> > a rebase.
> >
On Tue, Sep 17, 2013 at 11:38:07PM +0300, Michael S. Tsirkin wrote:
> On Tue, Sep 17, 2013 at 04:18:28PM -0400, Jeff King wrote:
> > On Tue, Sep 17, 2013 at 11:16:04PM +0300, Michael S. Tsirkin wrote:
> >
> > > > Thinking about it some more, it's a best effort thing anyway,
> > > > correct?
> > >
On Tue, Sep 17, 2013 at 04:18:28PM -0400, Jeff King wrote:
> On Tue, Sep 17, 2013 at 11:16:04PM +0300, Michael S. Tsirkin wrote:
>
> > > Thinking about it some more, it's a best effort thing anyway,
> > > correct?
> > >
> > > So how about, instead of doing a hash over the whole input,
> > > we ha
On Tue, Sep 17, 2013 at 11:16:04PM +0300, Michael S. Tsirkin wrote:
> On Tue, Sep 17, 2013 at 11:14:01PM +0300, Michael S. Tsirkin wrote:
> > On Tue, Sep 17, 2013 at 11:06:07AM -0700, Junio C Hamano wrote:
> > > "Michael S. Tsirkin" writes:
> > >
> > > > On Tue, Sep 17, 2013 at 10:24:19AM -0700,
On Tue, Sep 17, 2013 at 11:06:07AM -0700, Junio C Hamano wrote:
> "Michael S. Tsirkin" writes:
>
> > On Tue, Sep 17, 2013 at 10:24:19AM -0700, Junio C Hamano wrote:
> >> "Michael S. Tsirkin" writes:
> >>
> >> > So might it not be useful to tweak patch id to
> >> > sort the diff, making it a bit
On Tue, Sep 17, 2013 at 11:14:01PM +0300, Michael S. Tsirkin wrote:
> On Tue, Sep 17, 2013 at 11:06:07AM -0700, Junio C Hamano wrote:
> > "Michael S. Tsirkin" writes:
> >
> > > On Tue, Sep 17, 2013 at 10:24:19AM -0700, Junio C Hamano wrote:
> > >> "Michael S. Tsirkin" writes:
> > >>
> > >> > So
On Tue, Sep 17, 2013 at 11:16:04PM +0300, Michael S. Tsirkin wrote:
> > Thinking about it some more, it's a best effort thing anyway,
> > correct?
> >
> > So how about, instead of doing a hash over the whole input,
> > we hash each chunk and XOR them together?
> >
> > This way it will be stable
On Tue, Sep 17, 2013 at 11:06:07AM -0700, Junio C Hamano wrote:
> "Michael S. Tsirkin" writes:
>
> > On Tue, Sep 17, 2013 at 10:24:19AM -0700, Junio C Hamano wrote:
> >> "Michael S. Tsirkin" writes:
> >>
> >> > So might it not be useful to tweak patch id to
> >> > sort the diff, making it a bit
"Michael S. Tsirkin" writes:
> On Tue, Sep 17, 2013 at 10:24:19AM -0700, Junio C Hamano wrote:
>> "Michael S. Tsirkin" writes:
>>
>> > So might it not be useful to tweak patch id to
>> > sort the diff, making it a bit more stable?
>>
>> That is one thing that needs to be done, I think. But it
On Tue, Sep 17, 2013 at 10:24:19AM -0700, Junio C Hamano wrote:
> "Michael S. Tsirkin" writes:
>
> > So might it not be useful to tweak patch id to
> > sort the diff, making it a bit more stable?
>
> That is one thing that needs to be done, I think. But it would be
> unfortunate if we have to d
On Tue, Sep 17, 2013 at 09:26:13AM -0700, Junio C Hamano wrote:
> "Michael S. Tsirkin" writes:
>
> > Actually, after I've looked at the code,
> > diffcore_order is already already called for patch-id.
>
> That was a band-aid for an ill-thought-out orderfile misfeature to
> hide the breakage. Yo
"Michael S. Tsirkin" writes:
> So might it not be useful to tweak patch id to
> sort the diff, making it a bit more stable?
That is one thing that needs to be done, I think. But it would be
unfortunate if we have to do that unconditionally, though, as we may
be "buffering" many hundred kilobyte
"Michael S. Tsirkin" writes:
> Actually, after I've looked at the code,
> diffcore_order is already already called for patch-id.
That was a band-aid for an ill-thought-out orderfile misfeature to
hide the breakage. You somehow make sure that you pass the same
orderfile to diff generating machin
On Sun, Sep 15, 2013 at 10:49:00AM +0300, Michael S. Tsirkin wrote:
> On Wed, Sep 04, 2013 at 12:08:15AM +0300, Michael S. Tsirkin wrote:
> > On Tue, Sep 03, 2013 at 10:12:18AM -0700, Junio C Hamano wrote:
> > > "Michael S. Tsirkin" writes:
> > >
> > > > I always want my diffs to show header file
On Wed, Sep 04, 2013 at 12:08:15AM +0300, Michael S. Tsirkin wrote:
> On Tue, Sep 03, 2013 at 10:12:18AM -0700, Junio C Hamano wrote:
> > "Michael S. Tsirkin" writes:
> >
> > > I always want my diffs to show header files first,
> > > then .c files, then the rest. Make it possible to
> > > set ord
On Tue, Sep 03, 2013 at 10:12:18AM -0700, Junio C Hamano wrote:
> "Michael S. Tsirkin" writes:
>
> > I always want my diffs to show header files first,
> > then .c files, then the rest. Make it possible to
> > set orderfile though a config option to achieve this.
> >
> > Signed-off-by: Michael S.
"Michael S. Tsirkin" writes:
> I always want my diffs to show header files first,
> then .c files, then the rest. Make it possible to
> set orderfile though a config option to achieve this.
>
> Signed-off-by: Michael S. Tsirkin
> ---
I admit that I was the guilty one who introduced the orderfil
I always want my diffs to show header files first,
then .c files, then the rest. Make it possible to
set orderfile though a config option to achieve this.
Signed-off-by: Michael S. Tsirkin
---
diff.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/diff.c b/diff.c
index 208094f..cca0767 10
32 matches
Mail list logo
