[PATCH] Update git-multimail to version 1.0.2
The only changes are to the README files, most notably the list of maintainers and the project URL. Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- contrib/hooks/multimail/README | 43 +++--- contrib/hooks/multimail/README.Git | 6 +++--- 2 files changed, 25 insertions(+), 24 deletions(-) diff --git a/contrib/hooks/multimail/README b/contrib/hooks/multimail/README index 477d65f..6efa4ff 100644 --- a/contrib/hooks/multimail/README +++ b/contrib/hooks/multimail/README @@ -456,34 +456,35 @@ consider sharing them with the community! Getting involved -git-multimail is an open-source project, built by volunteers. We -would welcome your help! +git-multimail is an open-source project, built by volunteers. We would +welcome your help! -The current maintainer is Michael Haggerty mhag...@alum.mit.edu. +The current maintainers are Michael Haggerty mhag...@alum.mit.edu +and Matthieu Moy matthieu@grenoble-inp.fr. -General discussion of git-multimail takes place on the main Git -mailing list, +Please note that although a copy of git-multimail is distributed in +the contrib section of the main Git project, development takes place +in a separate git-multimail repository on GitHub: -git@vger.kernel.org +https://github.com/git-multimail/git-multimail -Please CC emails regarding git-multimail to me so that I don't -overlook them. +Whenever enough changes to git-multimail have accumulated, a new +code-drop of git-multimail will be submitted for inclusion in the Git +project. -The git-multimail project itself is currently hosted on GitHub: +We use the GitHub issue tracker to keep track of bugs and feature +requests, and we use GitHub pull requests to exchange patches (though, +if you prefer, you can send patches via the Git mailing list with CC +to the maintainers). Please sign off your patches as per the Git +project practice. -https://github.com/mhagger/git-multimail +General discussion of git-multimail can take place on the main Git +mailing list, -We use the GitHub issue tracker to keep track of bugs and feature -requests, and GitHub pull requests to exchange patches (though, if you -prefer, you can send patches via the Git mailing list with cc to me). -Please sign off your patches as per the Git project practice. - -Please note that although a copy of git-multimail will probably be -distributed in the contrib section of the main Git project, -development takes place in the separate git-multimail repository on -GitHub! (Whenever enough changes to git-multimail have accumulated, a -new code-drop of git-multimail will be submitted for inclusion in the -Git project.) +git@vger.kernel.org + +Please CC emails regarding git-multimail to the maintainers so that we +don't overlook them. Footnotes diff --git a/contrib/hooks/multimail/README.Git b/contrib/hooks/multimail/README.Git index 129b771..ab3ece5 100644 --- a/contrib/hooks/multimail/README.Git +++ b/contrib/hooks/multimail/README.Git @@ -3,13 +3,13 @@ section of the Git project as a convenience to Git users. git-multimail is developed as an independent project at the following website: -https://github.com/mhagger/git-multimail +https://github.com/git-multimail/git-multimail The version in this directory was obtained from the upstream project -on 2014-04-07 and consists of the git-multimail subdirectory from +on 2015-04-27 and consists of the git-multimail subdirectory from revision -1b32653bafc4f902535b9fc1cd9cae911325b870 +8c3aaafa873bf10de8dddf1d202c449b3eff3b42 refs/tags/1.0.2 Please see the README file in this directory for information about how to report bugs or contribute to git-multimail. -- 2.1.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: [PATCH] blame: add blame.showemail config option
On Mon, Apr 27, 2015 at 9:46 AM, Quentin Neill quentin.ne...@gmail.com wrote: On Fri, Apr 24, 2015 at 12:22 AM, Eric Sunshine sunsh...@sunshineco.com wrote: It's not clear why you relocated documentation of --show-email from git-blame.txt to blame-options.txt, and the commit message does not explain the move. If there's a good reason for the relocation, the justification should be spelled out so that people reviewing the patch or looking through history later on will not have to guess about it. I moved it to be with the other variables that had configuration options, but I will move it back. It might also make sense to do the relocation as a separate preparatory patch of a 2-patch series, in which the patch adding blame.showemail is the second of the two. If you think it should be relocated, I will address in a separate patch. Junio's response[1] addresses both points nicely. To be clear, I wasn't suggesting that you should do the relocation, but instead that the relocation seemed unrelated to the overall intent of the patch and that its purpose wasn't clear. So, as a general statement, when the motive for a change is unclear, it deserves explanation in the commit message; and when a change is not directly related to the patch itself, it often deserves to be placed in its own patch. In this case, neither applies since the relocation is unwarranted. - if (opt OUTPUT_SHOW_EMAIL) + if ((opt OUTPUT_SHOW_EMAIL) || show_email) The desired behavior is for a configuration setting to provide a fallback, and for a command-line option to override the fallback. So, for instance, if blame.showemail is true, then --no-show-email should countermand that. Unfortunately, the way this patch is implemented, it's impossible to override the setting from the command-line since show_email==true will always win (when blame.showemail is true). More below. I followed the code for blame.showRoot and blame.blankboundary. I think the desired behavior for the other switches would go in a separate patch, the question is should it precede this one adding 'blame.showemail'? As per Junio's response[1], logic for the other configuration options seems to be fine, so I'm not quite sure what changes you propose. You'll also want to add tests for the new blame.showemail configuration. There's already one test in t8002-blame.sh which checks that --show-email works, but you will want tests to ensure that you get the expected results for all combinations of blame.showemail and --show-email (including when --show-email is not specified). Agreed, but again I don't see tests for the other switches with options. Unfortunately, test coverage is sometimes sparse, however, patches with accompanying tests are looked upon with favor and instill greater confidence, so they are encouraged. If you need assistance with the tests, feel free to ask. It's not your responsibility to fill the gaps of missing tests for other options which you're not touching, but you're welcome to add tests for them if you want to. [1]: http://thread.gmane.org/gmane.comp.version-control.git/267720/focus=267862 -- 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
GSoC 2015: 2 accepted proposals
Hi, The results just got offical: the Git organization has 2 students accepted for the summer of code 2015. Karthik Nayak will work on Unifying git branch -l, git tag -l, and git for-each-ref mentored by Christian Couder and yours truly. Paul Tan will work on Make git-pull and git-am builtins, mentored by Johannes Schindelin and Stefan Beller. Regards, -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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] Update git-multimail to version 1.0.2
On 04/27/2015 09:05 PM, Junio C Hamano wrote: Matthieu Moy matthieu@grenoble-inp.fr writes: Junio C Hamano gits...@pobox.com writes: [...] Well, the patch does not update git_multimail.py at all. Requoting the part you omitted from my response $ git rev-list -1 master contrib/hooks/multimail/ b513f71f6043c05c3918e670b332dfa7ec6b2661 which is b513f71f (git-multimail: update to version 1.0.0, 2014-04-07) it matches what was obtained from the upstream project on 2014-04-07. Yes, but it also matches was obtained on 2015-04-27, since only the README has changed (the commit message of this patch says: The only changes are to the README files, most notably the list of maintainers and the project URL.). Or did you forget to include the update to the software in the patch? The update to the software is empty. Hmm, that may be technically correct but it is grossly misleading to update the existing was obtained on 2014-04-07 to was obtained on 2015-04-27, especially if nothing was actually obtained, isn't it? I'm sorry to have caused confusion. Matthieu, your explanations have been exactly correct. Let me just add a couple of details: Junio, you asked me (off-list) for an update to README and README.Git. Those two files come from the git-multimail repo, as git-multimail/README and git-multimail/README.Git.template, respectively, so I modified the files in our repo then submitted the corresponding patch to your repo. It's true that only documentation changes are in the patch, but it still seemed like good practice to create a tag and all that. If nothing else, it will make it easier to figure out the baseline for future code drops. There have been a couple of small software changes in git-multimail's master branch, but I didn't include those in the patch I submitted to you because I thought you wouldn't want to have code changes so close to the release. So 1.0.2 is on the newly-created maint branch. I honestly am surprised that, after seeing the announcement about a new repository, co-maintainer and multiple contributors, no code change is made over the past 12 months. I totally understand your disappointment. Mea culpa. That, in fact, is WHY I'm so happy that Matthieu has agreed to help maintain the project. If it's any consolation, none of the user feedback that I have been so remiss in addressing involves serious or security-related bugs. I would understand it if the description were The version in this directory matches the upstream project as of 2015-04-27, though. I think of the contents of contrib/hooks/multimail as a whole, so even if the software hasn't changed, updated documentation *has* been obtained from upstream. But feel free to adjust the text in whatever way you like. Michael -- Michael Haggerty mhag...@alum.mit.edu -- 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: Rebasing with submodule change causes red herring with --continue
On Thu, Apr 23, 2015 at 5:43 PM, John Keeping j...@keeping.me.uk wrote: On Thu, Apr 23, 2015 at 09:35:38PM +0100, John Keeping wrote: On Thu, Apr 23, 2015 at 09:43:44PM +0200, Jens Lehmann wrote: Am 23.04.2015 um 21:07 schrieb Robert Dailey: On Thu, Apr 23, 2015 at 1:17 PM, Robert Dailey rcdailey.li...@gmail.com wrote: On Fri, Apr 10, 2015 at 11:44 AM, John Keeping j...@keeping.me.uk wrote: On Fri, Apr 10, 2015 at 11:30:20AM -0500, Robert Dailey wrote: I have a branch that contains a commit with a single change: A submodule pointing to a new SHA1. When I rebase this branch onto the tip of its parent branch AND that parent branch had modified that same submodule, the rebase stops at the commit on my branch that modified the submodule and asks me if I want to keep REMOTE or LOCAL. I say LOCAL and notice immediately that the submodule is not staged (normally it would be). I do: $ git add my-submodule Then I do: $ git rebase --continue At this point, it fails asking me if I forgot to stage changes and recommends doing --skip. This is normally what you would see if the staging area was completely empty, however it isn't, since I see the submodule is in there. Is this a bug or am I missing a fundamental here? I'm using Git 2.1.0 on Windows through MSYS. I'll provide more concrete examples if my summary of the issue doesn't ring any bells. I hit something similar in the past, but it was fixed with commit a6754cd (rebase -i continue: don't skip commits that only change submodules, 2012-04-07) so I think you must be hitting a slightly different problem, although the tests added in that commit look like they do test the scenario you describe (specifically 'rebase -i continue with only submodule staged'). I am still running into this issue on git 2.3.5 on Windows. Logs below. One interesting thing to note in the git trace output is that it is specifying --ignore-submodules option to `git diff-files` during the rebase continue. Is this due to a configuration option? It seems like git should not be ignoring submodules when continuing a rebase (this should only affect direct calls to diff) |-- Robert@M5536:/e/code/frontend (timeline-ids-develop|REBASE 3/3) --| $ git status rebase in progress; onto bb05e7c You are currently rebasing branch 'timeline-ids-develop' on 'bb05e7c'. (all conflicts fixed: run git rebase --continue) Changes to be committed: (use git reset HEAD file... to unstage) modified: Core Changes not staged for commit: (use git add file... to update what will be committed) (use git checkout -- file... to discard changes in working directory) modified: Core (new commits) Untracked files: (use git add file... to include in what will be committed) Tools/FontTool/ |-- Robert@M5536:/e/code/frontend (timeline-ids-develop|REBASE 3/3) --| $ GIT_TRACE=1 git rebase --continue 19:15:33.569945 git.c:557 trace: exec: 'git-rebase' '--continue' 19:15:33.569945 run-command.c:351 trace: run_command: 'git-rebase' '--continue' 19:15:33.775097 git.c:348 trace: built-in: git 'rev-parse' '--parseopt' '--stuck-long' '--' '--continue' 19:15:33.931190 git.c:348 trace: built-in: git 'rev-parse' '--git-dir' 19:15:34.007242 git.c:348 trace: built-in: git 'rev-parse' '--is-bare-repository' 19:15:34.059280 git.c:348 trace: built-in: git 'rev-parse' '--show-toplevel' 19:15:34.148343 git.c:348 trace: built-in: git 'config' '--bool' 'rebase.stat' 19:15:34.227399 git.c:348 trace: built-in: git 'config' '--bool' 'rebase.autostash' 19:15:34.280437 git.c:348 trace: built-in: git 'config' '--bool' 'rebase.autosquash' 19:15:34.335476 git.c:348 trace: built-in: git 'rev-parse' '--verify' 'HEAD' 19:15:34.389515 git.c:348 trace: built-in: git 'update-index' '--ignore-submodules' '--refresh' 19:15:34.554631 git.c:348 trace: built-in: git 'diff-files' '--quiet' '--ignore-submodules' 19:15:34.902879 git.c:557 trace: exec: 'git-am' '--resolved' '--resolvemsg= When you have resolved this problem, run git rebase --continue. If you prefer to skip this patch, run git rebase --skip instead. To check out the original branch and stop rebasing, run git rebase --abort. ' 19:15:34.902879 run-command.c:351 trace: run_command: 'git-am' '--resolved' '--resolvemsg= When you have resolved this problem, run git rebase --continue. If you prefer to skip this patch, run git rebase --skip instead. To check out the original branch and stop rebasing, run git rebase --abort. ' 19:15:35.113028 git.c:348
Re: [PATCH/RFC] blame: CRLF in the working tree and LF in the repo
On 04/27/2015 07:47 PM, Junio C Hamano wrote: Junio C Hamano gits...@pobox.com writes: I suspect (I haven't looked very carefully for this round yet to be sure, though) that it may turn out that the commit you are proposing to revert was a misguided attempt to fix a non issue, or to break the behaviour to match a mistaken expectation. If that is the case then definitely the reversion is a good idea, and you should argue along that line of justification. We'd just be fixing an old misguided and bad change in such a case. The original says this: blame: correctly handle files regardless of autocrlf If a file contained CRLF line endings in a repository with core.autocrlf=input, then blame always marked lines as Not Committed Yet, even if they were unmodified. Don't attempt to convert the line endings when creating the fake commit so that blame works correctly regardless of the autocrlf setting. Reported-by: Ephrim Khong dr.kh...@gmail.com Signed-off-by: brian m. carlson sand...@crustytoothpaste.net Signed-off-by: Junio C Hamano gits...@pobox.com But if autocrlf=input, then the end-user expectation is to keep the in-repository data with LF line endings. If your tip-of-the-tree commit incorrectly has CRLF line endings, and if you were going to commit what is in the working tree on top, you would be correcting that mistake by turning the in-repository data into a text file with LF line endings, so Not Committed Yet _is_ the correct behaviour. So I think that the reverting that change is the right thing to do. It really was a change to break the behaviour to match a mistaken expectation, I would have to say. Besides a better commit message (suggestions welcome), What do you think about the following test cases for a V2 patch ? test_expect_success 'create blamerepo' ' test_create_repo blamerepo ( cd blamerepo printf testcase\r\n crlffile git -c core.autocrlf=false add crlffile git commit -m add files git -c core.autocrlf=false blame crlffile crlfclean.txt ) ' test_expect_success 'blaming files with CRLF newlines in repo, core.autoclrf=input' ' ( cd blamerepo git -c core.autocrlf=input blame crlffile actual grep Not Committed Yet actual ) ' test_expect_success 'blaming files with CRLF newlines core.autocrlf=true' ' ( cd blamerepo git -c core.autocrlf=true blame crlffile actual test_cmp crlfclean.txt actual ) ' test_expect_success 'blaming files with CRLF newlines core.autocrlf=false' ' ( cd blamerepo git -c core.autocrlf=false blame crlffile actual test_cmp crlfclean.txt actual ) ' -- 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's cooking in git.git (Apr 2015, #04; Mon, 27)
Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. I'll merge two small documentation follow-up to the new features in 2.4.0 (mg/status-v-v and nd/versioncmp-prereleases topics) to 'master' and tag the final Git 2.4 later this week. You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-public-repositories.html -- [Graduated to master] * jc/push-cert (2015-04-02) 1 commit (merged to 'next' on 2015-04-08 at aecdd43) + push --signed: tighten what the receiving end can ask to sign The git push --signed protocol extension did not limit what the nonce that is a server-chosen string can contain or how long it can be, which was unnecessarily lax. Limit both the length and the alphabet to a reasonably small space that can still have enough entropy. * ma/bash-completion-leaking-x (2015-04-12) 1 commit (merged to 'next' on 2015-04-14 at 3a52a6d) + completion: fix global bash variable leak on __gitcompappend The completion script (in contrib/) contaminated global namespace and clobbered on a shell variable $x. * ps/grep-help-all-callback-arg (2015-04-12) 1 commit (merged to 'next' on 2015-04-14 at e0a8092) + grep: correctly initialize help-all option Code clean-up. * tb/connect-ipv6-parse-fix (2015-04-08) 1 commit (merged to 'next' on 2015-04-14 at e720918) + connect.c: ignore extra colon after hostname An earlier update to the parser that disects a URL broke an address, followed by a colon, followed by an empty string (instead of the port number), e.g. ssh://example.com:/path/to/repo. This should go to the maintenance track, too. * va/fix-git-p4-tests (2015-04-12) 3 commits (merged to 'next' on 2015-04-14 at 261bf90) + t9814: guarantee only one source exists in git-p4 copy tests + git-p4: fix copy detection test + t9814: fix broken shell syntax in git-p4 rename test Test fixes for git-p4. -- [New Topics] * jc/epochtime-wo-tz (2015-04-15) 2 commits (merged to 'next' on 2015-04-21 at b926f72) + parse_date_basic(): let the system handle DST conversion + parse_date_basic(): return early when given a bogus timestamp git commit --date=now or anything that relies on approxidate lost the daylight-saving-time offset. Will merge to 'master' in the second batch of post v2.4 cycle. * jc/plug-fmt-merge-msg-leak (2015-04-20) 1 commit (merged to 'next' on 2015-04-21 at 443c728) + fmt-merge-msg: plug small leak of commit buffer Will merge to 'master' in the second batch of post v2.4 cycle. * cn/bom-in-gitignore (2015-04-16) 5 commits (merged to 'next' on 2015-04-21 at f7d56f1) + attr: skip UTF8 BOM at the beginning of the input file + config: use utf8_bom[] from utf.[ch] in git_parse_source() + utf8-bom: introduce skip_utf8_bom() helper + add_excludes_from_file: clarify the bom skipping logic + dir: allow a BOM at the beginning of exclude files Teach the codepaths that read .gitignore and .gitattributes files that these files encoded in UTF-8 may have UTF-8 BOM marker at the beginning; this makes it in line with what we do for configuration files already. Will merge to 'master' in the second batch of post v2.4 cycle. * ee/clean-remove-dirs (2015-04-26) 5 commits - clean: improve performance when removing lots of directories - p7300: add performance tests for clean - t7300: add tests to document behavior of clean and nested git - setup: sanity check file size in read_gitfile_gently - setup: add gentle version of read_gitfile Replace is this subdirectory a separate repository that should not be touched? check git clean does by checking if it has .git/HEAD using the submodule-related code with a more optimized check. Will merge to 'next'. * ep/fix-test-lib-functions-report (2015-04-16) 1 commit (merged to 'next' on 2015-04-21 at 23e584f) + test-lib-functions.sh: fix the second argument to some helper functions Will merge to 'master' in the second batch of post v2.4 cycle. * jk/still-interesting (2015-04-17) 1 commit (merged to 'next' on 2015-04-21 at 58b54af) + limit_list: avoid quadratic behavior from still_interesting git rev-list --objects $old --not --all to see if everything that is reachable from $old is already connected to the existing refs was very inefficient. Will merge to 'master' in the second batch of post v2.4 cycle. * jk/type-from-string-gently (2015-04-17) 1 commit (merged to 'next' on 2015-04-20 at a97611f) + type_from_string_gently: make sure length matches git cat-file bl $blob failed to barf even though there is no object type that is bl. Will merge to 'master' in the first batch of post v2.4 cycle. * ls/p4-changes-block-size (2015-04-20) 1 commit (merged to 'next' on 2015-04-21 at 830eeed) + git-p4: use -m
[ANNOUNCE] Git v2.3.7
The latest maintenance release Git v2.3.7 is now available at the usual places. Hopefully this will be the last v2.3.x update until the master front is tagged as v2.4 final. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/ The following public repositories all have a copy of the 'v2.3.7' tag and the 'maint' branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://code.google.com/p/git-core/ url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git Git v2.3.7 Release Notes Fixes since v2.3.6 -- * An earlier update to the parser that disects a URL broke an address, followed by a colon, followed by an empty string (instead of the port number), e.g. ssh://example.com:/path/to/repo. * The completion script (in contrib/) contaminated global namespace and clobbered on a shell variable $x. * The git push --signed protocol extension did not limit what the nonce that is a server-chosen string can contain or how long it can be, which was unnecessarily lax. Limit both the length and the alphabet to a reasonably small space that can still have enough entropy. Also contains typofixes, documentation updates and trivial code clean-ups. Changes since v2.3.6 are as follows: Junio C Hamano (2): push --signed: tighten what the receiving end can ask to sign Git 2.3.7 Márcio Almada (1): completion: fix global bash variable leak on __gitcompappend Torsten Bögershausen (1): connect.c: ignore extra colon after hostname -- 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/RFC] blame: CRLF in the working tree and LF in the repo
On 04/27/2015 08:58 PM, Johannes Sixt wrote: Am 27.04.2015 um 08:11 schrieb Stepan Kasal: Git does not support CRLF as the internal line separator. If you commit file in binary mode with CRLF, you are on your own. When I commit my C source code files with CRLF into the repository (because I do not set any line ending options or configurations or any 'text' attributes or similar), do I then commit binary files or text files? Should I expect not to see any diffs? -- Hannes You commit files with CRLF in the repo. If you have CRLF in the working tree, things are as follows: core.autocrlf=false : Same as binary, no changes core.autocrlf=true: Normalization is suppressed, (CRLF in repo), and therefore no changes. core.autocrlf=input : Normalization wanted, (CRLF in repo), normalization will be done (and should be committed as soon as possible) -- 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 3/3] connect: improve check for plink to reduce false positives
Hi, On 2015-04-26 22:30, brian m. carlson wrote: The git_connect function has code to handle plink and tortoiseplink specially, as they require different command line arguments from OpenSSH (-P instead of -p for ports; tortoiseplink additionally requires -batch). However, the match was done by checking for plink anywhere in the string, which led to a GIT_SSH value containing uplink being treated as an invocation of putty's plink. Improve the check by looking for plink or tortoiseplink (or those names suffixed with .exe) only in the final component of the path. This has the downside that a program such as plink-0.63 would no longer be recognized, but the increased robustness is likely worth it. Add tests to cover these cases to avoid regressions. Signed-off-by: brian m. carlson sand...@crustytoothpaste.net I like it! Acked-by: Johannes Schindelin johannes.schinde...@gmx.de Ciao, Dscho -- 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/RFC] blame: CRLF in the working tree and LF in the repo
Hello, On Sun, Apr 26, 2015 at 10:31:11PM -0700, Junio C Hamano wrote: [...] the commit you are proposing to revert [4d4813a5] was a misguided attempt to fix a non issue, [...] yes, it was this. So I propose to remove the whole commit, including the test case and add two new test cases. Details: Git does not support CRLF as the internal line separator. If you commit file in binary mode with CRLF, you are on your own. If you then recode the file in the working tree to use LF, no wonder things break. If you do it indirectly, by setting the file mode to text, things break exactly the same way. And that is the case that 4d4813a5 wanted to fix, cf the test case in it. OTOH, the commit has broken the most recommended scenario for Windows: LF in the repo, CRLF in the work tree. Thanks, Stepan -- 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
gute Neuigkeiten
gute Neuigkeiten Handy, Laptop, TV-Raum, Goultard . Versand ist kostenlos Alle unsere Produkte können Preferred Rabatt von 50% angeboten werden si te: weacaoo . com
Re: Cleaning projects with submodules
Hi, On Sat, Apr 25, 2015 at 11:36:25PM +0200, Simon Richter wrote: I'm trying to set up a continuous integration build for Boost, which uses massive amounts of submodules, and keep running into problems when running git clean in the toplevel project. When I switch to a version where a submodule has been removed (e.g. an earlier version), git clean -dx will not remove the submodule's directory, because it has its own .git directory. Using a single -f flag, the process fails (because directories containing .git directories are no longer skipped), and using -ff removes all submodules (which is overkill). Is there a good way to clean a project, leaving valid submodules in place (these are then switched to the new tip and cleaned in separate commands) while removing submodules that are no longer referenced? Unfortunately there is no really nice way for that yet. Safely removing submodule ist still under development. Here is a snippet that I used on a CI server for this purpose: git status --porcelain | grep ^?? | sed -e 's/^?? //' | \ while read i; do rm -rf $i done It does a little more, since it unconditionally removes all untracked files that are not ignored. Cheers Heiko -- 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] Update git-multimail to version 1.0.2
Michael Haggerty mhag...@alum.mit.edu writes: The only changes are to the README files, most notably the list of maintainers and the project URL. Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- contrib/hooks/multimail/README | 43 +++--- contrib/hooks/multimail/README.Git | 6 +++--- 2 files changed, 25 insertions(+), 24 deletions(-) Acked-by: Matthieu Moy matthieu@imag.fr -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] git-compat-util.h: implement a different ARRAY_SIZE macro for for safely deriving the size of array
To get number of elements in an array git use the ARRAY_SIZE macro defined as:
#define ARRAY_SIZE(x) (sizeof(x)/sizeof((x)[0]))
The problem with it is a possibility of mistakenly passing to it a
pointer instead an array. The ARRAY_SIZE macro as conventionally
defined does not provide good type-safety and the open-coded approach
is more fragile, more verbose and provides no improvement in type-safety.
Use instead a different but compatible ARRAY_SIZE() macro,
which will also break compile if you try to
use it on a pointer. This implemention revert to the original code if
the compiler doesn't know the typeof and __builtin_types_compatible_p
GCC extensions.
This can ensure our code is robust to changes, without
needing a gratuitous macro or constant. A similar
ARRAY_SIZE implementation also exists in the linux kernel.
Credits to Rusty Russell and his ccan library.
Signed-off-by: Elia Pinto gitter.spi...@gmail.com
---
Makefile | 7 +++
configure.ac | 24
git-compat-util.h | 36 +++-
3 files changed, 66 insertions(+), 1 deletion(-)
This is the second version of this patch.
It had not been discussed before. In the second version, I just tried to
clarify
the comment in the commit. I resend it just in case you missed
diff --git a/Makefile b/Makefile
index 5f3987f..cb2a044 100644
--- a/Makefile
+++ b/Makefile
@@ -359,6 +359,9 @@ all::
# compiler is detected to support it.
#
# Define HAVE_BSD_SYSCTL if your platform has a BSD-compatible sysctl function.
+#
+# Define SUPPORT__BUILTIN_TYPES_COMPATIBLE_P if your compiler support
+# the builtin function __builtin_types_compatible_
GIT-VERSION-FILE: FORCE
@$(SHELL_PATH) ./GIT-VERSION-GEN
@@ -1437,6 +1440,10 @@ ifdef HAVE_BSD_SYSCTL
BASIC_CFLAGS += -DHAVE_BSD_SYSCTL
endif
+ifdef SUPPORT__BUILTIN_TYPES_COMPATIBLE_P
+ BASIC_CFLAGS += -DSUPPORT__BUILTIN_TYPES_COMPATIBLE_P
+endif
+
ifeq ($(TCLTK_PATH),)
NO_TCLTK = NoThanks
endif
diff --git a/configure.ac b/configure.ac
index bbdde85..151864d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -139,6 +139,28 @@ if test -n $1; then
fi
])
+AC_DEFUN([GIT_FUNC_TYPES_COMPATIBLE_P], [
+ AC_CACHE_CHECK([if compiler has __builtin_types_compatible_p function],
+ [cc_cv_func_types_compatible_p],
+ [ac_save_CFLAGS=$CFLAGS
+ CFLAGS=$CFLAGS -Werror
+ AC_COMPILE_IFELSE([AC_LANG_SOURCE(
+ [int some_function();
+ int some_function() {
+ return __builtin_types_compatible_p(char *, int) ? 1 :
0;
+ }])],
+ [cc_cv_func_types_compatible_p=yes],
+ [cc_cv_func_types_compatible_p=no])
+ CFLAGS=$ac_save_CFLAGS
+ ])
+
+ AS_IF([test x$cc_cv_func_types_compatible_p = xyes],
+ [GIT_CONF_SUBST([SUPPORT__BUILTIN_TYPES_COMPATIBLE_P],
[YesPlease])],
+ [$2])
+])
+
+
+
## Configure body starts here.
AC_PREREQ(2.59)
@@ -910,6 +932,8 @@ else
fi
GIT_CONF_SUBST([NEEDS_MODE_TRANSLATION])
+GIT_FUNC_TYPES_COMPATIBLE_P
+
## Checks for library functions.
## (in default C library and libraries checked by AC_CHECK_LIB)
diff --git a/git-compat-util.h b/git-compat-util.h
index bc8fc8c..8e9f6c2 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -25,7 +25,41 @@
#endif
#endif
-#define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))
+
+/*
+ * BUILD_ASSERT_OR_ZERO - assert a build-time dependency, as an expression.
+ * @cond: the compile-time condition which must be true.
+ *
+ * Your compile will fail if the condition isn't true, or can't be evaluated
+ * by the compiler. This can be used in an expression: its value is 0.
+ *
+ * Example:
+ * #define foo_to_char(foo)\
+ * ((char *)(foo) \
+ * + BUILD_ASSERT_OR_ZERO(offsetof(struct foo, string) == 0))
+ */
+#define BUILD_ASSERT_OR_ZERO(cond) \
+ (sizeof(char [1 - 2*!(cond)]) - 1)
+
+
+#if SUPPORT__BUILTIN_TYPES_COMPATIBLE_P
+/* arr[0] degrades to a pointer: a different type from an array */
+#define _array_size_chk(arr) \
+ BUILD_ASSERT_OR_ZERO(!__builtin_types_compatible_p(typeof(arr), \
+ typeof((arr)[0])))
+#else
+#define _array_size_chk(arr) 0
+#endif
+
+/*
+ * ARRAY_SIZE - get the number of elements in a visible array
+ * at x: the array whose size you want.
+ *
+ * This does not work on pointers, or arrays declared as [], or
+ * function parameters. With correct compiler support, such usage
+ * will cause a build error (see build_assert).
+ */
+#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]) + _array_size_chk(x))
#define bitsizeof(x) (CHAR_BIT * sizeof(x))
#define maximum_signed_value_of_type(a) \
--
2.1.0
--
Re: [PATCH v8 2/4] cat-file: teach cat-file a '--literally' option
On 04/25/2015 10:34 PM, Junio C Hamano wrote: karthik nayak karthik@gmail.com writes: Is there any other way to make cat-file looser other than accepting an unknown type name from the future? If not, then perhaps it may make sense to give it a generic name that implies that we would trigger such additional looseness in the future. But as the inventor of it as a debugging aid, I would say a name that spells out the specific way this option is being loose, e.g. --allow-bogus-type or with s/bogus/unknown/, best describes what it currently does. Yes this gives the best description, but its large, while we could use something like --no-strict instead. We could, if you answered my first question with no. By naming this --no-strict, the first bug report you will receive may be that cat-file --no-strict should parse a zlib deflate that begins with blob 1234\n\0 (notice that there are two SPs instead of the usual one, and length is followed by LF that should not be there before the NUL) but it does not. As your option name --no-strict signals that you will make the best effort to parse such nonsense, that would be a valid bug report, against which you would need to update the code to make it work. But is it worth the effort to make such a thing work? I dunno. Nice point, I don't see the need to parse such objects at the moment. That rules out --no-strict and everything similar. I still find --allow-unkown-type a bit too big, what about something like * --any-type * --arbitrary-type -- 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] blame: add blame.showemail config option
Thanks for the thorough review!
I have adjusted the commit messages and updated the documentation changes.
I'm in trying to add tests, I'll probably have some issues but will
post something that works soon.
As for the comments on behavior, see my responses below.
--
Quentin
There! His Majesty can now read my name without glasses. And he can
double the reward on my head! - John Hancock, upon signing the
Declaration of Independence
On Fri, Apr 24, 2015 at 12:22 AM, Eric Sunshine sunsh...@sunshineco.com wrote:
Thanks for the submission. See comments below...
On Thu, Apr 23, 2015 at 10:13 PM, Quentin Neill quentin.ne...@gmail.com
wrote:
From: Quentin Neill quentin.ne...@gmail.com
You should drop this line. git-am will pluck your name and email
automatically from the email From: header.
If you prefer seeing emails in your git blame output, rather
than sprinkling '-e' options everywhere you can just set
the new config blame.showemail to true.
Drop the indentation from the commit message.
It's not clear what everywhere means in the above. It might be
sufficient to rephrase more simply as:
Complement existing --show-email option with fallback
configuration variable.
or something.
---
Missing Signed-off-by:. See Documentation/SubmittingPatches.
diff --git a/Documentation/blame-options.txt
b/Documentation/blame-options.txt
index b299b59..9326115 100644
--- a/Documentation/blame-options.txt
+++ b/Documentation/blame-options.txt
@@ -1,6 +1,11 @@
-b::
Show blank SHA-1 for boundary commits. This can also
be controlled via the `blame.blankboundary` config option.
+-e::
+--show-email::
Insert a blank line before the -e line to separate it from the -b
paragraph.
+ Show the author email instead of author name (Default: off).
+ This can also be controlled via the `blame.showemail` config
+ option.
Despite being case-insensitive and despite existing inconsistencies,
in documentation, it is customary to use camelCase for configuration
options, so blame.showEmail.
Also blame.showEmail probably ought to be documented in
Documentation/config.txt (although there is some inconsistency here in
that documentation for the other blame-specific variables is missing
from config.txt, so perhaps that's something that could be addressed
separately).
--root::
Do not treat root commits as boundaries. This can also be
diff --git a/Documentation/git-blame.txt b/Documentation/git-blame.txt
index 9f23a86..50a9030 100644
--- a/Documentation/git-blame.txt
+++ b/Documentation/git-blame.txt
@@ -73,10 +73,6 @@ include::blame-options.txt[]
-s::
Suppress the author name and timestamp from the output.
--e::
---show-email::
- Show the author email instead of author name (Default: off).
-
It's not clear why you relocated documentation of --show-email from
git-blame.txt to blame-options.txt, and the commit message does not
explain the move. If there's a good reason for the relocation, the
justification should be spelled out so that people reviewing the patch
or looking through history later on will not have to guess about it.
I moved it to be with the other variables that had configuration
options, but I will move it back.
It might also make sense to do the relocation as a separate
preparatory patch of a 2-patch series, in which the patch adding
blame.showemail is the second of the two.
If you think it should be relocated, I will address in a separate patch.
-w::
Ignore whitespace when comparing the parent's version and
the child's to find where the lines came from.
diff --git a/builtin/blame.c b/builtin/blame.c
index 06484c2..70bfd0a 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -44,6 +44,7 @@ static int max_score_digits;
static int show_root;
static int reverse;
static int blank_boundary;
+static int show_email;
static int incremental;
static int xdl_opts;
static int abbrev = -1;
@@ -1926,7 +1927,7 @@ static void emit_other(struct scoreboard *sb, struct
blame_entry *ent, int opt)
printf(%.*s, length, hex);
if (opt OUTPUT_ANNOTATE_COMPAT) {
const char *name;
- if (opt OUTPUT_SHOW_EMAIL)
+ if ((opt OUTPUT_SHOW_EMAIL) || show_email)
The desired behavior is for a configuration setting to provide a
fallback, and for a command-line option to override the fallback. So,
for instance, if blame.showemail is true, then --no-show-email
should countermand that. Unfortunately, the way this patch is
implemented, it's impossible to override the setting from the
command-line since show_email==true will always win (when
blame.showemail is true).
More below.
I followed the code for blame.showRoot and blame.blankboundary.
I think the desired behavior for the other switches would go in a
separate patch, the question is should it
Re: [PATCH] git-p4: prevent --chain-lint failure
On Mon, Apr 27, 2015 at 11:20:28PM +0100, Luke Diamand wrote:
t9814 has a test that simply sets up a pre-requisite for
another test, and as such, always succeeds. The way it was
written doesn't quite work with the test lint checks introduced
with the --chain-lint option.
Add an additional layer of {} to prevent the --chain-lint
code getting confused.
Thanks for looking into this. I tried to fix any existing tests I could,
but I missed ones whose prerequisites aren't met on my system.
Using {} is reasonable in general; that's how the fixes in 9ddc5ac (t:
wrap complicated expect_code users in a block, 2015-03-20) worked.
However, I think your case is somewhat simpler, in that you really just
want a big conditional to set a prereq based on whether or not a command
succeeds.
Would it make sense to convert this whole thing to just:
test_lazy_prereq P4D_HAVE_CONFIGURABLE_RUN_MOVE_ALLOW '
p4 configure show run.move.allow out
egrep ^run.move.allow: 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: Regular Rebase Failure
[+mailing list, so others can also chime in and have an answer/opinion] On Mon, Apr 27, 2015 at 10:07 AM, Adam Steel adamgst...@gmail.com wrote: Stefan, So I switched git versions. $ git --version git version 2.3.1 I'm still getting the same regular rebase failures. --- fatal: Unable to create '/Users/asteel/Repositories/rails-teespring/.git/index.lock': File exists. If no other git process is currently running, this probably means a git process crashed in this repository earlier. Make sure no other git process is running and remove the file manually to continue. --- Any ideas? Adam On Tue, Apr 21, 2015 at 12:34 PM, Stefan Beller sbel...@google.com wrote: [+mailing list] On Tue, Apr 21, 2015 at 11:20 AM, Adam adamgst...@gmail.com wrote: I'm using git version 2.3.2 (Apple Git-55). We should loop in the maintainers of the Apple Git version, they'd know what changed in git about two weeks ago. I have no idea who that is though. That explains why I can't find the index.lock file, since the error that was thrown deleted it. I'm still not sure what to do about this, though. Complain at the right people so it gets fixed. ;) Thanks for responding. Adam -- 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] git-p4: prevent --chain-lint failure
t9814 has a test that simply sets up a pre-requisite for
another test, and as such, always succeeds. The way it was
written doesn't quite work with the test lint checks introduced
with the --chain-lint option.
Add an additional layer of {} to prevent the --chain-lint
code getting confused.
Signed-off-by: Luke Diamand l...@diamand.org
---
t/t9814-git-p4-rename.sh | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/t/t9814-git-p4-rename.sh b/t/t9814-git-p4-rename.sh
index 99bb71b..14f9dc3 100755
--- a/t/t9814-git-p4-rename.sh
+++ b/t/t9814-git-p4-rename.sh
@@ -227,13 +227,15 @@ test_expect_success 'detect copies' '
# See if configurables can be set, and in particular if the run.move.allow
# variable exists, which allows admins to disable the p4 move command.
test_expect_success 'p4 configure command and run.move.allow are available' '
- p4 configure show run.move.allow out ; retval=$?
- test $retval = 0
- {
- egrep ^run.move.allow: out
- test_set_prereq P4D_HAVE_CONFIGURABLE_RUN_MOVE_ALLOW ||
- true
- } || true
+{
+ p4 configure show run.move.allow out ; retval=$?
+ test $retval = 0
+ {
+ egrep ^run.move.allow: out
+ test_set_prereq P4D_HAVE_CONFIGURABLE_RUN_MOVE_ALLOW ||
+ true
+ } || true
+}
'
# If move can be disabled, turn it off and test p4 move handling
--
2.3.4.48.g223ab37
--
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] Fixup test-lint error in git-p4 t9814 test
While running the git-p4 tests, I noticed that t9814 has started failing due to the (very ingenious!) chain-lint detection introduced in: bb79af9 t/test-lib: introduce --chain-lint option I think that what's going on is that the chain-lint test is getting itself confused by this test, which is designed to always succeed, regardless of whether the individual sub-commands succeed or not, since it's just setting up a pre-requisite for later use. I've added an additional set of braces, which makes it clearer to the --chain-lint code what's going on, but I'd be interested to know if this is the right way to fix this. Thanks, Luke Luke Diamand (1): git-p4: prevent --chain-lint failure t/t9814-git-p4-rename.sh | 16 +--- 1 file changed, 9 insertions(+), 7 deletions(-) -- 2.3.4.48.g223ab37 -- 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/RFC] blame: CRLF in the working tree and LF in the repo
On Mon, Apr 27, 2015 at 10:47:29AM -0700, Junio C Hamano wrote: The original says this: blame: correctly handle files regardless of autocrlf If a file contained CRLF line endings in a repository with core.autocrlf=input, then blame always marked lines as Not Committed Yet, even if they were unmodified. Don't attempt to convert the line endings when creating the fake commit so that blame works correctly regardless of the autocrlf setting. Reported-by: Ephrim Khong dr.kh...@gmail.com Signed-off-by: brian m. carlson sand...@crustytoothpaste.net Signed-off-by: Junio C Hamano gits...@pobox.com But if autocrlf=input, then the end-user expectation is to keep the in-repository data with LF line endings. If your tip-of-the-tree commit incorrectly has CRLF line endings, and if you were going to commit what is in the working tree on top, you would be correcting that mistake by turning the in-repository data into a text file with LF line endings, so Not Committed Yet _is_ the correct behaviour. So I think that the reverting that change is the right thing to do. It really was a change to break the behaviour to match a mistaken expectation, I would have to say. I don't have a strong opinion on whether or not this should be reverted, since I don't use Windows and therefore don't use CRLF or the respective options anywhere, nor am I very familiar with how they are supposed to function. Junio has articulated a good rationale for why it's broken, and I'm willing to go along with that. I will say that perhaps it's worthwhile to write some documentation to explain how the CRLF translation works, as it seems that there's a lot of misunderstanding about it. I am, for the aforementioned reasons, not a good choice to write it. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
curl
Hi, Is it right that git uses libcurl to download while libgit2 does without it? -- Thiago Farina -- 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 3/3] connect: improve check for plink to reduce false positives
On Sun, Apr 26, 2015 at 08:30:12PM +, brian m. carlson wrote: The git_connect function has code to handle plink and tortoiseplink specially, as they require different command line arguments from OpenSSH (-P instead of -p for ports; tortoiseplink additionally requires -batch). However, the match was done by checking for plink anywhere in the string, which led to a GIT_SSH value containing uplink being treated as an invocation of putty's plink. Improve the check by looking for plink or tortoiseplink (or those names suffixed with .exe) only in the final component of the path. This has the downside that a program such as plink-0.63 would no longer be recognized, but the increased robustness is likely worth it. Add tests to cover these cases to avoid regressions. Thanks, I think this version looks good. It's possible that it's too tight, but I think it represents our best guess at what is reasonable, and we can only know more by getting it into the hands of users (hopefully while it is cooking during this release cycle, but I am not incredibly optimistic about such things). -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 v3 0/3] Improve robustness of putty detection
On Sun, Apr 26, 2015 at 03:04:56PM -0700, Junio C Hamano wrote:
The test scripts are expected to take either 3 or 4 parameters, and
the extra parameter when it takes 4 is the comma separated list of
prerequisites. bracketed hostnames are still ssh does not look
like prerequisites at all to us humans, and the framework should
also be able to notice that and barf, I would think.
Perhaps something like this?
I like it. I wondered if we could even recognize a known set of prereqs
(e.g., say I don't know about the FOO prereq; did you forget to
test_lazy_prereq it?), but I don't think we can. Some of the prereqs
are set by arbitrary code, and when they are not set, we don't call a
test_do_not_set_prereq FOO. Enforcing a sane syntax is almost as
good, and seems pretty easy to implement.
+test_verify_prereq () {
+ test -z $test_prereq ||
+ expr /dev/null $test_prereq : '^[A-Z0-9_,!]*$' ||
+ error bug in the test script: '$test_prereq' does not look like a
prereq
+}
The leading ^ is unnecessary in an expr regexp, as such expressions
are always left-anchored. And according to POSIX, even undesirable
due to hysterical raisins. You do still need the '$' to anchor the end.
I was surprised that the regexp does not match the empty string itself
(making the initial test -z redundant), but it does not seem to with
my version of expr. Weird. I think it is because the exit value is not
did it match but is the return value of the expression non-zero, and
of course we matched zero characters.
At any rate, we are probably much better off having the initial test
-z there as an optimization, anyway. expr is not usually a built-in,
and otherwise we add an extra fork to each test invocation (not
something I expect matters under Linux, but I know Windows folks are
very sensitive to it).
-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: curl
On Mon, Apr 27, 2015 at 11:49:51PM -0300, Thiago Farina wrote: Is it right that git uses libcurl to download while libgit2 does without it? I'm not sure if you mean right as in this statement is true or as in is this a good thing that it is the case. For the former, yes, libgit2 does not use curl. On Windows, it can use the native http calls (which do nice things like using the system proxy and auth systems). On Unix, I think it is a combination of hand-rolled code, openssl, and an imported http parser (from nginx). Whether that is a good idea or not, I can't comment too much. From what I have seen discussed in libgit2 issues, the stock http transport is meant to be bare-bones (but with minimal dependencies). But it could co-exist with a curl transport (just as it does with the WinHTTP transport). Maybe Carlos (cc'd) can say more. -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 5/5] ref_transaction_commit(): only keep one lockfile open at a time
On Sat, Apr 25, 2015 at 12:21:07PM -0700, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
I am not too worried about push --atomic, as we can just add a few
words to Release Notes and documentation saying this is still an
experimental broken code that is unusable; don't use the feature in
production.
I however am more worried about the other one update-ref --stdin;
the change will be pure regression for those who want to do many
updates and do not care if the update is atomic, no?
I should have refrained from touching the keyboard so late at night
X-. This regression was done long time ago (even in v2.1.0 I see
that ref_transaction_commit() tries to grab all locks at once).
So it is only push --atomic.
The choice is between (1) shipping push --atomic that is known to
be broken, (2) applying your five-patch series which may (a) fix
both push --atomic and update-ref --stdin, or (b) break other
transaction users including update-ref -stdin in unexpected ways.
I'm not sure --atomic is foolproof even with these patches.
Certainly there is the obvious problem that the filesystem is not atomic
(so a power loss halfway through committing the locks will result in a
non-atomic push). But there are also subtle locking issues related to
D/F conflicts.
For instance, if we do (and I take no credit for this discovery; Michael
showed it to me last week):
{
echo create refs/heads/branch $sha1
echo create refs/heads/foo/bar $sha1
echo create refs/heads/foo $sha1
} | git update-ref --stdin
we do not notice the conflict between foo and foo/bar until the
commit stage. Fortunately our ref-ordering rules mean we will always try
to write foo before foo/bar, which will fail because foo must be a
directory (because we have foo/bar.lock). But because branch comes
alphabetically first, we will have written that ref already, committing
part of the request.
You can work around this with code to check for D/F conflicts in a
single transaction, but then you are subject to races with other
processes. E.g., one process writes branch and foo, the other is
simultaneously writing foo/bar. There is no lock contention, but the
write of foo may fail at the commit stage.
So I think it is OK to restrict the definition of atomic here to the
common case of making sure that we can lock and check the $old_sha1 for
each of the refs. Under that definition, push --atomic is not broken
as-is, but there is room for improving its robustness. And I have no
problem with trying to make our storage format as robust as possible in
these cases, but I think we need to admit that the filesystem ref
storage is never going to be 100% transactional.
I know that sounds a bit like moving the goalposts to say eh, this
feature is not broken, your definition of broken is just wrong. But my
point is that shipping push --atomic as-is is still a useful step
forward, and we can continue to iterate and improve on the concept in
future releases.
-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 v3 0/3] Improve robustness of putty detection
On 04/27/2015 12:04 AM, Junio C Hamano wrote:
brian m. carlson sand...@crustytoothpaste.net writes:
While I was adding tests, I noticed that we had a broken test due to the
use of single quotes within a test, which resulted in the test always
being skipped.
Good eyes. While fixing the test is necessary, we should also be
able to improve the test framework to prevent such mistakes at the
same time.
ok 38 # skip
git clone [myhost:123]:src ssh-bracket-clone
expect_ssh myhost -p (missing bracketed hostnames are still
ssh)
The test scripts are expected to take either 3 or 4 parameters, and
the extra parameter when it takes 4 is the comma separated list of
prerequisites. bracketed hostnames are still ssh does not look
like prerequisites at all to us humans, and the framework should
also be able to notice that and barf, I would think.
Perhaps something like this?
t/test-lib-functions.sh | 9 +
1 file changed, 9 insertions(+)
diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
index 0698ce7..0e4f2a6 100644
--- a/t/test-lib-functions.sh
+++ b/t/test-lib-functions.sh
@@ -348,11 +348,18 @@ test_declared_prereq () {
return 1
}
+test_verify_prereq () {
+ test -z $test_prereq ||
+ expr /dev/null $test_prereq : '^[A-Z0-9_,!]*$' ||
+ error bug in the test script: '$test_prereq' does not look like a
prereq
+}
+
test_expect_failure () {
test_start_
test $# = 3 { test_prereq=$1; shift; } || test_prereq=
test $# = 2 ||
error bug in the test script: not 2 or 3 parameters to
test-expect-failure
+ test_verify_prereq
export test_prereq
if ! test_skip $@
then
@@ -372,6 +379,7 @@ test_expect_success () {
test $# = 3 { test_prereq=$1; shift; } || test_prereq=
test $# = 2 ||
error bug in the test script: not 2 or 3 parameters to
test-expect-success
+ test_verify_prereq
export test_prereq
if ! test_skip $@
then
@@ -400,6 +408,7 @@ test_external () {
error 5 bug in the test script: not 3 or 4 parameters to
test_external
descr=$1
shift
+ test_verify_prereq
export test_prereq
if ! test_skip $descr $@
then
Thanks for fixing my bugs :-)
--
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: Can't override username of default credential context to have different username in custom context.
Hi, Here is my scenario: 1. First I set default username git config --global credential.username myUsername 2. Then I want to have different username for my other repository git config --global credential.https://myOtherRepository.visualstudio.com.username myOtherUsername 3. When I try to pull new changes, git asks for password of myUsername Password for 'https://myusern...@myotherrepository.visualstudio.com': But I want to have: Password for 'https://myotherusern...@myotherrepository.visualstudio.com': Is there any way to accomplish overriding? PS: I've found that if I change steps 1 and 2 I will get what I want. But this is not a solution as it require to unset and set credential.username after I add a new credential context. So the ordering does matter and it looks for me like it shouldn't. -- Best regards, Vlad. -- 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] Clarify documentation on commit message strip
Fredrik Gustafsson iv...@iveqy.com writes: I agree that it is very clear once you do edit the commit message. My main point with this patch was to clarify -v, since it's not obvious from the documentation that it will be removed. While I agree with you that the documentation should make it clear that the patch will not be part of the commit, I think the root cause of the current unclear-ness is because the documentation does not make it clear *WHY* the -v option gives the patch text there. Doing something like this on top of your patch may clarify the reason what -v is used for, and I suspect that it may even make it unnecessary to explicitly say that the patch text will not be part of the log message (but I didn't remove that with this how about this follow-up). Documentation/git-commit.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt index 1db4c7f..617dea0 100644 --- a/Documentation/git-commit.txt +++ b/Documentation/git-commit.txt @@ -282,7 +282,9 @@ configuration variable documented in linkgit:git-config[1]. --verbose:: Show unified diff between the HEAD commit and what would be committed at the bottom of the commit message - template. Note that this diff output doesn't have its + template to help the user describe the commit by reminding + what changes the commit has. + Note that this diff output doesn't have its lines prefixed with '#'. This diff will not be a part of the commit message. + -- 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/RFC] blame: CRLF in the working tree and LF in the repo
Junio C Hamano gits...@pobox.com writes: I suspect (I haven't looked very carefully for this round yet to be sure, though) that it may turn out that the commit you are proposing to revert was a misguided attempt to fix a non issue, or to break the behaviour to match a mistaken expectation. If that is the case then definitely the reversion is a good idea, and you should argue along that line of justification. We'd just be fixing an old misguided and bad change in such a case. The original says this: blame: correctly handle files regardless of autocrlf If a file contained CRLF line endings in a repository with core.autocrlf=input, then blame always marked lines as Not Committed Yet, even if they were unmodified. Don't attempt to convert the line endings when creating the fake commit so that blame works correctly regardless of the autocrlf setting. Reported-by: Ephrim Khong dr.kh...@gmail.com Signed-off-by: brian m. carlson sand...@crustytoothpaste.net Signed-off-by: Junio C Hamano gits...@pobox.com But if autocrlf=input, then the end-user expectation is to keep the in-repository data with LF line endings. If your tip-of-the-tree commit incorrectly has CRLF line endings, and if you were going to commit what is in the working tree on top, you would be correcting that mistake by turning the in-repository data into a text file with LF line endings, so Not Committed Yet _is_ the correct behaviour. So I think that the reverting that change is the right thing to do. It really was a change to break the behaviour to match a mistaken expectation, I would have to say. -- 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] Update git-multimail to version 1.0.2
Michael Haggerty mhag...@alum.mit.edu writes: The only changes are to the README files, most notably the list of maintainers and the project URL. Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- contrib/hooks/multimail/README | 43 +++--- contrib/hooks/multimail/README.Git | 6 +++--- 2 files changed, 25 insertions(+), 24 deletions(-) ... (mental note) OK, only the doc updates; that should be safe even to apply during -rc freeze period if I wanted to... diff --git a/contrib/hooks/multimail/README b/contrib/hooks/multimail/README index 477d65f..6efa4ff 100644 --- a/contrib/hooks/multimail/README +++ b/contrib/hooks/multimail/README @@ -456,34 +456,35 @@ consider sharing them with the community! Getting involved -git-multimail is an open-source project, built by volunteers. We -would welcome your help! +git-multimail is an open-source project, built by volunteers. We would +welcome your help! Yuck. +Whenever enough changes to git-multimail have accumulated, a new +code-drop of git-multimail will be submitted for inclusion in the Git +project. OK. diff --git a/contrib/hooks/multimail/README.Git b/contrib/hooks/multimail/README.Git index 129b771..ab3ece5 100644 --- a/contrib/hooks/multimail/README.Git +++ b/contrib/hooks/multimail/README.Git @@ -3,13 +3,13 @@ section of the Git project as a convenience to Git users. git-multimail is developed as an independent project at the following website: -https://github.com/mhagger/git-multimail +https://github.com/git-multimail/git-multimail The version in this directory was obtained from the upstream project -on 2014-04-07 and consists of the git-multimail subdirectory from +on 2015-04-27 and consists of the git-multimail subdirectory from revision -1b32653bafc4f902535b9fc1cd9cae911325b870 +8c3aaafa873bf10de8dddf1d202c449b3eff3b42 refs/tags/1.0.2 Huh, really? -- 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 v2] git-compat-util.h: implement a different ARRAY_SIZE macro for for safely deriving the size of array
Elia Pinto gitter.spi...@gmail.com writes: This is the second version of this patch. It had not been discussed before. In the second version, I just tried to clarify the comment in the commit. I resend it just in case you missed I do not recall seeing it before. No discussion usually means no interest, so I'll see what happens this time on the list for a few days before picking it up. +#if SUPPORT__BUILTIN_TYPES_COMPATIBLE_P +/* arr[0] degrades to a pointer: a different type from an array */ +#define _array_size_chk(arr) \ + BUILD_ASSERT_OR_ZERO(!__builtin_types_compatible_p(typeof(arr), \ + typeof((arr)[0]))) +#else +#define _array_size_chk(arr) 0 +#endif Wouldn't there be a more sensible name? _chk does not tell us anything about what is being checked, and the only thing this name gives us is what uses it (i.e. it is some magic used by array-size and does not say what it checks and what for). I think you are checking arr is an array and not a pointer. Perhaps #define is_an_array(arr) or something along that line may be a more descriptive name for it. I doubt the leading underscore is particularly a good idea, though. +/* + * ARRAY_SIZE - get the number of elements in a visible array + * at x: the array whose size you want. + * + * This does not work on pointers, or arrays declared as [], or + * function parameters. With correct compiler support, such usage + * will cause a build error (see build_assert). + */ +#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]) + _array_size_chk(x)) #define bitsizeof(x) (CHAR_BIT * sizeof(x)) #define maximum_signed_value_of_type(a) \ -- 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 v8 2/4] cat-file: teach cat-file a '--literally' option
On Mon, Apr 27, 2015 at 7:57 AM, karthik nayak karthik@gmail.com wrote: On 04/25/2015 10:34 PM, Junio C Hamano wrote: karthik nayak karthik@gmail.com writes: Yes this gives the best description, but its large, while we could use something like --no-strict instead. We could, if you answered my first question with no. By naming this --no-strict, the first bug report you will receive may be that cat-file --no-strict should parse a zlib deflate that begins with blob 1234\n\0 (notice that there are two SPs instead of the usual one, and length is followed by LF that should not be there before the NUL) but it does not. As your option name --no-strict signals that you will make the best effort to parse such nonsense, that would be a valid bug report, against which you would need to update the code to make it work. But is it worth the effort to make such a thing work? I dunno. Nice point, I don't see the need to parse such objects at the moment. That rules out --no-strict and everything similar. I still find --allow-unkown-type a bit too big, what about something like * --any-type * --arbitrary-type As a diagnostic aid when encountering a (hopefully rare) broken or corrupt object, this option is not likely to be used often. The allow in --allow-unknown-type conveys the intended purpose more accurately than either of the shorter names suggested above; and considering how infrequently it is likely to be used, the extra six characters should not be a significant burden. -- 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] Update git-multimail to version 1.0.2
Junio C Hamano gits...@pobox.com writes: Matthieu Moy matthieu@grenoble-inp.fr writes: Junio C Hamano gits...@pobox.com writes: --- a/contrib/hooks/multimail/README.Git +++ b/contrib/hooks/multimail/README.Git @@ -3,13 +3,13 @@ section of the Git project as a convenience to Git users. git-multimail is developed as an independent project at the following website: -https://github.com/mhagger/git-multimail +https://github.com/git-multimail/git-multimail The version in this directory was obtained from the upstream project -on 2014-04-07 and consists of the git-multimail subdirectory from +on 2015-04-27 and consists of the git-multimail subdirectory from revision -1b32653bafc4f902535b9fc1cd9cae911325b870 +8c3aaafa873bf10de8dddf1d202c449b3eff3b42 refs/tags/1.0.2 Huh, really? What's the problem with this hunk? I just checked, and the tag is there, with the right sha1. The patch is to apply to a file in my tree, so The version in this directory is contrib/hooks/multimail/git_multimail.py in my tree. Was that obtained from the upstream project (i.e. you) and match your 1.0.2 tag? Yes. Isn't that what the text above says? -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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] Update git-multimail to version 1.0.2
Matthieu Moy matthieu@grenoble-inp.fr writes: Junio C Hamano gits...@pobox.com writes: Matthieu Moy matthieu@grenoble-inp.fr writes: Junio C Hamano gits...@pobox.com writes: --- a/contrib/hooks/multimail/README.Git +++ b/contrib/hooks/multimail/README.Git @@ -3,13 +3,13 @@ section of the Git project as a convenience to Git users. git-multimail is developed as an independent project at the following website: -https://github.com/mhagger/git-multimail +https://github.com/git-multimail/git-multimail The version in this directory was obtained from the upstream project -on 2014-04-07 and consists of the git-multimail subdirectory from +on 2015-04-27 and consists of the git-multimail subdirectory from revision -1b32653bafc4f902535b9fc1cd9cae911325b870 +8c3aaafa873bf10de8dddf1d202c449b3eff3b42 refs/tags/1.0.2 Huh, really? What's the problem with this hunk? I just checked, and the tag is there, with the right sha1. The patch is to apply to a file in my tree, so The version in this directory is contrib/hooks/multimail/git_multimail.py in my tree. Was that obtained from the upstream project (i.e. you) and match your 1.0.2 tag? Yes. Isn't that what the text above says? Well, the patch does not update git_multimail.py at all. Requoting the part you omitted from my response $ git rev-list -1 master contrib/hooks/multimail/ b513f71f6043c05c3918e670b332dfa7ec6b2661 which is b513f71f (git-multimail: update to version 1.0.0, 2014-04-07) it matches what was obtained from the upstream project on 2014-04-07. Or did you forget to include the update to the software in the patch? -- 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] Update git-multimail to version 1.0.2
Junio C Hamano gits...@pobox.com writes: Matthieu Moy matthieu@grenoble-inp.fr writes: Junio C Hamano gits...@pobox.com writes: Was that obtained from the upstream project (i.e. you) and match your 1.0.2 tag? Yes. Isn't that what the text above says? Well, the patch does not update git_multimail.py at all. Requoting the part you omitted from my response $ git rev-list -1 master contrib/hooks/multimail/ b513f71f6043c05c3918e670b332dfa7ec6b2661 which is b513f71f (git-multimail: update to version 1.0.0, 2014-04-07) it matches what was obtained from the upstream project on 2014-04-07. Yes, but it also matches was obtained on 2015-04-27, since only the README has changed (the commit message of this patch says: The only changes are to the README files, most notably the list of maintainers and the project URL.). Or did you forget to include the update to the software in the patch? The update to the software is empty. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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/RFC] blame: CRLF in the working tree and LF in the repo
Am 27.04.2015 um 08:11 schrieb Stepan Kasal: Git does not support CRLF as the internal line separator. If you commit file in binary mode with CRLF, you are on your own. When I commit my C source code files with CRLF into the repository (because I do not set any line ending options or configurations or any 'text' attributes or similar), do I then commit binary files or text files? Should I expect not to see any diffs? -- Hannes -- 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] rebase: silence git checkout for noop rebase
On Mon, Apr 27, 2015 at 12:05:41PM -0700, Sam Cates wrote: STEPS TO REPRODUCE: 1. git checkout master 2. git rebase --quiet master topic EXPECTED RESULTS: The checkout and rebase occur with no output. ACTUAL RESULTS: The output from the checkout is not suppressed. Can you be more specific about your setup? What is the relationship between master and topic? If topic is already up to date with master, I get: $ git rebase --quiet master topic Switched to branch 'topic' (the --quiet does suppress Current branch topic is up to date). The patch below addresses that. But there may be other calls to git-checkout that would need similar treatment (either unconditional -q as below, or respecting $GIT_QUIET, depending on the individual case). -- 8 -- Subject: rebase: silence git checkout for noop rebase When the branch to be rebased is already up to date, we git checkout the branch, print an up to date message, and end the rebase early. However, our checkout may print Switched to branch 'foo' or Already on 'foo', even if the user has asked for --quiet. We should avoid printing these messages at all, --quiet or no. Since the rebase is a noop, this checkout can be seen as optimizing out these other two checkout operations (that happen in a real rebase): 1. Moving to the detached HEAD to start the rebase; we always feed -q to checkout there, and instead rely on our own custom message (which respects --quiet). 2. Finishing a rebase, where we move to the final branch. Here we actually use update-ref rather than git-checkout, and produce no messages. Signed-off-by: Jeff King p...@peff.net --- git-rebase.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/git-rebase.sh b/git-rebase.sh index 55da9db..90854e3 100755 --- a/git-rebase.sh +++ b/git-rebase.sh @@ -582,7 +582,7 @@ then # Lazily switch to the target branch if needed... test -z $switch_to || GIT_REFLOG_ACTION=$GIT_REFLOG_ACTION: checkout $switch_to \ - git checkout $switch_to -- + git checkout -q $switch_to -- say $(eval_gettext Current branch \$branch_name is up to date.) finish_rebase exit 0 -- 2.4.0.rc3.477.gc25258d -- 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: Question about how git determines the minimum packfile for a push.
On Mon, Apr 27, 2015 at 12:41:28AM +, Brad Litterell wrote: Is it possible git is not computing the delta correctly? Or does git only look at the top-level commit objects to figure out what to include in the push packfile? It's the latter. Junio mentioned that push is not as thorough about finding common ancestors as fetch, but I think even fetch would have the same problem. If we know that the other side has commit X, we know that it also has X~3, and we also know that it has every tree and blob mentioned by X~3. But it's much too expensive to open up every tree to generate the full set of reachable objects; for the Linux kernel, that is something like 45 seconds of CPU time, just to find out oh, we only need to send 5 objects. This works pretty well in practice, because trees and blobs from older history don't tend to resurface verbatim. But as you noticed, there are certain cases where it does happen, and the number of objects affected can be quite large (to the point that sending the extra objects is much more expensive than the cost of doing the extra tree traversal). Unfortunately there is no look harder option you can give to git push when you, as the user, realize this is happening. If you have pack reachability bitmaps, they do produce a more thorough answer. So probably: git repack -adb git push on the client would make this work as you expect. Will it upload the larger pack only to have the server correctly handle the duplicates? Yes, the receiving side should correctly handle the duplicates. -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: Fwd: Can't override username of default credential context to have different username in custom context.
On Mon, Apr 27, 2015 at 09:19:31PM +0500, Vladislav Kostenko wrote: Here is my scenario: 1. First I set default username git config --global credential.username myUsername 2. Then I want to have different username for my other repository git config --global credential.https://myOtherRepository.visualstudio.com.username myOtherUsername 3. When I try to pull new changes, git asks for password of myUsername Password for 'https://myusern...@myotherrepository.visualstudio.com': But I want to have: Password for 'https://myotherusern...@myotherrepository.visualstudio.com': Is there any way to accomplish overriding? Only by changing the ordering in the config file, as you noticed. The other http.* options will choose the most-specific match, but the credential code predates that, and blindly goes in config order. Kyle (cc'd) added the urlmatch support for http.*, and might be able to say whether it could be adapted for the credential code. If so, then I think it would need somebody to volunteer to work on it. That would technically be a backwards-incompatible change to switch the lookup order at this point in time, but I'm somewhat of the opinion that in any case it matters, the new behavior would be a strict improvement. -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: Fwd: Can't override username of default credential context to have different username in custom context.
[+cc Kyle, who I forgot on the initial send. Oops!] On Tue, Apr 28, 2015 at 01:25:02AM -0400, Jeff King wrote: On Mon, Apr 27, 2015 at 09:19:31PM +0500, Vladislav Kostenko wrote: Here is my scenario: 1. First I set default username git config --global credential.username myUsername 2. Then I want to have different username for my other repository git config --global credential.https://myOtherRepository.visualstudio.com.username myOtherUsername 3. When I try to pull new changes, git asks for password of myUsername Password for 'https://myusern...@myotherrepository.visualstudio.com': But I want to have: Password for 'https://myotherusern...@myotherrepository.visualstudio.com': Is there any way to accomplish overriding? Only by changing the ordering in the config file, as you noticed. The other http.* options will choose the most-specific match, but the credential code predates that, and blindly goes in config order. Kyle (cc'd) added the urlmatch support for http.*, and might be able to say whether it could be adapted for the credential code. If so, then I think it would need somebody to volunteer to work on it. That would technically be a backwards-incompatible change to switch the lookup order at this point in time, but I'm somewhat of the opinion that in any case it matters, the new behavior would be a strict improvement. -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 -- 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 v2] git-compat-util.h: implement a different ARRAY_SIZE macro for for safely deriving the size of array
On Mon, Apr 27, 2015 at 10:56:30AM -0700, Junio C Hamano wrote: Elia Pinto gitter.spi...@gmail.com writes: This is the second version of this patch. It had not been discussed before. In the second version, I just tried to clarify the comment in the commit. I resend it just in case you missed I do not recall seeing it before. No discussion usually means no interest, so I'll see what happens this time on the list for a few days before picking it up. I'm in favor of any method for improving compile-time bug-checking, provided that: 1. It does not carry a maintenance cost that spreads throughout the code base (e.g., here the cost is localized to making ARRAY_SIZE a bit more complex, but callers do not have to care about the extra checking). 2. It gracefully degrades when using older compilers (i.e., we can fall back to the existing ARRAY_SIZE definition when the magic builtin is not available). I think this is OK for both points. It would be nice if we could auto-detect the presence of the builtin without using autoconf. I think most git developers do not use autoconf at all, and the feature does not help much if nobody turns it on. Is there a __GNUC__ or similar feature-test macro we could use for this? +#define _array_size_chk(arr) 0 +#endif Wouldn't there be a more sensible name? _chk does not tell us anything about what is being checked, and the only thing this name gives us is what uses it (i.e. it is some magic used by array-size and does not say what it checks and what for). I think you are checking arr is an array and not a pointer. Perhaps #define is_an_array(arr) or something along that line may be a more descriptive name for it. I doubt the leading underscore is particularly a good idea, though. Agreed on the naming (modulo the not from your follow-on email). Also, should it be in ALL_CAPS like the other added macros? We are slightly inconsistent about that in our code-base. -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] blame: add blame.showemail config option
Quentin Neill quentin.ne...@gmail.com writes:
It's not clear why you relocated documentation of --show-email from
git-blame.txt to blame-options.txt, and the commit message does not
explain the move. If there's a good reason for the relocation, the
justification should be spelled out so that people reviewing the patch
or looking through history later on will not have to guess about it.
I moved it to be with the other variables that had configuration
options, but I will move it back.
Please do not do anything before you understand why there are two
places, and if you don't understand, ask.
If you do this:
$ git grep blame-options Documentation/
you would discover that blame-options.txt is meant to hold things
that are shared across git annotate and git blame. What is
understood only by git blame but not by git annotate is to be
described in git-blame.txt, I think. So the criteria is not does
it have configuration?; it is does git-annotate understand it?
@@ -1926,7 +1927,7 @@ static void emit_other(struct scoreboard *sb, struct
blame_entry *ent, int opt)
printf(%.*s, length, hex);
if (opt OUTPUT_ANNOTATE_COMPAT) {
const char *name;
- if (opt OUTPUT_SHOW_EMAIL)
+ if ((opt OUTPUT_SHOW_EMAIL) || show_email)
The desired behavior is for a configuration setting to provide a
fallback, and for a command-line option to override the fallback. So,
for instance, if blame.showemail is true, then --no-show-email
should countermand that. Unfortunately, the way this patch is
implemented, it's impossible to override the setting from the
command-line since show_email==true will always win (when
blame.showemail is true).
More below.
I followed the code for blame.showRoot and blame.blankboundary.
I do not think that is quite true.
The code strucure for other existing options is perfectly fine.
What they do is:
- show_root is initialized to the fallback default value of
false by being in BSS;
- configuration is read to tweak that default;
- command line parser may override the default with --show-root
or --no-show-root.
And then show_root is used throughout the system.
If you truly followed this code pattern, I would expect that there
will not be a separate show_email variable introduced to support
this new configuration variable. The OUTPUT_SHOW_EMAIL bit in the
opt flag word corresponds to show_root and blank_boundary variables,
so the code to read configuration variable would set that bit in the
opt flag word before the command line parser would kick in. And the
code that checks opt OUTPUT_SHOW_EMAIL currently does not have
to change at all.
--
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] Update git-multimail to version 1.0.2
Junio C Hamano gits...@pobox.com writes: --- a/contrib/hooks/multimail/README.Git +++ b/contrib/hooks/multimail/README.Git @@ -3,13 +3,13 @@ section of the Git project as a convenience to Git users. git-multimail is developed as an independent project at the following website: -https://github.com/mhagger/git-multimail +https://github.com/git-multimail/git-multimail The version in this directory was obtained from the upstream project -on 2014-04-07 and consists of the git-multimail subdirectory from +on 2015-04-27 and consists of the git-multimail subdirectory from revision -1b32653bafc4f902535b9fc1cd9cae911325b870 +8c3aaafa873bf10de8dddf1d202c449b3eff3b42 refs/tags/1.0.2 Huh, really? What's the problem with this hunk? I just checked, and the tag is there, with the right sha1. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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] Update git-multimail to version 1.0.2
Matthieu Moy matthieu@grenoble-inp.fr writes: Junio C Hamano gits...@pobox.com writes: --- a/contrib/hooks/multimail/README.Git +++ b/contrib/hooks/multimail/README.Git @@ -3,13 +3,13 @@ section of the Git project as a convenience to Git users. git-multimail is developed as an independent project at the following website: -https://github.com/mhagger/git-multimail +https://github.com/git-multimail/git-multimail The version in this directory was obtained from the upstream project -on 2014-04-07 and consists of the git-multimail subdirectory from +on 2015-04-27 and consists of the git-multimail subdirectory from revision -1b32653bafc4f902535b9fc1cd9cae911325b870 +8c3aaafa873bf10de8dddf1d202c449b3eff3b42 refs/tags/1.0.2 Huh, really? What's the problem with this hunk? I just checked, and the tag is there, with the right sha1. The patch is to apply to a file in my tree, so The version in this directory is contrib/hooks/multimail/git_multimail.py in my tree. Was that obtained from the upstream project (i.e. you) and match your 1.0.2 tag? $ git rev-list -1 master contrib/hooks/multimail/ b513f71f6043c05c3918e670b332dfa7ec6b2661 which is b513f71f (git-multimail: update to version 1.0.0, 2014-04-07) -- 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 v2] git-compat-util.h: implement a different ARRAY_SIZE macro for for safely deriving the size of array
Junio C Hamano gits...@pobox.com writes: +#if SUPPORT__BUILTIN_TYPES_COMPATIBLE_P +/* arr[0] degrades to a pointer: a different type from an array */ +#define _array_size_chk(arr) \ +BUILD_ASSERT_OR_ZERO(!__builtin_types_compatible_p(typeof(arr), \ +typeof((arr)[0]))) +#else +#define _array_size_chk(arr) 0 +#endif Wouldn't there be a more sensible name? _chk does not tell us anything about what is being checked, and the only thing this name gives us is what uses it (i.e. it is some magic used by array-size and does not say what it checks and what for). I think you are checking arr is an array and not a pointer. Perhaps #define is_an_array(arr) or something along that line may be a more descriptive name for it. I doubt the leading underscore is particularly a good idea, though. And is_an_array(arr) is probably not quite a good name, as that sounds as if it would give 1 and adding it to sizeof(x)/sizeof(x[0]) does not make sense. barf_if_not_an_array() is what the macro does. -- 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] Clarify documentation on commit message strip
On Mon, Apr 27, 2015 at 10:31:28AM -0700, Junio C Hamano wrote: Fredrik Gustafsson iv...@iveqy.com writes: I agree that it is very clear once you do edit the commit message. My main point with this patch was to clarify -v, since it's not obvious from the documentation that it will be removed. While I agree with you that the documentation should make it clear that the patch will not be part of the commit, I think the root cause of the current unclear-ness is because the documentation does not make it clear *WHY* the -v option gives the patch text there. I agree. Doing something like this on top of your patch may clarify the reason what -v is used for, and I suspect that it may even make it unnecessary to explicitly say that the patch text will not be part of the log message (but I didn't remove that with this how about this follow-up). Even better. I would be glad if this could make it into a release. Thanks for the feedback, to make this a good patch. -- Fredrik Gustafsson phone: +46 733-608274 e-mail: iv...@iveqy.com website: http://www.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
Re: Bug report : bad filter-branch (OSX only)
On Sun, Apr 26, 2015 at 11:25:52AM +0200, Olivier ROLAND wrote: OSX 10.10.3 git 2.3.6 HFS+ case-sensitive How to reproduce : Step 1 : git clone https://github.com/begeric/FastParsers.git Step 2 : cd FastParsers/ Step 3 : git filter-branch --env-filter 'if [ 0 = 1 ]; then echo 0; fi' -- --all Result on OSX : Rewrite 65df7c5ac1ed956252b07b8c911ad7eba0a15c2b (206/206) Ref 'refs/heads/experiment' was rewritten Ref 'refs/remotes/origin/experiment' was rewritten WARNING: Ref 'refs/remotes/origin/experiment' is unchanged Ref 'refs/remotes/origin/master' was rewritten Result on Debian : Rewrite 65df7c5ac1ed956252b07b8c911ad7eba0a15c2b (206/206) WARNING: Ref 'refs/heads/experiment' is unchanged WARNING: Ref 'refs/remotes/origin/experiment' is unchanged WARNING: Ref 'refs/remotes/origin/experiment' is unchanged WARNING: Ref 'refs/remotes/origin/master' is unchanged Do you have any thoughts on this ? Weird. Did you build both versions of git from source (that is, there's no question that the OS X one is a hacked-up Apple git or something)? Presumably it's some incompatibility in the shells used. What does: head -1 $(git --exec-path)/git-filter-branch say about the shell in use on each system? Does running that shell with --version report anything useful? -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] Update git-multimail to version 1.0.2
Matthieu Moy matthieu@grenoble-inp.fr writes: Junio C Hamano gits...@pobox.com writes: Matthieu Moy matthieu@grenoble-inp.fr writes: Junio C Hamano gits...@pobox.com writes: Was that obtained from the upstream project (i.e. you) and match your 1.0.2 tag? Yes. Isn't that what the text above says? Well, the patch does not update git_multimail.py at all. Requoting the part you omitted from my response $ git rev-list -1 master contrib/hooks/multimail/ b513f71f6043c05c3918e670b332dfa7ec6b2661 which is b513f71f (git-multimail: update to version 1.0.0, 2014-04-07) it matches what was obtained from the upstream project on 2014-04-07. Yes, but it also matches was obtained on 2015-04-27, since only the README has changed (the commit message of this patch says: The only changes are to the README files, most notably the list of maintainers and the project URL.). Or did you forget to include the update to the software in the patch? The update to the software is empty. Hmm, that may be technically correct but it is grossly misleading to update the existing was obtained on 2014-04-07 to was obtained on 2015-04-27, especially if nothing was actually obtained, isn't it? I honestly am surprised that, after seeing the announcement about a new repository, co-maintainer and multiple contributors, no code change is made over the past 12 months. I would understand it if the description were The version in this directory matches the upstream project as of 2015-04-27, though. -- 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-rebase doesn't forward --quiet to git-checkout
STEPS TO REPRODUCE: 1. git checkout master 2. git rebase --quiet master topic EXPECTED RESULTS: The checkout and rebase occur with no output. ACTUAL RESULTS: The output from the checkout is not suppressed. Thanks, Sam -- 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] Update git-multimail to version 1.0.2
Junio C Hamano gits...@pobox.com writes: Hmm, that may be technically correct but it is grossly misleading to update the existing was obtained on 2014-04-07 to was obtained on 2015-04-27, especially if nothing was actually obtained, isn't it? That is because you're looking at the patch. The intended audience are people reading the README.Git file, and the text reads just fine then. I honestly am surprised that, after seeing the announcement about a new repository, co-maintainer and multiple contributors, no code change is made over the past 12 months. That is the point indeed. Michael does not use git-multimail himself, and does not find time to work on it. I'm joining the effort, but currently have no time either. But eventually I'll go through the list of pending pull-requests, and we'll actually get new code. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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] blame: add blame.showemail config option
On Mon, Apr 27, 2015 at 2:10 PM, Junio C Hamano gits...@pobox.com wrote:
Quentin Neill quentin.ne...@gmail.com writes:
Eric Sunshine sunsh...@sunshineco.com writes:
Quentin Neill quentin.ne...@gmail.com writes:
- if (opt OUTPUT_SHOW_EMAIL)
+ if ((opt OUTPUT_SHOW_EMAIL) || show_email)
The desired behavior is for a configuration setting to provide a
fallback, and for a command-line option to override the fallback. So,
for instance, if blame.showemail is true, then --no-show-email
should countermand that. Unfortunately, the way this patch is
implemented, it's impossible to override the setting from the
command-line since show_email==true will always win (when
blame.showemail is true).
I followed the code for blame.showRoot and blame.blankboundary.
If you truly followed this code pattern, I would expect that there
will not be a separate show_email variable introduced to support
this new configuration variable. The OUTPUT_SHOW_EMAIL bit in the
opt flag word corresponds to show_root and blank_boundary variables,
so the code to read configuration variable would set that bit in the
opt flag word before the command line parser would kick in. And the
code that checks opt OUTPUT_SHOW_EMAIL currently does not have
to change at all.
Right. Rather than having a separate global 'show_email' variable and
consulting that variable in parallel with OUTPUT_SHOW_EMAIL throughout
the code, instead set the OUTPUT_SHOW_EMAIL bit in git_blame_config().
To do this, take advantage of the callback data argument of
git_config(), which will arrive in git_blame_config() as its 'void
*cb' argument. So, for instance, something like this:
static int git_blame_config(var, value, void *cb)
{
...
if (!strcmp(var, blame.showemail)) {
if (git_config_bool(var, value)) {
int *output_options = cb;
*output_options |= OUTPUT_SHOW_EMAIL;
}
return 0;
}
...
}
int cmd_blame(...)
{
...
git_config(git_blame_config, output_options);
...
parse_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
