Tight submodule bindings (was: Preferred local submodule branches)
On Wed, Jan 08, 2014 at 10:17:51PM -0800, W. Trevor King wrote: > In another branch of the submodule thread Francesco kicked off, I > mentioned that we could store the preferred local submodule branch on > a per-superbranch level if we used the > .git/modules//config for local overrides [1]. Here's > a patch series that greatly extends my v2 "submodule: Respect > requested branch on all clones" series [2] to also support automatic, > recursive submodule checkouts, as I outlined here [3]. > > [1]: http://article.gmane.org/gmane.comp.version-control.git/240240 > [2]: http://article.gmane.org/gmane.comp.version-control.git/239967 > [3]: http://article.gmane.org/gmane.comp.version-control.git/240192 While mulling over better ways to explain my local-branch idea, I've come up with a more tightly bound model that may help break the silence that has greeted the “Preferred local submodule branches” series ;). That series doesn't have strong options on update mechanics, which leads to wishy-washy exchanges where nobody has a clear mental picture: On Thu, Jan 09, 2014 at 10:40:52PM +0100, Jens Lehmann wrote: > Am 09.01.2014 20:55, schrieb W. Trevor King: > > On Thu, Jan 09, 2014 at 08:23:07PM +0100, Jens Lehmann wrote: > >> Am 09.01.2014 18:32, schrieb W. Trevor King: > when superproject branches are merged (with and without conflicts), > >>> > >>> I don't think this currently does anything to the submodule itself, > >>> and that makes sense to me (use 'submodule update' or my 'submodule > >>> checkout' if you want such effects). We should keep the current logic > >>> for updating the gitlinked $sha. In the case that the > >>> .gitmodule-configured local-branches disagree, we should give the > >>> usual conflict warning (and <<<===>>> markup) and let the user resolve > >>> the conflict in the usual way. > >> > >> For me it makes lots of sense that in recursive checkout mode the > >> merged submodules are already checked out (if possible) right after > >> a superproject merge, making another "submodule update" unnecessary > >> (the whole point of recursive update is to make "submodule update" > >> obsolete, except for "--remote"). > > > > If you force the user to have the configured local-branch checked out > > before a non-checkout operations with checkout side-effects (as we > > currently do for other kinds of dirty trees), I think you'll avoid > > most (all?) of the branch-clobbering problems. > > I'm thinking that a local branch works in two directions: It should > make it easy to follow an upstream branch and also make changes to it > (and publish those) if necessary. But neither local nor upstream > changes take precedence, so the user should either use "merge" or > "rebase" as update strategy or be asked to resolve the conflict > manually when "checkout" is configured and the branches diverged. > Does that make sense? The current series is only weakly bound (you can explicitly call git submodule checkout' to change to the preferred local submodule branch), and the current Git is extremely weakly bound (you have to cd into the submodule and change branches by hand). The following extrapolates the “Preferred local submodule branches” series to a tightly-bound ideal. Gitlinked commit hash - The submodule model revolves around links to commits (“gitlinks”): $ git ls-tree HEAD 100644 blob 189fc359d3dc1ed5019b9834b93f0dfb49c5851f.gitmodules 16 commit fbfa124c29362f180026bf0074630e8bd0ff4550 submod These are effectively switchable trees. The tree referenced by commit fbfa124 is 492781c: $ (cd submod/ && git cat-file commit fbfa124) tree 492781c581d4dec380a61ef5ec69a104de448a74 … If you init the submodule, subsequent checkouts will check out that tree, just like 'git checkout' would do if you'd had a superproject tree like: $ git ls-tree HEAD 100644 blob 189fc359d3dc1ed5019b9834b93f0dfb49c5851f.gitmodules 04 tree 492781c581d4dec380a61ef5ec69a104de448a74submod For folks who treat the submodule as a black box (and do no local development), switchable trees are all they care about. They can easily checkout (or not, with deinit), the submodule tree at a gitlinked hash, and everything is nice and reproducible. The fact that 'submod' is stored as a commit object and not a tree, is just a convenient marker for optional init/deinit/remote-update-integration functionality. Additional metadata, the initial checkout, and syncing down --- However, folks who do local submodule development will care about which submodule commit is responsible for that tree, because that's going to be the base of their local development. They also care about additional out-of-tree information, including the branch that commit is on. For already-initialized submodules, there are existing places in the submodule config to store this configuration: 1. HEAD for the checked-out branch, 2. branch..remote → remo
Git: Question about specific subtree usage
Hi, I have a question about a specific use case for subtrees, but I'm not sure if is really possible (hence my e-mail, because all my tests failed so far...) >From what I have read, subtrees are used mainly to: - Import inside a working git repository, other git repositories... it's a little like a symbolic link pointing to another git repository, but without the burden (it will be the main working git repository that will handle the unified history); - Merge many repositories into a single one (after that, they will be seen as directories linked to the same history); - Conversely, dispatch branches in a single repository, to make them distinct repositories; And now, here is my use case... I have a big project, which contains many components (each one having, for the moment, its own directory and repository): MainLibrary/ MainLibrary-Tests/ Frontend1/ Frontend1-Tests/ Frontend2/ Frontend2-Tests/ MainLibrary contains the heart of the application; all other components are linked to it when compiling. For testing purpose, it must be possible to synchronize each component independently (checking out MainLibrary at a specific tag level, and checking out MainLibrary-Tests at another commit level for instance). This is the important point... Each component must have its own history line, and I must be able to check it out freely and independently from the other components. Here would be my dream... Each component would be managed by a subtree, but ensure that: - Components are not be tied to a same common branch... but I'm not sure if it is possible to manage distinct history lines within a same git history; after creating orphan branches, it becomes impossible to run most operations like "check out"); - Any new developer would need only one basic operation to get the full working material: clone one repo, and it's done (it would be awesome, because in reality, my project is even bigger than my example). It would spare us many scripting operations... - Each component can be checked out at any desired level, and so we get the sources of multiple components simultaneously (so far, using subtrees or submodules, I had always the same trouble: I could only get the sources of one component, which was the last I checked out or activated). Having a big shared history for all components may slow down some operations, but it won't be a big problem for the scope of our project. So... is my use case possible using git-magic? (I hinted subtrees, but maybe there are better ways?) Or must I keep my current methodology (one independant repository per components... so each new developer must clones zillions of things at the right place...) Greetings, Andreas THILLOSEN. -- 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 0/6] Make 'git help everyday' work
From: "Junio C Hamano"
"Philip Oakley" writes:
From: "Junio C Hamano"
I think we already use a nicer way to set up a page alias to keep
old links working than making a copy in Documentation/; please mimic
that if possible.
This was mainly about ensuring that the 'git help' command could
access these extra extra guides that it currently misses. (Tt also
misses the 'user-manual', which isn't a man page, but could have a
link page to guide the seeker of truth between 'git help' and the
actual user-manual)
The only method I can see for that (via help.c) is to get the
filename
format correct. Where you thinking of something else?
I do not have an objection against the creation of giteveryday.txt;
I was questioning the way the original everyday.txt was left behind
to bit-rot. It is good to keep _something_ there, because there may
be old URLs floating around that point at Documentation/everyday.txt,
but the contents of that file does not have to be a stale copy.
Cf. bd4a3d61 (Rename {git- => git}remote-helpers.txt, 2013-01-31)
for how we renamed git-remote-helpers.txt to gitremote-helpers.txt
The commit also highlighted a couple of other places I needed to update
What's the right set of options for format-patch to avoid the bulk
deletions and bulk insertions between the old an new versions? That
commit was amended in situ, so never had the three way
delete/move/create problem.
We have:
everyday.txt (old) -> delete
everyday.txt (new) ->create (<5% similarity)
everyday.txt (old) -> giteveryday.txt (>95% similarity)
It just feels that 400+ lines of complete deletion doesn't need to be in
the summary patch. I have it in my mind that we always end up with the
deletions being listed.
Philip
--
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
Error in documentation for @{-n} in gitrevisions
While discussing the behavior of "git checkout -", I apparently was
confused because the documentation states:
The construct @{-} means the th branch checked out before the
current one.
But experimenting with it, it also takes you back to previously
checkout commits.
git-checkout-at-minus-one :: (master) » git checkout origin/master
Note: checking out 'origin/master'.
HEAD is now at f8b2f0c... two
git-checkout-at-minus-one :: (f8b2f0c) » git checkout -
Switched to branch 'master'
git-checkout-at-minus-one :: (master) » git checkout -
Note: checking out
'f8b2f0c1419d1fe798159c2c2578d2dbe1323148'.
HEAD is now at f8b2f0c... two
Either the documentation is wrong, and should be changed to "th
branch/commit checkout out before the current one", or the behavior of
@{-1} is wrong.
--
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] Fix asciidoc header in pack-heuristics.txt
Create a proper header when formatted as html. Signed-off-by: Thomas Ackermann --- Documentation/technical/pack-heuristics.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/technical/pack-heuristics.txt b/Documentation/technical/pack-heuristics.txt index b7bd951..95a07db 100644 --- a/Documentation/technical/pack-heuristics.txt +++ b/Documentation/technical/pack-heuristics.txt @@ -1,5 +1,5 @@ -Concerning Git's Packing Heuristics -=== +Concerning Git's Packing Heuristics +=== Oh, here's a really stupid question: -- 1.8.5.2.msysgit.0 --- Thomas -- 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 1/2] completion: complete merge-base options
Signed-off-by: John Keeping
---
contrib/completion/git-completion.bash | 6 ++
1 file changed, 6 insertions(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 4fe5ce3..e74d402 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1499,6 +1499,12 @@ _git_mergetool ()
_git_merge_base ()
{
+ case "$cur" in
+ --*)
+ __gitcomp "--octopus --independent --is-ancestor --fork-point"
+ return
+ ;;
+ esac
__gitcomp_nl "$(__git_refs)"
}
--
1.8.5.226.g0d60d77
--
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 2/2] completion: handle --[no-]fork-point options to git-rebase
Signed-off-by: John Keeping --- contrib/completion/git-completion.bash | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index e74d402..3c1a11f 100644 --- a/contrib/completion/git-completion.bash +++ b/contrib/completion/git-completion.bash @@ -1637,7 +1637,7 @@ _git_rebase () --preserve-merges --stat --no-stat --committer-date-is-author-date --ignore-date --ignore-whitespace --whitespace= - --autosquash + --autosquash --fork-point --no-fork-point " return -- 1.8.5.226.g0d60d77 -- 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] Create HTML for technical/http-protocol.txt
- Add to Documentation/Makefile
- Start every TODO with a new line
- Fix indentation error
Signed-off-by: Thomas Ackermann
---
Documentation/Makefile| 1 +
Documentation/technical/http-protocol.txt | 3 +--
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 36c58fc..b4a4c82 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -70,6 +70,7 @@ TECH_DOCS += technical/racy-git
TECH_DOCS += technical/send-pack-pipeline
TECH_DOCS += technical/shallow
TECH_DOCS += technical/trivial-merge
+TECH_DOCS += technical/http-protocol
SP_ARTICLES += $(TECH_DOCS)
SP_ARTICLES += technical/api-index
diff --git a/Documentation/technical/http-protocol.txt
b/Documentation/technical/http-protocol.txt
index d21d77d..c64a5e9 100644
--- a/Documentation/technical/http-protocol.txt
+++ b/Documentation/technical/http-protocol.txt
@@ -332,6 +332,7 @@ server advertises capability "allow-tip-sha1-in-want".
have_list = *PKT-LINE("have" SP id LF)
TODO: Document this further.
+
TODO: Don't use uppercase for variable names below.
The Negotiation Algorithm
@@ -376,10 +377,8 @@ The computation to select the minimal pack proceeds as
follows
Commands MUST appear in the following order, if they appear
at all in the request stream:
-
* want
* have
-
The stream is terminated by a pkt-line flush ("").
A single "want" or "have" command MUST have one hex formatted
--
1.8.5.2.msysgit.0
---
Thomas
--
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
