Re: [RFC/PATCH] submodule: add 'exec' option to submodule update

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

 



Am 28.06.2013 11:53, schrieb Chris Packham:
> This allows the user some finer grained control over how the update is
> done. The primary motivation for this was interoperability with stgit
> however being able to intercept the submodule update process may prove
> useful for integrating or extending other tools.
> 
> Signed-off-by: Chris Packham <judge.packham@xxxxxxxxx>
> --
> Hi,
> 
> At $dayjob we have a number of users that are accustomed to using stgit.
> Stgit doesn't play nicely with git rebase which would be the logical
> setting for submodule.*.update for our usage. Instead we need to run
> 'stg rebase --merged' on those submodules that have been initialised
> with stgit.
> 
> Our current solution is an in-house script which is a poor substitute
> for git submodule update. I'd much rather replace our script with git
> submodule update but we do have a requirement to keep stgit for the
> foreseeable future.  Rather than narrowing in on stgit it seems logical
> to allow an arbitrary update command to be executed.

Hhmmm...
Can't the same be accomplished with 
 
  git submodule foreach 'your-update-script $sha1'

Am I missing something?

Stefan
-- 
----------------------------------------------------------------
/dev/random says: Preserve nature... pickle a squirrel.
python -c "print '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
--
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]