Hi, I'm using guilt 0.28-1 (Ubuntu package) and git-core 1.5.4.3-1ubuntu2. When I use guilt patchbomb, I get some scary output from git-rev-list: Enter all the Cc: email addresses (separated by space): usage: git-rev-list [OPTION] <commit-id>... [ -- paths... ] limiting output: --max-count=nr --max-age=epoch --min-age=epoch --sparse --no-merges --remove-empty --all --stdin --quiet ordering output: --topo-order --date-order format...

This should make the output more readable (by default using diff -u) when some tests fail. Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> --- t/t7501-commit.sh | 12 ++++++------ 1 files changed, 6 insertions(+), 6 deletions(-) diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh index 0edd9dd..6f8c038 100755 --- a/t/t7501-commit.sh +++ b/t/t7501-commit.sh @@ -141,7 +141,7 @@ EOF test_expect_success \ 'validate git-rev-list output.' \ - 'diff current expected' + ...

Sorry for the duplication, I didn't want to send it twice. I also just realised after sending that I forgot to rebase it again current master, where git-rev-list is replaced by git rev-list, but I guess git am -3 handles it. ;-)

Hi, In the kernel tree, I see 2 .gitignore files that use "+pattern": ./arch/blackfin/include/asm/.gitignore:+mach ./arch/blackfin/boot/.gitignore:+vmImage However, I can't find anything about '+' on the gitignore(5) man page at http://www.kernel.org/pub/software/scm/git/docs/gitignore.html . Does the '+' mean something special or is it just a character in the filename/dir pattern? Thanks, -- ~Randy --

OK, I'll ask the blackfin developers/maintainers about it. Thanks. -- ~Randy --

My eyes are getting dry after looking at these s/git-/git / patches, so please do not get offended if I leave these in my Inbox unread for a few days. But I think this particular one is worth mentioning something about, so I am responding to it now. To me, the above suggests that: * we should install git-cvsserver in $(bindir) so that it can be found on $PATH; and * it would be better to encourage users to consistently use "git-cvsserver" everywhere instead of "git cvsserver"; hen...

Also use "git hash-object" and "git rev-parse" without dash. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> --- t/t9300-fast-import.sh | 80 ++++++++++++++++++++++++------------------------ t/t9301-fast-export.sh | 2 +- 2 files changed, 41 insertions(+), 41 deletions(-) diff --git a/t/t9300-fast-import.sh b/t/t9300-fast-import.sh index bd5d5af..328444a 100755 --- a/t/t9300-fast-import.sh +++ b/t/t9300-fast-import.sh @@ -3,7 +3,7 @@ # Copyright (c) 2007 Shawn Pearce # ...

This changes "git-foo" to "git foo" when message strings in tests name git subcommands. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> --- t/t7606-merge-custom.sh | 2 +- t/t9100-git-svn-basic.sh | 4 ++-- t/t9101-git-svn-props.sh | 4 ++-- t/t9102-git-svn-deep-rmdir.sh | 4 ++-- t/t9112-git-svn-md5less-file.sh | 2 +- t/t9122-git-svn-author.sh | 2 +- t/t9123-git...

--- t/t9700-perl-git.sh | 16 ++++++++-------- 1 files changed, 8 insertions(+), 8 deletions(-) diff --git a/t/t9700-perl-git.sh b/t/t9700-perl-git.sh index 0f04ba0..b81d5df 100755 --- a/t/t9700-perl-git.sh +++ b/t/t9700-perl-git.sh @@ -27,14 +27,14 @@ test_expect_success \ echo "changed file 1" > file1 && git commit -a -m "second commit" && - git-config --add color.test.slot1 green && - git-config --add test.string value && - gi...

--- t/t9200-git-cvsexportcommit.sh | 14 +++++++------- 1 files changed, 7 insertions(+), 7 deletions(-) diff --git a/t/t9200-git-cvsexportcommit.sh b/t/t9200-git-cvsexportcommit.sh index 988c3ac..245a7c3 100755 --- a/t/t9200-git-cvsexportcommit.sh +++ b/t/t9200-git-cvsexportcommit.sh @@ -9,7 +9,7 @@ test_description='Test export of commits to CVS' cvs >/dev/null 2>&1 if test $? -ne 1 then - test_expect_success 'skipping git-cvsexportcommit tests, cvs not found' : + test_...

Didn't 9907721 (templates/Makefile: don't depend on local umask setting, 2008-02-28) take care of that? ... goes and looks ... Ah, that is only to propagate the wish of the person who _built_ it. You probably have a tight umask and have sources checked out unreadable to others, which is propagated to the installation (check the permission of files in your templates/blt directory to verify this conjecture). And the build procedure is honoring your wish to make things unreadable to others....

