* Also close config file handle when leaving git_config_set_multivar_in_file() early
From: 乙酸鋰 @ 2012-12-01 14:01 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 221 bytes --]
Hi,
This patch fixes the captioned problem.
It is needed because our program statically link git.
In this case, do not assume a fail will call die() and exit program so
the handle is leave not closed.
Regards,
ch3cooli
[-- Attachment #2: 0001-Also-close-config-file-handle-when-leaving-git_confi.patch --]
[-- Type: application/octet-stream, Size: 872 bytes --]
From 5d8d28f039b4db7b4f040a40fdc2edf866200f0c Mon Sep 17 00:00:00 2001
From: Sup Yut Sum <ch3cooli@gmail.com>
Date: Sat, 1 Dec 2012 21:56:41 +0800
Subject: [PATCH] Also close config file handle when leaving
git_config_set_multivar_in_file() early
Signed-off-by: Sup Yut Sum <ch3cooli@gmail.com>
---
config.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/config.c b/config.c
index fff8a43..4b5c877 100644
--- a/config.c
+++ b/config.c
@@ -1424,6 +1424,7 @@ int git_config_set_multivar_in_file(const char *config_filename,
contents = xmmap(NULL, contents_sz, PROT_READ,
MAP_PRIVATE, in_fd, 0);
close(in_fd);
+ in_fd = -1;
if (store.seen == 0)
store.seen = 1;
@@ -1493,6 +1494,8 @@ out_free:
if (lock)
rollback_lock_file(lock);
free(filename_buf);
+ if (in_fd >= 0)
+ close(in_fd);
return ret;
write_err_out:
--
1.8.0.msysgit.0
^ permalink raw reply related
* Re: [RFC] remove/deprecate 'submodule init' and 'sync'
From: Jens Lehmann @ 2012-12-01 15:38 UTC (permalink / raw)
To: W. Trevor King
Cc: Phil Hord, Git, Heiko Voigt, Junio C Hamano, Jeff King,
Shawn Pearce, Nahor
In-Reply-To: <20121130175309.GA718@odin.tremily.us>
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).
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.
> What to do about this? `init` has been around for a while, so we
> can't just remove it (maybe in 2.0?). Leaving it in place is not
> really a problem though, it just means that the user is locking in the
> current .gitmodules configuration (as Jens pointed out with respect to
> .branch).
We still need those commands to set and update the "url" setting.
> ---
> #
> # 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}"
> }
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.
^ permalink raw reply
* Re: [RFC] remove/deprecate 'submodule init' and 'sync'
From: Jens Lehmann @ 2012-12-01 15:42 UTC (permalink / raw)
To: W. Trevor King
Cc: Phil Hord, Git, Heiko Voigt, Junio C Hamano, Jeff King,
Shawn Pearce, Nahor
In-Reply-To: <20121201124842.GA32291@odin.tremily.us>
Am 01.12.2012 13:48, schrieb W. Trevor King:
> On Fri, Nov 30, 2012 at 06:52:22PM -0500, Phil Hord wrote:
>> 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.
>
> This is something I'll fix while working up a trial patch. Currently cmd_update calls module_clone if the <submodule>/.git does not exist. This should probably happen in each command (in a wrapper around module_list?). It's possible that module_list itself would need some work, but I haven't absorbed its implementation yet [1].
Please do not fix it, this is a feature. "update" is the only command
where that should happen (and only if "url" is set in .git/config, as
I explained in my other mail). So everything should be fine here.
^ permalink raw reply
* 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
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