On Tue, Apr 19, 2016 at 04:07:35PM -0700, Junio C Hamano wrote: > Jacob Keller <jacob.kel...@gmail.com> writes: > > > On Tue, Apr 19, 2016 at 10:06 AM, Jeff King <p...@peff.net> wrote: > >> On Tue, Apr 19, 2016 at 08:17:38AM -0700, Stefan Beller wrote: > >> > >>> On Mon, Apr 18, 2016 at 10:03 PM, Jeff King <p...@peff.net> wrote: > >>> > >>> > I guess this will invalidate old patch-ids, but there's not much to be > >>> > done about that. > >>> > >>> What do you mean by that? (What consequences do you imagine?) > >>> I think diffs with any kind of heuristic can still be applied, no? > >> > >> I mean that if you save any old patch-ids from "git patch-id", they > >> won't match up when compared with new versions of git. We can probably > >> ignore it, though. This isn't the first time that patch-ids might have > >> changed, and I think the advice is already that one should not count on > >> them to be stable in the long term. > >> > >> -Peff > > > > Plus they'll be stable within a version of Git, it's only recorded > > patch ids that change, which hopefully isn't done very much if at all. > > > > Thanks, > > Jake > > Some people, like those who did things like 30e12b92 (patch-id: make > it stable against hunk reordering, 2014-04-27), _may_ care. >
FWIW IIRC what that commit is about is ability to reorder the chunks in a patch without changing patch-id. Not about keeping id stable across git revisions. -- MST -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
