French translation: copy -> copie. #45
Conversation
|
MSysGit - the development behind Git for Windows » git #62 SUCCESS |
|
Translation-updates aren't Windows specific, so they should go to the upstream git mailing list instead. |
|
@Grahack while @kusma is right that this patch should be sent upstream (to git@vger.kernel.org, they don't do pull requests as far as I can tell), I merged it into our repository nevertheless because it is better to have it than not to have it ;-) |
|
That's a git-gui commit - so I've applied it to git-gui. It will end up in git mainstream in due course. |
|
One reason they don't accept pull requests at upstream - no sign-off again. |
|
@patthoyts How's a pull request with a missing sign-off different from a patch on the mailing list missing a sign-off? In both cases you would have to iterate with the developer. Sorry for getting slightly off-topic here, but I do not see why this is a reason against opening upstream for GitHub pull requests. |
|
Its different in that its already been merged. Pull requests seem to encourage merge and push with significantly less review. In this case, did the git mailing list thing of extracting this as a patch, applying it to git-gui's repo (git am -p 2 -s patchfile), testing it and noticing that it only had my signoff. Pull requests are ok they're basically no different to a mail with a patc - but clicking a UI button to have it be merged for you should be discouraged. Adding my signoff is a reasonable trace that I actually tried the patch out before pushing it. |
|
@patthoyts in general I think you are absolutely correct. However, for an obviously correct typo fix (I am almost fluent in French), IMHO requiring contributors to jump through the hoops the Git project established is really overkill. I want to encourage contributions, not discourage them... |
"while sh t5601-clone.sh; do :; done" seems to fail sporadically at around test msysgit#45 where fake-ssh wrapper is copied create plink.exe, with an error message that says the "text is busy". I have a mild suspicion that the root cause of the bug is that the fake SSH process from the previous test is still running by the time the next test wants to replace it with a new binary, but in the meantime, removing the target that could still be executing before copying something else over seems to work it around. Signed-off-by: Junio C Hamano <gitster@pobox.com>
No description provided.