* [PATCH] Add testcase to ensure merging an early part of a branch is done properly
From: Miklos Vajna @ 2008-10-13 20:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, git
In-Reply-To: <1217438608-28855-1-git-send-email-vmiklos@frugalware.org>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
[ Adding Shawn to CC as the interim maintainer. ]
On Wed, Jul 30, 2008 at 07:23:28PM +0200, Miklos Vajna <vmiklos@frugalware.org> wrote:
> Uh-oh. Here is a testcase that fails with master, but passes with your
> patch.
I remember you had a note about it's a bad habit to write a new test for
every bug, so here is an updated version that just improves
t7600-merge.sh and does not adds a new one.
t/t7600-merge.sh | 26 ++++++++++++++++++++++++++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/t/t7600-merge.sh b/t/t7600-merge.sh
index 7313ac2..a4443a7 100755
--- a/t/t7600-merge.sh
+++ b/t/t7600-merge.sh
@@ -520,4 +520,30 @@ test_expect_success 'refresh the index before merging' '
test_debug 'gitk --all'
+cat >expected <<EOF
+Merge branch 'c5' (early part)
+EOF
+
+test_expect_success 'merge early part of c2' '
+ git reset --hard c3 &&
+ echo c4 > c4.c &&
+ git add c4.c &&
+ git commit -m c4 &&
+ git tag c4 &&
+ echo c5 > c5.c &&
+ git add c5.c &&
+ git commit -m c5 &&
+ git tag c5 &&
+ git reset --hard c3 &&
+ echo c6 > c6.c &&
+ git add c6.c &&
+ git commit -m c6 &&
+ git tag c6 &&
+ git merge c5~1 &&
+ git show -s --pretty=format:%s HEAD > actual &&
+ test_cmp actual expected
+'
+
+test_debug 'gitk --all'
+
test_done
--
1.6.0.2
^ permalink raw reply related
* Re: [PATCH v2] Fix fetch/pull when run without --update-head-ok
From: Daniel Barkalow @ 2008-10-13 20:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git, spearce
In-Reply-To: <alpine.DEB.1.00.0810132001230.22125@pacific.mpi-cbg.de.mpi-cbg.de>
On Mon, 13 Oct 2008, Johannes Schindelin wrote:
> I actually understand now why the tests started failing: the change from
> resolve_ref() to get_branch() as requested by Daniel are at fault:
> get_branch() does not check if the branch has an initial commit.
>
> I am actually regretting making this change. Daniel, do you agree that it
> might be better to change back to resolve_ref(), so that the initial
> complaint (IIRC Han-Wen git pull'ed into a freshly initialized repository
> with that utterly bogus "git pull origin master:master" line) is not
> re-raised?
Is it, in fact, okay to fetch into the current branch if it's "yet to be
born"? I feel like it shouldn't be, since you'll get exactly the same
problem that you would if the branch already existed: the index reflects
the previous state (in this case, it's empty), so git will show that
you've staged removing all of the files, right? So this would make the
check for --update-head-ok more strict than before, but I think the
behavior change is correct.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: concerns about git
From: Brandon @ 2008-10-13 19:51 UTC (permalink / raw)
To: David Tweed; +Cc: Shawn O. Pearce, deepwinter, git
In-Reply-To: <e1dab3980810131140p45c62e5cs690ac190eeacc38e@mail.gmail.com>
You can use "git config core.worktree <location>" to create a ".git"
folder that manages a working copy in another location.
I know some of the GUI tools don't support this though so I would only
use it if truly necessary . (For example a using git to manage a
mapped network drive, it would be faster to keep the ".git" folder on
the local harddrive)
More documentation here: http://www.kernel.org/pub/software/scm/git/docs/
On Mon, Oct 13, 2008 at 2:40 PM, David Tweed <david.tweed@gmail.com> wrote:
> On Mon, Oct 13, 2008 at 7:19 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
>> # then every once in a while, or from a cron job
>> $ git push --all backup
>>
>> Of course since Git is distributed you can you use this same approach
>> to make backups to other systems. You can even edit the .git/config
>> to give the [remote "backup"] section more than one url line, so
>> that "git push --all backup" will send updated copies to multiple
>> locations at once.
>
> Another advantage of 'git push'ing to another repository (possibly via
> cron) as backup is that (for technical reasons) git push has to
> 'parse' the new changes to your repository in order to push, so it is
> likely to spot corruption (eg, dying disk) at that time and when you
> can decide what to do about it. (I have enough backups all over the
> place that I don't worry about not having a 'copy' of any stuff I care
> about, but that there'll be some fatal corruption I don't notice
> immediately that then gets propagated everywhere rendering them
> useless.)
>
> --
> cheers, dave tweed__________________________
> david.tweed@gmail.com
> Rm 124, School of Systems Engineering, University of Reading.
> "while having code so boring anyone can maintain it, use Python." --
> attempted insult seen on slashdot
> --
> 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
>
^ permalink raw reply
* [PATCH] git show-ref: add --remotes option.
From: Heikki Hokkanen @ 2008-10-13 19:23 UTC (permalink / raw)
To: git; +Cc: gitster
This works as --tags and --heads, limiting the outputted ref types.
Any combination of the three can be used.
Signed-off-by: Heikki Hokkanen <hoxu@users.sf.net>
---
Documentation/git-show-ref.txt | 10 ++++++----
builtin-show-ref.c | 12 +++++++++---
2 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-show-ref.txt b/Documentation/git-show-ref.txt
index 2f173ff..5aea2de 100644
--- a/Documentation/git-show-ref.txt
+++ b/Documentation/git-show-ref.txt
@@ -9,7 +9,8 @@ SYNOPSIS
--------
[verse]
'git show-ref' [-q|--quiet] [--verify] [-h|--head] [-d|--dereference]
- [-s|--hash] [--abbrev] [--tags] [--heads] [--] <pattern>...
+ [-s|--hash] [--abbrev] [--tags] [--heads] [--remotes]
+ [--] <pattern>...
'git show-ref' --exclude-existing[=pattern]
DESCRIPTION
@@ -36,10 +37,11 @@ OPTIONS
--tags::
--heads::
+--remotes::
- Limit to only "refs/heads" and "refs/tags", respectively. These
- options are not mutually exclusive; when given both, references stored
- in "refs/heads" and "refs/tags" are displayed.
+ Limit to only "refs/heads", "refs/tags" and "refs/remotes" respectively.
+ These options are not mutually exclusive; when given all, references
+ stored in "refs/heads", "refs/tags" and "refs/remotes" are displayed.
-d::
--dereference::
diff --git a/builtin-show-ref.c b/builtin-show-ref.c
index 572b114..d2362c2 100644
--- a/builtin-show-ref.c
+++ b/builtin-show-ref.c
@@ -5,10 +5,11 @@
#include "tag.h"
#include "string-list.h"
-static const char show_ref_usage[] = "git show-ref [-q|--quiet] [--verify] [-h|--head] [-d|--dereference] [-s|--hash[=<length>]] [--abbrev[=<length>]] [--tags] [--heads] [--] [pattern*] < ref-list";
+static const char show_ref_usage[] = "git show-ref [-q|--quiet] [--verify] [-h|--head] [-d|--dereference] [-s|--hash[=<length>]] [--abbrev[=<length>]] [--tags] [--heads] [--remotes] [--] [pattern*] < ref-list";
static int deref_tags = 0, show_head = 0, tags_only = 0, heads_only = 0,
- found_match = 0, verify = 0, quiet = 0, hash_only = 0, abbrev = 0;
+ remotes_only = 0, found_match = 0, verify = 0, quiet = 0, hash_only = 0,
+ abbrev = 0;
static const char **pattern;
static void show_one(const char *refname, const unsigned char *sha1)
@@ -26,11 +27,12 @@ static int show_ref(const char *refname, const unsigned char *sha1, int flag, vo
const char *hex;
unsigned char peeled[20];
- if (tags_only || heads_only) {
+ if (tags_only || heads_only || remotes_only) {
int match;
match = heads_only && !prefixcmp(refname, "refs/heads/");
match |= tags_only && !prefixcmp(refname, "refs/tags/");
+ match |= remotes_only && !prefixcmp(refname, "refs/remotes/");
if (!match)
return 0;
}
@@ -217,6 +219,10 @@ int cmd_show_ref(int argc, const char **argv, const char *prefix)
heads_only = 1;
continue;
}
+ if (!strcmp(arg, "--remotes")) {
+ remotes_only = 1;
+ continue;
+ }
if (!strcmp(arg, "--exclude-existing"))
return exclude_existing(NULL);
if (!prefixcmp(arg, "--exclude-existing="))
--
1.6.0.2.526.g5c283.dirty
^ permalink raw reply related
* Re: concerns about git
From: David Tweed @ 2008-10-13 18:40 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: deepwinter, git
In-Reply-To: <20081013181941.GT4856@spearce.org>
On Mon, Oct 13, 2008 at 7:19 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> # then every once in a while, or from a cron job
> $ git push --all backup
>
> Of course since Git is distributed you can you use this same approach
> to make backups to other systems. You can even edit the .git/config
> to give the [remote "backup"] section more than one url line, so
> that "git push --all backup" will send updated copies to multiple
> locations at once.
Another advantage of 'git push'ing to another repository (possibly via
cron) as backup is that (for technical reasons) git push has to
'parse' the new changes to your repository in order to push, so it is
likely to spot corruption (eg, dying disk) at that time and when you
can decide what to do about it. (I have enough backups all over the
place that I don't worry about not having a 'copy' of any stuff I care
about, but that there'll be some fatal corruption I don't notice
immediately that then gets propagated everywhere rendering them
useless.)
--
cheers, dave tweed__________________________
david.tweed@gmail.com
Rm 124, School of Systems Engineering, University of Reading.
"while having code so boring anyone can maintain it, use Python." --
attempted insult seen on slashdot
^ permalink raw reply
* Re: concerns about git
From: Shawn O. Pearce @ 2008-10-13 18:19 UTC (permalink / raw)
To: deepwinter; +Cc: git
In-Reply-To: <19959918.post@talk.nabble.com>
deepwinter <deepwinter@winterroot.net> wrote:
>
> i've been looking into using git for some version control and it looks
> great.. except for 1 thing that really disturbs me. why is the .git
> repository stored within the working copy? this is seems like a recipe for
> accidental deletion. if you are an individual using version control lets
> say for just your own work, there is a lot of security that is gained from
> at least having your repository within a different directory, or better on a
> different partition. this ensures that accidental deletions or hard drive
> crashes are less likely to result in loosing the ENTIRE project! of course,
> accidentally deleting your working copy is stupid, but it does happen. git
> seems to offer no protection against this kind of mistake for the individual
> coder.. or is there some way to have git put the actual repository files in
> a different directory? (can't find info on that)
Because every working copy is equal. They all have a copy of the
project's metadata in the .git/ directory.
If you want a backup, create one with clone and push to it every
so often, e.g.:
# one time setup
$ git clone --bare . /some/other/drive/project.git
$ git remote add backup /some/other/drive/project.git
# then every once in a while, or from a cron job
$ git push --all backup
Of course since Git is distributed you can you use this same approach
to make backups to other systems. You can even edit the .git/config
to give the [remote "backup"] section more than one url line, so
that "git push --all backup" will send updated copies to multiple
locations at once.
Who needs a central repository like SVN or CVS when you can have 3
or 4, on just as many disks, in different buildings, and possibly
different parts of the world. Yes, I keep my real work that I care
about backed up under different providers, with their data centers
located in different countries. And of course extra copies locally,
in case the 'net is down.
--
Shawn.
^ permalink raw reply
* concerns about git
From: deepwinter @ 2008-10-13 18:12 UTC (permalink / raw)
To: git
i've been looking into using git for some version control and it looks
great.. except for 1 thing that really disturbs me. why is the .git
repository stored within the working copy? this is seems like a recipe for
accidental deletion. if you are an individual using version control lets
say for just your own work, there is a lot of security that is gained from
at least having your repository within a different directory, or better on a
different partition. this ensures that accidental deletions or hard drive
crashes are less likely to result in loosing the ENTIRE project! of course,
accidentally deleting your working copy is stupid, but it does happen. git
seems to offer no protection against this kind of mistake for the individual
coder.. or is there some way to have git put the actual repository files in
a different directory? (can't find info on that)
--
View this message in context: http://www.nabble.com/concerns-about-git-tp19959918p19959918.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] Introduce core.keepHardLinks
From: Junio C Hamano @ 2008-10-13 18:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0810131950140.22125@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Mon, 13 Oct 2008, Junio C Hamano wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>> > - 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,
>>
>> These are non-arguments,
>
> Actually, they are arguments.
>
> The thing is: these editors do what they do for a reason. Which is
> exactly the second reason.
>
> When a user makes hard links, it is not just for fun and bullocks. It is
> not for copy-on-write either, that's not what hard links are supposed to
> do. It is for cases when you need the _same_ information in two places.
>
> I am not that big a user of hard links myself, but when I do, I know
> exactly what I am doing. And with my patch and that config variable set
> to true, Git will not interfer with that.
Ok, such a possible benefit should be described and defended better then.
I only thought of the scenario Shawn has brought up, which is a downside
of using this option without any conceivable upside, when I read your
patch and your rationale you repeated in a few messages that followed.
You could have said something like "The users may want to have a checkout,
and keep the same contents always appear elsewhere i.e. 'installing by
hardlinking'. In such a setup, editing the source with an editor
configured not to break hardlinks would still work fine, but git-checkout
will unconditionally break such links, which is undesirable. Such a setup
would want a configuration variable like this."
"It is not for fun and bullocks" is not a description any clearer than
what you kept repeating, but if you stated it like the above, then I would
not have had trouble understanding what you wanted to say.
The documentation update needs to warn about the Shawn's scenario. I also
do not know what this should do when you have two tracked paths with
identical contents hardlinked to each other. Because we do not track
hardlinks, I _think_ breaking links would be the right thing to do for
such paths regardless of this configuration variable.
It also raises another question. Don't you want this to be an attribute
for paths, not all-or-nothing configuration per repository?
^ permalink raw reply
* Re: [PATCH v2] Fix fetch/pull when run without --update-head-ok
From: Johannes Schindelin @ 2008-10-13 18:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, git, spearce
In-Reply-To: <7vod1obmlh.fsf@gitster.siamese.dyndns.org>
Hi,
thanks for doing the due diligence that I should have done (but I ran out
of time).
On Mon, 13 Oct 2008, Junio C Hamano wrote:
> The parts of the tests you fixed came from these:
>
> 6738c81 (send-pack: segfault fix on forced push, 2007-11-08)
This really wants to make sure that no objects are shared or hard-linked
between the repository in "trash directory/" and the one in its
subdirectory "another/". It predates "test_must_fail", too, it seems.
It never touches the working directory "another/", so using
--update-head-ok is okay.
> 4ebc914 (builtin-remote: prune remotes correctly ..., 2008-02-29)
This tests "git remote add"'s --mirror option.
It never touches the working directory either.
> 4942025 (t5510: test "git fetch" following tags minimally, 2008-09-21)
This test is actually not fixed, but contains two test cases for the issue
the commit fixes.
> 03db452 (Support gitlinks in fast-import., 2008-07-19)
This creates an empty repository for tests to fast-import, and fetches
into the current (not yet existing) branch.
I actually understand now why the tests started failing: the change from
resolve_ref() to get_branch() as requested by Daniel are at fault:
get_branch() does not check if the branch has an initial commit.
I am actually regretting making this change. Daniel, do you agree that it
might be better to change back to resolve_ref(), so that the initial
complaint (IIRC Han-Wen git pull'ed into a freshly initialized repository
with that utterly bogus "git pull origin master:master" line) is not
re-raised?
> 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).
The only test that would need fixing after reverting back to resolve_ref()
would be the "remote add --mirror" thing, which I think should be fine.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Improve and fix git-check-attr(1)
From: Jonas Fonseca @ 2008-10-13 17:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Always use 'verse' for multi-line synopsis sections. Add output and
example sections to document what output can be expected.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
Documentation/git-check-attr.txt | 63 +++++++++++++++++++++++++++++++++++++-
1 files changed, 62 insertions(+), 1 deletions(-)
At least the first chunk should be applied. The last is a quick attempt
at documenting the expected output formally and with examples.
diff --git a/Documentation/git-check-attr.txt b/Documentation/git-check-attr.txt
index 14e4374..09c5234 100644
--- a/Documentation/git-check-attr.txt
+++ b/Documentation/git-check-attr.txt
@@ -8,8 +8,9 @@ git-check-attr - Display gitattributes information.
SYNOPSIS
--------
+[verse]
'git check-attr' attr... [--] pathname...
-'git check-attr' --stdin [-z] attr... < <list-of-paths
+'git check-attr' --stdin [-z] attr... < <list-of-paths>
DESCRIPTION
-----------
@@ -30,6 +31,66 @@ OPTIONS
arguments as path names. If not supplied, only the first argument will
be treated as an attribute.
+OUTPUT
+------
+
+The output is of the form:
+<path> COLON SP <attribute> COLON SP <info> LF
+
+Where <path> is the path of a file being queried, <attribute> is an attribute
+being queried and <info> can be either:
+
+'unspecified';; when the attribute is not defined for the path.
+'unset';; when the attribute is defined to false.
+'set';; when the attribute is defined to true.
+<value>;; when a value has been assigned to the attribute.
+
+EXAMPLES
+--------
+
+In the following examples, the following '.gitattributes' file is used:
+---------------
+*.java diff=java -crlf myAttr
+README caveat=unspecified
+---------------
+
+* Output for an unspecified attribute:
+---------------
+$ git check-attr filter src/org/example/lib/MyClass.java
+src/org/example/lib/MyClass.java: filter: unspecified
+---------------
+
+* Output for an unset attribute:
+---------------
+$ git check-attr crlf src/org/example/lib/MyClass.java
+src/org/example/lib/MyClass.java: crlf: unset
+---------------
+
+* Output for an attribute that has been set:
+---------------
+$ git check-attr myAttr src/org/example/lib/MyClass.java
+src/org/example/lib/MyClass.java: myAttr: set
+---------------
+
+* Output for an attribute set to a value:
+---------------
+$ git check-attr diff src/org/example/lib/MyClass.java
+src/org/example/lib/MyClass.java: diff: java
+---------------
+
+* Listing multiple attributes for a file:
+---------------
+$ git check-attr crlf diff myAttr -- src/org/example/lib/MyClass.java
+src/org/example/lib/MyClass.java: crlf: unset
+src/org/example/lib/MyClass.java: diff: java
+src/org/example/lib/MyClass.java: myAttr: set
+---------------
+
+* Not all values are equally unambiguous:
+---------------
+$ git check-attr caveat README
+src/org/example/lib/MyClass.java: caveat: unspecified
+---------------
SEE ALSO
--------
--
tg: (340fcf4..) jf/man-git-check-attr (depends on: next)
--
Jonas Fonseca
^ permalink raw reply related
* Re: [PATCH v2] Fix fetch/pull when run without --update-head-ok
From: Johannes Schindelin @ 2008-10-13 17:57 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Daniel Barkalow, git, gitster
In-Reply-To: <20081013140938.GM4856@spearce.org>
Hi,
On Mon, 13 Oct 2008, Shawn O. Pearce wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > 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. :-\
Heh. My "this time" was meant as "since the first revision of the patch".
I really tested the first revision, promise! And those tests did not fail
back then. Or I am even stupider than I am prepared to admit.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Introduce core.keepHardLinks
From: Johannes Schindelin @ 2008-10-13 17:55 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Stephan Beyer, Junio C Hamano, git
In-Reply-To: <20081013162351.GQ4856@spearce.org>
Hi,
On Mon, 13 Oct 2008, Shawn O. Pearce wrote:
> Stephan Beyer <s-beyer@gmx.net> wrote:
> > Johannes Schindelin wrote:
> > > and I would have expected others to need a lot less arguments
> > > to see it that way, too.
> >
> > Despite the fact that I've never used hardlinks in a git repository, I
> > would have expected git to keep them. So I'm one of the "others" who
> > thinks this config option is just sane (and should perhaps even be
> > enabled by default, if it does not break stuff on file systems that do
> > not have a hardlink feature... but ok)
>
> My problem is many users do "cp -rl a b" to clone a->b and hardlink the
> working directory. They expect "cd b && git checkout foo" to then only
> unlink the paths that differ. Updating the original inode would break
> repository a.
>
> Its a change in behavior, to some of our oldest users. So it can't
> really be on by default.
Which is the reason why my commit is not titled "Make Git respect hard
links by default", but "Introduce core.keepHardLinks". I also hate people
who try to break my setup.
Which scenario (breaking someone's setup) was exactly what triggered this
patch.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Introduce core.keepHardLinks
From: Johannes Schindelin @ 2008-10-13 17:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhc7g9z7s.fsf@gitster.siamese.dyndns.org>
Hi,
On Mon, 13 Oct 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > - 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,
>
> These are non-arguments,
Actually, they are arguments.
The thing is: these editors do what they do for a reason. Which is
exactly the second reason.
When a user makes hard links, it is not just for fun and bullocks. It is
not for copy-on-write either, that's not what hard links are supposed to
do. It is for cases when you need the _same_ information in two places.
I am not that big a user of hard links myself, but when I do, I know
exactly what I am doing. And with my patch and that config variable set
to true, Git will not interfer with that.
Ciao,
Dscho
^ permalink raw reply
* [JGIT PATCH 2/2] Add --[no-]thin and --[no-]fsck optiosn to fetch command line tool
From: Shawn O. Pearce @ 2008-10-13 17:36 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <1223919401-15873-1-git-send-email-spearce@spearce.org>
This way users can force verification on the fly, such as when
fetching from an untrusted URL pasted on the command line.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../src/org/spearce/jgit/pgm/Fetch.java | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/org.spearce.jgit.pgm/src/org/spearce/jgit/pgm/Fetch.java b/org.spearce.jgit.pgm/src/org/spearce/jgit/pgm/Fetch.java
index e14e213..ad7e08f 100644
--- a/org.spearce.jgit.pgm/src/org/spearce/jgit/pgm/Fetch.java
+++ b/org.spearce.jgit.pgm/src/org/spearce/jgit/pgm/Fetch.java
@@ -54,6 +54,22 @@
@Option(name = "--verbose", aliases = { "-v" }, usage = "be more verbose")
private boolean verbose;
+ @Option(name = "--fsck", usage = "perform fsck style checks on receive")
+ private Boolean fsck;
+
+ @Option(name = "--no-fsck")
+ void nofsck(final boolean ignored) {
+ fsck = Boolean.FALSE;
+ }
+
+ @Option(name = "--thin", usage = "fetch thin pack")
+ private Boolean thin;
+
+ @Option(name = "--no-thin")
+ void nothin(final boolean ignored) {
+ thin = Boolean.FALSE;
+ }
+
@Argument(index = 0, metaVar = "uri-ish")
private String remote = "origin";
@@ -63,6 +79,10 @@
@Override
protected void run() throws Exception {
final Transport tn = Transport.open(db, remote);
+ if (fsck != null)
+ tn.setCheckFetchedObjects(fsck.booleanValue());
+ if (thin != null)
+ tn.setFetchThin(thin.booleanValue());
final FetchResult r;
try {
r = tn.fetch(new TextProgressMonitor(), toget);
--
1.6.0.2.706.g340fc
^ permalink raw reply related
* [JGIT PATCH 1/2] Check object connectivity during fetch if fsck is enabled
From: Shawn O. Pearce @ 2008-10-13 17:36 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
If we are fetching over a pack oriented connection and we are doing
object-level fsck validation we need to also verify the graph is
fully connected after the fetch is complete. This additional check
is necessary to ensure the peer didn't omit objects that we don't
have, but which are listed as needing to be present.
On the walk style fetch connection we can bypass this check, as the
connectivity was implicitly verified by the walker as it downloaded
objects and built its queue of things to fetch. Native pack and
bundle transports however do not have this check built into them,
and require that we execute the work ourselves.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
This is a follow-on to my fsck during fetch series, which is already
in master. Making calls to ObjectChecker isn't enough as it does
not check the DAG's connectivity.
.../jgit/transport/BasePackFetchConnection.java | 4 +++
.../spearce/jgit/transport/FetchConnection.java | 22 ++++++++++++++++++++
.../org/spearce/jgit/transport/FetchProcess.java | 13 ++++++++++-
.../spearce/jgit/transport/TransportBundle.java | 4 +++
.../jgit/transport/WalkFetchConnection.java | 4 +++
5 files changed, 45 insertions(+), 2 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/BasePackFetchConnection.java b/org.spearce.jgit/src/org/spearce/jgit/transport/BasePackFetchConnection.java
index a542eb7..542a8a9 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/BasePackFetchConnection.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/BasePackFetchConnection.java
@@ -146,6 +146,10 @@ public boolean didFetchIncludeTags() {
return false;
}
+ public boolean didFetchTestConnectivity() {
+ return false;
+ }
+
protected void doFetch(final ProgressMonitor monitor,
final Collection<Ref> want) throws TransportException {
try {
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/FetchConnection.java b/org.spearce.jgit/src/org/spearce/jgit/transport/FetchConnection.java
index 9d25b0d..d93972d 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/FetchConnection.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/FetchConnection.java
@@ -111,4 +111,26 @@ public void fetch(final ProgressMonitor monitor, final Collection<Ref> want)
* false if tags were not implicitly obtained.
*/
public boolean didFetchIncludeTags();
+
+ /**
+ * Did the last {@link #fetch(ProgressMonitor, Collection)} validate graph?
+ * <p>
+ * Some transports walk the object graph on the client side, with the client
+ * looking for what objects it is missing and requesting them individually
+ * from the remote peer. By virtue of completing the fetch call the client
+ * implicitly tested the object connectivity, as every object in the graph
+ * was either already local or was requested successfully from the peer. In
+ * such transports this method returns true.
+ * <p>
+ * Some transports assume the remote peer knows the Git object graph and is
+ * able to supply a fully connected graph to the client (although it may
+ * only be transferring the parts the client does not yet have). Its faster
+ * to assume such remote peers are well behaved and send the correct
+ * response to the client. In such tranports this method returns false.
+ *
+ * @return true if the last fetch had to perform a connectivity check on the
+ * client side in order to succeed; false if the last fetch assumed
+ * the remote peer supplied a complete graph.
+ */
+ public boolean didFetchTestConnectivity();
}
\ No newline at end of file
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/FetchProcess.java b/org.spearce.jgit/src/org/spearce/jgit/transport/FetchProcess.java
index 654572d..bb2d051 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/FetchProcess.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/FetchProcess.java
@@ -118,7 +118,7 @@ else if (tagopt == TagOpt.FETCH_TAGS)
final boolean includedTags;
if (!askFor.isEmpty() && !askForIsComplete()) {
- conn.fetch(monitor, askFor.values());
+ fetchObjects(monitor);
includedTags = conn.didFetchIncludeTags();
// Connection was used for object transfer. If we
@@ -143,7 +143,7 @@ else if (tagopt == TagOpt.FETCH_TAGS)
if (!askFor.isEmpty() && (!includedTags || !askForIsComplete())) {
reopenConnection();
if (!askFor.isEmpty())
- conn.fetch(monitor, askFor.values());
+ fetchObjects(monitor);
}
}
} finally {
@@ -171,6 +171,15 @@ else if (tagopt == TagOpt.FETCH_TAGS)
}
}
+ private void fetchObjects(final ProgressMonitor monitor)
+ throws TransportException {
+ conn.fetch(monitor, askFor.values());
+ if (transport.isCheckFetchedObjects()
+ && !conn.didFetchTestConnectivity() && !askForIsComplete())
+ throw new TransportException(transport.getURI(),
+ "peer did not supply a complete object graph");
+ }
+
private void closeConnection() {
if (conn != null) {
conn.close();
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/TransportBundle.java b/org.spearce.jgit/src/org/spearce/jgit/transport/TransportBundle.java
index 5b321a0..7d38b02 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/TransportBundle.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/TransportBundle.java
@@ -165,6 +165,10 @@ private String readLine(final byte[] hdrbuf) throws IOException {
return RawParseUtils.decode(Constants.CHARSET, hdrbuf, 0, lf);
}
+ public boolean didFetchTestConnectivity() {
+ return false;
+ }
+
@Override
protected void doFetch(final ProgressMonitor monitor,
final Collection<Ref> want) throws TransportException {
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/WalkFetchConnection.java b/org.spearce.jgit/src/org/spearce/jgit/transport/WalkFetchConnection.java
index 5638454..d089f7b 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/WalkFetchConnection.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/WalkFetchConnection.java
@@ -189,6 +189,10 @@ WalkFetchConnection(final WalkTransport wt, final WalkRemoteObjectDatabase w) {
workQueue = new LinkedList<ObjectId>();
}
+ public boolean didFetchTestConnectivity() {
+ return true;
+ }
+
@Override
protected void doFetch(final ProgressMonitor monitor,
final Collection<Ref> want) throws TransportException {
--
1.6.0.2.706.g340fc
^ permalink raw reply related
* Re: [PATCH] Introduce core.keepHardLinks
From: Junio C Hamano @ 2008-10-13 17:33 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0810131611470.22125@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> - 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,
These are non-arguments, when you are asked to give rationale for adding
capability to "ask for hard links" to begin with.
IOW, the question was why git should support tracked contents being
hardlinked to something else.
[jc: Sorry for dropping Shawn from CC: list. pobox.com seems to complain
on his address for some reason. Here are msmtp log for an identical
message with and without him on the recipient list.
Oct 13 10:23:57 host=sasl.smtp.pobox.com tls=on auth=on user=junio@pobox.com from=junio@pobox.com recipients=Johannes.Schindelin@gmx.de,barkalow@iabervon.org,git@vger.kernel.org,spearce@spearce.org,gitster@pobox.com smtpstatus=451 smtpmsg='451 4.3.5 Server configuration problem' errormsg='recipient address spearce@spearce.org not accepted by the server' exitcode=EX_DATAERR
Oct 13 10:31:26 host=sasl.smtp.pobox.com tls=on auth=on user=junio@pobox.com from=junio@pobox.com recipients=Johannes.Schindelin@gmx.de,barkalow@iabervon.org,git@vger.kernel.org,gitster@pobox.com mailsize=2283 exitcode=EX_OK
]
^ permalink raw reply
* Re: [PATCH v2] Fix fetch/pull when run without --update-head-ok
From: Junio C Hamano @ 2008-10-13 17:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Daniel Barkalow, git
In-Reply-To: <7vod1obmlh.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> 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).
Proposed amendment to the commit log message is:
Fix fetch/pull when run without --update-head-ok
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". This should only be
allowed when (an incorrect) "git pull origin master:master" tries to work
around by giving --update-head-ok to underlying "git fetch", and otherwise
we should refuse it, but somewhere along the lines we lost that behavior.
The check for the current branch is now _only_ performed in non-bare
repositories, which is an improvement from the original behaviour.
Some newer tests were depending on the broken behaviour of "git fetch"
this patch fixes, and have been adjusted.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Thanks for the fix.
^ permalink raw reply
* Re: [JGIT PATCH 4/4] Intelligent parsing of ambiguously encoded meta data.
From: Robin Rosenberg @ 2008-10-13 17:10 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20081013022708.GJ4856@spearce.org>
måndagen den 13 oktober 2008 04.27.08 skrev Shawn O. Pearce:
> Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> > We cannot trust meta data to be encoded in any particular way, so we try
> > different encodings. First we try UTF-8, which is the only sane encoding
> > for non-local data, even when used in regions where eight bit legacy
> > encodings are common. The chance of mistakenly parsing non-UTF-8 data
> > as valid UTF-8 is varies from extremely low (western encodings) to low
> > for most other encodings. If the data does not look like UTF-8, we try the
> > suggested encoding. If that fails we try the user locale and finally, if
> > that fails we try ISO-8859-1, which cannot fail.
>
> Hmm. I'm concerned about the infinite loop you have here.
> If ISO-8859-1 fails we'd be stuck here until the end of time.
> Plus its a bit ugly to read.
>
> I wonder if this is any better. It passes your tests and is 2
> lines shorter.
Yes. Not sure what I was thinking with the loop there... :)
-- robin
^ permalink raw reply
* Re: [PATCH v2] Fix fetch/pull when run without --update-head-ok
From: Daniel Barkalow @ 2008-10-13 17:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster, spearce
In-Reply-To: <alpine.DEB.1.00.0810131129110.22125@pacific.mpi-cbg.de.mpi-cbg.de>
On Mon, 13 Oct 2008, Johannes Schindelin 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: Daniel Barkalow <barkalow@iabervon.org>
^ permalink raw reply
* Re: [JGIT PATCH 0/5] Support receive.fsckobjects
From: Shawn O. Pearce @ 2008-10-13 16:54 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <1223916746-11262-1-git-send-email-spearce@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> wrote:
> This series adds support for receive.fsckobjects, but on the fetch
Sorry for the noise. Left over cover letter from a prior series.
/me adds a check for that to his format-patch wrapper...
--
Shawn.
^ permalink raw reply
* [JGIT PATCH] Add bundle creation support
From: Shawn O. Pearce @ 2008-10-13 16:52 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <1223916746-11262-1-git-send-email-spearce@spearce.org>
BundleWriter offers a safe API to create new bundles.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
I wrote this a while back but haven't had a chance to write unit
tests for it. It may be worthwhile including as it looks to be
obviously correct and is probably necessary to create pure Java
based unit tests for the bundle fetch transport.
.../org/spearce/jgit/transport/BundleWriter.java | 196 ++++++++++++++++++++
1 files changed, 196 insertions(+), 0 deletions(-)
create mode 100644 org.spearce.jgit/src/org/spearce/jgit/transport/BundleWriter.java
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/BundleWriter.java b/org.spearce.jgit/src/org/spearce/jgit/transport/BundleWriter.java
new file mode 100644
index 0000000..f0fbd37
--- /dev/null
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/BundleWriter.java
@@ -0,0 +1,196 @@
+/*
+ * Copyright (C) 2008, Google Inc.
+ *
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * - Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above
+ * copyright notice, this list of conditions and the following
+ * disclaimer in the documentation and/or other materials provided
+ * with the distribution.
+ *
+ * - Neither the name of the Git Development Community nor the
+ * names of its contributors may be used to endorse or promote
+ * products derived from this software without specific prior
+ * written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ * CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+ * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+ * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
+ * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+package org.spearce.jgit.transport;
+
+import java.io.BufferedOutputStream;
+import java.io.IOException;
+import java.io.OutputStream;
+import java.io.OutputStreamWriter;
+import java.io.Writer;
+import java.util.HashSet;
+import java.util.Map;
+import java.util.Set;
+import java.util.TreeMap;
+
+import org.spearce.jgit.lib.AnyObjectId;
+import org.spearce.jgit.lib.Constants;
+import org.spearce.jgit.lib.ObjectId;
+import org.spearce.jgit.lib.PackWriter;
+import org.spearce.jgit.lib.ProgressMonitor;
+import org.spearce.jgit.lib.Ref;
+import org.spearce.jgit.lib.Repository;
+import org.spearce.jgit.revwalk.RevCommit;
+
+/**
+ * Creates a Git bundle file, for sneaker-net transport to another system.
+ * <p>
+ * Bundles generated by this class can be later read in from a file URI using
+ * the bundle transport, or from an application controlled buffer by the more
+ * generic {@link TransportBundleStream}.
+ * <p>
+ * Applications creating bundles need to call one or more <code>include</code>
+ * calls to reflect which objects should be available as refs in the bundle for
+ * the other side to fetch. At least one include is required to create a valid
+ * bundle file, and duplicate names are not permitted.
+ * <p>
+ * Optional <code>assume</code> calls can be made to declare commits which the
+ * recipient must have in order to fetch from the bundle file. Objects reachable
+ * from these assumed commits can be used as delta bases in order to reduce the
+ * overall bundle size.
+ */
+public class BundleWriter {
+ private final PackWriter packWriter;
+
+ private final Map<String, ObjectId> include;
+
+ private final Set<RevCommit> assume;
+
+ /**
+ * Create a writer for a bundle.
+ *
+ * @param repo
+ * repository where objects are stored.
+ * @param monitor
+ * operations progress monitor.
+ */
+ public BundleWriter(final Repository repo, final ProgressMonitor monitor) {
+ packWriter = new PackWriter(repo, monitor);
+ include = new TreeMap<String, ObjectId>();
+ assume = new HashSet<RevCommit>();
+ }
+
+ /**
+ * Include an object (and everything reachable from it) in the bundle.
+ *
+ * @param name
+ * name the recipient can discover this object as from the
+ * bundle's list of advertised refs . The name must be a valid
+ * ref format and must not have already been included in this
+ * bundle writer.
+ * @param id
+ * object to pack. Multiple refs may point to the same object.
+ */
+ public void include(final String name, final AnyObjectId id) {
+ if (!Repository.isValidRefName(name))
+ throw new IllegalArgumentException("Invalid ref name: " + name);
+ if (include.containsKey(name))
+ throw new IllegalStateException("Duplicate ref: " + name);
+ include.put(name, id.toObjectId());
+ }
+
+ /**
+ * Include a single ref (a name/object pair) in the bundle.
+ * <p>
+ * This is a utility function for:
+ * <code>include(r.getName(), r.getObjectId())</code>.
+ *
+ * @param r
+ * the ref to include.
+ */
+ public void include(final Ref r) {
+ include(r.getName(), r.getObjectId());
+ }
+
+ /**
+ * Assume a commit is available on the recipient's side.
+ * <p>
+ * In order to fetch from a bundle the recipient must have any assumed
+ * commit. Each assumed commit is explicitly recorded in the bundle header
+ * to permit the recipient to validate it has these objects.
+ *
+ * @param c
+ * the commit to assume being available. This commit should be
+ * parsed and not disposed in order to maximize the amount of
+ * debugging information available in the bundle stream.
+ */
+ public void assume(final RevCommit c) {
+ if (c != null)
+ assume.add(c);
+ }
+
+ /**
+ * Generate and write the bundle to the output stream.
+ * <p>
+ * This method can only be called once per BundleWriter instance.
+ *
+ * @param os
+ * the stream the bundle is written to. If the stream is not
+ * buffered it will be buffered by the writer. Caller is
+ * responsible for closing the stream.
+ * @throws IOException
+ * an error occurred reading a local object's data to include in
+ * the bundle, or writing compressed object data to the output
+ * stream.
+ */
+ public void writeBundle(OutputStream os) throws IOException {
+ if (!(os instanceof BufferedOutputStream))
+ os = new BufferedOutputStream(os);
+
+ final HashSet<ObjectId> inc = new HashSet<ObjectId>();
+ final HashSet<ObjectId> exc = new HashSet<ObjectId>();
+ inc.addAll(include.values());
+ for (final RevCommit r : assume)
+ exc.add(r.getId());
+ packWriter.preparePack(inc, exc, exc.size() > 0, true);
+
+ final Writer w = new OutputStreamWriter(os, Constants.CHARSET);
+ w.write(TransportBundle.V2_BUNDLE_SIGNATURE);
+ w.write('\n');
+
+ final char[] tmp = new char[Constants.OBJECT_ID_LENGTH * 2];
+ for (final RevCommit a : assume) {
+ w.write('-');
+ a.copyTo(tmp, w);
+ if (a.getRawBuffer() != null) {
+ w.write(' ');
+ w.write(a.getShortMessage());
+ }
+ w.write('\n');
+ }
+ for (final Map.Entry<String, ObjectId> e : include.entrySet()) {
+ e.getValue().copyTo(tmp, w);
+ w.write(' ');
+ w.write(e.getKey());
+ w.write('\n');
+ }
+
+ w.write('\n');
+ w.flush();
+ packWriter.writePack(os);
+ }
+}
--
1.6.0.2.706.g340fc
^ permalink raw reply related
* [JGIT PATCH 0/5] Support receive.fsckobjects
From: Shawn O. Pearce @ 2008-10-13 16:52 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
This series adds support for receive.fsckobjects, but on the fetch
side of the connection. Perhaps it should be transfer.fsckobjects
or fetch.fsckobjects, but git.git doesn't support either of those
right now.
I mainly need this series because I'm fetching out of untrusted
bundles. The content of the bundle has to pass git-fsck for it
to be considered safe.
The ObjectChecker class covers the same rules as git-fsck does, and
is perhaps even stricter on some of the things git-fsck lets slide.
I think git-fsck is too lenient in some areas, and I'd like to try
and improve the rules more in git.git, but I don't have time for
it right now.
Shawn O. Pearce (5):
Expose RawParseUtils.match to application callers
Fix UnpackedObjectLoader.getBytes to return a copy
Object validation tests for "jgit fsck"
Expose the critical receive configuration options to JGit
Honor receive.fsckobjects during any fetch connection
.../org/spearce/jgit/lib/ObjectCheckerTest.java | 1294 ++++++++++++++++++++
.../src/org/spearce/jgit/lib/ObjectChecker.java | 352 ++++++
.../src/org/spearce/jgit/lib/ObjectLoader.java | 7 +-
.../org/spearce/jgit/lib/PackedObjectLoader.java | 7 -
.../src/org/spearce/jgit/lib/RepositoryConfig.java | 10 +
.../src/org/spearce/jgit/lib/TransferConfig.java | 56 +
.../org/spearce/jgit/lib/UnpackedObjectLoader.java | 4 -
.../jgit/transport/BasePackFetchConnection.java | 1 +
.../src/org/spearce/jgit/transport/IndexPack.java | 60 +-
.../src/org/spearce/jgit/transport/Transport.java | 24 +
.../spearce/jgit/transport/TransportBundle.java | 10 +-
.../jgit/transport/WalkFetchConnection.java | 26 +-
.../src/org/spearce/jgit/util/RawParseUtils.java | 23 +-
13 files changed, 1842 insertions(+), 32 deletions(-)
create mode 100644 org.spearce.jgit.test/tst/org/spearce/jgit/lib/ObjectCheckerTest.java
create mode 100644 org.spearce.jgit/src/org/spearce/jgit/lib/ObjectChecker.java
create mode 100644 org.spearce.jgit/src/org/spearce/jgit/lib/TransferConfig.java
^ permalink raw reply
* Re: [PATCH] Introduce core.keepHardLinks
From: Shawn O. Pearce @ 2008-10-13 16:23 UTC (permalink / raw)
To: Stephan Beyer; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <20081013162132.GB20371@leksak.fem-net>
Stephan Beyer <s-beyer@gmx.net> wrote:
> Johannes Schindelin wrote:
> > and I would have expected others to need a lot less arguments
> > to see it that way, too.
>
> Despite the fact that I've never used hardlinks in a git repository, I
> would have expected git to keep them. So I'm one of the "others" who
> thinks this config option is just sane (and should perhaps even be
> enabled by default, if it does not break stuff on file systems that do
> not have a hardlink feature... but ok)
My problem is many users do "cp -rl a b" to clone a->b and hardlink
the working directory. They expect "cd b && git checkout foo" to
then only unlink the paths that differ. Updating the original inode
would break repository a.
Its a change in behavior, to some of our oldest users. So it can't
really be on by default.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Introduce core.keepHardLinks
From: Stephan Beyer @ 2008-10-13 16:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Shawn O. Pearce, git
In-Reply-To: <alpine.DEB.1.00.0810131611470.22125@pacific.mpi-cbg.de.mpi-cbg.de>
Hi,
Johannes Schindelin wrote:
> and I would have expected others to need a lot less arguments
> to see it that way, too.
Despite the fact that I've never used hardlinks in a git repository, I
would have expected git to keep them. So I'm one of the "others" who
thinks this config option is just sane (and should perhaps even be
enabled by default, if it does not break stuff on file systems that do
not have a hardlink feature... but ok)
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* 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
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