Re: redundant message in builtin/rm.c
Ralf Thielow ralf.thie...@gmail.com writes:
It's more readable if \n is at the end of a line.
Q_(the following submodule (or one of its nested submodules)\n
uses a .git directory:
Thanks both. Perhaps we should do something like this?
-- 8 --
Subject: builtin/rm.c: consolidate error reporting for removing submodules
We have two (not identical) copies of error reporting when
attempting to remove submodules that have their repositories
embedded within them. Add a helper function so that we do not have
to repeat similar error messages with subtly different wording
without a good reason.
Noticed by Jiang Xin.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/rm.c | 41 -
1 file changed, 20 insertions(+), 21 deletions(-)
diff --git a/builtin/rm.c b/builtin/rm.c
index 5d0c068..694568a 100644
--- a/builtin/rm.c
+++ b/builtin/rm.c
@@ -57,6 +57,21 @@ static void print_error_files(struct string_list *files_list,
}
}
+static void error_removing_concrete_submodules(struct string_list *files, int
*errs)
+{
+ print_error_files(files,
+ Q_(the following submodule (or one of its nested
+submodules)\n
+uses a .git directory:,
+the following submodules (or one of its nested
+submodules)\n
+use a .git directory:, files-nr),
+ _(\n(use 'rm -rf' if you really want to remove
+ it including all of its history)),
+ errs);
+ string_list_clear(files, 0);
+}
+
static int check_submodules_use_gitfiles(void)
{
int i;
@@ -85,16 +100,8 @@ static int check_submodules_use_gitfiles(void)
if (!submodule_uses_gitfile(name))
string_list_append(files, name);
}
- print_error_files(files,
- Q_(the following submodule (or one of its nested
-submodules)\n uses a .git directory:,
-the following submodules (or one of its nested
-submodules)\n use a .git directory:,
-files.nr),
- _(\n(use 'rm -rf' if you really want to remove
- it including all of its history)),
- errs);
- string_list_clear(files, 0);
+
+ error_removing_concrete_submodules(files, errs);
return errs;
}
@@ -236,17 +243,9 @@ static int check_local_mod(unsigned char *head, int
index_only)
or -f to force removal)),
errs);
string_list_clear(files_cached, 0);
- print_error_files(files_submodule,
- Q_(the following submodule (or one of its nested
-submodule)\nuses a .git directory:,
-the following submodules (or one of its nested
-submodule)\nuse a .git directory:,
-files_submodule.nr),
- _(\n(use 'rm -rf' if you really
- want to remove it including all
- of its history)),
- errs);
- string_list_clear(files_submodule, 0);
+
+ error_removing_concrete_submodules(files_submodule, errs);
+
print_error_files(files_local,
Q_(the following file has local modifications:,
the following files have local modifications:,
--
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: [REQUEST 1/1] docs: update http.url.* options documentation
Junio C Hamano gits...@pobox.com writes: Will queue the attached, unless you spot glaring errors made by me, coding while drunk ;-) ... aand, it turns out that I screwed up while running git commit --amend (missed -a). I should go to bed now. -- 8 -- From: Kyle J. McKay mack...@gmail.com Date: Thu, 25 Jul 2013 15:39:13 -0700 Subject: [PATCH] docs: update http.url.* options documentation Overhaul the text of the http.url.* options documentation providing a hopefully easier to understand itemized list of matching behavior as suggested by and including text from Jeff King. Signed-off-by: Jeff King p...@peff.net Signed-off-by: Kyle J. McKay mack...@gmail.com Signed-off-by: Junio C Hamano gits...@pobox.com --- Documentation/config.txt | 63 ++-- 1 file changed, 40 insertions(+), 23 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index 6b135be..60c140f 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -1515,30 +1515,47 @@ http.useragent:: http.url.*:: Any of the http.* options above can be applied selectively to some urls. - For example http.https://example.com.useragent; would set the user - agent only for https connections to example.com. The url value - matches a url if it refers to the same scheme, host and port and the - path portion is an exact match or a prefix that matches at a / - boundary. If url does not include a user name, it will match a url - with any username otherwise the user name must match as well (the - password part, if present in the url, is always ignored). A url - with longer path matches takes precedence over shorter matches no matter - what order they occur in the configuration file. + For a config key to match a URL, each element of the config key is + compared to that of the URL, in the following order: + -For example, if both https://u...@example.com/path; and -https://example.com/path/name; are used as a config url value and -then https://u...@example.com/path/name/here; is passed to a git -command, the settings in the https://example.com/path/name; section -will be preferred because that url has a longer path length match than -https://u...@example.com/path; even though the latter did match the -user. For same length matches, the last one wins except that a same -length url match that includes a user name will be preferred over a -same length url match that does not. The urls are normalized before -matching so that equivalent urls that are simply spelled differently -will match properly. Environment variable settings always override any -matches. The urls that are matched against are those given directly to -git commands. This means any urls visited as a result of a redirection -do not participate in matching. +-- +. Scheme (e.g., `https` in `https://example.com/`). This field + must match exactly between the config key and the URL. + +. Host/domain name (e.g., `example.com` in `https://example.com/`). + This field must match exactly between the config key and the URL. + +. Port number (e.g., `8080` in `http://example.com:8080/`). + This field must match exactly between the config key and the URL. + Omitted port numbers are automatically converted to the correct + default for the scheme before matching. + +. Path (e.g., `repo.git` in `https://example.com/repo.git`). The + path field of the config key must match the path field of the URL + either exactly or as a prefix of slash-delimited path elements. This means + a config key with path `foo/` matches URL path `foo/bar`. A prefix can only + match on a slash (`/`) boundary. Longer matches take precedence (so a config + key with path `foo/bar` is a better match to URL path `foo/bar` than a config + key with just path `foo/`). + +. User name (e.g., `user` in `https://u...@example.com/repo.git`). If + the config key has a user name it must match the user name in the + URL exactly. If the config key does not have a user name, that + config key will match a URL with any user name (including none). +-- ++ +The list above is ordered by decreasing precedence; a URL that matches +a config key's path is preferred to one that matches its user name. For example, +if the URL is `https://u...@example.com/foo/bar` a config key match of +`https://example.com/foo` will be preferred over a config key match of +`https://u...@example.com`. ++ +All URLs are normalized before attempting any matching (the password part, +if embedded in the URL, is always ignored for matching purposes) so that +equivalent urls that are simply spelled differently will match properly. +Environment variable settings always override any matches. The urls that are +matched against are those given directly to Git commands. This means any URLs +visited as a result of a redirection do not participate in matching. i18n.commitEncoding:: Character encoding
Re: [REQUEST 1/1] docs: update http.url.* options documentation
On Jul 25, 2013, at 21:37, Jeff King wrote: On Thu, Jul 25, 2013 at 03:39:13PM -0700, Kyle J. McKay wrote: Overhaul the text of the http.url.* options documentation providing a hopefully easier to understand itemized list of matching behavior as suggested by and including text from Jeff King. --- Signed-off-by: Jeff King p...@peff.net Thank you. Added. You should add your S-O-B, too, for your bits. Yes. I wanted to make certain it didn't get applied just yet. :) +-- +. Scheme (e.g., `https` in `https://example.com/`). This field + must match exactly between the config key and the URL. +. Host/domain name (e.g., `example.com` in `https://example.com/`). + This field must match exactly between the config key and the URL. These look fine in the rendered manpage, but I think the source might be a little easier to read with a blank line between items. My ASCIIDOC is a bit weak. I have added some blank lines. +. Exact user name match (e.g., `user` in `https://u...@example.com/repo.git `). + If the config key has a user name it must match the user name in the URL + exactly. +. Any user name match. If a config key does not have a user name, that config + key will match a URL with any user name (including none). IMHO, this would be more clear as a single item, like: . User name (e.g., `user` in `https://u...@example.com/repo.git`). If the config key has a user name it must match the user name in the URL exactly. If the config key does not have a user name, that config key will match a URL with any user name (including none). The only problem I have with a single item is what's the precedence? Does an exact user match have the same precedence as an any-user match? That would seem to be implied by having them as the same item number. Separating them would appear to make it clearer that an exact user match wins over an any user match, but if you have some alternate text as a suggestion for the single item that clears that up... :) +All URLs are normalized before attempting any matching (the password part, +if embedded in the URL, is always ignored for matching purposes) so that +equivalent urls that are simply spelled differently will match properly. And this nicely ties up the open questions I had after re-reading the list. Good. We could define equivalent here (the %-encoding thing is obvious, I think, but which components are case-sensitive and which are not is perhaps a bit subtle). I do not necessarily know that it is useful to the user, though, and is one more thing to confuse them. And somebody who really cares can look at the appropriate RFCs. I am considering this text to address that: All URLs are normalized (%-encodings are standardized, case- insensitive parts are lowercased, `./` and `../` path components are resolved) before attempting any matching (the password part, if embedded in the URL, but I'm not sure the extra verbiage makes it better. I think it may just complicate the explanation unnecessarily? -- 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: [REQUEST 1/1] docs: update http.url.* options documentation
On Jul 25, 2013, at 23:23, Kyle J. McKay wrote: On Jul 25, 2013, at 21:37, Jeff King wrote: You should add your S-O-B, too, for your bits. Yes. I wanted to make certain it didn't get applied just yet. :) Looks like it got patch snarfed anyway. ;-) On Jul 25, 2013, at 23:07, Junio C Hamano wrote: Junio C Hamano gits...@pobox.com writes: Will queue the attached, unless you spot glaring errors made by me, coding while drunk ;-) On Jul 25, 2013, at 21:37, Jeff King wrote: So this patch looks pretty good to me; the two points I raised above are how I would have done it, but they are relatively minor if you do not agree. So Yeah, looks pretty good to me too then. ;) -- 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: Why can't I push from a shallow clone?
On Thu, Jul 25, 2013 at 07:33:16PM -0700, Gulshan Singh wrote: I've been trying to figure out why I can't push from a shallow clone (using --depth) to a repository. I've made simple examples where it works, but I've read that in doesn't work in every case. However, I can't come up with a case where it doesn't work. Googling gives this answer: http://stackoverflow.com/questions/6900103/why-cant-i-push-from-a-shallow-clone, but I don't completely understand the explanation, so I was hoping someone could explain it. I can't explain it better than what Junio did in the link you just provide. However there's ongoing work to allow shallow clones to be able to push. You can read about it here: http://thread.gmane.org/gmane.comp.version-control.git/230612/focus=230878 -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- 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
Fwd: Kick off for Git 1.8.4 l10n round 1
-- Forwarded message -- Hi, Since Git v1.8.4-rc0 had already been released, it's time to start new round of git l10n. This time there are 99 new messages need to be translated. The new git.pot is generated in commit v1.8.4-rc0-1-g28b3cff: l10n: git.pot: v1.8.4 round 1 (99 new, 46 removed) Generate po/git.pot from v1.8.4-rc0 for git v1.8.4 l10n round 1. Signed-off-by: Jiang Xin worldhello@gmail.com You can get it from the usual place: https://github.com/git-l10n/git-po/ As how to update your XX.po and help to translate Git, please see Updating a XX.po file and other sections in “po/README file. -- Jiang Xin -- 蒋鑫 北京群英汇信息技术有限公司 邮件: worldhello@gmail.com 网址: http://www.ossxp.com/ 博客: http://www.worldhello.net/ 微博: http://weibo.com/gotgit/ 电话: 18601196889 -- 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: git and cyrillic branches
26.07.2013, 05:50, Torsten Bögershausen tbo...@web.de: On 2013-07-25 14.19, иванов иван wrote: hello! there is problem vith git and cyrillic (utf-8) names of branches. branch creates perfectly, but when i clone this remote branch to local host, there are 2 bugs: 1) git branch doesnt show checked branch with asterisk (while on remote server it does) 2) git push gives 2 errors: fatal: BRANCH_NAME cannot be resolved to branch. and fatal: The remote end hung up unexpectedly thanks. It could be helpful if you could provide more information. The best could be a step-by-step instruction using a some mini repo, so that we we can reproduce the problem. I have done an illustrating example using UTF-8, (not cyrillic, I don't have these letters on my keyboard ;-) tb@linux:~$ mkdir cyrill tb@linux:~$ cd cyrill/ tb@linux:~/cyrill$ git init Initialized empty Git repository in /home/tb/cyrill/.git/ tb@linux:~/cyrill$ echo FileFile tb@linux:~/cyrill$ git checkout -b bränch Switched to a new branch 'bränch' tb@linux:~/cyrill$ git add File tb@linux:~/cyrill$ git commit -m Add File [bränch (root-commit) e39d84e] Add File 1 file changed, 1 insertion(+) create mode 100644 File tb@linux:~/cyrill$ git branch * bränch tb@linux:~/cyrill$ tb@macos:~ git clone tb@linux:~/cyrill Cloning into 'cyrill'... tb@linux's password: remote: Counting objects: 3, done. Receiving objects: 100% (3/3), done. remote: Total 3 (delta 0), reused 0 (delta 0) tb@macos:~ cd cyrill/ tb@macos:~/cyrill git branch * bränch tb@macos:~/cyrill ls -l total 8 -rw-r--r-- 1 tb staff 6 Jul 26 03:39 File tb@macos:~/cyrill === Other question: what does (on Mac OS) git config core.precomposeunicode give you? /Torsten okay, i've changed core.precomposeunicode to true and seems it solved the problem, branches are listed just fine and git push goes good as well. i didn't look that way at first time, thought that is case for filenames only, not branches. thank you all for responces, i guess this time problem is really solved now. :) -- 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] git-tag man: when to use lightweight or annotated tags
On 07/25/2013 04:47 PM, Marc Branchaud wrote: On 13-07-25 09:45 AM, Daniele Segato wrote: From d0f4eca712e7cf74286bfab306763a8a571b6c95 Mon Sep 17 00:00:00 2001 From: Daniele Segato daniele.seg...@gmail.com Date: Thu, 25 Jul 2013 15:33:18 +0200 Subject: [PATCH] git-tag man: when to use lightweight or annotated tags stress the difference between the two with suggestion on when the user should use one in place of the other. Signed-off-by: Daniele Segato daniele.seg...@gmail.com --- Documentation/git-tag.txt |4 1 file changed, 4 insertions(+) diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt index 22894cb..48f5504 100644 --- a/Documentation/git-tag.txt +++ b/Documentation/git-tag.txt @@ -36,6 +36,10 @@ are absent, `-a` is implied. Otherwise just a tag reference for the SHA-1 object name of the commit object is created (i.e. a lightweight tag). +Annotated and Lightweight tags are not the same thing for git and you shouldn't +mix them up. Annotated tags are meant for release while lightweight tags are +meant to tag random commits. Unfortunately the word annotated hasn't yet been introduced at this point, so the overall effect is even more confusing. Actually annotated tag has already be introduced but they haven't been named Annotated yet; what about changing the above paragraph like this: If one of `-a`, `-s`, or `-u key-id` is passed, the command -creates a 'tag' object, and requires a tag message. Unless +creates a 'tag' object called 'Annotated tag', and requires a tag message. Unless `-m msg` or `-F file` is given, an editor is started for the user to type in the tag message. Also, I find the release vs. random distinction a bit misleading since both types of tag can refer to any object. I can change it into something like these (using your suggestion below): Annotated tags are meant for release while lightweight tags are meant for private or temporary object labels. What do you think? I also liked the direction of your earlier command only consider annotated tags by default phrasing. I also think it would be helpful. We can write this after the previous sentence: Most git commands only consider Annotated tags by default. After reading the Tagging section of the Git Book[1] I came up with the following. Feel free to modify it as you like, or ignore it completely: Tag objects (created with -a) are called annotated tags. While a lightweight tag is simply a name for an object (usually a commit object), an annotated tag contains the creation date, the tagger's name and e-mail, a tagging message, and can be signed and verified with GNU Privacy Guard (GnuPG). Most git commands only consider annotated tags by default. In general lightweight tags are for private or temporary object labels, while annotated tags are meant to be permanent and/or published. For example, an annotated tag is normally used to identify a release point. M. [1] http://git-scm.com/book/en/Git-Basics-Tagging I took some inspiration but I think writing about what a tag object contains in the documentation is not useful at that point in the doc. What's important there is that user do understand the difference between Annotated and Lightweight tags. I'll follow with a patch containing these modification I'm talking about, should be easier to comment. Regards, Daniele -- 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] git-tag man: when to use lightweight or annotated tags
From 34fdcb56e5784699ffa327ebfcd2c5cd99b61d2d Mon Sep 17 00:00:00 2001 From: Daniele Segato daniele.seg...@gmail.com Date: Thu, 25 Jul 2013 15:33:18 +0200 Subject: [PATCH] git-tag man: when to use lightweight or annotated tags stress the difference between the two with suggestion on when the user should use one in place of the other. Signed-off-by: Daniele Segato daniele.seg...@gmail.com --- Documentation/git-tag.txt |7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt index 22894cb..5c6284e 100644 --- a/Documentation/git-tag.txt +++ b/Documentation/git-tag.txt @@ -26,7 +26,7 @@ to delete, list or verify tags. Unless `-f` is given, the named tag must not yet exist. If one of `-a`, `-s`, or `-u key-id` is passed, the command -creates a 'tag' object, and requires a tag message. Unless +creates a 'tag' object called 'Annotated tag', and requires a tag message. Unless `-m msg` or `-F file` is given, an editor is started for the user to type in the tag message. @@ -36,6 +36,11 @@ are absent, `-a` is implied. Otherwise just a tag reference for the SHA-1 object name of the commit object is created (i.e. a lightweight tag). +'Annotated' and 'Lightweight' tags are not the same thing for git and you shouldn't +mix them up. Annotated tags are meant for release while lightweight tags are +meant for private or temporary object labels. Most git commands only consider +Annotated tags by default. + A GnuPG signed tag object will be created when `-s` or `-u key-id` is used. When `-u key-id` is not used, the committer identity for the current user is used to find the -- 1.7.10.4 -- 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: Why can't I push from a shallow clone?
On Thu, 25 Jul 2013 19:33:16 -0700 Gulshan Singh gsingh2...@gmail.com wrote: I've been trying to figure out why I can't push from a shallow clone (using --depth) to a repository. I've made simple examples where it works, but I've read that in doesn't work in every case. However, I can't come up with a case where it doesn't work. Googling gives this answer: http://stackoverflow.com/questions/6900103/why-cant-i-push-from-a-shallow-clone, but I don't completely understand the explanation, so I was hoping someone could explain it. See also this thread [1] which originated from this SO question [2]. 1. http://thread.gmane.org/gmane.comp.version-control.git/221634 2. http://stackoverflow.com/q/16077691/720999 -- 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
fatal: reference is not a tree: on git checkout branch
Hi, Reproduce: $ git clone https://github.com/cms-sw/cmsdist.git $ git branch -a | grep devel-gcc48 remotes/origin/IB/CMSSW_7_0_X/devel-gcc48 $ git checkout IB/CMSSW_7_0_X/devel-gcc48 fatal: reference is not a tree: IB/CMSSW_7_0_X/devel-gcc48 It has stopped to work with the last pull request. All the references on Google talk about submodules, which I don't use. Any ideas what could be causing this issue? You can get into detached state by: $ git checkout origin/IB/CMSSW_7_0_X/devel-gcc48 You also can checkout a branch by doing: $ git clone -b IB/CMSSW_7_0_X/devel-gcc48 https://github.com/cms-sw/cmsdist.git $ git branch * IB/CMSSW_7_0_X/devel-gcc48 Thanks, david-- 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] send-email: squelch warning from Net::SMTP::SSL
'Twas brillig, and Matthieu Moy at 05/07/13 12:31 did gyre and gimble: Ramkumar Ramachandra artag...@gmail.com writes: John Keeping wrote: I don't think this is really fix, it's more plastering over the problem. It defaulted to SSL_VERIFY_NONE before Net::SMTP::SSL was updated, and the behavior hasn't changed now. The new version simply asks us to be explicit about SSL_VERIFY_NONE, so we are aware about it. We as the Git developers, yes. But your change makes sure users are _not_ aware about it. There's a long history of software ignoring SSL certificates by default, I don't think we should cast in stone that we don't want SSL certificate verification. For what it's worth, after upgrading here, I got this error at the server side: Jul 26 10:15:41 foo.example.com postfix/smtpd[7736]: warning: TLS library problem: 7736:error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca:s3_pkt.c:1256:SSL alert number 48: This is because my postfix doesn't have a ca bundle configured but all other mail clients have been fine before. With the original patch here I could continue. I'd really love to see an option to set this to none in the .gitconfig, but agree with the principle that it should be one by default and the setting should over ride that. All the best Col PS I'm mainly posting this such that people searching the intertubes for the postfix error above and git-send-email will match at least this message and find the fix/workaround :) -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ -- 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
What is the best way to perform a complex refactoring spanning multiple repositories?
Hi, I need to re-organize a project using git. This project currently has 3 separate (central) repositories and I will need to move a large number of files back and forth between them. While doing this, there is development going on on each branch, and the restructuring will take some time. I have been continuously rebasing my refactor branches from master in each respective repository. Is there an established way of doing this sort of complex cross repository refactoring in a way that preserves the history across repositories and takes advantage of git's rename merge logic across repositories, by say moving all repos into a third one, do the merge and move back? Effectively, I have three repositories, A, B, and C. I want to move files from B to A and C and preserve history. This is not a simple move of one directory, but a large number of individual files being moved to new locations, renamed, updated etc. I have been working across A, B, and C, moving and updating files, but this will obviously not keep the history of the files being moved across repositories. I imagine that it would be possible to create a new repository D, import A, B, and C into sub directories, rebase to merge the individual commits on A, B, and C into one new big commit on D that will make git understand that files have been moved across, not just removed in one place and deleted from another, then apply the changes back to each individual repository? Thanks, Kristian -- 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 5/4] document 'allow-tip-sha1-in-want' capability
See 390eb36 (upload-pack: optionally allow fetching from the tips of hidden refs - 2013-01-28) for more information. Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- Maybe this too for completeness.. Documentation/technical/protocol-capabilities.txt | 7 +++ 1 file changed, 7 insertions(+) diff --git a/Documentation/technical/protocol-capabilities.txt b/Documentation/technical/protocol-capabilities.txt index ec131b6..31cbe07 100644 --- a/Documentation/technical/protocol-capabilities.txt +++ b/Documentation/technical/protocol-capabilities.txt @@ -210,3 +210,10 @@ be shown when processing the received pack. A send-pack client should respond with the 'quiet' capability to suppress server-side progress reporting if the local progress reporting is also being suppressed (e.g., via `push -q`, or if stderr does not go to a tty). + +allow-tip-sha1-in-want +-- + +If the upload-pack server advertises this capability, fetch-pack may +send want lines with SHA-1s that exist at the server but are not +advertised by upload-pack. -- 1.8.2.83.gc99314b -- 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: fatal: reference is not a tree: on git checkout branch
On Fri, Jul 26, 2013 at 4:52 PM, David Abdurachmanov david@gmail.com wrote: Hi, Reproduce: $ git clone https://github.com/cms-sw/cmsdist.git $ git branch -a | grep devel-gcc48 remotes/origin/IB/CMSSW_7_0_X/devel-gcc48 $ git checkout IB/CMSSW_7_0_X/devel-gcc48 fatal: reference is not a tree: IB/CMSSW_7_0_X/devel-gcc48 It has stopped to work with the last pull request. All the references on Google talk about submodules, which I don't use. Any ideas what could be causing this issue? Bad naming. It interprets the branch name as something-gHEX like the output from git-describe. Coincidently cc48 is an umambiguous short sha-1. check_tracking_name, which prefix origin/ in, never has a chance to run. We should probably check in get_describe_name() that the returned value is a commit or a tag, but that doesn't really solve the problem. I think check_tracking_name should have higher priority than get_describe_name().. -- Duy -- 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 v3] remotes-hg: bugfix for fetching non local remotes
On 25 Jul 2013, at 21:12, Felipe Contreras felipe.contre...@gmail.com wrote:
[…]
---
contrib/remote-helpers/git-remote-hg | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index 0194c67..f4e9d1c 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -390,7 +390,7 @@ def get_repo(url, alias):
if not os.path.exists(dirname):
os.makedirs(dirname)
else:
-shared_path = os.path.join(gitdir, 'hg')
+shared_path = os.path.join(gitdir, 'hg', '.shared')
if not os.path.exists(shared_path):
try:
hg.clone(myui, {}, url, shared_path, update=False, pull=True)
--
1.8.3.4
I don't like this approach because if it's a huge repository the user
would have to clone again, not only if he was using v1.8.3, but also
if he was using the latest and greatest (because you are changing the
location again). t's relatively trivial to move from the old to the
shared organization, so that's what I vote for. Besides, I don't see
the point of having a '.shared/.hg' directory, and nothing else on
that '.shared' folder.
Agreed… it just was the shortest possible fix with an in my POV minor
optimisation drawback of once refetching...
--
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 v3] remotes-hg: bugfix for fetching non local remotes
On 25 Jul 2013, at 23:10, Antoine Pelisse apeli...@gmail.com wrote: On Thu, Jul 25, 2013 at 10:40 PM, Felipe Contreras felipe.contre...@gmail.com wrote: That's true. Maybe something like: for x in repos: local_hg = os.path.join(shared_path, x, 'clone', '.hg') if os.path.exists(local_hg): shutil.copytree(local_hg, hg_path) break I think that would work yupp, might work, but holding you liable to the same optimality restriction you imposed on me before: This will still refetch the whole repo once if it was cloned from a local hg repo first (they don't have a clone subdir). Shouldn't we then also go through the additional effort and copy the .hg dir from local remotes when a remote remote is added and there's no other remote remote? j -- 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
Git on intranet
Howdy, I want to use Git over the local network in our company because the internet connection isn't stable so I wonder how can I use git with pull request (similar to Github)? As I read about Gitorious.org I found it most candidate but I'm not sure is it supports this feature or maybe there is better open source solutions! -- Best Regards, Muhammad Bashir Al-Noimi -- 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: Git on intranet
On 07/26/2013 03:36 PM, Muhammad Bashir Al-Noimi wrote: Howdy, I want to use Git over the local network in our company because the internet connection isn't stable so I wonder how can I use git with pull request (similar to Github)? As I read about Gitorious.org I found it most candidate but I'm not sure is it supports this feature or maybe there is better open source solutions! Best search result I got is: http://stackoverflow.com/a/2593330 the user says that both *Gitolite* http://sitaramc.github.com/gitolite/ and *Gitorious* http://gitorious.com/local_install/ are very hard to configure!!! What do you suggest? -- Best Regards, Muhammad Bashir Al-Noimi -- 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: Git on intranet
On Fri, 26 Jul 2013 16:21:28 +0200 Muhammad Bashir Al-Noimi mbno...@gmail.com wrote: I want to use Git over the local network in our company because the internet connection isn't stable so I wonder how can I use git with pull request (similar to Github)? Depends on what feature set you imply when you refer to pull request. The problem with the terminology here is that the term pull request might refer both to a social act and to a formal technical action supported by a particular software (Git-hosting or otherwise). I mean, it's perfectly OK for one developer to push a branch in a repository and then ask another developer (directly, by mail or otherwise) to pull the changes from that branch, integrating them into some other branch. I think, for intranet this should cover 99% of use cases. The github software platform allows to formalize this process by providing web interface knobs to do pull requests -- this is useful exactly because it stipulates contributions to a project by *random people.* Conversely, the people working on your projects in your intranet are usually not random, and are usually well connected by corporate e-mail, chat, phone and other means. As I read about Gitorious.org I found it most candidate but I'm not sure is it supports this feature or maybe there is better open source solutions! Best search result I got is: http://stackoverflow.com/a/2593330 the user says that both *Gitolite* http://sitaramc.github.com/gitolite/ and *Gitorious* http://gitorious.com/local_install/ are very hard to configure!!! What do you suggest? As to gitolite, for me personally installing it was a matter of running `apt-get install gitolite` on one of my Debian machines. But administering it might require some getting used to as it uses a special administrative Git repository to manage public SSH keys for your Git developers and configuration of repositories. You will also need to possess at least some level of knowledge about what a Git repository is, after all. But in any case, gitolite only manages repos and users, it has no web UI and no format support for github-style pull requests. Coming back to F/OSS turn-key Git-hosting solutions, GitLab [1] supports github-style pull requests since some version. It's written in Ruby so I, personally, would not touch it to avoid administrative nightmares when the next upgrade comes but YMMV. Gitorious also seems to support merge requests [3] which are actually the same thing, I fancy. Again, Ruby. Gitblit and Girocco seem not to support such a feature yet (but the former appears to have it in the works [2]). 1. http://gitlab.org/ 2. http://code.google.com/p/gitblit/issues/detail?id=215 3. http://gitorious.wordpress.com/2009/07/15/new-merge-request-functionality/ 4. http://repo.or.cz/w/girocco.git -- 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] git-tag man: when to use lightweight or annotated tags
On 13-07-26 04:46 AM, Daniele Segato wrote: From 34fdcb56e5784699ffa327ebfcd2c5cd99b61d2d Mon Sep 17 00:00:00 2001 From: Daniele Segato daniele.seg...@gmail.com Date: Thu, 25 Jul 2013 15:33:18 +0200 Subject: [PATCH] git-tag man: when to use lightweight or annotated tags When sending a patch to the list it's not necessary to include these headers, as the git tools will extract them from the email itself. Also, when sending a revision to a previously posted patch it's customary to include a revision number, e.g. [PATCHv2]. stress the difference between the two with suggestion on when the user should use one in place of the other. Signed-off-by: Daniele Segato daniele.seg...@gmail.com --- Documentation/git-tag.txt |7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt index 22894cb..5c6284e 100644 --- a/Documentation/git-tag.txt +++ b/Documentation/git-tag.txt @@ -26,7 +26,7 @@ to delete, list or verify tags. Unless `-f` is given, the named tag must not yet exist. If one of `-a`, `-s`, or `-u key-id` is passed, the command -creates a 'tag' object, and requires a tag message. Unless +creates a 'tag' object called 'Annotated tag', and requires a tag message. 1) Don't capitalize annotated -- it's not capitalized anywhere else in the text. The same goes for lightweight. 2) I find the phrasing here awkward. The important thing to convey is that annotated tag is a synonym for tag object. The proposed text implies that there can be other kinds of tag objects that are not annotated tags, but I don't think that's true. I've mulled over different ways of introducing the annotated tag term here, but I can't come up with a succinct way to do it. I think it's better to just introduce the term later. Unless `-m msg` or `-F file` is given, an editor is started for the user to type in the tag message. @@ -36,6 +36,11 @@ are absent, `-a` is implied. Otherwise just a tag reference for the SHA-1 object name of the commit object is created (i.e. a lightweight tag). +'Annotated' and 'Lightweight' tags are not the same thing for git and you shouldn't +mix them up. Annotated tags are meant for release while lightweight tags are +meant for private or temporary object labels. Most git commands only consider +Annotated tags by default. + I'm sorry, but I feel this misses the mark. It's redundant to say the tag types are not the same thing, since the fact that they have different names already implies that. Also, to me the admonition you shouldn't mix them up is just a scary warning that conveys no helpful information. Furthermore, I think simply stating that the tag types are meant for particular uses without explaining why is too glib. Although it may be natural in your circumstances to think of the tag types rigidly, I do not think that's true for all git users and I don't think the documentation should assume there's a One True Way to use tags. The text should give readers enough information to decide for themselves how they want to use the different types of tags. That's why I included the annotated tag's contents in my suggestion, so that readers could figure out which tag type best meets their needs. What you've proposed is a step in the right direction, but I think you need to go further. M. -- 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 5/4] document 'allow-tip-sha1-in-want' capability
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: See 390eb36 (upload-pack: optionally allow fetching from the tips of hidden refs - 2013-01-28) for more information. Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- Maybe this too for completeness.. You are absolutely right, and this exists only on the fetch vs upload-pack side, so there is no need to update the introductory text and the change in this patch is sufficient and complete. Thanks. Documentation/technical/protocol-capabilities.txt | 7 +++ 1 file changed, 7 insertions(+) diff --git a/Documentation/technical/protocol-capabilities.txt b/Documentation/technical/protocol-capabilities.txt index ec131b6..31cbe07 100644 --- a/Documentation/technical/protocol-capabilities.txt +++ b/Documentation/technical/protocol-capabilities.txt @@ -210,3 +210,10 @@ be shown when processing the received pack. A send-pack client should respond with the 'quiet' capability to suppress server-side progress reporting if the local progress reporting is also being suppressed (e.g., via `push -q`, or if stderr does not go to a tty). + +allow-tip-sha1-in-want +-- + +If the upload-pack server advertises this capability, fetch-pack may +send want lines with SHA-1s that exist at the server but are not +advertised by upload-pack. -- 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] config doc: quote paths, fixing tilde-interpretation
Ramkumar Ramachandra artag...@gmail.com writes: The --global section of git-config(1) currently reads like: For writing options: write to global /.gitconfig file rather than the ^ start tilde repository .git/config, write to $XDG_CONFIG_HOME/git/config file if this file exists and the/.gitconfig file doesn’t. ^ end tilde Instead of tilde (~) being interpreted literally, asciidoc subscripts the text between the two tildes. To fix this problem, use backticks (`) to quote all the paths in the file uniformly, just like config.txt does. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- Candidate for maint? Surely; thanks for sharp eyes. Documentation/git-config.txt | 26 ++ 1 file changed, 14 insertions(+), 12 deletions(-) diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt index 34b0894..2dbe486 100644 --- a/Documentation/git-config.txt +++ b/Documentation/git-config.txt @@ -96,29 +96,31 @@ OPTIONS names are not. --global:: - For writing options: write to global ~/.gitconfig file rather than - the repository .git/config, write to $XDG_CONFIG_HOME/git/config file - if this file exists and the ~/.gitconfig file doesn't. + For writing options: write to global `~/.gitconfig` file + rather than the repository `.git/config`, write to + `$XDG_CONFIG_HOME/git/config` file if this file exists and the + `~/.gitconfig` file doesn't. + -For reading options: read only from global ~/.gitconfig and from -$XDG_CONFIG_HOME/git/config rather than from all available files. +For reading options: read only from global `~/.gitconfig` and from +`$XDG_CONFIG_HOME/git/config` rather than from all available files. + See also FILES. --system:: - For writing options: write to system-wide $(prefix)/etc/gitconfig - rather than the repository .git/config. + For writing options: write to system-wide + `$(prefix)/etc/gitconfig` rather than the repository + `.git/config`. + -For reading options: read only from system-wide $(prefix)/etc/gitconfig +For reading options: read only from system-wide `$(prefix)/etc/gitconfig` rather than from all available files. + See also FILES. --local:: - For writing options: write to the repository .git/config file. + For writing options: write to the repository `.git/config` file. This is the default behavior. + -For reading options: read only from the repository .git/config rather than +For reading options: read only from the repository `.git/config` rather than from all available files. + See also FILES. @@ -218,9 +220,9 @@ $(prefix)/etc/gitconfig:: $XDG_CONFIG_HOME/git/config:: Second user-specific configuration file. If $XDG_CONFIG_HOME is not set - or empty, $HOME/.config/git/config will be used. Any single-valued + or empty, `$HOME/.config/git/config` will be used. Any single-valued variable set in this file will be overwritten by whatever is in - ~/.gitconfig. It is a good idea not to create this file if + `~/.gitconfig`. It is a good idea not to create this file if you sometimes use older versions of Git, as support for this file was added fairly recently. -- 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] git-tag man: when to use lightweight or annotated tags
On 07/26/2013 04:51 PM, Marc Branchaud wrote: On 13-07-26 04:46 AM, Daniele Segato wrote: From 34fdcb56e5784699ffa327ebfcd2c5cd99b61d2d Mon Sep 17 00:00:00 2001 From: Daniele Segato daniele.seg...@gmail.com Date: Thu, 25 Jul 2013 15:33:18 +0200 Subject: [PATCH] git-tag man: when to use lightweight or annotated tags When sending a patch to the list it's not necessary to include these headers, as the git tools will extract them from the email itself. Also, when sending a revision to a previously posted patch it's customary to include a revision number, e.g. [PATCHv2]. Thanks, I'll try to do the right thing with the next patch. By the way which is your role in the community? Don't want to be rude, I just don't know who I'm talking about :) the documentation maintainer? Thanks for the help anyway. diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt index 22894cb..5c6284e 100644 --- a/Documentation/git-tag.txt +++ b/Documentation/git-tag.txt @@ -26,7 +26,7 @@ to delete, list or verify tags. Unless `-f` is given, the named tag must not yet exist. If one of `-a`, `-s`, or `-u key-id` is passed, the command -creates a 'tag' object, and requires a tag message. Unless +creates a 'tag' object called 'Annotated tag', and requires a tag message. 1) Don't capitalize annotated -- it's not capitalized anywhere else in the text. The same goes for lightweight. Ok 2) I find the phrasing here awkward. The important thing to convey is that annotated tag is a synonym for tag object. The proposed text implies that there can be other kinds of tag objects that are not annotated tags, but I don't think that's true. I've mulled over different ways of introducing the annotated tag term here, but I can't come up with a succinct way to do it. I think it's better to just introduce the term later. Ok, English is not my native language so no surprise it sound awkward ;) I'll follow your suggestion here and move everything later. Unless `-m msg` or `-F file` is given, an editor is started for the user to type in the tag message. @@ -36,6 +36,11 @@ are absent, `-a` is implied. Otherwise just a tag reference for the SHA-1 object name of the commit object is created (i.e. a lightweight tag). +'Annotated' and 'Lightweight' tags are not the same thing for git and you shouldn't +mix them up. Annotated tags are meant for release while lightweight tags are +meant for private or temporary object labels. Most git commands only consider +Annotated tags by default. + I'm sorry, but I feel this misses the mark. It's redundant to say the tag types are not the same thing, since the fact that they have different names already implies that. Also, to me the admonition you shouldn't mix them up is just a scary warning that conveys no helpful information. Furthermore, I think simply stating that the tag types are meant for particular uses without explaining why is too glib. Although it may be natural in your circumstances to think of the tag types rigidly, I do not think that's true for all git users and I don't think the documentation should assume there's a One True Way to use tags. The text should give readers enough information to decide for themselves how they want to use the different types of tags. That's why I included the annotated tag's contents in my suggestion, so that readers could figure out which tag type best meets their needs. What you've proposed is a step in the right direction, but I think you need to go further. M. I tried to take into account everything you said to me and rewrite the patch, following this message. Regards, Daniele -- 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: [PATCHv3] git-tag man: when to use lightweight or annotated tags
stress the difference between the two with suggestion on when the user should use one in place of the other. Signed-off-by: Daniele Segato daniele.seg...@gmail.com --- Documentation/git-tag.txt |9 + 1 file changed, 9 insertions(+) diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt index 22894cb..495eb71 100644 --- a/Documentation/git-tag.txt +++ b/Documentation/git-tag.txt @@ -42,6 +42,15 @@ committer identity for the current user is used to find the GnuPG key for signing. The configuration variable `gpg.program` is used to specify custom GnuPG binary. +The tag objects (created with `-a`, `s`, or `-u`) are called 'annotated' tags, +they contains a creation date, the tagger name and e-mail, a tagging message +and, eventually, the GNUPG signing and verification data. While a +'lightweight' tag is simply a name for an object (usually a commit object). + +'Annotated' tag are meant for release while 'lightweight' tags are meant +for private or temporary object labels, thus most git commands ignore +lightweight tags by default. + OPTIONS --- -- 1.7.10.4 -- 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] branch: make sure the upstream remote is configured
A command of e.g.
git push --set-upstream /tmp/t master
will call install_branch_config() with a remote name of /tmp/t. This
function will set the 'branch.master.remote' key to, which is
nonsensical as there is no remote by that name.
Instead, make sure that the remote given does exist when writing the
configuration and warn if it does not. In order to distinguish named
remotes, introduce REMOTE_NONE as the default origin for remotes,
which the functions reading from the different sources will
overwrite. Thus, an origin of REMOTE_NONE means it has been created at
run-time in order to push to it.
Signed-off-by: Carlos Martín Nieto c...@elego.de
---
It's somewhat surprising that there didn't seem to be a way to
distinguish named remotes from those created from a command-line path,
but I guess nobody needed to.
branch.c | 11 +++
remote.h | 1 +
t/t5523-push-upstream.sh | 5 +
3 files changed, 17 insertions(+)
diff --git a/branch.c b/branch.c
index c5c6984..cefb8f6 100644
--- a/branch.c
+++ b/branch.c
@@ -53,6 +53,7 @@ void install_branch_config(int flag, const char *local, const
char *origin, cons
int remote_is_branch = !prefixcmp(remote, refs/heads/);
struct strbuf key = STRBUF_INIT;
int rebasing = should_setup_rebase(origin);
+ struct remote *r = remote_get(origin);
if (remote_is_branch
!strcmp(local, shortname)
@@ -62,6 +63,16 @@ void install_branch_config(int flag, const char *local,
const char *origin, cons
return;
}
+ /*
+* Make sure that the remote passed is a configured remote, or
+* we end up setting 'branch.foo.remote = /tmp/t' which is
+* nonsensical.
+*/
+ if (origin strcmp(origin, .) r-origin == REMOTE_NONE) {
+ warning(_(there is no remote named '%s', no upstream
configuration will be set.), origin);
+ return;
+ }
+
strbuf_addf(key, branch.%s.remote, local);
git_config_set(key.buf, origin ? origin : .);
diff --git a/remote.h b/remote.h
index cf56724..92f6e33 100644
--- a/remote.h
+++ b/remote.h
@@ -2,6 +2,7 @@
#define REMOTE_H
enum {
+ REMOTE_NONE,
REMOTE_CONFIG,
REMOTE_REMOTES,
REMOTE_BRANCHES
diff --git a/t/t5523-push-upstream.sh b/t/t5523-push-upstream.sh
index 3683df1..e84c2f8 100755
--- a/t/t5523-push-upstream.sh
+++ b/t/t5523-push-upstream.sh
@@ -71,6 +71,11 @@ test_expect_success 'push -u HEAD' '
check_config headbranch upstream refs/heads/headbranch
'
+test_expect_success 'push -u url' '
+git push -u parent HEAD 2err
+grep no upstream configuration will be set err
+'
+
test_expect_success TTY 'progress messages go to tty' '
ensure_fresh_upstream
--
1.8.3
--
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] commit: correct advice about aborting a cherry-pick
When a cherry-pick results in an empty commit, git prints: The previous cherry-pick is now empty, possibly due to conflict resolution. If you wish to commit it anyway, use: git commit --allow-empty Otherwise, please use 'git reset' The last line is plain wrong in the case of a ranged pick, as a 'git reset' will fail to remove $GIT_DIR/sequencer, failing a subsequent cherry-pick or revert. Change the advice to: git cherry-pick --abort Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- Another candidate for maint? I'd also really like to squelch this with an advice.* variable; any suggestions? builtin/commit.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/builtin/commit.c b/builtin/commit.c index 003bd7d..1b213f7 100644 --- a/builtin/commit.c +++ b/builtin/commit.c @@ -64,7 +64,10 @@ N_(The previous cherry-pick is now empty, possibly due to conflict resolution.\ \n git commit --allow-empty\n \n -Otherwise, please use 'git reset'\n); +Otherwise, use:\n +\n +git cherry-pick --abort\n +\n); static const char *use_message_buffer; static const char commit_editmsg[] = COMMIT_EDITMSG; -- 1.8.4.rc0.1.g8f6a3e5.dirty -- 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] branch: make sure the upstream remote is configured
On Fri, Jul 26, 2013 at 07:39:37PM +0200, Carlos Martín Nieto wrote:
A command of e.g.
git push --set-upstream /tmp/t master
will call install_branch_config() with a remote name of /tmp/t. This
function will set the 'branch.master.remote' key to, which is
nonsensical as there is no remote by that name.
Is it nonsensical? It does not make sense for the @{upstream} magic
token, because we will not have a branch in tracking branch refs/remotes
to point to. But the configuration would still affect how git pull
chooses a branch to fetch and merge.
I.e., you can currently do:
git push --set-upstream /tmp/t master
git pull ;# pulls from /tmp/t master
-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] branch: make sure the upstream remote is configured
On Fri, Jul 26, 2013 at 02:43:11PM -0400, Jeff King wrote:
On Fri, Jul 26, 2013 at 07:39:37PM +0200, Carlos Martín Nieto wrote:
A command of e.g.
git push --set-upstream /tmp/t master
will call install_branch_config() with a remote name of /tmp/t. This
function will set the 'branch.master.remote' key to, which is
nonsensical as there is no remote by that name.
Is it nonsensical? It does not make sense for the @{upstream} magic
token, because we will not have a branch in tracking branch refs/remotes
Eh, I am incapable of typing (and proofreading). That should be not
have a tracking branch in refs/remotes.
-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: [PATCHv3] git-tag man: when to use lightweight or annotated tags
On Fri, Jul 26, 2013 at 07:33:01PM +0200, Daniele Segato wrote: stress the difference between the two with suggestion on when the user should use one in place of the other. Signed-off-by: Daniele Segato daniele.seg...@gmail.com The intent of your patch seems reasonable to me. There are a few minor language and typographical mistakes, and the patch itself is whitespace-damaged. I also do not know that it is accurate to say most git commands ignore lightweight tags. It is really only naming ones like git describe. Here is a re-send of your patch with the fixups I would recommend. -- 8 -- From: Daniele Segato daniele.seg...@gmail.com Subject: [PATCH] docs/git-tag: explain lightweight versus annotated tags Stress the difference between the two with a suggestion on when the user should use one in place of the other. Signed-off-by: Daniele Segato daniele.seg...@gmail.com Signed-off-by: Jeff King p...@peff.net --- Documentation/git-tag.txt | 11 +++ 1 file changed, 11 insertions(+) diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt index 22894cb..c418c44 100644 --- a/Documentation/git-tag.txt +++ b/Documentation/git-tag.txt @@ -42,6 +42,17 @@ is used to specify custom GnuPG binary. GnuPG key for signing. The configuration variable `gpg.program` is used to specify custom GnuPG binary. +Tag objects (created with `-a`, `s`, or `-u`) are called annotated +tags; they contain a creation date, the tagger name and e-mail, a +tagging message, and an optional GnuPG signature. Whereas a +lightweight tag is simply a name for an object (usually a commit +object). + +Annotated tags are meant for release while lightweight tags are meant +for private or temporary object labels. For this reason, some git +commands for naming objects (like `git describe`) will ignore +lightweight tags by default. + OPTIONS --- -- 1.8.3.rc1.30.gff0fb75 -- 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: Why can't I push from a shallow clone?
Hey Fredrick, It's good to know that work is being done on this. I still want to understand it though, so I guess I'll ask specific questions about Junio's response. He states, If you cloned shallowly some time ago, worked without communicating with the other side while the other side progressed, AND if the other side's progress included a rewind rebuild of the history, you would see a similar topology. The leftmost 'S' in the above picture might have been the tip of the branch when you shallowly cloned with depth 1, and since then the remote end may have discarded topmost three commits and have rebuilt its history that leads to the rightmost 'R'. In such a case pushing to the remote's HEAD will fail. So as an example, if you shallow clone a branch, then someone squashes the head commit and makes a new commit, you won't be able to push to HEAD because the parent has changed. But if someone does that, I don't think you would be able to push even if it was a full clone. That's why it's usually not a good idea to rebase shared branches. So did I misunderstand the scenario? On Thu, Jul 25, 2013 at 11:55 PM, Fredrik Gustafsson iv...@iveqy.com wrote: On Thu, Jul 25, 2013 at 07:33:16PM -0700, Gulshan Singh wrote: I've been trying to figure out why I can't push from a shallow clone (using --depth) to a repository. I've made simple examples where it works, but I've read that in doesn't work in every case. However, I can't come up with a case where it doesn't work. Googling gives this answer: http://stackoverflow.com/questions/6900103/why-cant-i-push-from-a-shallow-clone, but I don't completely understand the explanation, so I was hoping someone could explain it. I can't explain it better than what Junio did in the link you just provide. However there's ongoing work to allow shallow clones to be able to push. You can read about it here: http://thread.gmane.org/gmane.comp.version-control.git/230612/focus=230878 -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- Gulshan Singh University of Michigan, Class of 2015 College of Engineering, Computer Science Major guls...@umich.edu | 248.961.6317 Alternate E-mail: gsingh2...@gmail.com -- 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] commit: correct advice about aborting a cherry-pick
On Fri, Jul 26, 2013 at 11:42:00PM +0530, Ramkumar Ramachandra wrote: When a cherry-pick results in an empty commit, git prints: The previous cherry-pick is now empty, possibly due to conflict resolution. If you wish to commit it anyway, use: git commit --allow-empty Otherwise, please use 'git reset' The last line is plain wrong in the case of a ranged pick, as a 'git reset' will fail to remove $GIT_DIR/sequencer, failing a subsequent cherry-pick or revert. Change the advice to: git cherry-pick --abort Hmm. I don't think I've run across this message myself, so perhaps I do not understand the situation. But it seems like you would want to do one of: 1. Make an empty commit. 2. Skip this commit and continue the rest of the cherry-pick sequence. 3. Abort the cherry pick sequence. Those are the options presented when rebase runs into an empty commit, where (2) is presented as rebase --skip. I'm not sure how to do that here; is it just cherry-pick --continue? I'd also really like to squelch this with an advice.* variable; any suggestions? This seems like a good candidate for squelching, but you would probably want to split it. The two parts of the message are: 1. What happened (the cherry-pick is empty). 2. How to proceed from here (allow-empty, abort, etc). You still want to say (1), but (2) is useless to old-timers. Probably something like advice.cherryPickInstructions would be a good name for an option to squelch (2), and it should apply wherever we tell the user how to proceed. Potentially it should even be advice.sequenceInstructions, and apply to rebase and am as well. -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: [PATCHv3] git-tag man: when to use lightweight or annotated tags
Jeff King wrote: --- a/Documentation/git-tag.txt +++ b/Documentation/git-tag.txt @@ -42,6 +42,17 @@ is used to specify custom GnuPG binary. GnuPG key for signing. The configuration variable `gpg.program` is used to specify custom GnuPG binary. +Tag objects (created with `-a`, `s`, or `-u`) are called annotated +tags; they contain a creation date, the tagger name and e-mail, a +tagging message, and an optional GnuPG signature. Whereas a +lightweight tag is simply a name for an object (usually a commit +object). + +Annotated tags are meant for release while lightweight tags are meant +for private or temporary object labels. For this reason, some git +commands for naming objects (like `git describe`) will ignore +lightweight tags by default. Very readable, and I think this is a good start. Reviewed-by: Jonathan Nieder jrnie...@gmail.com Eventually the description section should probably be tweaked to start by explaining what the command is actually for. ;-) -- 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] builtins: search builtin commands via binary search.
There are currently 115 commands built into the git executable.
Before this commit, it was iterated over these commands in a linear
order, i.e. each command was checked.
As it turns out the commands are already sorted alphabetically, it is easy
to perform a binary search instead of linear searching.
This results in 7 lookups in the worst case.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
git.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/git.c b/git.c
index 2025f77..0d7a9b5 100644
--- a/git.c
+++ b/git.c
@@ -309,9 +309,18 @@ static int run_builtin(struct cmd_struct *p, int argc,
const char **argv)
return 0;
}
+static int compare_internal_command(const void *a, const void *b) {
+ /* The first parameter is of type char* describing the name,
+ the second is a struct cmd_struct */
+ const char *name = (const char*)a;
+ const struct cmd_struct *cmd_struct = (struct cmd_struct*)b;
+ return strcmp(name, cmd_struct-cmd);
+}
+
static void handle_internal_command(int argc, const char **argv)
{
const char *cmd = argv[0];
+ /* commands must be sorted alphabetically */
static struct cmd_struct commands[] = {
{ add, cmd_add, RUN_SETUP | NEED_WORK_TREE },
{ annotate, cmd_annotate, RUN_SETUP },
@@ -447,12 +456,12 @@ static void handle_internal_command(int argc, const char
**argv)
argv[0] = cmd = help;
}
- for (i = 0; i ARRAY_SIZE(commands); i++) {
- struct cmd_struct *p = commands+i;
- if (strcmp(p-cmd, cmd))
- continue;
+ struct cmd_struct *p = (struct cmd_struct *)bsearch(cmd, commands,
+ ARRAY_SIZE(commands), sizeof(struct cmd_struct),
+ compare_internal_command);
+
+ if (p)
exit(run_builtin(p, argc, argv));
- }
}
static void execv_dashed_external(const char **argv)
--
1.8.4.rc0.1.g8f6a3e5
--
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] builtins: search builtin commands via binary search.
Hi,
Stefan Beller wrote:
--- a/git.c
+++ b/git.c
@@ -309,9 +309,18 @@ static int run_builtin(struct cmd_struct *p, int argc,
const char **argv)
return 0;
}
+static int compare_internal_command(const void *a, const void *b) {
+ /* The first parameter is of type char* describing the name,
+the second is a struct cmd_struct */
Style:
/*
* Multi-line comments in git look like this, with an initial
* /* line, a leading * on each line with text, and a line
* with '*' '/' at the end.
*/
[...]
@@ -447,12 +456,12 @@ static void handle_internal_command(int argc, const
char **argv)
argv[0] = cmd = help;
}
- for (i = 0; i ARRAY_SIZE(commands); i++) {
- struct cmd_struct *p = commands+i;
- if (strcmp(p-cmd, cmd))
- continue;
+ struct cmd_struct *p = (struct cmd_struct *)bsearch(cmd, commands,
+ ARRAY_SIZE(commands), sizeof(struct cmd_struct),
+ compare_internal_command);
No need to cast --- this is C.
Fun. Does this result in a measurable speedup, or is it just for more
pleasant reading?
Thanks and 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: [PATCHv3] git-tag man: when to use lightweight or annotated tags
On 13-07-26 03:06 PM, Jeff King wrote: On Fri, Jul 26, 2013 at 07:33:01PM +0200, Daniele Segato wrote: stress the difference between the two with suggestion on when the user should use one in place of the other. Signed-off-by: Daniele Segato daniele.seg...@gmail.com The intent of your patch seems reasonable to me. There are a few minor language and typographical mistakes, and the patch itself is whitespace-damaged. I also do not know that it is accurate to say most git commands ignore lightweight tags. It is really only naming ones like git describe. Here is a re-send of your patch with the fixups I would recommend. I'm happy with Peff's version. Reviewed-by: Marc Branchaud marcn...@xiplink.com (Daniele, don't feel put off because Jonathan I are accepting Peff's text. If you think it still needs improving please speak up!) M. -- 8 -- From: Daniele Segato daniele.seg...@gmail.com Subject: [PATCH] docs/git-tag: explain lightweight versus annotated tags Stress the difference between the two with a suggestion on when the user should use one in place of the other. Signed-off-by: Daniele Segato daniele.seg...@gmail.com Signed-off-by: Jeff King p...@peff.net --- Documentation/git-tag.txt | 11 +++ 1 file changed, 11 insertions(+) diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt index 22894cb..c418c44 100644 --- a/Documentation/git-tag.txt +++ b/Documentation/git-tag.txt @@ -42,6 +42,17 @@ is used to specify custom GnuPG binary. GnuPG key for signing. The configuration variable `gpg.program` is used to specify custom GnuPG binary. +Tag objects (created with `-a`, `s`, or `-u`) are called annotated +tags; they contain a creation date, the tagger name and e-mail, a +tagging message, and an optional GnuPG signature. Whereas a +lightweight tag is simply a name for an object (usually a commit +object). + +Annotated tags are meant for release while lightweight tags are meant +for private or temporary object labels. For this reason, some git +commands for naming objects (like `git describe`) will ignore +lightweight tags by default. + OPTIONS --- -- 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] commit: correct advice about aborting a cherry-pick
Jeff King wrote: Hmm. I don't think I've run across this message myself, so perhaps I do not understand the situation. It's very simple. # on branch master $ git checkout -b test $ git cherry-pick master $ ls .git/sequencer # missing In the pseudo multi-pick case (I say pseudo because there's really just one commit to pick): # on branch master $ git checkout -b test $ git cherry-pick master~.. $ ls .git/sequencer cat .git/sequencer/todo if you like. 2. Skip this commit and continue the rest of the cherry-pick sequence. Nope, this is unsupported afaik. Those are the options presented when rebase runs into an empty commit, where (2) is presented as rebase --skip. I'm not sure how to do that here; is it just cherry-pick --continue? No, --continue will just print the same message over and over again. Yes, the whole ranged cherry-pick thing can use a lot more polish. 1. What happened (the cherry-pick is empty). 2. How to proceed from here (allow-empty, abort, etc). You still want to say (1), but (2) is useless to old-timers. Probably something like advice.cherryPickInstructions would be a good name for an option to squelch (2), and it should apply wherever we tell the user how to proceed. Potentially it should even be advice.sequenceInstructions, and apply to rebase and am as well. Good suggestion. I'll pick advice.cherryPickInstructions when I decide to polish sequencer.c a bit. Thanks. -- 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] git-tag man: when to use lightweight or annotated tags
On 13-07-26 01:19 PM, Daniele Segato wrote: By the way which is your role in the community? Don't want to be rude, I just don't know who I'm talking about :) the documentation maintainer? I'm just a git user and (very) occasional contributor. There's not much structure to the git community. Anyone who wants git to change can post a patch (or patch series) to this list. The patch can touch any area of the code, and it's considered good manners to CC whoever last touched the part(s) of the code being patched. The patch is discussed and revised as needed, and eventually the patch thread's participants arrive at a consensus as to whether or not the patch should become a part of git. If the patch is accepted the git maintainer (Junio C. Hamano) shepherds the patch through git's release process. See this note: http://git-blame.blogspot.ca/p/a-note-from-maintainer.html for more about that and other aspects of the git development community. M. -- 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] commit: correct advice about aborting a cherry-pick
On Sat, Jul 27, 2013 at 02:47:47AM +0530, Ramkumar Ramachandra wrote: 2. Skip this commit and continue the rest of the cherry-pick sequence. Nope, this is unsupported afaik. Ah. I don't mind improving the message in the meantime, but it sounds like this is a deficiency in sequenced cherry-pick that needs addressed eventually. Your patch is just swapping out git reset for cherry-pick --abort, so I think that is a good improvement in the meantime. -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] commit: correct advice about aborting a cherry-pick
Jeff King wrote: Ah. I don't mind improving the message in the meantime, but it sounds like this is a deficiency in sequenced cherry-pick that needs addressed eventually. I'm especially irked by how slow rebase--am is, and want to replace it. -- 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] commit: correct advice about aborting a cherry-pick
Jeff King wrote: Your patch is just swapping out git reset for cherry-pick --abort, so I think that is a good improvement in the meantime. Um, wasn't the idea of the original message that you can run git reset and then git cherry-pick --continue? Confused, 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] commit: correct advice about aborting a cherry-pick
On Fri, Jul 26, 2013 at 02:37:05PM -0700, Jonathan Nieder wrote: Jeff King wrote: Your patch is just swapping out git reset for cherry-pick --abort, so I think that is a good improvement in the meantime. Um, wasn't the idea of the original message that you can run git reset and then git cherry-pick --continue? Maybe. :) I missed that subtlety. Of my three things you would want to do, that means it was _trying_ say number 2, how to skip, rather than 3, how to abort. If that is the case, then it should probably explain the sequence of steps as reset and then --continue to make it more clear. I.e., a patch is needed, but Ram's is going in the opposite direction. -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: Why can't I push from a shallow clone?
From: Gulshan Singh gsingh2...@gmail.com Sent: Friday, July 26, 2013 8:12 PM Hey Fredrick, It's good to know that work is being done on this. I still want to understand it though, so I guess I'll ask specific questions about Junio's response. He states, If you cloned shallowly some time ago, worked without communicating with the other side while the other side progressed, AND if the other side's progress included a rewind rebuild of the history, you would see a similar topology. The leftmost 'S' in the above picture might have been the tip of the branch when you shallowly cloned with depth 1, and since then the remote end may have discarded topmost three commits and have rebuilt its history that leads to the rightmost 'R'. In such a case pushing to the remote's HEAD will fail. So as an example, if you shallow clone a branch, then someone squashes the head commit and makes a new commit, you won't be able to push to HEAD because the parent has changed. But if someone does that, I don't think you would be able to push even if it was a full clone. That's why it's usually not a good idea to rebase shared branches. So did I misunderstand the scenario? In your example you have a sucessful failure, that is, the shallow issue hasn't got in the way of the normal non-ff failure on push. (asuming the squash is an extra commit, not a re-written top commit, so at least you still have your common commit of your depth1 shallow clone) For it to be a proper shallow failure the remote repo needs to be re-written sufficiently far back that your shallow clone has nothing in common with it. In such a case your DAG can't join onto the remote's DAG. On Thu, Jul 25, 2013 at 11:55 PM, Fredrik Gustafsson iv...@iveqy.com wrote: On Thu, Jul 25, 2013 at 07:33:16PM -0700, Gulshan Singh wrote: I've been trying to figure out why I can't push from a shallow clone (using --depth) to a repository. I've made simple examples where it works, but I've read that in doesn't work in every case. However, I can't come up with a case where it doesn't work. Googling gives this answer: http://stackoverflow.com/questions/6900103/why-cant-i-push-from-a-shallow-clone, but I don't completely understand the explanation, so I was hoping someone could explain it. I can't explain it better than what Junio did in the link you just provide. However there's ongoing work to allow shallow clones to be able to push. You can read about it here: http://thread.gmane.org/gmane.comp.version-control.git/230612/focus=230878 -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- Gulshan Singh University of Michigan, Class of 2015 College of Engineering, Computer Science Major guls...@umich.edu | 248.961.6317 Alternate E-mail: gsingh2...@gmail.com -- Philip -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REQUEST 1/1] docs: update http.url.* options documentation
On Thu, Jul 25, 2013 at 11:23:23PM -0700, Kyle J. McKay wrote: IMHO, this would be more clear as a single item, like: . User name (e.g., `user` in `https://u...@example.com/repo.git`). If the config key has a user name it must match the user name in the URL exactly. If the config key does not have a user name, that config key will match a URL with any user name (including none). The only problem I have with a single item is what's the precedence? Does an exact user match have the same precedence as an any-user match? That would seem to be implied by having them as the same item number. Separating them would appear to make it clearer that an exact user match wins over an any user match, but if you have some alternate text as a suggestion for the single item that clears that up... :) Ah, I see your thinking now. You want to say no username has less precedence than some username, which has less precedence than a path, so they are all elements of a single list. My thinking was username has precedence less than path, and like a shorter path has less precedence than a longer path, an empty username has less precedence than a non-empty username. I agree my suggested wording would need to mention that explicitly. Like: . User name (e.g., `user` in `https://u...@example.com/repo.git`). If the config key has a user name it must match the user name in the URL exactly. If the config key does not have a user name, that config key will match a URL with any user name (including none), but at lower precedence than a config key with a user name. I can live with it either way, though. They are just two ways of considering the same thing. I am considering this text to address that: All URLs are normalized (%-encodings are standardized, case-insensitive parts are lowercased, `./` and `../` path components are resolved) before attempting any matching (the password part, if embedded in the URL, but I'm not sure the extra verbiage makes it better. I think it may just complicate the explanation unnecessarily? Yeah, I think I agree. Let's leave it out. -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] branch: make sure the upstream remote is configured
On Fri, 2013-07-26 at 14:43 -0400, Jeff King wrote:
On Fri, Jul 26, 2013 at 07:39:37PM +0200, Carlos Martín Nieto wrote:
A command of e.g.
git push --set-upstream /tmp/t master
will call install_branch_config() with a remote name of /tmp/t. This
function will set the 'branch.master.remote' key to, which is
nonsensical as there is no remote by that name.
Is it nonsensical? It does not make sense for the @{upstream} magic
token, because we will not have a branch in tracking branch refs/remotes
This was the main point, yes; the only time I've seen it used is by
mistake/misunderstanding, and thinking that you wouldn't want to do
something like what's below.
You are also unable to do this kind of thing through git-branch, and as
it seemed to be an oversight, I wanted to tighten it up.
to point to. But the configuration would still affect how git pull
chooses a branch to fetch and merge.
I.e., you can currently do:
git push --set-upstream /tmp/t master
git pull ;# pulls from /tmp/t master
Interestingly, this actually fetches the right branch from the remote. I
wasn't expecting something like this to work at all.
Somewhat doubtful that this usage is something you'd really want to do,
I see that it does behave properly.
cmn
--
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] commit: correct advice about aborting a cherry-pick
On Fri, Jul 26, 2013 at 05:40:36PM -0400, Jeff King wrote: Jeff King wrote: Your patch is just swapping out git reset for cherry-pick --abort, so I think that is a good improvement in the meantime. Um, wasn't the idea of the original message that you can run git reset and then git cherry-pick --continue? Maybe. :) I missed that subtlety. Of my three things you would want to do, that means it was _trying_ say number 2, how to skip, rather than 3, how to abort. If that is the case, then it should probably explain the sequence of steps as reset and then --continue to make it more clear. I.e., a patch is needed, but Ram's is going in the opposite direction. I played around a bit with the test cases that Ram showed. It seems like the advice needed is different depending on whether you are in a single or multi-commit cherry-pick. So if we hit an empty commit and you want to: 1. Make an empty commit, then always run git commit --allow-empty. 2. Skip this commit, then if: a. this is a single commit cherry-pick, you run git reset (and nothing more, the cherry pick is finished; running cherry-pick --continue will yield an error). b. this is a multi-commit cherry-pick, you run git reset, followed by git cherry-pick --continue 3. Abort the commit, run git cherry-pick --abort Let's assume that the instructions we want to give the user are how to do options 1 and 2. I do not mind omitting 3, as it should be reasonably obvious that cherry-pick --abort is always good way to abort. So we give good instructions for the single-commit case, but bad instructions for the multi-commit case. Ram's patch suggests --abort instead of reset, which is the same for the single-commit case, but suggests 3 instead of 2 for the multi-patch. I think instead we would want to leave the single-commit case alone, and for the multi-commit case add ...and then cherry-pick --continue. That message is generated from within git-commit, though; I guess it would need to learn about the difference between single/multi cherry-picks. -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
subtree split prepends -nnewline to commit messages on OS X
Looks like this was introduced in 1.8.3.3. To reproduce, run git init repo cd repo mkdir splitme touch splitme/foo git add splitme/ git commit -m 'Add foo' git subtree split -P splitme -b splitme-only After that, I get: $ git log splitme-only commit 6ce8124a0b5e52d4bba198144d2f3f664d7b19e7 Author: me Date: Fri Jul 26 12:22:27 2013 -0500 -n Add foo Compared with the original: $ git log master commit 6d5164076bd88d1dab8963d91ec013372e58a444 Author: me Date: Fri Jul 26 12:22:27 2013 -0500 Add foo Notice how `-nnewline` has been prepended to the commit message. This was introduced when subtree was changed to use `sh` instead of `bash`, in this commit:https://github.com/git/git/commit/6912ea952bf5d1b2d21d5935d6b726bab02d8bf6#contrib/subtree/git-subtree.sh This was merged in here: https://github.com/git/git/commit/779fd737d79a3e19a1aa420c33cf1195c7e20dd7#contrib/subtree/git-subtree.sh I verified that changing the line in question back to `#!/bin/bash` eliminates the problem. I believe that it was caused by the fact that sh echos the -n in this line: https://github.com/git/git/blob/master/contrib/subtree/git-subtree.sh#L314 Note that this consequently happens when, for instance, using `git subtree push` to push the subtree to an upstream repository. I'm using OS X 10.8.4. The problem does not occur on Ubuntu at least since Ubuntu's sh is actually dash. -- 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] commit: correct advice about aborting a cherry-pick
On Fri, Jul 26, 2013 at 06:43:59PM -0400, Jeff King wrote:
I think instead we would want to leave the single-commit case alone, and
for the multi-commit case add ...and then cherry-pick --continue. That
message is generated from within git-commit, though; I guess it would
need to learn about the difference between single/multi cherry-picks.
Like this?
-- 8 --
Subject: [PATCH] commit: tweak empty cherry pick advice for sequencer
When we refuse to make an empty commit, we check whether we
are in a cherry-pick in order to give better advice on how
to proceed. We instruct the user to repeat the commit with
--allow-empty to force the commit, or to use git reset
to skip it and abort the cherry-pick.
This works fine when we are cherry-picking a single commit.
When we are using the sequencer to cherry-pick multiple
items, though, using git reset is not good advice. It does
not skip the commit (you must run cherry-pick --continue
to keep going), but nor does it abort the cherry-pick (the
.sequencer directory still exists).
Let's teach commit to tell when the sequencer is in use, and
to mention cherry-pick --continue in that case.
Signed-off-by: Jeff King p...@peff.net
---
The advice in the multi case could eventually change to cherry-pick
--skip if and when it exists.
builtin/commit.c | 23 ---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index e47f100..45a98d7 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -63,8 +63,14 @@ N_(The previous cherry-pick is now empty, possibly due to
conflict resolution.\
If you wish to commit it anyway, use:\n
\n
git commit --allow-empty\n
+\n);
+static const char empty_cherry_pick_advice_skip_single[] =
+N_(Otherwise, please use 'git reset'\n);
+static const char empty_cherry_pick_advice_skip_multi[] =
+N_(If you wish to skip this commit, use:\n
\n
-Otherwise, please use 'git reset'\n);
+git reset git cherry-pick --continue\n
+\n);
static const char *use_message_buffer;
static const char commit_editmsg[] = COMMIT_EDITMSG;
@@ -107,6 +113,7 @@ static enum commit_whence whence;
static const char *cleanup_arg;
static enum commit_whence whence;
+static int sequencer_in_use;
static int use_editor = 1, include_status = 1;
static int show_ignored_in_status, have_option_m;
static const char *only_include_assumed;
@@ -141,8 +148,11 @@ static void determine_whence(struct wt_status *s)
{
if (file_exists(git_path(MERGE_HEAD)))
whence = FROM_MERGE;
- else if (file_exists(git_path(CHERRY_PICK_HEAD)))
+ else if (file_exists(git_path(CHERRY_PICK_HEAD))) {
whence = FROM_CHERRY_PICK;
+ if (file_exists(git_path(sequencer)))
+ sequencer_in_use = 1;
+ }
else
whence = FROM_COMMIT;
if (s)
@@ -808,8 +818,15 @@ static int prepare_to_commit(const char *index_file, const
char *prefix,
run_status(stdout, index_file, prefix, 0, s);
if (amend)
fputs(_(empty_amend_advice), stderr);
- else if (whence == FROM_CHERRY_PICK)
+ else if (whence == FROM_CHERRY_PICK) {
fputs(_(empty_cherry_pick_advice), stderr);
+ if (!sequencer_in_use)
+ fputs(_(empty_cherry_pick_advice_skip_single),
+ stderr);
+ else
+ fputs(_(empty_cherry_pick_advice_skip_multi),
+ stderr);
+ }
return 0;
}
--
1.8.3.rc1.30.gff0fb75
--
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] commit: correct advice about aborting a cherry-pick
Jeff King wrote: --- a/builtin/commit.c +++ b/builtin/commit.c @@ -63,8 +63,14 @@ N_(The previous cherry-pick is now empty, possibly due to conflict resolution.\ If you wish to commit it anyway, use:\n \n git commit --allow-empty\n +\n); +static const char empty_cherry_pick_advice_skip_single[] = +N_(Otherwise, please use 'git reset'\n); +static const char empty_cherry_pick_advice_skip_multi[] = +N_(If you wish to skip this commit, use:\n \n -Otherwise, please use 'git reset'\n); +git reset git cherry-pick --continue\n +\n); Hmm, wouldn't it be more consistent to either say If you wish to commit it anyway, use git commit --allow-empty git cherry-pick --continue If you wish to skip this commit, use git reset git cherry-pick --continue Or If you wish to commit it anyway, use git commit --allow-empty If you wish to skip this commit, use git reset Then git cherry-pick --continue will resume cherry-picking the remaining commits. ? -- 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] branch: make sure the upstream remote is configured
On Sat, Jul 27, 2013 at 12:29:47AM +0200, Carlos Martín Nieto wrote:
Is it nonsensical? It does not make sense for the @{upstream} magic
token, because we will not have a branch in tracking branch refs/remotes
This was the main point, yes; the only time I've seen it used is by
mistake/misunderstanding, and thinking that you wouldn't want to do
something like what's below.
If that is what you want to prevent, I do not think checking for a named
remote is sufficient. You can also be pushing to a branch on a named
remote that is not part of your fetch refspec, in which case you do not
have a tracking branch. I.e.:
git clone $URL repo.git
cd repo.git
git push --set-upstream HEAD:refs/foo/whatever
For that matter, I wonder what --set-upstream would do if used with
refs/tags/foo. You would not do that in general, but what about:
git push --set-upstream master:master master:v1.0
I didn't test.
to point to. But the configuration would still affect how git pull
chooses a branch to fetch and merge.
I.e., you can currently do:
git push --set-upstream /tmp/t master
git pull ;# pulls from /tmp/t master
Interestingly, this actually fetches the right branch from the remote. I
wasn't expecting something like this to work at all.
Somewhat doubtful that this usage is something you'd really want to do,
I see that it does behave properly.
I do not claim to have used it myself. Tightening the --set-upstream
behavior would not hurt people who want to configure such a thing
manually, and it might catch errors from people doing it accidentally.
So even though the config it generates is not nonsensical, there is a
reasonable chance it was an error, and tightening may make sense. But I
think you would not want the condition to be this is a named remote,
but rather the generated configuration actually has an @{upstream}.
-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] commit: correct advice about aborting a cherry-pick
On Fri, Jul 26, 2013 at 04:08:57PM -0700, Jonathan Nieder wrote: Jeff King wrote: --- a/builtin/commit.c +++ b/builtin/commit.c @@ -63,8 +63,14 @@ N_(The previous cherry-pick is now empty, possibly due to conflict resolution.\ If you wish to commit it anyway, use:\n \n git commit --allow-empty\n +\n); +static const char empty_cherry_pick_advice_skip_single[] = +N_(Otherwise, please use 'git reset'\n); +static const char empty_cherry_pick_advice_skip_multi[] = +N_(If you wish to skip this commit, use:\n \n -Otherwise, please use 'git reset'\n); +git reset git cherry-pick --continue\n +\n); Hmm, wouldn't it be more consistent to either say If you wish to commit it anyway, use git commit --allow-empty git cherry-pick --continue If you wish to skip this commit, use git reset git cherry-pick --continue Good point. Clearly the original assumed that you knew to cherry-pick --continue, since it is needed (and omitted) in both cases. And perhaps most people do, but certainly the lack of mentioning it confused both me and Ram about whether the git reset advice was meant to skip or abort. Or If you wish to commit it anyway, use git commit --allow-empty If you wish to skip this commit, use git reset Then git cherry-pick --continue will resume cherry-picking the remaining commits. I like this one better. You could _almost_ just use the top bit for the single-commit case, but I hesitate to use the word skip in that case. Right now the single-commit case does not need to make the distinction between skip this, and there is nothing else to do and abort the operation, because they are the same thing. Whichever way the user thinks about it is OK. -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] branch: make sure the upstream remote is configured
On Fri, Jul 26, 2013 at 07:12:11PM -0400, Jeff King wrote: If that is what you want to prevent, I do not think checking for a named remote is sufficient. You can also be pushing to a branch on a named remote that is not part of your fetch refspec, in which case you do not have a tracking branch. I.e.: git clone $URL repo.git cd repo.git git push --set-upstream HEAD:refs/foo/whatever For that matter, I wonder what --set-upstream would do if used with refs/tags/foo. You would not do that in general, but what about: git push --set-upstream master:master master:v1.0 I didn't test. Ah, nevermind. We already catch the case of non-heads (on both the local and remote sides) and abort. So that makes me more confident that your change is a reasonable one; we are already disallowing a subset of what's possible via --set-upstream in the name of preventing weird accidental configurations. This is just fixing another such loophole. -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] commit: correct advice about aborting a cherry-pick
On Fri, Jul 26, 2013 at 07:19:02PM -0400, Jeff King wrote:
Or
If you wish to commit it anyway, use
git commit --allow-empty
If you wish to skip this commit, use
git reset
Then git cherry-pick --continue will resume cherry-picking
the remaining commits.
I like this one better.
Here it is in patch form, with an updated commit message that hopefully
explains the rationale a bit better.
-- 8 --
Subject: [PATCH] commit: tweak empty cherry pick advice for sequencer
When we refuse to make an empty commit, we check whether we
are in a cherry-pick in order to give better advice on how
to proceed. We instruct the user to repeat the commit with
--allow-empty to force the commit, or to use git reset
to skip it and abort the cherry-pick.
In the case of a single cherry-pick, the distinction between
skipping and aborting is not important, as there is no more
work to be done afterwards. When we are using the sequencer
to cherry pick a series of commits, though, the instruction
is confusing: does it skip this commit, or does it abort the
rest of the cherry-pick?
It does skip, after which the user can continue the
cherry-pick. This is the right thing to be advising the user
to do, but let's make it more clear what will happen, both
by using the word skip, and by mentioning that the rest of
the sequence can be continued via cherry-pick --continue
(whether we skip or take the commit).
Noticed-by: Ramkumar Ramachandra artag...@gmail.com
Helped-by: Jonathan Nieder jrnie...@gmail.com
Signed-off-by: Jeff King p...@peff.net
---
builtin/commit.c | 25 ++---
1 file changed, 22 insertions(+), 3 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index e47f100..73fafe2 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -63,8 +63,18 @@ N_(The previous cherry-pick is now empty, possibly due to
conflict resolution.\
If you wish to commit it anyway, use:\n
\n
git commit --allow-empty\n
+\n);
+
+static const char empty_cherry_pick_advice_single[] =
+N_(Otherwise, please use 'git reset'\n);
+
+static const char empty_cherry_pick_advice_multi[] =
+N_(If you wish to skip this commit, use:\n
\n
-Otherwise, please use 'git reset'\n);
+git reset\n
+\n
+Then \git cherry-pick --continue\ will resume cherry-picking\n
+the remaining commits.\n);
static const char *use_message_buffer;
static const char commit_editmsg[] = COMMIT_EDITMSG;
@@ -107,6 +117,7 @@ static enum commit_whence whence;
static const char *cleanup_arg;
static enum commit_whence whence;
+static int sequencer_in_use;
static int use_editor = 1, include_status = 1;
static int show_ignored_in_status, have_option_m;
static const char *only_include_assumed;
@@ -141,8 +152,11 @@ static void determine_whence(struct wt_status *s)
{
if (file_exists(git_path(MERGE_HEAD)))
whence = FROM_MERGE;
- else if (file_exists(git_path(CHERRY_PICK_HEAD)))
+ else if (file_exists(git_path(CHERRY_PICK_HEAD))) {
whence = FROM_CHERRY_PICK;
+ if (file_exists(git_path(sequencer)))
+ sequencer_in_use = 1;
+ }
else
whence = FROM_COMMIT;
if (s)
@@ -808,8 +822,13 @@ static int prepare_to_commit(const char *index_file, const
char *prefix,
run_status(stdout, index_file, prefix, 0, s);
if (amend)
fputs(_(empty_amend_advice), stderr);
- else if (whence == FROM_CHERRY_PICK)
+ else if (whence == FROM_CHERRY_PICK) {
fputs(_(empty_cherry_pick_advice), stderr);
+ if (!sequencer_in_use)
+ fputs(_(empty_cherry_pick_advice_single),
stderr);
+ else
+ fputs(_(empty_cherry_pick_advice_multi),
stderr);
+ }
return 0;
}
--
1.8.3.rc1.30.gff0fb75
--
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] builtins: search builtin commands via binary search.
On Fri, Jul 26, 2013 at 4:50 PM, Stefan Beller
stefanbel...@googlemail.com wrote:
There are currently 115 commands built into the git executable.
Before this commit, it was iterated over these commands in a linear
order, i.e. each command was checked.
As it turns out the commands are already sorted alphabetically, it is easy
to perform a binary search instead of linear searching.
This results in 7 lookups in the worst case.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
git.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/git.c b/git.c
index 2025f77..0d7a9b5 100644
--- a/git.c
+++ b/git.c
@@ -309,9 +309,18 @@ static int run_builtin(struct cmd_struct *p, int argc,
const char **argv)
return 0;
}
+static int compare_internal_command(const void *a, const void *b) {
+ /* The first parameter is of type char* describing the name,
+ the second is a struct cmd_struct */
+ const char *name = (const char*)a;
+ const struct cmd_struct *cmd_struct = (struct cmd_struct*)b;
Comments typically exist to elucidate something non-obvious in the
code, however, in this case the code and comment say the same thing,
making the comment redundant. Such redundancy can make code harder to
read since the reader has to take extra time to figure out if the
comment is really explaining something not obvious in the code. Thus,
this comment can be removed without loss of clarity.
+ return strcmp(name, cmd_struct-cmd);
+}
+
static void handle_internal_command(int argc, const char **argv)
{
const char *cmd = argv[0];
+ /* commands must be sorted alphabetically */
static struct cmd_struct commands[] = {
This new comment, on the other hand does explain something not obvious
at this point in the code.
{ add, cmd_add, RUN_SETUP | NEED_WORK_TREE },
{ annotate, cmd_annotate, RUN_SETUP },
@@ -447,12 +456,12 @@ static void handle_internal_command(int argc, const
char **argv)
argv[0] = cmd = help;
}
- for (i = 0; i ARRAY_SIZE(commands); i++) {
- struct cmd_struct *p = commands+i;
- if (strcmp(p-cmd, cmd))
- continue;
+ struct cmd_struct *p = (struct cmd_struct *)bsearch(cmd, commands,
+ ARRAY_SIZE(commands), sizeof(struct
cmd_struct),
+ compare_internal_command);
Since this will break down if the commands[] array becomes unsorted,
it would make sense to protect against such a failure. For instance,
you could add a check in Makefile which triggers when git.c is edited.
It might do something like this:
awk '/cmd_struct commands/,/};/ { if (match($2,//)) print $2 }'
git.c builtin.actual
sort builtin.actual builtin.expect
cmp -s builtin.expect builtin.actual
rm builtin.expect builtin.actual
+
+ if (p)
exit(run_builtin(p, argc, argv));
- }
}
static void execv_dashed_external(const char **argv)
--
--
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/RFC] core.precomposeunicode is true by default
When core.precomposeunicode was introduced, it was set to false
by default, to be compatible with older versions of Git.
Whenever UTF-8 file names are used in a mixed environment,
the Mac OS users need to find out that this configuration exist
and set it to true manually.
There is no measurable performance impact between false and true.
A smoother workflow can be achieved for new Git users,
so change the default to true:
- Remove the auto-sensing
- Rename the internal variable into precompose_unicode,
and set it to 1 meaning true.
- Adjust and clean up test cases
The configuration core.precomposeunicode is still supported.
Signed-off-by: Torsten Bögershausen tbo...@web.de
---
Documentation/config.txt | 2 +-
builtin/init-db.c| 1 -
cache.h | 2 +-
compat/precompose_utf8.c | 28 ++--
compat/precompose_utf8.h | 1 -
config.c | 2 +-
environment.c| 2 +-
git-compat-util.h| 1 -
t/t0050-filesystem.sh| 1 +
t/t3910-mac-os-precompose.sh | 14 --
t/t7400-submodule-basic.sh | 1 -
11 files changed, 7 insertions(+), 48 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index e0b923f..abe4cfa 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -240,7 +240,7 @@ core.precomposeunicode::
This option is only used by Mac OS implementation of Git.
When core.precomposeunicode=true, Git reverts the unicode decomposition
of filenames done by Mac OS. This is useful when sharing a repository
- between Mac OS and Linux or Windows.
+ between Mac OS and Linux or Windows. True by default.
(Git for Windows 1.7.10 or higher is needed, or Git under cygwin 1.7).
When false, file names are handled fully transparent by Git,
which is backward compatible with older versions of Git.
diff --git a/builtin/init-db.c b/builtin/init-db.c
index 78aa387..08854d5 100644
--- a/builtin/init-db.c
+++ b/builtin/init-db.c
@@ -290,7 +290,6 @@ static int create_default_files(const char *template_path)
strcpy(path + len, CoNfIg);
if (!access(path, F_OK))
git_config_set(core.ignorecase, true);
- probe_utf8_pathname_composition(path, len);
}
return reinit;
diff --git a/cache.h b/cache.h
index 4c606ce..abb2cad 100644
--- a/cache.h
+++ b/cache.h
@@ -593,7 +593,7 @@ extern int read_replace_refs;
extern int fsync_object_files;
extern int core_preload_index;
extern int core_apply_sparse_checkout;
-extern int precomposed_unicode;
+extern int precompose_unicode;
/*
* The character that begins a commented line in user-editable file
diff --git a/compat/precompose_utf8.c b/compat/precompose_utf8.c
index 7980abd..5396b91 100644
--- a/compat/precompose_utf8.c
+++ b/compat/precompose_utf8.c
@@ -36,30 +36,6 @@ static size_t has_non_ascii(const char *s, size_t maxlen,
size_t *strlen_c)
}
-void probe_utf8_pathname_composition(char *path, int len)
-{
- static const char *auml_nfc = \xc3\xa4;
- static const char *auml_nfd = \x61\xcc\x88;
- int output_fd;
- if (precomposed_unicode != -1)
- return; /* We found it defined in the global config, respect it
*/
- strcpy(path + len, auml_nfc);
- output_fd = open(path, O_CREAT|O_EXCL|O_RDWR, 0600);
- if (output_fd = 0) {
- close(output_fd);
- strcpy(path + len, auml_nfd);
- /* Indicate to the user, that we can configure it to true */
- if (!access(path, R_OK))
- git_config_set(core.precomposeunicode, false);
- /* To be backward compatible, set precomposed_unicode to 0 */
- precomposed_unicode = 0;
- strcpy(path + len, auml_nfc);
- if (unlink(path))
- die_errno(_(failed to unlink '%s'), path);
- }
-}
-
-
void precompose_argv(int argc, const char **argv)
{
int i = 0;
@@ -67,7 +43,7 @@ void precompose_argv(int argc, const char **argv)
char *newarg;
iconv_t ic_precompose;
- if (precomposed_unicode != 1)
+ if (!precompose_unicode)
return;
ic_precompose = iconv_open(repo_encoding, path_encoding);
@@ -130,7 +106,7 @@ struct dirent_prec_psx *precompose_utf8_readdir(PREC_DIR
*prec_dir)
prec_dir-dirent_nfc-d_ino = res-d_ino;
prec_dir-dirent_nfc-d_type = res-d_type;
- if ((precomposed_unicode == 1) has_non_ascii(res-d_name,
(size_t)-1, NULL)) {
+ if (precompose_unicode has_non_ascii(res-d_name,
(size_t)-1, NULL)) {
if (prec_dir-ic_precompose == (iconv_t)-1) {
die(iconv_open(%s,%s) failed, but needed:\n
precomposed unicode is not
Re: [REQUEST 1/1] docs: update http.url.* options documentation
On Jul 26, 2013, at 15:27, Jeff King wrote: On Thu, Jul 25, 2013 at 11:23:23PM -0700, Kyle J. McKay wrote: IMHO, this would be more clear as a single item, like: . User name (e.g., `user` in `https://u...@example.com/repo.git`). If the config key has a user name it must match the user name in the URL exactly. If the config key does not have a user name, that config key will match a URL with any user name (including none). The only problem I have with a single item is what's the precedence? Does an exact user match have the same precedence as an any-user match? That would seem to be implied by having them as the same item number. Separating them would appear to make it clearer that an exact user match wins over an any user match, but if you have some alternate text as a suggestion for the single item that clears that up... :) Ah, I see your thinking now. You want to say no username has less precedence than some username, which has less precedence than a path, so they are all elements of a single list. My thinking was username has precedence less than path, and like a shorter path has less precedence than a longer path, an empty username has less precedence than a non-empty username. I agree my suggested wording would need to mention that explicitly. Like: . User name (e.g., `user` in `https://u...@example.com/repo.git`). If the config key has a user name it must match the user name in the URL exactly. If the config key does not have a user name, that config key will match a URL with any user name (including none), but at lower precedence than a config key with a user name. I can live with it either way, though. They are just two ways of considering the same thing. I am considering this text to address that: All URLs are normalized (%-encodings are standardized, case- insensitive parts are lowercased, `./` and `../` path components are resolved) before attempting any matching (the password part, if embedded in the URL, but I'm not sure the extra verbiage makes it better. I think it may just complicate the explanation unnecessarily? Yeah, I think I agree. Let's leave it out. So there's a version of this in next as cea9928 and I think that version is fine. If the documentation gets updated in the future, or perhaps moved to a separate urls-matching.txt for some reason at some point (git config --url, git config --url-parse), I'll make a point of inserting the , but at lower precedence than a config key with a user name text. Kyle -- 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: [REQUEST 1/1] docs: update http.url.* options documentation
On Fri, Jul 26, 2013 at 07:15:07PM -0700, Kyle J. McKay wrote: So there's a version of this in next as cea9928 and I think that version is fine. If the documentation gets updated in the future, or perhaps moved to a separate urls-matching.txt for some reason at some point (git config --url, git config --url-parse), I'll make a point of inserting the , but at lower precedence than a config key with a user name text. Unless you are planning to do that immediately, we are very likely to forget. Either it is worth adding or not, and if it is, we should not let having to add one more commit stop us. Here it is in patch form, so the amount of effort does not influence our decision. :) I'd lean towards including it, but don't feel strongly. -- 8 -- Subject: [PATCH] docs: mention precedence of empty username matching in URLs The documentation makes it clear that a URL with a username will match a config entry with or without a username, but is not clear that in the presence of both, the one with username would be preferred. Signed-off-by: Jeff King p...@peff.net --- Documentation/config.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index 0dd5566..f2ed9ef 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -1568,7 +1568,8 @@ http.url.*:: . User name (e.g., `user` in `https://u...@example.com/repo.git`). If the config key has a user name it must match the user name in the URL exactly. If the config key does not have a user name, that - config key will match a URL with any user name (including none). + config key will match a URL with any user name (including none), + but at a lower precedence than a config key with a user name. -- + The list above is ordered by decreasing precedence; a URL that matches -- 1.8.3.rc1.30.gff0fb75 -- 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: [REQUEST 1/1] docs: update http.url.* options documentation
On Jul 26, 2013, at 19:43, Jeff King wrote: On Fri, Jul 26, 2013 at 07:15:07PM -0700, Kyle J. McKay wrote: So there's a version of this in next as cea9928 and I think that version is fine. If the documentation gets updated in the future, or perhaps moved to a separate urls-matching.txt for some reason at some point (git config --url, git config --url-parse), I'll make a point of inserting the , but at lower precedence than a config key with a user name text. Unless you are planning to do that immediately, we are very likely to forget. Either it is worth adding or not, and if it is, we should not let having to add one more commit stop us. Here it is in patch form, so the amount of effort does not influence our decision. :) I'd lean towards including it, but don't feel strongly. -- 8 -- Subject: [PATCH] docs: mention precedence of empty username matching in URLs The documentation makes it clear that a URL with a username will match a config entry with or without a username, but is not clear that in the presence of both, the one with username would be preferred. Signed-off-by: Jeff King p...@peff.net --- Documentation/config.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index 0dd5566..f2ed9ef 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -1568,7 +1568,8 @@ http.url.*:: . User name (e.g., `user` in `https://u...@example.com/repo.git`). If the config key has a user name it must match the user name in the URL exactly. If the config key does not have a user name, that - config key will match a URL with any user name (including none). + config key will match a URL with any user name (including none), + but at a lower precedence than a config key with a user name. -- + The list above is ordered by decreasing precedence; a URL that matches -- 1.8.3.rc1.30.gff0fb75 I like it. :) +1 for adding it as an incremental patch to next. -- 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: repo consistency under crashes and power failures?
On Mon, Jul 15, 2013 at 01:48:23PM -0400, Greg Troxel wrote: I am curious if anyone has actual experiences to share, either a report of corruption after a crash (where corruption means that either 1) git fsck reports worse than dangling objects or 2) some ref did not either point to the old place or the new place) experiments intended to provoke corruption, like dropping power during pushes, or forced panics in the kernel due to timers, etc. I have quite a bit of experience with this, as I investigate all repo corruption that we see on github.com, and have run experiments to try to reproduce such corruption. Our backend git systems are ext3 with journaling and data=ordered. We run that on top of drbd, with two redundant machines sharing the block device. If one dies, we fail over to the spare. Writes to the block device are not considered committed until they are written to both machines. Git's scheme is to write objects (both loose and when receiving packs over the wire) via tempfile, with an atomic link-into-place after close. We do not fsync object files by default, but we do fsync packs. However, it shouldn't matter as long as your filesystem orders data and metadata writes (if it doesn't, you probably want to turn on object fsyncing). So for our data=ordered filesystems, that's fine. Ref writes have a similar fsync situation to loose object files. We write the new ref to a tempfile, close, and then rename into place. If the data and metadata writes are out of order, one could have problems (but again, not a problem with data=ordered). Most of the corruption we have seen at GitHub has been one of: 1. Buggy non-core-git implementations that do not properly use tempfiles to create objects (Grit used to have this problem, but it is now fixed). 2. Race conditions in examining ref state that can cause refs to be missed when determining reachability (thus you might prune objects that should be left). The worst of these is fixed in the current master and will be part of git v1.8.4. There are still ways that we can prune too much, but they are reasonably unlikely unless you are pruning constantly. We did once experience some lost objects after a server failover. After much experimentation, we finally found out that the machine in question had a RAID card with bad memory which would drop some writes which it claimed to have committed after a power failure (so even fsync did not help). So for ordered data and metadata writes, in my experience git is quite solid against power failures and crashes. For systems without that guarantee, you should turn on core.fsyncobjectfiles, but I suspect you could also see some ref corruption (and possibly index corruption, too, as it does not fsync either). -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: limit memory usage on large repositories
On Wed, Jul 10, 2013 at 05:27:57PM -0500, Matt Schoen wrote: I've been using git for some time now, and host my remote bare repositories on my shared hosting account at Dreamhost.com. As a protective feature on their shared host setup, they enact a policy that kills processes that consume too much memory. This happens to git sometimes. By sometimes I mean on large repos (~500MB), when performing operations like git gc and git fsck and, most annoyingly, when doing a clone. It seems to happen in the pack phase, but I can't be sure exactly. Do you know how they measure the memory? One of the problems we've had at GitHub in measuring git's memory usage is that git will mmap the fairly large packfiles. This can bloat the RSS of the git process. At the same time, not counting the map is not quite right, either; it is memory the process is using, but it could stand to give up some of it if other processes needed it (and that giving up is managed by the kernel, not by git). So you end up in a situation where you may have a large RSS precisely _because_ there is no memory pressure on the system, which leaves the kernel free to leave the mmap'd pages in RAM. You can reduce the amount of memory you map at once with core.packedGitWindowSize. I've messed around with the config options like pack.threads and pack.sizeLimit, and basically anything on the git config manpage that mentions memory. I limit all of these things to 1 or 0 or 1m when applicable, just to be sure. To be honest, I really don't know what I'm doing ;) I assume you did pack.deltaCacheSize, which can take a fair bit of memory during packing (or cloning). Packing itself takes up a lot, as I think we keep the whole window's worth of objects in memory at one time (so 10 by default). If you have large objects, that can spike your memory usage for a moment as we keep several versions of the large object in memory at once. If you have such large objects that don't delta well, you can use the nodelta gitattribute so that git doesn't even try them. Oddly enough, I'm having trouble reproducing my issue with anything but git fsck. Clones were failing in the past, but after a successful git gc, everything seems to be ok(?) Memory usage for clone should improve after a gc, as we will mostly be reusing deltas from disk instead of trying to find new ones between packs. -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
