gmane.comp.version-control.git

--follow is ignored when used with --reverse

Alois Mahdal — 2013-05-23T23:23:24

Hello!

This [has been reported][1] to this list about half a year ago
but with no response so I'm  not even sure if it's been
acknowledged as bug.

  [1]: http://marc.info/?l=git&m=135215709307126&q=raw

When I use `git log --follow file` all is OK, but once I add
`--reverse` to it, it no longer follows the file beyond renames.

This makes it hard to query for when the file was really added,
which I was trying to achieve with

    $ git -1 --reverse --follow several_times_renamed_file

Is this going to be fixed?

Thanks,
aL.

[PATCH] git-remote-mediawiki: better error message when HTTP(S) access fails

Matthieu Moy — 2013-05-23T20:05:03

My use-case is an invalid SSL certificate. Pulling from the wiki with a
recent version of libwww-perl fails, and git-remote-mediawiki gave no
clue about the reason. Give the mediawiki API detailed error message, and
since it is not so informative, hint the user about an invalid SSL
certificate on https:// urls.

Signed-off-by: Matthieu Moy <Matthieu.Moy< at >imag.fr>
---
 contrib/mw-to-git/git-remote-mediawiki.perl | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/contrib/mw-to-git/git-remote-mediawiki.perl b/contrib/mw-to-git/git-remote-mediawiki.perl
