Re: [PATCH] submodule : Add --no-separate-git-dir option to add and update command.
Le lundi 10 mars 2014 à 21:32 +0100, Heiko Voigt a écrit : On Mon, Mar 10, 2014 at 10:08:06AM +0100, Henri GEIST wrote: Le samedi 08 mars 2014 à 00:00 +0100, Jens Lehmann a écrit : Am 06.03.2014 23:20, schrieb Henri GEIST: What is the use case you are trying to solve and why can that not be handled by adding subsubmodule inside submodule? The problem is access rights. Imagine you have 2 people Pierre and Paul. Each with different access write on the server. Pierre has full access on every things. Paul has full access on superproject and subsubmodule but no read/write access to submodule only execution on the directory. Ok, I think I'm slowly beginning to understand your setup. I want all user to get every things they are allowed to have with the command 'git submodule update --init --recursive'. Then as Paul can not clone submodule he can not get subsubmodule recursively through it. Sure, that's how it should work. Paul could only work on a branch where submodule is an empty directory containing subsubmodule, as he doesn't have the rights to clone submodule. I will not redundantly create a branch for each user on the server. When users clone the server it already create a special branch for them 'master' which track 'origin/master'. And if each user have its own branch on the server it will completely defeat the goal of the server collaboration. And transform the git server in simple rsync server. I do not think that is what Jens was suggesting. It does not matter in which branch they work, they can directly use master if you like. What he was suggesting is that they create their repository structure like this: git clone g...@somewhere.net:superproject.git cd superproject/submodule git clone g...@somehwere.net:subsubmodule.git cd subsubmodule ... work, commit, work, commit ... The same applies for the superproject. Now only someone with access to the submodule has to update the registered sha1 once the work is pushed to submodule. I am not sure to understand everything. But if you suggest to clone manually subsubmodule because it could not be clone recursively by submodule due to the lake of access write to get submodule. It is not practical in my use cases. Two of the superprojects I have in charge contains hundreds of submodules or subsubmodules and I have too much users with disparate computer skills. Getting all what a user has access on should be just a recursive clone. And I need superproject to add also submodule/subsubmodule. No. Never let the same file/directory be tracked by two git repositories at the same time. Give Paul a branch to work on where submodule is just an empty directory, and everything will be fine. Or move subsubmodule outside of submodule (and let a symbolic link point to the new location if the path cannot be easily changed). Would that work for you? If I use symbolic links it will just as gitlink enable to use the same subsubmodule clone by more than one superproject but with two major problems : - symbolic links do not work under Windows and some of my users do not even know something else could exist. - symbolic links will not store the SHA-1 of the subsubmodule. And a 'git status' in the repository containing the symbolic link will say nothing about subsubmodule state. Here you are also missing something. What Jens was suggesting was that you move your subsubmodule directly underneath the superproject and from the old location you create a link to the new location for a quick transition. But you can also change all paths in your project to point to the new location. But in the new location you will have subsubmodule registered as a submodule only that it is now directly linked (as submodule) from the superproject instead of the submodule. Ok but in this case what happen to someone cloning only submodule but not superproject ? He will not get subsubmodule which is part of it. Just a dead symbolic link with no hint on what is missing behind. Each of my submodules (at any level) should be usable superprojects by them self having a gitlink to each subsubmodules they needs. I think where we diverge is in the way we are looking gitlinks. Where you see a hierarchic tree, I see a web. And I use gitlinks just like multiplatform symbolic links storing the SHA-1 of there destination and pointing exclusively on git repositories. Well but the problem with a web is that it will introduce a lot of problems that need to be solved. Some repository has to have the authority about a file (or link). If you have a file in multiple repositories overlayed how do you know who is in charge and when? It will not introduce a lot of problems. Me and my teams are using gitlinks this way every days for 2 years know. With a web far more complex than the example I give above
Re: [PATCH/RFC] git-gui: Add a 'recursive' checkbox in the clone menu.
Le mercredi 05 mars 2014 à 19:00 +0100, Jens Lehmann a écrit : Am 05.03.2014 00:01, schrieb Henri GEIST: Permit to do a 'git clone --recursive' through git-gui. I really like where this is heading! Some minor issues: - I think we should be more verbose in the commit message, including that and why the default should be on. Maybe like this? Permit to do a 'git clone --recursive' through git-gui. Add a 'recursive' checkbox in the clone menu which allows users to clone a repository and all its submodules in one go (unless the 'update' flag is set to none in the .gitmodules file for a submodule, in that case that specific submodule is not cloned automatically). Enable this new option per default, as most users want to clone all submodules too when cloning the superproject (This is currently not possible without leaving git gui or adding a custom tool entry for that). - I'd rather change the button text from Recursive (For submodules) to something like Recursively clone submodules too or such. Perfect. Would you like me to send the new version of the patch in this thread Or to make a new thread [patch v2] ? signature.asc Description: This is a digitally signed message part
[PATCH v2] git-gui: Add a 'recursive' checkbox in the clone menu.
Permit to do a 'git clone --recursive' through git-gui.
Add a 'recursive' checkbox in the clone menu which allows
users to clone a repository and all its submodules in one
go (unless the 'update' flag is set to none in the
.gitmodules file for a submodule, in that case that
specific submodule is not cloned automatically).
Enable this new option per default, as most users want to
clone all submodules too when cloning the superproject
(This is currently not possible without leaving git gui
or adding a custom tool entry for that).
Signed-off-by: Henri GEIST geist.he...@laposte.net
Thanks-to: Jens Lehmann jens.lehm...@web.de
---
lib/choose_repository.tcl | 34 --
1 file changed, 32 insertions(+), 2 deletions(-)
diff --git a/lib/choose_repository.tcl b/lib/choose_repository.tcl
index 3c10bc6..1209fa6 100644
--- a/lib/choose_repository.tcl
+++ b/lib/choose_repository.tcl
@@ -18,6 +18,7 @@ field local_path {} ; # Where this repository is locally
field origin_url {} ; # Where we are cloning from
field origin_name origin ; # What we shall call 'origin'
field clone_type hardlink ; # Type of clone to construct
+field recursive true ; # Recursive cloning flag
field readtree_err; # Error output from read-tree (if any)
field sorted_recent ; # recent repositories (sorted)
@@ -525,6 +526,11 @@ method _do_clone {} {
foreach r $w_types {
pack $r -anchor w
}
+ ${NS}::checkbutton $args.type_f.recursive \
+ -text [mc Recursively clone submodules too] \
+ -variable @recursive \
+ -onvalue true -offvalue false
+ pack $args.type_f.recursive
grid $args.type_l $args.type_f -sticky new
grid columnconfigure $args 1 -weight 1
@@ -952,6 +958,30 @@ method _do_clone_checkout {HEAD} {
fileevent $fd readable [cb _readtree_wait $fd]
}
+method _do_validate_submodule_cloning {ok} {
+ if {$ok} {
+ $o_cons done $ok
+ set done 1
+ } else {
+ _clone_failed $this [mc Cannot clone submodules.]
+ }
+}
+
+method _do_clone_submodules {} {
+ if {$recursive eq {true}} {
+ destroy $w_body
+ set o_cons [console::embed \
+ $w_body \
+ [mc Cloning submodules]]
+ pack $w_body -fill both -expand 1 -padx 10
+ $o_cons exec \
+ [list git submodule update --init --recursive] \
+ [cb _do_validate_submodule_cloning]
+ } else {
+ set done 1
+ }
+}
+
method _readtree_wait {fd} {
set buf [read $fd]
$o_cons update_meter $buf
@@ -982,7 +1012,7 @@ method _readtree_wait {fd} {
fconfigure $fd_ph -blocking 0 -translation binary -eofchar {}
fileevent $fd_ph readable [cb _postcheckout_wait $fd_ph]
} else {
- set done 1
+ _do_clone_submodules $this
}
}
@@ -996,7 +1026,7 @@ method _postcheckout_wait {fd_ph} {
hook_failed_popup post-checkout $pch_error 0
}
unset pch_error
- set done 1
+ _do_clone_submodules $this
return
}
fconfigure $fd_ph -blocking 0
--
1.7.9.3.369.gd715.dirty
--
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: Re: [PATCH] submodule : Add --no-separate-git-dir option to add and update command.
Le mardi 11 mars 2014 à 21:11 +0100, Heiko Voigt a écrit : On Tue, Mar 11, 2014 at 10:55:03AM +0100, Henri GEIST wrote: Le lundi 10 mars 2014 à 21:32 +0100, Heiko Voigt a écrit : On Mon, Mar 10, 2014 at 10:08:06AM +0100, Henri GEIST wrote: Le samedi 08 mars 2014 à 00:00 +0100, Jens Lehmann a écrit : Am 06.03.2014 23:20, schrieb Henri GEIST: What is the use case you are trying to solve and why can that not be handled by adding subsubmodule inside submodule? The problem is access rights. Imagine you have 2 people Pierre and Paul. Each with different access write on the server. Pierre has full access on every things. Paul has full access on superproject and subsubmodule but no read/write access to submodule only execution on the directory. Ok, I think I'm slowly beginning to understand your setup. I want all user to get every things they are allowed to have with the command 'git submodule update --init --recursive'. Then as Paul can not clone submodule he can not get subsubmodule recursively through it. Sure, that's how it should work. Paul could only work on a branch where submodule is an empty directory containing subsubmodule, as he doesn't have the rights to clone submodule. I will not redundantly create a branch for each user on the server. When users clone the server it already create a special branch for them 'master' which track 'origin/master'. And if each user have its own branch on the server it will completely defeat the goal of the server collaboration. And transform the git server in simple rsync server. I do not think that is what Jens was suggesting. It does not matter in which branch they work, they can directly use master if you like. What he was suggesting is that they create their repository structure like this: git clone g...@somewhere.net:superproject.git cd superproject/submodule git clone g...@somehwere.net:subsubmodule.git cd subsubmodule ... work, commit, work, commit ... The same applies for the superproject. Now only someone with access to the submodule has to update the registered sha1 once the work is pushed to submodule. I am not sure to understand everything. But if you suggest to clone manually subsubmodule because it could not be clone recursively by submodule due to the lake of access write to get submodule. It is not practical in my use cases. Two of the superprojects I have in charge contains hundreds of submodules or subsubmodules and I have too much users with disparate computer skills. Getting all what a user has access on should be just a recursive clone. Then I would think about getting rid of the recursion part as it seems you have interdependencies which can only be solved by a package management system. I would see the superproject as this package management system, but it requires you to have all the submodules next to each other instead of contained in each other. You put the finger on a key point. I use the submodule system exactly as a package management system. It is even the only use I have of it. I am not able to imagine another use. (My imagination is limited). I really use 'git clone --recursive' as 'apt-get install'. And I am pretty sure you also. And in fact for the case where the submodules/packages should be side by side, I have a third patch witch enable just this by enabling '../' to be part of a gitlink. Much of my submodules/packages make use of this feature but I also have the case where the dependency make them contained in each others. I think in terms of combining libraries that is actually the correct solution because there can be modules that need each other. Some submodule A might evolve and add a dependency to a subsubmodule B that is itself contained in another submodule C. Then it just does not feel correct anymore that B is contained in C. You want to have one instance that is in charge of all the dependencies, that is IMO directly the superproject and not something that reaches through another submodule to record a dependency to a subsubmodule. Right. But each module need to know by its own gitlinks which are its dependency to be able to track version compatibility and not rely on an hypothetic superproject which may or may not do it as a submodule do not even know if it is part of a superproject. And could be include in totally different superprojects. And I need superproject to add also submodule/subsubmodule. No. Never let the same file/directory be tracked by two git repositories at the same time. Give Paul a branch to work on where submodule is just an empty directory, and everything will be fine. Or move subsubmodule outside of submodule (and let a symbolic link point to the new location if the path cannot
Re: [PATCH/RFC] Documentation: Say that submodule clones use a separate gitdirs.
Le dimanche 09 mars 2014 à 19:24 -0400, Andrew Keller a écrit : On Mar 7, 2014, at 7:50 PM, Henri GEIST wrote: Le vendredi 07 mars 2014 à 15:37 -0800, Junio C Hamano a écrit : Henri GEIST geist.he...@laposte.net writes: This information is technical in nature but has some importance for general users. As this kind of clone have a separate gitdir, you will have a surprise if you copy past the worktree as the gitdir will not come together. I am not sure if I understand exactly what you are trying to say. Are you saying that you had a submodule at sub/dir in your working tree, and then mkdir ../another cp -R sub/dir ../another did not result in a usable Git working tree in ../another directory? It is almost like complaining that mkdir ../newone cp -R * ../newone/ did not result in a usable git repository in ../newone directory and honestly speaking, that sounds borderline insane, I'd have to say. Yes, if a user knows what she is doing, she should be able to make something like that work, without running git clone (which is probably the way most users would do it). And yes, it would be good to let the user learn from the documentation enough so that she knows what she is doing. But no, I do not think end-user facing documentation for git-submodule subcommand is the way to do that. That is why I suggested repository-layout as potentially a better alternative location. But perhaps I am mis-reading your rationale. Let me rephrase my example : To give one of my project to someone else I have copied it on a USB key. By a simple drag and drop with the mouse. And I am quite sure I am not alone doing this way. I have done those kind of things lot of time without any problem. But that day 'the_project' happened to be a submodule cloned by 'git submodule update' then on the USB key the $GIT_DIR of 'the_project' was missing. If 'man git-submodule' have made me aware of the particularities of submodules clone I had write in a terminal: git clone the_project /media/usb/the_project Or at least I had understand what happened quicker. I have nothing against also adding something in repository-layout but I am pretty sure normal users never read repository-layout as it is not a command they use. And it is not mentioned in most tutorials. How about something like this: The git directory of a submodule lives inside the git directory of the parent repository instead of within the working directory. I'm not sure where to put it, though. - Andrew Keller 'git directory' seems ambiguous to me. Maybe we could use 'git metadata'. signature.asc Description: This is a digitally signed message part
Re: [PATCH] submodule : Add --no-separate-git-dir option to add and update command.
Le samedi 08 mars 2014 à 00:00 +0100, Jens Lehmann a écrit : Am 06.03.2014 23:20, schrieb Henri GEIST: Le jeudi 06 mars 2014 à 21:51 +0100, Jens Lehmann a écrit : Am 06.03.2014 21:15, schrieb Henri GEIST: Le jeudi 06 mars 2014 à 20:48 +0100, Jens Lehmann a écrit : Am 06.03.2014 02:25, schrieb Henri GEIST: Wow, that shouldn't even work (as everything inside submodule shouldn't be part of the superproject but must be contained in the submodule itself). Do the git submodule script and other git commands like git status work for you in such setups? As I stated above it is the purpose of the other patch that I have not already send to implement this behavior. And that is why it work. Ok. Everything including 'git submodule' and 'git status' work perfectly. The intent of this patch is only to permit this for gitlinks. Not for regular files. But I still believe that this shouldn't be permitted at all, no matter if files or submodules are concerned. The pitfalls files face in such a scenario are pretty much the same for submodules too. May be you have a good argument for this belief ? Sure, I stated it further down: The problem you're creating with your future patch is related to the work tree, not the GIT_DIR: subsubmodule could also be added to and tracked by submodule (as that is completely unaware of subsubmodule already being tracked by the superproject). Then you would end up in real trouble, as superproject and submodule could have differing SHA-1s recorded for subsubmodule. Don't go there, for just the same reasons we do not allow that for files. As for the difference between submodules and regular files the only difference is in the meaning. Technically directory are just a special kind of file. But there day to day use is drastically different of the use of files which are not directories. I am not against enabling it for files as well. I am just unable to imagine a case where it make sens. It doesn't make sense for both files and submodules. A possible solution when someone try to do it is to issue a warning. We are not able to see any good reason to do this are sure (y/n) ? No, the only possible solution I see is not to allow that at all. In this case where should the separate gitdir of subsubmodule be placed ? - In superproject/modules/submodule/subsubmodule ? - In superproject/submodule/modules/subsubmodule ? - Depending on the 'git submodule update' command order ? - Or both ? It should be placed in .git/modules/submodule/modules/subsubmodule of the superproject (assuming the subsubmodule is part of the first level submodule). But in your example that would live in .git/modules/submodule/subsubmodule (but as mentioned above, I do not consider this a valid setup because then two repositories would be responsible for the data inside subsubmodule, which will lead to lots of trouble). That is why a had proposed an option '--no-separate-git-dir' for 'git submodule add|update' then no repository is responsible for the data in subsubmodule except subsubmodule itself. As I mentioned in my other email, it doesn't matter at all for the setup you're describing if the git directory lives under .git/modules of the superproject or in a .git directory in the submodule. The problem you're creating with your future patch is related to the work tree, not the GIT_DIR: subsubmodule could also be added to and tracked by submodule (as that is completely unaware of subsubmodule already being tracked by the superproject). Then you would end up in real trouble, as superproject and submodule could have differing SHA-1s recorded for subsubmodule. Don't go there, for just the same reasons we do not allow that for files. In fact it mater. Because multiples checkout of superproject and submodules in versions where subsubmodule is present and not. subsubmodule could have been clone one time by submodule and one time by superproject. And each would have a different .git directory. Where is the problem with that? Size? Different refs? The problem is having two gitdir for one worktree. with the .git file in the worktree pointing sometime on one and sometime on the other. And then if they are cloned with --separate-gitdir subsubmodule can have two gitdirs in superproject/modules/submodule/subsubmodule and in superproject/submodule/modules/subsubmodule. Only one is active at a given time but they are two and not synchronized. But the synchronization is done via the superproject, no? Only lot of careful manual command by the user could keep them synchronize. But it is big wast of time. For no added value. It is quicker to make subsubmodule a regular clone without a separate gitdir then there is nothing needing a synchronization. What is the use case you are trying to solve and why can that not be handled by adding
Re: [PATCH/RFC] Documentation: Say that submodule clones use a separate gitdirs.
Le lundi 10 mars 2014 à 08:31 -0700, Junio C Hamano a écrit : Andrew Keller and...@kellerfarm.com writes: On Mar 7, 2014, at 7:50 PM, Henri GEIST wrote: ... To give one of my project to someone else I have copied it on a USB key. By a simple drag and drop with the mouse. And I am quite sure I am not alone doing this way. I have done those kind of things lot of time without any problem. But that day 'the_project' happened to be a submodule cloned by 'git submodule update' then on the USB key the $GIT_DIR of 'the_project' was missing. If 'man git-submodule' have made me aware of the particularities of submodules clone I had write in a terminal: git clone the_project /media/usb/the_project Or at least I had understand what happened quicker. I have nothing against also adding something in repository-layout but I am pretty sure normal users never read repository-layout as it is not a command they use. And it is not mentioned in most tutorials. How about something like this: The git directory of a submodule lives inside the git directory of the parent repository instead of within the working directory. I'm not sure where to put it, though. This is not limited to submodules. There are multiple lower-level mechanisms for a $path/.git to borrow the repository data from elsewhere outside of $path and a cloned submodule uses only one of them. For any such $path, cp -R $path $otherplace will result in an $otherplace that does not work as a Git repository in exactly the same way, whether it happens to be a submodule checkout or not. That is why I suggested to enhance description on a more general part of the documentation that covers what a Git repository is. You are entirely right. My view of the situation was biased by the fact that submodule cloning is the only case I am aware of except when the user manually type '--separate-git-dir' where this problem could occur. If there is some other situation where this can occur as a side effect of a git command it can be good to have the user aware of the list or at least inform them in general case a git repository cannot be copied in a place every body will see. Or place a note in the manpage of every git command which can have this side effect. signature.asc Description: This is a digitally signed message part
Re: [PATCH/RFC] Documentation: Say that submodule clones use a separate gitdirs.
Le vendredi 07 mars 2014 à 16:42 -0500, Andrew Keller a écrit : On Mar 7, 2014, at 2:53 AM, Henri GEIST geist.he...@laposte.net wrote: Adding a note in the submodule documentation signaling that the automatically cloned missing submodules are cloned with a separate gitdir. And where it is put. Signed-off-by: Henri GEIST geist.he...@laposte.net --- Documentation/git-submodule.txt |5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt index 21cb59a..ea837fd 100644 --- a/Documentation/git-submodule.txt +++ b/Documentation/git-submodule.txt @@ -64,6 +64,11 @@ using the 'status' subcommand and get a detailed overview of the difference between the index and checkouts using the 'summary' subcommand. +*NOTE*: when submodule add or submodule update commands clone a missing +submodule, the option --separate-git-dir is passed to the clone command +and the gitdir of the submodule is placed outside of its working +directory in the .git/module of the current repository. + The modules directory is 'modules'. And, the '.git' folder is not always called '.git' -- in a submodule, for example, the directory name is the name of the module. Also, this file contains mostly high-level documentation, and this addition feels technical in nature. Is there a location for more technical documentation? Or, perhaps it can be reworded to sound less technical? This information is technical in nature but has some importance for general users. As this kind of clone have a separate gitdir, you will have a surprise if you copy past the worktree as the gitdir will not come together. I have done it and as the doc say nothing about that it take me some time to understand what happened. And why this repository behave differently than others. May be I can rephrase like this : *NOTE*: when 'submodule add' or 'submodule update' commands clone a missing submodule, the $GIT_DIR of the submodule containing the metadata is placed outside of its working directory in the $GIT_DIR/modules of the current repository. Those submodule can not directly be copied or move. You need to use 'git clone'. COMMANDS -- 1.7.9.3.369.gd715.dirty -- - Andrew Keller signature.asc Description: This is a digitally signed message part
Re: [PATCH/RFC] Documentation: Say that submodule clones use a separate gitdirs.
Le vendredi 07 mars 2014 à 15:37 -0800, Junio C Hamano a écrit : Henri GEIST geist.he...@laposte.net writes: This information is technical in nature but has some importance for general users. As this kind of clone have a separate gitdir, you will have a surprise if you copy past the worktree as the gitdir will not come together. I am not sure if I understand exactly what you are trying to say. Are you saying that you had a submodule at sub/dir in your working tree, and then mkdir ../another cp -R sub/dir ../another did not result in a usable Git working tree in ../another directory? It is almost like complaining that mkdir ../newone cp -R * ../newone/ did not result in a usable git repository in ../newone directory and honestly speaking, that sounds borderline insane, I'd have to say. Yes, if a user knows what she is doing, she should be able to make something like that work, without running git clone (which is probably the way most users would do it). And yes, it would be good to let the user learn from the documentation enough so that she knows what she is doing. But no, I do not think end-user facing documentation for git-submodule subcommand is the way to do that. That is why I suggested repository-layout as potentially a better alternative location. But perhaps I am mis-reading your rationale. Let me rephrase my example : To give one of my project to someone else I have copied it on a USB key. By a simple drag and drop with the mouse. And I am quite sure I am not alone doing this way. I have done those kind of things lot of time without any problem. But that day 'the_project' happened to be a submodule cloned by 'git submodule update' then on the USB key the $GIT_DIR of 'the_project' was missing. If 'man git-submodule' have made me aware of the particularities of submodules clone I had write in a terminal: git clone the_project /media/usb/the_project Or at least I had understand what happened quicker. I have nothing against also adding something in repository-layout but I am pretty sure normal users never read repository-layout as it is not a command they use. And it is not mentioned in most tutorials. signature.asc Description: This is a digitally signed message part
Re: [PATCH] submodule : Add --no-separate-git-dir option to add and update command.
Le jeudi 06 mars 2014 à 20:48 +0100, Jens Lehmann a écrit : Am 06.03.2014 02:25, schrieb Henri GEIST: Le mercredi 05 mars 2014 à 19:13 +0100, Jens Lehmann a écrit : Am 03.03.2014 21:34, schrieb Henri GEIST: Le lundi 03 mars 2014 à 17:45 +, Jens Lehmann a écrit : Am 03.03.2014 14:47, schrieb Henri GEIST: This new option prevent git submodule add|update to clone the missing submodules with the --separate-git-dir option. Then the submodule will be regular repository and their gitdir will not be placed in the superproject gitdir/modules directory. And what is your motivation for this? After all submodules containing a .git directory are second class citizens (because they can never be safely removed by regular git commands). I recognize most people will prefer to have the .git directory separate. And I do not intend to make this option the default. My reasons are: - As it is not clearly stated in the doc that the gitdir is separate. The first time I have copied one module to an USB key I had a big surprise. Oops! Could you please help us by hinting how the documentation could be improved here? Of course. There is nothing in Documentation/git-submodule.txt to inform that submodules clones are different from regular clones. I will write and propose a patch for the documentation. But maybe in a new thread. Thanks! - This will not change anything for people not using it. I do not agree, as they'll be seeing a new option and might use it to go backward as Junio explained in his answer. - I use an other patch which I plane to send later which enable multiple level of superproject to add a gitlink to the same submodule. And in this case the superproject containing the separate gitdir will be arbitrary and depend on the processing order of the 'git submodule update --recursive' command. I don't understand that. How is that different from using different names (and thus different separate gitdirs) for that duplicated submodule? After all, the .git directory is just moved somewhere else in the superproject's work tree, and as the name defaults to the path of the submodule ... I think I should give an example. If I have a hierarchy like this : superproject/submodule/subsubmodule What I often do is: superproject -- submodule -- subsubmodule | ^ '-' Where '--' is a gitlink. That mean .gitmodules and index of the superproject contain both submodule and submodule/subsubmodule. Wow, that shouldn't even work (as everything inside submodule shouldn't be part of the superproject but must be contained in the submodule itself). Do the git submodule script and other git commands like git status work for you in such setups? As I stated above it is the purpose of the other patch that I have not already send to implement this behavior. And that is why it work. Everything including 'git submodule' and 'git status' work perfectly. The intent of this patch is only to permit this for gitlinks. Not for regular files. and also mean (and that is the point) subsubmodule is a direct 'child' of both superproject and submodule. Which I think should not be possible. If that works with current Git I suspect we have a bug to fix ... or does your other patch make this work? You have no bug on this point without my modification this is not possible. In this case where should the separate gitdir of subsubmodule be placed ? - In superproject/modules/submodule/subsubmodule ? - In superproject/submodule/modules/subsubmodule ? - Depending on the 'git submodule update' command order ? - Or both ? It should be placed in .git/modules/submodule/modules/subsubmodule of the superproject (assuming the subsubmodule is part of the first level submodule). But in your example that would live in .git/modules/submodule/subsubmodule (but as mentioned above, I do not consider this a valid setup because then two repositories would be responsible for the data inside subsubmodule, which will lead to lots of trouble). That is why a had proposed an option '--no-separate-git-dir' for 'git submodule add|update' then no repository is responsible for the data in subsubmodule except subsubmodule itself. signature.asc Description: This is a digitally signed message part
Re: [PATCH] submodule : Add --no-separate-git-dir option to add and update command.
Le jeudi 06 mars 2014 à 21:51 +0100, Jens Lehmann a écrit : Am 06.03.2014 21:15, schrieb Henri GEIST: Le jeudi 06 mars 2014 à 20:48 +0100, Jens Lehmann a écrit : Am 06.03.2014 02:25, schrieb Henri GEIST: Le mercredi 05 mars 2014 à 19:13 +0100, Jens Lehmann a écrit : Am 03.03.2014 21:34, schrieb Henri GEIST: - I use an other patch which I plane to send later which enable multiple level of superproject to add a gitlink to the same submodule. And in this case the superproject containing the separate gitdir will be arbitrary and depend on the processing order of the 'git submodule update --recursive' command. I don't understand that. How is that different from using different names (and thus different separate gitdirs) for that duplicated submodule? After all, the .git directory is just moved somewhere else in the superproject's work tree, and as the name defaults to the path of the submodule ... I think I should give an example. If I have a hierarchy like this : superproject/submodule/subsubmodule What I often do is: superproject -- submodule -- subsubmodule | ^ '-' Where '--' is a gitlink. That mean .gitmodules and index of the superproject contain both submodule and submodule/subsubmodule. Wow, that shouldn't even work (as everything inside submodule shouldn't be part of the superproject but must be contained in the submodule itself). Do the git submodule script and other git commands like git status work for you in such setups? As I stated above it is the purpose of the other patch that I have not already send to implement this behavior. And that is why it work. Ok. Everything including 'git submodule' and 'git status' work perfectly. The intent of this patch is only to permit this for gitlinks. Not for regular files. But I still believe that this shouldn't be permitted at all, no matter if files or submodules are concerned. The pitfalls files face in such a scenario are pretty much the same for submodules too. May be you have a good argument for this belief ? As for the difference between submodules and regular files the only difference is in the meaning. Technically directory are just a special kind of file. But there day to day use is drastically different of the use of files which are not directories. I am not against enabling it for files as well. I am just unable to imagine a case where it make sens. A possible solution when someone try to do it is to issue a warning. We are not able to see any good reason to do this are sure (y/n) ? and also mean (and that is the point) subsubmodule is a direct 'child' of both superproject and submodule. Which I think should not be possible. If that works with current Git I suspect we have a bug to fix ... or does your other patch make this work? You have no bug on this point without my modification this is not possible. Glad to hear that. In this case where should the separate gitdir of subsubmodule be placed ? - In superproject/modules/submodule/subsubmodule ? - In superproject/submodule/modules/subsubmodule ? - Depending on the 'git submodule update' command order ? - Or both ? It should be placed in .git/modules/submodule/modules/subsubmodule of the superproject (assuming the subsubmodule is part of the first level submodule). But in your example that would live in .git/modules/submodule/subsubmodule (but as mentioned above, I do not consider this a valid setup because then two repositories would be responsible for the data inside subsubmodule, which will lead to lots of trouble). That is why a had proposed an option '--no-separate-git-dir' for 'git submodule add|update' then no repository is responsible for the data in subsubmodule except subsubmodule itself. As I mentioned in my other email, it doesn't matter at all for the setup you're describing if the git directory lives under .git/modules of the superproject or in a .git directory in the submodule. The problem you're creating with your future patch is related to the work tree, not the GIT_DIR: subsubmodule could also be added to and tracked by submodule (as that is completely unaware of subsubmodule already being tracked by the superproject). Then you would end up in real trouble, as superproject and submodule could have differing SHA-1s recorded for subsubmodule. Don't go there, for just the same reasons we do not allow that for files. In fact it mater. Because multiples checkout of superproject and submodules in versions where subsubmodule is present and not. subsubmodule could have been clone one time by submodule and one time by superproject. And then if they are cloned with --separate-gitdir subsubmodule can have two gitdirs in superproject/modules/submodule/subsubmodule and in superproject/submodule/modules/subsubmodule. Only
[PATCH/RFC] Documentation: Say that submodule clones use a separate gitdirs.
Adding a note in the submodule documentation signaling that the automatically cloned missing submodules are cloned with a separate gitdir. And where it is put. Signed-off-by: Henri GEIST geist.he...@laposte.net --- Documentation/git-submodule.txt |5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt index 21cb59a..ea837fd 100644 --- a/Documentation/git-submodule.txt +++ b/Documentation/git-submodule.txt @@ -64,6 +64,11 @@ using the 'status' subcommand and get a detailed overview of the difference between the index and checkouts using the 'summary' subcommand. +*NOTE*: when submodule add or submodule update commands clone a missing +submodule, the option --separate-git-dir is passed to the clone command +and the gitdir of the submodule is placed outside of its working +directory in the .git/module of the current repository. + COMMANDS -- 1.7.9.3.369.gd715.dirty -- 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] git-gui: Add a 'recursive' checkbox in the clone menu.
Le mercredi 05 mars 2014 à 19:00 +0100, Jens Lehmann a écrit :
Am 05.03.2014 00:01, schrieb Henri GEIST:
Permit to do a 'git clone --recursive' through git-gui.
I really like where this is heading!
Some minor issues:
- I think we should be more verbose in the commit message,
including that and why the default should be on. Maybe
like this?
Permit to do a 'git clone --recursive' through git-gui.
Add a 'recursive' checkbox in the clone menu which allows
users to clone a repository and all its submodules in one
go (unless the 'update' flag is set to none in the
.gitmodules file for a submodule, in that case that
specific submodule is not cloned automatically).
Enable this new option per default, as most users want to
clone all submodules too when cloning the superproject
(This is currently not possible without leaving git gui
or adding a custom tool entry for that).
Ok for me.
- I'd rather change the button text from Recursive (For
submodules) to something like Recursively clone
submodules too or such.
Perfect
- Wouldn't it be easier to pass the '--recurse-submodules
option to the git clone call for the superproject instead
of adding the _do_clone_submodules() function doing a
subsequent git submodule update --init --recursive? That
is also be more future proof with respect to the autoclone
config option we have in mind (which would add that behavior
for git clone itself, making the call you added redundant).
That is what I planned to do at beginning.
But git-gui never call git clone anywhere.
It make the clone step by step with a long and complicated list of
commands just like a Tcl rewrite of git-clone.
Have a look on the function _do_clone2 in choose_repository.tcl.
As I suspect there should be a good reason for this that I did not
understand I have choose to not refactoring it.
And in fact looking in the code 'git clone --recursive' do nothing
else than calling 'git submodule update --init --recursive' like I
have done to complete this rewrite of 'git-clone'.
Signed-off-by: Henri GEIST geist.he...@laposte.net
---
I have set the default checkbox state to 'true' by default has all my gui
users
use it all the time this way.
But as it change the default behavior you may prefer to set it to 'false' by
default.
git-gui/lib/choose_repository.tcl | 34 --
1 file changed, 32 insertions(+), 2 deletions(-)
diff --git a/git-gui/lib/choose_repository.tcl
b/git-gui/lib/choose_repository.tcl
index 3c10bc6..47d436b 100644
--- a/git-gui/lib/choose_repository.tcl
+++ b/git-gui/lib/choose_repository.tcl
@@ -18,6 +18,7 @@ field local_path {} ; # Where this repository is
locally
field origin_url {} ; # Where we are cloning from
field origin_name origin ; # What we shall call 'origin'
field clone_type hardlink ; # Type of clone to construct
+field recursive true ; # Recursive cloning flag
field readtree_err; # Error output from read-tree (if any)
field sorted_recent ; # recent repositories (sorted)
@@ -525,6 +526,11 @@ method _do_clone {} {
foreach r $w_types {
pack $r -anchor w
}
+ ${NS}::checkbutton $args.type_f.recursive \
+ -text [mc Recursive (For submodules)] \
+ -variable @recursive \
+ -onvalue true -offvalue false
+ pack $args.type_f.recursive
grid $args.type_l $args.type_f -sticky new
grid columnconfigure $args 1 -weight 1
@@ -952,6 +958,30 @@ method _do_clone_checkout {HEAD} {
fileevent $fd readable [cb _readtree_wait $fd]
}
+method _do_validate_submodule_cloning {ok} {
+ if {$ok} {
+ $o_cons done $ok
+ set done 1
+ } else {
+ _clone_failed $this [mc Cannot clone submodules.]
+ }
+}
+
+method _do_clone_submodules {} {
+ if {$recursive eq {true}} {
+ destroy $w_body
+ set o_cons [console::embed \
+ $w_body \
+ [mc Cloning submodules]]
+ pack $w_body -fill both -expand 1 -padx 10
+ $o_cons exec \
+ [list git submodule update --init --recursive] \
+ [cb _do_validate_submodule_cloning]
+ } else {
+ set done 1
+ }
+}
+
method _readtree_wait {fd} {
set buf [read $fd]
$o_cons update_meter $buf
@@ -982,7 +1012,7 @@ method _readtree_wait {fd} {
fconfigure $fd_ph -blocking 0 -translation binary -eofchar {}
fileevent $fd_ph readable [cb _postcheckout_wait $fd_ph]
} else {
- set done 1
+ _do_clone_submodules $this
}
}
@@ -996,7 +1026,7 @@ method _postcheckout_wait {fd_ph} {
hook_failed_popup post-checkout $pch_error 0
}
unset pch_error
- set done
[PATCH/RFC] git-gui: Add a 'recursive' checkbox in the clone menu.
Permit to do a 'git clone --recursive' through git-gui.
Signed-off-by: Henri GEIST geist.he...@laposte.net
---
I have set the default checkbox state to 'true' by default has all my gui users
use it all the time this way.
But as it change the default behavior you may prefer to set it to 'false' by
default.
git-gui/lib/choose_repository.tcl | 34 --
1 file changed, 32 insertions(+), 2 deletions(-)
diff --git a/git-gui/lib/choose_repository.tcl
b/git-gui/lib/choose_repository.tcl
index 3c10bc6..47d436b 100644
--- a/git-gui/lib/choose_repository.tcl
+++ b/git-gui/lib/choose_repository.tcl
@@ -18,6 +18,7 @@ field local_path {} ; # Where this repository is locally
field origin_url {} ; # Where we are cloning from
field origin_name origin ; # What we shall call 'origin'
field clone_type hardlink ; # Type of clone to construct
+field recursive true ; # Recursive cloning flag
field readtree_err; # Error output from read-tree (if any)
field sorted_recent ; # recent repositories (sorted)
@@ -525,6 +526,11 @@ method _do_clone {} {
foreach r $w_types {
pack $r -anchor w
}
+ ${NS}::checkbutton $args.type_f.recursive \
+ -text [mc Recursive (For submodules)] \
+ -variable @recursive \
+ -onvalue true -offvalue false
+ pack $args.type_f.recursive
grid $args.type_l $args.type_f -sticky new
grid columnconfigure $args 1 -weight 1
@@ -952,6 +958,30 @@ method _do_clone_checkout {HEAD} {
fileevent $fd readable [cb _readtree_wait $fd]
}
+method _do_validate_submodule_cloning {ok} {
+ if {$ok} {
+ $o_cons done $ok
+ set done 1
+ } else {
+ _clone_failed $this [mc Cannot clone submodules.]
+ }
+}
+
+method _do_clone_submodules {} {
+ if {$recursive eq {true}} {
+ destroy $w_body
+ set o_cons [console::embed \
+ $w_body \
+ [mc Cloning submodules]]
+ pack $w_body -fill both -expand 1 -padx 10
+ $o_cons exec \
+ [list git submodule update --init --recursive] \
+ [cb _do_validate_submodule_cloning]
+ } else {
+ set done 1
+ }
+}
+
method _readtree_wait {fd} {
set buf [read $fd]
$o_cons update_meter $buf
@@ -982,7 +1012,7 @@ method _readtree_wait {fd} {
fconfigure $fd_ph -blocking 0 -translation binary -eofchar {}
fileevent $fd_ph readable [cb _postcheckout_wait $fd_ph]
} else {
- set done 1
+ _do_clone_submodules $this
}
}
@@ -996,7 +1026,7 @@ method _postcheckout_wait {fd_ph} {
hook_failed_popup post-checkout $pch_error 0
}
unset pch_error
- set done 1
+ _do_clone_submodules $this
return
}
fconfigure $fd_ph -blocking 0
--
1.7.9.3.369.gd715.dirty
signature.asc
Description: This is a digitally signed message part
[PATCH] submodule : Add --no-separate-git-dir option to add and update command.
This new option prevent git submodule add|update to clone the missing submodules with the --separate-git-dir option. Then the submodule will be regular repository and their gitdir will not be placed in the superproject gitdir/modules directory. Signed-off-by: Henri GEIST geist.he...@laposte.net --- Documentation/git-submodule.txt | 18 -- git-submodule.sh| 22 -- t/t7400-submodule-basic.sh | 12 3 files changed, 48 insertions(+), 4 deletions(-) diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt index 21cb59a..303a475 100644 --- a/Documentation/git-submodule.txt +++ b/Documentation/git-submodule.txt @@ -10,13 +10,14 @@ SYNOPSIS [verse] 'git submodule' [--quiet] add [-b branch] [-f|--force] [--name name] - [--reference repository] [--depth depth] [--] repository [path] + [--reference repository] [--depth depth] [--no-separate-git-dir] + [--] repository [path] 'git submodule' [--quiet] status [--cached] [--recursive] [--] [path...] 'git submodule' [--quiet] init [--] [path...] 'git submodule' [--quiet] deinit [-f|--force] [--] path... 'git submodule' [--quiet] update [--init] [--remote] [-N|--no-fetch] [-f|--force] [--rebase|--merge|--checkout] [--reference repository] - [--depth depth] [--recursive] [--] [path...] + [--depth depth] [--recursive] [--no-separate-git-dir] [--] [path...] 'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) n] [commit] [--] [path...] 'git submodule' [--quiet] foreach [--recursive] command @@ -107,6 +108,10 @@ is the superproject and submodule repositories will be kept together in the same relative location, and only the superproject's URL needs to be provided: git-submodule will correctly locate the submodule using the relative URL in .gitmodules. ++ +If `--no-separate-git-dir` is specified, missing submodules will be cloned +has normal git repository without the option `--separate-git-dir` pointing +to the modules directory of the superproject gitdir. status:: Show the status of the submodules. This will print the SHA-1 of the @@ -185,6 +190,10 @@ If the submodule is not yet initialized, and you just want to use the setting as stored in .gitmodules, you can automatically initialize the submodule with the `--init` option. + +If `--no-separate-git-dir` is specified, missing submodules will be cloned +has normal git repository without the option `--separate-git-dir` pointing +to the modules directory of the superproject gitdir. ++ If `--recursive` is specified, this command will recurse into the registered submodules, and update any nested submodules within. + @@ -363,6 +372,11 @@ for linkgit:git-clone[1]'s `--reference` and `--shared` options carefully. clone with a history truncated to the specified number of revisions. See linkgit:git-clone[1] +--no-separate-git-dir:: + This option is valid for add and update commands. Specify that missing + submodules should be clonned as self contain repository without a + separate gitdir placed in the modules directory of the superproject + gitdir. path...:: Paths to submodule(s). When specified this will restrict the command diff --git a/git-submodule.sh b/git-submodule.sh index a33f68d..36eaf31 100755 --- a/git-submodule.sh +++ b/git-submodule.sh @@ -5,11 +5,11 @@ # Copyright (c) 2007 Lars Hjemli dashless=$(basename $0 | sed -e 's/-/ /') -USAGE=[--quiet] add [-b branch] [-f|--force] [--name name] [--reference repository] [--] repository [path] +USAGE=[--quiet] add [-b branch] [-f|--force] [--name name] [--reference repository] [--no-separate-git-dir] [--] repository [path] or: $dashless [--quiet] status [--cached] [--recursive] [--] [path...] or: $dashless [--quiet] init [--] [path...] or: $dashless [--quiet] deinit [-f|--force] [--] path... - or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch] [-f|--force] [--rebase] [--reference repository] [--merge] [--recursive] [--] [path...] + or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch] [-f|--force] [--rebase] [--reference repository] [--merge] [--recursive] [--no-separate-git-dir] [--] [path...] or: $dashless [--quiet] summary [--cached|--files] [--summary-limit n] [commit] [--] [path...] or: $dashless [--quiet] foreach [--recursive] command or: $dashless [--quiet] sync [--recursive] [--] [path...] @@ -36,6 +36,7 @@ update= prefix= custom_name= depth= +noseparategitdir= # The function takes at most 2 arguments. The first argument is the # URL that navigates to the submodule origin repo. When relative, this URL @@ -270,6 +271,17 @@ module_clone() quiet=-q fi + + if test -n $noseparategitdir + then + ( + clear_local_git_env
Re: [PATCH] submodule : Add --no-separate-git-dir option to add and update command.
Le lundi 03 mars 2014 à 17:45 +, Jens Lehmann a écrit : Am 03.03.2014 14:47, schrieb Henri GEIST: This new option prevent git submodule add|update to clone the missing submodules with the --separate-git-dir option. Then the submodule will be regular repository and their gitdir will not be placed in the superproject gitdir/modules directory. And what is your motivation for this? After all submodules containing a .git directory are second class citizens (because they can never be safely removed by regular git commands). I recognize most people will prefer to have the .git directory separate. And I do not intend to make this option the default. My reasons are: - As it is not clearly stated in the doc that the gitdir is separate. The first time I have copied one module to an USB key I had a big surprise. - This will not change anything for people not using it. - I use an other patch which I plane to send later which enable multiple level of superproject to add a gitlink to the same submodule. And in this case the superproject containing the separate gitdir will be arbitrary and depend on the processing order of the 'git submodule update --recursive' command. - I have written this for myself and have using it since 2012 and send it in the hope it could be useful for someone else even if it is only a few people. But if its not the case no problem I will keep using it for myself. Signed-off-by: Henri GEIST geist.he...@laposte.net --- Documentation/git-submodule.txt | 18 -- git-submodule.sh| 22 -- t/t7400-submodule-basic.sh | 12 3 files changed, 48 insertions(+), 4 deletions(-) diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt index 21cb59a..303a475 100644 --- a/Documentation/git-submodule.txt +++ b/Documentation/git-submodule.txt @@ -10,13 +10,14 @@ SYNOPSIS [verse] 'git submodule' [--quiet] add [-b branch] [-f|--force] [--name name] - [--reference repository] [--depth depth] [--] repository [path] + [--reference repository] [--depth depth] [--no-separate-git-dir] + [--] repository [path] 'git submodule' [--quiet] status [--cached] [--recursive] [--] [path...] 'git submodule' [--quiet] init [--] [path...] 'git submodule' [--quiet] deinit [-f|--force] [--] path... 'git submodule' [--quiet] update [--init] [--remote] [-N|--no-fetch] [-f|--force] [--rebase|--merge|--checkout] [--reference repository] - [--depth depth] [--recursive] [--] [path...] + [--depth depth] [--recursive] [--no-separate-git-dir] [--] [path...] 'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) n] [commit] [--] [path...] 'git submodule' [--quiet] foreach [--recursive] command @@ -107,6 +108,10 @@ is the superproject and submodule repositories will be kept together in the same relative location, and only the superproject's URL needs to be provided: git-submodule will correctly locate the submodule using the relative URL in .gitmodules. ++ +If `--no-separate-git-dir` is specified, missing submodules will be cloned +has normal git repository without the option `--separate-git-dir` pointing +to the modules directory of the superproject gitdir. status:: Show the status of the submodules. This will print the SHA-1 of the @@ -185,6 +190,10 @@ If the submodule is not yet initialized, and you just want to use the setting as stored in .gitmodules, you can automatically initialize the submodule with the `--init` option. + +If `--no-separate-git-dir` is specified, missing submodules will be cloned +has normal git repository without the option `--separate-git-dir` pointing +to the modules directory of the superproject gitdir. ++ If `--recursive` is specified, this command will recurse into the registered submodules, and update any nested submodules within. + @@ -363,6 +372,11 @@ for linkgit:git-clone[1]'s `--reference` and `--shared` options carefully. clone with a history truncated to the specified number of revisions. See linkgit:git-clone[1] +--no-separate-git-dir:: + This option is valid for add and update commands. Specify that missing + submodules should be clonned as self contain repository without a + separate gitdir placed in the modules directory of the superproject + gitdir. path...:: Paths to submodule(s). When specified this will restrict the command diff --git a/git-submodule.sh b/git-submodule.sh index a33f68d..36eaf31 100755 --- a/git-submodule.sh +++ b/git-submodule.sh @@ -5,11 +5,11 @@ # Copyright (c) 2007 Lars Hjemli dashless=$(basename $0 | sed -e 's/-/ /') -USAGE=[--quiet] add [-b branch] [-f|--force] [--name name] [--reference repository
