threads / discuss / 36431

automatic submodule deinit (platform specific blacklist)

Subject: automatic submodule deinit (platform specific blacklist)

## tl;dr

3 messages between Apr 17, 2014 and Apr 17, 2014.

replies: 2people: 2as markdown or json

Gerhard Gappmeier· Apr 17, 2014, 08:02 UTC · lore
Hi all

in our cross-platform projects we always have a certain Windows-only submodule, which contains all the compatibility stuff and missing libraries for Windows.

When cloning such a repository on a Linux machine the typical procedure is: git clone git@server:project.git cd project git submodule init git submodule deinit path/to/windows-stuff git submodule update

This way you avoid wasting time and disk space to clone stuff that you don't need on Linux (or on whatever non-windows machine your are actually working).

It would be really cool to add a kind of platform specific submodule blacklist, either in .gitconfig or maybe even better in .gitattributes so that we can add this configuration to the repository.

Example .gitattributes how this could look like:
  # common stuff
  *.sh eol=lf
  *.conf eol=lf
  # submodule config
  [src/windows-compat]
  platforms = win32

By default the platforms could have the value "all". But one can change it to a list of platform names e.g. "platforms = linux, macosx" or "win32" like in the example above.

Such a feature would also make it possible to simply use "git clone -- recursive git@server:project.git" avoiding the single stops as shown above.

What do your think? Is something like this possible? Or is it even possible already somehow?

Today I'm using a shell script to automate this steps, but this is just a workaround. It would be cool if git itself could do this for us.

-- 
mit freundlichen Grüßen / best regards

Gerhard Gappmeier
ascolab GmbH - automation systems communication laboratory
Tel.: +49 9131 691 123
Fax: +49 9131 691 128
Web: http://www.ascolab.com
GPG-KeyId: 5AAC50C4
GPG-Fingerprint: 967A 15F1 2788 164D CCA3 6C46 07CD 6F82 5AAC 50C4

--
ascolab GmbH
Geschäftsführer: Gerhard Gappmeier, Matthias Damm, Uwe Steinkrauß
Sitz der Gesellschaft: Am Weichselgarten 7 • 91058 Erlangen • Germany
Registernummer: HRB 9360
Registergericht: Amtsgericht Fürth
Jens Lehmann· Apr 17, 2014, 15:45 UTC · re: Gerhard Gappmeier · lore

Re: automatic submodule deinit (platform specific blacklist)

Am 17.04.2014 10:02, schrieb Gerhard Gappmeier:
Show 41 quoted lines
> Hi all
> 
> in our cross-platform projects we always have a certain Windows-only 
> submodule, which contains all the compatibility stuff and missing libraries for 
> Windows.
> 
> When cloning such a repository on a Linux machine the typical procedure is:
> git clone git@server:project.git
> cd project
> git submodule init
> git submodule deinit path/to/windows-stuff
> git submodule update
> 
> This way you avoid wasting time and disk space to clone stuff that you don't 
> need on Linux (or on whatever non-windows machine your are actually working).
> 
> It would be really cool to add a kind of platform specific submodule blacklist,
> either in .gitconfig or maybe even better in .gitattributes so that we can add 
> this configuration to the repository.
> 
> Example .gitattributes how this could look like:
>   # common stuff
>   *.sh eol=lf
>   *.conf eol=lf
> 
>   # submodule config
>   [src/windows-compat]
>   platforms = win32
> 
> By default the platforms could have the value "all". But one can change it to 
> a list of platform names e.g. "platforms = linux, macosx" or "win32" like in 
> the example above.
> 
> Such a feature would also make it possible to simply use "git clone --
> recursive git@server:project.git" avoiding the single stops as shown above.
> 
> What do your think? Is something like this possible?
> Or is it even possible already somehow?
> 
> Today I'm using a shell script to automate this steps, but this is just a 
> workaround. It would be cool if git itself could do this for us.

What about setting "submodule.<name>.update" to "none" in the config of your non-Windows machines? Then they would be initialized (= the URL setting gets copied to .git/config) but never checked out.

Gerhard Gappmeier· Apr 17, 2014, 20:11 UTC · re: Jens Lehmann · lore

Re: automatic submodule deinit (platform specific blacklist)

On 04/17/14 17:45, Jens Lehmann wrote:
Show 45 quoted lines
> Am 17.04.2014 10:02, schrieb Gerhard Gappmeier:
>> Hi all
>>
>> in our cross-platform projects we always have a certain Windows-only
>> submodule, which contains all the compatibility stuff and missing libraries for
>> Windows.
>>
>> When cloning such a repository on a Linux machine the typical procedure is:
>> git clone git@server:project.git
>> cd project
>> git submodule init
>> git submodule deinit path/to/windows-stuff
>> git submodule update
>>
>> This way you avoid wasting time and disk space to clone stuff that you don't
>> need on Linux (or on whatever non-windows machine your are actually working).
>>
>> It would be really cool to add a kind of platform specific submodule blacklist,
>> either in .gitconfig or maybe even better in .gitattributes so that we can add
>> this configuration to the repository.
>>
>> Example .gitattributes how this could look like:
>>    # common stuff
>>    *.sh eol=lf
>>    *.conf eol=lf
>>
>>    # submodule config
>>    [src/windows-compat]
>>    platforms = win32
>>
>> By default the platforms could have the value "all". But one can change it to
>> a list of platform names e.g. "platforms = linux, macosx" or "win32" like in
>> the example above.
>>
>> Such a feature would also make it possible to simply use "git clone --
>> recursive git@server:project.git" avoiding the single stops as shown above.
>>
>> What do your think? Is something like this possible?
>> Or is it even possible already somehow?
>>
>> Today I'm using a shell script to automate this steps, but this is just a
>> workaround. It would be cool if git itself could do this for us.
> What about setting "submodule.<name>.update" to "none" in the config of
> your non-Windows machines? Then they would be initialized (= the URL
> setting gets copied to .git/config) but never checked out.
great! that works.

It would be even better if we could store this config in the repository, but this helps already a lot.

thx

← back to recent threads