* Re: [PATCH 0/5] ignore SIG{INT,QUIT} when launching editor
From: Paul Fox @ 2012-12-01 15:48 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano, Krzysztof Mazur
In-Reply-To: <20121130223943.GA27120@sigill.intra.peff.net>
jeff wrote:
> This is a re-roll of the pf/editor-ignore-sigint series.
>
> There are two changes from the original:
>
> 1. We ignore both SIGINT and SIGQUIT for "least surprise" compared to
> system(3).
>
> 2. We now use "code + 128" to look for signal death (instead of
> WTERMSIG), as per run-command's documentation on how it munges the
> code.
this series all looks good to me. thanks for re- and re-re-rolling.
paul
>
> People mentioned some buggy editors which go into an infinite EIO loop
> when their parent dies due to SIGQUIT. That should be a non-issue now,
> as we will be ignoring SIGQUIT. And even if you could replicate it
> (e.g., with another signal) those programs should be (and reportedly
> have been) fixed. It is not git's job to babysit its child processes.
>
> The patches are:
>
> [1/5]: run-command: drop silent_exec_failure arg from wait_or_whine
> [2/5]: launch_editor: refactor to use start/finish_command
> [3/5]: launch_editor: ignore terminal signals while editor has control
> [4/5]: run-command: do not warn about child death from terminal
> [5/5]: launch_editor: propagate signals from editor to git
>
> Since this can be thought of as "act more like system(3)", I wondered
> whether the signal-ignore logic should be moved into run-command, or
> even used by default for blocking calls to run_command (which are
> basically our version of system(3)). But it is detrimental in the common
> case that the child is not taking control of the terminal, and is just
> an implementation detail (e.g., we call "git update-ref" behind the
> scenes, but the user does not know or care). If they hit ^C during such
> a run and we are ignoring SIGINT, then either:
>
> 1. we will notice the child died by signal and report an
> error in the subprocess rather than just dying; the end result is
> similar, but the error is unnecessarily confusing
>
> 2. we do not bother to check the child's return code (because we do
> not care whether the child succeeded or not, like a "gc --auto");
> we end up totally ignoring the user's request to abort the
> operation
>
> So I do not think we care about this behavior except for launching the
> editor. And the signal-propagation behavior of 5/5 is really so weirdly
> editor-specific (because it is about behaving well whether the child
> blocks signals or not).
>
> -Peff
=---------------------
paul fox, pgf@foxharp.boston.ma.us (arlington, ma, where it's 24.8 degrees)
^ permalink raw reply
* Re: [RFC] remove/deprecate 'submodule init' and 'sync'
From: Jens Lehmann @ 2012-12-01 15:56 UTC (permalink / raw)
To: Phil Hord
Cc: W. Trevor King, Git, Heiko Voigt, Junio C Hamano, Jeff King,
Shawn Pearce, Nahor
In-Reply-To: <CABURp0qNBcFnxbvhn7PsKWLUOsTiK4u5vx-=6cG3JQHw9aUeHA@mail.gmail.com>
Am 01.12.2012 00:52, schrieb Phil Hord:
> If I never 'submodule init' a submodule, it does not get visited by
> 'git submodule foreach', among others. I think some people use this
> behavior explicitly.
>
> On the other hand, I've also notice that a submodule which I have
> removed does not get de-inited later one. It causes my 'git submodule
> foreach' to emit errors. :-(
I'm currently hacking on "git submodule deinit" which removes the 'url'
setting from git/config. This should do the trick for you, right?
Just removing that submodule automagically would not work that well, as
it would deinitialize a submodule when you switch to a branch where it
isn't present and you'd have to reinitialize it when you come back.
^ permalink raw reply
* Inconsistency in messages about --set-upstream from git pull and git branch
From: Dan Rosén @ 2012-12-01 15:36 UTC (permalink / raw)
To: git
I added a new origin to a repository and did git pull and got this message:
* [new branch] master -> origin/master
There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details
git pull <remote> <branch>
If you wish to set tracking information for this branch you can do so with:
git branch --set-upstream master origin/<branch>
I followed the instructions:
$ git branch --set-upstream master origin/master
The --set-upstream flag is deprecated and will be removed. Consider
using --track or --set-upstream-to
Branch master set up to track remote branch master from origin.
I was using git version 1.8.0 precompiled for Arch Linux.
I tried to find an issue tracker but perhaps it is appropriate to
report this inconsistency to this mailing list.
Best,
Dan
^ permalink raw reply
* Re: [RFC] remove/deprecate 'submodule init' and 'sync'
From: W. Trevor King @ 2012-12-01 16:30 UTC (permalink / raw)
To: Jens Lehmann
Cc: Phil Hord, Git, Heiko Voigt, Junio C Hamano, Jeff King,
Shawn Pearce, Nahor
In-Reply-To: <50BA245A.5000702@web.de>
[-- Attachment #1: Type: text/plain, Size: 3387 bytes --]
On Sat, Dec 01, 2012 at 04:38:02PM +0100, Jens Lehmann wrote:
> Am 30.11.2012 18:53, schrieb W. Trevor King:
> > In my v5 patch, I check for submodule.<name>.remote first in the usual
> > `git config` files. If I don't find what I'm looking for I fall back
> > on .gitmodules (basically Jens' suggestion). However, my initial
> > copying-to-.git/config approach was mostly done to mimic existing
> > configuration handling in git-submodule.sh. Since I agree with Jens
> > on configuration precendence, and I now had two options to read
> > (.branch and .remote), I thought I'd pull the logic out into its own
> > function (code included at the end). While I was shifting the
> > existing submodule config handling over to my new function, I noticed
> > that with this logic, `submodule init` doesn't really do anything
> > important anymore. Likewise for `submodule sync`, which seems to be
> > quite similar to `init`.
>
> You need to handle the 'url' setting differently. While I think the
> 'update' setting should not be copied into .git/config at all
> (because it makes it impossible for upstream to change that later
> without the user copying that himself as 'sync' doesn't do that) the
> 'url' setting in .git/config has two important implications:
>
> 1) It tells the submodule commands that the user wants to have that
> submodule populated (which is done in a subsequent "update" after
> "init" copied the url there).
Good point, but this should depend on submodule.<name>.update; having
it as a side effect of a local submodule.<name>.url makes no sense.
Perhaps `submodule init` should be reduced to just wrap:
$ git config submodule.<name>.update checkout
where the default update configuration would be 'none'.
> 2) It can be used to follow moving upstreams (think of checking out
> an earlier commit before the upstream was moved, you won't be able
> to clone it from there without having the new setting persist).
> And which repository you follow is a matter of trust, so the extra
> "git submodule sync" in that case is a good thing to have.
>
> So I believe 'url' is the only setting that should be copied into
> .git/config while all the others shouldn't.
If you want to override the old repository location for an old commit,
setting submodule.<name>.url makes sense. My rewritten `sync` updates
the local submodule.<name>.url in the superproject if the
configuration option is already set [1]. Perhaps a `sync --local`
invocation should forcibly populate the local submodule.<name>.url to
make this workflow easier. Bundling sugar for this special case
should not happen under an extra command called `init`.
> > [snip get_submodule_config()]
>
> Something like that makes sense. You can use it for the settings you add
> first and we can then reuse that for 'update' in a separate patch later.
I'm currently working out the details independently against v1.8.0.
This will be a fairly major shift, so I think it should stay
independent of `update --remote`. The `update --remote` stuff should
be easy to adjust/rebase if the `init` removal/adjustment develops
into something acceptable.
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [RFC] remove/deprecate 'submodule init' and 'sync'
From: W. Trevor King @ 2012-12-01 16:37 UTC (permalink / raw)
To: Jens Lehmann
Cc: Phil Hord, Git, Heiko Voigt, Junio C Hamano, Jeff King,
Shawn Pearce, Nahor
In-Reply-To: <50BA2892.7060706@web.de>
[-- Attachment #1: Type: text/plain, Size: 1250 bytes --]
On Sat, Dec 01, 2012 at 04:56:02PM +0100, Jens Lehmann wrote:
> Am 01.12.2012 00:52, schrieb Phil Hord:
> > If I never 'submodule init' a submodule, it does not get visited by
> > 'git submodule foreach', among others. I think some people use this
> > behavior explicitly.
> >
> > On the other hand, I've also notice that a submodule which I have
> > removed does not get de-inited later one. It causes my 'git submodule
> > foreach' to emit errors. :-(
>
> I'm currently hacking on "git submodule deinit" which removes the 'url'
> setting from git/config. This should do the trick for you, right?
>
> Just removing that submodule automagically would not work that well, as
> it would deinitialize a submodule when you switch to a branch where it
> isn't present and you'd have to reinitialize it when you come back.
I think this is another case where we should be looping through
submodules based on the revision-specific .gitmodules content, and
querying the local config only to determine if the user wants to
update them (to drop into them with foreach, etc.).
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH] submodule: add 'deinit' command
From: Jens Lehmann @ 2012-12-01 16:45 UTC (permalink / raw)
To: Phil Hord
Cc: W. Trevor King, Git, Heiko Voigt, Junio C Hamano, Jeff King,
Shawn Pearce, Nahor
In-Reply-To: <50BA2892.7060706@web.de>
With "git submodule init" the user is able to tell git he cares about one
or more submodules and wants to have it populated on the next call to "git
submodule update". But currently there is no easy way he could tell git he
does not care about a submodule anymore and wants to get rid of his local
work tree (except he knows a lot about submodule internals and removes the
"submodule.$name.url" setting from .git/config himself).
Help those users by providing a 'deinit' command. This removes the url
setting from .git/config either for the given submodule(s) or for all
those which have been initialized if none were given. Complain only when
for a submodule given on the command line the url setting can't be found
in .git/config.
Add tests and link the man pages of "git submodule deinit" and "git rm" to
assist the user in deciding whether removing or unregistering the submodule
is the right thing to do for him.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
Am 01.12.2012 16:56, schrieb Jens Lehmann:
> Am 01.12.2012 00:52, schrieb Phil Hord:
>> If I never 'submodule init' a submodule, it does not get visited by
>> 'git submodule foreach', among others. I think some people use this
>> behavior explicitly.
>>
>> On the other hand, I've also notice that a submodule which I have
>> removed does not get de-inited later one. It causes my 'git submodule
>> foreach' to emit errors. :-(
>
> I'm currently hacking on "git submodule deinit" which removes the 'url'
> setting from git/config. This should do the trick for you, right?
And here we go ...
Documentation/git-rm.txt | 4 ++++
Documentation/git-submodule.txt | 11 +++++++++
git-submodule.sh | 50 ++++++++++++++++++++++++++++++++++++++++-
t/t7400-submodule-basic.sh | 11 +++++++++
4 files changed, 75 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt
index 262436b..ec42bf5 100644
--- a/Documentation/git-rm.txt
+++ b/Documentation/git-rm.txt
@@ -149,6 +149,10 @@ files that aren't ignored are present in the submodules work tree.
Ignored files are deemed expendable and won't stop a submodule's work
tree from being removed.
+If you only want to remove the local checkout of a submodule from your
+work tree without committing that use `git submodule deinit` instead
+(see linkgit:git-submodule[1]).
+
EXAMPLES
--------
`git rm Documentation/\*.txt`::
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index b1de3ba..fba77f6 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -13,6 +13,7 @@ SYNOPSIS
[--reference <repository>] [--] <repository> [<path>]
'git submodule' [--quiet] status [--cached] [--recursive] [--] [<path>...]
'git submodule' [--quiet] init [--] [<path>...]
+'git submodule' [--quiet] deinit [--] [<path>...]
'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--rebase]
[--reference <repository>] [--merge] [--recursive] [--] [<path>...]
'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) <n>]
@@ -134,6 +135,16 @@ init::
the explicit 'init' step if you do not intend to customize
any submodule locations.
+deinit::
+ Unregister the submodules, i.e. remove the `submodule.$name.url`
+ setting from .git/config. Further calls to `git submodule update`,
+ `git submodule foreach` and `git submodule sync` will skip any
+ unregistered submodules until they are initialized again, so use
+ this command if you don't want to have a local checkout of the
+ submodule in your work tree anymore. If you really want to remove
+ a submodule from the repository and commit that use
+ linkgit:git-rm[1] instead.
+
update::
Update the registered submodules, i.e. clone missing submodules and
checkout the commit specified in the index of the containing repository.
diff --git a/git-submodule.sh b/git-submodule.sh
index 2365149..4059a2e 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -8,6 +8,7 @@ dashless=$(basename "$0" | sed -e 's/-/ /')
USAGE="[--quiet] add [-b <branch>] [-f|--force] [--name <name>] [--reference <repository>] [--] <repository> [<path>]
or: $dashless [--quiet] status [--cached] [--recursive] [--] [<path>...]
or: $dashless [--quiet] init [--] [<path>...]
+ or: $dashless [--quiet] deinit [--] [<path>...]
or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force] [--rebase] [--reference <repository>] [--merge] [--recursive] [--] [<path>...]
or: $dashless [--quiet] summary [--cached|--files] [--summary-limit <n>] [commit] [--] [<path>...]
or: $dashless [--quiet] foreach [--recursive] <command>
@@ -516,6 +517,53 @@ cmd_init()
}
#
+# Unregister submodules from .git/config
+#
+# $@ = requested paths (default to all)
+#
+cmd_deinit()
+{
+ # parse $args after "submodule ... init".
+ while test $# -ne 0
+ do
+ case "$1" in
+ -q|--quiet)
+ GIT_QUIET=1
+ ;;
+ --)
+ shift
+ break
+ ;;
+ -*)
+ usage
+ ;;
+ *)
+ break
+ ;;
+ esac
+ shift
+ done
+
+ module_list "$@" |
+ while read mode sha1 stage sm_path
+ do
+ die_if_unmatched "$mode"
+ name=$(module_name "$sm_path") || exit
+ url=$(git config submodule."$name".url)
+ if test -z "$url"
+ then
+ # Only mention uninitialized submodules when its
+ # path have been specified
+ test "$#" != "0" &&
+ say "$(eval_gettext "No url found for submodule path '\$sm_path' in .git/config")"
+ continue
+ fi
+ git config --unset submodule."$name".url &&
+ say "$(eval_gettext "Submodule '\$name' (\$url) unregistered")"
+ done
+}
+
+#
# Update each submodule path to correct revision, using clone and checkout as needed
#
# $@ = requested paths (default to all)
@@ -1108,7 +1156,7 @@ cmd_sync()
while test $# != 0 && test -z "$command"
do
case "$1" in
- add | foreach | init | update | status | summary | sync)
+ add | foreach | init | deinit | update | status | summary | sync)
command=$1
;;
-q|--quiet)
diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
index de7d453..803bda7 100755
--- a/t/t7400-submodule-basic.sh
+++ b/t/t7400-submodule-basic.sh
@@ -756,4 +756,15 @@ test_expect_success 'submodule add with an existing name fails unless forced' '
)
'
+test_expect_success 'submodule deinit should unregister submodule url from .git/config' '
+ url=$(git config submodule.example.url) &&
+ git submodule deinit &&
+ test -z "$(git config submodule.example.url)"
+'
+
+test_expect_success 'submodule deinit complains only when explicitly used on an uninitialized submodule' '
+ git submodule deinit &&
+ test_must_fail git submodule deinit example
+'
+
test_done
--
1.7.11.7
^ permalink raw reply related
* Re: [RFC] remove/deprecate 'submodule init' and 'sync'
From: W. Trevor King @ 2012-12-01 16:54 UTC (permalink / raw)
To: Jens Lehmann, Phil Hord
Cc: Git, Heiko Voigt, Junio C Hamano, Jeff King, Shawn Pearce, Nahor
In-Reply-To: <20121130175309.GA718@odin.tremily.us>
[-- Attachment #1: Type: text/plain, Size: 1522 bytes --]
I'm currently stuck with adding a commit-less existing repository as a
submodule (which happens in t7400-submodule-basic.sh, ../bar/a/b/c
works with relative local path):
$ mkdir -p super/sub
$ cd super
$ git init
$ (cd sub && git init)
$ git submodule add ./ sub
$ git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git rm --cached <file>..." to unstage)
#
# new file: .gitmodules
#
What I'm missing is a gitlink form sub for 'Subproject commit
00000...' or some such. When the subproject has an actual commit,
things work as expected:
$ mkdir -p super/sub
$ cd super
$ git init
$ (cd sub && git init && echo line-1 > file && git add file && git commit -m file)
$ git submodule add ./ sub
$ git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git rm --cached <file>..." to unstage)
#
# new file: .gitmodules
# new file: sub
#
This means that module_list isn't aware of the empty submodule, when
the user has just explicitly added it. Fixing this would seem to need
either 'Subproject commit 00000...' as I suggested earlier, or an
adjustment to module_list that also spits out submodules that are in
.gitmodules but not in the index.
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [RFC] remove/deprecate 'submodule init' and 'sync'
From: Jens Lehmann @ 2012-12-01 17:25 UTC (permalink / raw)
To: W. Trevor King
Cc: Phil Hord, Git, Heiko Voigt, Junio C Hamano, Jeff King,
Shawn Pearce, Nahor
In-Reply-To: <20121201163004.GB4823@odin.tremily.us>
Am 01.12.2012 17:30, schrieb W. Trevor King:
> On Sat, Dec 01, 2012 at 04:38:02PM +0100, Jens Lehmann wrote:
>> You need to handle the 'url' setting differently. While I think the 'update' setting should not be copied into .git/config at all (because it makes it impossible for upstream to change that later without the user copying that himself as 'sync' doesn't do that) the 'url' setting in .git/config has two important implications:
>>
>> 1) It tells the submodule commands that the user wants to have that submodule populated (which is done in a subsequent "update" after "init" copied the url there).
>
> Good point, but this should depend on submodule.<name>.update; having it as a side effect of a local submodule.<name>.url makes no sense.
Sorry, but that makes tons of sense: url controls if the submodule
is to be populated and from where, update controls how (and can even
veto populating it if set to "none"). We /could/ do it differently,
but I can't see why we should (and risk severe compatibility issues).
> Perhaps `submodule init` should be reduced to just wrap:
>
> $ git config submodule.<name>.update checkout
>
> where the default update configuration would be 'none'.
>
>> 2) It can be used to follow moving upstreams (think of checking out an earlier commit before the upstream was moved, you won't be able to clone it from there without having the new setting persist). And which repository you follow is a matter of trust, so the extra "git submodule sync" in that case is a good thing to have.
>>
>> So I believe 'url' is the only setting that should be copied into .git/config while all the others shouldn't.
>
> If you want to override the old repository location for an old commit, setting submodule.<name>.url makes sense. My rewritten `sync` updates the local submodule.<name>.url in the superproject if the configuration option is already set [1]. Perhaps a `sync --local` invocation should forcibly populate the local submodule.<name>.url to make this workflow easier. Bundling sugar for this special case should not happen under an extra command called `init`.
What real world problems do we have with the current init/sync that
this approach would solve?
>>> [snip get_submodule_config()]
>>
>> Something like that makes sense. You can use it for the settings you add first and we can then reuse that for 'update' in a separate patch later.
>
> I'm currently working out the details independently against v1.8.0. This will be a fairly major shift, so I think it should stay independent of `update --remote`. The `update --remote` stuff should be easy to adjust/rebase if the `init` removal/adjustment develops into something acceptable.
I totally agree. Let's get the `update --remote` stuff ready first.
^ permalink raw reply
* Re: [PATCH/RFC 1/5] mingw: make fgetc raise SIGINT if apropriate
From: Jeff King @ 2012-12-01 17:39 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: Johannes Schindelin, git, msysgit
In-Reply-To: <CABPQNSZaaZsfcC6dHDEhYUDpX4doQC7H=1VHGHuqfU4+m31jkA@mail.gmail.com>
On Sat, Dec 01, 2012 at 01:31:23PM +0100, Erik Faye-Lund wrote:
> >> One thing you might want to mention is that the fgetc() handling is not
> >> thread-safe, and intentionally so: if two threads read from the same
> >> console, we are in trouble anyway.
> >
> > That makes sense to me, but I'm confused why it is part of mingw_fgetc,
> > which could in theory read from arbitrary streams, no? It it is not
> > necessarily a console operation at all. I feel like I'm probably missing
> > something subtle here...
>
> I did add an early out for the non-console cases. Is this what you're
> missing, perhaps?
Oops, yes. That is exactly what I was missing. :)
Sorry for the noise.
-Peff
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply
* Re: [RFC] remove/deprecate 'submodule init' and 'sync'
From: W. Trevor King @ 2012-12-01 17:49 UTC (permalink / raw)
To: Jens Lehmann
Cc: Phil Hord, Git, Heiko Voigt, Junio C Hamano, Jeff King,
Shawn Pearce, Nahor
In-Reply-To: <50BA3D7D.8040707@web.de>
[-- Attachment #1: Type: text/plain, Size: 3824 bytes --]
On Sat, Dec 01, 2012 at 06:25:17PM +0100, Jens Lehmann wrote:
> Am 01.12.2012 17:30, schrieb W. Trevor King:
> > On Sat, Dec 01, 2012 at 04:38:02PM +0100, Jens Lehmann wrote:
> > > 1) It tells the submodule commands that the user wants to have
> > > that submodule populated (which is done in a subsequent "update"
> > > after "init" copied the url there).
> >
> > Good point, but this should depend on submodule.<name>.update;
> > having it as a side effect of a local submodule.<name>.url makes
> > no sense.
>
> Sorry, but that makes tons of sense: url controls if the submodule
> is to be populated and from where, update controls how (and can even
> veto populating it if set to "none"). We /could/ do it differently,
> but I can't see why we should (and risk severe compatibility issues).
I think removing `init` will cause some compatibility issues anyway,
so I was re-imaging how you do it. I don't think update='none' and
"don't populate my submodule" are distinct ideas, while a locally
configured url="somwhere" and "please populate my submodule" are (with
the blank-url case defaulting to the superproject itself).
> > > 2) It can be used to follow moving upstreams (think of checking
> > > out an earlier commit before the upstream was moved, you won't
> > > be able to clone it from there without having the new setting
> > > persist). And which repository you follow is a matter of trust,
> > > so the extra "git submodule sync" in that case is a good thing
> > > to have.
> > >
> > > So I believe 'url' is the only setting that should be copied
> > > into .git/config while all the others shouldn't.
> >
> > If you want to override the old repository location for an old
> > commit, setting submodule.<name>.url makes sense. My rewritten
> > `sync` updates the local submodule.<name>.url in the superproject
> > if the configuration option is already set [1]. Perhaps a `sync
> > --local` invocation should forcibly populate the local
> > submodule.<name>.url to make this workflow easier. Bundling sugar
> > for this special case should not happen under an extra command
> > called `init`.
>
> What real world problems do we have with the current init/sync that
> this approach would solve?
I don't have any, but in my `update --remote` series I'm adding two
new config options that are handled differently (define in
.gitmodules, override in superproject .git/config) than existing
submodules options. I'm trying to avoid confusing users by
standardizing on the more flexible method, which avoids copying stuff
into the superproject's .git/config, and under which the current
`init` functionality doesn't make much sense.
> > > > [snip get_submodule_config()]
> > >
> > > Something like that makes sense. You can use it for the settings
> > > you add first and we can then reuse that for 'update' in a
> > > separate patch later.
> >
> > I'm currently working out the details independently against
> > v1.8.0. This will be a fairly major shift, so I think it should
> > stay independent of `update --remote`. The `update --remote`
> > stuff should be easy to adjust/rebase if the `init`
> > removal/adjustment develops into something acceptable.
>
> I totally agree. Let's get the `update --remote` stuff ready first.
Ok, but we'll have the possible confusion about option setting that I
mention above. Still, it's good to minimize the number of irons in
the fire, and an `init` removal will probably not get in until 2.0
anyway. If other people are fine with the different initialization
paths, I'll put the init-removal on hold for now.
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [RFC] remove/deprecate 'submodule init' and 'sync'
From: Jens Lehmann @ 2012-12-01 18:04 UTC (permalink / raw)
To: W. Trevor King
Cc: Phil Hord, Git, Heiko Voigt, Junio C Hamano, Jeff King,
Shawn Pearce, Nahor
In-Reply-To: <20121201174920.GE4823@odin.tremily.us>
Am 01.12.2012 18:49, schrieb W. Trevor King:
> I think removing `init` will cause some compatibility issues anyway,
> so I was re-imaging how you do it. I don't think update='none' and
> "don't populate my submodule" are distinct ideas, while a locally
> configured url="somwhere" and "please populate my submodule" are (with
> the blank-url case defaulting to the superproject itself).
Why would we want to remove "init"? It still has to copy the "url"
setting (and it would be a compatibility nightmare if we would change
that, imagine different git versions used on the same work tree).
>> What real world problems do we have with the current init/sync that
>> this approach would solve?
>
> I don't have any, but in my `update --remote` series I'm adding two
> new config options that are handled differently (define in
> .gitmodules, override in superproject .git/config) than existing
> submodules options.
No, they're not. They are just handled differently than "url" and
"update", but will behave just like "fetchRecurseSubmodules" and
"ignore" do since day one. And as I explained in another mail I
think "url" is special and "update" should be change to behave like
the other two some day.
^ permalink raw reply
* Re: [RFC] remove/deprecate 'submodule init' and 'sync'
From: W. Trevor King @ 2012-12-01 18:16 UTC (permalink / raw)
To: Jens Lehmann
Cc: Phil Hord, Git, Heiko Voigt, Junio C Hamano, Jeff King,
Shawn Pearce, Nahor
In-Reply-To: <50BA4695.7030008@web.de>
[-- Attachment #1: Type: text/plain, Size: 1956 bytes --]
On Sat, Dec 01, 2012 at 07:04:05PM +0100, Jens Lehmann wrote:
> Am 01.12.2012 18:49, schrieb W. Trevor King:
> > I think removing `init` will cause some compatibility issues anyway,
> > so I was re-imaging how you do it. I don't think update='none' and
> > "don't populate my submodule" are distinct ideas, while a locally
> > configured url="somwhere" and "please populate my submodule" are (with
> > the blank-url case defaulting to the superproject itself).
>
> Why would we want to remove "init"? It still has to copy the "url"
> setting (and it would be a compatibility nightmare if we would change
> that, imagine different git versions used on the same work tree).
In my init-less rewrite, it doesn't have to copy the url setting.
People using older versions of Git would need to run `init` using
their old version. Having the url defined in .git/config won't break
my init-less submodule commands, it just means that the value in
.gitmodules will be masked.
> >> What real world problems do we have with the current init/sync that
> >> this approach would solve?
> >
> > I don't have any, but in my `update --remote` series I'm adding two
> > new config options that are handled differently (define in
> > .gitmodules, override in superproject .git/config) than existing
> > submodules options.
>
> No, they're not. They are just handled differently than "url" and
> "update", but will behave just like "fetchRecurseSubmodules" and
> "ignore" do since day one. And as I explained in another mail I
> think "url" is special and "update" should be change to behave like
> the other two some day.
I somehow missed those earlier. Thanks for correcting my tunnel
vision. This makes me much happier about postponing the init-removal.
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Inconsistency in messages about --set-upstream from git pull and git branch
From: Carlos Martín Nieto @ 2012-12-02 1:29 UTC (permalink / raw)
To: danr; +Cc: git
In-Reply-To: <CAN2DD_Hc4ZoQZefUirSZF=PZY5654yqrQfk5g1VzBLixEC=T-g@mail.gmail.com>
Dan Rosén <danr@student.chalmers.se> writes:
>
> git branch --set-upstream master origin/<branch>
>
This has been fixed already in 1.8.0.1
cmn
^ permalink raw reply
* Re: [PATCH 6/8] imap-send: change msg_data from storing (char *, len) to storing strbuf
From: Junio C Hamano @ 2012-12-02 1:48 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git, Jeremy White, Johannes Schindelin, Jeff King
In-Reply-To: <50B8B66F.3090300@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> On 11/29/2012 10:30 PM, Junio C Hamano wrote:
>
>>> A side effect of this change is that the memory for each message is
>>> freed after it is used rather than leaked, though that detail is
>>> unimportant given that imap-send is a top-level command.
>>>
>>> --
>>
>> ?
>
> If by "?" you are wondering where the memory leak was, it was:
No, I was wondering if you meant to say "---" to mark te remainder
of what you wrote does not exactly belong to the log message.
>>> For some reason, there is a bunch of infrastructure in this file for
>>> dealing with IMAP flags, although there is nothing in the code that
>>> actually allows any flags to be set. If there is no plan to add
>>> support for flags in the future, a bunch of code could be ripped out
>>> and "struct msg_data" could be completely replaced with strbuf.
>>
>> Yeah, after all these years we have kept the unused flags field
>> there and nobody needed anything out of it. I am OK with a removal
>> if it is done at the very end of the series.
>
> I don't think the removal of flags needs to be part of the same series.
Oh, I did not think so, either.
> I suggest a separate patch series dedicated to deleting *all* the extra
> imap infrastructure at once. That being said, I'm not committing to do
> so. (We could add it to an "straightforward projects for aspiring git
> developers" list, if we had such a thing.)
A "low-hanging fruit and/or janitorial work" stack may be worth
having.
^ permalink raw reply
* Re: [PATCH] submodule: add 'deinit' command
From: Junio C Hamano @ 2012-12-02 2:00 UTC (permalink / raw)
To: Jens Lehmann
Cc: Phil Hord, W. Trevor King, Git, Heiko Voigt, Jeff King,
Shawn Pearce, Nahor
In-Reply-To: <50BA3412.60309@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
> With "git submodule init" the user is able to tell git he cares about one
> or more submodules and wants to have it populated on the next call to "git
> submodule update". But currently there is no easy way he could tell git he
> does not care about a submodule anymore and wants to get rid of his local
> work tree (except he knows a lot about submodule internals and removes the
> "submodule.$name.url" setting from .git/config himself).
>
> Help those users by providing a 'deinit' command. This removes the url
> setting from .git/config either for the given submodule(s) or for all
> those which have been initialized if none were given. Complain only when
> for a submodule given on the command line the url setting can't be found
> in .git/config.
>
> Add tests and link the man pages of "git submodule deinit" and "git rm" to
> assist the user in deciding whether removing or unregistering the submodule
> is the right thing to do for him.
>
> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
> ---
I fully agree with your analysis on the reason why the "url" element
is special and has to be copied to $GIT_DIR/config, but when you
deinit (or uninit) a submodule to say you are no longer interested
in it and do not want it populated in the context of the
superproject, I am not sure if removing only submodule.$name.url (so
that when you later decide to "init" it again, you will keep the
values for submodule.$name.update and other things from the previous
life) is the sane thing to do, or it is better to remove
submodule.$name.* altogether as if an earlier "init" has never
happened. Would it be worth analyzing the pros-and-cons here?
> Am 01.12.2012 16:56, schrieb Jens Lehmann:
>> Am 01.12.2012 00:52, schrieb Phil Hord:
>>> If I never 'submodule init' a submodule, it does not get visited by
>>> 'git submodule foreach', among others. I think some people use this
>>> behavior explicitly.
>>>
>>> On the other hand, I've also notice that a submodule which I have
>>> removed does not get de-inited later one. It causes my 'git submodule
>>> foreach' to emit errors. :-(
>>
>> I'm currently hacking on "git submodule deinit" which removes the 'url'
>> setting from git/config. This should do the trick for you, right?
>
> And here we go ...
>
>
> Documentation/git-rm.txt | 4 ++++
> Documentation/git-submodule.txt | 11 +++++++++
> git-submodule.sh | 50 ++++++++++++++++++++++++++++++++++++++++-
> t/t7400-submodule-basic.sh | 11 +++++++++
> 4 files changed, 75 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt
> index 262436b..ec42bf5 100644
> --- a/Documentation/git-rm.txt
> +++ b/Documentation/git-rm.txt
> @@ -149,6 +149,10 @@ files that aren't ignored are present in the submodules work tree.
> Ignored files are deemed expendable and won't stop a submodule's work
> tree from being removed.
>
> +If you only want to remove the local checkout of a submodule from your
> +work tree without committing that use `git submodule deinit` instead
> +(see linkgit:git-submodule[1]).
> +
> EXAMPLES
> --------
> `git rm Documentation/\*.txt`::
> diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
> index b1de3ba..fba77f6 100644
> --- a/Documentation/git-submodule.txt
> +++ b/Documentation/git-submodule.txt
> @@ -13,6 +13,7 @@ SYNOPSIS
> [--reference <repository>] [--] <repository> [<path>]
> 'git submodule' [--quiet] status [--cached] [--recursive] [--] [<path>...]
> 'git submodule' [--quiet] init [--] [<path>...]
> +'git submodule' [--quiet] deinit [--] [<path>...]
> 'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--rebase]
> [--reference <repository>] [--merge] [--recursive] [--] [<path>...]
> 'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) <n>]
> @@ -134,6 +135,16 @@ init::
> the explicit 'init' step if you do not intend to customize
> any submodule locations.
>
> +deinit::
> + Unregister the submodules, i.e. remove the `submodule.$name.url`
> + setting from .git/config. Further calls to `git submodule update`,
> + `git submodule foreach` and `git submodule sync` will skip any
> + unregistered submodules until they are initialized again, so use
> + this command if you don't want to have a local checkout of the
> + submodule in your work tree anymore. If you really want to remove
> + a submodule from the repository and commit that use
> + linkgit:git-rm[1] instead.
> +
> update::
> Update the registered submodules, i.e. clone missing submodules and
> checkout the commit specified in the index of the containing repository.
> diff --git a/git-submodule.sh b/git-submodule.sh
> index 2365149..4059a2e 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -8,6 +8,7 @@ dashless=$(basename "$0" | sed -e 's/-/ /')
> USAGE="[--quiet] add [-b <branch>] [-f|--force] [--name <name>] [--reference <repository>] [--] <repository> [<path>]
> or: $dashless [--quiet] status [--cached] [--recursive] [--] [<path>...]
> or: $dashless [--quiet] init [--] [<path>...]
> + or: $dashless [--quiet] deinit [--] [<path>...]
> or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force] [--rebase] [--reference <repository>] [--merge] [--recursive] [--] [<path>...]
> or: $dashless [--quiet] summary [--cached|--files] [--summary-limit <n>] [commit] [--] [<path>...]
> or: $dashless [--quiet] foreach [--recursive] <command>
> @@ -516,6 +517,53 @@ cmd_init()
> }
>
> #
> +# Unregister submodules from .git/config
> +#
> +# $@ = requested paths (default to all)
> +#
> +cmd_deinit()
> +{
> + # parse $args after "submodule ... init".
> + while test $# -ne 0
> + do
> + case "$1" in
> + -q|--quiet)
> + GIT_QUIET=1
> + ;;
> + --)
> + shift
> + break
> + ;;
> + -*)
> + usage
> + ;;
> + *)
> + break
> + ;;
> + esac
> + shift
> + done
> +
> + module_list "$@" |
> + while read mode sha1 stage sm_path
> + do
> + die_if_unmatched "$mode"
> + name=$(module_name "$sm_path") || exit
> + url=$(git config submodule."$name".url)
> + if test -z "$url"
> + then
> + # Only mention uninitialized submodules when its
> + # path have been specified
> + test "$#" != "0" &&
> + say "$(eval_gettext "No url found for submodule path '\$sm_path' in .git/config")"
> + continue
> + fi
> + git config --unset submodule."$name".url &&
> + say "$(eval_gettext "Submodule '\$name' (\$url) unregistered")"
> + done
> +}
> +
> +#
> # Update each submodule path to correct revision, using clone and checkout as needed
> #
> # $@ = requested paths (default to all)
> @@ -1108,7 +1156,7 @@ cmd_sync()
> while test $# != 0 && test -z "$command"
> do
> case "$1" in
> - add | foreach | init | update | status | summary | sync)
> + add | foreach | init | deinit | update | status | summary | sync)
> command=$1
> ;;
> -q|--quiet)
> diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
> index de7d453..803bda7 100755
> --- a/t/t7400-submodule-basic.sh
> +++ b/t/t7400-submodule-basic.sh
> @@ -756,4 +756,15 @@ test_expect_success 'submodule add with an existing name fails unless forced' '
> )
> '
>
> +test_expect_success 'submodule deinit should unregister submodule url from .git/config' '
> + url=$(git config submodule.example.url) &&
> + git submodule deinit &&
> + test -z "$(git config submodule.example.url)"
> +'
> +
> +test_expect_success 'submodule deinit complains only when explicitly used on an uninitialized submodule' '
> + git submodule deinit &&
> + test_must_fail git submodule deinit example
> +'
> +
> test_done
^ permalink raw reply
* Re: [PATCH v7 p2 1/2] fast-export: don't handle uninteresting refs
From: Junio C Hamano @ 2012-12-02 2:07 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Max Horn, git, Jeff King
In-Reply-To: <CAMP44s08Jfu08oeABHcy=xPtn=LZfKTdbaRZuDbf7g+RiP7xAA@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> On Thu, Nov 29, 2012 at 2:16 AM, Max Horn <postbox@quendi.de> wrote:
>>
>> On 28.11.2012, at 23:23, Felipe Contreras wrote:
>>
>>> They have been marked as UNINTERESTING for a reason, lets respect that.
>>>
>>> Currently the first ref is handled properly, but not the rest:
>>>
>>> % git fast-export master ^uninteresting ^foo ^bar
>>
>> All these refs are assumed to point to the same object, right? I think it would be better if the commit message stated that explicitly. To make up for the lost space, you could then get rid of one of the four refs, I think three are sufficient to drive the message home ;-).
>
> Yeah, they point to the same object.
Do you want me to amend the log message of that commit to clarify
this?
>> <snip>
>>
> ...
> It's actually revs.cmdline, I typed the wrong one.
> ...
> So I think it's good.
Wait.
I at least read two points above you said what you wrote in the
commit was not corrrect and misleading to later readers. And then I
hear "it's good". Which one?
Are you merely saying that it is easily fixable to become good? If
so, what do you want to do with these not-so-good part?
If you want to ask me to amend, that is fine, but do so in a more
explicit way, not in a message at the tail of long thread that is
not even CC'ed to me.
Of course, a proper re-roll like everybody else does is just fine.
Thanks.
^ permalink raw reply
* Re: [PATCH] gitk: add a checkbox to control the visibility of tags
From: Junio C Hamano @ 2012-12-02 2:16 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git, Łukasz Stelmach
In-Reply-To: <1354309737-4280-1-git-send-email-stlman@poczta.fm>
Łukasz Stelmach <stlman@poczta.fm> writes:
> Enable hiding of tags displayed in the tree as yellow labels.
> If a repository is used together with a system like Gerrit
> there may be quite a lot of tags used to control building
> and there may be hardly any place left for commit subjects.
>
> Signed-off-by: Łukasz Stelmach <stlman@poczta.fm>
> ---
Paul, this patch is not done against your tree (does not have gitk
at the top-level), but other than that, the change mimics the way
existing hideremoes is implemented and looks reasonable to me.
We _may_ want to unify these two "hidestuff" into a list of patterns
that hides any ref that match one of the patterns in the list, e.g.
set hidestuff {refs/heads/*/* refs/tags/* refs/remotes/*}
may hide all tags, all remote-tracking branches and local branches
that have a slash in their names.
But that is an independent change that can come later.
> gitk-git/gitk | 23 +++++++++++++++--------
> 1 files changed, 15 insertions(+), 8 deletions(-)
>
> diff --git a/gitk-git/gitk b/gitk-git/gitk
> index d93bd99..274b46b 100755
> --- a/gitk-git/gitk
> +++ b/gitk-git/gitk
> @@ -1754,7 +1754,7 @@ proc readrefs {} {
> global tagids idtags headids idheads tagobjid
> global otherrefids idotherrefs mainhead mainheadid
> global selecthead selectheadid
> - global hideremotes
> + global hideremotes hidetags
>
> foreach v {tagids idtags headids idheads otherrefids idotherrefs} {
> catch {unset $v}
> @@ -1776,6 +1776,7 @@ proc readrefs {} {
> set headids($name) $id
> lappend idheads($id) $name
> } elseif {[string match "tags/*" $name]} {
> + if {$hidetags} continue
> # this lets refs/tags/foo^{} overwrite refs/tags/foo,
> # which is what we want since the former is the commit ID
> set name [string range $name 5 end]
> @@ -2702,7 +2703,7 @@ proc savestuff {w} {
> global cmitmode wrapcomment datetimeformat limitdiffs
> global colors uicolor bgcolor fgcolor diffcolors diffcontext selectbgcolor
> global autoselect autosellen extdifftool perfile_attrs markbgcolor use_ttk
> - global hideremotes want_ttk
> + global hideremotes hidetags want_ttk
>
> if {$stuffsaved} return
> if {![winfo viewable .]} return
> @@ -2725,6 +2726,7 @@ proc savestuff {w} {
> puts $f [list set autosellen $autosellen]
> puts $f [list set showneartags $showneartags]
> puts $f [list set hideremotes $hideremotes]
> + puts $f [list set hidetags $hidetags]
> puts $f [list set showlocalchanges $showlocalchanges]
> puts $f [list set datetimeformat $datetimeformat]
> puts $f [list set limitdiffs $limitdiffs]
> @@ -10864,7 +10866,7 @@ proc create_prefs_page {w} {
> proc prefspage_general {notebook} {
> global NS maxwidth maxgraphpct showneartags showlocalchanges
> global tabstop limitdiffs autoselect autosellen extdifftool perfile_attrs
> - global hideremotes want_ttk have_ttk
> + global hideremotes hidetags want_ttk have_ttk
>
> set page [create_prefs_page $notebook.general]
>
> @@ -10887,6 +10889,9 @@ proc prefspage_general {notebook} {
> ${NS}::checkbutton $page.hideremotes -text [mc "Hide remote refs"] \
> -variable hideremotes
> grid x $page.hideremotes -sticky w
> + ${NS}::checkbutton $page.hidetags -text [mc "Hide tag labels"] \
> + -variable hidetags
> + grid x $page.hidetags -sticky w
>
> ${NS}::label $page.ddisp -text [mc "Diff display options"]
> grid $page.ddisp - -sticky w -pady 10
> @@ -10988,7 +10993,7 @@ proc doprefs {} {
> global oldprefs prefstop showneartags showlocalchanges
> global uicolor bgcolor fgcolor ctext diffcolors selectbgcolor markbgcolor
> global tabstop limitdiffs autoselect autosellen extdifftool perfile_attrs
> - global hideremotes want_ttk have_ttk
> + global hideremotes hidetags want_ttk have_ttk
>
> set top .gitkprefs
> set prefstop $top
> @@ -10997,7 +11002,7 @@ proc doprefs {} {
> return
> }
> foreach v {maxwidth maxgraphpct showneartags showlocalchanges \
> - limitdiffs tabstop perfile_attrs hideremotes want_ttk} {
> + limitdiffs tabstop perfile_attrs hideremotes hidetags want_ttk} {
> set oldprefs($v) [set $v]
> }
> ttk_toplevel $top
> @@ -11117,7 +11122,7 @@ proc prefscan {} {
> global oldprefs prefstop
>
> foreach v {maxwidth maxgraphpct showneartags showlocalchanges \
> - limitdiffs tabstop perfile_attrs hideremotes want_ttk} {
> + limitdiffs tabstop perfile_attrs hideremotes hidetags want_ttk} {
> global $v
> set $v $oldprefs($v)
> }
> @@ -11131,7 +11136,7 @@ proc prefsok {} {
> global oldprefs prefstop showneartags showlocalchanges
> global fontpref mainfont textfont uifont
> global limitdiffs treediffs perfile_attrs
> - global hideremotes
> + global hideremotes hidetags
>
> catch {destroy $prefstop}
> unset prefstop
> @@ -11177,7 +11182,8 @@ proc prefsok {} {
> $limitdiffs != $oldprefs(limitdiffs)} {
> reselectline
> }
> - if {$hideremotes != $oldprefs(hideremotes)} {
> + if {$hideremotes != $oldprefs(hideremotes) ||
> + $hidetags != $oldprefs(hidetags)} {
> rereadrefs
> }
> }
> @@ -11601,6 +11607,7 @@ set cmitmode "patch"
> set wrapcomment "none"
> set showneartags 1
> set hideremotes 0
> +set hidetags 0
> set maxrefs 20
> set maxlinelen 200
> set showlocalchanges 1
^ permalink raw reply
* Re: [PATCH 0/5] "diff --stat" counting fixes
From: Junio C Hamano @ 2012-12-02 2:23 UTC (permalink / raw)
To: Antoine Pelisse; +Cc: git
In-Reply-To: <CALWbr2xYrWkfSCUc7gocVGLQP_RHjWrMmFspPe5O_ekjisNqxw@mail.gmail.com>
Antoine Pelisse <apelisse@gmail.com> writes:
> I feel like (but I can obviously be wrong):
> 1. The info is redundant. When performing a merge, all diffs (without
> --staged flag) are unmerged
Yes, it is redundant. They are primarily meant as a warning to
anybody who runs "git diff --stat" while their index is not fully
merged so that they do not mistakenly think they are looking at
meaningful numbers. The number of added lines likely includes the
conflict markers you haven't dealt with ;-)
> 2. While status shows the line once, while diff shows the diff for the file
> once, while diff --shortstat counts the file once, diff --stat shows two
> lines for the file.
Yeah, don't use shortstat while your index is unmerged.
> 3. diff --numstat shows two lines for the same file. As a script
> writer (I guess that's what it's meant for), I would definitely expect
> uniqueness in third column/filenames.
Then your script wouldn't receive any hint in the output that you
are reading from a nonsense input. When you see the same filename
twice, you will know there is something strange (not just "I seem to
have more added lines than I thought I added -- Ah, I see added
files from both sides because I still have conflicts unresolved")
that gives you a chance to notice.
^ permalink raw reply
* Re: [PATCH] t4049: avoid test failures on filemode challenged file systems (Windows)
From: Junio C Hamano @ 2012-12-02 2:24 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Antoine Pelisse
In-Reply-To: <50B86438.3010806@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Am 11/29/2012 21:48, schrieb Junio C Hamano:
>> I've tested this with the testpen set on vfat mounted on my Linux
>> box, ...
>> and it seems to work OK,
>
> Works well here on Windows, too.
Thanks for checking.
^ permalink raw reply
* Re: [PATCH 1/2] git-fast-import.txt: improve documentation for quoted paths
From: Junio C Hamano @ 2012-12-02 2:27 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Jeff King, git
In-Reply-To: <vpqvccnctvd.fsf@grenoble-inp.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> That "shell-style" contradicts with what fast-import.c says, though.
>> It claims to grok \octal and described as C-style.
>
> As Peff mentionned, my last version is better, although still a bit
> incomplete. My new version documents things that _must_ be escaped, but
> not what _can_.
Yeah, I agree.
^ permalink raw reply
* does a successful 'git gc' imply 'git fsck'
From: Sitaram Chamarty @ 2012-12-02 2:31 UTC (permalink / raw)
To: Git Mailing List
Hi,
Background: I have a situation where I have to fix up a few hundred
repos in terms of 'git gc' (the auto gc seems to have failed in many
cases; they have far more than 6700 loose objects). I also found some
corrupted objects in some cases that prevent the gc from completing.
I am running "git gc" followed by "git fsck". The majority of the
repos I have worked through so far appear to be fine, but in the
larger repos (upwards of 2-3 GB) the git fsck is taking almost 5 times
longer than the 'gc'.
If I could assume that a successful 'git gc' means an fsck is not
needed, I'd save a lot of time. Hence my question.
--
Sitaram
^ permalink raw reply
* [PATCH v6 3/4] submodule add: If --branch is given, record it in .gitmodules
From: W. Trevor King @ 2012-12-02 3:17 UTC (permalink / raw)
To: Git
Cc: Junio C Hamano, Heiko Voigt, Jeff King, Phil Hord, Shawn Pearce,
Jens Lehmann, Nahor, W. Trevor King
In-Reply-To: <cover.1354417618.git.wking@tremily.us>
From: "W. Trevor King" <wking@tremily.us>
This allows you to easily record a submodule.<name>.branch option in
.gitmodules when you add a new submodule. With this patch,
$ git submodule add -b <branch> <repository> [<path>]
$ git config -f .gitmodules submodule.<path>.branch <branch>
reduces to
$ git submodule add -b <branch> <repository> [<path>]
This means that future calls to
$ git submodule update --remote ...
will get updates from the same branch that you used to initialize the
submodule, which is usually what you want.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/git-submodule.txt | 2 ++
git-submodule.sh | 4 ++++
t/t7400-submodule-basic.sh | 1 +
3 files changed, 7 insertions(+)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 72dd52f..988bba9 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -208,6 +208,8 @@ OPTIONS
-b::
--branch::
Branch of repository to add as submodule.
+ The name of the branch is recorded as `submodule.<path>.branch` in
+ `.gitmodules` for `update --remote`.
-f::
--force::
diff --git a/git-submodule.sh b/git-submodule.sh
index 104b5de..27b02fe 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -395,6 +395,10 @@ Use -f if you really want to add it." >&2
git config -f .gitmodules submodule."$sm_path".path "$sm_path" &&
git config -f .gitmodules submodule."$sm_path".url "$repo" &&
+ if test -n "$branch"
+ then
+ git config -f .gitmodules submodule."$sm_path".branch "$branch"
+ fi &&
git add --force .gitmodules ||
die "$(eval_gettext "Failed to register submodule '\$sm_path'")"
}
diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
index 5397037..90e2915 100755
--- a/t/t7400-submodule-basic.sh
+++ b/t/t7400-submodule-basic.sh
@@ -133,6 +133,7 @@ test_expect_success 'submodule add --branch' '
(
cd addtest &&
git submodule add -b initial "$submodurl" submod-branch &&
+ test "initial" = "$(git config -f .gitmodules submodule.submod-branch.branch)" &&
git submodule init
) &&
--
1.8.0.4.gf74b0fc.dirty
^ permalink raw reply related
* [PATCH v6 4/4] submodule update: add submodule.<name>.remote config option
From: W. Trevor King @ 2012-12-02 3:17 UTC (permalink / raw)
To: Git
Cc: Junio C Hamano, Heiko Voigt, Jeff King, Phil Hord, Shawn Pearce,
Jens Lehmann, Nahor, W. Trevor King
In-Reply-To: <cover.1354417618.git.wking@tremily.us>
From: "W. Trevor King" <wking@tremily.us>
Don't force the user to clone from the tracked repository
(branch.<name>.remote) or `origin`. By setting
submodule.<name>.remote in .gitmodules or the usual git config files,
you can easily point a submodule at a different remote when using
`submodule update --remote`.
The configured remote name is also used in `submodule sync` to
determine which remote.<name>.url is updated with the submodule's
origin URL.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/config.txt | 7 ++++---
Documentation/git-submodule.txt | 10 +++++-----
git-submodule.sh | 27 +++++++++++++++++++++------
t/t7406-submodule-update.sh | 18 ++++++++++++++++++
4 files changed, 48 insertions(+), 14 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 6f4663c..c54b9b4 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1999,10 +1999,11 @@ submodule.<name>.update::
by 'git submodule init'; edit them to override the
URL and other values found in the `.gitmodules` file. See
+submodule.<name>.remote::
submodule.<name>.branch::
- The remote branch name for a submodule, used by `git submodule
- update --remote`. Set this option to override the value found in
- the `.gitmodules` file. See linkgit:git-submodule[1] and
+ The remote repository and branch names for a submodule, used by `git
+ submodule update --remote`. Set these options to override the value
+ found in the `.gitmodules` file. See linkgit:git-submodule[1] and
linkgit:gitmodules[5] for details.
submodule.<name>.fetchRecurseSubmodules::
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 988bba9..1d8d5f1 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -242,11 +242,11 @@ OPTIONS
This option is only valid for the update command. Instead of using
the superproject's recorded SHA-1 to update the submodule, use the
status of the submodule's remote tracking branch. The remote used
- is branch's remote (`branch.<name>.remote`), defaulting to `origin`.
- The remote branch used defaults to `master`, but the branch name may
- be overridden by setting the `submodule.<name>.branch` option in
- either `.gitmodules` or `.git/config` (with `.git/config` taking
- precedence).
+ is branch's remote (`branch.<name>.remote`, defaulting to `origin`),
+ and the remote branch used defaults to `master`, but either may be
+ overridden by setting the `submodule.<name>.remote` or
+ `submodule.<name>.branch` option in `.gitmodules` or `.git/config`
+ (with `.git/config` taking precedence).
+
This works for any of the supported update procedures (`--checkout`,
`--rebase`, etc.). The only change is the source of the target SHA-1.
diff --git a/git-submodule.sh b/git-submodule.sh
index 27b02fe..3e39e29 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -179,6 +179,21 @@ get_submodule_config()
printf '%s' "${value:-$default}"
}
+#
+# Print the name of a submodule's configured remote
+#
+# $1 = submodule name
+#
+get_submodule_remote()
+{
+ name="$1"
+ remote=$(get_submodule_config "$name" remote)
+ if test -z "$remote"
+ then
+ remote=$(get_default_remote)
+ fi
+ printf '%s' "${remote}"
+}
#
# Map submodule path to submodule name
@@ -605,6 +620,7 @@ cmd_update()
fi
name=$(module_name "$sm_path") || exit
url=$(git config submodule."$name".url)
+ remote_name=$(get_submodule_remote "$name")
branch=$(get_submodule_config "$name" branch master)
if ! test -z "$update"
then
@@ -645,10 +661,9 @@ Maybe you want to use 'update --init'?")"
if test -z "$nofetch"
then
# Fetch remote before determining tracking $sha1
- (clear_local_git_env; cd "$sm_path" && git-fetch) ||
- die "$(eval_gettext "Unable to fetch in submodule path '\$sm_path'")"
+ (clear_local_git_env; cd "$sm_path" && git-fetch "$remote_name") ||
+ die "$(eval_gettext "Unable to fetch '\$remote_name' in submodule path '\$sm_path'")"
fi
- remote_name=$(get_default_remote)
sha1=$(clear_local_git_env; cd "$sm_path" &&
git rev-parse --verify "${remote_name}/${branch}") ||
die "$(eval_gettext "Unable to find current ${remote_name}/${branch} revision in submodule path '\$sm_path'")"
@@ -669,8 +684,8 @@ Maybe you want to use 'update --init'?")"
# is not reachable from a ref.
(clear_local_git_env; cd "$sm_path" &&
( (rev=$(git rev-list -n 1 $sha1 --not --all 2>/dev/null) &&
- test -z "$rev") || git-fetch)) ||
- die "$(eval_gettext "Unable to fetch in submodule path '\$sm_path'")"
+ test -z "$rev") || git-fetch "$remote_name")) ||
+ die "$(eval_gettext "Unable to fetch '\$remote_name' in submodule path '\$sm_path'")"
fi
# Is this something we just cloned?
@@ -1110,7 +1125,7 @@ cmd_sync()
(
clear_local_git_env
cd "$sm_path"
- remote=$(get_default_remote)
+ remote=$(get_submodule_remote "$name")
git config remote."$remote".url "$sub_origin_url"
)
fi
diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh
index a567834..86c85f8 100755
--- a/t/t7406-submodule-update.sh
+++ b/t/t7406-submodule-update.sh
@@ -149,6 +149,24 @@ test_expect_success 'submodule update --remote should fetch upstream changes' '
)
'
+test_expect_success 'local config should override .gitmodules remote' '
+ (cd submodule &&
+ echo line5-master >> file &&
+ git add file &&
+ test_tick &&
+ git commit -m "upstream line5-master"
+ ) &&
+ (cd super/submodule &&
+ git remote rename origin test-remote
+ ) &&
+ (cd super &&
+ git config submodule.submodule.remote test-remote &&
+ git submodule update --remote --force submodule &&
+ cd submodule &&
+ test "$(git log -1 --oneline)" = "$(GIT_DIR=../../submodule/.git git log -1 --oneline)"
+ )
+'
+
test_expect_success 'local config should override .gitmodules branch' '
(cd submodule &&
git checkout -b test-branch &&
--
1.8.0.4.gf74b0fc.dirty
^ permalink raw reply related
* [PATCH v6 2/4] submodule update: add --remote for submodule's upstream changes
From: W. Trevor King @ 2012-12-02 3:17 UTC (permalink / raw)
To: Git
Cc: Junio C Hamano, Heiko Voigt, Jeff King, Phil Hord, Shawn Pearce,
Jens Lehmann, Nahor, W. Trevor King
In-Reply-To: <cover.1354417618.git.wking@tremily.us>
From: "W. Trevor King" <wking@tremily.us>
The current `update` command incorporates the superproject's gitlinked
SHA-1 ($sha1) into the submodule HEAD ($subsha1). Depending on the
options you use, it may checkout $sha1, rebase the $subsha1 onto
$sha1, or merge $sha1 into $subsha1. This helps you keep up with
changes in the upstream superproject.
However, it's also useful to stay up to date with changes in the
upstream subproject. Previous workflows for incorporating such
changes include the ungainly:
$ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull'
With this patch, all of the useful functionality for incorporating
superproject changes can be reused to incorporate upstream subproject
updates. When you specify --remote, the target $sha1 is replaced with
a $sha1 of the submodule's origin/master tracking branch. If you want
to merge a different tracking branch, you can configure the
`submodule.<name>.branch` option in `.gitmodules`. You can override
the `.gitmodules` configuration setting for a particular superproject
by configuring the option in that superproject's default configuration
(using the usual configuration hierarchy, e.g. `.git/config`,
`~/.gitconfig`, etc.).
Previous use of submodule.<name>.branch
=======================================
Because we're adding a new configuration option, it's a good idea to
check if anyone else is already using the option. The foreach-pull
example above was described by Ævar in
commit f030c96d8643fa0a1a9b2bd9c2f36a77721fb61f
Author: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Fri May 21 16:10:10 2010 +0000
git-submodule foreach: Add $toplevel variable
Gerrit uses the same interpretation for the setting, but because
Gerrit has direct access to the subproject repositories, it updates
the superproject repositories automatically when a subproject changes.
Gerrit also accepts the special value '.', which it expands into the
superproject's branch name.
Although the --remote functionality is using `submodule.<name>.branch`
slightly differently, the effect is the same. The foreach-pull
example uses the option to record the name of the local branch to
checkout before pulls. The tracking branch to be pulled is recorded
in `.git/modules/<name>/config`, which was initialized by the module
clone during `submodule add` or `submodule init`. Because the branch
name stored in `submodule.<name>.branch` was likely the same as the
branch name used during the initial `submodule add`, the same branch
will be pulled in each workflow.
Implementation details
======================
In order to ensure a current tracking branch state, `update --remote`
fetches the submodule's remote repository before calculating the
SHA-1. However, I didn't change the logic guarding the existing fetch:
if test -z "$nofetch"
then
# Run fetch only if $sha1 isn't present or it
# is not reachable from a ref.
(clear_local_git_env; cd "$path" &&
( (rev=$(git rev-list -n 1 $sha1 --not --all 2>/dev/null) &&
test -z "$rev") || git-fetch)) ||
die "$(eval_gettext "Unable to fetch in submodule path '\$path'")"
fi
There will not be a double-fetch, because the new $sha1 determined
after the `--remote` triggered fetch should always exist in the
repository. If it doesn't, it's because some racy process removed it
from the submodule's repository and we *should* be re-fetching.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/config.txt | 7 ++++++-
Documentation/git-submodule.txt | 25 ++++++++++++++++++++++++-
Documentation/gitmodules.txt | 5 +++++
git-submodule.sh | 22 +++++++++++++++++++++-
t/t7406-submodule-update.sh | 31 +++++++++++++++++++++++++++++++
5 files changed, 87 insertions(+), 3 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 11f320b..6f4663c 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1998,7 +1998,12 @@ submodule.<name>.update::
for a submodule. These variables are initially populated
by 'git submodule init'; edit them to override the
URL and other values found in the `.gitmodules` file. See
- linkgit:git-submodule[1] and linkgit:gitmodules[5] for details.
+
+submodule.<name>.branch::
+ The remote branch name for a submodule, used by `git submodule
+ update --remote`. Set this option to override the value found in
+ the `.gitmodules` file. See linkgit:git-submodule[1] and
+ linkgit:gitmodules[5] for details.
submodule.<name>.fetchRecurseSubmodules::
This option can be used to control recursive fetching of this
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index b4683bb..72dd52f 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -13,7 +13,7 @@ SYNOPSIS
[--reference <repository>] [--] <repository> [<path>]
'git submodule' [--quiet] status [--cached] [--recursive] [--] [<path>...]
'git submodule' [--quiet] init [--] [<path>...]
-'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--rebase]
+'git submodule' [--quiet] update [--init] [--remote] [-N|--no-fetch] [--rebase]
[--reference <repository>] [--merge] [--recursive] [--] [<path>...]
'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) <n>]
[commit] [--] [<path>...]
@@ -236,6 +236,29 @@ OPTIONS
(the default). This limit only applies to modified submodules. The
size is always limited to 1 for added/deleted/typechanged submodules.
+--remote::
+ This option is only valid for the update command. Instead of using
+ the superproject's recorded SHA-1 to update the submodule, use the
+ status of the submodule's remote tracking branch. The remote used
+ is branch's remote (`branch.<name>.remote`), defaulting to `origin`.
+ The remote branch used defaults to `master`, but the branch name may
+ be overridden by setting the `submodule.<name>.branch` option in
+ either `.gitmodules` or `.git/config` (with `.git/config` taking
+ precedence).
++
+This works for any of the supported update procedures (`--checkout`,
+`--rebase`, etc.). The only change is the source of the target SHA-1.
+For example, `submodule update --remote --merge` will merge upstream
+submodule changes into the submodules, while `submodule update
+--merge` will merge superproject gitlink changes into the submodules.
++
+In order to ensure a current tracking branch state, `update --remote`
+fetches the submodule's remote repository before calculating the
+SHA-1. This makes `submodule update --remote --merge` similar to
+running `git pull` in the submodule. If you don't want to fetch (for
+something closer to `git merge`), you should use `submodule update
+--remote --no-fetch --merge`.
+
-N::
--no-fetch::
This option is only valid for the update command.
diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt
index 4effd78..4004fa6 100644
--- a/Documentation/gitmodules.txt
+++ b/Documentation/gitmodules.txt
@@ -47,6 +47,11 @@ submodule.<name>.update::
This config option is overridden if 'git submodule update' is given
the '--merge', '--rebase' or '--checkout' options.
+submodule.<name>.branch::
+ A remote branch name for tracking updates in the upstream submodule.
+ If the option is not specified, it defaults to 'master'. See the
+ `--remote` documentation in linkgit:git-submodule[1] for details.
+
submodule.<name>.fetchRecurseSubmodules::
This option can be used to control recursive fetching of this
submodule. If this option is also present in the submodules entry in
diff --git a/git-submodule.sh b/git-submodule.sh
index 97ce5e4..104b5de 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -8,7 +8,8 @@ dashless=$(basename "$0" | sed -e 's/-/ /')
USAGE="[--quiet] add [-b branch] [-f|--force] [--reference <repository>] [--] <repository> [<path>]
or: $dashless [--quiet] status [--cached] [--recursive] [--] [<path>...]
or: $dashless [--quiet] init [--] [<path>...]
- or: $dashless [--quiet] update [--init] [-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] [--] [<path>...]
+ges
or: $dashless [--quiet] summary [--cached|--files] [--summary-limit <n>] [commit] [--] [<path>...]
or: $dashless [--quiet] foreach [--recursive] <command>
or: $dashless [--quiet] sync [--] [<path>...]"
@@ -26,6 +27,7 @@ cached=
recursive=
init=
files=
+remote=
nofetch=
update=
prefix=
@@ -536,6 +538,9 @@ cmd_update()
-i|--init)
init=1
;;
+ --remote)
+ remote=1
+ ;;
-N|--no-fetch)
nofetch=1
;;
@@ -596,6 +601,7 @@ cmd_update()
fi
name=$(module_name "$sm_path") || exit
url=$(git config submodule."$name".url)
+ branch=$(get_submodule_config "$name" branch master)
if ! test -z "$update"
then
update_module=$update
@@ -630,6 +636,20 @@ Maybe you want to use 'update --init'?")"
die "$(eval_gettext "Unable to find current revision in submodule path '\$sm_path'")"
fi
+ if test -n "$remote"
+ then
+ if test -z "$nofetch"
+ then
+ # Fetch remote before determining tracking $sha1
+ (clear_local_git_env; cd "$sm_path" && git-fetch) ||
+ die "$(eval_gettext "Unable to fetch in submodule path '\$sm_path'")"
+ fi
+ remote_name=$(get_default_remote)
+ sha1=$(clear_local_git_env; cd "$sm_path" &&
+ git rev-parse --verify "${remote_name}/${branch}") ||
+ die "$(eval_gettext "Unable to find current ${remote_name}/${branch} revision in submodule path '\$sm_path'")"
+ fi
+
if test "$subsha1" != "$sha1" -o -n "$force"
then
subforce=$force
diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh
index 1542653..a567834 100755
--- a/t/t7406-submodule-update.sh
+++ b/t/t7406-submodule-update.sh
@@ -135,6 +135,37 @@ test_expect_success 'submodule update --force forcibly checks out submodules' '
)
'
+test_expect_success 'submodule update --remote should fetch upstream changes' '
+ (cd submodule &&
+ echo line4 >> file &&
+ git add file &&
+ test_tick &&
+ git commit -m "upstream line4"
+ ) &&
+ (cd super &&
+ git submodule update --remote --force submodule &&
+ cd submodule &&
+ test "$(git log -1 --oneline)" = "$(GIT_DIR=../../submodule/.git git log -1 --oneline)"
+ )
+'
+
+test_expect_success 'local config should override .gitmodules branch' '
+ (cd submodule &&
+ git checkout -b test-branch &&
+ echo line5 >> file &&
+ git add file &&
+ test_tick &&
+ git commit -m "upstream line5" &&
+ git checkout master
+ ) &&
+ (cd super &&
+ git config submodule.submodule.branch test-branch &&
+ git submodule update --remote --force submodule &&
+ cd submodule &&
+ test "$(git log -1 --oneline)" = "$(GIT_DIR=../../submodule/.git git log -1 --oneline test-branch)"
+ )
+'
+
test_expect_success 'submodule update --rebase staying on master' '
(cd super/submodule &&
git checkout master
--
1.8.0.4.gf74b0fc.dirty
^ permalink raw reply related
* [PATCH v6 1/4] submodule: add get_submodule_config helper funtion
From: W. Trevor King @ 2012-12-02 3:17 UTC (permalink / raw)
To: Git
Cc: Junio C Hamano, Heiko Voigt, Jeff King, Phil Hord, Shawn Pearce,
Jens Lehmann, Nahor, W. Trevor King
In-Reply-To: <cover.1354417618.git.wking@tremily.us>
From: "W. Trevor King" <wking@tremily.us>
Several submodule configuration variables
(e.g. fetchRecurseSubmodules) are read from .gitmodules with local
overrides from the usual git config files. This shell function mimics
that logic to help initialize configuration variables in
git-submodule.sh.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
git-submodule.sh | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/git-submodule.sh b/git-submodule.sh
index ab6b110..97ce5e4 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -152,6 +152,33 @@ die_if_unmatched ()
}
#
+# Print a submodule configuration setting
+#
+# $1 = submodule name
+# $2 = option name
+# $3 = default value
+#
+# Checks in the usual git-config places first (for overrides),
+# otherwise it falls back on .gitmodules. This allows you to
+# distribute project-wide defaults in .gitmodules, while still
+# customizing individual repositories if necessary. If the option is
+# not in .gitmodules either, print a default value.
+#
+get_submodule_config()
+{
+ name="$1"
+ option="$2"
+ default="$3"
+ value=$(git config submodule."$name"."$option")
+ if test -z "$value"
+ then
+ value=$(git config -f .gitmodules submodule."$name"."$option")
+ fi
+ printf '%s' "${value:-$default}"
+}
+
+
+#
# Map submodule path to submodule name
#
# $1 = path
--
1.8.0.4.gf74b0fc.dirty
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox