Michael S. Tsirkin m...@redhat.com writes:
So I think I prefer using an option and not a heuristic if you
are fine with that.
Sure. Changing behaviour only by explicit user request (command line
or configuration) is much safer than heuristics that does not work
reliably.
--
To unsubscribe from
Michael S. Tsirkin m...@redhat.com writes:
On Mon, Mar 31, 2014 at 12:54:46PM -0700, Junio C Hamano wrote:
Michael S. Tsirkin m...@redhat.com writes:
The hash used is mostly an internal implementation detail, isn't it?
Yes, but that does not mean we can break people who keep an external
On Wed, Apr 02, 2014 at 11:18:26AM -0700, Junio C Hamano wrote:
Michael S. Tsirkin m...@redhat.com writes:
On Mon, Mar 31, 2014 at 12:54:46PM -0700, Junio C Hamano wrote:
Michael S. Tsirkin m...@redhat.com writes:
The hash used is mostly an internal implementation detail, isn't it?
Michael S. Tsirkin m...@redhat.com writes:
Clarify that patch ID is now a sum of hashes, not a hash.
Document --stable and --unstable flags.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
changes from v2:
explicitly list the kinds of changes against which patch ID is stable
Michael S. Tsirkin m...@redhat.com writes:
The hash used is mostly an internal implementation detail, isn't it?
Yes, but that does not mean we can break people who keep an external
database indexed with the patch-id by changing the default under
them, and they can give --unstable option to work
On Mon, Mar 31, 2014 at 12:54:46PM -0700, Junio C Hamano wrote:
Michael S. Tsirkin m...@redhat.com writes:
The hash used is mostly an internal implementation detail, isn't it?
Yes, but that does not mean we can break people who keep an external
database indexed with the patch-id by
Clarify that patch ID is now a sum of hashes, not a hash.
Document --stable and --unstable flags.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
changes from v2:
explicitly list the kinds of changes against which patch ID is stable
Documentation/git-patch-id.txt | 23
7 matches
Mail list logo
