Re: [PATCH v2 44/44] request-pull: rewrite to C
Felipe Contreras wrote: builtin/request-pull.c | 275 + git-request-pull.rb| 199 --- My head started hurting beyond part 15: I need more coffee ;) Right now, I'm looking at these two side by side: https://github.com/felipec/git/blob/724e759e777e21ddc1e1a77b5bad16a301dffe38/git-request-pull.rb https://github.com/felipec/git/blob/68dd43654e265d8ebe42daf43646c636d3f0ff99/builtin/request-pull.c Truly beautiful. No more kitchen-sink-dependency-embedded-lua-language-war-flame fud. I look forward to more eyes, and a clean merge. Part 2 is missing a commit message, but the rest of your series looks very reasonable. Thanks a lot for doing this! You've opened the door for an incredible amount of learning opportunities. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Local tag killer
On Sun, Sep 29, 2013 at 6:29 AM, Michael Haggerty mhag...@alum.mit.edu wrote: I wonder whether remotes.group could sensibly be used to group remotes into logical groups for value lookups: [remotes] gitk = gitk-origin gitk = second-gitk-repo Then DWIM could be taught to seek gitk/foo under refs/remotes/gitk-origin/tags/foo and refs/remotes/second-gitk-repo/tags/foo in addition to refs/tags/gitk/foo (insisting, of course, that if more than one of these are present that they are all consistent). This is an interesting idea. AFAICS, remotes.group is currently only used by git remote update and git fetch. According to git-remote(1) it's used like this: [git remote] update Fetch updates for a named set of remotes in the repository as defined by remotes.group. If a named group is not specified on the command line, the configuration parameter remotes.default will be used; if remotes.default is not defined, all remotes which do not have the configuration parameter remote.name.skipDefaultUpdate set to true will be updated. (See git-config(1)). I believe this would work well when extended to ref lookup as well: - Defining remotes.$group allows you to lookup refs across the grouped remotes by using the $group/ref syntax, as you describe above. - If remotes.default is defined, ref lookup happens by default across only those remotes, i.e. $tag will be sought under refs/tags/$tag and then refs/remotes/$remote/tags/$tag for each $remote in remotes.default. - If remotes.default is not defined, ref lookup happens across all remotes. This is analogous to what happens with tags today; they are all dumped into refs/tags/* and lookup considers all of them. Remote groups might also be used to configure the remotes that describe considers when describing a commit: [remotes] describe = junio describe = jrn or maybe (using the above config) git describe --remote-group=gitk Hmm. I'd like to apply the same rules here, to stay consistent: - git describe --from=$remote1 --from=$remote2 considers tags from refs/remotes/$remote1/tags/* and refs/remotes/$remote2/tags/* - git describe --from=$group considers tags from refs/remotes/$remote/tags/* for each $remote in $group - git describe considers tags from all remotes mentioned in remotes.default, or _all_ remotes is remotes.default is unset. Additionally: - git describe (without --from) also considers (and prefers?) local tags. - git describe --from=foo does NOT consider local tags, but will also consider them if --from=. is used. ...Johan -- Johan Herland, jo...@herland.net www.herland.net -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Loan Offer
We offer Loan for 3% if you are interested do send details.contact Mr Tony Bowyer: coastalfinanceloanf...@hotmail.com This message was sent using IMP, the Internet Messaging Program. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] [PATCH] mingw-multibyte: fix memory acces violation and path length limits.
On 09/29/2013 04:56 AM, Wataru Noguchi wrote: - gcc optimization level is O2.(fail) - gcc O0, O1 works fine. Maybe you could try to compile with STACK found at http://css.csail.mit.edu/stack/ That tool is designed to find Optimization-unstable code. signature.asc Description: OpenPGP digital signature
Re: [PATCH] builtin/push.c: Add `--notes` option
On Fri, Sep 20, 2013 at 2:20 PM, Rodolphe Belouin rodolphe.belo...@gmail.com wrote: Make the user able to call `git push --notes` instead of `git push refs/notes/*` I'm sorry for not replying to this earlier. I'm unsure how much of the earlier discussions around pushing and pulling notes you have followed, but the short story is that (as demontrated by the script in [1]) pushing and pulling notes is not as simple as it might initially seem. Notes behave more like branches than tags (in that we expect them to change over time, and we (often) want to collaborate on advancing them). In order to support distributed collaboration on branches, we have remote-tracking branches (remotes/$remote/$branch) and associated behavior in git, which keeps track of the state of other repos, and supports the integration of remote and local changes. That infrastructure does not yet exist for notes. As a result, collaborating on notes quickly becomes painful when you have to fetch magic refspecs and manually orchestrate the integration of remote and local notes changes (as shown in [1]). The proposed solution for this is to reorganize the refs/remotes/ hierarchy to allow for remote-tracking notes in addition to remote-tracking branches (and also other kinds of remote-tracking refs). However this reorganization is itself a big project and will not be completed in the short term. So, how does this apply to your patch? There is (AFAICS) nothing wrong with the patch itself (except maybe some added tests would be nice...), but we must consider its implications and how it guides the use of notes. First, as you state in the commit message, this allows use of a simple option instead of a supplying a refspec. And as long as you are the only person pushing notes into that repo (and you only fast-forward), this should work well, and lower the barrier for exchanging notes with a remote repo. However, as soon as you start collaborating with others, you will need to integrate their changes, and that's where current Git stops providing any help: You are left to do the manual integration shown in [1]. This integration requires you to know about and juggle refspecs quite intimately, and it could even be argued that the simplicity of git push --notes tricks an unsuspecting user into a future manual integration regime that is probably outside most git users' comfort zone... That said, if there is consensus that push --notes is valuable in the short term (before the larger remote refs reorg is complete), and that it won't set a user interface precedent that will obviously be broken by said reorg, then I am not opposed to this patch. Hope this helps, ...Johan [1]: #!/bin/sh set -e rm -rf notes_test_area mkdir notes_test_area cd notes_test_area # Prepare server with initial note git init server cd server echo foofoo git add foo git commit -m foo git notes add -m Initial note on foo echo bar foo git commit -a -m bar cd .. # Clone two clients and transfer notes git clone server clientA cd clientA git fetch origin refs/notes/commits:refs/notes/commits cd .. git clone server clientB cd clientB git fetch origin refs/notes/commits:refs/notes/commits cd .. # Add notes in both clients cd clientA git notes add -m clientA's note on bar cd ../clientB git notes add -m clientB's note on bar cd .. # Push notes from clientA cd clientA git push origin 'refs/notes/*' # This works cd .. # Push notes from clientB cd clientB git push origin 'refs/notes/*' || echo This command fails! # Must merge changes from origin's refs/notes/commits into our own # refs/notes/commits, but there is no built-in machinery to do so. # Do it manually instead: git fetch origin refs/notes/commits:refs/notes/commits_from_origin git notes merge commits_from_origin || echo Oops, conflict! # Conflict in .git/NOTES_MERGE_WORKTREE/$SHA1. Resolve manually commit=$(git rev-parse HEAD) echo clientA's and clientB's notes on bar .git/NOTES_MERGE_WORKTREE/$commit # Commit conflict resolution to finalize notes merge git notes merge --commit # Remove temporary placeholder for origin's notes git update-ref -d refs/notes/commits_from_origin # Now we can finally try to push again git push origin 'refs/notes/*' # This works cd .. # Behold the end result cd server git log --graph -p -c refs/notes/commits cd .. echo done -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Makefile: suppress false positive warnings of empty format string.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index de3d72c..60afa51 100644 --- a/Makefile +++ b/Makefile @@ -349,7 +349,7 @@ GIT-VERSION-FILE: FORCE # CFLAGS and LDFLAGS are for the users to override from the command line. -CFLAGS = -g -O2 -Wall +CFLAGS = -g -O2 -Wall -Wno-format-zero-length LDFLAGS = ALL_CFLAGS = $(CPPFLAGS) $(CFLAGS) ALL_LDFLAGS = $(LDFLAGS) -- 1.8.4.474.g128a96c -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Makefile: suppress false positive warnings of empty format string.
On Sun, Sep 29, 2013 at 7:08 AM, Stefan Beller stefanbel...@googlemail.com wrote: Signed-off-by: Stefan Beller stefanbel...@googlemail.com --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index de3d72c..60afa51 100644 --- a/Makefile +++ b/Makefile @@ -349,7 +349,7 @@ GIT-VERSION-FILE: FORCE # CFLAGS and LDFLAGS are for the users to override from the command line. -CFLAGS = -g -O2 -Wall +CFLAGS = -g -O2 -Wall -Wno-format-zero-length Oh yes please. However, somebody mentioned that this might break compilers other than gcc, but perhaps we can do what Linux does: cc-disable-warning = $(call try-run,\ $(CC) $(CFLAGS) -W$(strip $(1)) -c -x c /dev/null -o $$TMP,-Wno-$(strip $(1))) CFLAGS = -g -O2 -Wall $(call cc-disable-warning,format-zero-length,) -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Makefile: suppress false positive warnings of empty format string.
On 29/09/13 16:07, Felipe Contreras wrote: On Sun, Sep 29, 2013 at 7:08 AM, Stefan Beller stefanbel...@googlemail.com wrote: Signed-off-by: Stefan Beller stefanbel...@googlemail.com --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index de3d72c..60afa51 100644 --- a/Makefile +++ b/Makefile @@ -349,7 +349,7 @@ GIT-VERSION-FILE: FORCE # CFLAGS and LDFLAGS are for the users to override from the command line. -CFLAGS = -g -O2 -Wall +CFLAGS = -g -O2 -Wall -Wno-format-zero-length Oh yes please. However, somebody mentioned that this might break compilers other than gcc, but perhaps we can do what Linux does: I simply added: CFLAGS+=-Wno-format-zero-length to my config.mak file. I had originally intended to do so conditionally, depending on the compiler being gcc, but I found that clang and tcc just ignored it ... cc-disable-warning = $(call try-run,\ $(CC) $(CFLAGS) -W$(strip $(1)) -c -x c /dev/null -o $$TMP,-Wno-$(strip $(1))) CFLAGS = -g -O2 -Wall $(call cc-disable-warning,format-zero-length,) ATB, Ramsay Jones -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] build: fix installation of scripts
They need the gitexecdir. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- Otherwise this makes it difficult to package contrib scripts in certain distributions. For example, if you have a proper Makefile in contrib: --- TESTS := $(wildcard test*.sh) SCRIPTS := $(wildcard git-remote-*.py) export T := $(addprefix $(CURDIR)/,$(TESTS)) export MAKE := $(MAKE) -e export PATH := $(CURDIR):$(PATH) export TEST_LINT := test-lint-executable test-lint-shell-syntax export SCRIPT_PYTHON := $(addprefix $(CURDIR)/,$(SCRIPTS)) all: $(SCRIPTS) $(MAKE) -C ../.. build-python-script install: $(MAKE) -C ../.. install-python-script test: all $(MAKE) -C ../../t $@ $(TESTS): all $(MAKE) -C ../../t $(CURDIR)/$@ .PHONY: all install test $(TESTS) --- A packager might create a git-bzr package that does this: % make -C contrib/remote-helpers install But that would fail, unless this patch is applied. Distributions like Arch Linux don't have a concept of multiple binary packages from a single source package, so there would need to be a separate PKGBUILD (akin to spec file) for git-bzr. In addition this package might not be official, but part of the user maintained AUR. Similarly, other distributions might want to package git-bzr separetly, for example from launchpad. Makefile | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/Makefile b/Makefile index 3588ca1..e51b92e 100644 --- a/Makefile +++ b/Makefile @@ -511,12 +511,14 @@ build-perl-script: $(SCRIPT_PERL_GEN) build-sh-script: $(SCRIPT_SH_GEN) build-python-script: $(SCRIPT_PYTHON_GEN) -.PHONY: install-perl-script install-sh-script install-python-script -install-sh-script: $(SCRIPT_SH_INS) +.PHONY: install-gitexecdir install-perl-script install-sh-script install-python-script +install-gitexecdir: + $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitexec_instdir_SQ)' +install-sh-script: $(SCRIPT_SH_INS) | install-gitexecdir $(INSTALL) $^ '$(DESTDIR_SQ)$(gitexec_instdir_SQ)' -install-perl-script: $(SCRIPT_PERL_INS) +install-perl-script: $(SCRIPT_PERL_INS) | install-gitexecdir $(INSTALL) $^ '$(DESTDIR_SQ)$(gitexec_instdir_SQ)' -install-python-script: $(SCRIPT_PYTHON_INS) +install-python-script: $(SCRIPT_PYTHON_INS) | install-gitexecdir $(INSTALL) $^ '$(DESTDIR_SQ)$(gitexec_instdir_SQ)' .PHONY: clean-perl-script clean-sh-script clean-python-script -- 1.8.4-fc -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/9] http: update base URLs when we see redirects
On Sat, Sep 28, 2013 at 04:34:05AM -0400, Jeff King wrote: Subsequent requests will not be for info/refs, but for other paths relative to the base. We must ask the caller to pass in the original base, and we must pass the redirected base back to the caller (so that it can generte more URLs s/generte/generate/ from it). Furthermore, we need to feed the new base to the credential code, so that requests to credential helpers (or to the user) match the URL we will be requesting. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: [PATCH] Makefile: suppress false positive warnings of empty format string.
Hi, Stefan Beller wrote: --- a/Makefile +++ b/Makefile @@ -349,7 +349,7 @@ GIT-VERSION-FILE: FORCE # CFLAGS and LDFLAGS are for the users to override from the command line. -CFLAGS = -g -O2 -Wall +CFLAGS = -g -O2 -Wall -Wno-format-zero-length Thanks for taking this on. Two thoughts: 1) As Felipe mentioned, this isn't portable. Would it make sense to make it conditional on the value of $(CC) or the output of $(CC) --version? 2) I don't understand the value of -Wformat-zero-length at all. What bug is it meant to prevent? Do you know if anyone has asked the GCC maintainers to disable it from the default set of warnings in -Wall, which would give us a bug number to point to? 3) Since we don't enable -Werror by default (which is really good --- use of -Werror can be a fine development tool but is a terrible default), the warning does not actually do much harm. When it becomes harmful is when someone turns on -Werror for static analysis purposes and is unable to move forward from there. Do we document suggested pedantic compiler flags anywhere other than the todo:Make script? Should we? I suspect such a documentation fix would have more impact, since it could encourage people to experiment with flags and to check their code strictly even when warnings are not portable, without significantly slowing down the normal build. For reference, todo:Make suggests the following flags: -Wpointer-arith -Woverflow -Wunused \ -Wno-pointer-to-int-cast -Werror \ -Wold-style-definition std=c99 -O2 \ -Wall -Wdeclaration-after-statement -Wno-format-zero-length -g Hope that helps, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/9] http: update base URLs when we see redirects
On Sat, Sep 28, 2013 at 4:34 AM, Jeff King p...@peff.net wrote:
diff --git a/http.c b/http.c
index 65a0048..8775b5c 100644
--- a/http.c
+++ b/http.c
@@ -921,11 +921,71 @@ static int http_request_reauth(const char *url,
+static int update_url_from_redirect(struct strbuf *base,
+ const char *asked,
+ const struct strbuf *got)
+{
+ const char *tail;
+ size_t tail_len;
+
+ if (!strcmp(asked, got-buf))
+ return 0;
+
+ if (strncmp(asked, base-buf, base-len))
+ die(BUG: update_url_from_redirect: %s is not a superset of
%s,
+ asked, base-buf);
Is there something non-obvious going on here? die(...,base-buf) takes
advantage of the terminating NUL promised by strbuf, but then
strncmp(...,base-buf,base-len) is used rather than the simpler
strcmp(...,base-buf).
+ tail = asked + base-len;
+ tail_len = strlen(tail);
+
+ if (got-len tail_len ||
+ strcmp(tail, got-buf + got-len - tail_len))
+ return 0; /* insane redirect scheme */
+
+ strbuf_reset(base);
+ strbuf_add(base, got-buf, got-len - tail_len);
+ return 1;
+}
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/9] http: update base URLs when we see redirects
On Sun, Sep 29, 2013 at 03:26:45PM -0400, Eric Sunshine wrote:
On Sat, Sep 28, 2013 at 4:34 AM, Jeff King p...@peff.net wrote:
diff --git a/http.c b/http.c
index 65a0048..8775b5c 100644
--- a/http.c
+++ b/http.c
@@ -921,11 +921,71 @@ static int http_request_reauth(const char *url,
+static int update_url_from_redirect(struct strbuf *base,
+ const char *asked,
+ const struct strbuf *got)
+{
+ const char *tail;
+ size_t tail_len;
+
+ if (!strcmp(asked, got-buf))
+ return 0;
+
+ if (strncmp(asked, base-buf, base-len))
+ die(BUG: update_url_from_redirect: %s is not a superset of
%s,
+ asked, base-buf);
Is there something non-obvious going on here? die(...,base-buf) takes
advantage of the terminating NUL promised by strbuf, but then
strncmp(...,base-buf,base-len) is used rather than the simpler
strcmp(...,base-buf).
Yes, we are not checking for equality, but rather making sure that
asked begins with base-buf. It might be more clearly written as:
if (prefixcmp(asked, base-buf))
I was trying to take advantage of the fact that we know base-len
already, but this it not a particularly performance-critical code path.
We can afford the extra strlen that prefixcmp will do.
-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/9] http: update base URLs when we see redirects
On Sun, Sep 29, 2013 at 3:32 PM, Jeff King p...@peff.net wrote:
On Sun, Sep 29, 2013 at 03:26:45PM -0400, Eric Sunshine wrote:
On Sat, Sep 28, 2013 at 4:34 AM, Jeff King p...@peff.net wrote:
diff --git a/http.c b/http.c
index 65a0048..8775b5c 100644
--- a/http.c
+++ b/http.c
@@ -921,11 +921,71 @@ static int http_request_reauth(const char *url,
+static int update_url_from_redirect(struct strbuf *base,
+ const char *asked,
+ const struct strbuf *got)
+{
+ const char *tail;
+ size_t tail_len;
+
+ if (!strcmp(asked, got-buf))
+ return 0;
+
+ if (strncmp(asked, base-buf, base-len))
+ die(BUG: update_url_from_redirect: %s is not a superset
of %s,
+ asked, base-buf);
Is there something non-obvious going on here? die(...,base-buf) takes
advantage of the terminating NUL promised by strbuf, but then
strncmp(...,base-buf,base-len) is used rather than the simpler
strcmp(...,base-buf).
Yes, we are not checking for equality, but rather making sure that
asked begins with base-buf. It might be more clearly written as:
Ah right, I knew that that was the intention but had a synapse
misfire. Sorry for the noise.
if (prefixcmp(asked, base-buf))
I was trying to take advantage of the fact that we know base-len
already, but this it not a particularly performance-critical code path.
We can afford the extra strlen that prefixcmp will do.
-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/4] git-svn.txt: miscellaneous changes
I'm not sure if this was the best way to split my changes into commits. Please let me know if it wasn't. Keshav Kini (4): git-svn.txt: fix AsciiDoc formatting error git-svn.txt: reword description of gc command git-svn.txt: replace .git with $GIT_DIR git-svn.txt: elaborate on rev_map files Documentation/git-svn.txt | 46 +- 1 file changed, 33 insertions(+), 13 deletions(-) -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/4] git-svn.txt: replace .git with $GIT_DIR
As $GIT_DIR may not equal '.git', it's usually more generally correct to refer to files in $GIT_DIR rather than in .git . This will also allow me to link some of the occurrences of '.git' in git-svn.txt to a new reference target inside this file in an upcoming commit, because in AsciiDoc definitions apparently can't start with a '.' character. Signed-off-by: Keshav Kini keshav.k...@gmail.com --- Documentation/git-svn.txt | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index 62ec727..3ddf545 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -104,8 +104,8 @@ COMMANDS 'fetch':: Fetch unfetched revisions from the Subversion remote we are tracking. The name of the [svn-remote ...] section in the - .git/config file may be specified as an optional command-line - argument. + $GIT_DIR/config file may be specified as an optional + command-line argument. --localtime;; Store Git commit times in the local timezone instead of UTC. This @@ -684,7 +684,7 @@ svn-remote.name.noMetadata:: + This option can only be used for one-shot imports as 'git svn' will not be able to fetch again without metadata. Additionally, -if you lose your .git/svn/\*\*/.rev_map.* files, 'git svn' will not +if you lose your $GIT_DIR/svn/\*\*/.rev_map.* files, 'git svn' will not be able to rebuild them. + The 'git svn log' command will not work on repositories using @@ -977,8 +977,8 @@ 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, use 'init' to set up your Git repository then, before your first 'fetch', edit -the .git/config file so that the branches and tags are associated with -different name spaces. For example: +the $GIT_DIR/config file so that the branches and tags are associated +with different name spaces. For example: branches = stable/*:refs/remotes/svn/stable/* branches = debug/*:refs/remotes/svn/debug/* @@ -1006,7 +1006,7 @@ CONFIGURATION - 'git svn' stores [svn-remote] configuration information in the -repository .git/config file. It is similar the core Git +repository $GIT_DIR/config file. It is similar the core Git [remote] sections except 'fetch' keys do not accept glob arguments; but they are instead handled by the 'branches' and 'tags' keys. Since some SVN repositories are oddly @@ -1060,8 +1060,8 @@ $ git svn branch -d branches/server release-2-3-0 Note that git-svn keeps track of the highest revision in which a branch or tag has appeared. If the subset of branches or tags is changed after -fetching, then .git/svn/.metadata must be manually edited to remove (or -reset) branches-maxRev and/or tags-maxRev as appropriate. +fetching, then $GIT_DIR/svn/.metadata must be manually edited to remove +(or reset) branches-maxRev and/or tags-maxRev as appropriate. SEE ALSO -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/4] git-svn.txt: fix AsciiDoc formatting error
As asterisks are used to indicate bold text in AsciiDoc, shell glob expressions must be escaped appropriately. Signed-off-by: Keshav Kini keshav.k...@gmail.com --- Documentation/git-svn.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index 4dd3bcb..239c33c 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -684,7 +684,7 @@ svn-remote.name.noMetadata:: + This option can only be used for one-shot imports as 'git svn' will not be able to fetch again without metadata. Additionally, -if you lose your .git/svn/**/.rev_map.* files, 'git svn' will not +if you lose your .git/svn/\*\*/.rev_map.* files, 'git svn' will not be able to rebuild them. + The 'git svn log' command will not work on repositories using -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/4] git-svn.txt: reword description of gc command
It's redundant to say that $GIT_DIR/svn/refname/unhandled.log or $GIT_DIR/svn/refname/index is in .git/svn when $GIT_DIR is '.git', and is wrong when $GIT_DIR is not '.git' Also, a '/' was missing from the pathname $GIT_DIR/svn/refname/index . Signed-off-by: Keshav Kini keshav.k...@gmail.com --- Documentation/git-svn.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index 239c33c..62ec727 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -435,8 +435,8 @@ Any other arguments are passed directly to 'git log' specific revision. 'gc':: - Compress $GIT_DIR/svn/refname/unhandled.log files in .git/svn - and remove $GIT_DIR/svn/refnameindex files in .git/svn. + Compress $GIT_DIR/svn/refname/unhandled.log files and remove + $GIT_DIR/svn/refname/index files. 'reset':: Undoes the effects of 'fetch' back to the specified revision. -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/4] git-svn.txt: elaborate on rev_map files
The man page for `git svn` describes a situation in which 'git svn' will not be able to rebuild your $GIT_DIR/svn/**/.rev_map* files, but no mention is made of in what circumstances `git svn` *will* be able to do so, how to get `git svn` to do so, or even what these files are. This patch adds a FILES section to the man page with a description of what $GIT_DIR/svn/**/.rev_map* files are and how they are (re)built, and links to this description from various other parts of the man page. Signed-off-by: Keshav Kini keshav.k...@gmail.com --- Documentation/git-svn.txt | 28 1 file changed, 24 insertions(+), 4 deletions(-) diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt index 3ddf545..5383496 100644 --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -106,6 +106,9 @@ COMMANDS tracking. The name of the [svn-remote ...] section in the $GIT_DIR/config file may be specified as an optional command-line argument. ++ +This automatically updates the rev_map if needed (see +'$GIT_DIR/svn/\*\*/.rev_map.*' in the FILES section below for details). --localtime;; Store Git commit times in the local timezone instead of UTC. This @@ -201,6 +204,9 @@ accept. However, '--fetch-all' only fetches from the current + Like 'git rebase'; this requires that the working tree be clean and have no uncommitted changes. ++ +This automatically updates the rev_map if needed (see +'$GIT_DIR/svn/\*\*/.rev_map.*' in the FILES section below for details). -l;; --local;; @@ -449,9 +455,10 @@ Any other arguments are passed directly to 'git log' file cannot be ignored forever (with --ignore-paths) the only way to repair the repo is to use 'reset'. + -Only the rev_map and refs/remotes/git-svn are changed. Follow 'reset' -with a 'fetch' and then 'git reset' or 'git rebase' to move local -branches onto the new tree. +Only the rev_map and refs/remotes/git-svn are changed (see +'$GIT_DIR/svn/\*\*/.rev_map.*' in the FILES section below for details). +Follow 'reset' with a 'fetch' and then 'git reset' or 'git rebase' to +move local branches onto the new tree. -r n;; --revision=n;; @@ -684,7 +691,7 @@ svn-remote.name.noMetadata:: + This option can only be used for one-shot imports as 'git svn' will not be able to fetch again without metadata. Additionally, -if you lose your $GIT_DIR/svn/\*\*/.rev_map.* files, 'git svn' will not +if you lose your '$GIT_DIR/svn/\*\*/.rev_map.*' files, 'git svn' will not be able to rebuild them. + The 'git svn log' command will not work on repositories using @@ -1063,6 +1070,19 @@ or tag has appeared. If the subset of branches or tags is changed after fetching, then $GIT_DIR/svn/.metadata must be manually edited to remove (or reset) branches-maxRev and/or tags-maxRev as appropriate. +FILES +- +$GIT_DIR/svn/\*\*/.rev_map.*:: + Mapping between Subversion revision numbers and Git commit + names. In a repository where the noMetadata option is not set, + this can be rebuilt from the git-svn-id: lines that are at the + end of every commit (see the 'svn.noMetadata' section above for + details). ++ +'git svn fetch' and 'git svn rebase' automatically update the rev_map +if it is missing or not up to date. 'git svn reset' automatically +rewinds it. + SEE ALSO linkgit:git-rebase[1] -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
для Вас распахнутся Необычные возможносттак же, так же более не будет помех!
негласное вооружение синьор http://li.ru/go?gl.to/779692
