* Re: [PATCH] Introduce core.keepHardLinks
From: Johannes Schindelin @ 2008-10-13 16:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, git
In-Reply-To: <7vskr0bnlk.fsf@gitster.siamese.dyndns.org>
Hi,
On Mon, 13 Oct 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> I cannot fathom why a user wants this much rope to hang themselves
> >> with...
> >
> > The question is not so much why anyone want to do this, but _if_.
>
> Sorry, I think the question should be _why_.
>
> You can gain a sympathetic "Ah, that is sensible, and 'this much rope to
> hang themselves with' comment was unwarranted" only by answering that
> question.
Okay, here are a couple of reasons:
- all the editors that this guy tested keep the hard links, so it was
kinda hard to understand why Git insists on behaving differently,
- if the user asked for hard links, it is not Git's place to question that
decision,
- and in that user's scenario a certain file has to be shared between
different projects that are all version-controlled with Git, but in
different teams and with different servers they connect to. So no, you
cannot even make a submodule of it, because the guys involved do not
share any repository/server access. Besides, submodules are not
user-friendly enough yet.
Oh, and come to think of it, this could solve the old issue of "I want to
track only a few files in my $HOME/".
Anyway, I think that breaking hard links is not a nice habit of Git (after
all, from the user's point of view the file is not created, but
modified!), and I would have expected others to need a lot less arguments
to see it that way, too.
Ciao,
Dscho
^ permalink raw reply
* Re: tip tree clone fail
From: H. Peter Anvin @ 2008-10-13 15:59 UTC (permalink / raw)
To: Wang Chen
Cc: Ingo Molnar, Petr Baudis, Thomas Gleixner, FNST-Lai Jiangshan,
FJ-KOSAKI Motohiro, git, Junio C Hamano
In-Reply-To: <48F3178A.50106@cn.fujitsu.com>
Wang Chen wrote:
>
> Ingo, thank you for your work.
> I can clone more, but error still occurs:
>
> Getting alternates list for http://www.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip.git
> Also look at http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
> Also look at http://www.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git/
> Getting pack list for http://www.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip.git
> error: transfer closed with 8280 bytes remaining to read
> Getting pack list for http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
> Getting pack list for http://www.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git/
> error: Unable to find 95630fe2917f805a26f8d8beaafb80cd2f729eb5 under http://www.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip.git
> Cannot obtain needed object 95630fe2917f805a26f8d8beaafb80cd2f729eb5
I cleaned it up and it should work now.
-hpa
^ permalink raw reply
* [PATCH v2] describe: Make --tags and --all match lightweight tags more often
From: Shawn O. Pearce @ 2008-10-13 14:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Pierre Habouzit, Erez Zilber, Uwe Kleine-K�nig
In-Reply-To: <20081010171217.GB29028@artemis.corp>
If the caller supplies --tags they want the lightweight, unannotated
tags to be searched for a match. If a lightweight tag is closer
in the history, it should be matched, even if an annotated tag is
reachable further back in the commit chain.
The same applies with --all when matching any other type of ref.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Acked-By: Uwe Kleine-K�nig <ukleinek@strlen.de>
---
Changes since v1 of this patch:
- Documentation updates were added.
- Comment for "tags" flag modified per Uwe's suggestion.
Documentation/git-describe.txt | 9 +++++++--
builtin-describe.c | 6 ++----
t/t6120-describe.sh | 8 ++++----
3 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
index c4dbc2a..40e061f 100644
--- a/Documentation/git-describe.txt
+++ b/Documentation/git-describe.txt
@@ -18,6 +18,9 @@ shown. Otherwise, it suffixes the tag name with the number of
additional commits on top of the tagged object and the
abbreviated object name of the most recent commit.
+By default (without --all or --tags) `git describe` only shows
+annotated tags. For more information about creating annoated tags
+see the -a and -s options to linkgit:git-tag[1].
OPTIONS
-------
@@ -26,11 +29,13 @@ OPTIONS
--all::
Instead of using only the annotated tags, use any ref
- found in `.git/refs/`.
+ found in `.git/refs/`. This option enables matching
+ any known branch, remote branch, or lightweight tag.
--tags::
Instead of using only the annotated tags, use any tag
- found in `.git/refs/tags`.
+ found in `.git/refs/tags`. This option enables matching
+ a lightweight (non-annotated) tag.
--contains::
Instead of finding the tag that predates the commit, find
diff --git a/builtin-describe.c b/builtin-describe.c
index ec404c8..d2cfb1b 100644
--- a/builtin-describe.c
+++ b/builtin-describe.c
@@ -15,8 +15,8 @@ static const char * const describe_usage[] = {
};
static int debug; /* Display lots of verbose info */
-static int all; /* Default to annotated tags only */
-static int tags; /* But allow any tags if --tags is specified */
+static int all; /* Any valid ref can be used */
+static int tags; /* Allow lightweight tags */
static int longformat;
static int abbrev = DEFAULT_ABBREV;
static int max_candidates = 10;
@@ -112,8 +112,6 @@ static int compare_pt(const void *a_, const void *b_)
{
struct possible_tag *a = (struct possible_tag *)a_;
struct possible_tag *b = (struct possible_tag *)b_;
- if (a->name->prio != b->name->prio)
- return b->name->prio - a->name->prio;
if (a->depth != b->depth)
return a->depth - b->depth;
if (a->found_order != b->found_order)
diff --git a/t/t6120-describe.sh b/t/t6120-describe.sh
index 16cc635..e6c9e59 100755
--- a/t/t6120-describe.sh
+++ b/t/t6120-describe.sh
@@ -91,10 +91,10 @@ check_describe D-* HEAD^^
check_describe A-* HEAD^^2
check_describe B HEAD^^2^
-check_describe A-* --tags HEAD
-check_describe A-* --tags HEAD^
-check_describe D-* --tags HEAD^^
-check_describe A-* --tags HEAD^^2
+check_describe c-* --tags HEAD
+check_describe c-* --tags HEAD^
+check_describe e-* --tags HEAD^^
+check_describe c-* --tags HEAD^^2
check_describe B --tags HEAD^^2^
check_describe B-0-* --long HEAD^^2^
--
1.6.0.2.706.g340fc
--
Shawn.
^ permalink raw reply related
* Re: [RFC PATCH] describe: Make --tags and --all match lightweight tags more often
From: Shawn O. Pearce @ 2008-10-13 14:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pierre Habouzit, git, Erez Zilber
In-Reply-To: <7vwsggl3ep.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
>
> The primary mode of operation without --tags of "describe" is about coming
> up with version numbers, and as such, it should try to base its output on
> immutable anchors as much as possible. For that reason, I think it should
> use "tag " line from the tag object, not the name of the ref, to describe
> the committish. They should match (otherwise fsck would say something
> about it) in practice, though...
FWIW the use of "tag " line for an annotated tag being output is what
212945d4 (Teach git-describe to verify annotated tag names before
output) was all about. That has been in tree since v1.5.5-rc0~86^2.
So we already are doing (have been doing) exactly what you are
asking for.
Or did I misunderstand you?
--
Shawn.
^ permalink raw reply
* Re: What's cooking in git/spearce.git (Oct 2008, #02; Sun, 12)
From: Junio C Hamano @ 2008-10-13 14:25 UTC (permalink / raw)
To: Stephen Haberman; +Cc: Shawn O. Pearce, git
In-Reply-To: <20081013013752.8fc16695.stephen@exigencecorp.com>
Stephen Haberman <stephen@exigencecorp.com> writes:
> (I also have a test comment typo and test_expect_failure change to make
> to rebase-i-p from Junio's feedback and would like to know the
> preferred way to submit those--e.g. a patch on top of your pu, a patch
> on top of the existing series, or a new series all together. Given it
> is not next, I'm guessing a new series all together.)
You guessed it right.
As sh/maint-rebase3 is about a pure fix, while the other -i-p is a more
involved enhancement, I am guessing Shawn decided not to queue the latter
for 1.6.0.X, and I agree with that. The final shape of the history should
look like:
* maint will eventually get sh/maint-rebase3 to be in 1.6.0.X, which in
turn will eventually be merged to master;
* master will eventually get sh/rebase-i-p.
When two series have dependencies like this, it is generally the easiest
and cleanest to prepare them to match such a final shape of the history.
Hence, we would want two series built like this:
* sh/maint-rebase3 applicable to the tip of 'maint' (this is already done;
what is in sh/maint-rebase3 is exactly that);
* apply the above locally to 'maint', merge the result locally to
'master', and prepare sh/rebase-i-p series applicable on top of that
merge.
Thanks.
^ permalink raw reply
* Re: [PATCH v2] Fix fetch/pull when run without --update-head-ok
From: Junio C Hamano @ 2008-10-13 14:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Daniel Barkalow, git, gitster, spearce
In-Reply-To: <alpine.DEB.1.00.0810131129110.22125@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Some confusing tutorials suggested that it would be a good idea to fetch
> into the current branch with something like this:
>
> git fetch origin master:master
>
> (or even worse: the same command line with "pull" instead of "fetch").
> While it might make sense to store what you want to pull, it typically
> is plain wrong when the current branch is "master".
>
> As noticed by Junio, this behavior should be triggered by _not_ passing
> the --update-head-ok option, but somewhere along the lines we lost that
> behavior.
Do you mean, by "this behavior should be triggered", "we should allow
updating the current branch head only when --update-head-ok is given", in
other words, "we should error out if the user tries to update the current
head with git-fetch without passing --update-head-ok"?
> NOTE: this patch does not completely resurrect the original behavior
> without --update-head-ok: the check for the current branch is now _only_
> performed in non-bare repositories.
I think that is a sensible improvement.
> Strangely, some more tests refused to pass this time, because they
> did not use --update-head-ok; this was fixed, too.
We need to look at these changes a bit carefully, as changes to existing
tests can be either (1) fixing those that depended on broken behaviour of
the command, or (2) trying to hide regressions introduced by the patch
under the rug.
> t/t5405-send-pack-rewind.sh | 2 +-
> t/t5505-remote.sh | 2 +-
> t/t5510-fetch.sh | 12 ++++++++++++
> t/t9300-fast-import.sh | 2 +-
I suspect all of these offending tests came after b888d61 (Make fetch a
builtin, 2007-09-10) which lacked the necessary check in do_fetch() to
cause the regression you are fixing (iow, I am suspecting that the
brokenness of the tests were hidden by the breakage you are fixing). The
parts of the tests you fixed came from these:
6738c81 (send-pack: segfault fix on forced push, 2007-11-08)
4ebc914 (builtin-remote: prune remotes correctly ..., 2008-02-29)
4942025 (t5510: test "git fetch" following tags minimally, 2008-09-21)
03db452 (Support gitlinks in fast-import., 2008-07-19)
all of which are indeed descendants of b888d61.
With these verified, I think I should move the "Strangely" comment to the
commit log message proper (after stripping "Strangely" part -- it is not
strange anymore after we understand why).
^ permalink raw reply
* Re: [PATCH v2] Fix fetch/pull when run without --update-head-ok
From: Shawn O. Pearce @ 2008-10-13 14:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Daniel Barkalow, git, gitster
In-Reply-To: <alpine.DEB.1.00.0810131129110.22125@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> Some confusing tutorials suggested that it would be a good idea to fetch
> into the current branch with something like this:
>
> git fetch origin master:master
>
> (or even worse: the same command line with "pull" instead of "fetch").
> While it might make sense to store what you want to pull, it typically
> is plain wrong when the current branch is "master".
>
> As noticed by Junio, this behavior should be triggered by _not_ passing
> the --update-head-ok option, but somewhere along the lines we lost that
> behavior.
>
> NOTE: this patch does not completely resurrect the original behavior
> without --update-head-ok: the check for the current branch is now _only_
> performed in non-bare repositories.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
> Strangely, some more tests refused to pass this time, because they
> did not use --update-head-ok; this was fixed, too.
Not strange, --update-head-ok was busted and the tests took advantage
of it. :-\
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Introduce core.keepHardLinks
From: Junio C Hamano @ 2008-10-13 14:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn O. Pearce, git
In-Reply-To: <alpine.DEB.1.00.0810131057150.22125@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> I cannot fathom why a user wants this much rope to hang themselves
>> with...
>
> The question is not so much why anyone want to do this, but _if_.
Sorry, I think the question should be _why_.
You can gain a sympathetic "Ah, that is sensible, and 'this much rope to
hang themselves with' comment was unwarranted" only by answering that
question.
^ permalink raw reply
* Re: [PATCH 3/4] diff: introduce diff.<driver>.binary
From: Junio C Hamano @ 2008-10-13 13:54 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Sixt, Matthieu Moy, git
In-Reply-To: <20081013041525.GA32629@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> It's possible that one could, given the binary preimage and the two
> lossy textconv'd versions, produce a custom binary merge that would just
> munge the tags, or just munge the text, or whatever. But that is an
> order of magnitude more work than writing a textconv, which is usually
> as simple as "/path/to/existing/conversion-script".
>
> And the whole point of this exercise was to make it simple to set this
> conversion up.
>
>> I'd say that format-patch should always disable textconv so that we won't
>> have to worry about it for now.
>
> Agreed, if you remove "for now". I had never intended for these to be
> anything but a human-readable display (and while I am generally OK with
> generalizing functionality when we can, I think there is real value in
> the simplicity here).
Ok. I don't disagree with any of the above.
We however need to make it very clear that reversibility (aka ability to
produce applicable diff) is never the goal of the textconv mechanism (and
suggest your "for applicable and reviewable diff, you produce the standard
binary diff and add the textconv diff as a comment" in the documentation),
as I am quite sure that 6 months down the road somebody who was not
involved in this thread would complain.
^ permalink raw reply
* Re: [PATCHv5 0/5] *** SUBJECT HERE ***
From: Giuseppe Bilotta @ 2008-10-13 11:42 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis, Shawn O. Pearce, Junio C Hamano
In-Reply-To: <200810131300.35309.jnareb@gmail.com>
On Mon, Oct 13, 2008 at 1:00 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> Err... "*** SUBJECT HERE ***"? Not that it matters...
Yeah, I realized that as soon as I sent the thing 8-(
> I like it, and with the exception of the last patch (which looks like
> it doesn't check if $file_name contains '..', even as it checks if
> $file_parent contains '..', and which probably should not esc_url)
Oopsie. I'll get to fix that.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [PATCHv5 0/5] *** SUBJECT HERE ***
From: Jakub Narebski @ 2008-10-13 11:00 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Shawn O. Pearce, Junio C Hamano
In-Reply-To: <1223893165-26022-1-git-send-email-giuseppe.bilotta@gmail.com>
Err... "*** SUBJECT HERE ***"? Not that it matters...
On Mon, 13 Oct 2008, Giuseppe Bilotta wrote:
> Fifth attempt for my gitweb PATH_INFO patchset, whose purpose is to
> reduce the use of CGI parameters by embedding as many parameters as
> possible in the URL path itself, provided the pathinfo feature is
> enabled.
[...]
> Giuseppe Bilotta (5):
> gitweb: parse project/action/hash_base:filename PATH_INFO
> gitweb: generate project/action/hash URLs
> gitweb: use_pathinfo filenames start with /
> gitweb: parse parent..current syntax from PATH_INFO
> gitweb: generate parent..current URLs
I like it, and with the exception of the last patch (which looks like
it doesn't check if $file_name contains '..', even as it checks if
$file_parent contains '..', and which probably should not esc_url)
it looks OK. from (superficial) browsing through patches.
I'll try to review them soon.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCHv5 0/5] *** SUBJECT HERE ***
From: Ondrej Certik @ 2008-10-13 10:52 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
In-Reply-To: <1223893165-26022-1-git-send-email-giuseppe.bilotta@gmail.com>
On Mon, Oct 13, 2008 at 12:19 PM, Giuseppe Bilotta
<giuseppe.bilotta@gmail.com> wrote:
> Fifth attempt for my gitweb PATH_INFO patchset, whose purpose is to
> reduce the use of CGI parameters by embedding as many parameters as
> possible in the URL path itself, provided the pathinfo feature is
> enabled.
>
> The new typical gitweb URL is therefore in the form
>
> $project/$action/$parent:$file..$hash:$file
>
> (with useless parts stripped). Backwards compatibility for old-style
> $project/$hash[:$file] URLs is kept, as long as $hash is not a refname whose
> name happens to match a git action.
Thanks Giuseppe for doing this. I just switched from Mercurial to git
recently and this is one thing that I was missing a lot in git.
Ondrej
^ permalink raw reply
* [PATCHv5 5/5] gitweb: generate parent..current URLs
From: Giuseppe Bilotta @ 2008-10-13 10:19 UTC (permalink / raw)
To: git
Cc: Jakub Narebski, Petr Baudis, Shawn O. Pearce, Junio C Hamano,
Giuseppe Bilotta
In-Reply-To: <1223893165-26022-5-git-send-email-giuseppe.bilotta@gmail.com>
If use_pathinfo is enabled, href now creates links that contain paths in
the form $project/$action/oldhash:/oldname..newhash:/newname for actions
that use hash_parent etc.
If any of the filename contains two consecutive dots, it's kept as a CGI
parameter since the resulting path would otherwise be ambiguous.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 30 +++++++++++++++++++++++++-----
1 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 1a7b0b9..f4642e7 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -759,7 +759,8 @@ sub href (%) {
# try to put as many parameters as possible in PATH_INFO:
# - project name
# - action
- # - hash or hash_base:/filename
+ # - hash_parent or hash_parent_base:/file_parent
+ # - hash or hash_base:/file_name
# When the script is the root DirectoryIndex for the domain,
# $href here would be something like http://gitweb.example.com/
@@ -778,17 +779,36 @@ sub href (%) {
delete $params{'action'};
}
- # Finally, we put either hash_base:/file_name or hash
+ # Next, we put hash_parent_base:/file_parent..hash_base:/file_name,
+ # stripping nonexistent or useless pieces
+ $href .= "/" if ($params{'hash_base'} || $params{'hash_parent_base'}
+ || $params{'hash_parent'} || $params{'hash'});
if (defined $params{'hash_base'}) {
- $href .= "/".esc_url($params{'hash_base'});
- if (defined $params{'file_name'}) {
+ if (defined $params{'hash_parent_base'}) {
+ $href .= esc_url($params{'hash_parent_base'});
+ # skip the file_parent if it's the same as the file_name
+ delete $params{'file_parent'} if $params{'file_parent'} eq $params{'file_name'};
+ if (defined $params{'file_parent'} && $params{'file_parent'} !~ /\.\./) {
+ $href .= ":/".esc_url($params{'file_parent'});
+ delete $params{'file_parent'};
+ }
+ $href .= "..";
+ delete $params{'hash_parent'};
+ delete $params{'hash_parent_base'};
+ } elsif (defined $params{'hash_parent'}) {
+ $href .= esc_url($params{'hash_parent'}). "..";
+ delete $params{'hash_parent'};
+ }
+
+ $href .= esc_url($params{'hash_base'});
+ if (defined $params{'file_name'} && $params{'file_name'} !~ /\.\./) {
$href .= ":/".esc_url($params{'file_name'});
delete $params{'file_name'};
}
delete $params{'hash'};
delete $params{'hash_base'};
} elsif (defined $params{'hash'}) {
- $href .= "/".esc_url($params{'hash'});
+ $href .= esc_url($params{'hash'});
delete $params{'hash'};
}
}
--
1.5.6.5
^ permalink raw reply related
* [PATCHv5 4/5] gitweb: parse parent..current syntax from PATH_INFO
From: Giuseppe Bilotta @ 2008-10-13 10:19 UTC (permalink / raw)
To: git
Cc: Jakub Narebski, Petr Baudis, Shawn O. Pearce, Junio C Hamano,
Giuseppe Bilotta
In-Reply-To: <1223893165-26022-4-git-send-email-giuseppe.bilotta@gmail.com>
This patch makes it possible to use an URL such as
$project/somebranch..otherbranch:/filename to get a diff between
different version of a file. Paths like
$project/$action/somebranch:/somefile..otherbranch:/otherfile are parsed
as well.
All '*diff' actions and in general actions that use $hash_parent[_base]
and $file_parent can now get all of their parameters from PATH_INFO
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 36 ++++++++++++++++++++++++++++++++++--
1 files changed, 34 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 49730f3..1a7b0b9 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -548,7 +548,12 @@ sub evaluate_path_info {
'history',
);
- my ($refname, $pathname) = split(/:/, $path_info, 2);
+ # horrible regexp to catch
+ # [$hash_parent_base[:$file_parent]..]$hash_parent[:$file_name]
+ my ($parentrefname, $parentpathname, $refname, $pathname) =
+ ($path_info =~ /^(?:(.+?)(?::(.+))?\.\.)?(.+?)(?::(.+))?$/);
+
+ # first, analyze the 'current' part
if (defined $pathname) {
# we got "branch:filename" or "branch:dir/"
# we could use git_get_type(branch:pathname), but it needs $git_dir
@@ -557,7 +562,13 @@ sub evaluate_path_info {
$input_params{'action'} ||= "tree";
$pathname =~ s,/$,,;
} else {
- $input_params{'action'} ||= "blob_plain";
+ # the default action depends on whether we had parent info
+ # or not
+ if ($parentrefname) {
+ $input_params{'action'} ||= "blobdiff_plain";
+ } else {
+ $input_params{'action'} ||= "blob_plain";
+ }
}
$input_params{'hash_base'} ||= $refname;
$input_params{'file_name'} ||= $pathname;
@@ -577,6 +588,27 @@ sub evaluate_path_info {
$input_params{'hash'} ||= $refname;
}
}
+
+ # next, handle the 'parent' part, if present
+ if (defined $parentrefname) {
+ # a missing pathspec defaults to the 'current' filename, allowing e.g.
+ # someproject/blobdiff/oldrev..newrev:/filename
+ if ($parentpathname) {
+ $parentpathname =~ s,^/+,,;
+ $parentpathname =~ s,/$,,;
+ $input_params{'file_parent'} ||= $parentpathname;
+ } else {
+ $input_params{'file_parent'} ||= $input_params{'file_name'};
+ }
+ # we assume that hash_parent_base is wanted if a path was specified,
+ # or if the action wants hash_base instead of hash
+ if (defined $input_params{'file_parent'} ||
+ grep($input_params{'action'}, @wants_base)) {
+ $input_params{'hash_parent_base'} ||= $parentrefname;
+ } else {
+ $input_params{'hash_parent'} ||= $parentrefname;
+ }
+ }
}
evaluate_path_info();
--
1.5.6.5
^ permalink raw reply related
* [PATCHv5 1/5] gitweb: parse project/action/hash_base:filename PATH_INFO
From: Giuseppe Bilotta @ 2008-10-13 10:19 UTC (permalink / raw)
To: git
Cc: Jakub Narebski, Petr Baudis, Shawn O. Pearce, Junio C Hamano,
Giuseppe Bilotta
In-Reply-To: <1223893165-26022-1-git-send-email-giuseppe.bilotta@gmail.com>
This patch enables gitweb to parse URLs with more information embedded
in PATH_INFO, reducing the need for CGI parameters. The typical gitweb
path is now $project/$action/$hash_base:$file_name or
$project/$action/$hash
This is mostly backwards compatible with the old-style gitweb paths,
$project/$branch[:$filename], except when it was used to access a branch
whose name matches a gitweb action.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 37 +++++++++++++++++++++++++++++++------
1 files changed, 31 insertions(+), 6 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index c5254af..6d0dc26 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -534,23 +534,48 @@ sub evaluate_path_info {
return if $input_params{'action'};
$path_info =~ s,^\Q$project\E/*,,;
+ # next, check if we have an action
+ my $action = $path_info;
+ $action =~ s,/.*$,,;
+ if (exists $actions{$action}) {
+ $path_info =~ s,^$action/*,,;
+ $input_params{'action'} = $action;
+ }
+
+ # list of actions that want hash_base instead of hash
+ my @wants_base = (
+ 'tree',
+ 'history',
+ );
+
my ($refname, $pathname) = split(/:/, $path_info, 2);
if (defined $pathname) {
- # we got "project.git/branch:filename" or "project.git/branch:dir/"
+ # we got "branch:filename" or "branch:dir/"
# we could use git_get_type(branch:pathname), but it needs $git_dir
$pathname =~ s,^/+,,;
if (!$pathname || substr($pathname, -1) eq "/") {
- $input_params{'action'} = "tree";
+ $input_params{'action'} ||= "tree";
$pathname =~ s,/$,,;
} else {
- $input_params{'action'} = "blob_plain";
+ $input_params{'action'} ||= "blob_plain";
}
$input_params{'hash_base'} ||= $refname;
$input_params{'file_name'} ||= $pathname;
} elsif (defined $refname) {
- # we got "project.git/branch"
- $input_params{'action'} = "shortlog";
- $input_params{'hash'} ||= $refname;
+ # we got "branch". in this case we have to choose if we have to
+ # set hash or hash_base.
+ #
+ # Most of the actions without a pathname only want hash to be
+ # set, except for the ones specified in @wants_base that want
+ # hash_base instead. It should also be noted that hand-crafted
+ # links having 'history' as an action and no pathname or hash
+ # set will fail, but that happens regardless of PATH_INFO.
+ $input_params{'action'} ||= "shortlog";
+ if (grep($input_params{'action'},@wants_base)) {
+ $input_params{'hash_base'} ||= $refname;
+ } else {
+ $input_params{'hash'} ||= $refname;
+ }
}
}
evaluate_path_info();
--
1.5.6.5
^ permalink raw reply related
* [PATCHv5 3/5] gitweb: use_pathinfo filenames start with /
From: Giuseppe Bilotta @ 2008-10-13 10:19 UTC (permalink / raw)
To: git
Cc: Jakub Narebski, Petr Baudis, Shawn O. Pearce, Junio C Hamano,
Giuseppe Bilotta
In-Reply-To: <1223893165-26022-3-git-send-email-giuseppe.bilotta@gmail.com>
When using path info, make filenames start with a / (right after the :
that separates them from the hash base). This minimal change allows
relative navigation to work properly when viewing HTML files in raw
('blob_plain') mode.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 5337d40..49730f3 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -727,7 +727,7 @@ sub href (%) {
# try to put as many parameters as possible in PATH_INFO:
# - project name
# - action
- # - hash or hash_base:filename
+ # - hash or hash_base:/filename
# When the script is the root DirectoryIndex for the domain,
# $href here would be something like http://gitweb.example.com/
@@ -746,11 +746,11 @@ sub href (%) {
delete $params{'action'};
}
- # Finally, we put either hash_base:file_name or hash
+ # Finally, we put either hash_base:/file_name or hash
if (defined $params{'hash_base'}) {
$href .= "/".esc_url($params{'hash_base'});
if (defined $params{'file_name'}) {
- $href .= ":".esc_url($params{'file_name'});
+ $href .= ":/".esc_url($params{'file_name'});
delete $params{'file_name'};
}
delete $params{'hash'};
--
1.5.6.5
^ permalink raw reply related
* [PATCHv5 2/5] gitweb: generate project/action/hash URLs
From: Giuseppe Bilotta @ 2008-10-13 10:19 UTC (permalink / raw)
To: git
Cc: Jakub Narebski, Petr Baudis, Shawn O. Pearce, Junio C Hamano,
Giuseppe Bilotta
In-Reply-To: <1223893165-26022-2-git-send-email-giuseppe.bilotta@gmail.com>
When generating path info URLs, reduce the number of CGI parameters by
embedding action and hash_parent:filename or hash in the path.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 33 ++++++++++++++++++++++++++++++---
1 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 6d0dc26..5337d40 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -724,14 +724,41 @@ sub href (%) {
my ($use_pathinfo) = gitweb_check_feature('pathinfo');
if ($use_pathinfo) {
- # use PATH_INFO for project name
+ # try to put as many parameters as possible in PATH_INFO:
+ # - project name
+ # - action
+ # - hash or hash_base:filename
+
+ # When the script is the root DirectoryIndex for the domain,
+ # $href here would be something like http://gitweb.example.com/
+ # Thus, we strip any trailing / from $href, to spare us double
+ # slashes in the final URL
+ $href =~ s,/$,,;
+
+ # Then add the project name, if present
$href .= "/".esc_url($params{'project'}) if defined $params{'project'};
delete $params{'project'};
- # Summary just uses the project path URL
- if (defined $params{'action'} && $params{'action'} eq 'summary') {
+ # Summary just uses the project path URL, any other action is
+ # added to the URL
+ if (defined $params{'action'}) {
+ $href .= "/".esc_url($params{'action'}) unless $params{'action'} eq 'summary';
delete $params{'action'};
}
+
+ # Finally, we put either hash_base:file_name or hash
+ if (defined $params{'hash_base'}) {
+ $href .= "/".esc_url($params{'hash_base'});
+ if (defined $params{'file_name'}) {
+ $href .= ":".esc_url($params{'file_name'});
+ delete $params{'file_name'};
+ }
+ delete $params{'hash'};
+ delete $params{'hash_base'};
+ } elsif (defined $params{'hash'}) {
+ $href .= "/".esc_url($params{'hash'});
+ delete $params{'hash'};
+ }
}
# now encode the parameters explicitly
--
1.5.6.5
^ permalink raw reply related
* [PATCHv5 0/5] *** SUBJECT HERE ***
From: Giuseppe Bilotta @ 2008-10-13 10:19 UTC (permalink / raw)
To: git
Cc: Jakub Narebski, Petr Baudis, Shawn O. Pearce, Junio C Hamano,
Giuseppe Bilotta
Fifth attempt for my gitweb PATH_INFO patchset, whose purpose is to
reduce the use of CGI parameters by embedding as many parameters as
possible in the URL path itself, provided the pathinfo feature is
enabled.
The new typical gitweb URL is therefore in the form
$project/$action/$parent:$file..$hash:$file
(with useless parts stripped). Backwards compatibility for old-style
$project/$hash[:$file] URLs is kept, as long as $hash is not a refname whose
name happens to match a git action.
The main implementation is provided by paired patches (#1#2, #4#5)
that implement parsing and generation of the new style URLs.
Patch #3 is a minor improvement to the URL syntax that allows web
sites to be properly browsable in raw mode.
The patchset depends on my previous input parameter handling patch currently
waiting in 'next'.
Giuseppe Bilotta (5):
gitweb: parse project/action/hash_base:filename PATH_INFO
gitweb: generate project/action/hash URLs
gitweb: use_pathinfo filenames start with /
gitweb: parse parent..current syntax from PATH_INFO
gitweb: generate parent..current URLs
gitweb/gitweb.perl | 124 +++++++++++++++++++++++++++++++++++++++++++++++----
1 files changed, 114 insertions(+), 10 deletions(-)
^ permalink raw reply
* Re: tip tree clone fail
From: Wang Chen @ 2008-10-13 9:40 UTC (permalink / raw)
To: Ingo Molnar
Cc: Petr Baudis, H. Peter Anvin, Thomas Gleixner, FNST-Lai Jiangshan,
FJ-KOSAKI Motohiro, git, Junio C Hamano
In-Reply-To: <20081012165954.GA2317@elte.hu>
Ingo Molnar said the following on 2008-10-13 0:59:
> * Petr Baudis <pasky@suse.cz> wrote:
>
>> On Sun, Oct 12, 2008 at 05:24:27PM +0200, Ingo Molnar wrote:
>>> hm, -tip's .git/hooks/post-update already contained this, for the last 2
>>> months:
>>>
>>> exec git update-server-info
>>>
>>> so ... _despite_ us having this in the git repo, the HTTP protocol still
>>> does not work. Why?
>> I think your problem is that HTTP does not know where to look for
>> objects coming from alternates; IIRC this would work if you used
>> relative paths in objects/info/alternates, or you can create
>> objects/info/http-alternates like
>>
>> /pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects
>> /pub/scm/linux/kernel/git/sfr/linux-next.git/objects
>
> ok, i've now set it up like this:
>
> $ pwd
> /pub/scm/linux/kernel/git/x86/linux-2.6-tip.git
>
> $ cat objects/info/alternates
> /home/ftp/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects
> /home/ftp/pub/scm/linux/kernel/git/sfr/linux-next.git/objects
>
> $ cat objects/info/http-alternates
> /pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects
> /pub/scm/linux/kernel/git/sfr/linux-next.git/objects
>
> and i've added "git update-server-info" to hooks/post-receive and made
> it chmod +x.
>
> that should be golden, right? I'm wondering why this isnt in the default
> setup - i've been behind a limited corporate firewall in a former life
> and having HTTP access is indeed very handy and pragmatic. Often hotel
> WLANs are HTTP only as well.
>
> Soapbox: in fact it would be outright stupid to limit the kernel
> source's availability artificially by not making HTTP a tier-one access
> method.
>
> Fighting against HTTP-only firewalls is like constantly pointing it out
> to the popular press that they should say 'cracker' instead of 'hacker'.
> It is pointless and only hurts the availability our own project.
>
Ingo, thank you for your work.
I can clone more, but error still occurs:
Getting alternates list for http://www.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip.git
Also look at http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
Also look at http://www.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git/
Getting pack list for http://www.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip.git
error: transfer closed with 8280 bytes remaining to read
Getting pack list for http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
Getting pack list for http://www.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git/
error: Unable to find 95630fe2917f805a26f8d8beaafb80cd2f729eb5 under http://www.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip.git
Cannot obtain needed object 95630fe2917f805a26f8d8beaafb80cd2f729eb5
^ permalink raw reply
* [PATCH] tests: shell negation portability fix
From: Jeff King @ 2008-10-13 9:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Commit 969c8775 introduced a test which uses the non-portable construct:
command1 && ! command2 | command3
which must be
command1 && ! (command2 | command3)
to work on bsd shells (this is another example of bbf08124, which fixed
several similar cases).
Signed-off-by: Jeff King <peff@peff.net>
---
I had totally forgotten about this monstrosity until my autobuild broke.
diff --git a/t/t4128-apply-root.sh b/t/t4128-apply-root.sh
index bc7a8a8..8f6aea4 100755
--- a/t/t4128-apply-root.sh
+++ b/t/t4128-apply-root.sh
@@ -72,7 +72,7 @@ test_expect_success 'apply --directory (delete file)' '
echo content >some/sub/dir/delfile &&
git add some/sub/dir/delfile &&
git apply --directory=some/sub/dir/ --index patch &&
- ! git ls-files | grep delfile
+ ! (git ls-files | grep delfile)
'
cat > patch << 'EOF'
^ permalink raw reply related
* [PATCH v2] Fix fetch/pull when run without --update-head-ok
From: Johannes Schindelin @ 2008-10-13 9:36 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git, gitster, spearce
In-Reply-To: <alpine.LNX.1.00.0810121501590.19665@iabervon.org>
Some confusing tutorials suggested that it would be a good idea to fetch
into the current branch with something like this:
git fetch origin master:master
(or even worse: the same command line with "pull" instead of "fetch").
While it might make sense to store what you want to pull, it typically
is plain wrong when the current branch is "master".
As noticed by Junio, this behavior should be triggered by _not_ passing
the --update-head-ok option, but somewhere along the lines we lost that
behavior.
NOTE: this patch does not completely resurrect the original behavior
without --update-head-ok: the check for the current branch is now _only_
performed in non-bare repositories.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Sun, 12 Oct 2008, Daniel Barkalow and Shawn Pearce sent some
good suggestions to fix the first version of the patch.
This is the updated version. In particular, the test is only
performed without the option "--update-head-ok", the function
branch_get(NULL) is called to get the current branch, a test was
added to verify that --update-head-ok works as expected, and the
commit message was modified in the hope that it confuses less now.
Strangely, some more tests refused to pass this time, because they
did not use --update-head-ok; this was fixed, too.
builtin-fetch.c | 15 +++++++++++++++
t/t5405-send-pack-rewind.sh | 2 +-
t/t5505-remote.sh | 2 +-
t/t5510-fetch.sh | 12 ++++++++++++
t/t9300-fast-import.sh | 2 +-
5 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/builtin-fetch.c b/builtin-fetch.c
index ee93d3a..57c161d 100644
--- a/builtin-fetch.c
+++ b/builtin-fetch.c
@@ -534,6 +534,19 @@ static void find_non_local_tags(struct transport *transport,
string_list_clear(&new_refs, 0);
}
+static void check_not_current_branch(struct ref *ref_map)
+{
+ struct branch *current_branch = branch_get(NULL);
+
+ if (is_bare_repository() || !current_branch)
+ return;
+
+ for (; ref_map; ref_map = ref_map->next)
+ if (ref_map->peer_ref && !strcmp(current_branch->refname,
+ ref_map->peer_ref->name))
+ die("Refusing to fetch into current branch");
+}
+
static int do_fetch(struct transport *transport,
struct refspec *refs, int ref_count)
{
@@ -558,6 +571,8 @@ static int do_fetch(struct transport *transport,
}
ref_map = get_ref_map(transport, refs, ref_count, tags, &autotags);
+ if (!update_head_ok)
+ check_not_current_branch(ref_map);
for (rm = ref_map; rm; rm = rm->next) {
if (rm->peer_ref)
diff --git a/t/t5405-send-pack-rewind.sh b/t/t5405-send-pack-rewind.sh
index 86abc62..cb9aacc 100755
--- a/t/t5405-send-pack-rewind.sh
+++ b/t/t5405-send-pack-rewind.sh
@@ -12,7 +12,7 @@ test_expect_success setup '
mkdir another && (
cd another &&
git init &&
- git fetch .. master:master
+ git fetch --update-head-ok .. master:master
) &&
>file2 && git add file2 && test_tick &&
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index c449663..0103e1a 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -188,7 +188,7 @@ test_expect_success 'prune --dry-run' '
test_expect_success 'add --mirror && prune' '
(mkdir mirror &&
cd mirror &&
- git init &&
+ git init --bare &&
git remote add --mirror -f origin ../one) &&
(cd one &&
git branch -m side2 side) &&
diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
index 9aae496..9e679b4 100755
--- a/t/t5510-fetch.sh
+++ b/t/t5510-fetch.sh
@@ -323,4 +323,16 @@ test_expect_success 'auto tag following fetches minimum' '
)
'
+test_expect_success 'refuse to fetch into the current branch' '
+
+ test_must_fail git fetch . side:master
+
+'
+
+test_expect_success 'fetch into the current branch with --update-head-ok' '
+
+ git fetch --update-head-ok . side:master
+
+'
+
test_done
diff --git a/t/t9300-fast-import.sh b/t/t9300-fast-import.sh
index 328444a..91b5ace 100755
--- a/t/t9300-fast-import.sh
+++ b/t/t9300-fast-import.sh
@@ -983,7 +983,7 @@ test_expect_success \
git checkout subuse1 &&
rm -rf sub && mkdir sub && cd sub &&
git init &&
- git fetch .. refs/heads/sub:refs/heads/master &&
+ git fetch --update-head-ok .. refs/heads/sub:refs/heads/master &&
git checkout master &&
cd .. &&
git submodule init &&
--
1.6.0.2.749.g0cc32
^ permalink raw reply related
* Re: [PATCH] fetch: refuse to fetch into the current branch in a non-bare repository
From: Johannes Schindelin @ 2008-10-13 9:28 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20081012184727.GE4856@spearce.org>
Hi,
On Sun, 12 Oct 2008, Shawn O. Pearce wrote:
> Junio C Hamano <gitster@pobox.com> wrote:
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> > > Some confusing tutorials suggest that it would be a good idea to call
> > > something like this:
> > >
> > > git pull origin master:master
> > >
> > > While it might make sense to store what you want to merge, it typically
> > > is plain wrong.
> >
> > I am somewhat confused.
>
> The description is confusing, yes. It should be about git fetch,
> not git pull.
However, it was a "git pull origin master:master" that was the issue.
That's why I wrote it in the commit message.
> > This "confusion" has been there for very long time and (at least the
> > scripted version of) git-pull/git-fetch pair has supported a
> > workaround in the form of --update-head-ok option.
Good point. I completely had forgotten about that feature.
> I think "git fetch url side:master" when master is the current branch
> and we have omitted --update-head-ok is broken. Specifically Dscho's
> last hunk which adds this test. The test fails on current master.
Thanks for testing; I ran out of my Git time budget yesterday. Will send
an updated patch as a reply to Daniel's reply.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Introduce core.keepHardLinks
From: Johannes Schindelin @ 2008-10-13 9:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, spearce
In-Reply-To: <7vskr1c976.fsf@gitster.siamese.dyndns.org>
Hi,
On Sun, 12 Oct 2008, Junio C Hamano wrote:
> Shawn had this queued in pu, but it appears to even fail its own tests
> on my machine, when applied on top of 'master'.
Sorry, I cannot reproduce at all.
I tested this on two machines, i686 and x86_64 (of course, on top of my
patches to 'next', but now repeated the test with the commit
cherry-picked to your 5c283eb(Merge branch 'maint')).
It passes.
Ciao,
Dscho
P.S.: I even made "make clean && make -j50 test", just in case we have
some dependency issue in the Makefile (happened before). Still passes.
P.P.S.: It would be nice if you could run the test with -i -v (and maybe
with sh -x) and post the output. Thank you very much.
P.P.P.S.: Just for reference: this is what the cherry-picked commit
format-patches to:
-- snipsnap --
[PATCH] Introduce core.keepHardLinks
When a tracked file was hard linked, we used to break the hard link
whenever Git writes to that file. Make that optional.
To keep the implementation simple, mode changes will still break the
hard links.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Documentation/config.txt | 4 +++
cache.h | 1 +
config.c | 5 ++++
entry.c | 7 ++++-
environment.c | 1 +
t/t0056-hardlinked.sh | 58 ++++++++++++++++++++++++++++++++++++++++++++++
6 files changed, 74 insertions(+), 2 deletions(-)
create mode 100644 t/t0056-hardlinked.sh
diff --git a/Documentation/config.txt b/Documentation/config.txt
index da18a54..aacaeae 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -207,6 +207,10 @@ core.symlinks::
file. Useful on filesystems like FAT that do not support
symbolic links. True by default.
+core.keepHardLinks::
+ If true, do not break hard links by deleting and recreating the
+ files. Off by default.
+
core.gitProxy::
A "proxy command" to execute (as 'command host port') instead
of establishing direct connection to the remote server when
diff --git a/cache.h b/cache.h
index 991544c..d6348a1 100644
--- a/cache.h
+++ b/cache.h
@@ -478,6 +478,7 @@ enum rebase_setup_type {
extern enum branch_track git_branch_track;
extern enum rebase_setup_type autorebase;
+extern int keep_hard_links;
#define GIT_REPO_VERSION 0
extern int repository_format_version;
diff --git a/config.c b/config.c
index b8d289d..944e18e 100644
--- a/config.c
+++ b/config.c
@@ -490,6 +490,11 @@ static int git_default_core_config(const char *var, const char *value)
return 0;
}
+ if (!strcmp(var, "core.keephardlinks")) {
+ keep_hard_links = git_config_bool(var, value);
+ return 0;
+ }
+
/* Add other config variables here and to Documentation/config.txt. */
return 0;
}
diff --git a/entry.c b/entry.c
index aa2ee46..dfddf83 100644
--- a/entry.c
+++ b/entry.c
@@ -82,7 +82,8 @@ static void remove_subtree(const char *path)
static int create_file(const char *path, unsigned int mode)
{
mode = (mode & 0100) ? 0777 : 0666;
- return open(path, O_WRONLY | O_CREAT | O_EXCL, mode);
+ return open(path, O_WRONLY | O_CREAT |
+ (keep_hard_links ? O_TRUNC : O_EXCL), mode);
}
static void *read_blob_entry(struct cache_entry *ce, const char *path, unsigned long *size)
@@ -225,7 +226,9 @@ int checkout_entry(struct cache_entry *ce, const struct checkout *state, char *t
if (!state->force)
return error("%s is a directory", path);
remove_subtree(path);
- } else if (unlink(path))
+ } else if ((!keep_hard_links || !S_ISREG(st.st_mode) ||
+ st.st_mode != ce->ce_mode) &&
+ unlink(path))
return error("unable to unlink old '%s' (%s)", path, strerror(errno));
} else if (state->not_new)
return 0;
diff --git a/environment.c b/environment.c
index 0693cd9..ef721e0 100644
--- a/environment.c
+++ b/environment.c
@@ -42,6 +42,7 @@ enum safe_crlf safe_crlf = SAFE_CRLF_WARN;
unsigned whitespace_rule_cfg = WS_DEFAULT_RULE;
enum branch_track git_branch_track = BRANCH_TRACK_REMOTE;
enum rebase_setup_type autorebase = AUTOREBASE_NEVER;
+int keep_hard_links = 0;
/* This is set by setup_git_dir_gently() and/or git_default_config() */
char *git_work_tree_cfg;
diff --git a/t/t0056-hardlinked.sh b/t/t0056-hardlinked.sh
new file mode 100644
index 0000000..934c2bc
--- /dev/null
+++ b/t/t0056-hardlinked.sh
@@ -0,0 +1,58 @@
+#!/bin/sh
+
+test_description='read-tree and checkout respect hardlinked files'
+
+. ./test-lib.sh
+
+cat > file << EOF
+1. Nf3 Nf6 2. c4 g6 3. Nc3 Bg7 4. d4 O-O 5. Bf4 d5 6. Qb3 dxc4 7. Qxc4 c6
+8. e4 Nbd7 9. Rd1 Nb6 10. Qc5 Bg4 11. Bg5 Na4 12. Qa3 Nxc3 13. bxc3 Nxe4
+14. Bxe7 Qb6 15. Bc4 Nxc3 16. Bc5 Rfe8+ 17. Kf1 Be6 18. Bxb6 Bxc4+ 19. Kg1 Ne2+
+20. Kf1 Nxd4+ 21. Kg1 Ne2+ 22. Kf1 Nc3+ 23. Kg1 axb6 24. Qb4 Ra4 25. Qxb6 Nxd1
+26. h3 Rxa2 27. Kh2 Nxf2 28. Re1 Rxe1 29. Qd8+ Bf8 30. Nxe1 Bd5 31. Nf3 Ne4
+32. Qb8 b5 33. h4 h5 34. Ne5 Kg7 35. Kg1 Bc5+ 36. Kf1 Ng3+ 37. Ke1 Bb4+
+38. Kd1 Bb3+ 39. Kc1 Ne2+ 40. Kb1 Nc3+
+EOF
+
+ln file link || {
+ say "Could not hard link; skipping test"
+ test_done
+ exit
+}
+
+test_expect_success setup '
+
+ git config core.keepHardLinks true &&
+ test_cmp file link &&
+ cp file old &&
+ git add file &&
+ test_tick &&
+ git commit -m initial &&
+ echo "41. Kc1 Rc2#" >> file &&
+ git add file &&
+ test_tick &&
+ git commit -m 2nd &&
+ test_cmp file link &&
+ ! test_cmp file old
+
+'
+
+test_expect_success 'checking a file out does not break the hard link' '
+
+ git checkout HEAD^ -- file &&
+ test_cmp file link &&
+ test_cmp file old
+
+'
+
+test_expect_success 'read-tree -u -m does not break the hard link' '
+
+ git reset --hard &&
+ test_cmp file link &&
+ git read-tree -u -m HEAD^ &&
+ test_cmp file link &&
+ test_cmp file old
+
+'
+
+test_done
--
1.6.0.2.749.g0cc32
^ permalink raw reply related
* Re: [PATCH] Introduce core.keepHardLinks
From: Johannes Schindelin @ 2008-10-13 8:58 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, gitster
In-Reply-To: <20081012183855.GA5255@spearce.org>
Hi,
On Sun, 12 Oct 2008, Shawn O. Pearce wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > When a tracked file was hard linked, we used to break the hard link
> > whenever Git writes to that file. Make that optional.
>
> Why would anyone want to do this?
>
> I cannot fathom why a user wants this much rope to hang themselves
> with...
The question is not so much why anyone want to do this, but _if_.
And the answer is: yes.
Ciao,
Dscho
^ permalink raw reply
* Re: User Authentication ?
From: Jakub Narebski @ 2008-10-13 8:23 UTC (permalink / raw)
To: Neshama Parhoti; +Cc: git
In-Reply-To: <912ec82a0810130109k56e2e976kd00678e2ca3bc558@mail.gmail.com>
Neshama Parhoti wrote:
> On Sat, Oct 11, 2008 at 8:28 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> "Neshama Parhoti" <pneshama@gmail.com> writes:
>>
>>> I want to setup a git server on the web but I need user
>>> authentication.
>>> I really don't want to give ssh logins for people who I just want to
>>> be able to access my repository...
>>
>> First, you can always set git-shell as shell for those git only
>> accounts. [...]
>
> Thank you ! That should really be good. Any chance you are aware of
> documentation or further guidance about how to set this up ?
I have never had the need, but for Gitosis the seminal reference is
I think
"Hosting Git repositories, The Easy (and Secure) Way"
http://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way
--
Jakub Narebski
Poland
^ 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