* Re: [ANNOUNCE] Git 1.7.8.rc0
From: Stefan Naewe @ 2011-11-01 21:53 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20111101T205618-231@post.gmane.org>
Stefan Naewe <stefan.naewe <at> gmail.com> writes:
> I'll recheck everything at work, where I live behind a very restrictive
> firewall (Don't know if that makes any difference).
s/firewall/proxy/
Stefan
^ permalink raw reply
* [PATCH v3] Display change history as a diff between two dirs
From: Roland Kaufmann @ 2011-11-01 21:37 UTC (permalink / raw)
To: gitster; +Cc: git
Watching patches serially it can be difficult to get an overview of how
a pervasive change is distributed through-out different modules. Thus;
Extract snapshots of the files that have changed between two revisions
into temporary directories and launch a graphical tool to show the diff
between them.
Use existing functionality in git-diff to get the files themselves, and
git-difftool to launch the diff viewer.
Based on a script called 'git-diffc' by Nitin Gupta.
Signed-off-by: Roland Kaufmann <rlndkfmn+git@gmail.com>
---
Issues addressed in this revision are:
* Diff-viewer is searched for in order: env. var. GIT_EXTERNAL_TREEDIFF,
env. var. GIT_EXTERNAL_DIFF, conf. of git-difftool.
If dir. comp. is found useful, there should probably be some config
var. to control it too, but I think that will require some refactoring
of git-mergetool--lib.
* Only platforms where mktemp is known to exist (and have sane options)
are explicitly tested for; the default is to fallback to a Perl module
implementation which is heavier, but has a greater chance of working
I reckon (git-send-email uses this module).
* Less convoluted testing of empty directory.
contrib/dirdiff/README | 10 ++++
contrib/dirdiff/git-dirdiff--helper.sh | 37 ++++++++++++++++
contrib/dirdiff/git-dirdiff.sh | 72 ++++++++++++++++++++++++++++++++
contrib/dirdiff/git-dirdiff.txt | 71 +++++++++++++++++++++++++++++++
4 files changed, 190 insertions(+), 0 deletions(-)
create mode 100644 contrib/dirdiff/README
create mode 100755 contrib/dirdiff/git-dirdiff--helper.sh
create mode 100755 contrib/dirdiff/git-dirdiff.sh
create mode 100644 contrib/dirdiff/git-dirdiff.txt
diff --git a/contrib/dirdiff/README b/contrib/dirdiff/README
new file mode 100644
index 0000000..d06461a
--- /dev/null
+++ b/contrib/dirdiff/README
@@ -0,0 +1,10 @@
+# install on GNU, BSD:
+for f in "" "--helper"; do
+ b=git-dirdiff$f
+ sudo install -m 0755 contrib/dirdiff/$b.sh $(git --exec-path)/$b
+done
+
+# install on Windows
+for /f %a in ('git --exec-path') do set GIT_PATH=%a
+set GIT_PATH=%GIT_PATH:/=\%
+for %a in ("" "--helper") do copy contrib\dirdiff\git-dirdiff%~a.sh "%GIT_PATH%\%~a" /y
diff --git a/contrib/dirdiff/git-dirdiff--helper.sh b/contrib/dirdiff/git-dirdiff--helper.sh
new file mode 100755
index 0000000..8ff0124
--- /dev/null
+++ b/contrib/dirdiff/git-dirdiff--helper.sh
@@ -0,0 +1,37 @@
+#!/bin/sh
+#
+# Accumulate files in a changeset into a pre-defined directory.
+#
+# Copyright (C) 2011 Roland Kaufmann
+#
+# Based on a script called git-diffc by Nitin Gupta and valuable
+# suggestions by Junio C. Hamano.
+#
+# This file is licensed under the GPL v2, or a later version
+# at the discretion of the official Git maintainer.
+
+. git-sh-setup
+
+# check that we are called by git-dirdiff
+test -z "$__GIT_DIFF_DIR" &&
+ die Error: Do not call $(basename "$0") directly
+
+# what is the directory name of the file that has changed
+RELDIR=$(dirname "$1") ||
+ exit $?
+
+# don't attempt to copy new or removed files
+if test "$2" != "/dev/null"
+then
+ mkdir -p "$__GIT_DIFF_DIR/old/$RELDIR" ||
+ exit $?
+ cp "$2" "$__GIT_DIFF_DIR/old/$1" ||
+ exit $?
+fi
+if test "$5" != "/dev/null"
+then
+ mkdir -p "$__GIT_DIFF_DIR/new/$RELDIR" ||
+ exit $?
+ cp "$5" "$__GIT_DIFF_DIR/new/$1" ||
+ exit $?
+fi
diff --git a/contrib/dirdiff/git-dirdiff.sh b/contrib/dirdiff/git-dirdiff.sh
new file mode 100755
index 0000000..c5834ae
--- /dev/null
+++ b/contrib/dirdiff/git-dirdiff.sh
@@ -0,0 +1,72 @@
+#!/bin/sh
+#
+# Display differences between two commits with a directory comparison.
+#
+# Copyright (C) 2011 Roland Kaufmann
+#
+# Based on a script called git-diffc by Nitin Gupta and valuable
+# suggestions by Junio C. Hamano.
+#
+# This file is licensed under the GPL v2, or a later version
+# at the discretion of the official Git maintainer.
+
+. git-sh-setup
+
+# TMPDIR points to the designated space for temporary files; only if
+# not set use /tmp (MSYS even mounts %TEMP% to there)
+test -z "$TMPDIR" && TMPDIR=/tmp
+
+# create a temporary directory to hold snapshots of changed files
+# fallback on crippled platforms is to use a Perl module
+case $(uname -s) in
+Linux | *BSD | Darwin | windows* | CYGWIN_NT*)
+ __GIT_DIFF_DIR=$(mktemp -d "$TMPDIR/git-dirdiff.XXXXXX")
+ ;;
+*)
+ __GIT_DIFF_DIR=$(perl -e "use File::Temp qw/tempdir/; print tempdir(\"git-dirdiff.XXXXXX\", DIR=>\"$TMPDIR\")")
+ ;;
+esac
+test -d "$__GIT_DIFF_DIR" -a -w "$__GIT_DIFF_DIR" ||
+ die Error: Could not create a temporary subdir in $TMPDIR
+
+# cleanup after we're done
+trap 'rm -rf $__GIT_DIFF_DIR' 0
+
+# export this variable so that scripts called indirectly can access it
+export __GIT_DIFF_DIR
+
+# let the helper script accumulate all changed files into the temporary
+# directory letting 'git diff' do all the heavy lifting
+GIT_EXTERNAL_DIFF=git-dirdiff--helper git --no-pager diff "$@" ||
+ exit $?
+
+# first and second argument will always be the special directory links
+# if there are no hidden files nor regular files, then $3 will be the
+# second wildcard unexpanded
+isempty () {
+ set - $1/.* $1/*
+ test ! -f "$3"
+}
+
+# no-op if no files were changed
+isempty "$__GIT_DIFF_DIR/old" && isempty "$__GIT_DIFF_DIR/new" &&
+ exit 0
+
+# if a different tool is setup for tree comparison, launch that instead
+# if GIT_EXTERNAL_TREEDIFF is not set, then use GIT_EXTERNAL_DIFF
+if test -n "$GIT_EXTERNAL_DIFF"
+then
+ GIT_DIFFTOOL_EXTCMD=$GIT_EXTERNAL_DIFF
+ export GIT_DIFFTOOL_EXTCMD
+fi
+if test -n "$GIT_EXTERNAL_TREEDIFF"
+then
+ GIT_DIFFTOOL_EXTCMD=$GIT_EXTERNAL_TREEDIFF
+ export GIT_DIFFTOOL_EXTCMD
+fi
+
+# run original diff program, reckoning it will understand directories
+# modes and shas does not apply to the root directories so submit dummy
+# values for those, hoping that the diff tool does not use them.
+git-difftool--helper - "$__GIT_DIFF_DIR/old" deadbeef 0755 "$__GIT_DIFF_DIR/new" babeface 0755 ||
+ exit $?
diff --git a/contrib/dirdiff/git-dirdiff.txt b/contrib/dirdiff/git-dirdiff.txt
new file mode 100644
index 0000000..b80430a
--- /dev/null
+++ b/contrib/dirdiff/git-dirdiff.txt
@@ -0,0 +1,71 @@
+git-dirdiff(1)
+==============
+
+NAME
+----
+git-dirdiff - Show changes using directory compare
+
+SYNOPSIS
+--------
+[verse]
+'git dirdiff' [<options>] [<commit> [<commit>]] [--] [<path>...]
+
+DESCRIPTION
+-----------
+'git dirdiff' is a git command that allows you to compare revisions
+as a difference between two directories. 'git dirdiff' is a frontend
+to linkgit:git-diff[1].
+
+OPTIONS
+-------
+See linkgit:git-diff[1] for the list of supported options.
+
+ENVIRONMENT VARIABLES
+---------------------
+'GIT_EXTERNAL_TREEDIFF'::
+ When 'GIT_EXTERNAL_TREEDIFF' is set, the program named by it is
+ used as a diff viewer. The program must accept 7 parameters, where
+ parameter 2 is the path to a temporary directory containing the
+ "old" revision, and parameter 5 is the path of the "new" revision.
+ The other five parameters will only contain dummy values, and their
+ contents are subject to change.
+
+'GIT_EXTERNAL_DIFF'::
+ If and only if 'GIT_EXTERNAL_TREEDIFF' is not set, 'git dirdiff'
+ will use the contents of 'GIT_EXTERNAL_DIFF' as the name of the
+ diff viewer.
+
+CONFIG VARIABLES
+----------------
+If none of the above environment variables are set, 'git dirdiff' will
+use the same config variables as linkgit:git-difftool[1] to determine
+which difftool should be used.
+
+TEMPORARY FILES
+---------------
+'git dirdiff' creates a directory with 'mktemp' to hold snapshots of the
+files which are different in the two revisions. This directory is removed
+when the diff viewer terminates.
+
+NOTES
+-----
+The diff viewer must support being passed directories instead of files
+as its arguments.
++
+Files that are not put under version control are not included when
+viewing the difference between a revision and the working directory.
+
+SEE ALSO
+--------
+linkgit:git-diff[1]::
+ Show changes between commits, commit and working tree, etc
+
+linkgit:git-difftool[1]::
+ Show changes using common diff tools
+
+linkgit:git-config[1]::
+ Get and set repository or global options
+
+GIT
+---
+Part of the linkgit:git[1] suite
--
1.7.1
^ permalink raw reply related
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Linus Torvalds @ 2011-11-01 21:21 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, James Bottomley, Jeff Garzik, Andrew Morton, linux-ide, LKML
In-Reply-To: <7vwrbjlj5r.fsf@alter.siamese.dyndns.org>
On Tue, Nov 1, 2011 at 12:47 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> While I like the "an ephemeral tag is used only for hop-to-hop
> communication to carry information to be recorded in the resulting
> history" approach, I see a few downsides.
So I do agree.
I'd actually be *happier* with a generic multi-line "branch
description" thing that involves no git objects at all, just a nice
description of what the branch is.
The fact that you could also hide a signed version of the
top-of-branch there would be kind of a side effect, and wouldn't be a
requirement.
I hate how anonymous our branches are. Sure, we can use good names for
them, but it was a mistake to think we should describe the repository
(for gitweb), rather than the branch.
Ok, "hate" is a strong word. I don't "hate" it. I don't even think
it's a major design issue. But I do think that it would have been
nicer if we had had some branch description model.
The only reason I suggest a tag is really because it would fit with
existing tooling - especially the git transport protocol. So it's not
that I actually think that a tag is the right way to describe (and
sign) the branch, it's just that it's the way that wouldn't require
any changes other than in "git push -s" and "git pull".
> * To verify the commit C that was taken from the tip of lieutenant's tree
> some time ago, one has to find the merge commit that has C as a parent,
> and look at the merge commit. For example "git log --show-signature"
> would either show or not show the authenticity of C depending on where
> the traversal comes from. You certainly can implement it that way, but
> "some child describes an aspect of its parent, but not necessarily all
> children do so" feels philosophically less correct than "the commit has
> data to describe itself".
Yeah.
Having thought about it, I'm also not convinced I really want to
pollute the "git log" output with information that realistically
almost nobody cares about. The primary use is just for the person who
pulls things to verify it, after that the information is largely stale
and almost certain to never be interesting to anybody ever again. It's
*theoretically* useful if somebody wants to go back and re-verify, but
at the same time that really isn't expected to be the common case.
So I'm wondering if we want to save it at all. it's quite possible
that realistically speaking "google the mailing list archives" is the
*right* way to look up the signature if it is ever needed later.
Maybe just verifying the email message (with the suggested kind of
change to "git request-pull") is actually the right approach. And what
I should do is to just wrap my "git pull" in some script that I can
just cut-and-paste the gpg-signed thing into, and which just does the
"gpg --verify" on it, and then does the "git pull" after that.
Because in many ways, "git request-pull" is when you do want to sign
stuff. A developer might well want to push out his stuff for some
random internal testing (linux-next, for example), and then only later
decide "Ok, it was all good, now I want to make it 'official' and ask
Linus to pull it", and sign it at *that* time, rather than when
actually pushing it out.
And I suspect signing the pull request fits better into peoples
existing workflow anyway - sending out the email to ask the maintainer
to pull really is the "special event", rather than pushing out the
code itself.
Linus
^ permalink raw reply
* git sticker svg
From: Jeff King @ 2011-11-01 21:16 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 835 bytes --]
If you were at the GSoC mentor summit or the GitTogether last week, you
may seen Git stickers floating around. I printed 500, thinking there
would be some leftovers to distribute afterwards. But either git is very
popular, or somebody decided to re-wallpaper their bedroom, because we
ran out.
In case anybody wants to make their own git sticker (or whatever), I'm
providing the SVG that I sent to the printer. I ordered 2"x4" stickers,
but it's scalable, you should be able to do any size.
Credit where credit is due:
The logo is shamelessly stolen from one Sam Vilain made for GitTogether
t-shirts in 2008. It's really just the "---/+++" logo done in FreeMono
with a few pretty colors and outlines. I have no idea who did the
original "---/+++" logo. It's awesome, but I couldn't find a nice
scalable version, hence this.
-Peff
[-- Attachment #2: git-sticker.svg --]
[-- Type: image/svg+xml, Size: 4761 bytes --]
^ permalink raw reply
* Re: [msysGit] Re: [PATCHv2] Compile fix for MSVC
From: Junio C Hamano @ 2011-11-01 20:47 UTC (permalink / raw)
To: kusmabite
Cc: Junio C Hamano, Johannes Schindelin, Vincent van Ravesteijn, git,
ramsay, msysgit, Karsten Blees
In-Reply-To: <CABPQNSaiFpmHa_GLF8PaejvXTkqCMoWG+Cd4MbNrqXF-SXR1yw@mail.gmail.com>
Erik Faye-Lund <kusmabite@gmail.com> writes:
>> It seems, from your description, that msvc update series has some way to
>> go and it probably is better to be cooked by Windows-savvy folks for
>> another cycle.
>
> I don't think you need to hold these three patches; with them I was
> able to build your 'master'. I believe the problems I bumped into only
> exist in msysgit's 'devel' (or in your 'next', which msysgit/devel is
> based upon).
Ok, then. Thanks for clarifying.
^ permalink raw reply
* Re: [PATCH] git-svn: add hook to allow modifying the subversion commit message
From: Michael Lutz @ 2011-11-01 20:45 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20111101202806.GB29769@dcvr.yhbt.net>
Am 01.11.2011 21:28 schrieb Eric Wong:
> I'm not convinced this is a good feature to support. We already have
> --no-metadata to remove git-svn-id: lines and I hate that feature
> because it introduced extra variables for testing/debugging/recovery.
>
> Metadata in the commit message is important, if you want to remove
> it after-the-fact, there's git-filter-branch.
The actual use case here is to replace a custom hack that adds some info
to the git commit message. In this case filter-branch isn't an option
because git-svn continuously pulls from the subversion master repository.
Additionally, especially for *adding* information, the information might
not be available later any more.
The only current metadata (the git-svn-id line) isn't affected by this
change as git-svn outputs it separately after the svn commit message that
the proposed hook can modify.
I fully realize that this is a rather specialized feature but I wanted to
publish it in case somebody else finds a use for this as well.
Michael Lutz
^ permalink raw reply
* Re: Re: [PATCHv2] Compile fix for MSVC
From: Erik Faye-Lund @ 2011-11-01 20:43 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Vincent van Ravesteijn, git, ramsay, msysgit,
Karsten Blees
In-Reply-To: <alpine.DEB.1.00.1111011332400.32316@s15462909.onlinehome-server.info>
On Tue, Nov 1, 2011 at 7:40 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi kusma,
>
> On Tue, 1 Nov 2011, Erik Faye-Lund wrote:
>> I've applied the patches to 'devel', verified that the result builds,
>> and pushed it out.
>
> I've applied your patches and made up commit messages. So far, I only
> tested with MSVCE 9.0 (AKA Express 2008) before running out of time.
> Please have a look at the commits (since I could build a git.exe with the
> correct version, I felt comfortable enough to push out to 'devel').
The commits look good to me. Thanks for following up on it :)
> Maybe if someone donates Jenkins resources, we could make an automatic
> branch in the future that has git.sln in it (similar to the 'html' branch
> in git.git).
CloudBees seems to have some kind of a free Jenkins service. Perhaps
it's sufficient?
http://www.cloudbees.com/dev-pricing.cb
^ permalink raw reply
* Re: [msysGit] Re: [PATCHv2] Compile fix for MSVC
From: Erik Faye-Lund @ 2011-11-01 20:35 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Vincent van Ravesteijn, git, ramsay, msysgit,
Karsten Blees
In-Reply-To: <7vy5vzn65u.fsf@alter.siamese.dyndns.org>
On Tue, Nov 1, 2011 at 5:45 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Erik Faye-Lund <kusmabite@gmail.com> writes:
>
>> This is a slip-up in my patch 0f77dea, but I don't quite understand
>> why this didn't cause any troubles until now... I guess the MSVC parts
>> of Makefile are somehow more dependent on LIB_H or something...
>>
>> Junio, is it too late to squash in a fix-up? If it is, I can send a
>> fixup-patch instead...
>
> I can queue this for v1.7.8-rc1 if you want, as it is a fix whether or not
> we define MSVC or not while building.
Yes, please do. This looks good to me, thanks for picking it up :)
>> So there's some more work left to be done. Unfortunately, I don't have
>> time to polish these changes for at least a week, so unless someone
>> volunteers it'll take some time...
>
> It seems, from your description, that msvc update series has some way to
> go and it probably is better to be cooked by Windows-savvy folks for
> another cycle.
I don't think you need to hold these three patches; with them I was
able to build your 'master'. I believe the problems I bumped into only
exist in msysgit's 'devel' (or in your 'next', which msysgit/devel is
based upon).
> Which would mean that your upload-archive series is still
> good to go as long as it works for non-MSVC/mingw people, right?
>
Yes. Apart from the slip-up with LIB_H, my upload-archive series
should be unrelated to the issues I found here.
^ permalink raw reply
* Re: [PATCH] git-svn: add hook to allow modifying the subversion commit message
From: Eric Wong @ 2011-11-01 20:28 UTC (permalink / raw)
To: Michael Lutz; +Cc: git
In-Reply-To: <1319228708-9052-1-git-send-email-michi@icosahedron.de>
Michael Lutz <michi@icosahedron.de> wrote:
> Sometimes modifying the commit message git-svn creates for a subversion
> commit can be useful, for example if the original message contains meta
> information not needed in the git clone or information from svn properties
> should be stored visibly in the commit message.
>
> This change adds a hook 'git-svn-msg' analogue to the 'commit-msg' hook.
> Additionally to the commit message, the hook is passed the git-svn meta
> data by an environment variable.
I'm not convinced this is a good feature to support. We already have
--no-metadata to remove git-svn-id: lines and I hate that feature
because it introduced extra variables for testing/debugging/recovery.
Metadata in the commit message is important, if you want to remove
it after-the-fact, there's git-filter-branch.
When dealing with repositories that have been through several systems
(e.g. (CVS|Perforce) -> SVN -> git), it's useful to be able to refer to
old mailing list archives that only refer to the original system (since
neither SVN nor git existed at the time the email was sent).
^ permalink raw reply
* Re: [ANNOUNCE] Git 1.7.8.rc0
From: Stefan Naewe @ 2011-11-01 20:18 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20111101T205618-231@post.gmane.org>
Stefan Naewe <stefan.naewe <at> gmail.com> writes:
> Push with https works, if the URL looks e.g. like this:
>
> https://github.com/user/repo.git
>
> rather than this
>
> https://user <at> github.com/user/repo.git
>
> and having a ~/.netrc like this
>
> machine github.com login user password YouDontWantToKnow
>
> If the URL contains 'user@' I get the 'need ENTER' behaviour.
>
Another update:
If I revert deba493 the 'need ENTER' is gone and everything works as above.
Stefan
^ permalink raw reply
* Re: [ANNOUNCE] Git 1.7.8.rc0
From: Stefan Naewe @ 2011-11-01 20:06 UTC (permalink / raw)
To: git
In-Reply-To: <7vmxcfn23i.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster <at> pobox.com> writes:
>
> [administrivia: dropped the kernel mailing list from and added Peff to Cc]
>
> Stefan Näwe <stefan.naewe <at> atlas-elektronik.com> writes:
>
> >>> * HTTP transport did not use pushurl correctly, and also did not tell
> >>> what host it is trying to authenticate with when asking for
> >>> credentials.
> >>> (merge deba493 jk/http-auth later to maint).
> >>
> >> This seems to break pushing with https for me.
> >> It never uses values from my '~/.netrc'.
> >> I'll come up with a detailed scenario later.
> >
> > Update:
> >
> > git push prompts for the password but just pressing return succeeds.
> >
> > Weird...
>
> There are only handful of commits that even remotely touch http related
> codepath between v1.7.7 and v1.7.8-rc0:
>
> [...]
>
> Could you try reverting deba493 and retest, and then if the behaviour is
> the same "need ENTER", further revert 070b4dd and retest?
Did some tests again at my home machine with v1.7.8-rc0.
Push with https works, if the URL looks e.g. like this:
https://github.com/user/repo.git
rather than this
https://user@github.com/user/repo.git
and having a ~/.netrc like this
machine github.com login user password YouDontWantToKnow
If the URL contains 'user@' I get the 'need ENTER' behaviour.
I'll recheck everything at work, where I live behind a very restrictive
firewall (Don't know if that makes any difference).
Regards,
Stefan
^ permalink raw reply
* Re: Git is exploding
From: Junio C Hamano @ 2011-11-01 20:14 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Øyvind A. Holm, git
In-Reply-To: <vpqty6n1ybs.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> http://www.ohloh.net/p/compare?project_0=Git&project_1=Subversion&project_2=mercurial&submit_2=Go
> => Git has 2,659 users on ohloh, Subversion has 7,667 and Mercurial has
> 795.
Git costs $11M (6 years old) while Subversion costs $6.7M (11 years old)?
^ permalink raw reply
* Re: [PATCH] svn: Quote repository root in regex match
From: Eric Wong @ 2011-11-01 20:13 UTC (permalink / raw)
To: Ted Percival; +Cc: git
In-Reply-To: <1320100632-10058-1-git-send-email-ted.percival@quest.com>
Ted Percival <ted.percival@quest.com> wrote:
> Fixes a problem matching repository URLs, especially those with a '+' in
> the URL, such as svn+ssh:// URLs. Parts of the URL were interpreted as
> special characters by the regex matching.
>
> Signed-off-by: Ted Percival <ted.percival@quest.com>
Looks obviously correct to me, thanks
Acked-by: Eric Wong <normalperson@yhbt.net>
And pushed to master of git://bogomips.org/git-svn.git
(commit 0e7e30f5606b48a4c6d34bc99c6d680bb76d3fbc)
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Junio C Hamano @ 2011-11-01 19:47 UTC (permalink / raw)
To: Linus Torvalds
Cc: git, James Bottomley, Jeff Garzik, Andrew Morton, linux-ide, LKML
In-Reply-To: <CA+55aFwL_s=DcT46dprcYVWEAm_=WkuTV6K9dAn3wc_bDQU8vA@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> But what would be nice is that "git pull" would fetch the tag (based on
> name) *automatically*, and not actually create a tag in my repository at
> all. Instead, if would use the tag to check the signature, and - if we
> do this right - also use the tag contents to populate the merge commit
> message.
>
> In other words, no actual tag would ever be left around as a turd, it
> would simply be used as an automatic communication channel between the
> "git push -s" of the submitter and my subsequent "git pull". Neither
> side would have to do anything special, and the tag would never show
> up in any relevant tree (it could even be in a totally separate
> namespace like "refs/pullmarker/<branchname>" or something).
While I like the "an ephemeral tag is used only for hop-to-hop
communication to carry information to be recorded in the resulting
history" approach, I see a few downsides.
* The ephemeral tag needs to stay somewhere under refs/ hierarchy of the
lieutenant's tree until you pick it up, even if they are out of the way
in refs/pullmarker/$branchname. The next time the same lieutenant makes
a pull request, either it will be overwritten or multiple versions of
them refs/pullmarker/$branchname/$serial need to be kept.
- If the former, this makes forking of the project harder. Suppose a
pull request is made, you fetch and reject it. The lieutenant reworks
and makes another pull request. At this point the earlier signature
is gone. If somebody disagreed with your rejection and wanted to run
his tree with the initial version you rejected, his tree will not
carry the signature from the lieutenant.
- If the latter, then there needs to be a way to expire these pull
markers when they no longer are useful (i.e. the signature in it is
transcribed to a merge commit you create) [*1*]. But the party who
has power to clean them (i.e. the lieutenant who owns the repository)
is different from the party whose action determines when they no
longer are necessary (i.e. you). In practice this would lead to these
pull markers not cleaned at all [*2*].
* To verify the commit C that was taken from the tip of lieutenant's tree
some time ago, one has to find the merge commit that has C as a parent,
and look at the merge commit. For example "git log --show-signature"
would either show or not show the authenticity of C depending on where
the traversal comes from. You certainly can implement it that way, but
"some child describes an aspect of its parent, but not necessarily all
children do so" feels philosophically less correct than "the commit has
data to describe itself".
In your "ephemeral tag", the workflow for a developer (D) and his
integrator (U) would look like this, I think.
D$ until have something worth sending; do work; done
D$ git push -s
Enter passphrase: ...
- "push" internally creates a pull marker that signs the commit
object name this is pushing, among other things, and sends it
along the primary payload
D$ git pull-request; mail linus
U$ git pull
- "pull" notices the pull marker and fetches it as well;
- "pull" GPG validates the pull marker;
- When preparing a merge commit message, the contents of the
pull marker is included in .git/MERGE_MSG
The "in-commit signature" would give you 100% and your contributors 98% of
that, I think.
D$ until have something worth sending; do work; done
- The final round of reworking is concluded with "commit -S",
which would GPG sign the tip commit itself
D$ git push
- Nothing needs to change in the protocol nor "push" itself
D$ git pull-request; mail linus
U$ git pull
- "pull" GPG validates the tip commit
- Nothing unusual needs to happen to the resulting "merge" commit
And as a bonus, the code is already there ;-).
[Footnote]
*1* The common ancestor discovery in fetch uses as many refs as it can to
reduce the amount of data that needs to be transferred, and it is known to
hurt performance of the initial advertisement exchange when there are too
many useless refs.
*2* Do casual git users even know how to remove refs in a
remote/publishing repository?
^ permalink raw reply
* Re: [msysGit] Re: [PATCHv2] Compile fix for MSVC
From: Johannes Schindelin @ 2011-11-01 18:40 UTC (permalink / raw)
To: Erik Faye-Lund
Cc: Junio C Hamano, Vincent van Ravesteijn, git, ramsay, msysgit,
Karsten Blees
In-Reply-To: <CABPQNSaCRRRpEQPG1Mb4DovkMdQSBhHTm-i7y5M4iT+ndHX4XA@mail.gmail.com>
Hi kusma,
On Tue, 1 Nov 2011, Erik Faye-Lund wrote:
> On Tue, Nov 1, 2011 at 1:09 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>
> > On Mon, 31 Oct 2011, Junio C Hamano wrote:
> >
> >> Thanks. The patch looks good from a POSIX person's point of view, and
> >> I do not immediately see how this would break other variants of
> >> Windows build at least from the code inspection.
> >
> > As my virtual machine still ran the test suite after my latest
> > rebasing merge when I left work, I could not test the MSVC stuff just
> > yet. I wanted to do that tomorrow and either merge or come back with
> > suggestions.
>
> I've applied the patches to 'devel', verified that the result builds,
> and pushed it out.
I've applied your patches and made up commit messages. So far, I only
tested with MSVCE 9.0 (AKA Express 2008) before running out of time.
Please have a look at the commits (since I could build a git.exe with the
correct version, I felt comfortable enough to push out to 'devel').
Maybe if someone donates Jenkins resources, we could make an automatic
branch in the future that has git.sln in it (similar to the 'html' branch
in git.git).
Ciao,
Dscho
^ permalink raw reply
* Re: Git is exploding
From: Matthieu Moy @ 2011-11-01 18:39 UTC (permalink / raw)
To: Øyvind A. Holm; +Cc: git
In-Reply-To: <CAA787r=jeBv9moineaJVY=urYzEX+d7n23ED-txAGhLS+OPbmg@mail.gmail.com>
Øyvind A. Holm <sunny@sunbase.org> writes:
> Found an interesting "Popularity Contest" graph on debian.org (via
> Thomas Bassetto on G+):
>
> http://bit.ly/rNxVN0
Here are a few other interesting metrics:
http://www.ohloh.net/repositories/compare
=> around 1/4 of the repositories found are Git repositories. Subversion
has a bit more than half, and the last 1/4 is essentially CVS.
http://www.ohloh.net/p/compare?project_0=Git&project_1=Subversion&project_2=mercurial&submit_2=Go
=> Git has 2,659 users on ohloh, Subversion has 7,667 and Mercurial has
795.
From those numbers, centralized VCS are still dominant, but Git really
emerges among DVCS, and is not that far behind.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [ANNOUNCE] Git 1.7.8.rc0
From: Jeff King @ 2011-11-01 18:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stefan Näwe, git@vger.kernel.org
In-Reply-To: <7vmxcfn23i.fsf@alter.siamese.dyndns.org>
On Tue, Nov 01, 2011 at 11:12:49AM -0700, Junio C Hamano wrote:
> Stefan Näwe <stefan.naewe@atlas-elektronik.com> writes:
>
> >>> * HTTP transport did not use pushurl correctly, and also did not tell
> >>> what host it is trying to authenticate with when asking for
> >>> credentials.
> >>> (merge deba493 jk/http-auth later to maint).
> >>
> >> This seems to break pushing with https for me.
> >> It never uses values from my '~/.netrc'.
> >> I'll come up with a detailed scenario later.
> >
> > Update:
> >
> > git push prompts for the password but just pressing return succeeds.
> >
> > Weird...
>
> There are only handful of commits that even remotely touch http related
> codepath between v1.7.7 and v1.7.8-rc0:
>
> * deba493 http_init: accept separate URL parameter
>
> This could change the URL string given to http_auth_init().
>
> * 070b4dd http: use hostname in credential description
>
> This only changes the prompt string; as far as I understand it, the
> condition the password is prompted in the callsites of git_getpass()
> has not changed.
>
> * 6cdf022 remote-curl: Fix warning after HTTP failure
> * be22d92 http: avoid empty error messages for some curl errors
> * 8abc508 http: remove extra newline in error message
> * 8d677ed http: retry authentication failures for all http requests
> * 28d0c10 remote-curl: don't retry auth failures with dumb protocol
>
> These shouldn't affect anything wrt prompting, unless you are somehow
> internally reauthenticating.
>
> Could you try reverting deba493 and retest, and then if the behaviour is
> the same "need ENTER", further revert 070b4dd and retest?
I don't use .netrc, but with all of my patches (most of which aren't
even in what you are running), I tried not to affect the netrc case. I
just checked a few things, and it seems to be working as I expect. Do we
have a repeatable test?
-Peff
^ permalink raw reply
* Re: [PATCHv2 3/3] completion: match ctags symbol names in grep patterns
From: Junio C Hamano @ 2011-11-01 18:14 UTC (permalink / raw)
To: Jeff King; +Cc: SZEDER Gábor, git
In-Reply-To: <20111101152148.GA5552@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Yeah, that makes sense. Again, my inclination is to just leave that for
> a further patch if somebody really wants to make the completion (for
> this and any other positional slots) more accurate.
I tend to agree with your inclination. Let's go with the current simple
version and see if real users want something different.
^ permalink raw reply
* Re: [ANNOUNCE] Git 1.7.8.rc0
From: Junio C Hamano @ 2011-11-01 18:12 UTC (permalink / raw)
To: Stefan Näwe; +Cc: git@vger.kernel.org, Jeff King
In-Reply-To: <4EAFC18A.1070502@atlas-elektronik.com>
[administrivia: dropped the kernel mailing list from and added Peff to Cc]
Stefan Näwe <stefan.naewe@atlas-elektronik.com> writes:
>>> * HTTP transport did not use pushurl correctly, and also did not tell
>>> what host it is trying to authenticate with when asking for
>>> credentials.
>>> (merge deba493 jk/http-auth later to maint).
>>
>> This seems to break pushing with https for me.
>> It never uses values from my '~/.netrc'.
>> I'll come up with a detailed scenario later.
>
> Update:
>
> git push prompts for the password but just pressing return succeeds.
>
> Weird...
There are only handful of commits that even remotely touch http related
codepath between v1.7.7 and v1.7.8-rc0:
* deba493 http_init: accept separate URL parameter
This could change the URL string given to http_auth_init().
* 070b4dd http: use hostname in credential description
This only changes the prompt string; as far as I understand it, the
condition the password is prompted in the callsites of git_getpass()
has not changed.
* 6cdf022 remote-curl: Fix warning after HTTP failure
* be22d92 http: avoid empty error messages for some curl errors
* 8abc508 http: remove extra newline in error message
* 8d677ed http: retry authentication failures for all http requests
* 28d0c10 remote-curl: don't retry auth failures with dumb protocol
These shouldn't affect anything wrt prompting, unless you are somehow
internally reauthenticating.
Could you try reverting deba493 and retest, and then if the behaviour is
the same "need ENTER", further revert 070b4dd and retest?
^ permalink raw reply
* Re: [PATCH] Display change history as a diff between two dirs
From: Junio C Hamano @ 2011-11-01 17:15 UTC (permalink / raw)
To: Roland Kaufmann; +Cc: git
In-Reply-To: <CANEMaQRoXRygmrYsu0xF6mWq50r9Qhh-YuXXNAhyQewd+fDtsQ@mail.gmail.com>
Roland Kaufmann <rlndkfmn+git@gmail.com> writes:
> On Tue, Nov 1, 2011 at 04:49, Junio C Hamano <gitster@pobox.com> wrote:
>> Roland Kaufmann <rlndkfmn+git@gmail.com> writes:
>>> Would it be better to have yet another configuration available for
>>> this option instead of reusing the existing infrastructure for `git
>>> difftool`?
>
>> It probably is OK for "git diff --dirdiff" to use GIT_EXTERNAL_TREEDIFF if
>> and only if GIT_EXTERNAL_DIFF is not defined, and use GIT_EXTERNAL_DIFF
>> otherwise. People who have GIT_EXTERNAL_DIFF set to a tool capable of
>> handing directory pair can just add "--dirdiff" to the command line, and
>
> Did you perhaps mean the other way around: GIT_EXTERNAL_TREEDIFF
> if set, and GIT_EXTERNAL_DIFF otherwise?
I think I misstated the precedence order. What I had in mind was roughly
like this:
1. "git diff" (and others like "git log") without "--dirdiff" option:
GIT_EXTERNAL_DIFF is used just as before and no GIT_EXTERNAL_TREEDIFF
is consulted;
2. "git diff --dirdiff": GIT_EXTERNAL_TREEDIFF is used if set, otherwise
GIT_EXTERNAL_DIFF is used.
That way, people who have been using GIT_EXTERNAL_DIFF that is capable of
comparing two directories do not have to change anything and can just give
"--dirdiff" when they want to operate the command with this new mode of
comparison. People whose GIT_EXTERNAL_DIFF is not capable of comparing two
directories have two choices, but in either case they first would need to
find an external tool they want to use with the "--dirdiff" mode. If they
want to use the same new external tool for non "--dirdiff" mode, then they
can set GIT_EXTERNAL_DIFF to it. If they want to keep using the command
they have been using with GIT_EXTERNAL_DIFF when not in "--dirdiff" mode,
however, they can keep their GIT_EXTERNAL_DIFF to the old "two files
comparison" tool, and set GIT_EXTERNAL_TREEDIFF to the new one.
But that is all about envisioning how a proper integration of the feature
in the main "diff/log -p" command codepath would work. I do not know if it
is worth to add that to your script, which would be a stop-gap experiment
until we find out if the "populate two temporary directories and have a
tool compare them as a whole" mode is useful.
^ permalink raw reply
* Re: [msysGit] Re: [PATCHv2] Compile fix for MSVC
From: Junio C Hamano @ 2011-11-01 16:45 UTC (permalink / raw)
To: kusmabite
Cc: Johannes Schindelin, Vincent van Ravesteijn, git, ramsay, msysgit,
Karsten Blees
In-Reply-To: <CABPQNSaCRRRpEQPG1Mb4DovkMdQSBhHTm-i7y5M4iT+ndHX4XA@mail.gmail.com>
Erik Faye-Lund <kusmabite@gmail.com> writes:
> This is a slip-up in my patch 0f77dea, but I don't quite understand
> why this didn't cause any troubles until now... I guess the MSVC parts
> of Makefile are somehow more dependent on LIB_H or something...
>
> Junio, is it too late to squash in a fix-up? If it is, I can send a
> fixup-patch instead...
I can queue this for v1.7.8-rc1 if you want, as it is a fix whether or not
we define MSVC or not while building.
-- >8 --
From: Erik Faye-Lund <kusmabite@gmail.com>
Date: Tue, 1 Nov 2011 12:56:21 +0100
Subject: [PATCH] mingw: poll.h is no longer in sys/
Earlier we moved this header file in the code but forgot to
update the Makefile that refers to it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 4c09b35..ee34eab 100644
--- a/Makefile
+++ b/Makefile
@@ -515,7 +515,7 @@ LIB_H += compat/mingw.h
LIB_H += compat/obstack.h
LIB_H += compat/win32/pthread.h
LIB_H += compat/win32/syslog.h
-LIB_H += compat/win32/sys/poll.h
+LIB_H += compat/win32/poll.h
LIB_H += compat/win32/dirent.h
LIB_H += connected.h
LIB_H += csum-file.h
--
1.7.8.rc0.88.g45c5be
> Anyway, with that fix in place, it still breaks here:
> ...
> Again, this seems to be related to the poll-emulation... I see that
> these things are guarded by an "#if(_WIN32_WINNT >= 0x0600)" in
> <winsock2.h>, which means it's supported for Windows Vista and
> above... We still support Windows XP, so it seems someone has set this
> too high :)
> ...
> And THEN it compiles fine from 'devel'.
>
> So there's some more work left to be done. Unfortunately, I don't have
> time to polish these changes for at least a week, so unless someone
> volunteers it'll take some time...
It seems, from your description, that msvc update series has some way to
go and it probably is better to be cooked by Windows-savvy folks for
another cycle. Which would mean that your upload-archive series is still
good to go as long as it works for non-MSVC/mingw people, right?
^ permalink raw reply related
* Re: imap-send badly handles commit bodies beginning with "From <"
From: Jeff King @ 2011-11-01 16:14 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Magnus Bäck, git, Andrew Eikum
In-Reply-To: <4EB01918.8080604@alum.mit.edu>
On Tue, Nov 01, 2011 at 05:06:48PM +0100, Michael Haggerty wrote:
> On 11/01/2011 04:38 PM, Jeff King wrote:
> > Right. If you properly quote and unquote "From " lines, then mbox can be
> > unambiguous.
>
> That is not quite true. The RFC says only that lines matching "^From "
> should be quoted, not lines matching "^>From " (or, generally, "^>*From
> "). So the quoting is lossy; it is *not* possible to tell whether a
> line starting with ">From " should be unquoted (it could have been
> ">From " in the original).
That was what I meant by "properly". Note that the second link Magnus
mentioned (and which is referred to in the RFC in the paragraph
immediately following the discussion of "from" quoting) discusses this
explicitly.
The real issue with mbox is not that it can't be done well, but that you
have no clue which variant the writing end used. In practice, it works
OK because it's simple and those corner cases just don't come up much
(at least for a reasonably defensive reader).
-Peff
^ permalink raw reply
* Re: imap-send badly handles commit bodies beginning with "From <"
From: Michael Haggerty @ 2011-11-01 16:06 UTC (permalink / raw)
To: Jeff King; +Cc: Magnus Bäck, git, Andrew Eikum
In-Reply-To: <20111101153803.GB5552@sigill.intra.peff.net>
On 11/01/2011 04:38 PM, Jeff King wrote:
> Right. If you properly quote and unquote "From " lines, then mbox can be
> unambiguous.
That is not quite true. The RFC says only that lines matching "^From "
should be quoted, not lines matching "^>From " (or, generally, "^>*From
"). So the quoting is lossy; it is *not* possible to tell whether a
line starting with ">From " should be unquoted (it could have been
">From " in the original).
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: imap-send badly handles commit bodies beginning with "From <"
From: Jeff King @ 2011-11-01 15:38 UTC (permalink / raw)
To: Magnus Bäck; +Cc: git, Andrew Eikum
In-Reply-To: <20111030090111.GA1624@jpl.local>
On Sun, Oct 30, 2011 at 10:01:11AM +0100, Magnus Bäck wrote:
> > Mbox does have this problem, but I think in this case it is a
> > particularly crappy implementation of mbox in imap-send. Look at
> > imap-send.c:split_msg; it just looks for "From ".
>
> While there seems to be about a million different implementations of
> mbox creation and parsing, the relevant RFC[0] points to [1] as an
> authoritative source. The latter claims that lines matching "^From "
> denote a message boundary and that lines within a message that match
> the same pattern should be quoted with ">". That would suggest that
> the problem isn't imap-send.c but whatever code produces the mbox
> file in the first place. Of course, if that software isn't part of
> Git I guess we'll have to deal with the situation anyway. And whatever
> the RFCs say, we still need to be as compatible is possible with
> whatever software is out there.
Right. If you properly quote and unquote "From " lines, then mbox can be
unambiguous. But many pieces of software don't quote them (including
git, I think, but I didn't check), so it's prudent when reading to look
for something that actually appears to be a "From" line.
If somebody wants to tackle >From quoting of commit messages in
git-format-patch, they can certainly do so. In practice, it doesn't tend
to come up (because sane readers expect there to be a date at the end of
the line), so nobody has put forth the effort.
-Peff
^ permalink raw reply
* Re: [PATCHv2 3/3] completion: match ctags symbol names in grep patterns
From: Jeff King @ 2011-11-01 15:21 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: git
In-Reply-To: <20111029124755.GE2345@goldbirke>
On Sat, Oct 29, 2011 at 02:47:55PM +0200, SZEDER Gábor wrote:
> > Grep only looks in the current subdirectory for matches.
>
> Unless the user explicitly specifies the path(s)... But that comes at
> the end of the command line, so the completion script could have no
> idea about it at the time of 'git grep <TAB>'.
True. But that's a more general problem. You have a 'tags' file that
presumably represents the working tree. But you are not necessarily
grepping there. You might be grepping something related (e.g., what's in
the index), which makes the tags file still a good guess.
But you might also be grepping some totally unrelated branch, in which
case this is not helpful.
I tend to think that we are OK erring on the side of using the 'tags'
file, even if it might be wrong, since otherwise we have nothing to
tab-complete. When the user hits <Tab>, they are asking us to make our
best guess, and if they know there is nothing to complete, they won't
hit <Tab>. So it's not like we're hurting some existing workflow.
And in that sense, maybe we should just do the "search back up the
working tree" thing. Sure, it may be return way more matches than are
accurate, but even that's better than having no tab-completion at all.
> > You don't want __gitdir here, but rather "git rev-parse --show-cdup".
>
> Oh, yes, indeed.
>
> But there was a point in using __gitdir() here: it respects the
> --git-dir= option. Which brings up the question: what
> should 'git --git-dir=/some/where/.git grep <TAB>' offer?
I guess if core.worktree is set, it would look there instead (and ditto
for specifying --work-tree on the command line). Handling those is such
a corner case that I'm not too concerned if we don't. And if somebody
really cares, they can fix the completion later to pick up magic like
that from the early part of the command line. I don't see it as a
blocker for an initial version of the patch.
> _get_comp_words_by_ref() is a general completion function, the purpose
> of which is to provide a bash-version-independent equivalent of
> $COMP_WORDS and $COMP_CWORD by working around the different word
> splitting rules. It doesn't know about git and its commands at all.
>
> But there is the while loop in _git() that looks for the git command
> (among other things) on the command line, which could store the index
> of the command name in $words in a variable. This variable could then
> be used in that case statement (and probably in a couple of other
> places, too).
Yeah, that makes sense. Again, my inclination is to just leave that for
a further patch if somebody really wants to make the completion (for
this and any other positional slots) more accurate.
-Peff
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox