[Empty message]

FreeBSD for example does not ship with a /usr/bin/python such that Python installed from ports will be located by default in /usr/local/bin --- Makefile | 2 +- contrib/fast-import/import-zips.py | 2 +- contrib/hg-to-git/hg-to-git.py | 2 +- contrib/p4import/git-p4import.py | 2 +- git_remote_helpers/Makefile | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) diff --git a/Makefile b/Makefile index 3a6c6ea..2b248b4 100644 --- ...

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. -------------------------------------------------- [Graduated to "master"] * jk/maint-add-ignored-dir (2010-02-28) 3 commits (merged to 'next' on 2010-03-13 at df91e32) + tests for "git add ignored-dir/file" without -f + dir: fix COLLECT_IGNORED ...

Entirely free SHOKING video clips collected and posted from users all over the Net. Katie Gill, Chelsea Handler, Lanre Idewu, and more! http://ho.io/celebs --

find_unique_abbrev() already returns the full SHA-1 if abbrev = 0, so we can remove the logic that avoids the call. Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com> --- builtin/ls-files.c | 7 ++----- builtin/ls-tree.c | 6 ++---- 2 files changed, 4 insertions(+), 9 deletions(-) diff --git a/builtin/ls-files.c b/builtin/ls-files.c index b065061..c0fbcdc 100644 --- a/builtin/ls-files.c +++ b/builtin/ls-files.c @@ -153,8 +153,7 @@ static void show_ce_entry(const char *tag, struct ...

Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com> --- sha1_name.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sha1_name.c b/sha1_name.c index bf92417..2b1be58 100644 --- a/sha1_name.c +++ b/sha1_name.c @@ -196,10 +196,10 @@ const char *find_unique_abbrev(const unsigned char *sha1, int len) int status, exists; static char hex[41]; + if (len == 40 || !len) + return sha1_to_hex(sha1); exists = has_sha1_file(sha1); memcpy(hex, sha1_to_hex(sha1), ...

55246aa (Dont use "<unknown>" for placeholders and suppress printing of empty user formats) introduced a check to prevent empty user-formats from being printed. This test didn't take empty commit messages into account, and prevented the line-termination from being output. This lead to multiple commits on a single line. Correct it by guarding with a check for user-format. Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com> --- This is a fix for the issue I posted about with rebase ...

Hi! I'd like to single this out - this is a very arbitrary decision and has its distinct pros and cons compared to alternative approaches, and was not taken lightly. It wouldn't be that difficult to go in a different Why not just manage them in separate repositories? If you want to pick I agree that topgit really sucks in many areas. :) While it is usable in practice if you know what you are doing, in some aspects it never got But how is this different from TopGit's approach? ...

The values passed this way will override whatever is defined in the config files. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> --- Documentation/git.txt | 7 +++++ builtin/config.c | 6 +++- cache.h | 2 + config.c | 71 ++++++++++++++++++++++++++++++++++++++++++++++++ git.c | 9 ++++++ t/t1300-repo-config.sh | 7 +++++ 6 files changed, 101 insertions(+), 1 deletions(-) diff --git a/Documentation/git.txt ...

The hook templates were still using/referencing 'git-foo' instead of 'git foo.' This patch updates the sample hooks to use the modern conventions instead. Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca> --- templates/hooks--commit-msg.sample | 2 +- templates/hooks--post-update.sample | 2 +- templates/hooks--pre-commit.sample | 4 ++-- templates/hooks--pre-rebase.sample | 18 +++++++++--------- templates/hooks--prepare-commit-msg.sample | ...

Replace different binary search function with a generic one. Signed-off-by: Bo Yang <struggleyb.nku@gmail.com> --- commit.c | 24 +++++++++--------------- 1 files changed, 9 insertions(+), 15 deletions(-) diff --git a/commit.c b/commit.c index 731191e..dba67d5 100644 --- a/commit.c +++ b/commit.c @@ -6,6 +6,7 @@ #include "diff.h" #include "revision.h" #include "notes.h" +#include "sha1-lookup.h" int save_commit_buffer = 1; @@ -79,23 +80,16 @@ static unsigned long ...

Hi, I like it very much already! You obviously put in a substantial amount of time to learn intricate details about the way Git operates, and what is already available. And you also provided a patch (unrelated to line-level history browser), so you proved that you actually cloned Git, and that you can actually patch it and use Git itself to send a patch to this list. Very good. I think that that might be good for starters, but one could imagine that an integration into "git ...

If you are hooking into "git log", it already has "-M / -C / -C -C" as a notion to express "different levels of digging" to find code movement and copies, and so does "git blame". You probably will save a lot of time if you studied the current blame implementation thouroughly before designing or coding. Two things that you need to think about carefully is why "blame" stops at the commits it shows, and if you could "peel" these lines in its output to peek what are behind the lines, what you ...

You might want to reconsider the line range syntax. Exactly the same syntax is already used to specify a commit range, so reusing it may lead to confusion. --

I, actually, think the proposed line range syntax works because it uses the same _range_ notation. The issue is how to differentiate the _line_ range(s) from the _commit_ range(s); and, yes, I would like multiple ranges of each type as well as multiple files. --

Several tests did not use test_expect_success for their setup commands. Putting these start commands into the testing framework means both that errors during setup will be caught quickly and that non-error text will be suppressed without -v. Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com> --- Noticed some extra output when updating my server's copy of git from source. Tested on OS X using bash and dash. t/t3020-ls-files-error-unmatch.sh | 8 ++- ...

Several tests did not use test_expect_success for their setup commands. Putting these start commands into the testing framework means both that errors during setup will be caught quickly and that non-error text will be suppressed without -v. Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com> --- Updated to only have one setup test in t4103, which also includes the initial set of cat commands just in case. t/t3020-ls-files-error-unmatch.sh | 8 ++- t/t3800-mktag.sh ...

Aside from handling of SIGPIPE, there was no reason for verify-tag to run in a separate process. Not much advantage to this I can see. It just simplifies things a little. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> --- builtin/tag.c | 6 +----- 1 files changed, 1 insertions(+), 5 deletions(-) diff --git a/builtin/tag.c b/builtin/tag.c index d56c882..d138e0c 100644 --- a/builtin/tag.c +++ b/builtin/tag.c @@ -147,11 +147,7 @@ static int delete_tag(const char *name, const ...

There is not much reason to avoid dashed command names here except setting a good example, but setting a good example is reason enough. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> --- builtin/tag.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/builtin/tag.c b/builtin/tag.c index 4ef1c4f..d56c882 100644 --- a/builtin/tag.c +++ b/builtin/tag.c @@ -147,9 +147,9 @@ static int delete_tag(const char *name, const char *ref, static int verify_tag(const char ...

Avoid an unnecessary get_sha1() call in cmd_tag(). Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> --- builtin/tag.c | 2 +- builtin/verify-tag.c | 16 ++++++++++++++-- tag.h | 3 ++- verify-tag.c | 6 +----- 4 files changed, 18 insertions(+), 9 deletions(-) diff --git a/builtin/tag.c b/builtin/tag.c index d138e0c..df94a8c 100644 --- a/builtin/tag.c +++ b/builtin/tag.c @@ -147,7 +147,7 @@ static int delete_tag(const char *name, const char ...

If the rest of the patches go in the right direction, this one should be dropped. I should presented it as two alternative series instead: one that follows the appropriate calling convention here, and one that libifies verify_tag. In other words, no good reason at all; thanks for pointing it out. I’ll send a version of patch 4/5 that doesn’t depend on this one in a moment. Jonathan --

Patch does not apply; no version of Makefile I have has this line in it. --

GNU make’s target-specific variables facility has one weird facet: any variables set for a given target apply to all of its dependencies, too. For example, when running “make exec_cmd.o”, since exec_cmd.o depends on GIT-CFLAGS, the variable assignment in exec_cmd.s exec_cmd.o: ALL_CFLAGS += \ '-DGIT_EXEC_PATH="$(gitexecdir_SQ)"' \ '-DBINDIR="$(bindir_relative_SQ)"' \ '-DPREFIX="$(prefix_SQ)"' applies when refreshing GIT-CFLAGS, and the extra options get included in the tracked ...

From: Imre Deak <imre.deak@gmail.com> This typo will lead to git-daemon dying any time the connect string includes a port after the host= attribute. This can lead for example to one of the following error messages on the client side when someone tries git clone git://...:<port>. When the daemon is running on localhost: fatal: The remote end hung up unexpectedly or when the daemon is connected through an ssh tunnel: fatal: protocol error: bad line length character: erro In the latter ...

Signed-off-by: Benjamin C Meyer <bmeyer@rim.com> --- git-rebase.sh | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/git-rebase.sh b/git-rebase.sh index fb4fef7..bf93019 100755 --- a/git-rebase.sh +++ b/git-rebase.sh @@ -101,7 +101,7 @@ call_merge () { cmt="$(cat "$dotest/cmt.$1")" echo "$cmt" > "$dotest/current" hd=$(git rev-parse --verify HEAD) - cmt_name=$(git symbolic-ref HEAD 2> /dev/null || echo HEAD) + cmt_name=$(git symbolic-ref --quiet HEAD || echo ...

Signed-off-by: Benjamin C Meyer <bmeyer@rim.com> --- git-pull.sh | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/git-pull.sh b/git-pull.sh index d45b50c..08dac0a 100755 --- a/git-pull.sh +++ b/git-pull.sh @@ -206,7 +206,7 @@ test true = "$rebase" && { . git-parse-remote && remoteref="$(get_remote_merge_branch "$@" 2>/dev/null)" && oldremoteref="$(git rev-parse -q --verify "$remoteref")" && - for reflog in $(git rev-list -g $remoteref 2>/dev/null) + for ...

Are you sure? My local copy of git-rev-list.1 says --quiet Don’t print anything to standard output. This form is primarily meant to allow the caller to test the exit status to see if a range of objects is fully connected (or not). It is faster than redirecting stdout to /dev/null as the output does not have to be formatted. A similar question applies to the other patches in this series: are you sure they suppress the right output? (I haven’t ...

I would like to know how the interface (the command line arguments passed to the program) and output should look like (a rough example would be fine). I'm very interested in participating in Google Summer of Code, but living in the Southern Hemisphere means that I would have to do it in parallel with my university classes, therefore limiting the scope of projects that I can handle. The line-level history browser appears to be well within my reach. André Ferreira --

Hi there, I attached a trivial patch that auto-corrects a frequent typo does not trigger any error with git pull. I find it useful so I hope others will too. -- Benoit "tsuna" Sigoure

Make the rpm spec file create a git-completion subpackage that contains the bash completion support from the contrib/ directory. Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca> --- This is the alternate method for shipping the bash completion support. I think I personally prefer this method, but I'd be happy to see either solution ship as part of the .spec file so that I don't need to continue handling it separately. git.spec.in | 17 +++++++++++++++++ 1 files changed, 17 ...

The spec file provided by the author of bash-completion, Ian Macdonald, uses this path: http://www.caliban.org/files/redhat/SPECS/bash-completion.spec As does the Fedora Project (including EPEL): http://cvs.fedoraproject.org/viewvc/rpms/bash-completion/F-13/bash-completion.spec?vie... http://cvs.fedoraproject.org/viewvc/rpms/bash-completion/EL-5/bash-completion.spec?vie... OpenSUSE 11 does not appear to ship ...

--

Thanks. --

log.decorate is still in "next". My understanding was that it was not going to graduate to "master" until this issue had been resolved, and that the current plan was to disable config decoration for --pretty=raw. That would solve the issue without any effort on the part of gitk. -Peff --

If CDPATH is set, "cd" prints its destination to stdout, causing the common (cd a && tar cf - .) | (cd b && tar xf -) idiom to fail. For example: make -C templates DESTDIR='' install make[1]: Entering directory `/users/e477610/exptool/src/git-1.7.0.2/templates' install -d -m 755 '/home/e477610/exptool/share/git-core/templates' (cd blt && gtar cf - .) | \ (cd '/home/e477610/exptool/share/git-core/templates' && umask 022 && gtar xof -) gtar: This does not look like a tar archive Most ...

As Sverre pointed out, this is not the goal of the project. The proposal is not to rewrite git-svn. You're probably right to assume that any such endeavor would be unsuccessful in one summer. The proposal is to create an application that will natively support SVN repositories in Git. I'm simply pointing out the limitations of git-svn as a motivation for this project. As I've mentioned in my proposal, good SVN exporters already exist, and creating an SVN client can be fairly elementary. The ...

Hi, I just prepared another revision of my proposal- I've tried to be clearer about the objective, and included a timeline this time. Note that I've also changed the name from native-git-svn to git-remote-svn, as recommended by Sverre. ====================================== Project Proposal: git-remote-svn | Native SVN support in Git == The Outline == The objective of git-remote-svn is to allow native interaction with SVN repositories in Git. The motivation for writing this comes ...

Hi, The one thing I worry about is that you are proposing to wait a while before submitting your changes upstream. I would suggest pushing whatever pieces work to contrib/ early on to get more feedback from reviewers and testers. (I am saying this selfishly, as a potential In particular, this seems like very little time to get the code into shape for git.git. Hope that helps. Cheers, Jonathan --

Right. I only split it up for the purposes of illustration. 3 and 4 will be merged into a program called `git-remote-svn` that will automatically be invoked when Git encounters an SVN remote. 2 and 5 will be merged into another program `svn-export-import` which can be thought of as the fusion of svn-fast-export and svn-fast-import. `git-remote-svn` will invoke it when necessary. And yeah, I don't know if I want to write the SVN client into `svn-export-import` or leave it Thanks. I'll have ...

To me it looks like another config file to the config stack. No thing can go worse (except that if you have core.worktree in $GIT_DIR/config, now also specify -c core.worktree=foo, then core.worktree code would be called twice). However, specifying "-c foo=relativepath" may surprise users. Current working directory may have been moved when that config is used. -- Duy --

That's gmail, again. There must be an attachment with a normal patch, but I'll resend. --

Thanks for doing the gruntwork; very much appreciated. I'll backburner this and wait until the people who are described by these entries say they want these entries in the .mailmap file. If they do not like the variant that your patch suggested, and if they care, then we will get updates that should be applied. Otherwise they themselves don't care, so why should we ;-)? --

I think at least one person (Michael) cared, so if the people described by those entries don't provide feedback then that means they don't care and you shouldn't wait after them to apply the patch including those entries. Nicolas --

You are giving me too much credit. I just made a suggestion, you had the choice to agree to or disagree with it, and I am hoping that you made the final decision to rewrite the patch to match what I suggested not because you wanted a "commit count" in the project with any form of a change, but because you thought the suggested approach made much more sense than the earlier iterations. And in that case, the final decision to submit the patch in this form was due to _you_. Don't give me undue ...

I think you misunderstood the point of having tests. It is not about demonstrating that you did a good job implementing the new feature, or your implementation works as advertised in the submitted form. That is the job of the review process before patch acceptance. Tests are to pretect what you perfected during the patch acceptance review from getting broken by other people in the future, while you are not closely monitoring the mailing list traffic. Many people, me included, tend to ...

I hope I am not giving you undue burden, but here is what I would add. One thing that I am not sure about is what to do with "-l --orhpan". --- t/t2017-checkout-orphan.sh | 43 ++++++++++++++++++++++++++++++++++++++++++- 1 files changed, 42 insertions(+), 1 deletions(-) diff --git a/t/t2017-checkout-orphan.sh b/t/t2017-checkout-orphan.sh index 5a9a3fa..e80e167 100755 --- a/t/t2017-checkout-orphan.sh +++ b/t/t2017-checkout-orphan.sh @@ -44,7 +44,48 @@ test_expect_success '--orphan ...

It is not true. From the git-config(1) manpage, the description (meaning) of user.name and user.email is: user.email:: Your email address to be recorded in any newly created commits. Can be overridden by the 'GIT_AUTHOR_EMAIL', 'GIT_COMMITTER_EMAIL', and 'EMAIL' environment variables. See linkgit:git-commit-tree[1]. user.name:: Your full name to be recorded in any newly created commits. Can be overridden by the 'GIT_AUTHOR_NAME' and ...

That doesn't make any sense to me. Think why you are saying A..B, with an explicit "A". It is because you know it is different from HEAD; otherwise you would have done "git merge B"---slurp all changes between HEAD..B, which would be equivalent to "cherry-pick --ff HEAD..B". As an ingredient for use of scripts that do not want to check (even if they could) if it is dealing with a corner case in which the commit a change is being applied to happens to be the commit the change in ...

Reviewed-and-tested-by: Jonathan Nieder <jrnieder@gmail.com> There’s a follow-up patch to remove the duplicated code this touches (no functional changes) at <http://bugs.debian.org/465776>. Thanks again. Jonathan --

Unless the ‘-encoding’ option is supplied, wish interprets source files using the default system encoding, which depends on locale. This can cause the copyright symbol to display incorrectly in gitk’s about dialog. The -encoding option was added to tcl in version 8.1. Reported-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> --- Hi, When I tried applying your patch, running “make update-po” seemed to undo its effect on translations. ...

Do you know whether the situation described by the comment has been addressed for Tk? Maybe gitk could check for an appropriate Tk version to avoid this workaround on all platforms. --

It could be version differences of AsciiDoc-to-xmlto toolchain. I think I've listed the versions I use (and the ones currently used to format the copies people get from k.org) elsewhere in this thread. If you are using anything newer, perhaps we are seeing an issue waiting to materialize and you are being a useful coalmine canary. If the output you showed is the best we could achieve without using constructs that break the versions that are older than what you used but are still in use ...