On Mon, Jul 31, 2017 at 01:26:40PM -0700, Stefan Beller wrote:
> On Sun, Jul 30, 2017 at 4:24 PM, brian m. carlson
> wrote:
> > I realize this was worded poorly. So for my example, in this case, we'd
> > do:
> >
> > test-helper-hash-string "263 410"
> >
> > For SHA-1, we'd get "263 410". For SHA
On Mon, Jul 31, 2017 at 1:17 PM, Ævar Arnfjörð Bjarmason
wrote:
> On Mon, Jul 31, 2017 at 1:24 AM, brian m. carlson
> wrote:
>> On Sun, Jul 30, 2017 at 11:00:19PM +, brian m. carlson wrote:
>>> Yes, basically, but a bit more generally. There will always be cases in
>>> which we need to speci
On Sun, Jul 30, 2017 at 4:24 PM, brian m. carlson
wrote:
> On Sun, Jul 30, 2017 at 11:00:19PM +, brian m. carlson wrote:
>> Yes, basically, but a bit more generally. There will always be cases in
>> which we need to specify an object ID or an arbitrary string and the
>> behavior will need to
On Mon, Jul 31, 2017 at 1:24 AM, brian m. carlson
wrote:
> On Sun, Jul 30, 2017 at 11:00:19PM +, brian m. carlson wrote:
>> Yes, basically, but a bit more generally. There will always be cases in
>> which we need to specify an object ID or an arbitrary string and the
>> behavior will need to
On Sun, Jul 30, 2017 at 11:00:19PM +, brian m. carlson wrote:
> Yes, basically, but a bit more generally. There will always be cases in
> which we need to specify an object ID or an arbitrary string and the
> behavior will need to vary based on the hash. That can be something
> like, in this
On Sun, Jul 30, 2017 at 02:21:50PM -0700, Junio C Hamano wrote:
> "brian m. carlson" writes:
>
> > One approach I had considered taking is having a helper of some sort
> > that wrapped a simple key/value store. We could pass the wrapper the
> > SHA-1 value (or, if necessary, an arbitrary key) an
"brian m. carlson" writes:
> One approach I had considered taking is having a helper of some sort
> that wrapped a simple key/value store. We could pass the wrapper the
> SHA-1 value (or, if necessary, an arbitrary key) and have it return the
> proper value based on the given hash function.
>
>
On Fri, Jul 28, 2017 at 03:14:49PM -0700, Junio C Hamano wrote:
> Stefan Beller writes:
>
> > The first test marked relies on hard coded sha1:
> >
> > # We need to create two object whose sha1s start with 17
> > # since this is what git gc counts. As it happens, these
> > # two blobs
Stefan Beller writes:
> The first test marked relies on hard coded sha1:
>
> # We need to create two object whose sha1s start with 17
> # since this is what git gc counts. As it happens, these
> # two blobs will do so.
> test_commit 263 &&
> test_commit 410 &&
>
> T
On Fri, Jul 28, 2017 at 10:59 AM, Junio C Hamano wrote:
> There is another one that is better suited for this demonstration patch,
> whose sole point is about creating bunch of objects that prefix conflicts
> with each other to test the abbreviation machinery.
'Another one' meaning in another tes
There is another one that is better suited for this demonstration patch,
whose sole point is about creating bunch of objects that prefix conflicts
with each other to test the abbreviation machinery.
On Fri, Jul 28, 2017 at 10:18 AM, Stefan Beller wrote:
> The first test marked relies on hard co
The first test marked relies on hard coded sha1:
# We need to create two object whose sha1s start with 17
# since this is what git gc counts. As it happens, these
# two blobs will do so.
test_commit 263 &&
test_commit 410 &&
The next two seem to rely on st
12 matches
Mail list logo
