* 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 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: [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: 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: [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
* [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: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
* 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
* 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: 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
* 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: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: [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
* 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: W. Trevor King @ 2012-12-01 12:48 UTC (permalink / raw)
To: Phil Hord
Cc: Jens Lehmann, Git, Heiko Voigt, Junio C Hamano, Jeff King,
Shawn Pearce, Nahor
In-Reply-To: <CABURp0qNBcFnxbvhn7PsKWLUOsTiK4u5vx-=6cG3JQHw9aUeHA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 785 bytes --]
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].
Trevor
[1]: I read Perl by sounding out each letter ;).
--
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: [PATCH/RFC 2/5] compat/terminal: factor out echo-disabling
From: Erik Faye-Lund @ 2012-12-01 12:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, msysgit, peff
In-Reply-To: <alpine.DEB.1.00.1211301858570.31987@s15462909.onlinehome-server.info>
On Fri, Nov 30, 2012 at 6:59 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Tue, 13 Nov 2012, Erik Faye-Lund wrote:
>
>> By moving the echo-disabling code to a separate function, we can
>> implement OS-specific versions of it for non-POSIX platforms.
>>
>> Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
>> ---
>> compat/terminal.c | 43 +++++++++++++++++++++++++------------------
>> 1 file changed, 25 insertions(+), 18 deletions(-)
>>
>> diff --git a/compat/terminal.c b/compat/terminal.c
>> index bbb038d..3217838 100644
>> --- a/compat/terminal.c
>> +++ b/compat/terminal.c
>> @@ -14,6 +14,7 @@ static void restore_term(void)
>> return;
>>
>> tcsetattr(term_fd, TCSAFLUSH, &old_term);
>> + close(term_fd);
>> term_fd = -1;
>> }
>
> That looks like an independent resource leak fix... correct?
It might look like it, but it's not; term_fd used to be returned by
"fileno(fh)", and fh did get properly closed.
With my refactoring, disable_echo/restore_term takes opens /dev/tty a
second time, like Jeff points out. And that second file descriptor
needs to be closed.
--
*** 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: [PATCH/RFC 1/5] mingw: make fgetc raise SIGINT if apropriate
From: Erik Faye-Lund @ 2012-12-01 12:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, msysgit, peff
In-Reply-To: <alpine.DEB.1.00.1211301857170.31987@s15462909.onlinehome-server.info>
On Fri, Nov 30, 2012 at 6:58 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Tue, 13 Nov 2012, Erik Faye-Lund wrote:
>
>> Set a control-handler to prevent the process from terminating, and
>> simulate SIGINT so it can be handled by a signal-handler as usual.
>
> 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.
I'm not entirely sure if I know what you mean. Do you suggest that two
threads can race for setting the console ctrl-handler? I don't think
that's the case; "SetConsoleCtrlHandler(x, TRUE)" adds a console
handler to the handler-chain, and SetConsoleCtrlHandler(x, FALSE)
removes it. If two threads add handlers, it is my understanding that
one of them will be run, only to report "no, no more ctrl-handling
needed". Since both handlers block further ctrl-handling, I don't
think there's a problem.
Do you care to clarify what your thread-safety complaint is?
> BTW I like the new mingw_raise() very much!
Thanks! I originally implemented it for a different reason, but that
patch didn't turn out to be useful, so it's nice to finally put it to
use ;)
--
*** 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: [PATCH 0/5] ignore SIG{INT,QUIT} when launching editor
From: Krzysztof Mazur @ 2012-12-01 12:34 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano, Paul Fox
In-Reply-To: <20121130223943.GA27120@sigill.intra.peff.net>
On Fri, Nov 30, 2012 at 05:39:43PM -0500, Jeff King wrote:
> This is a re-roll of the pf/editor-ignore-sigint series.
>
> 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.
>
Also some good editors printed error message after they got EIO,
confusing the user.
Looks good to me. I've tested this with ed (always ignores SIGINT
and SIGQUIT), vim (always ignores SIGINT, but dies after three
SIGQUIT) and "sleep" (dies after SIGINT and SIGQUIT) and git works now
as expected. Doing what editor does is probably the best thing to do.
Tested-by: Krzysztof Mazur <krzysiek@podlesie.net>
Thanks,
Krzysiek
^ permalink raw reply
* Re: [PATCH/RFC 1/5] mingw: make fgetc raise SIGINT if apropriate
From: Erik Faye-Lund @ 2012-12-01 12:31 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, git, msysgit
In-Reply-To: <20121130181119.GA7197@sigill.intra.peff.net>
On Fri, Nov 30, 2012 at 7:11 PM, Jeff King <peff@peff.net> wrote:
> On Fri, Nov 30, 2012 at 06:58:11PM +0100, Johannes Schindelin wrote:
>
>> Hi,
>>
>> On Tue, 13 Nov 2012, Erik Faye-Lund wrote:
>>
>> > Set a control-handler to prevent the process from terminating, and
>> > simulate SIGINT so it can be handled by a signal-handler as usual.
>>
>> 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?
--
*** 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
* Bug report : gitattribute export-ignore behavior does not match documentation
From: Jean-Noël AVILA @ 2012-12-01 11:24 UTC (permalink / raw)
To: git
Tested on latest maint and master.
The 'export-ignore' gitattribute is documented as behaving on a pattern, just
like in .gitignore.
In repo where I have a tree like this:
.gitattributes
figures/
fr/figures/
I want to remove from archive all the figures directories. So I added
figures/ export-ignore
to the top level .gitattributes file.
but then:
$ git check-attr -a fr/figures
$ git check-attr -a figures
$
If I change the line in .gitattributes to :
figures export-ignore
I get the correct result, but I am not sure to exclude only directories.
Am I wrong somewhere?
Thank you.
Jean-Noël AVILA
^ permalink raw reply
* [PATCH v2 3/4] git-svn: Expand documentation for --follow-parent
From: Sebastian Leske @ 2012-11-30 7:16 UTC (permalink / raw)
To: git; +Cc: Michael J Gruber, Eric Wong
In-Reply-To: <cover.1354324110.git.Sebastian.Leske@sleske.name>
Describe what the option --follow-parent does, and what happens if it is
set or unset.
Signed-off-by: Sebastian Leske <sebastian.leske@sleske.name>
---
Documentation/git-svn.txt | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index bfa8788..6bda014 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -628,10 +628,19 @@ ADVANCED OPTIONS
Default: "svn"
--follow-parent::
+ This option is only relevant if we are tracking branches (using
+ one of the repository layout options --trunk, --tags,
+ --branches, --stdlayout). For each tracked branch, try to find
+ out where its revision was copied (i.e. branched) from, and set
+ a suitable parent in the first git commit for the branch.
This is especially helpful when we're tracking a directory
- that has been moved around within the repository, or if we
- started tracking a branch and never tracked the trunk it was
- descended from. This feature is enabled by default, use
+ that has been moved around within the repository. If this
+ feature is disabled, the branches created by 'git svn' will all
+ be linear and not share any history, meaning that there will be
+ no information on where branches where branched off or merged.
+ However, following long/convoluted histories can take a long
+ time, so disabling this feature may speed up the cloning
+ process. This feature is enabled by default, use
--no-follow-parent to disable it.
+
[verse]
--
1.7.10.4
^ permalink raw reply related
* [PATCH v2 4/4] git-svn: Note about tags.
From: Sebastian Leske @ 2012-11-30 7:16 UTC (permalink / raw)
To: git; +Cc: Michael J Gruber, Eric Wong
In-Reply-To: <cover.1354324110.git.Sebastian.Leske@sleske.name>
Document that 'git svn' will import SVN tags as branches.
Signed-off-by: Sebastian Leske <sebastian.leske@sleske.name>
---
Documentation/git-svn.txt | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 6bda014..18d5e45 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -959,6 +959,13 @@ the possible corner cases (git doesn't do it, either). Committing
renamed and copied files is fully supported if they're similar enough
for git to detect them.
+SVN tags (if tracked using options '--tags' or '--stdlayout') are
+imported as git branches, prefixing the tag name with 'tags/'.
+This is because tags in SVN behave more like git branches: The contents
+of a tag need not be identical to the tagged commit, and it is possible
+(though discouraged) to commit changes to a tag (because a tag is just a
+directory copy, thus technically the same as a branch).
+
CONFIGURATION
-------------
--
1.7.10.4
^ permalink raw reply related
* [PATCH v2 2/4] Recommend use of structure options for git svn.
From: Sebastian Leske @ 2012-11-30 7:16 UTC (permalink / raw)
To: git; +Cc: Michael J Gruber, Eric Wong
In-Reply-To: <cover.1354324110.git.Sebastian.Leske@sleske.name>
Document that when using git svn, one should usually either use the
directory structure options to import branches as branches, or only
import one subdirectory. The default behaviour of cloning all branches
and tags as subdirectories in the working copy is usually not what the
user wants.
Signed-off-by: Sebastian Leske <sebastian.leske@sleske.name>
---
Documentation/git-svn.txt | 24 +++++++++++++++++++++---
1 file changed, 21 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 824bf82..bfa8788 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -739,7 +739,8 @@ for rewriteRoot and rewriteUUID which can be used together.
BASIC EXAMPLES
--------------
-Tracking and contributing to the trunk of a Subversion-managed project:
+Tracking and contributing to the trunk of a Subversion-managed project
+(ignoring tags and branches):
------------------------------------------------------------------------
# Clone a repo (like git clone):
@@ -764,8 +765,10 @@ Tracking and contributing to an entire Subversion-managed project
(complete with a trunk, tags and branches):
------------------------------------------------------------------------
-# Clone a repo (like git clone):
- git svn clone http://svn.example.com/project -T trunk -b branches -t tags
+# Clone a repo with standard SVN directory layout (like git clone):
+ git svn clone http://svn.example.com/project --stdlayout
+# Or, if the repo uses a non-standard directory layout:
+ git svn clone http://svn.example.com/project -T tr -b branch -t tag
# View all branches and tags you have cloned:
git branch -r
# Create a new branch in SVN
@@ -871,6 +874,21 @@ already dcommitted. It is considered bad practice to --amend commits
you've already pushed to a remote repository for other users, and
dcommit with SVN is analogous to that.
+When cloning an SVN repository, if none of the options for describing
+the repository layout is used (--trunk, --tags, --branches,
+--stdlayout), 'git svn clone' will create a git repository with
+completely linear history, where branches and tags appear as separate
+folders in the working copy. While this is the easiest way to get a
+copy of a complete repository, for projects with many branches it will
+lead to a working copy many times larger than just the trunk. Thus for
+projects using the standard directory structure (trunk/branches/tags),
+it is recommended to clone with option '--stdlayout'. If the project
+uses a non-standard structure, and/or if branches and tags are not
+required, it is easiest to only clone one directory (typically trunk),
+without giving any repository layout options. If the full history with
+branches and tags is required, the options '--trunk' / '--branches' /
+'--tags' must be used.
+
When using multiple --branches or --tags, 'git svn' does not automatically
handle name collisions (for example, if two branches from different paths have
the same name, or if a branch and a tag have the same name). In these cases,
--
1.7.10.4
^ permalink raw reply related
* [PATCH v2 0/4] git-svn: More docs for branch handling in
From: Sebastian Leske @ 2012-12-01 1:08 UTC (permalink / raw)
To: git; +Cc: Michael J Gruber, Eric Wong
Updated version of my documentation patch for git-svn. Thanks to Michael
J Gruber and Eric Wong for helpful comments.
Sebastian Leske (4):
git-svn: Document branches with at-sign(@).
Recommend use of structure options for git svn.
git-svn: Expand documentation for --follow-parent
git-svn: Note about tags.
Documentation/git-svn.txt | 84 +++++++++++++++++++++++++++++++++++++++++----
1 file changed, 78 insertions(+), 6 deletions(-)
--
1.7.10.4
^ permalink raw reply
* [PATCH v2 1/4] git-svn: Document branches with at-sign(@).
From: Sebastian Leske @ 2012-11-30 7:16 UTC (permalink / raw)
To: git; +Cc: Michael J Gruber, Eric Wong
In-Reply-To: <cover.1354324110.git.Sebastian.Leske@sleske.name>
git svn will sometimes create branches with an at-sign in the name
(branchname@revision). These branches confuse many users and it is a FAQ
why they are created. Document when git svn will create them.
Signed-off-by: Sebastian Leske <sebastian.leske@sleske.name>
---
Documentation/git-svn.txt | 38 ++++++++++++++++++++++++++++++++++++++
1 file changed, 38 insertions(+)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 8b0d3ad..824bf82 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -881,6 +881,44 @@ different name spaces. For example:
branches = stable/*:refs/remotes/svn/stable/*
branches = debug/*:refs/remotes/svn/debug/*
+If 'git svn' is configured to fetch branches (and --follow-branches
+is in effect), it will sometimes create multiple branches for one SVN
+branch, where the addtional branches have names of the form
+'branchname@nnn' (with nnn an SVN revision number). These additional
+branches are created if 'git svn' cannot find a parent commit for the
+first commit in an SVN branch, to connect the branch to the history of
+the other branches. Normally, the first commit in an SVN branch consists
+of a copy operation. 'git svn' will read this commit to get the SVN
+revision the branch was created (copied) from. It will then try to find the
+git commit that corresponds to this SVN revision, and use that as the
+parent of the branch. However, it is possible that there is no suitable
+git commit to serve as parent. This will happen, among other reasons,
+if the SVN branch is a copy of a revision that was not fetched by 'git
+svn' (e.g. because it is an old revision that was skipped with
+'--revision'), or if in SVN a directory was copied that is not tracked
+by 'git svn' (such as a branch that is not tracked at all, or a
+subdirectory of a tracked branch). In these cases, 'git svn' will still
+create a git branch, but instead of using an existing git commit as the
+parent of the branch, it will read the SVN history of the directory the
+branch was copied from and create appropriate git commits (this is
+indicated by the message "Initializing parent: <branchname>").
+Additionally, it will create a special branch named
+'<branchname>@<SVN-Revision>', where <SVN-Revision> is the SVN revision
+number the branch was copied from. This branch will point to the newly
+created parent commit of the branch. If in SVN the branch was deleted
+and later recreated from a different version, there will be multiple
+such branches with an '@'.
+Note that this may mean that multiple git commits are created for a
+single SVN revision. An example: In an SVN repository with a standard
+trunk/tags/branches layout, a directory trunk/sub is created in r.100.
+In r.200, trunk/sub is branched by copying it to branches/. 'git svn
+clone -s' will then create a branch 'sub'. It will also create new git
+commits for r.100 through r.199 and use these as the history of branch
+'sub'. Thus there will be two git commits for each revision from r.100
+to r.199 (one containing trunk/, one containing trunk/sub/). Finally,
+it will create a branch 'sub@200' pointing to the new parent commit of
+branch 'sub' (i.e. the commit for r.200 and trunk/sub/).
+
BUGS
----
--
1.7.10.4
^ 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