Re: [ANNOUNCE] Git v2.2.0
Steven Noonan schrieb am 27.11.2014 um 22:32: I'm sad to report that I'm getting test failures with this release. Built from git and did 'make -C t prove NO_SVN_TESTS=1' and got this result: $ make -j8 $ make -C t prove NO_SVN_TESTS=1 PROVE=prove -j8 [...] Test Summary Report --- t4202-log.sh (Wstat: 256 Tests: 42 Failed: 2) Failed tests: 41-42 Non-zero exit status: 1 t5534-push-signed.sh (Wstat: 256 Tests: 7 Failed: 2) Failed tests: 6-7 Non-zero exit status: 1 t5801-remote-helpers.sh (Wstat: 256 Tests: 28 Failed: 2) Failed tests: 21-22 Non-zero exit status: 1 t6050-replace.sh (Wstat: 256 Tests: 33 Failed: 4) Failed tests: 30-33 Non-zero exit status: 1 t6300-for-each-ref.sh(Wstat: 256 Tests: 134 Failed: 19) Failed tests: 115-133 Non-zero exit status: 1 t7510-signed-commit.sh (Wstat: 256 Tests: 10 Failed: 10) Failed tests: 1-10 Non-zero exit status: 1 t7612-merge-verify-signatures.sh (Wstat: 256 Tests: 6 Failed: 5) Failed tests: 2-6 Non-zero exit status: 1 t7600-merge.sh (Wstat: 256 Tests: 49 Failed: 2) Failed tests: 48-49 Non-zero exit status: 1 t7004-tag.sh (Wstat: 256 Tests: 136 Failed: 32) Failed tests: 65-66, 69-72, 74-75, 77-100 Non-zero exit status: 1 Files=685, Tests=11975, 88 wallclock secs ( 3.97 usr 0.70 sys + 73.84 cusr 22.10 csys = 100.61 CPU) Result: FAIL I suspect that gnupg v2.1 is to blame somehow (I've had similar bad behavior with my own projects using GPG in automation). Running through several of the git tests shows that gpg is failing to sign: $ make -C t t7510-signed-commit GIT_TEST_OPTS=--verbose --debug make: Entering directory '/home/snoonan/Development/git/t' *** t7510-signed-commit.sh *** Initialized empty Git repository in /home/snoonan/Development/git/t/trash directory.t7510-signed-commit/.git/ expecting success: [...] gpg: starting migration from earlier GnuPG versions gpg: porting secret keys from '/home/snoonan/Development/git/t/trash directory.t7510-signed-commit/gpghome/secring.gpg' to gpg-agent gpg: key CDDE430D: secret key imported gpg: key B7227189: secret key imported gpg: migration succeeded gpg: signing failed: Operation cancelled gpg: signing failed: Operation cancelled error: gpg failed to sign the data fatal: failed to write commit object gpg: signing failed: Operation cancelled gpg: signing failed: Operation cancelled error: gpg failed to sign the data fatal: failed to write commit object not ok 1 - create signed commits If I build and install the old gnupg v2.0.26 package, things are happier: $ make -C t prove NO_SVN_TESTS=1 PROVE=prove -j8 [...] All tests successful. Files=685, Tests=11975, 87 wallclock secs ( 4.02 usr 0.69 sys + 76.41 cusr 21.96 csys = 103.08 CPU) Result: PASS Using Arch Linux on x86_64. Anyone else able to repro? Are you running gnome_keyring_deamon by any chance? It think it runs by default in Gnome, claims to offer gpg_agent functionality but does not seem to do so fully. I.e., its presence may keep gpg2.1 from starting its own gpg-agent. But gpg2.1 (gnupg modern branch) needs a new gpg-agent which knows how to handle secret keys for gpg2.1. (I may take a shot at trying, but I'm on Fedora - they're slow and special in all things gpg/crypto. And compiling gpg2.1 means compiling all the bits and pieces that monster consists of these days...) Michael -- 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: [RFC] On watchman support
On Wed, Nov 19, 2014 at 1:12 AM, David Turner dtur...@twopensource.com wrote: Or will you go with cityhash now.. I ask because you have another sse optimization for hashmap on your watchman branch and that could reduce init time for name-hash. Name-hash is used often on case-insensitive fs (less often on case-sensitive fs). Cityhash would be better, because it has actual engineering effort put into it; what I did on my branch is a hack that happens to work decently. As the comment notes, I did not spend much effort on tuning my implementation. Also, Cityhash doesn't require SSE, so it's more portable. Cityhash looks less appealing to me. For one thing it's C++ so linking to C can't be done. I could add a few extern C to make it work. But if we plan to support it eventually, cityhash must support C out of the box. Then cityhash does not support case-insensitive hashing. I had to make a CityHash32i version based on CityHash32. It's probably my bugs there, but performance is worse (~120ms) than original hashmap.c (90ms). Enabling sse4.2 helps a bit, but still worse. Using the case-sensitive version in place for memihash and strihash does make cityhash win over hashmap.c, around 50ms (with or without sse4.2). But that's still not as good as your version (~35ms).. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Our cumbersome mailing list workflow
From: Matthieu Moy matthieu@grenoble-inp.fr Torsten Bögershausen tbo...@web.de writes: On 2014-11-25 01.28, Michael Haggerty wrote: [] Let me list the aspects of our mailing list workflow that I find cumbersome as a contributor and reviewer: * Submitting patches to the mailing list is an ordeal of configuring format-patch and send-email and getting everything just right, using instructions that depend on the local environment. Typically everything fits into ~/.gitconfig, which can be carried around on a USB-Stick. I personnally submit all my Git patches from a machine whose /usr/sbin/sendmail knows how to send emails, so for me configuration is super simple. But I can imagine the pain of someone working on various machines with various network configuration and normally using a webmail to send emails. Sharing ~/.gitconfig does not always work because on machine A you only can use one SMTP server, and on machine B only another ... The bit I find awkward for the send-email step is the creation of the to and cc lists. I tend to create the command line in a separate file so that I can re-use it for V2 etc. and even then I end up with all patches going to the full to/cc list. Michael's original discussion email did feel to summarise the isses [1] well. -- Philip [1] System Problems are Wicked problems : http://en.wikipedia.org/wiki/Wicked_problem www.poppendieck.com/wicked.htm -- 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 1/1] change contract between system_path and it's callers
From: Alexander Kuleshov kuleshovm...@gmail.com Sent: Wednesday, November 26, 2014 3:53 AM None of these warrant the code churn, I would say. Sorry, english is not my first language, what did you mean when saying: code churn? Code duplication or something else? -- Hi Alexander, The term 'churn' is originally from British butter making. Churn: verb 1.shake (milk or cream) in a machine in order to produce butter. the cream is ripened before it is churned synonyms: stir, agitate; 2.(with reference to liquid) move or cause to move about vigorously. the seas churned. For Code (used in a somewhat negative sense), it means that lots of bits are moved around a great deal for little apparent benefit. In the sense Junio used it, I believe it's suggesting that the balance between the amount of change and usefulness of the change had gone further than hoped. (Though Junio is usually open to receiving a well argued case) Philip see also http://en.wikipedia.org/wiki/Churn_rate -- 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: Unable to Revert Commit
Rex:
On Thu, Nov 27, 2014 at 11:35:57AM -0500, Rex Macey wrote:
Unable to Revert Commit ... Resolve the conflicts in your working
directory and commit them before trying the revert again. Please
help me understand how to resolve the conflicts. Here's what
happened (as best as I remember).
Created a windows folder github_learn (not under my
\documents\github folder) ;
Created a file file1.r.
Dragged folder into Github for Windows. Committed; I could see the
file in my directory, Github for Windows, and on the server
(github.com);
I modified the first file. Checked that there were different
versions and then committed it.;
I created a second file, file2.r Committed it. All good.;
Then I tested whether I could retrieve the first version of file1.r
(before modification). In the History area of Github for Windows, I
can see this version. I click on that, and then I click on Revert
which produces the error.
I am very new to Git and have read some of the documentation and
this exercise is my attempt to test myself. So far my grade is not
good. I appreciate any guidance including links to instructions.
GitHub and GitHub for Windows are not Git. I don't think
you will find official support for those proprietary products on
this mailing list (I may be wrong). It looks like you can request
support for those products from the contact page on the GitHub
Web site: https://github.com/contact.
My personal recommendation would be to get rid of those anyway
and learn to use the real Git. It's not very difficult, and it is
likely to do things better in the long run. As a general rule,
GUI programs are limited, clumsy, and try too hard to hide the
details of what they are doing from you that you need to
understand to effectively use the software. Do not fear the
command line. It is just like writing code. If you are interested
in Git then you are probably interested in code. Think of the
command line interface as a more direct interface to tell the
computer what you want with high-level code instead of expensive
graphics and event loops and spaghetti code.
I can tell you that git-revert(1) basically means create new
commits that undo the changes introduced by the specified
commits. That is likely accomplished by applying a reversed
patch, and that is likely to fail if the tree (files) has changed
much.
Conflicts are OK! They are normal when you work with version
control software. You can manually resolve the conflicts and
continue with the revert. Google can help you to understand how
to resolve conflicts. You can do so manually (my preference, and
a good thing to learn to help you understand why conflicts
occurred in the first place) or you can use software tools to
help. I recommend you create backups of your repository (.git)
and working tree (...folder where your files are) using something
like 7-zip (but a simple copy suffices) when you're new to Git so
that if you make a wrong move it's easier to go back and try
again with confidence.
That said, if you just want to *see* the state of the file at a
particular point in history you can use git-cat-file(1). Another
way would be (with a clean tree) git-checkout(1), though that
will make changes to your tree (and if you aren't careful can
destroy changes that you have already made) that you may not
want. The file can be restored to the latest committed version
using git-checkout(1) again (or git-reset(1) with the --hard
option). Both of these options need to be used with care. In this
case, git-reset(1) could also be used to reset the state of your
working tree to a clean state if you do decide that git-revert(1)
isn't what you wanted.
I recommend that you just find a plain Git tutorial and learn to
the use the real thing. It's really not that hard. And Git for
Windows works well without the need for GitHub's own
proprietary, platform-specific solution. It even includes a Git
GUI if you're still reluctant to use the command line (but my
above wisdom regarding GUIs probably still applies).
If you use the real Git then not only can we help you, but you
can get real-time advice and guidance from the #git channel on
irc.freenode.net.
Regards,
--
Brandon McCaig bamcc...@gmail.com bamcc...@castopulence.org
Castopulence Software https://www.castopulence.org/
Blog http://www.bamccaig.com/
perl -E '$_=q{V zrna gur orfg jvgu jung V fnl. }.
q{Vg qbrfa'\''g nyjnlf fbhaq gung jnl.};
tr/A-Ma-mN-Zn-z/N-Zn-zA-Ma-m/;say'
signature.asc
Description: Digital signature
Re: Our cumbersome mailing list workflow
On 11/27/2014 06:46 PM, Torsten Bögershausen wrote: On 2014-11-25 01.28, Michael Haggerty wrote: [] Let me list the aspects of our mailing list workflow that I find cumbersome as a contributor and reviewer: * Submitting patches to the mailing list is an ordeal of configuring format-patch and send-email and getting everything just right, using instructions that depend on the local environment. Typically everything fits into ~/.gitconfig, which can be carried around on a USB-Stick. Is there any details which I miss, or howtows we can improve ? I used to need one setup at work and a different one at home (because of how my email was configured), and sometimes had to switch back and forth as I carried my notebook around. [...] * I do git fetch gitster, then try to figure out whether the branch I'm interested in is present, what its name is, and whether the version in your tree is the latest version, then git checkout xy/foobar. There are 12 branches from mh/, so it should be possible to find the name, und run git log gitster/xy/fix_this_bug or so. Even more important, this branch is the single point of truth, because this branch may be merged eventually, and nothing else. I know it's *possible*. The question is whether it could be made easier. * Following patch series across iterations is also awkward. To compare two versions, I have to first get both patch series into my repo, which involves digging through the ML history to find older versions, followed by the git am steps. Often submitters are nice enough to put links to previous versions of their patch series in their cover letters, but the links are to a web-based email archive, from which it is even more awkward to grab and apply patches. So in practice I then go back to my email client and search my local archive for my copy of the same email that was referenced in the archive, and apply the patch from there. Finding comments about old versions of a patch series is nearly as much work. In short: We can ask every contributor, if the patch send to the mailing list is available on a public Git-repo, and what the branch name is, like _V2.. Does this makes sense ? That would be helpful, but it would put yet *another* requirement on the submitter (to send patch emails *and* push the branch to some accessible repository). We regulars could script this pretty easily, but people who only contribute occasionally or who are trying to get started will be even more overwhelmed. As an alternative, you can save the branches locally, after running git-am once, just keep the branch. [] Yes, but it is even more unnecessary manual bookkeeping. [...] But there is another thing: Once a patch is send out, I would ask the sender to wait and collect comments at least 24 hours before sending a V2. We all living in different time zones, so please let the world spin once. Yes, good idea. My feeling is that a patch 5 commits should have a waiting time 5 days, otherwise I start reviewing V1, then V2 comes, then V3 before I am finished with V1. That is not ideal. One day per patch might be exaggerated, but I agree that long series should be iterated more slowly than short ones. What does it cost to push your branch to a public repo and include that information in the email ? One has to run an additional command and add some information to the cover letter, every time a patch series is submitted. If it's scripted then it's relatively painless. But for a newcomer these will be manual steps that are easy to forget or to do incorrectly, making it more likely that the newcomer's first contribution to Git will end in mild embarrassment rather than success. 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: Unable to Revert Commit
From: Rex Macey r...@macey.us Unable to Revert Commit ... Resolve the conflicts in your working directory and commit them before trying the revert again. Please help me understand how to resolve the conflicts. Here's what happened (as best as I remember). Created a windows folder github_learn (not under my \documents\github folder) ; Created a file file1.r. Dragged folder into Github for Windows. Committed; I could see the file in my directory, Github for Windows, and on the server (github.com); I modified the first file. Checked that there were different versions and then committed it.; I created a second file, file2.r Committed it. All good.; Then I tested whether I could retrieve the first version of file1.r (before modification). In the History area of Github for Windows, I can see this version. I click on that, and then I click on Revert which produces the error. I am very new to Git and have read some of the documentation and this exercise is my attempt to test myself. So far my grade is not good. I appreciate any guidance including links to instructions. Thank you. Rex Macey -- I belive that what is trying to be said is: You have a 'dirty' worktree which currently contains un-resolved conflicts. It would be unwise to attempt a revert, which may further conflict with those conflict markers. The easy way out is to resolve those conflict markers first. I'd agree that for the beginner, the compactness of the error messages can be a be difficult to understand. -- Philip -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Our cumbersome mailing list workflow
On 11/27/2014 11:53 PM, Eric Wong wrote: Torsten Bögershausen tbo...@web.de wrote: On 2014-11-25 01.28, Michael Haggerty wrote: [...] In short: We can ask every contributor, if the patch send to the mailing list is available on a public Git-repo, and what the branch name is, like _V2.. Does this makes sense ? Not unreasonable. I hope that won't give folks an excuse to refuse to mail patches, though. Some folks read email offline and can't fetch repos until they're online again. My ideal would be to invert the procedure. Let the patches in a public Git repository somewhere be the primary artifact, and let the review process be focused there. Let email be an alternative interface to the central review site: * Generate patch emails (similar to the current format) when pull requests are submitted. * Generate notification emails when people comment on the patches. * Allow people to respond to the patch and notification emails via email. The central review site should associate those comments with the patches that they apply to, and present them along with other review comments received via other interfaces. I like Gerrit as well. But it is less efficient to use, a WEB browser is slower (often), and you need to use the mouse... IMNSHO, development of non-graphical software should never depend on graphical software. Also, I guess there is no way to comment on Gerrit via email (without registration/logins?). The days of the vt52 are over. I'm an old neckbeard myself and have used *real* vt52s. But these days even my *cellphone* is able to handle the GitHub website [1]. Rejecting modern technology is not intrinsically virtuous; it only makes sense if the old technology is really superior. And it is not enough for it to be superior only for neckbeards; it should be superior when averaged over all of the people whose participation we would like to have in the Git project. And by the way, there are text-only clients for interacting with GitHub [1]. Lately, I've been trying to think of ways to make collaboration less centralized. Moving to more centralized collaboration tools is a step back for decentralized VCS. If an efficient decentralized collaboration system existed, then I'd love to give it a chance. But as far as I know, the existing systems are all embryonic. Don't forget that even our current system is centralized to some extent. There is a single mailing list through which all emails pass. There are a few email archives that we de facto rely on (and it is a brittle dependency--if Gmane were to disappear, we would have an awful lot of broken URLs in our emails that would be impossible to fix). It seems like a few desirable features are being talked about here, and summarizing the discussion as centralized vs decentralized is too simplistic. What is really important? 1. Convenient and efficient, including for newcomers 2. Usable while offline 3. Usable in pure-text mode 4. Decentralized Something else? In my opinion, a central system with good Git integration (helps with 1) and both a straightforward web UI (also helps 1) and a good email interface (which gives both 2 and 3) and the ability to export the review history (which avoids lockin, the most important aspect of 4) would be perfect. Is there such a thing? Michael [1] ...probably other websites too. I'm really not trying to flog GitHub here; it's just the one I have the most experience with. In fact, I kindof assume that the Git project would choose a service that is itself based on open-source software. -- 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: Our cumbersome mailing list workflow
On 14-11-28 09:31 AM, Michael Haggerty wrote: On 11/27/2014 06:46 PM, Torsten Bögershausen wrote: On 2014-11-25 01.28, Michael Haggerty wrote: [] Let me list the aspects of our mailing list workflow that I find cumbersome as a contributor and reviewer: * Submitting patches to the mailing list is an ordeal of configuring format-patch and send-email and getting everything just right, using instructions that depend on the local environment. Typically everything fits into ~/.gitconfig, which can be carried around on a USB-Stick. Is there any details which I miss, or howtows we can improve ? I used to need one setup at work and a different one at home (because of how my email was configured), and sometimes had to switch back and forth as I carried my notebook around. [...] * I do git fetch gitster, then try to figure out whether the branch I'm interested in is present, what its name is, and whether the version in your tree is the latest version, then git checkout xy/foobar. There are 12 branches from mh/, so it should be possible to find the name, und run git log gitster/xy/fix_this_bug or so. Even more important, this branch is the single point of truth, because this branch may be merged eventually, and nothing else. I know it's *possible*. The question is whether it could be made easier. * Following patch series across iterations is also awkward. To compare two versions, I have to first get both patch series into my repo, which involves digging through the ML history to find older versions, followed by the git am steps. Often submitters are nice enough to put links to previous versions of their patch series in their cover letters, but the links are to a web-based email archive, from which it is even more awkward to grab and apply patches. So in practice I then go back to my email client and search my local archive for my copy of the same email that was referenced in the archive, and apply the patch from there. Finding comments about old versions of a patch series is nearly as much work. In short: We can ask every contributor, if the patch send to the mailing list is available on a public Git-repo, and what the branch name is, like _V2.. Does this makes sense ? That would be helpful, but it would put yet *another* requirement on the submitter (to send patch emails *and* push the branch to some accessible repository). We regulars could script this pretty easily, but people who only contribute occasionally or who are trying to get started will be even more overwhelmed. A bot could subscribe to the list and create branches in a public repo. (This idea feels familiar -- didn't somebody attempt this already?) Integrate the bot into the list manager, and every PATCH email sent through the list could have the patch's URL (maybe in the footer, or as an X- header). Could this make a decent GSoC project? M. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] commit: inform pre-commit if --amend is used
On 11/28/2014 12:18 AM, Jeff King wrote: On Thu, Nov 27, 2014 at 09:40:08AM -0500, Mark Levedahl wrote: Then when you add new arguments, the hook has to search through the parameters looking for one that matches, rather than just checking $1 for amend (and $2 for the new option, and so on). As long as the set of options remains relatively small, I think that is preferable. We could also just pass them through the environment, which gives nice named parameters. See http://comments.gmane.org/gmane.comp.version-control.git/148479 for an earlier conversation on this exact topic. Also, see http://permalink.gmane.org/gmane.comp.version-control.git/148480 for a similar change in git-gui. Thanks for the links; I had no recollection of that thread. Unsurprisingly, I like the HEAD/HEAD~1 suggestion. That peff guy seems really clever (and handsome, too, I'll bet). I'd still be OK with any of the suggestions given in this thread, though. -Peff ars Apparently our combined handsome-foo was insufficient to get this accepted way back when, hopefully the current submitter has more :^) In any event, I've carried the patches using HEAD/HEAD~1 in my tree for the last 4+ years, have a widely used pre-commit script that depends upon those. So, I personally would be very happy to see this finally show up in Junio's tree, would prefer HEAD/HEAD~1 but can adapt to whatever. Mark -- 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: Our cumbersome mailing list workflow
On Fri, Nov 28, 2014 at 04:34:09PM +0100, Michael Haggerty wrote: My ideal would be to invert the procedure. Let the patches in a public Git repository somewhere be the primary artifact, and let the review process be focused there. Let email be an alternative interface to the central review site: * Generate patch emails (similar to the current format) when pull requests are submitted. * Generate notification emails when people comment on the patches. * Allow people to respond to the patch and notification emails via email. The central review site should associate those comments with the patches that they apply to, and present them along with other review comments received via other interfaces. I think these are good goals. Even as a semi-regular contributor, I prefer to push branches around using Git rather than formatting patches and mailing them. Also, I think that being able to comment on a patch or report a bug without a login (via email) is desirable. I'm not a fan of having to have an account on every Bugzilla on the planet. That's why I like debbugs. It seems like a few desirable features are being talked about here, and summarizing the discussion as centralized vs decentralized is too simplistic. What is really important? 1. Convenient and efficient, including for newcomers 2. Usable while offline 3. Usable in pure-text mode 4. Decentralized I think 1 is definitely important. For me personally, 2 isn't very important, as all my email is via IMAP (so I have to be online). I think 3 is important for accessibility reasons. There are a lot of blind or low-sighted people for whom a GUI is infeasible or burdensome. Something else? It might be useful to have a system that has a bug or issue tracker. We often have posts to the mailing list that don't get a response, even though those may represent legitimate bugs (code or documentation). -- 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
tests do not work with gpg 2.1
[updated subject, as this is not specific to the v2.2.0 release at all] On Fri, Nov 28, 2014 at 10:48:51AM +0100, Michael J Gruber wrote: Are you running gnome_keyring_deamon by any chance? It think it runs by default in Gnome, claims to offer gpg_agent functionality but does not seem to do so fully. I.e., its presence may keep gpg2.1 from starting its own gpg-agent. But gpg2.1 (gnupg modern branch) needs a new gpg-agent which knows how to handle secret keys for gpg2.1. (I may take a shot at trying, but I'm on Fedora - they're slow and special in all things gpg/crypto. And compiling gpg2.1 means compiling all the bits and pieces that monster consists of these days...) I'm not running the gnome daemon (I do normally run gpg-agent, though), and I can reproduce. I wanted to try experimenting today with making sure GPG_AGENT_INFO was unset in the environment. But despite nothing changing (i.e., before I even cleared that variable), I'm getting totally different results. Now when I run t4202, I get no agent prompt, and just: ok 40 - dotdot is a parent directory expecting success: test_when_finished git reset --hard git checkout master git checkout -b signed master echo foo foo git add foo git commit -S -m signed_commit git log --graph --show-signature -n1 signed actual grep ^| gpg: Signature made actual grep ^| gpg: Good signature actual Switched to a new branch 'signed' gpg: skipped C O Mitter commit...@example.com: No secret key gpg: signing failed: No secret key error: gpg failed to sign the data fatal: failed to write commit object And then a subsequent run gives me: rm: cannot remove '/home/peff/compile/git/t/trash directory.t4202-log/gpghome/private-keys-v1.d/19D48118D24877F59C2AE86FEC8C3E90694B2631.key': Permission denied rm: cannot remove '/home/peff/compile/git/t/trash directory.t4202-log/gpghome/private-keys-v1.d/E0C803F8BC3BCC4990E174E05936A7636E99.key': Permission denied rm: cannot remove '/home/peff/compile/git/t/trash directory.t4202-log/gpghome/private-keys-v1.d/FCFAC48BF12AC0FCC32B69AB90AA7B1891382C29.key': Permission denied rm: cannot remove '/home/peff/compile/git/t/trash directory.t4202-log/gpghome/private-keys-v1.d/D50A866904B91C0C49A3F6059584F4A09807D330.key': Permission denied FATAL: Cannot prepare test area It seems that it creates the private-keys directory without the 'x' bit: $ ls -ld trash*/gpghome/private-keys-v1.d drw--- 2 peff peff 4096 Nov 28 11:45 trash directory.t4202-log/gpghome/private-keys-v1.d/ So that's weird, and doubly so that it is behaving differently than it was last night. Obviously _something_ must have change. Maybe something related to the state of my running agent, I guess. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] t0050-*.sh: mark the rename (case change) test as passing
Since commit baa37bff (mv: allow renaming to fix case on case insensitive filesystems, 08-05-2014), the 'git mv' command has been able to rename a file, to one which differs only in case, on a case insensitive filesystem. This results in the 'rename (case change)' test, which used to fail prior to this commit, to now (unexpectedly) pass. Mark this test as passing. Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk --- Hi Junio, I noticed this last week while testing on cygwin. I have only tested this on (64-bit) cygwin/ntfs, but I would assume that other case insensitive filesystems would be OK, since there have been no complaints about t6039-merge-ignorecase.sh not working. Note that I didn't remove $test_case, despite having removed its last use in this test, in case there will be a future need. I'm not sure there will be a future need, of course, so if you would rather I got rid of it, just let me know. ATB, Ramsay Jones t/t0050-filesystem.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t0050-filesystem.sh b/t/t0050-filesystem.sh index 6b3cedc..988c392 100755 --- a/t/t0050-filesystem.sh +++ b/t/t0050-filesystem.sh @@ -64,7 +64,7 @@ test_expect_success setup case tests ' git checkout -f master ' -$test_case 'rename (case change)' ' +test_expect_success 'rename (case change)' ' git mv camelcase CamelCase git commit -m rename ' -- 2.1.0 -- 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
Force git submodule update --remote for some branches
Hi, I have a repository with a submodule and I'd like to force git to checkout the LAST version of the submodule and not the stored one (like git submodule update --remote), but only on some branches and without the need to remember to add --remote every time you are on this branch. Is there any way to do it? Maybe using .gitmodules? Thanks -- Timothy M. Redaelli Arch Linux Trusted User signature.asc Description: OpenPGP digital signature
[PATCH] for-each-ref: correct spelling of Tcl in option description
Tcl is conventionally spelled Tcl. The description of option --tcl, however, spells it tcl. Let's follow the convention. Reported-by: Hartmut Henkel hartmut_hen...@gmx.de Signed-off-by: Ralf Thielow ralf.thie...@gmail.com --- builtin/for-each-ref.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c index 603a90e..f3ce004 100644 --- a/builtin/for-each-ref.c +++ b/builtin/for-each-ref.c @@ -1075,7 +1075,7 @@ int cmd_for_each_ref(int argc, const char **argv, const char *prefix) OPT_BIT(0 , python, quote_style, N_(quote placeholders suitably for python), QUOTE_PYTHON), OPT_BIT(0 , tcl, quote_style, - N_(quote placeholders suitably for tcl), QUOTE_TCL), + N_(quote placeholders suitably for Tcl), QUOTE_TCL), OPT_GROUP(), OPT_INTEGER( 0 , count, maxcount, N_(show only n matched refs)), -- 2.2.0 -- 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] l10n: de.po: fix typos
Am 23. November 2014 um 17:41 schrieb Ralf Thielow ralf.thie...@gmail.com: From: Hartmut Henkel hartmut_hen...@gmx.de Signed-off-by: Hartmut Henkel hartmut_hen...@gmx.de Signed-off-by: Ralf Thielow ralf.thie...@gmail.com --- Junio, please apply this patch directly to your tree. I'll send a pull-request to the l10n coordinator with this change. No need to apply directly. Thanks -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] git-new-workdir: Don't fail if the target directory is empty
On Wed, 2014-11-26 at 15:16 -0800, Junio C Hamano wrote: $ ./src/git/contrib/workdir/git-new-workdir src/git foo master mkdir: cannot create directory ‘foo’: Not a directory unable to create new workdir foo! ;-) That comes from mkdir || fail which is indeed sufficient. Right. Often I find it simpler/clearer to let the underlying commands give the errors: they use perror() and can often provide more specific error messages than my script can, unless I spend a lot of effort trying to determine exactly what the problem is (permissions, disk space, bad symlink, existing file, whatever). Should I respin this with the \$new_workdir\ - '$new_workdir' change (I actually prefer the latter myself but the former was used somewhere so I kept it)? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] t0050-*.sh: mark the rename (case change) test as passing
On Fri, Nov 28, 2014 at 11:57 AM, Ramsay Jones ram...@ramsay1.demon.co.uk wrote: Since commit baa37bff (mv: allow renaming to fix case on case insensitive filesystems, 08-05-2014), the 'git mv' command has been able to rename a file, to one which differs only in case, on a case insensitive filesystem. This results in the 'rename (case change)' test, which used to fail prior to this commit, to now (unexpectedly) pass. Mark this test as passing. Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk --- Hi Junio, I noticed this last week while testing on cygwin. I have only tested this on (64-bit) cygwin/ntfs, but I would assume that other case insensitive filesystems would be OK, since there have been no complaints about t6039-merge-ignorecase.sh not working. I tested and verified that this patch is also needed on Mac OS X (as expected). Note that I didn't remove $test_case, despite having removed its last use in this test, in case there will be a future need. I'm not sure there will be a future need, of course, so if you would rather I got rid of it, just let me know. ATB, Ramsay Jones t/t0050-filesystem.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t0050-filesystem.sh b/t/t0050-filesystem.sh index 6b3cedc..988c392 100755 --- a/t/t0050-filesystem.sh +++ b/t/t0050-filesystem.sh @@ -64,7 +64,7 @@ test_expect_success setup case tests ' git checkout -f master ' -$test_case 'rename (case change)' ' +test_expect_success 'rename (case change)' ' git mv camelcase CamelCase git commit -m rename ' -- 2.1.0 -- 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: Our cumbersome mailing list workflow
A bot could subscribe to the list and create branches in a public repo. (This idea feels familiar -- didn't somebody attempt this already?) Thomas Rast maintains git notes that link git commits to their gmane discussion, you can get them with [remote mailnotes] url = git://github.com/trast/git.git fetch = refs/heads/notes/*:refs/notes/* There is gmane branch and a message-id branch, its pretty usefull. -- 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
