Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com> --- Documentation/git-cvsexportcommit.txt | 22 ++++++++++++++---- git-cvsexportcommit.perl | 39 ++++++++++++++++++++++---------- 2 files changed, 44 insertions(+), 17 deletions(-) I finally got tired of swapping working directories. -- robin diff --git a/Documentation/git-cvsexportcommit.txt b/Documentation/git-cvsexportcommit.txt index c3922f9..310d56a 100644 --- a/Documentation/git-cvsexportcommit.txt +++...

You beat me to it, as I was busy flaming Linus. :) The patch I started is very similar to this, but I had one concern that I was tracking down: is the author name encoding necessarily the same as the commit text encoding? -Peff -

Fixed some spelling mistakes. --- po/ru.po | 516 +++++++++++++++++++++++++++++++++++--------------------------- 1 files changed, 292 insertions(+), 224 deletions(-) diff --git a/po/ru.po b/po/ru.po index b8e9447..6727a83 100644 --- a/po/ru.po +++ b/po/ru.po @@ -7,7 +7,7 @@ msgid "" msgstr "" "Project-Id-Version: git-gui\n" "Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2007-10-10 04:04-0400\n" +"POT-Creation-Date: 2007-10-31 21:23+0100\n" "PO-Revision-Date: 2007-10-22 22:30-0200\n" ...

Previously commits without parents would fail to export with a message indicating that the commits had more than one parent. Instead we should use the --root option for git-diff-tree in place of a parent. Signed-off-by: Brad King <brad.king@kitware.com> --- git-cvsexportcommit.perl | 13 ++++++++++--- 1 files changed, 10 insertions(+), 3 deletions(-) diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl index f284c88..7548cc0 100755 --- a/git-cvsexportcommit.perl +++ b/git...

Signed-off-by: Mike Hommey <mh@glandium.org> --- git-clone.sh | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/git-clone.sh b/git-clone.sh index 0ea3c24..57e96ae 100755 --- a/git-clone.sh +++ b/git-clone.sh @@ -191,7 +191,9 @@ fi # it is local if base=$(get_repo_base "$repo"); then repo="$base" - local=yes + if type cpio > /dev/null 2>&1; then + local=yes + fi fi dir="$2" -- 1.5.3.4 -

Hi, I thought the accord was that "cpio" is a _runtime_ dependency. But yes, I agree "type" is not necessarily the best choice. Maybe testing the exit code for 127 (not found) is the better choice? Ciao, Dscho -

Hello, I've made my first attempt at tracking my changes to upstream git repository using git-fetch/git-rebase workflow. I did three commits to my master branch, and then upstream incorporated two of them in slightly modified form, so that some conflicts are to be expected. I did git-fetch followed by git-rebase, and finally have got the end result I hoped for, but there were some confusion along the way. I think I'd post the log of the session here along with my thoughts so that an interested per...