index 9c14c1f..5b6e833 100755
--- a/contrib/mw-to-git/git-remote-mediawiki.perl
+++ b/contrib/mw-to-git/git-remote-mediawiki.perl
< at >< at > -292,7 +292,13 < at >< at > sub get_mw_all_pages {
 if (!defined($mw_pages)) {
 print STDERR "fatal: could not get the list of wiki pages.\n";
 print STDERR "fatal: '$url' does not appear to be a mediawiki\n";
-print STDERR "fatal: make sure '$url/api.php' is a valid page.\n";
+if ($url =~ /^https/) {
+    pr

Feature Request: existence-only tracking

Brett Trotter — 2013-05-23T17:01:43

In my work, we have a lot of autogenerated files that need to exist so
a script will replace their contents, but tracking the contents
creates a lot of unnecessary conflicts. I would love to see an option
for a different tracking method that just makes sure a file or
directory exists. This would also obviate the need for adding things
like .empty files in a directory to force the directory to exist.

[PATCH 0/7] Let's get that < at >{push}!

Ramkumar Ramachandra — 2013-05-23T15:12:43

[7/7] is the meat.  Sorry it's in such a messy state: I was having a
field day tracing what push is actually doing.  Anyway, I wanted to
send out the series now to get early feedback.

In other news: why on earth is push doing _so_ much processing before
pushing?  Is it written very badly, or am I missing something?

Thanks.

(based on rr/die-on-missing-upstream)

Ramkumar Ramachandra (7):
  sha1_name: abstract upstream_mark() logic
  sha1_name: factor out die_no_upstream()
  sha1_name: remove upstream_mark()
  remote: expose parse_push_refspec()
  remote: expose get_ref_match()
  sha1_name: prepare to introduce AT_KIND_PUSH
  sha1_name: implement finding < at >{push}

 remote.c    |   4 +--
 remote.h    |   4 +++
 sha1_name.c | 111 ++++++++++++++++++++++++++++++++++++++++++++----------------
 3 files changed, 88 insertions(+), 31 deletions(-)

hello

2013-05-23T14:14:01

hello 

My names is Barrister Javier Gomez of CANALES & ASOCIADOS ABOGADOS SPAIN. I 
sent you a business proposal letter long time ago,but you have not respond to 
me, 
I am using this medium to remind you again, Please I would appreciate if you 
could confirm to 
me if you received the proposal letter please let me know through this Emails 
below: 

For further clarification reach me on this Private Email: gomezjavier322< at >yahoo.
es 


Best Regards, 
Mr.Javier Gomez.

[PATCH] git-send-email: another fix for special characters

Michael S. Tsirkin — 2013-05-23T14:13:52

When patch sender's name has special characters,
git send-email did not quote it before matching
against the author name.
As a result suppress_cc = self did not work:
sender is still Cc'd.

Fix by sanitizing before matching to patch author name.

Signed-off-by: Michael S. Tsirkin <mst< at >redhat.com>
---
 git-send-email.perl | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/git-send-email.perl b/git-send-email.perl
index c4dc438..a3fed7c 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
< at >< at > -1309,7 +1309,10 < at >< at > foreach my $t (< at >files) {
 elsif (/^From:\s+(.*)$/i) {
 ($author, $author_encoding) = unquote_rfc2047($1);
 next if $suppress_cc{'author'};
-next if $suppress_cc{'self'} and $author eq $sender;
+if ($suppress_cc{'self'}) {
+                                    my $sanitized_sender = sanitize_address($sender);
+                                    next if $author eq $sanitized_sender;
+                                }
 printf("(mbox) Adding cc: %s from line

[PATCH] git-send-email: fix handling of special characters

Michael S. Tsirkin — 2013-05-23T13:54:18

When patch sender's name has special characters,
git send-email did not quote it before matching
against the author name.
As a result it would produce mail like this:

Date: Thu, 23 May 2013 16:36:00 +0300
From: "Michael S. Tsirkin" <mst< at >redhat.com>
To: qemu-devel< at >nongnu.org
Cc: "Michael S. Tsirkin" <mst< at >redhat.com>
Subject: [PATCH 0/9] virtio: switch to linux headers
Message-Id: <1369316169-20181-1-git-send-email-mst< at >redhat.com>

From: "Michael S. Tsirkin" <mst< at >redhat.com>

Fix by sanitizing before matching to patch author name.

Signed-off-by: Michael S. Tsirkin <mst< at >redhat.com>
---
 git-send-email.perl | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/git-send-email.perl b/git-send-email.perl
index bd13cc8..c4dc438 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
< at >< at > -1400,7 +1400,8 < at >< at > foreach my $t (< at >files) {
 $subject = quote_subject($subject, $auto_8bit_encoding);
 }

-if (defined $author and $author ne $sender) {
+my $sanitized_sender = sanitize_address($sende

git hangs on pthread_join

Ian Kumlien — 2013-05-23T13:01:43

Hi,

I'm running a rather special configuration, basically i have a gerrit
server pushing
git data over openvpn connections (company regulations n' stuff)...

git 1.8.2.1 is started by xinetd
...
        port            = 9418
        socket_type     = stream
        wait            = no
        user            = gerrit2
        server          = /usr/bin/git
        server_args     =  daemon --inetd --syslog --export-all
--enable=receive-pack --init-timeout=3 --timeout=180 --base-path=<path>
...
        nice            = 10
        per_source      = UNLIMITED
        instances       = UNLIMITED
        flags           = KEEPALIVE NODELAY
---

Keepalive and nodelay has been added post fact, the same goes for the
timeouts.

I have found "git receive-pack"s that has been running for days/weeks
without terminating....

Attaching gdb and doing a trace results in:
#0  0x0000003261207b35 in pthread_join () from /lib64/libpthread.so.0
#1  0x00000000004ce58b in finish_async ()
#2  0x000000000045744b in cmd_receive_p

Bug report: git grep seems to use the wrong .gitattributes when invoked in a subdirectory

Joel Kaasinen — 2013-05-23T12:44:09

Greetings,

I bumped into a problem where git grep thinks files in repo/a/data are
binary files when it is invoked from repo/a and
repo/data/.gitattributes contains "* binary".

I can reproduce this on 1.7.9.5 and 1.7.10.4. Unfortunately I don't
have a newer version at hand.

How to reproduce:

[pseudo:~/tmp]% git --version
git version 1.7.10.4
[pseudo:~/tmp]% git init git-test
Initialized empty Git repository in /home/opqdonut/tmp/git-test/.git/
[pseudo:~/tmp]% cd git-test
[pseudo:~/tmp/git-test:master()]% mkdir -p a/data
[pseudo:~/tmp/git-test:master()]% mkdir data
[pseudo:~/tmp/git-test:master()]% echo '* binary' > data/.gitattributes
[pseudo:~/tmp/git-test:master()]% echo foo > a/data/foo
[pseudo:~/tmp/git-test:master()]% git add -A
[pseudo:~/tmp/git-test:master()]% git commit -m "foo"
[master (root-commit) 20fafbb] foo
 2 files changed, 1 insertion(+)
 create mode 100644 a/data/foo
 create mode 100644 data/.gitattributes
[pseudo:~/tmp/git-test:master()]% git grep foo
a/data/foo:foo
[pseudo:~/tmp/git-tes

push not resolving commit-ish?

Michael S. Tsirkin — 2013-05-23T10:53:10

Looks like push can't resolve tags to commits.
Why is that?

linux$ git push -f $PWD v3.10-rc2:refs/heads/vhost-next
error: Trying to write non-commit object
a8c6d53c4d84b3a5eb182758a9cdceceba4691da to branch refs/heads/vhost-next
To /scm/linux
 ! [remote rejected] v3.10-rc2 -> vhost-next (failed to write)
error: failed to push some refs to '/scm/linux'

linux$ git log v3.10-rc2|head -5
commit c7788792a5e7b0d5d7f96d0766b4cb6112d47d75
Author: Linus Torvalds <torvalds< at >linux-foundation.org>
Date:   Mon May 20 14:37:38 2013 -0700

    Linux 3.10-rc2


linux$ $ git push -f $PWD
c7788792a5e7b0d5d7f96d0766b4cb6112d47d75:refs/heads/vhost-next
Everything up-to-date

Bug when git rev-list options "--first-parent" and "--ancestry-path" are used together?

Michael Haggerty — 2013-05-23T10:07:04

It seems to me that

     git rev-list --first-parent --ancestry-path A..B

is well-defined and should list the commits in the intersection between

     git rev-list --first-parent                 A..B

and

     git rev-list                --ancestry-path A..B

But in many cases the first command doesn't provide any output even
though there are commits common to the output of the last two commands.

For example, take as an example the DAG from test t6019:

#          D---E-------F
#         /     \       \
#    B---C---G---H---I---J
#   /                     \
#  A-------K---------------L--M

(The merges are always downwards; e.g., the first parent of commit L is
K.)  The command

    git rev-list --first-parent --ancestry-path D..J

doesn't generate any output, whereas I would expect it to output "H I
J".  Similarly,

    git rev-list --first-parent --ancestry-path D..M

doesn't generate any output, whereas I would expect it to output "L M".

For fun, the attached script computes the output for all commit

We can have you as Plenary Speaker-Session Organizer (Code 24081926) in our parallel Conferences of Rhodes (Rodos) Island, Greece 2013.

Nikos Mastorakis — 2013-05-21T12:08:13

Dear Colleagues,

We can have you as Plenary Speaker-Session Organizer (Code 24081926) in our parallel Conferences of Rhodes (Rodos) Island, Greece 2013.
Please, select the most appropriate conference for you from the big list of our parallel Conferences: 
http://www.wseas.org
Plenary Speaker-Special Session Organizer must be at least Ph.D. Holder

We have this special policy:
--------------------------------
* We need from you a special session or a group of papers in the same conference
 (minimum number: 5 PAPERS and all of them must be presented and all these papers must be registered  with the very special discount fee 250 EUR /
paper)

* Upload these papers via the Web Site of the particular WSEAS Conference and then send us their ID numbers (ID numbers: You will have received them
by the system after uploading the papers) for the evaluation of the papers.

* All these arrangements (papers submission and registration) must finish before the announcement of the final program.

List of conferences: Rhodes

Your windows version has virus ?

Klavs Rommedahl — 2013-05-23T04:20:16

Hi.

  I just downloaded your Windows version, and got a virus attack, and a trojan.

  So sad to try "a new world" on the net, and then getting attacked. What to do ? Any clues ?

Sincerely
  A very very very disapointed - Klavs.

Ps : both McAfee, Symantec and Kaspersky find these attacks.

Sendt fra min iPhone--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

is it just me, or does --all ignore --no-tags?

Geoff Thorpe — 2013-05-22T21:16:14

I have some peculiar reasons for doing this, but nonetheless I don't
believe there's anything illegal here. I have a repo with a bunch of
remotes set up to pull in branches and tags from different places, and
I need all those branches and tags name-spaced. Eg. to illustrate, the
config looks something like;

[core]
        repositoryformatversion = 0
        filemode = true
        bare = true
[remote "foo"]
        url = git://some.address/foo
        fetch = +refs/heads/*:refs/remotes/foo/heads/*
        fetch = +refs/tags/*:refs/remotes/foo/tags/*
[remote "bar"]
        url = git://somewhere.else/bar
        fetch = +refs/heads/*:refs/remotes/bar/heads/*
        fetch = +refs/tags/*:refs/remotes/bar/tags/*

If I do "git fetch --no-tags foo && git fetch --no-tags bar",
everything's fine - all the branches and tags from "foo" sit under
refs/remotes/foo/{heads,tags}/, and similarly for "bar". OTOH, if I do
"git fetch --all --no-tags", it's as though the --no-tags wasn't
there. Inverting the argument order do

Remote branch can not be resolved as commit?

Kendall Shaw — 2013-05-22T14:29:14

I am trying to setup a repository for use inside the LAN, but I have 
been unable to checkout any branch so far. I am very new to git.

The repository is being served from gitblit over https. I have 
GIT_SSL_NO_VERIFY=true. The repository was created from git svn.

git ls-remote

shows the remote branches, e.g.:

... refs/remotes/2.0.3
... refs/remotes/trunk

git branch -r

shows none of the remote branches.

git checkout -b new-2.0.3 origin/2.0.3

produces:

fatal: git checkout: updating paths is incompatible with switching branches.
Did you intend to checkout 'origin/2.0.3' which can not be resolved as 
commit?

What does that mean?

I get the same result after each of these:

git fetch

git remote update
git fetch

git add remote stage-repo https://example.com:8443/git/blah-tools.git
git fetch stage-repo
git checkout -b new-2.0.3 stage-repo/2.0.3

Can you explain what the error message means, and what I am doing wrong?

Kendall

[PATCH] Geolocation support

Alessandro Di Marco — 2013-05-22T13:25:02

Hi all,

this is a hack I made a couple of years ago in order to store my current
location in git commits (I travel a lot and being able to associate a
place with the commit date helps me to quickly recover what were doing
at that time). Long story short, the screeenshot at
http://tinypic.com/r/wars40/5 shows the new gitk interface once this
patch has been integrated. Geolocation is controlled by two envvars
GIT_AUTHOR_PLACE and COMMITTER_PLACE, respectively. You can set them via
something like this:

function gitenv {
    DATA="`tail -n1 /etc/geotags.dat`"

    CITY="`echo \"$DATA\" | cut -d ',' -f 6 | sed -r 's/^\s+//'`"
    COUNTRY="`echo \"$DATA\" | cut -d ',' -f 5 | sed -r 's/^\s+//'`"
    LAT="`echo \"$DATA\" | cut -d ',' -f 2 | sed -r 's/^\s+//'`"
    LON="`echo \"$DATA\" | cut -d ',' -f 3 | sed -r 's/^\s+//'`"

    if [ -n "$CITY" ] ; then
export GIT_AUTHOR_PLACE="$CITY, $COUNTRY ($LAT, $LON)"
export GIT_COMMITTER_PLACE="$CITY, $COUNTRY ($LAT, $LON)"
    else
export GIT_AUTHOR_PLACE="$COUNTRY ($LA

first parent, commit graph layout, and pull merge direction

Andreas Krey — 2013-05-22T11:50:42

Hi everyone,

I'm just looking into better displays of the commit graph (as
displayed with gitk, smartgit, fisheye) - they tend to quickly
dissolve into a heap of spaghetti.

We had the idea that treating the first parent specially would
have some advantage here - including graphically indicating which
one of the parents of a commit is the first parent. (For instance,
by letting that line leave the commit node at the top/bottom,
and the other(s) to the side.)

A short trial showed that representing first parent chains as
straight lines in the graph does actually improve understandability,
as feature branches clearly stand out as separate lines even when
they no longer carry a branch name.

Does any GUI already do that (treat first parent specially),
or does anybody think of doing such? I don't quite dare to
jump into the gitk code yet.

Also, there is an implication with 'git pull': You'd expect the
master branch to be a first parent line, but when I do a small
thing directly on master and need to pull befor

[PATCH] push: document --no-verify

Michael S. Tsirkin — 2013-05-22T10:43:56

commit ec55559f937727bcb0fa8a3dfe6af68c188e968a added
--no-verify flag to git push, but didn't document it.
It's a useful flag when using pre-push hooks so
add the documentation.

Suggested-by: Thomas Rast <trast< at >inf.ethz.ch>
Cc: Aaron Schrab <aaron< at >schrab.com>
Signed-off-by: Michael S. Tsirkin <mst< at >redhat.com>
---
 Documentation/git-push.txt | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index d514813..346b28a 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
< at >< at > -11,7 +11,7 < at >< at > SYNOPSIS
 [verse]
 'git push' [--all | --mirror | --tags] [--follow-tags] [-n | --dry-run] [--receive-pack=<git-receive-pack>]
    [--repo=<repository>] [-f | --force] [--prune] [-v | --verbose] [-u | --set-upstream]
-   [<repository> [<refspec>...]]
+   [--no-verify]  [<repository> [<refspec>...]]
 
 DESCRIPTION
 -----------
< at >< at > -162,6 +162,11 < at >< at > useful if you write an alias or script around 'git push'.
 linkgit:git-pull[1] an

[PATCH v2 0/2] Fix invalid revision error messages

Ramkumar Ramachandra — 2013-05-22T10:39:53

As Junio pointed out in [0/2], this is not for 1.8.3; it's just a
regular "enhacement".

In [1/2], I've extended the commit message with the justification I
wrote out for Junio.

In [2/2], I've made sure to print the "correct" error message
everytime: I missed the detached HEAD case last time.  I'm not in
favor of anything "prettier", as I already explained in my email.

Thanks.

Ramkumar Ramachandra (2):
  sha1_name: fix error message for < at >{u}
  sha1_name: fix error message for < at >{<N>}, < at >{<date>}

 sha1_name.c                   | 23 +++++++++++++++++------
 t/t1507-rev-parse-upstream.sh | 15 +++++----------
 2 files changed, 22 insertions(+), 16 deletions(-)

[PATCH] Document push --no-verify

Thomas Rast — 2013-05-22T09:23:08

ec55559 (push: Add support for pre-push hooks, 2013-01-13) forgot to
add a note to git-push(1) about the new --no-verify option.

Signed-off-by: Thomas Rast <trast< at >inf.ethz.ch>
---

The insertion spot is at the end, because the existing ordering is
indistinguishable from random.  This should also be fixed, but is a
much bigger change and probably not suitable for an -rc period.


 Documentation/git-push.txt | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index d514813..426b3d2 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
< at >< at > -11,7 +11,7 < at >< at > SYNOPSIS
 [verse]
 'git push' [--all | --mirror | --tags] [--follow-tags] [-n | --dry-run] [--receive-pack=<git-receive-pack>]
    [--repo=<repository>] [-f | --force] [--prune] [-v | --verbose] [-u | --set-upstream]
-   [<repository> [<refspec>...]]
+   [--no-verify] [<repository> [<refspec>...]]
 
 DESCRIPTION
 -----------
< at >< at > -195,6 +195,9 < at >< at > useful if you write

[PATCH] guilt: fix date parsing

Theodore Ts'o — 2013-05-22T03:13:31

If the date field has a space in it, such as:

   Date: Tue, 14 May 2013 18:37:15 +0200

previously guilt would go belly up:

   + export GIT_AUTHOR_DATE=Tue, 14 May 2013 18:37:15 +0200
   /usr/local/bin/guilt: 571: export: 14: bad variable name

Fix this.

Signed-off-by: "Theodore Ts'o" <tytso< at >mit.edu>
---
 guilt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/guilt b/guilt
index 9953bdf..6e8d542 100755
--- a/guilt
+++ b/guilt
< at >< at > -568,7 +568,7 < at >< at > commit()
 author_date_str=`sed -n -e '/^Date:/ { s/^Date: //; p; q; }; /^(diff |---$|--- )/ q' "$p"`
 fi
 if [ ! -z "$author_date_str" ]; then
-export GIT_AUTHOR_DATE=`echo $author_date_str`
+export GIT_AUTHOR_DATE="$author_date_str"
 fi
 fi