* Re: [PATCH 5/9 v2] Allow the built-in exec path to be relative to the command invocation path
From: Junio C Hamano @ 2008-07-24 4:21 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <200807232112.18352.johannes.sixt@telecom.at>
Johannes Sixt <johannes.sixt@telecom.at> writes:
> It also fixes 'make install' of git-gui as well (sigh!) by not exporting
> gitexecdir - assuming that Shawn applies the git-gui patch.
Yeah, this seems to break the install quite badly without git-gui patch.
If your PATH does not include the bindir you are installing the freshly
built git, then the Makefile in git-gui runs:
ifndef gitexecdir
gitexecdir := $(shell git --exec-path)
endif
and miserably fails. We can assume that somebody who builds and installs
git-gui as a standalone project already *has* an installed, working git on
$PATH, so the above ifndef is Ok, but when git-gui is built as part of
git.git tree, we really should avoid triggering that codepath.
^ permalink raw reply
* [PATCH] document that git-tag can tag more than heads
From: Jonathan Nieder @ 2008-07-24 5:01 UTC (permalink / raw)
To: git
After looking the git-tag manpage, someone on #git wondered how
to tag a commit that is not a branch head. This patch changes
the synopsis to say "<commit-ish> | <object>" instead of
"<head>" to address his question.
Samuel Bronson had the idea of putting "<commit-ish> | <object>"
for "<object>" because most tags point to commits (and for the
rest of the manpage, all tags point to commits).
Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
---
Documentation/git-tag.txt | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index b8dc88f..1ce1d7d 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -9,7 +9,8 @@ git-tag - Create, list, delete or verify a tag object signed with GPG
SYNOPSIS
--------
[verse]
-'git tag' [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>] <name> [<head>]
+'git tag' [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>]
+ <name> [<commit-ish> | <object>]
'git tag' -d <name>...
'git tag' [-n[<num>]] -l [<pattern>]
'git tag' -v <name>...
--
1.5.6.3.549.g8ca11
^ permalink raw reply related
* Re: [RFC] Git User's Survey 2008
From: david @ 2008-07-24 5:02 UTC (permalink / raw)
To: Stephan Beyer; +Cc: Jakub Narebski, Robin Rosenberg, Johannes Schindelin, git
In-Reply-To: <20080723235359.GB12754@leksak.fem-net>
On Thu, 24 Jul 2008, Stephan Beyer wrote:
> Hi,
>
> Jakub Narebski wrote:
>> Dnia ?roda 23. lipca 2008 16:54, Robin Rosenberg napisa?:
>>> onsdagen den 23 juli 2008 15.18.40 skrev Johannes Schindelin:
>>>> On Wed, 23 Jul 2008, Jakub Narebski wrote:
>>>>> On Wed, 23 Jul 2008, Johannes Schindelin wrote:
>>>>>> On Wed, 23 Jul 2008, Jakub Narebski wrote:
>>>>>>
>>>>>>> 04. Which programming languages you are proficient with?
>>>>>>> (The choices include programming languages used by git)
>>>>>>> (zero or more: multiple choice)
>>>>>>> - C, shell, Perl, Python, Tcl/Tk
>>>>>>> + (should we include other languages, like C++, Java, PHP,
>>>>>>> Ruby,...?)
> [...]
>>
>> The idea is, I think, to know what languages people could contribute
>> to Git; see analysis of this question at GitSurvey2007 page on git wiki:
>> http://git.or.cz/gitwiki/GitSurvey2007#head-ecb5564d71e4093e2e93e508380407a26dbcbdea
>
> Oha, is this a Git User's Survey or a Git Potential Contributor's Survey?
> I thought this is some kind of demographic question about the "programming
> background" of the user.
>
>> And of course "I am not programmer" response...
>
> This doesn't make sense, does it?
> I know that there are non-programmer's who use git for there
> configuration files and other non-programming track files, but
> this looks somehow wrong in this survey.
there are non-programmers who use git to track projects that they want to
be able to run the latest versions of. they don't program, just git pull;
make;make install
David Lang
^ permalink raw reply
* [PATCH] Document disabling core.whitespace values trailing-space and space-before-tab
From: "Peter Valdemar Mørch (Lists)" @ 2008-07-24 5:34 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1252 bytes --]
From http://article.gmane.org/gmane.comp.version-control.git/68146 I got
the syntax that works:
git config core.whitespace "-trailing-space"
Is it me, or is this not readable from git help config which says:
> A comma separated list of common whitespace problems to notice. git
> diff will use color.diff.whitespace to highlight them, and git apply
> --whitespace=error will consider them as errors:
>
> · trailing-space treats trailing whitespaces at the end of the line
> as an error (enabled by default).
The '-trailing-space' syntax to disable the trailing-space setting is
not obvious and not documented as far as I can see. I would have assumed
a value of '' would disable it.
Is there a documentation bug here? If so, I suggest this patch. I didn't
find anywhere else where the '-setting' syntax was used to disable
something.
My first-ever git patch is attached, because Thunderbird messes up due
to wrapping. I realize that SubmittingPatches has a mini-guide for
reconfiguring Thunderbird (ver 1!), but I really prefer not to have to
add extensions and reconfigure Thunderbird to send patches. (Comments to
this and how the patch was made are welcome and encouraged)
Peter
--
Peter Valdemar Mørch
http://www.morch.com
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Document-disabling-core.whitespace-values-trailing-s.patch --]
[-- Type: text/x-patch; name="0001-Document-disabling-core.whitespace-values-trailing-s.patch", Size: 1424 bytes --]
>From 900455ce5a4e8bf771aea2e3dbdbab38e440cdf4 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Peter=20Valdemar=20M=C3=B8rch?= <peter@morch.com>
Date: Thu, 24 Jul 2008 07:18:48 +0200
Subject: [PATCH] Document disabling core.whitespace values trailing-space and space-before-tab
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Peter Valdemar Mørch <peter@morch.com>
---
Documentation/config.txt | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index e784805..a198b3c 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -361,10 +361,12 @@ core.whitespace::
consider them as errors:
+
* `trailing-space` treats trailing whitespaces at the end of the line
- as an error (enabled by default).
+ as an error (enabled by default - disable with 'git config core.whitespace
+ "-trailing-space"').
* `space-before-tab` treats a space character that appears immediately
before a tab character in the initial indent part of the line as an
- error (enabled by default).
+ error (enabled by default - disable with 'git config core.whitespace
+ "-space-before-tab"').
* `indent-with-non-tab` treats a line that is indented with 8 or more
space characters as an error (not enabled by default).
* `cr-at-eol` treats a carriage-return at the end of line as
--
1.5.6
^ permalink raw reply related
* Re: [PATCH] t6030 (bisect): work around Mac OS X "ls"
From: Christian Couder @ 2008-07-24 5:57 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
In-Reply-To: <Pine.GSO.4.62.0807232014030.14945@harper.uchicago.edu>
Le jeudi 24 juillet 2008, Jonathan Nieder a écrit :
> t6030-bisect-porcelain.sh relies on "ls" exiting with nonzero
> status when asked to list nonexistent files. Unfortunately,
> /bin/ls on Mac OS X 10.3 exits with exit code 0. So use "echo
> <shell glob pattern>" and grep instead.
>
> Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
> ---
> With this change, all the non-git-svn tests pass on my machine.
> I think the fix is portable but I do not have the experience to
> be sure. So I would be happier if someone looks it over.
>
> t/t6030-bisect-porcelain.sh | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
> index 0626544..d19fc1c 100755
> --- a/t/t6030-bisect-porcelain.sh
> +++ b/t/t6030-bisect-porcelain.sh
> @@ -76,7 +76,7 @@ test_expect_success 'bisect fails if given any junk
> instead of revs' ' test_must_fail git bisect start foo $HASH1 -- &&
> test_must_fail git bisect start $HASH4 $HASH1 bar -- &&
> test -z "$(git for-each-ref "refs/bisect/*")" &&
> - test_must_fail ls .git/BISECT_* &&
> + echo .git/BISECT_* | test_must_fail grep BISECT_[^*] &&
Perhaps the following is simpler:
+ test -z "$(ls .git/BISECT_*)" &&
> git bisect start &&
> test_must_fail git bisect good foo $HASH1 &&
> test_must_fail git bisect good $HASH1 bar &&
Thanks,
Christian.
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute in "git add" even if core.autocrlf has not been set
From: Steffen Prohaska @ 2008-07-24 6:06 UTC (permalink / raw)
To: Dmitry Potapov, Johannes Schindelin; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <20080723114022.GP2925@dpotapov.dyndns.org>
On Jul 23, 2008, at 1:40 PM, Dmitry Potapov wrote:
> On Wed, Jul 23, 2008 at 07:49:20AM +0200, Steffen Prohaska wrote:
>>
>> On Jul 23, 2008, at 3:31 AM, Johannes Schindelin wrote:
>>
>>>
>>> - if ((action == CRLF_BINARY) || !auto_crlf || !len)
>>> + if ((action == CRLF_BINARY) || (!auto_crlf && action < 0) || !len)
>>
>> I think we should strictly follow the documentation, so this should
>> read
>>
>> + if ((action == CRLF_BINARY) || (!auto_crlf && action !=
>> CRLF_INPUT) || !len)
>
> Well, your expression is correct if we choose to strictly follow to
> what
> the current documentation says, but it is not well written in this
> place,
> and, more importantly, I don't see any use case where you would want
> to
> set crlf=input in .gitattributes, because it is shared among users on
> different platforms. What you want to specify in it is whether a
> file is
> text or binary. If crlf is set, it means a text file; if unset, it
> is a
> binary file. Regardless of what autocrlf value, I don't see why a text
> file should be checked in with CRs. So, Dscho's patch makes more sense
> to me. This requires correction to the documentation though:
Ok, this and Dscho's earlier mail convinced me. My patch does not
make sense at all. I should have had thought a bit harder ;-)
I have however a related question:
Dscho,
Is the following your use case?
"I am the maintainer of this project. I know that this project needs
crlf conversion, because it is a cross-platform project. Therefore,
I want to force crlf conversion for this specific project, even if
the user did not configure core.autocrlf=input on Unix."
Your patch provides a solution, though not a very comfortable one. With
your patch applied, you could explicitly list all files (or filetypes)
that are text and mark them with 'crlf'. Git would not let CRLFs enter
the repository for these files. You could also specify 'crlf=input',
but I don't understand why you want to specify this. Anyway, you would
need to explicitly list all text filetypes and explicitly *not list* the
binary filetypes because they must not be converted. This is no very
comfortable, no?
I think what you really want to do is to tell git that the *automatic*
crlf detection shall be used for all files of your specific project,
even if the user did not configure core.autocrlf=input. This would
avoid listing each filetype separately.
Maybe we could allow 'crlf=guess' in .gitattributes with the following
documentation:
-- 8< --
Set to string value "guess"::
Setting `guess` tells git to apply conversion upon checkin
if the file content looks like text. On checkout, however,
git applies the conversion specified in `core.autocrlf`.
Setting `guess` can be useful to force automatic file type
detection for a specific project.
-- >8 --
> diff --git a/Documentation/gitattributes.txt b/Documentation/
> gitattributes.txt
> index d7b4114..448857b 100644
> --- a/Documentation/gitattributes.txt
> +++ b/Documentation/gitattributes.txt
> @@ -99,9 +99,9 @@ This attribute controls the line-ending convention.
> Set::
>
> Setting the `crlf` attribute on a path is meant to mark
> - the path as a "text" file. 'core.autocrlf' conversion
> - takes place without guessing the content type by
> - inspection.
> + the path as a "text" file. Line endings in a text file
> + are converted to LF upon checkin, and if 'core.autocrlf'
> + is true then to CRLF upon checkout.
>
> Unset::
Makes sense.
Steffen
^ permalink raw reply
* Re: [PATCH] t6030 (bisect): work around Mac OS X "ls"
From: Mike Hommey @ 2008-07-24 6:06 UTC (permalink / raw)
To: Christian Couder; +Cc: Jonathan Nieder, git
In-Reply-To: <200807240757.26290.chriscool@tuxfamily.org>
On Thu, Jul 24, 2008 at 07:57:26AM +0200, Christian Couder wrote:
> Le jeudi 24 juillet 2008, Jonathan Nieder a écrit :
> > t6030-bisect-porcelain.sh relies on "ls" exiting with nonzero
> > status when asked to list nonexistent files. Unfortunately,
> > /bin/ls on Mac OS X 10.3 exits with exit code 0. So use "echo
> > <shell glob pattern>" and grep instead.
> >
> > Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
> > ---
> > With this change, all the non-git-svn tests pass on my machine.
> > I think the fix is portable but I do not have the experience to
> > be sure. So I would be happier if someone looks it over.
> >
> > t/t6030-bisect-porcelain.sh | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
> > index 0626544..d19fc1c 100755
> > --- a/t/t6030-bisect-porcelain.sh
> > +++ b/t/t6030-bisect-porcelain.sh
> > @@ -76,7 +76,7 @@ test_expect_success 'bisect fails if given any junk
> > instead of revs' ' test_must_fail git bisect start foo $HASH1 -- &&
> > test_must_fail git bisect start $HASH4 $HASH1 bar -- &&
> > test -z "$(git for-each-ref "refs/bisect/*")" &&
> > - test_must_fail ls .git/BISECT_* &&
> > + echo .git/BISECT_* | test_must_fail grep BISECT_[^*] &&
>
> Perhaps the following is simpler:
>
> + test -z "$(ls .git/BISECT_*)" &&
That is still a useless use of ls ;)
Mike
^ permalink raw reply
* Re: [PATCH] Preserve cwd in setup_git_directory()
From: Johannes Sixt @ 2008-07-24 6:50 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: git, Johannes Schindelin, Geoff Russell
In-Reply-To: <20080724031441.GA26072@laptop>
Nguyễn Thái Ngọc Duy schrieb:
> --- a/setup.c
> +++ b/setup.c
> @@ -577,10 +577,14 @@ const char *setup_git_directory(void)
> /* If the work tree is not the default one, recompute prefix */
> if (inside_work_tree < 0) {
> static char buffer[PATH_MAX + 1];
> + static char cwd[PATH_MAX + 1];
> char *rel;
> + getcwd(cwd, PATH_MAX);
This needs an error check.
-- Hannes
^ permalink raw reply
* Re: git status in clean working dir
From: Ask Bjørn Hansen @ 2008-07-24 6:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git, David Bremner
In-Reply-To: <7vtzeir68z.fsf@gitster.siamese.dyndns.org>
On Jul 21, 2008, at 19:40, Junio C Hamano wrote:
> (2) Then why are we even allowing to configure the plumbing to page?
I don't have an opinion on the the appropriateness of paging various
commands, but to solve the problem of scripts getting tripped up by
the paging, couldn't the plumping check if STDOUT is a tty and only do
the paging if so?
(In Perl "page_output(...) if $pager_configured and -t STDOUT")
- ask
--
http://develooper.com/ - http://askask.com/
^ permalink raw reply
* BUG: fetch incorrect interpretation of globing patterns in refspecs
From: marc zonzon @ 2008-07-24 7:07 UTC (permalink / raw)
To: git
Helo
I have a repository repo1 with four branches b_first, b_second,
b/third, b/fourth.
In a repository repo2 I put a remote config with: fetch =
+refs/heads/b/*:refs/remotes/b/* and I expect a fetch to apply to both
b/third and b/fourth.
But fetch will also catch b_first and b_second even if they don't
match the globing pattern.
I give the full script to reproduce the bug.
Marc
---------------------------------------------------------------------------------
Script started on Thu 24 Jul 2008 08:23:26 AM CEST
$ mkdir repo1
$ cd repo1
$ git init
Initialized empty Git repository in /shared/home/marc/gits/testbed/repo1/.git/
$ echo "master branch" > README
$ git add README
$ git commit README -m'initial commit in master'
Created initial commit 9ebc74c: initial commit in master
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 README
$ git checkout -b b_first
Switched to a new branch "b_first"
$ echo "branch b_first" >| README
$ git add README
$ git commit README -m'commit in b_first'
Created commit 40d985a: commit in b_first
1 files changed, 1 insertions(+), 1 deletions(-)
$ git checkout -b b_second
Switched to a new branch "b_second"
$ echo "branch b_second" >| README
$ git add README
$ git commit README -m'commit in b_second'
Created commit 661fe61: commit in b_second
1 files changed, 1 insertions(+), 1 deletions(-)
$ git checkout -b b/third master
Switched to a new branch "b/third"
$ echo "branch b/third" >| README
$ git add README
$ git commit README -m'commit in b/third'
Created commit 4f02216: commit in b/third
1 files changed, 1 insertions(+), 1 deletions(-)
$ git checkout -b b/fourth master
Switched to a new branch "b/fourth"
$ echo "branch b/fourth" >| README
$ git add README
$ git commit README -m'commit in b/fourth'
Created commit 068f9da: commit in b/fourth
1 files changed, 1 insertions(+), 1 deletions(-)
$ cd ..
$ mkdir repo2
$ cd repo2
$ git init
Initialized empty Git repository in /shared/home/marc/gits/testbed/repo2/.git/
$ git config --add remote.repo1.url ../repo1
$ git config --add remote.repo1.fetch '+refs/heads/b/*:refs/remotes/b/*'
$ git fetch -v repo1
warning: no common commits
remote: Counting objects: 15, done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 15 (delta 2), reused 0 (delta 0)
Unpacking objects: 100% (15/15), done.
From ../repo1
* [new branch] b/fourth -> b/fourth
* [new branch] b/third -> b/third
* [new branch] b_first -> b_first
* [new branch] b_second -> b_second
^ permalink raw reply
* Re: [PATCH] builtin-branch.c: optimize --merged and --no-merged
From: Lars Hjemli @ 2008-07-24 7:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ingo Molnar, SZEDER Gábor, git
In-Reply-To: <7vtzeg9rhh.fsf_-_@gitster.siamese.dyndns.org>
On Thu, Jul 24, 2008 at 12:15 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Instead, we can let the revision machinery traverse the history as if we
> are running:
>
> $ git rev-list --branches --not $commit
>
> by queueing the tips of branches we encounter as positive refs (this
> mimicks the "--branches" option in the above command line) and then
> appending the merge_filter_ref commit as a negative one, and finally
> calling prepare_revision_walk() to limit the list..
Nice.
> @@ -213,6 +211,7 @@ static int append_ref(const char *refname, const unsigned char *sha1, int flags,
> {
> struct ref_list *ref_list = (struct ref_list*)(cb_data);
> struct ref_item *newitem;
> + struct commit *commit;
> int kind;
> int len;
> static struct commit_list branch;
I think you can drop the 'branch' here.
> @@ -239,12 +242,8 @@ static int append_ref(const char *refname, const unsigned char *sha1, int flags,
> branch.item = lookup_commit_reference_gently(sha1, 1);
> if (!branch.item)
> die("Unable to lookup tip of branch %s", refname);
..and here.
- if (merge_filter == SHOW_NOT_MERGED &&
- has_commit(merge_filter_ref, &branch))
- return 0;
- if (merge_filter == SHOW_MERGED &&
- !has_commit(merge_filter_ref, &branch))
- return 0;
+ add_pending_object(&ref_list->revs,
+ (struct object *)branch.item, refname);
..and use 'commit' instead of 'branch.item' here.
> @@ -305,7 +304,13 @@ static void print_ref_item(struct ref_item *item, int maxwidth, int verbose,
> {
> char c;
> int color;
> - struct commit *commit;
> + struct commit *commit = item->commit;
> +
> + if (merge_filter != NO_FILTER) {
> + int is_merged = !!(item->commit->object.flags & UNINTERESTING);
> + if (is_merged != (merge_filter == SHOW_MERGED))
> + return;
> + }
A possible issue here is that `git branch -v --[no]-merged` might use
a wrong maxwidth, but I'm not sure if it's even worth fixing.
Thanks for cleaning up my mess.
--
larsh
^ permalink raw reply
* Re: [PATCH] In perforce, RCS keywords are case-sensitive
From: Simon Hausmann @ 2008-07-24 7:05 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git, Junio C Hamano
In-Reply-To: <alpine.LNX.1.00.0807221235000.19665@iabervon.org>
On Tuesday 22 July 2008 18:48:57 Daniel Barkalow wrote:
> At least, this is true in 2007.2, according to the documentation.
>
> Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Acked-By: Simon Hausmann <simon@lst.de>
Thanks,
Simon
> A line of perl with the variable $file in a string followed by a different
> variable not in the string, for example, doesn't get mangled by p4 and may
> therefore appear in a p4 depot.
>
> I don't know if the "old-style keyword expansion" is case-sensitive,
> though, so I'm leaving that alone.
>
> contrib/fast-import/git-p4 | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
> index d8de9f6..1ee612e 100755
> --- a/contrib/fast-import/git-p4
> +++ b/contrib/fast-import/git-p4
> @@ -902,7 +902,7 @@ class P4Sync(Command):
> if stat['type'] in ('text+ko', 'unicode+ko', 'binary+ko'):
> text = re.sub(r'(?i)\$(Id|Header):[^$]*\$',r'$\1$', text)
> elif stat['type'] in ('text+k', 'ktext', 'kxtext',
> 'unicode+k', 'binary+k'): - text =
> re.sub(r'(?i)\$(Id|Header|Author|Date|DateTime|Change|File|Revision):[^$]*\
>$',r'$\1$', text) + text =
> re.sub(r'\$(Id|Header|Author|Date|DateTime|Change|File|Revision):[^$]*\$',r
>'$\1$', text)
>
> contents[stat['depotFile']] = text
^ permalink raw reply
* [PATCH v2] t6030 (bisect): work around Mac OS X "ls"
From: Jonathan Nieder @ 2008-07-24 7:43 UTC (permalink / raw)
To: Mike Hommey; +Cc: Christian Couder, git
In-Reply-To: <20080724060647.GA24587@glandium.org>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 1513 bytes --]
t6030-bisect-porcelain.sh relies on "ls" exiting with nonzero
status when asked to list nonexistent files. Unfortunately,
/bin/ls on Mac OS X 10.3 exits with exit code 0. So look at
its output instead.
Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
---
Mike Hommey wrote:
> On Thu, Jul 24, 2008 at 07:57:26AM +0200, Christian Couder wrote:
>> Le jeudi 24 juillet 2008, Jonathan Nieder a écrit :
>>> - test_must_fail ls .git/BISECT_* &&
>>> + echo .git/BISECT_* | test_must_fail grep BISECT_[^*] &&
>>
>> Perhaps the following is simpler:
>>
>> + test -z "$(ls .git/BISECT_*)" &&
>
> That is still a useless use of ls ;)
It is much better than what I wrote, at least.
Good night (well, good morning I guess), and thanks.
t/t6030-bisect-porcelain.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
index 0626544..244fda6 100755
--- a/t/t6030-bisect-porcelain.sh
+++ b/t/t6030-bisect-porcelain.sh
@@ -76,7 +76,7 @@ test_expect_success 'bisect fails if given any junk instead of revs' '
test_must_fail git bisect start foo $HASH1 -- &&
test_must_fail git bisect start $HASH4 $HASH1 bar -- &&
test -z "$(git for-each-ref "refs/bisect/*")" &&
- test_must_fail ls .git/BISECT_* &&
+ test -z "$(ls .git/BISECT_* 2>/dev/null)" &&
git bisect start &&
test_must_fail git bisect good foo $HASH1 &&
test_must_fail git bisect good $HASH1 bar &&
--
1.5.6.3.549.g8ca11
^ permalink raw reply related
* [PATCH] Preserve cwd in setup_git_directory()
From: Nguyen Thai Ngoc Duy @ 2008-07-24 8:12 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Johannes Schindelin, Geoff Russell
In-Reply-To: <48882628.7030305@viscovery.net>
When GIT_DIR is not set, cwd is used to determine where .git is.
If core.worktree is set, setup_git_directory() needs to jump back
to the original cwd in order to setup worktree, this leads to
incorrect .git location later in setup_work_tree().
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
On Thu, Jul 24, 2008 at 08:50:16AM +0200, Johannes Sixt wrote:
> Nguyễn Thái Ngọc Duy schrieb:
> > --- a/setup.c
> > +++ b/setup.c
> > @@ -577,10 +577,14 @@ const char *setup_git_directory(void)
> > /* If the work tree is not the default one, recompute prefix */
> > if (inside_work_tree < 0) {
> > static char buffer[PATH_MAX + 1];
> > + static char cwd[PATH_MAX + 1];
> > char *rel;
> > + getcwd(cwd, PATH_MAX);
>
> This needs an error check.
Check added.
setup.c | 5 +++++
t/t1501-worktree.sh | 13 ++++++++++++-
2 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/setup.c b/setup.c
index 6cf9094..fa1d696 100644
--- a/setup.c
+++ b/setup.c
@@ -577,10 +577,15 @@ const char *setup_git_directory(void)
/* If the work tree is not the default one, recompute prefix */
if (inside_work_tree < 0) {
static char buffer[PATH_MAX + 1];
+ static char cwd[PATH_MAX + 1];
char *rel;
+ if (!getcwd(cwd, PATH_MAX))
+ die ("Could not get the current working directory");
if (retval && chdir(retval))
die ("Could not jump back into original cwd");
rel = get_relative_cwd(buffer, PATH_MAX, get_git_work_tree());
+ if (retval && chdir(cwd))
+ die ("Could not jump back into original cwd");
return rel && *rel ? strcat(rel, "/") : NULL;
}
diff --git a/t/t1501-worktree.sh b/t/t1501-worktree.sh
index 2ee88d8..d53d66a 100755
--- a/t/t1501-worktree.sh
+++ b/t/t1501-worktree.sh
@@ -29,7 +29,18 @@ test_rev_parse() {
}
mkdir -p work/sub/dir || exit 1
-mv .git repo.git || exit 1
+
+git config core.worktree "$(pwd)"/work
+mv .git work || exit 1
+test_expect_success '--git-dir with relative .git' '
+ (
+ MYPWD="$(pwd)"
+ cd work/sub/dir &&
+ test "$MYPWD"/work/.git = "$(git rev-parse --git-dir)"
+ )
+'
+
+mv work/.git repo.git || exit 1
say "core.worktree = relative path"
GIT_DIR=repo.git
--
1.5.5.GIT
^ permalink raw reply related
* Re: [RFC] Git User's Survey 2008
From: Jakub Narebski @ 2008-07-24 8:15 UTC (permalink / raw)
To: Alex Riesen; +Cc: Johannes Schindelin, git
In-Reply-To: <20080723171745.GC5283@blimp.local>
On Wed, 23 Jul 2008, Alex Riesen wrote:
> Johannes Schindelin, Wed, Jul 23, 2008 11:53:27 +0200:
> > >
> > > 19. How do you publish/propagate your changes?
> > > (zero or more: multiple choice)
> > > - push, pull request, format-patch + email, bundle, other
> >
> > git svn
> >
>
> a converter using fast-import/fast-export/plumbing
So it would be now:
19. How do you publish/propagate your changes?
(zero or more: multiple choice)
- push, git-svn, foreign SCM (not via git-svn), pull request,
format-patch + email, bundle, other(*)
+ (*)If the way you publish your changes is not on above list,
please explain how do you publish your changes.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Jakub Narebski @ 2008-07-24 8:24 UTC (permalink / raw)
To: Stephan Beyer; +Cc: Dmitry Potapov, Johannes Schindelin, git
In-Reply-To: <20080723170120.GC17648@leksak.fem-net>
On Wed, 23 July 2008, Stephan Beyer wrote:
> Dmitry Potapov wrote:
>> On Wed, Jul 23, 2008 at 11:53:27AM +0200, Johannes Schindelin wrote:
>>> On Wed, 23 Jul 2008, Jakub Narebski wrote:
>>>>
>>>> 11. Why did you choose Git? (if you use Git)
>>>> What do you like about using Git?
>>>> (free form, not to be tabulated)
>>>
>>> Again, to avoid hassles with free-form:
>>>
>>> Mandatory: work, mandatory: open source project I am participating
>>> in, speed, scalability, It's What Linus Uses, Other.
>>
>> If we move away from free-form, it should be much more choices here.
>>
>> - Ability to work offline
>> - Cryptographic authentication of history.
>> - Distributed development (pull/push from/to more than one remote repo)
>> - Easy to extend functionality through scripting
>> - Efficient storage model
>> - Elegant design
>> - Fast
>> - Good community support
>> - Rewriting patches before publishing (git rebase, commit --amend)
>> - Scalability (Efficient handling of large projects)
>> - Strong support for non-linear development
>> - Support of wide range of protocols for synchronization.
>> ...
>
> Heh, I can imagine git users reading that survey and thinking
> "What? Git allows me to rewrite patches before publishing?
> And it provides cryptographic integrity? Sounds good. *click*"
>
> Nevertheless, the list is fine ;)
> Perhaps also: "Good reputation".
Perhaps also: "Because it is popular (hype)", and I hope that
"Ability to track code movement" would have any takers. Although
it is hard to distinguish between 'reasons to choose' and 'favourite
features' list; let's make it more 'reasons to choose' (like "feature
rich").
"Good documentation", perhaps, too?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFC PATCH 00/12] Sparse checkout
From: Nguyen Thai Ngoc Duy @ 2008-07-24 8:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807231753240.8986@racer>
On 7/23/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
>
> On Wed, 23 Jul 2008, Nguyen Thai Ngoc Duy wrote:
>
> > On 7/23/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
>
> > > On Wed, 23 Jul 2008, Nguyen Thai Ngoc Duy wrote:
> > >
> > > > So in short, sparse prefix will be stored in config,
> > > > core.sparsecheckout.
> > >
> > > Do you really think the prefix should be stored anywhere else than the
> > > index?
> > >
> > > With core.sparseCheckout you have to introduce a _sh*tload_ of config
> > > loaders.
> > >
> > > And with core.sparseCheckout you are at the whim of the user, since
> > > .git/config is _supposed_ to be user-editable.
> > >
> > > From a logical point of view, I'd say that the sparse prefix has
> > > nothing to do with the "configuration" of the local repository.
> >
> > Well, whatever place. I chose .git/config because I did not want to
> > introduce a new config place. But then how about .git/sparsecheckout?
>
>
> No, I did mean the index. This is an attribute of the index: either it is
> sparsely checked out or not. You can even have multiple indices
> (switching between them by setting GIT_INDEX_FILE) which have different
> prefixes.
I don't think so. It's a mask for workdir, right? If you save it it
index, you can switch index and the prefix as well, but workdir only
has several subtrees that do not fit any other prefix than the
original prefix.
> Ciao,
> Dscho "who seems to recall that the first series was much less intrusive"
The first series only took care of index, so yes it's simpler.
--
Duy
^ permalink raw reply
* Re: [PATCH] Document disabling core.whitespace values trailing-space and space-before-tab
From: Nanako Shiraishi @ 2008-07-24 8:29 UTC (permalink / raw)
To: "Peter Valdemar Mørch (Lists)"; +Cc: git
In-Reply-To: <4888144E.8090300@sneakemail.com>
Quoting "Peter Valdemar Mrch (Lists)" <4ux6as402@sneakemail.com>:
> The '-trailing-space' syntax to disable the trailing-space setting is
> not obvious and not documented as far as I can see. I would have
> assumed a value of '' would disable it.
>
> Is there a documentation bug here? If so, I suggest this patch. I
> didn't find anywhere else where the '-setting' syntax was used to
> disable something.
Doesn't gitattributes(5) describe the overall syntax in detail?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH] builtin-branch.c: optimize --merged and --no-merged
From: Nanako Shiraishi @ 2008-07-24 8:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtzeg9rhh.fsf_-_@gitster.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com> writes:
> "git branch --no-merged $commit" used to compute the merge base between
> the tip of each and every branch with the named $commit, but this was
> wasteful when you have many branches.
I am not sure if I followed the technical description of the patch, but I
have a stupid question. How is --merged different from --contains?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [RFC PATCH 00/12] Sparse checkout
From: James Pickens @ 2008-07-24 8:24 UTC (permalink / raw)
To: git
In-Reply-To: <20080723145518.GA29035@laptop>
Nguyễn Thái Ngọc Duy <pclouds <at> gmail.com> writes:
> I have not looked at non-builtin commands yet, but I think it's not
> a big deal. We have several rounds before this series is good enough ;)
> So in short, sparse prefix will be stored in config, core.sparsecheckout.
> you have three new commands to enter/update/leave sparse checkout:
>
> git clone --path=prefix # clone with sparse checkout
> git checkout --path=prefix # limit/update checkout paths
> git checkout --full # stop sparse checkout
>
First things first, thanks a lot for working on this feature. I have an
enormous project in CVS (144GB repo, containing 65000 directories and
463000 files) that I've been wanting to convert to git for a while now,
and the lack of sparse checkouts was the only thing about git that was
standing in the way. The project is so big that checking out the whole
tree all the time is unworkable, and I think my coworkers would hang me
if I tried to make them use submodules. We already use sparse checkouts
in CVS to make it manageable, so sparse checkout support in git would
vastly simplify the transition.
I played around with the patch briefly, and I have a couple of comments
on the interface.
First, I would want a capability to checkout a directory non-recursively.
I.e., checkout directory A/B, without also checking out directory A/B/C.
Perhaps a modifier could be added to a path element to make it
non-recursive.
Second, I would want a capability to checkout and release directories
incrementally, similar to how we do it in cvs. For example, I might do
the following in cvs:
$ cvs co -l A # Checkout dir A non-recursively
$ cd A
$ cvs up -l -d B1 B2 # Checkout dirs A/B1 and A/B2 non-recursively
$ cd B1
$ cvs up -d C1 C2 # Checkout dirs A/B1/C1 and A/B1/C2 recursively
(Oops, didn't need C2)
$ cvs release -d C2
At this point I would have the following directory tree, assuming the C1
directory in the repo contained a D1 directory:
A/
A/B1/
A/B1/C1/
A/B1/C1/D1/
A/B2/
A similar capability in git would be much appreciated.
Finally, I noticed what I think is a bug: if you do a partial checkout of
a non-existing directory, you just get an empty tree. I would expect to
get an error message in that case.
I hope this is helpful, and thanks again for working on this.
James
^ permalink raw reply
* Re: [PATCH 2/2] git-checkout: improve error messages, detect ambiguities.
From: Pierre Habouzit @ 2008-07-24 8:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7ibc9p93.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1356 bytes --]
On Wed, Jul 23, 2008 at 11:04:08PM +0000, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
>
> > The patch is twofold: it moves the option consistency checks just under
> > the parse_options call so that it doesn't get in the way of the tree
> > reference vs. pathspecs desambiguation.
>
> I think this goes a bit too far.
>
> Even if you have a file called 'master' tracked in your project, when you
> say:
>
> $ git checkout master
>
> that's almost always branch switching. Forcing "git checkout master --"
> disambiguation for such a common case is simply a wrong thing to do from
> the usability point of view.
>
> So how about (obviously we are interested only in the case without
> disambiguating '--' here):
>
> (3-1) if there is only one token left and if it is a rev, that's the
> branch to check out or commit to detach to.
>
> (3-2) otherwise the user might have mistyped one of the paths, so help
> avoiding by making sure the first token is unambiguously either
> a rev or a path (but not both).
It sounds really reasonable, and your patch seems really fine.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] document that git-tag can tag more than heads
From: Kalle Olavi Niemitalo @ 2008-07-24 8:48 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.GSO.4.62.0807240000470.23113@harper.uchicago.edu>
Jonathan Nieder <jrnieder@uchicago.edu> writes:
> Samuel Bronson had the idea of putting "<commit-ish> | <object>"
> for "<object>" because most tags point to commits (and for the
> rest of the manpage, all tags point to commits).
But the argument is not a <commit-ish>. git.txt says:
A command that takes a <commit-ish> argument ultimately
wants to operate on a <commit> object but automatically
dereferences <tag> objects that point at a <commit>.
git-tag does not automatically dereference tag objects that
point to a commit. So if you want to use "|", then it should be
"<commit> | <object>".
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Stephan Beyer @ 2008-07-24 8:57 UTC (permalink / raw)
To: david; +Cc: Jakub Narebski, Robin Rosenberg, Johannes Schindelin, git
In-Reply-To: <alpine.DEB.1.10.0807232201310.3721@asgard.lang.hm>
Hi,
david@lang.hm wrote:
>>> And of course "I am not programmer" response...
>>
>> This doesn't make sense, does it?
>> I know that there are non-programmer's who use git for there
>> configuration files and other non-programming track files, but
>> this looks somehow wrong in this survey.
>
> there are non-programmers who use git to track projects that they want to
> be able to run the latest versions of. they don't program, just git pull;
> make;make install
Ahh, you're totally right. :)
I wonder if those users take part in a Git User's Survey. We'll see. :)
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [RFC PATCH 00/12] Sparse checkout
From: Nguyen Thai Ngoc Duy @ 2008-07-24 9:00 UTC (permalink / raw)
To: James Pickens; +Cc: git
In-Reply-To: <loom.20080724T065737-580@post.gmane.org>
On 7/24/08, James Pickens <jepicken@gmail.com> wrote:
> Nguyen Thai Ngoc Duy <pclouds <at> gmail.com> writes:
>
> > I have not looked at non-builtin commands yet, but I think it's not
> > a big deal. We have several rounds before this series is good enough ;)
> > So in short, sparse prefix will be stored in config, core.sparsecheckout.
> > you have three new commands to enter/update/leave sparse checkout:
> >
> > git clone --path=prefix # clone with sparse checkout
> > git checkout --path=prefix # limit/update checkout paths
> > git checkout --full # stop sparse checkout
> >
>
>
> First things first, thanks a lot for working on this feature. I have an
> enormous project in CVS (144GB repo, containing 65000 directories and
> 463000 files) that I've been wanting to convert to git for a while now,
> and the lack of sparse checkouts was the only thing about git that was
> standing in the way. The project is so big that checking out the whole
> tree all the time is unworkable, and I think my coworkers would hang me
> if I tried to make them use submodules. We already use sparse checkouts
> in CVS to make it manageable, so sparse checkout support in git would
> vastly simplify the transition.
>
> I played around with the patch briefly, and I have a couple of comments
> on the interface.
>
> First, I would want a capability to checkout a directory non-recursively.
> I.e., checkout directory A/B, without also checking out directory A/B/C.
> Perhaps a modifier could be added to a path element to make it
> non-recursive.
This one is difficult (and may probably produce more intrusive patch).
Let's see what I can do.
> Second, I would want a capability to checkout and release directories
> incrementally, similar to how we do it in cvs. For example, I might do
> the following in cvs:
>
> $ cvs co -l A # Checkout dir A non-recursively
> $ cd A
> $ cvs up -l -d B1 B2 # Checkout dirs A/B1 and A/B2 non-recursively
> $ cd B1
> $ cvs up -d C1 C2 # Checkout dirs A/B1/C1 and A/B1/C2 recursively
> (Oops, didn't need C2)
> $ cvs release -d C2
> At this point I would have the following directory tree, assuming the C1
> directory in the repo contained a D1 directory:
>
> A/
> A/B1/
> A/B1/C1/
> A/B1/C1/D1/
> A/B2/
>
> A similar capability in git would be much appreciated.
You can do that with "git checkout --path" (non-recursive checkout aside):
$ git checkout --path=A # checkout full A
$ git checkout --path=A/B1/C1 # no, limit to A/B1/C1 only
$ git checkout --path=A/B1/C1:A/B2 # extend to A/B2 too
>
> Finally, I noticed what I think is a bug: if you do a partial checkout of
> a non-existing directory, you just get an empty tree. I would expect to
> get an error message in that case.
Thanks.
> I hope this is helpful, and thanks again for working on this.
>
> James
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Duy
^ permalink raw reply
* Re: [RFC PATCH 00/12] Sparse checkout
From: Jakub Narebski @ 2008-07-24 9:35 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Johannes Schindelin
In-Reply-To: <20080723145518.GA29035@laptop>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> I have not looked at non-builtin commands yet, but I think it's not
> a big deal. We have several rounds before this series is good enough ;)
> So in short, sparse prefix will be stored in config, core.sparsecheckout.
> you have three new commands to enter/update/leave sparse checkout:
>
> git clone --path=prefix # clone with sparse checkout
> git checkout --path=prefix # limit/update checkout paths
> git checkout --full # stop sparse checkout
>
> Other operations should be normal. User attempts to do anything outside
> sparse checkout will get flagged. Git itself should not touch anything
> outside sparse checkout.
>
> One more thing. As files outside sparse checkout will not be checking
> out, .gitignore and .gitattributes from parent directories (outside
> sparse checkout) will be gone too. This may lead to surprise.
>
> Comments are welcome.
A note: my comments here reflects what I have remember from reading
comments in this thread; I have not examined the code, though.
First, I think that 'sparse checkout' is a better idea than former
'subtree (partial) checkout'; and I guess it could be easier to code.
Second, I think you can simply special case .git* files (.gitignore,
.gitattributes, .gitmodules), and always check them out for all
intermediate directories (unless configured otherwise, of course).
So for example if you have the following directory structure:
A/.gitignore
A/a
A/B1/.gitignore
A/B1/b
A/B2/.gitignore
A/B2/c
and you are checking out only subdirectory 'B1' (and all files in it;
if subdirectories are checked out recursively it depends on
configuration), and if for example there is .gitignore in every
directory, then checked out tree would look like this:
A/.gitignore
A/B1/.gitignore
A/B1/b
The ability to do this is one of advantages of 'sparse' checkout over
'subtree' checkout.
Third, about the place where to store information about which paths
are checked out, and which are not. There are three possible places
to store this information:
1. repository configuration, e.g. `core.sparsecheckout' variable
(multivalued?), like for `core.worktree'
2. some text file in $GIT_DIR, e.g. '.git/sparse', like for shallow
clone ("git clone --depth <depth>") it is grafts-like
$GIT_DIR/shallow (see Documentation/technical/shallow.txt).
3. in the index itseld ($GIT_DIR/index), as proposed by Johannes
Schindelin.
While I do think that some information about sparseness should be in
the index, for git to be able to commit from the index for example,
I don't think it is a good place as the only/main place to store
information about which paths are checked out; I think that because
IMVHO git commands should survive hosing (removing) index file.
Just my 2 eurocents.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ 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