It wasn't a no-op patch. It had conflicts which you resolved to the There seems to be some bug in rebase that makes it fail in this case. Someone on #git also reported that --abort failed to reset his branch to the old head in a similar case, but I didn't manage to reproduce that yet (well, I didn't try that hard), so I don't know if it's really a bug or a misuse by that guy. Björn -

Hi, Isn't that obvious? To prevent you from accidentally losing a commit. Ciao, Dscho -

In case it is not obvious... A rebase conflict resolution that results in emptiness is a rather rare event (especially because rebase drops upfront the identical changes from the set of commits to be replayed), but it does happen. One could argue that "rebase --continue" can notice that the resolved index is identical to the tree of the HEAD commit and skip it automatically. Given an index that is identical to HEAD, however, it is not easy to safely determine if that is because the patch did ...

That would make sense to me if this was a mistake that could easily happen. I'd assumed that in the case of a conflict that stopped the rebase process, the index and working tree are always left dirty, so that if they both agree with the HEAD at the time of commit, then it's because the user explicitly made them that way. I ran into the same confusion as the original poster when starting to use rebase, so I suspect it's common. --b. -

Yeah, I think a message saying "patch is now empty, skipping..." would be sufficient to let the user know what's going on. This doesn't seem so perilous to me that it's worth requiring a positive acknowledgement. --b. -

Signed-off-by: Simon Sasburg <Simon.Sasburg@gmail.com> --- With this patch I was able to use git-send-email to send mail through gmail's smpt server, which uses TLS. Net::SMTP::TLS apparently doesn't do proper error handling, so the TLS codepath is essentially not checked for errors. I'm not really happy with this. But my perl knowledge is way too limited for me to know if/how that helps. (This patch was just made by copying existing code and fiddling with it untill it did what i wanted...

Ah, yes, i got the Authen::SASL errors at first, but even after resolving all missing module dependencies, the --smpt-ssl still did not work for me, so i started looking at Well, it fails here, maybe maybe you can show me exactly what you did (configuration/parameters etc)? and it fails, while the same line using --smtp-tls instead of --smtp-ssl with my patch applied works. What am i missing? -

hey All. i'm maintaining my own git porcelainen, and as part of that had to (re-)implement my own commit command: http://blogs.gnome.org/timj/2007/10/13/13102007-yummy-yummy-porcelain-version-08/ i've read through git-commit and cg-commit, and would really like to avoid reimplementing the hook and utf8 encoding handling. thus, my tool calls git-commit once it has created an index file with all the files that need comitting. ideally, it'd construct a temporary index, e.g. $GIT_DIR/next-index$$...

Looks like something nasty here. I also failed to reproduce with such test, however I definitely was sure, that I modelled it properly. The typical scenario here is that I'm syncing with external repository by hands. I tried to replay this with "bad" authors file, but it doesn't allow me to past through "bad" changeset. And yes, adding new entry to authors files fixes the problem. I saw corruption, when git-svn in the next run continues fetch changesets. As I saw this problem several times with m...

I just cloned the latest git and it builds ok, but fails when I clone: % uname -a Linux gronk.zopyra.com 2.4.9-21 #1 Thu Jan 17 14:16:30 EST 2002 i686 unknown % git --version git version gitgui.0.8.4.g9c514 % git clone --bare ~/my_repo Initialized empty Git repository in /repos/git/my_repo/ /opt/git/bin/git-clone: line 297: cpio: command not found So, should git not check this when it is building? I don't remember this dependence from earlier versions of git. I have been running git 1.4....

Why cpio? What is wrong with ln(1) (every Unix should have one) or link(2) ? Erik --=20 They're all fools. Don't worry. Darwin may be slow, but he'll eventually get them. -- Matthew Lammers in alt.sysadmin.recovery

Hi, Patch, please? Ciao, Dscho -

cp -l isn't even close to portable. It's not in POSIX, and doesn't work on (at least) Solaris. I think Mike's patch (cpio if available, copy otherwise) is a reasonable approach. If there are other methods (and I think cp -l is not unreasonable for systems where it is supported and cpio is unavailable), then perhaps it is worth trying them one by one and dropping back to full copy if all fail. -Peff -

git may be build and run on two different hosts, so while the build-time check is good there should be a run-time check as well. /Allan -

Your MUA seems to mark the UTF-8 message you are sending out as 8859-1, which means your name in the message gets corrupt. And crucially, you forgot to say "... when you do X". I am assuming that you meant: This (picture) becomes this (picture) instead of this (picture) when you run "git rebase -p -m master topicA". but without it, the nice ASCII drawings loses their value. It is somewhat disturbing that this treats the first parent too special. -

I believe that the issue is with Junio's mail client. Indeed, the context encoding for the mail *body* was specified as 8859-1, but that should have none effect on fields in the mail header, because any field is the header should be either printable ASCII or encoded to contain only ASCII characters as specified in RFC 1522: encoded-word = "=?" charset "?" encoding "?" encoded-text "?=" Here is the From field from the mail: From: =?utf-8?q?Bj=C3=B6rn=20Steinbrink?= <B.Steinbrink@gmx.de> ...

Hmm... I looked at the mail again and I cannot see where 8859-1 is specified. It seems that context encoding is not specified at all. Of course, it is incorrect to use non ASCII characters in a mail without specifying encoding. Apparently, because I use utf-8 in the terminal, the Sign-off line displays correctly for me, so I did not notice the problem. Sorry for the noise... Dmitry -

Yep, that's it. If the Signed-Off-By was added by commit -s, it works, while format-patch -s causes the header to be missing, although the Signed-Off-By is utf-8 encoded. Will try to remember that. Thanks, Björn -