In places that the standard malloc/strdup is used without checking if the allocation was successful, I replaced it to xmalloc/xstrdup which check the memory allocation result. Signed-off-by: Dotan Barak <dotanba@gmail.com> --- diff --git a/builtin-http-fetch.c b/builtin-http-fetch.c index 3a06248..ea2b689 100644 --- a/builtin-http-fetch.c +++ b/builtin-http-fetch.c @@ -53,7 +53,7 @@ int cmd_http_fetch(int argc, const char **argv, const char *prefix) } url = argv[arg]; if (url &...

A patch would only fail if it has a hunk containing a line with keyword expansion in it. So I for one am willing to _occasionally_ have to submit to perforce manually, for the benefits of no keyword expansion - among other things, the ability to diff between branches without the interferences is very important for me. But that's just my 2 cents, and I'm just another git(-p4) user. If you do come up with a "formal" patch, you might want to explicitly add Simon Hausmann to the To list, for he's...

AAUI, "git merge 2 3" doesn't mean "merge 2 and 3 together", but "merge 2 and 3 with the current HEAD". So, what you wanted was : git checkout 1 git merge 2 And what you did was an octopus merge of A, E and I (which ends up being the same since A is anyway the common ancestor of E and I). Now, this doesn't explain why the conflicted merge gives a result different from the other. -- Matthieu --

Yes, it was your 98cf9c3 (Introduce reduce_heads(), 2008-06-27).

Hi, I build git from sources and I have one small permissions issue that (I think) should be fixed. So I build it as described in INSTALL file make prefix=/usr all sudo make prefix=/usr install Everything goes fine here and we have a new version of git installed $ git --version git version 1.6.0.1.285.g1070 But when I want to create a new repo, I have a fatal problem $ git init fatal: cannot copy /usr/share/git-core/templates/ hooks/applypatch-msg.sample to /personal/sources/opensource/...

[...] By the way, I think the fact that in different SCMs meaning of "$scm revert" and of "$scm reset" differs widely caused Mercurial to adopt "hg backout" for creating a commit which reverts changes (cherry-pick -R), and "hg rollback" to undo last commit. -- Jakub Narebski Poland --

I agree with this. That's part of the problem I have with schemes to make commands work similarly to other SCMs. If you give, for example, eg a mode to act like "svn revert;" that all well and good until the user runs "git diff" and you're made a liar. In svn, there would be no diff, because the files all match their respective upstream versions. In git, you would see changes because the file no longer matches the last commit. It it a delicate balance to have the user interface match both the...

No, that would leave staged changes unreverted -- a particular case of which means that revert wouldn't be able to undo an add operation. For svn-like-revert, the default should be for both staged and unstaged changes to be undone, unless the user specifically requested that only part of the changes be reverted (e.g. with --staged or --unstaged flags). Making revert work prior to the initial commit for new adds is another case that needs a command with behavior different Why? If the command _by...

Ah, I had somehow missed hg backout. Thanks for the pointer! Elijah --

On Tue, Sep 9, 2008 at 12:37 PM, Govind Salinas In yap, "revert" is used to discard working copy changes. "revert -a" reverts all changes; just "revert" replies "nothing to do." Having "pyt revert" = "git reset --hard" makes me queasy; especially in Dvorak it's all too easy to hit Enter when reaching for '/'; seems like a catastrophe waiting to happen. I tend to dislike "DWIM" in interfaces, because the computer cannot read your mind, and can therefore never know with certainty what I mean. E...

The harm I see in trying to support every possible use case is that it makes it exponentially more difficult to fully understand the tool. Using yap as an example, I think it should be easy enough for a user to read the help blurb for every command and understand what it does and when to use it (this is easy for me to say as the author, but I think it would hold true for a "typical SCM user.") Having a mode the seems to act like another SCM (revert --since) seems great at first blush. The user w...

[Empty message]

The purpose I'd use the origin links for is to manage software projects that consist of 7 main branches which have branched in (on average) two year intervals, which never get merged anymore. The only thing that happens is that there are backports amongst the branches about two per week. The only way to perform the backports is by using cherry-pick. The history of each backport *is* important though. Since all the developers who care about the multiple release branches have all the relevant b...

Using special references in the free-form area of a commit is akin to using X-... headerfields in E-mail with all the assorted mess: - No strict definition of what it means. - Diverging porcelain implementations making use of the field in ever so slightly changing ways over the years. - You cannot rely on the field being always available. - Automated "renumbering" becomes difficult at best. What we want are concise and unambiguous definitions which allow us to build tools that operate predicta...