* Re: [ANNOUNCE] tig-0.9
From: Steven Grimm @ 2007-09-14 17:32 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Jonas Fonseca, git
In-Reply-To: <F6776054-00EC-49E8-B4C8-BB0EAB3939AB@silverinsanity.com>
Brian Gernhardt wrote:
> Complete build failure using autoconf here. Just using the Makefile
> like I always have works fine, but "autoconf ; ./configure" (from the
> git repo) fails with "configure: error: iconv() not found. Please
> install libiconv." This confuses me because I have
> /usr/lib/libiconv.dylib, and compiling with -liconv works. I fail to
> have the autoconf-foo to figure out what's wrong.
Try "aclocal ; autoconf ; ./configure".
-Steve
^ permalink raw reply
* [PATCH 2/2] Fix the rename detection limit checking
From: Linus Torvalds @ 2007-09-14 17:39 UTC (permalink / raw)
To: Junio C Hamano
Cc: Dmitry V. Levin, Shawn O. Pearce, Git Mailing List, Jeff King
In-Reply-To: <alpine.LFD.0.999.0709141014130.16478@woody.linux-foundation.org>
This adds more proper rename detection limits. Instead of just checking
the limit against the number of potential rename destinations, we verify
that the rename matrix (which is what really matters) doesn't grow
ridiculously large, and we also make sure that we don't overflow when
doing the matrix size calculation.
This also changes the default limits from unlimited, to a rename matrix
that is limited to 100 entries on a side. You can raise it with the config
entry, or by using the "-l<n>" command line flag, but at least the default
is now a sane number that avoids spending lots of time (and memory) in
situations that likely don't merit it.
The choice of default value is of course very debatable. Limiting the
rename matrix to a 100x100 size will mean that even if you have just one
obvious rename, but you also create (or delete) 10,000 files, the rename
matrix will be so big that we disable the heuristics. Sounds reasonable to
me, but let's see if people hit this (and, perhaps more importantly,
actually *care*) in real life.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
Due to the overflow issue (and yes, Dmitry's test-case actually triggered
an overflow even on 64-bit machines, because the math was done on "int"
types), I really think this was a real bug.
Now, whether this is necessarily the right way to fix it, I dunno, but it
also *does* fix the old broken limit handling that was based just on the
number of target files, and didn't take the number of potential source
files into account.
But the fix to that logic also means that the meaning of "-l<n>" changes
subtly. For the better, I think, but changes nonetheless.
I'd also like to apologize to the change in wt-status.c, but that code
doesn't use the regular diffopt setup logic, so it really is a special
case and needs to be handled as such. Do we want to teach "git runstatus"
to actually honor command line flags for diff generation etc? That's a
separate question, this patch just makes it use the same rename default as
the normal diffs now do.
diff.c | 2 +-
diffcore-rename.c | 19 +++++++++++++++++--
wt-status.c | 1 +
3 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/diff.c b/diff.c
index 1aca5df..0ee9ea1 100644
--- a/diff.c
+++ b/diff.c
@@ -17,7 +17,7 @@
#endif
static int diff_detect_rename_default;
-static int diff_rename_limit_default = -1;
+static int diff_rename_limit_default = 100;
static int diff_use_color_default;
int diff_auto_refresh_index = 1;
diff --git a/diffcore-rename.c b/diffcore-rename.c
index 6bde439..41b35c3 100644
--- a/diffcore-rename.c
+++ b/diffcore-rename.c
@@ -298,10 +298,25 @@ void diffcore_rename(struct diff_options *options)
else if (detect_rename == DIFF_DETECT_COPY)
register_rename_src(p->one, 1, p->score);
}
- if (rename_dst_nr == 0 || rename_src_nr == 0 ||
- (0 < rename_limit && rename_limit < rename_dst_nr))
+ if (rename_dst_nr == 0 || rename_src_nr == 0)
goto cleanup; /* nothing to do */
+ /*
+ * This basically does a test for the rename matrix not
+ * growing larger than a "rename_limit" square matrix, ie:
+ *
+ * rename_dst_nr * rename_src_nr > rename_limit * rename_limit
+ *
+ * but handles the potential overflow case specially (and we
+ * assume at least 32-bit integers)
+ */
+ if (rename_limit <= 0 || rename_limit > 32767)
+ rename_limit = 32767;
+ if (rename_dst_nr > rename_limit && rename_src_nr > rename_limit)
+ goto cleanup;
+ if (rename_dst_nr * rename_src_nr > rename_limit * rename_limit)
+ goto cleanup;
+
/* We really want to cull the candidates list early
* with cheap tests in order to avoid doing deltas.
* The first round matches up the up-to-date entries,
diff --git a/wt-status.c b/wt-status.c
index 5205420..10ce6ee 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -227,6 +227,7 @@ static void wt_status_print_updated(struct wt_status *s)
rev.diffopt.format_callback = wt_status_print_updated_cb;
rev.diffopt.format_callback_data = s;
rev.diffopt.detect_rename = 1;
+ rev.diffopt.rename_limit = 100;
wt_read_cache(s);
run_diff_index(&rev, 1);
}
^ permalink raw reply related
* Re: [ANNOUNCE] tig-0.9
From: Brian Gernhardt @ 2007-09-14 17:44 UTC (permalink / raw)
To: Steven Grimm; +Cc: Jonas Fonseca, git
In-Reply-To: <46EAC5C4.6020403@midwinter.com>
On Sep 14, 2007, at 1:32 PM, Steven Grimm wrote:
> Brian Gernhardt wrote:
>> Complete build failure using autoconf here. Just using the
>> Makefile like I always have works fine, but "autoconf ; ./
>> configure" (from the git repo) fails with "configure: error: iconv
>> () not found. Please install libiconv." This confuses me because
>> I have /usr/lib/libiconv.dylib, and compiling with -liconv works.
>> I fail to have the autoconf-foo to figure out what's wrong.
>
> Try "aclocal ; autoconf ; ./configure".
Yes, remembering to regenerate the configure script would have been
smart. Works perfectly, thank you.
~~ Brian
^ permalink raw reply
* StGIT patch editing command
From: Catalin Marinas @ 2007-09-14 17:57 UTC (permalink / raw)
To: GIT list
Hi,
Since some people mentioned in the past that it would be nice to be
able to edit patches, including the diff, I added the 'edit' command
in today's snapshot (and StGIT repository).
The command moves the editing features from 'refresh' into a separate
(and improved) command. In addition, it allows one to modify the diff
directly with the '--diff' option. The command also parses the From:
and Date: fields in the patch description so that the author and date
information can be modified.
'stg help edit' displays more information.
Enjoy :-)
--
Catalin
^ permalink raw reply
* Re: git commit workflow question
From: Shawn O. Pearce @ 2007-09-14 18:14 UTC (permalink / raw)
To: Brian Swetland; +Cc: git
In-Reply-To: <20070914103348.GA22621@bulgaria>
Brian Swetland <swetland@google.com> wrote:
> With perforce I often have a bunch of files modified (having p4 add'd
> or p4 edit'd them) and then only commit a subset of them. I can do
> this interactively by doing a p4 submit and just removing the files
> I don't want to check in from the list in the changelist description
> when I'm writing up the change description in $EDITOR, invoked by
> p4 submit.
>
> It seems like my options with git are to invoke git commit with
> a specific list of things to commit, invoke git commit --interactive
> and use the interactive menu thing to shuffle stuff around, or
> manually unstage things until I have the index in a state where
> a git commit without other arguments will do what I want.
Or use git-citool/git-gui to make commits, in which case that
will help you to arrange the index with what you want to commit.
But yes, git-commit does not pay any attention to modifications
made to the template in the edit buffer.
I'm not sure how the Git community would react to being able to edit
the list of files being committed from within the commit message
buffer. I think most Git users run at least `git diff --cached`
before they commit to make sure they are happy with the difference.
I know a lot of users who do that. Most/all of those users also do
not stage something into the index until they are happy with the
change, which means there isn't any list of files to remove when
it comes time to make the commit as the contents of the index is
exactly what should be committed.
I used p4 for a while before Git was invented. I found the file
editing feature useful then because there was no concept of the
index. Now with Git I've embraced the index so much that I'm not
sure I can work without it, and I don't need to remove files from
my index during the actual commit itself.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 1/2] Fix "git diff" setup code
From: Junio C Hamano @ 2007-09-14 18:19 UTC (permalink / raw)
To: Linus Torvalds
Cc: Dmitry V. Levin, Shawn O. Pearce, Git Mailing List, Jeff King
In-Reply-To: <alpine.LFD.0.999.0709141014130.16478@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> For some inexplicable reason, "git diff" would call "diff_setup_done()"
> iff we hadn't given an explicit output format.
>
> That makes no sense, since much of what diff_setup_done() does is exactly
> about checking the output format!
We did not even have _any_ setup_done() call in "git diff"
itself in the original, because setup_revisions() has its own
call to setup_done(), and it always called setup_revisions()
before you reached that part of the code you have in your patch.
Commit 047fbe906b375e8a3a7564ad0e4443f62dd528a2 ("builtin-diff:
turn recursive on when defaulting to --patch format.") added the
call to setup_done() only when we are defaulting to output
format, to re-validate the consistency of output format options.
The screw-up was commit fcfa33ec905fcde1c16e7cbbe00d7147b89f1f01
(diff: make more cases implicit --no-index) that made the call
to setup_revisions() conditional if setup_diff_no_index()
decides to take over, but it forgot that setup_diff_no_index()
does not call setup_done().
So I tend to think the attached is a better fix.
---
diff-lib.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/diff-lib.c b/diff-lib.c
index f5568c3..da55713 100644
--- a/diff-lib.c
+++ b/diff-lib.c
@@ -298,6 +298,8 @@ int setup_diff_no_index(struct rev_info *revs,
revs->diffopt.nr_paths = 2;
revs->diffopt.no_index = 1;
revs->max_count = -2;
+ if (diff_setup_done(&revs->diffopt) < 0)
+ die("diff_setup_done failed");
return 0;
}
^ permalink raw reply related
* Re: [PATCH] Added example hook script to save/restore permissions/ownership.
From: Junio C Hamano @ 2007-09-14 18:24 UTC (permalink / raw)
To: git; +Cc: Josh England
In-Reply-To: <118952994432-git-send-email-jjengla@sandia.gov>
Does nobody find these two patches useful?
I do not feel strong need myself to have them but on the other
hand I do not see anything wrong with them, so I am inclined to
apply it to 'master' soon, unless somebody objects.
^ permalink raw reply
* Re: [PATCH 1/2] git-commit: Disallow unchanged tree in non-merge mode
From: Junio C Hamano @ 2007-09-14 18:24 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jeff King, Dmitry V. Levin, Shawn O. Pearce, Git Mailing List
In-Reply-To: <alpine.LFD.0.999.0709132215250.16478@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> Yeah, we should probably:
> - default to something larger but still reasonably sane (ie not 100, but
> perhaps 1000)
> - special-case the "identical rename", and have a higher limit for that
> (we already handle the identicals as a separate pass before we even
> start doing the similarity analysis - and it's the similarity analysis
> that can be the really expensive part)
>
> There's really no point in trying to do rename analysis for tons and tons
> of files - even if we find perfect renames, the diff is going to be
> unreadable by a human, so realistically nobody is ever going to care! A
> machine won't care whether it was done as a create/delete or a rename, and
> a human won't be bothered to read about thousands of renames, so we're
> just wasting time trying to make it prettier.
>
> So quite arguably, the only case we really care about for renames is when
> the numbers are small enough to be human-readable.
I agree with that. At the same time we might want to revisit
the earlier "build a full matrix and pick the best ones"
approach commit 5c97558c9a813a0a775c438a79cfc438def00c22 (Detect
renames in diff family) introduced.
A tangent.
I've been thinking about updating the diffcore-rename for some
time to give bonus points to a filepair whose neighbors are
detected to be renames. E.g. if you have this pair of preimage
and postimage:
(preimage) (postimage)
arch/i386/foo.c arch/x86/foo-32.c
arch/i386/bar.c arch/x86/bar-32.c
arch/i386/baz.c arch/x86/baz-32.c
and if foo.c and bar.c are found to be very similar to foo-32.c
and bar-32.c while baz.c and baz-32.c are not that much, we may
want to take hints from the movement of neighbouring files and
boost the similarity score between baz.c and baz-32.c pair.
It would be a quite an interesting coding challenge for anybody
who wants to get his hands dirty. Would this be worth it in
practice? I dunno.
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Shawn O. Pearce @ 2007-09-14 18:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wd1d0le.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> * db/fetch-pack (Fri Sep 14 03:31:25 2007 -0400) 22 commits
...
> This is Daniel's fetch-pack in C plus fixups from Shawn.
> Unfortunately the fixups breaks t3200 ("*** glibc detected ***
> fetch: free(): invalid pointer xxx ***"), which I haven't looked
> into yet.
Doesn't crash out on my Mac OS X system but I am getting the
above failure on my amd64 Linux system. I'm debugging it now.
I'll have to quit in about an hour and pick it up later, so don't
expect a patch immediately. But I'll certainly send something soon.
Clearly I made a change in my fixups that I shouldn't have. ;-)
--
Shawn.
^ permalink raw reply
* Re: [PATCH 1/2] Fix "git diff" setup code
From: Linus Torvalds @ 2007-09-14 18:30 UTC (permalink / raw)
To: Junio C Hamano
Cc: Dmitry V. Levin, Shawn O. Pearce, Git Mailing List, Jeff King
In-Reply-To: <7v4phxaz3o.fsf@gitster.siamese.dyndns.org>
On Fri, 14 Sep 2007, Junio C Hamano wrote:
>
> So I tend to think the attached is a better fix.
Ahh, yes, that explains the conditional.
But whatever gets us to actually verify our options, and fill in the right
defaults is ok by me!
Linus
^ permalink raw reply
* [PATCH] Remove extra dots from doc of git-archive option --format
From: Jari Aalto @ 2007-09-14 18:38 UTC (permalink / raw)
To: git
The description of the option gave impression that there
were several formats available by using three dots. There are
no other formats than tar and gzip.
Signed-off-by: Jari Aalto <jari.aalto AT cante.net>
---
Documentation/git-archive.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-archive.txt b/Documentation/git-archive.txt
index f2080eb..04771dc 100644
--- a/Documentation/git-archive.txt
+++ b/Documentation/git-archive.txt
@@ -31,7 +31,7 @@ OPTIONS
-------
--format=<fmt>::
- Format of the resulting archive: 'tar', 'zip'... The default
+ Format of the resulting archive: 'tar' or 'zip'. The default
is 'tar'.
--list, -l::
--
1.5.3
--
Welcome to FOSS revolution: we fix and modify until it shines
^ permalink raw reply related
* [PATCH] Add comment that git-archive writes to stdout
From: Jari Aalto @ 2007-09-14 18:41 UTC (permalink / raw)
To: git
Signed-off-by: Jari Aalto <jari.aalto AT cante.net>
---
Documentation/git-archive.txt | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-archive.txt b/Documentation/git-archive.txt
index f2080eb..f172639 100644
--- a/Documentation/git-archive.txt
+++ b/Documentation/git-archive.txt
@@ -16,7 +16,8 @@ DESCRIPTION
-----------
Creates an archive of the specified format containing the tree
structure for the named tree. If <prefix> is specified it is
-prepended to the filenames in the archive.
+prepended to the filenames in the archive. The archive is
+written to stdout.
'git-archive' behaves differently when given a tree ID versus when
given a commit ID or tag ID. In the first case the current time is
--
1.5.3
--
Welcome to FOSS revolution: we fix and modify until it shines
^ permalink raw reply related
* Re: [PATCH 2/2] Fix the rename detection limit checking
From: Linus Torvalds @ 2007-09-14 18:44 UTC (permalink / raw)
To: Junio C Hamano
Cc: Dmitry V. Levin, Shawn O. Pearce, Git Mailing List, Jeff King
In-Reply-To: <alpine.LFD.0.999.0709141017450.16478@woody.linux-foundation.org>
On Fri, 14 Sep 2007, Linus Torvalds wrote:
>
> ... and we also make sure that we don't overflow when doing the matrix
> size calculation.
Side note: by "make sure", I don't really mean a total guarantee.
We could be even more careful here. In particular:
- we later do end up allocating the matrix with
sizeof(*mx) * num_create * num_src
and I didn't actually fix the overflow that is possible due to the
"sizeof(*mx)" multiplication.
- even after we've checked that not *both* of the source and destination
counts are larger than the rename_limit, we could still overflow the
multiplication in just the limit check.
.. but with the rename_limit being set to 100, in practice neither of
these are really even close to realistic (ie you'd need to have less than
100 new files, and deleted over twenty million files to overflow, or vice
versa).
So with a rename_limit of 100, it's all good (I'm pretty sure you'd have
*other* issues long before you'd hit the integer overflows on renames ;)
But if somebody sets the rename_limit to something bigger, it gets
increasingly easier to screw it up.
If somebody wants to be *really* careful, they'd need to do something like
unsigned long max;
/* This isn't going to overflow, since we limited 'rename_limit' */
max = rename_limit * rename_limit;
/*
* But we should also check that multiplying by "sizeof(*mx)"
* won't make it overlof either..
*/
while ((sizeof(*mx) * max) / sizeof(*mx) != max)
max >>= 1;
/*
* And then avoid multiplying "rename_dst_nr" and "rename_src_nr"
* together by turning it into a division instead
*/
if (max / rename_dst_nr > rename_src_nr)
goto cleanup;
but the patch I sent out was the "obvious" first one that at least avoided
the overflow for the triggerable case that Dmitry had, and as per above
likely in all reasonable cases...
Linus
^ permalink raw reply
* Re: [PATCH 2/2] Fix the rename detection limit checking
From: Linus Torvalds @ 2007-09-14 18:49 UTC (permalink / raw)
To: Junio C Hamano
Cc: Dmitry V. Levin, Shawn O. Pearce, Git Mailing List, Jeff King
In-Reply-To: <alpine.LFD.0.999.0709141132250.16478@woody.linux-foundation.org>
On Fri, 14 Sep 2007, Linus Torvalds wrote:
>
> but the patch I sent out was the "obvious" first one that at least avoided
> the overflow for the triggerable case that Dmitry had, and as per above
> likely in all reasonable cases...
Final note (I promise): the patch I sent out took "git runstatus" times on
the workload I replicated from Dmitry down from "so long you'd ^C it" to
about two seconds..
So I wanted to point out that this was not just the correctness issue of
the overflow, but that the rename limiting really does need to be done for
purely practical time reasons - doing the math in 64 bits would have
avoided the overflow, but wouldn't have avoided the real reason for not
wanting to do these kinds of things in the first place!
Linus
^ permalink raw reply
* Re: [PATCH 1/2] Fix "git diff" setup code
From: Junio C Hamano @ 2007-09-14 19:11 UTC (permalink / raw)
To: Linus Torvalds
Cc: Dmitry V. Levin, Shawn O. Pearce, Git Mailing List, Jeff King
In-Reply-To: <alpine.LFD.0.999.0709141129451.16478@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Fri, 14 Sep 2007, Junio C Hamano wrote:
>>
>> So I tend to think the attached is a better fix.
>
> Ahh, yes, that explains the conditional.
>
> But whatever gets us to actually verify our options, and fill in the right
> defaults is ok by me!
Sorry, my explanation only explains about missing setup_done()
when --no-index is used, but does not explain _if_ you actually
found that setup_done() was not called for you when you did a
real life test. Was it only from code inspection, or did you
hit a case where setup_done() is not run? If the latter then
there is something else going on, as I cannot think of a way to
call setup_revisions() and not have it call setup_done()...
^ permalink raw reply
* tags "problem"
From: Rene Herman @ 2007-09-14 19:31 UTC (permalink / raw)
To: git
Hi people.
(please keep me in CC)
Was just busy constructing a tree and noticed a "problem" -- no doubt caused
by me, but help appreciated.
I clone linus' kernel tree into ./local, then do a
git checkout -b v22 v2.6.22
to get a 2.6.22 branch. I like to have a simple "git pull" while on this
branch pull from the upstream stable tree, so as advised earlier, I put:
[branch "v22"]
remote = linux-2.6.22.y
merge = refs/heads/master
[remote "linux-2.6.22.y"]
url =
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.22.y.git
fetch = refs/heads/master
in ./git/config. "git pull" now indeed works nicely.
I just noticed now though that this doesn't automatiically fetches tags as
well. That is, no v2.6.22.x tags after that. "git fetch --tags" (or git pull
--tags directly, I assume) gets them without problem, but I was expecting
they'd be fetched automatically.
Should they? Can they? Can I put anything in the config so they will?
Rene.
^ permalink raw reply
* Re: [PATCH 1/2] Fix "git diff" setup code
From: Linus Torvalds @ 2007-09-14 19:46 UTC (permalink / raw)
To: Junio C Hamano
Cc: Dmitry V. Levin, Shawn O. Pearce, Git Mailing List, Jeff King
In-Reply-To: <7vodg59i4x.fsf@gitster.siamese.dyndns.org>
On Fri, 14 Sep 2007, Junio C Hamano wrote:
>
> Sorry, my explanation only explains about missing setup_done()
> when --no-index is used, but does not explain _if_ you actually
> found that setup_done() was not called for you when you did a
> real life test. Was it only from code inspection, or did you
> hit a case where setup_done() is not run?
Hmm. Mea culpa. What seems to have happened is that I ran things under
gdb, and noticed that the default rename_limit hadn't been correctly set:
but now that I look more at it, that particular session was probably from
"git runstatus", not "git diff".
So yeah, ignore my 1/2. It was almost certainly based on a bogus debugging
session, before I noticed that wt-status.c doesn't use the normal diff
stuff at all..
Linus
^ permalink raw reply
* Re: tags "problem"
From: Junio C Hamano @ 2007-09-14 21:14 UTC (permalink / raw)
To: Rene Herman; +Cc: git
In-Reply-To: <46EAE189.5000804@gmail.com>
Rene Herman <rene.herman@gmail.com> writes:
> Hi people.
>
> (please keep me in CC)
>
> Was just busy constructing a tree and noticed a "problem" -- no doubt
> caused by me, but help appreciated.
>
> I clone linus' kernel tree into ./local, then do a
>
> git checkout -b v22 v2.6.22
>
> to get a 2.6.22 branch. I like to have a simple "git pull" while on
> this branch pull from the upstream stable tree, so as advised earlier,
> I put:
>
> [branch "v22"]
> remote = linux-2.6.22.y
> merge = refs/heads/master
> [remote "linux-2.6.22.y"]
> url =
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.22.y.git
> fetch = refs/heads/master
>
> in ./git/config. "git pull" now indeed works nicely.
Perhaps more canonical would be to make the latter fetch as:
fetch = refs/heads/*:refs/remotes/linux-2.6.22.y/*
> I just noticed now though that this doesn't automatiically fetches
> tags as well.
I suspect that fetch without remote tracking does not auto-fetch
the tags.
^ permalink raw reply
* Re: Track /etc directory using Git
From: Nicolas Vilz @ 2007-09-14 21:26 UTC (permalink / raw)
To: Thomas Harning Jr.; +Cc: martin f krafft, git, Francis Moreau
In-Reply-To: <e47324780709141031t79981b04q3a91984668ea723e@mail.gmail.com>
On Fri, Sep 14, 2007 at 01:31:06PM -0400, Thomas Harning Jr. wrote:
> On 9/14/07, martin f krafft <madduck@madduck.net> wrote:
> > also sprach Francis Moreau <francis.moro@gmail.com> [2007.09.14.1008 +0200]:
> > > Did you find an alternative to git in this case ?
> >
> > No, and I did not look anywhere, but I know of no other VCS that can
> > adequatly track permissions.
> Has anyone checked out metastore? http://repo.or.cz/w/metastore.git
> ... there's an XML error in there somewhere, so its not loading the
> 'main' page, but http://repo.or.cz/w/metastore.git?a=shortlog should
> work.
>
> It looks like it could work.... any thoughts on this?
I use that tool. If you just have one branch, it works. With the
commit-hook, which also updates the metadata, you have current
permission tracking.
There is a lack of a checkout-hook, which sets the permissions, so you
have to remeber todo a metastore -a after you checked out a revision.
But if you have several branches which fork the master branch and try to
rebase the branches on master, you get trouble, because the metadata gets
corrupted somehow. I will think about a solution on this sometime.
Nicolas
^ permalink raw reply
* [PATCH] Remove non-POSIX alternation in sed script in instaweb
From: Bryan Larsen @ 2007-09-14 21:41 UTC (permalink / raw)
To: git
git-instaweb.sh uses alternation in a sed script. Unfortunately,
this is not POSIX compliant and does not work on some BSD's. This
patch removes the alternation via the simple expedient of doubling
the number of lines in the sed script.
Signed-off-by: Bryan Larsen <bryan@larsen.st>
---
git-instaweb.sh | 12 ++++++++----
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/git-instaweb.sh b/git-instaweb.sh
index b79c6b6..ce631a0 100755
--- a/git-instaweb.sh
+++ b/git-instaweb.sh
@@ -207,10 +207,14 @@ EOF
}
script='
-s#^\(my\|our\) $projectroot =.*#\1 $projectroot = "'`dirname $fqgitdir`'";#
-s#\(my\|our\) $gitbin =.*#\1 $gitbin = "'$GIT_EXEC_PATH'";#
-s#\(my\|our\) $projects_list =.*#\1 $projects_list = $projectroot;#
-s#\(my\|our\) $git_temp =.*#\1 $git_temp = "'$fqgitdir/gitweb/tmp'";#'
+s#^my $projectroot =.*#my $projectroot = "'`dirname $fqgitdir`'";#
+s#^our $projectroot =.*#our $projectroot = "'`dirname $fqgitdir`'";#
+s#my $gitbin =.*#my $gitbin = "'$GIT_EXEC_PATH'";#
+s#our $gitbin =.*#our $gitbin = "'$GIT_EXEC_PATH'";#
+s#my $projects_list =.*#my $projects_list = $projectroot;#
+s#our $projects_list =.*#our $projects_list = $projectroot;#
+s#my $git_temp =.*#my $git_temp = "'$fqgitdir/gitweb/tmp'";#
+s#our $git_temp =.*#our $git_temp = "'$fqgitdir/gitweb/tmp'";#'
gitweb_cgi () {
cat > "$1.tmp" <<\EOFGITWEB
--
1.5.3.1
^ permalink raw reply related
* Re: [PATCH] Tiny fix in git-config manual
From: Junio C Hamano @ 2007-09-14 21:48 UTC (permalink / raw)
To: Bram Schoenmakers; +Cc: git
In-Reply-To: <200709102307.02468.bramschoenmakers@xs4all.nl>
Bram Schoenmakers <bramschoenmakers@xs4all.nl> writes:
> A little problem is shown in the git-config manual, where the possible
> locations for the configuration files is to be found. The dot is a special
> character and hence not visible in the resulting documents. This patch
> fixes this by adding an additional whitespace.
Thanks, but depending on the docbook stylesheet version this
does not seem to do anything or does not seem to fix the issue.
As we usually refer the repository metadata directory $GIT_DIR,
I am inclined to do this instead.
---
Documentation/git-config.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt
index 5b794f4..a592b61 100644
--- a/Documentation/git-config.txt
+++ b/Documentation/git-config.txt
@@ -142,7 +142,7 @@ FILES
If not set explicitly with '--file', there are three files where
git-config will search for configuration options:
-.git/config::
+$GIT_DIR/config::
Repository specific configuration file. (The filename is
of course relative to the repository root, not the working
directory.)
^ permalink raw reply related
* [PATCH] Remove non-POSIX 'expr index' from instaweb.
From: Bryan Larsen @ 2007-09-14 22:01 UTC (permalink / raw)
To: git
git-instaweb.sh uses the non-POSIX 'expr index' command, which
is not present on some BSD's. This patch replaces this usage
with a simple grep expression.
Signed-off-by: Bryan Larsen < bryan@larsen.st>
---
git-instaweb.sh | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/git-instaweb.sh b/git-instaweb.sh
index ce631a0..ef1a4bf 100755
--- a/git-instaweb.sh
+++ b/git-instaweb.sh
@@ -30,8 +30,7 @@ test -z "$port" && port=1234
start_httpd () {
httpd_only="`echo $httpd | cut -f1 -d' '`"
- if test "`expr index $httpd_only /`" -eq '1' || \
- which $httpd_only >/dev/null
+ if test echo $http_only | grep ^/ || which $httpd_only >/dev/null
then
$httpd $fqgitdir/gitweb/httpd.conf
else
--
1.5.3.1
^ permalink raw reply related
* Re: [PATCH] Add tests for documented features of "git reset".
From: Carlos Rica @ 2007-09-14 22:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin
In-Reply-To: <7vr6l5oi4r.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 359 bytes --]
2007/9/11, Junio C Hamano <gitster@pobox.com>:
> I also suspect this would not pass on CRLF boxes.
I finally removed the hardcoded object IDs (patch attached,
to be applied on top of the previous patch).
But I don't know what to fix for making the test to pass
in CRLF boxes. Could it due to the comparison of
expected diffs with files created using <<EOF?
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-t7102-reset-Use-tags-to-avoid-hardcoded-revision-ID.patch --]
[-- Type: text/x-patch; name="0001-t7102-reset-Use-tags-to-avoid-hardcoded-revision-ID.patch", Size: 7070 bytes --]
From b4c696b3e5b79d02c228bbc79d0d0e8f6a144453 Mon Sep 17 00:00:00 2001
From: Carlos Rica <jasampler@gmail.com>
Date: Thu, 13 Sep 2007 12:37:45 +0200
Subject: [PATCH] t7102-reset: Use tags to avoid hardcoded revision IDs.
Signed-off-by: Carlos Rica <jasampler@gmail.com>
---
t/t7102-reset.sh | 83 ++++++++++++++++++++++++++---------------------------
1 files changed, 41 insertions(+), 42 deletions(-)
diff --git a/t/t7102-reset.sh b/t/t7102-reset.sh
index 2cad4db..7e3da71 100755
--- a/t/t7102-reset.sh
+++ b/t/t7102-reset.sh
@@ -21,19 +21,28 @@ test_expect_success 'creating initial files and commits' '
echo "2nd line 1st file" >>first &&
git commit -a -m "modify 1st file" &&
+ git tag modify1 &&
git rm first &&
git mv second secondfile &&
git commit -a -m "remove 1st and rename 2nd" &&
+ git tag moves &&
echo "1st line 2nd file" >secondfile &&
echo "2nd line 2nd file" >>secondfile &&
- git commit -a -m "modify 2nd file"
+ git commit -a -m "modify 2nd file" &&
+ git tag modify2
'
# git log --pretty=oneline # to see those SHA1 involved
+refs_are_equal() {
+ r1=$(git rev-parse $1) &&
+ r2=$(git rev-parse $2) &&
+ test $r1 = $r2
+}
+
check_changes () {
- test "$(git rev-parse HEAD)" = "$1" &&
+ refs_are_equal HEAD $1 &&
git diff | git diff .diff_expect - &&
git diff --cached | git diff .cached_expect - &&
for FILE in *
@@ -56,7 +65,7 @@ test_expect_success 'giving a non existing revision should fail' '
! git reset --mixed aaaaaa &&
! git reset --soft aaaaaa &&
! git reset --hard aaaaaa &&
- check_changes 3ec39651e7f44ea531a5de18a9fa791c0fd370fc
+ check_changes modify2
'
test_expect_success \
@@ -65,7 +74,7 @@ test_expect_success \
! git reset --hard -- first &&
! git reset --soft HEAD^ -- first &&
! git reset --hard HEAD^ -- first &&
- check_changes 3ec39651e7f44ea531a5de18a9fa791c0fd370fc
+ check_changes modify2
'
test_expect_success 'giving unrecognized options should fail' '
@@ -77,7 +86,7 @@ test_expect_success 'giving unrecognized options should fail' '
! git reset --soft -o &&
! git reset --hard --other &&
! git reset --hard -o &&
- check_changes 3ec39651e7f44ea531a5de18a9fa791c0fd370fc
+ check_changes modify2
'
test_expect_success \
@@ -101,7 +110,7 @@ test_expect_success \
git checkout master &&
git branch -D branch1 branch2 &&
- check_changes 3ec39651e7f44ea531a5de18a9fa791c0fd370fc
+ check_changes modify2
'
test_expect_success \
@@ -124,27 +133,19 @@ test_expect_success \
git checkout master &&
git branch -D branch3 branch4 &&
- check_changes 3ec39651e7f44ea531a5de18a9fa791c0fd370fc
+ check_changes modify2
'
test_expect_success \
'resetting to HEAD with no changes should succeed and do nothing' '
- git reset --hard &&
- check_changes 3ec39651e7f44ea531a5de18a9fa791c0fd370fc
- git reset --hard HEAD &&
- check_changes 3ec39651e7f44ea531a5de18a9fa791c0fd370fc
- git reset --soft &&
- check_changes 3ec39651e7f44ea531a5de18a9fa791c0fd370fc
- git reset --soft HEAD &&
- check_changes 3ec39651e7f44ea531a5de18a9fa791c0fd370fc
- git reset --mixed &&
- check_changes 3ec39651e7f44ea531a5de18a9fa791c0fd370fc
- git reset --mixed HEAD &&
- check_changes 3ec39651e7f44ea531a5de18a9fa791c0fd370fc
- git reset &&
- check_changes 3ec39651e7f44ea531a5de18a9fa791c0fd370fc
- git reset HEAD &&
- check_changes 3ec39651e7f44ea531a5de18a9fa791c0fd370fc
+ git reset --hard && check_changes modify2
+ git reset --hard HEAD && check_changes modify2
+ git reset --soft && check_changes modify2
+ git reset --soft HEAD && check_changes modify2
+ git reset --mixed && check_changes modify2
+ git reset --mixed HEAD && check_changes modify2
+ git reset && check_changes modify2
+ git reset HEAD && check_changes modify2
'
>.diff_expect
@@ -165,9 +166,8 @@ secondfile:
EOF
test_expect_success '--soft reset only should show changes in diff --cached' '
git reset --soft HEAD^ &&
- check_changes d1a4bc3abce4829628ae2dcb0d60ef3d1a78b1c4 &&
- test "$(git rev-parse ORIG_HEAD)" = \
- 3ec39651e7f44ea531a5de18a9fa791c0fd370fc
+ check_changes moves &&
+ refs_are_equal ORIG_HEAD modify2
'
>.diff_expect
@@ -182,9 +182,9 @@ test_expect_success \
'changing files and redo the last commit should succeed' '
echo "3rd line 2nd file" >>secondfile &&
git commit -a -C ORIG_HEAD &&
- check_changes 3d3b7be011a58ca0c179ae45d94e6c83c0b0cd0d &&
- test "$(git rev-parse ORIG_HEAD)" = \
- 3ec39651e7f44ea531a5de18a9fa791c0fd370fc
+ git tag addline1
+ check_changes addline1 &&
+ refs_are_equal ORIG_HEAD modify2
'
>.diff_expect
@@ -199,9 +199,8 @@ EOF
test_expect_success \
'--hard reset should change the files and undo commits permanently' '
git reset --hard HEAD~2 &&
- check_changes ddaefe00f1da16864591c61fdc7adb5d7cd6b74e &&
- test "$(git rev-parse ORIG_HEAD)" = \
- 3d3b7be011a58ca0c179ae45d94e6c83c0b0cd0d
+ check_changes modify1 &&
+ refs_are_equal ORIG_HEAD addline1
'
>.diff_expect
@@ -243,7 +242,7 @@ test_expect_success \
echo "1st line 2nd file" >secondfile &&
echo "2nd line 2nd file" >>secondfile &&
git add secondfile &&
- check_changes ddaefe00f1da16864591c61fdc7adb5d7cd6b74e
+ check_changes modify1
'
cat >.diff_expect <<EOF
@@ -271,9 +270,8 @@ secondfile:
EOF
test_expect_success '--mixed reset to HEAD should unadd the files' '
git reset &&
- check_changes ddaefe00f1da16864591c61fdc7adb5d7cd6b74e &&
- test "$(git rev-parse ORIG_HEAD)" = \
- ddaefe00f1da16864591c61fdc7adb5d7cd6b74e
+ check_changes modify1 &&
+ refs_are_equal ORIG_HEAD modify1
'
>.diff_expect
@@ -285,7 +283,7 @@ secondfile:
EOF
test_expect_success 'redoing the last two commits should succeed' '
git add secondfile &&
- git reset --hard ddaefe00f1da16864591c61fdc7adb5d7cd6b74e &&
+ git reset --hard modify1 &&
git rm first &&
git mv second secondfile &&
@@ -294,7 +292,7 @@ test_expect_success 'redoing the last two commits should succeed' '
echo "1st line 2nd file" >secondfile &&
echo "2nd line 2nd file" >>secondfile &&
git commit -a -m "modify 2nd file" &&
- check_changes 3ec39651e7f44ea531a5de18a9fa791c0fd370fc
+ check_changes modify2
'
>.diff_expect
@@ -316,10 +314,11 @@ test_expect_success '--hard reset to HEAD should clear a failed merge' '
git checkout branch2 &&
echo "3rd line in branch2" >>secondfile &&
git commit -a -m "change in branch2" &&
+ git tag addline2 &&
! git pull . branch1 &&
git reset --hard &&
- check_changes 77abb337073fb4369a7ad69ff6f5ec0e4d6b54bb
+ check_changes addline2
'
>.diff_expect
@@ -332,15 +331,15 @@ EOF
test_expect_success \
'--hard reset to ORIG_HEAD should clear a fast-forward merge' '
git reset --hard HEAD^ &&
- check_changes 3ec39651e7f44ea531a5de18a9fa791c0fd370fc &&
+ check_changes modify2 &&
git pull . branch1 &&
git reset --hard ORIG_HEAD &&
- check_changes 3ec39651e7f44ea531a5de18a9fa791c0fd370fc &&
+ check_changes modify2 &&
git checkout master &&
git branch -D branch1 branch2 &&
- check_changes 3ec39651e7f44ea531a5de18a9fa791c0fd370fc
+ check_changes modify2
'
cat > expect << EOF
--
1.5.3.1
^ permalink raw reply related
* Re: [PATCH] Remove duplicate note about removing commits with git-filter-branch
From: Johannes Schindelin @ 2007-09-14 22:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: ulrik, git
In-Reply-To: <7vk5qteqto.fsf@gitster.siamese.dyndns.org>
Hi,
On Thu, 13 Sep 2007, Junio C Hamano wrote:
> ulrik <ulrik.sverdrup@gmail.com> writes:
>
> > A duplicate of an already existing section in the documentation of
> > git-filter-branch was added in commit
> > f95eef15f2f8a336b9a42749f5458c841a5a5d63.
> > This patch removes that redundant section.
> >
> > Signed-off-by: Ulrik Sverdrup <ulrik.sverdrup@gmail.com>
> > ---
> > Documentation/git-filter-branch.txt | 5 -----
> > 1 files changed, 0 insertions(+), 5 deletions(-)
> >
> > diff --git a/Documentation/git-filter-branch.txt
> > b/Documentation/git-filter-branch.txt
> > index 29bb8ce..c878ed3 100644
> > --- a/Documentation/git-filter-branch.txt
> > +++ b/Documentation/git-filter-branch.txt
> > @@ -220,11 +220,6 @@ git filter-branch --commit-filter '
> > fi' HEAD
> > ------------------------------------------------------------------------------
> >
> > -Note that the changes introduced by the commits, and not reverted by
> > -subsequent commits, will still be in the rewritten branch. If you want
> > -to throw out _changes_ together with the commits, you should use the
> > -interactive mode of gitlink:git-rebase[1].
> > -
> > The function 'skip_commits' is defined as follows:
>
> Hmph, sharp eyes. I suspect that this could have been my
> screwup.
Yep, I confirm this was my screwup. Thanks for fixing this, Ulrik!
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add tests for documented features of "git reset".
From: Junio C Hamano @ 2007-09-14 22:10 UTC (permalink / raw)
To: Carlos Rica; +Cc: git, Johannes Schindelin
In-Reply-To: <1b46aba20709141501l6f0f7440hd22b2bd6c4838a0b@mail.gmail.com>
"Carlos Rica" <jasampler@gmail.com> writes:
> 2007/9/11, Junio C Hamano <gitster@pobox.com>:
>> I also suspect this would not pass on CRLF boxes.
>
> I finally removed the hardcoded object IDs (patch attached,
> to be applied on top of the previous patch).
>
> But I don't know what to fix for making the test to pass
> in CRLF boxes.
The blobs created by the test script would be different on CRLF
boxes, and exact object IDs hardcoded in your test would not
match. That was the only thing I meant.
But now you bring it up, I guess the expected output may not
match as well. Hmmm..
Anyway, thanks for the update.
^ 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