Re: [PATCH/RFC v2] Squashed changes for multiple worktrees vs. submodules
Am 07.12.2014 um 07:42 schrieb Max Kirillov: On Sat, Dec 06, 2014 at 02:06:08PM +0100, Jens Lehmann wrote: Am 05.12.2014 um 07:32 schrieb Max Kirillov: Currently I'm estimating approach when submodules which have .git file or directory inside are updated, and those which do not have it are not. I have added a config variable submodule.updateIgnoringConfigUrl (because usually the submodule.name.url is what turns on the update). It looks working, maybe I even add setting the variable when chackout --to is used. But it's not only submodule.name.url, the list goes on with update, fetch ignore and then there are the global options like diff.submodule, diff.ignoreSubmodules and some more. I believe that parameters are important for some use, but I know several tesns of git users who have no idea bout them, and I myself only learned about them while working on this. But we still want to support them all properly, no? To have some a submodule not initialized in some sorktree is what I really need. I was sure before it is managed by having the submodule checked out. Probably I just did not run `submodule update` in the worktree where did not use submodules, but I cannot rely on it. I see now from 211b7f19c7 that adding parameter for all updates will break the initalization. Maybe it would be better to have a runtime argument: `git submodule update --ignore-config-url` Huh? I think we already have that: If you ignore the url config it's as if the submodule was never initialized, so you can just *not* run the git submodule update command at all to get that effect. No new option needed ;-) Thanks to you and Duy for discussing this with me! I'd sum it up like this: *) Multiple worktrees are meant to couple separate worktrees with a single repository to avoid having to push and fetch each time to sync refs and also to not having to sync settings manually (with the benefit of some disk space savings). That's a cool feature and explains why a branch should be protected against being modified in different worktrees. I should notify that I am not the author of the feature, maybe Duy have some other vision. The first level submodule settings are shared between the multiple worktrees; submodule objects, settings and refs aren't (because the .git/modules directory isn't shared). Looks like that would work with just what we have now, no? Yes, very much like what I proposed in $gmane/258173, but I need to have something about preventing checkout. And I should review what I've done since that, maybe there are more things to fix. Hmm, I do not get the preventing checkout part. If you ran git submodule init path in just one of the multiple work trees a later git submodule update in any of the multiple work trees will checkout the submodule there. The only way I can imagine to change that is to implement separate worktree configurations for each of the multiple worktrees. *) I'd love to see a solution for sharing the object database between otherwise unrelated clones of the same project (so that fetching in one clone updates the objects in the common dir and gc cannot throw anything away used by one of the clones). But I'd expect a bare repository as the common one where we put the worktrees refs into their own namespaces. There is a GIT_NAMESPACE already, maybe it should be just extended to work with all commands? As you already noticed, it isn't a solution for my problem. btw, have you tried alternates? It does reduce the number of objects you need to keep very strongly. You can put in the alternate store only released branches which are guaranteed to be not force-updated, to avoid issues with missing objects, and it still helps. Which is exactly what we do *not* want to do on a CI server, its purpose is to endlessly build development branches that are force-updated on a regular basis. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v2] Squashed changes for multiple worktrees vs. submodules
On Mon, Dec 08, 2014 at 09:40:59PM +0100, Jens Lehmann wrote: Huh? I think we already have that: If you ignore the url config it's as if the submodule was never initialized, so you can just *not* run the git submodule update command at all to get that effect. No new option needed ;-) You are right. I was thinking about minimal change to submodules which would allow user selectively checkout them but the most minimal one is just selectively run `submodule update`. I think in scope of this feature no changes to git-submodule is required. btw, have you tried alternates? It does reduce the number of objects you need to keep very strongly. You can put in the alternate store only released branches which are guaranteed to be not force-updated, to avoid issues with missing objects, and it still helps. Which is exactly what we do *not* want to do on a CI server, its purpose is to endlessly build development branches that are force-updated on a regular basis. Yes, but they still are only somewhat ahead of some stable branch. And not very much, if you count space: _All_ git development, with whatever unstable branches, takes 5-10 times less space than its carved in stone history under `master`. -- Max -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v2] Squashed changes for multiple worktrees vs. submodules
On Sun, Dec 07, 2014 at 08:42:30AM +0200, Max Kirillov wrote: *) I'd love to see a solution for sharing the object database between otherwise unrelated clones of the same project (so that fetching in one clone updates the objects in the common dir and gc cannot throw anything away used by one of the clones). But I'd expect a bare repository as the common one where we put the worktrees refs into their own namespaces. There is a GIT_NAMESPACE already, maybe it should be just extended to work with all commands? No, this will not work for submodules, has same issues with the same config. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v2] Squashed changes for multiple worktrees vs. submodules
Am 05.12.2014 um 02:33 schrieb Duy Nguyen:
On Fri, Dec 5, 2014 at 3:06 AM, Jens Lehmann jens.lehm...@web.de wrote:
Wow, so the .git/config is shared between all worktrees? I
suspect you have very good reasons for that,
most of config vars are at repo-level, not worktree-level, except
maybe submodule.* and something else.
Yeah, that would have been my first guess too.
Technically we could use
include.path to point to a non-shared file, where we store
worktree-specific config.
I like that, but am not sure how hard that would be to
implement.
but I believe
that'll make multiple work trees surprise the user from time
to time when used with submodules. Because initializing a
submodule in one worktree initializes it in all other
worktrees too (I suspect other users regard git submodule
init being a worktree local command too). And setting
submodule.name.update to none will also affect all
other worktrees. But I'd need to have separate settings for
our CI server, e.g. to checkout the sources without the
largish documentation submodule in one test job (=worktree)
while checking out the whole documentation for another job
building the setup in another worktree.
And if I understand the checkout: reject if the branch is
already checked out elsewhere thread correctly, I won't be
able to build master in two jobs at the same time?
If you do git checkout --to ... master^{}, it should run fine.
So I'd have to teach our CI-server that incantation ... and
must hope nothing else breaks because of the detached HEAD.
I'm
still considering doing something better with the read-only refs, but
haven't found time to really think it through yet.
Hmm, what about different namespaces for the refs in the repo
borrowed from? Maybe only when it is bare? Dunno ...
Thanks. But I changed my mind about the details (now that I
know about .git/config and multiple worktrees). I think you'd
have to connect a .git directory in the submodule to the
common git dir directly, as you cannot use the core.worktree
setting (which could be different between commits due to
renames) when putting it into worktree/.git/modules. And
then you couldn't remove or rename a submodule anymore,
because that fails when it contains a .git directory.
Seems like we should put a Warning: may do unexpected things
when used with submodules (with some examples about what might
happen) in the multiple worktrees documentation. And I don't
believe anymore that teaching submodules to use the common git
dir makes that much sense after I know about the restrictions
it imposes.
I'm ok with such a warning fwiw.
I believe you'd need to prominently advertise that changing
settings in .git/config affects all worktrees anyway to avoid
surprising users (at least I didn't expect it ;-), so adding
a word or to that this also impacts submodules should suffice.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v2] Squashed changes for multiple worktrees vs. submodules
Am 05.12.2014 um 07:32 schrieb Max Kirillov: On Thu, Dec 4, 2014 at 10:06 PM, Jens Lehmann jens.lehm...@web.de wrote: But I'd need to have separate settings for our CI server, e.g. to checkout the sources without the largish documentation submodule in one test job (=worktree) while checking out the whole documentation for another job building the setup in another worktree. Currently I'm estimating approach when submodules which have .git file or directory inside are updated, and those which do not have it are not. I have added a config variable submodule.updateIgnoringConfigUrl (because usually the submodule.name.url is what turns on the update). It looks working, maybe I even add setting the variable when chackout --to is used. But it's not only submodule.name.url, the list goes on with update, fetch ignore and then there are the global options like diff.submodule, diff.ignoreSubmodules and some more. And if I understand the checkout: reject if the branch is already checked out elsewhere thread correctly, I won't be able to build master in two jobs at the same time? You are alerady second person complaining about it, but I don't really see how this can be a problem. Make a branch 'master2', it's another 40 bytes. I didn't mean to complain, I'm just explaining. And I cannot easily make it master2, I'd have to teach Jenkins that (and maybe that's easy and I just don't know how to do it). So two reasons against using multiple worktrees on our CI server to save quite some disk space :-( My use is not to save space (working tree files often takes more than the repository itself), but for development, I have like 3-5 checkouts usually, which used to be local clones, but not having to keep synching them is really life changing. Thanks, that explains my confusion. You want those repos to be tightly coupled while I'm looking for completely separate repos which just share their shared objects to reduce disk footprint. Seems like we should put a Warning: may do unexpected things when used with submodules (with some examples about what might happen) in the multiple worktrees documentation. And I don't believe anymore that teaching submodules to use the common git dir makes that much sense after I know about the restrictions it imposes. btw, I thought even about making it an error to add/remove/(de)initialize submodule not in the main working tree. But I'm afraid it would not be considered appropriate for merging. I think an error is too harsh here. If you know what you are doing (and what you cannot do) I see no reason not to use submodules together with multiple worktrees. And if you're sharing branches it might be rather obvious that you share submodule and other worktree settings too in the superproject. Thanks to you and Duy for discussing this with me! I'd sum it up like this: *) Multiple worktrees are meant to couple separate worktrees with a single repository to avoid having to push and fetch each time to sync refs and also to not having to sync settings manually (with the benefit of some disk space savings). That's a cool feature and explains why a branch should be protected against being modified in different worktrees. The first level submodule settings are shared between the multiple worktrees; submodule objects, settings and refs aren't (because the .git/modules directory isn't shared). Looks like that would work with just what we have now, no? Having submodules share repos would need at least a per-worktree core.git setting (which could be achieved via worktree-specific .git/config includes). *) I'd love to see a solution for sharing the object database between otherwise unrelated clones of the same project (so that fetching in one clone updates the objects in the common dir and gc cannot throw anything away used by one of the clones). But I'd expect a bare repository as the common one where we put the worktrees refs into their own namespaces. That's another beast (which nonetheless might be based on what you guys are doing here). And the worktree specific configuration needed here could help to share submodule repos for the multiple worktrees case. Does that make sense? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v2] Squashed changes for multiple worktrees vs. submodules
On Sat, Dec 06, 2014 at 02:06:08PM +0100, Jens Lehmann wrote: Am 05.12.2014 um 07:32 schrieb Max Kirillov: Currently I'm estimating approach when submodules which have .git file or directory inside are updated, and those which do not have it are not. I have added a config variable submodule.updateIgnoringConfigUrl (because usually the submodule.name.url is what turns on the update). It looks working, maybe I even add setting the variable when chackout --to is used. But it's not only submodule.name.url, the list goes on with update, fetch ignore and then there are the global options like diff.submodule, diff.ignoreSubmodules and some more. I believe that parameters are important for some use, but I know several tesns of git users who have no idea bout them, and I myself only learned about them while working on this. To have some a submodule not initialized in some sorktree is what I really need. I was sure before it is managed by having the submodule checked out. Probably I just did not run `submodule update` in the worktree where did not use submodules, but I cannot rely on it. I see now from 211b7f19c7 that adding parameter for all updates will break the initalization. Maybe it would be better to have a runtime argument: `git submodule update --ignore-config-url` Thanks to you and Duy for discussing this with me! I'd sum it up like this: *) Multiple worktrees are meant to couple separate worktrees with a single repository to avoid having to push and fetch each time to sync refs and also to not having to sync settings manually (with the benefit of some disk space savings). That's a cool feature and explains why a branch should be protected against being modified in different worktrees. I should notify that I am not the author of the feature, maybe Duy have some other vision. The first level submodule settings are shared between the multiple worktrees; submodule objects, settings and refs aren't (because the .git/modules directory isn't shared). Looks like that would work with just what we have now, no? Yes, very much like what I proposed in $gmane/258173, but I need to have something about preventing checkout. And I should review what I've done since that, maybe there are more things to fix. *) I'd love to see a solution for sharing the object database between otherwise unrelated clones of the same project (so that fetching in one clone updates the objects in the common dir and gc cannot throw anything away used by one of the clones). But I'd expect a bare repository as the common one where we put the worktrees refs into their own namespaces. There is a GIT_NAMESPACE already, maybe it should be just extended to work with all commands? btw, have you tried alternates? It does reduce the number of objects you need to keep very strongly. You can put in the alternate store only released branches which are guaranteed to be not force-updated, to avoid issues with missing objects, and it still helps. For example, the full git repository takes about 70mb, and if I put master to alternate store, the rest takes 7mb, and even if I clone all original repository, debian repository and msysgit repository, thay all take 15mb. It's without worktree, which takes 27mb :) -- Max -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v2] Squashed changes for multiple worktrees vs. submodules
Am 02.12.2014 um 23:16 schrieb Max Kirillov: On Tue, Dec 02, 2014 at 09:45:24PM +0100, Jens Lehmann wrote: But, while hacking the submodule init I became more convinced that the modules directory should be common and submodules in checkout should be a checkouts of the submodule. Because this is looks like concept of submodules, that they are unique for the lifetime of repository, even if they do not exist in all revisions. And if anybody want to use fully independent checkout they can be always checked out manually. Actually, after a submodule is initialized and have a proper gitlink, it can be updated and inquired regardless of where it points to. If I understand you correctly you want to put the submodule's common git dir under the superproject's common git dir. I agree that that makes most sense as the default, but having the possibility to use a common git dir for submodule's of different superprojects would be nice to have for some setups, e.g. CI-servers. But that can be added later. So far there is no separation of .git/config for different worktrees. As submodules rely on the config their separation cannot be done fully without changing that. So this should be really left for some later improvements. Wow, so the .git/config is shared between all worktrees? I suspect you have very good reasons for that, but I believe that'll make multiple work trees surprise the user from time to time when used with submodules. Because initializing a submodule in one worktree initializes it in all other worktrees too (I suspect other users regard git submodule init being a worktree local command too). And setting submodule.name.update to none will also affect all other worktrees. But I'd need to have separate settings for our CI server, e.g. to checkout the sources without the largish documentation submodule in one test job (=worktree) while checking out the whole documentation for another job building the setup in another worktree. And if I understand the checkout: reject if the branch is already checked out elsewhere thread correctly, I won't be able to build master in two jobs at the same time? So two reasons against using multiple worktrees on our CI server to save quite some disk space :-( Thanks. I just didn't quite understand why you had to do so many changes to git-submodule.sh. Wouldn't it be sufficient to just update module_clone()? Thanks, I should try it. Probably I had the opposite idea in mind - keep module_clone as untouched as possible. Maybe I should see how it's going to look if I move all worktrees logic there. Thanks. But I changed my mind about the details (now that I know about .git/config and multiple worktrees). I think you'd have to connect a .git directory in the submodule to the common git dir directly, as you cannot use the core.worktree setting (which could be different between commits due to renames) when putting it into worktree/.git/modules. And then you couldn't remove or rename a submodule anymore, because that fails when it contains a .git directory. Seems like we should put a Warning: may do unexpected things when used with submodules (with some examples about what might happen) in the multiple worktrees documentation. And I don't believe anymore that teaching submodules to use the common git dir makes that much sense after I know about the restrictions it imposes. Or am I misunderstanding anything? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v2] Squashed changes for multiple worktrees vs. submodules
On Fri, Dec 5, 2014 at 3:06 AM, Jens Lehmann jens.lehm...@web.de wrote:
Wow, so the .git/config is shared between all worktrees? I
suspect you have very good reasons for that,
most of config vars are at repo-level, not worktree-level, except
maybe submodule.* and something else. Technically we could use
include.path to point to a non-shared file, where we store
worktree-specific config.
but I believe
that'll make multiple work trees surprise the user from time
to time when used with submodules. Because initializing a
submodule in one worktree initializes it in all other
worktrees too (I suspect other users regard git submodule
init being a worktree local command too). And setting
submodule.name.update to none will also affect all
other worktrees. But I'd need to have separate settings for
our CI server, e.g. to checkout the sources without the
largish documentation submodule in one test job (=worktree)
while checking out the whole documentation for another job
building the setup in another worktree.
And if I understand the checkout: reject if the branch is
already checked out elsewhere thread correctly, I won't be
able to build master in two jobs at the same time?
If you do git checkout --to ... master^{}, it should run fine. I'm
still considering doing something better with the read-only refs, but
haven't found time to really think it through yet.
Thanks. But I changed my mind about the details (now that I
know about .git/config and multiple worktrees). I think you'd
have to connect a .git directory in the submodule to the
common git dir directly, as you cannot use the core.worktree
setting (which could be different between commits due to
renames) when putting it into worktree/.git/modules. And
then you couldn't remove or rename a submodule anymore,
because that fails when it contains a .git directory.
Seems like we should put a Warning: may do unexpected things
when used with submodules (with some examples about what might
happen) in the multiple worktrees documentation. And I don't
believe anymore that teaching submodules to use the common git
dir makes that much sense after I know about the restrictions
it imposes.
I'm ok with such a warning fwiw.
--
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v2] Squashed changes for multiple worktrees vs. submodules
On Thu, Dec 4, 2014 at 10:06 PM, Jens Lehmann jens.lehm...@web.de wrote: But I'd need to have separate settings for our CI server, e.g. to checkout the sources without the largish documentation submodule in one test job (=worktree) while checking out the whole documentation for another job building the setup in another worktree. Currently I'm estimating approach when submodules which have .git file or directory inside are updated, and those which do not have it are not. I have added a config variable submodule.updateIgnoringConfigUrl (because usually the submodule.name.url is what turns on the update). It looks working, maybe I even add setting the variable when chackout --to is used. And if I understand the checkout: reject if the branch is already checked out elsewhere thread correctly, I won't be able to build master in two jobs at the same time? You are alerady second person complaining about it, but I don't really see how this can be a problem. Make a branch 'master2', it's another 40 bytes. So two reasons against using multiple worktrees on our CI server to save quite some disk space :-( My use is not to save space (working tree files often takes more than the repository itself), but for development, I have like 3-5 checkouts usually, which used to be local clones, but not having to keep synching them is really life changing. Thanks. But I changed my mind about the details (now that I know about .git/config and multiple worktrees). I think you'd have to connect a .git directory in the submodule to the common git dir directly, as you cannot use the core.worktree setting (which could be different between commits due to renames) when putting it into worktree/.git/modules. And then you couldn't remove or rename a submodule anymore, because that fails when it contains a .git directory. I need to think more about it. Seems like we should put a Warning: may do unexpected things when used with submodules (with some examples about what might happen) in the multiple worktrees documentation. And I don't believe anymore that teaching submodules to use the common git dir makes that much sense after I know about the restrictions it imposes. btw, I thought even about making it an error to add/remove/(de)initialize submodule not in the main working tree. But I'm afraid it would not be considered appropriate for merging. -- Max -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v2] Squashed changes for multiple worktrees vs. submodules
Am 01.12.2014 um 00:27 schrieb Max Kirillov:
builtin/checkout.c: use absolute path instead of given argument for
picking worktree name, it happens to be needed because for submodule
checkout the new worktree is always .
environment.c: add GIT_COMMON_DIR to local_repo_env
git-submodule.sh: implement automatic cloning of main repository
and checkout to new worktree at submodule update --init
path.c, setup.c, submodule.c: fix diff --submodule when
submodule is a linked worktree
t/t7410-submodule-checkout-to.sh: tests for all the above
Signed-off-by: Max Kirillov m...@max630.net
---
Hi.
Thanks for including my 2 patches.
But, while hacking the submodule init I became more convinced that the
modules directory should be common and submodules in checkout should be
a checkouts of the submodule. Because this is looks like concept of
submodules, that they are unique for the lifetime of repository, even if
they do not exist in all revisions. And if anybody want to use fully
independent checkout they can be always checked out manually. Actually,
after a submodule is initialized and have a proper gitlink, it can be
updated and inquired regardless of where it points to.
If I understand you correctly you want to put the submodule's common
git dir under the superproject's common git dir. I agree that that
makes most sense as the default, but having the possibility to use a
common git dir for submodule's of different superprojects would be
nice to have for some setups, e.g. CI-servers. But that can be added
later.
So that one I think is not needed. I have instead some changes to
git-submodule, but have not prepared them yet as an exportable history.
I am submitting here squashed changes which I have so far, to give an
idea where it goes. I'll try to prepare a proper patch series as soon as
I can.
Thanks. I just didn't quite understand why you had to do so many
changes to git-submodule.sh. Wouldn't it be sufficient to just
update module_clone()?
If the superproject uses a common git dir I'd expect module_clone()
to set up the local superproject's worktree .git/modules/name
referencing the /modules/name directory of the superproject's
common git dir as the submodule's common git dir. So instead of a
clone of the submodule's upstream it would put a multiple worktree
version of the submodule under .git/modules/name. Then there
should be no further difference between a submodule that borrows
from the common git dir an one that doesn't.
Am I missing something about how the common dir thingy works? Or
maybe that .git/modules/name is bare is a problem here?
They contain change $gmane/258173, which I think is important,
especially because it is required not only for initialization but for
regular work also, and changes for initialization of submodules.
They are rebased on top of you patches excluding the 34/34 patch.
builtin/checkout.c | 25 ++---
cache.h | 1 +
environment.c| 1 +
git-submodule.sh | 94 ++
path.c | 24 -
setup.c | 17 +++-
submodule.c | 28 ++
t/t7410-submodule-checkout-to.sh | 201 +++
8 files changed, 332 insertions(+), 59 deletions(-)
create mode 100755 t/t7410-submodule-checkout-to.sh
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 953b763..78154ae 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -858,27 +858,29 @@ static int prepare_linked_checkout(const struct
checkout_opts *opts,
{
struct strbuf sb_git = STRBUF_INIT, sb_repo = STRBUF_INIT;
struct strbuf sb = STRBUF_INIT;
- const char *path = opts-new_worktree, *name;
+ struct strbuf sb_path = STRBUF_INIT;
+ const char *name;
struct stat st;
struct child_process cp;
int counter = 0, len, ret;
if (!new-commit)
die(_(no branch specified));
- if (file_exists(path) !is_empty_dir(path))
- die(_('%s' already exists), path);
+ strbuf_add_absolute_path(sb_path, opts-new_worktree);
+ if (file_exists(sb_path.buf) !is_empty_dir(sb_path.buf))
+ die(_('%s' already exists), sb_path.buf);
- len = strlen(path);
- while (len is_dir_sep(path[len - 1]))
+ len = sb_path.len;
+ while (len is_dir_sep(sb_path.buf[len - 1]))
len--;
- for (name = path + len - 1; name path; name--)
+ for (name = sb_path.buf + len - 1; name sb_path.buf; name--)
if (is_dir_sep(*name)) {
name++;
break;
}
strbuf_addstr(sb_repo,
- git_path(worktrees/%.*s, (int)(path + len - name),
name));
+ git_path(worktrees/%.*s, (int)(sb_path.buf + len -
name), name));
len = sb_repo.len;
if
Re: [PATCH/RFC v2] Squashed changes for multiple worktrees vs. submodules
On Tue, Dec 02, 2014 at 09:45:24PM +0100, Jens Lehmann wrote: But, while hacking the submodule init I became more convinced that the modules directory should be common and submodules in checkout should be a checkouts of the submodule. Because this is looks like concept of submodules, that they are unique for the lifetime of repository, even if they do not exist in all revisions. And if anybody want to use fully independent checkout they can be always checked out manually. Actually, after a submodule is initialized and have a proper gitlink, it can be updated and inquired regardless of where it points to. If I understand you correctly you want to put the submodule's common git dir under the superproject's common git dir. I agree that that makes most sense as the default, but having the possibility to use a common git dir for submodule's of different superprojects would be nice to have for some setups, e.g. CI-servers. But that can be added later. So far there is no separation of .git/config for different worktrees. As submodules rely on the config their separation cannot be done fully without changing that. So this should be really left for some later improvements. As a user I am currently perfectly satisfied with manually checking out or even cloning submodules inplace, I don't do it often. Thanks. I just didn't quite understand why you had to do so many changes to git-submodule.sh. Wouldn't it be sufficient to just update module_clone()? Thanks, I should try it. Probably I had the opposite idea in mind - keep module_clone as untouched as possible. Maybe I should see how it's going to look if I move all worktrees logic there. -- Max -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v2] Squashed changes for multiple worktrees vs. submodules
On Mon, Dec 1, 2014 at 6:27 AM, Max Kirillov m...@max630.net wrote: But, while hacking the submodule init I became more convinced that the modules directory should be common and submodules in checkout should be a checkouts of the submodule. Because this is looks like concept of submodules, that they are unique for the lifetime of repository, even if they do not exist in all revisions. And if anybody want to use fully independent checkout they can be always checked out manually. Actually, after a submodule is initialized and have a proper gitlink, it can be updated and inquired regardless of where it points to. Just throw something in for discussion. What about keeping $GIT_DIR/modules like it is now (i.e. not shared) and add $GIT_DIR/shared-modules, which is the same for all checkouts? That would keep current submodule code happy (no name collision or anything). New submodule code can start using $GIT_DIR/shared-modules while still keeping an eye on $GIT_DIR/modules for old setups. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v2] Squashed changes for multiple worktrees vs. submodules
On Mon, Dec 01, 2014 at 05:43:16PM +0700, Duy Nguyen wrote: On Mon, Dec 1, 2014 at 6:27 AM, Max Kirillov m...@max630.net wrote: But, while hacking the submodule init I became more convinced that the modules directory should be common and submodules in checkout should be a checkouts of the submodule. Because this is looks like concept of submodules, that they are unique for the lifetime of repository, even if they do not exist in all revisions. And if anybody want to use fully independent checkout they can be always checked out manually. Actually, after a submodule is initialized and have a proper gitlink, it can be updated and inquired regardless of where it points to. Just throw something in for discussion. What about keeping $GIT_DIR/modules like it is now (i.e. not shared) and add $GIT_DIR/shared-modules, which is the same for all checkouts? That would keep current submodule code happy (no name collision or anything). New submodule code can start using $GIT_DIR/shared-modules while still keeping an eye on $GIT_DIR/modules for old setups. I think it would be too complicated. To make fancy think user can always manually initialize a repository or a checkout. And all sumbodule functionality except adding/removing/(de)initialization should work with any repository or gitlink, regardless of where it points to. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v2] Squashed changes for multiple worktrees vs. submodules
builtin/checkout.c: use absolute path instead of given argument for
picking worktree name, it happens to be needed because for submodule
checkout the new worktree is always .
environment.c: add GIT_COMMON_DIR to local_repo_env
git-submodule.sh: implement automatic cloning of main repository
and checkout to new worktree at submodule update --init
path.c, setup.c, submodule.c: fix diff --submodule when
submodule is a linked worktree
t/t7410-submodule-checkout-to.sh: tests for all the above
Signed-off-by: Max Kirillov m...@max630.net
---
Hi.
Thanks for including my 2 patches.
But, while hacking the submodule init I became more convinced that the
modules directory should be common and submodules in checkout should be
a checkouts of the submodule. Because this is looks like concept of
submodules, that they are unique for the lifetime of repository, even if
they do not exist in all revisions. And if anybody want to use fully
independent checkout they can be always checked out manually. Actually,
after a submodule is initialized and have a proper gitlink, it can be
updated and inquired regardless of where it points to.
So that one I think is not needed. I have instead some changes to
git-submodule, but have not prepared them yet as an exportable history.
I am submitting here squashed changes which I have so far, to give an
idea where it goes. I'll try to prepare a proper patch series as soon as
I can.
They contain change $gmane/258173, which I think is important,
especially because it is required not only for initialization but for
regular work also, and changes for initialization of submodules.
They are rebased on top of you patches excluding the 34/34 patch.
builtin/checkout.c | 25 ++---
cache.h | 1 +
environment.c| 1 +
git-submodule.sh | 94 ++
path.c | 24 -
setup.c | 17 +++-
submodule.c | 28 ++
t/t7410-submodule-checkout-to.sh | 201 +++
8 files changed, 332 insertions(+), 59 deletions(-)
create mode 100755 t/t7410-submodule-checkout-to.sh
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 953b763..78154ae 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -858,27 +858,29 @@ static int prepare_linked_checkout(const struct
checkout_opts *opts,
{
struct strbuf sb_git = STRBUF_INIT, sb_repo = STRBUF_INIT;
struct strbuf sb = STRBUF_INIT;
- const char *path = opts-new_worktree, *name;
+ struct strbuf sb_path = STRBUF_INIT;
+ const char *name;
struct stat st;
struct child_process cp;
int counter = 0, len, ret;
if (!new-commit)
die(_(no branch specified));
- if (file_exists(path) !is_empty_dir(path))
- die(_('%s' already exists), path);
+ strbuf_add_absolute_path(sb_path, opts-new_worktree);
+ if (file_exists(sb_path.buf) !is_empty_dir(sb_path.buf))
+ die(_('%s' already exists), sb_path.buf);
- len = strlen(path);
- while (len is_dir_sep(path[len - 1]))
+ len = sb_path.len;
+ while (len is_dir_sep(sb_path.buf[len - 1]))
len--;
- for (name = path + len - 1; name path; name--)
+ for (name = sb_path.buf + len - 1; name sb_path.buf; name--)
if (is_dir_sep(*name)) {
name++;
break;
}
strbuf_addstr(sb_repo,
- git_path(worktrees/%.*s, (int)(path + len - name),
name));
+ git_path(worktrees/%.*s, (int)(sb_path.buf + len -
name), name));
len = sb_repo.len;
if (safe_create_leading_directories_const(sb_repo.buf))
die_errno(_(could not create leading directories of '%s'),
@@ -906,11 +908,11 @@ static int prepare_linked_checkout(const struct
checkout_opts *opts,
strbuf_addf(sb, %s/locked, sb_repo.buf);
write_file(sb.buf, 1, initializing\n);
- strbuf_addf(sb_git, %s/.git, path);
+ strbuf_addf(sb_git, %s/.git, sb_path.buf);
if (safe_create_leading_directories_const(sb_git.buf))
die_errno(_(could not create leading directories of '%s'),
sb_git.buf);
- junk_work_tree = xstrdup(path);
+ junk_work_tree = xstrdup(sb_path.buf);
strbuf_reset(sb);
strbuf_addf(sb, %s/gitdir, sb_repo.buf);
@@ -931,11 +933,11 @@ static int prepare_linked_checkout(const struct
checkout_opts *opts,
write_file(sb.buf, 1, ../..\n);
if (!opts-quiet)
- fprintf_ln(stderr, _(Enter %s (identifier %s)), path, name);
+ fprintf_ln(stderr, _(Enter %s (identifier %s)), sb_path.buf,
name);
setenv(GIT_CHECKOUT_NEW_WORKTREE, 1, 1);
setenv(GIT_DIR_ENVIRONMENT, sb_git.buf, 1);
-
