Re: [PATCH v2 00/19] Index-v5

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano <gitster@xxxxxxxxx> writes:

> Thomas Gummerer <t.gummerer@xxxxxxxxx> writes:
>
>> Ah ok, I understand.  I think it's best to add a GIT_INDEX_VERSION=x
>> config option to config.mak, where x is the index version that should be
>> tested.
>
> Whatever you do, please do not call it GIT_INDEX_VERSION _if_ it is
> only to be used while testing.  Have string "TEST" somewhere in the
> name, and make t/test-lib-functions.sh take notice.
>
> Currently, the way for the user to show the preference as to which
> index version to use is to explicitly set the version once, and then
> we will (try to) propagate it inside the repository.
>
> I would not mind if we add a mechanism to make write_index() notice
> the environment variable GIT_INDEX_VERSION and write the index in
> that version.  But that is conceptually very different from whatever
> you give "make VARIABLE=blah" from the command line when building
> Git (or set in config.mak which amounts to the same thing).

What I currently did is add a environment variable GIT_INDEX_VERSION
that is used only if there is no index yet, to make sure existing
repositories aren't affected and still have to be converted explicitly
by using git update-index.

For the tests I simply did export GIT_INDEX_VERSION in test-lib.sh to
allow the addition of GIT_INDEX_VERSION in config.mak.  Should I rename
that to GIT_INDEX_VERSION_TEST and do something like

set_index_version() {
        export GIT_INDEX_VERSION=$GIT_INDEX_VERSION_TEST
}

in test-lib-functions.sh instead, does that make sense?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]