* Re: [PATCH] git gui: Quote git path properly when starting another gui in a submodule
From: Shawn O. Pearce @ 2010-01-28 23:45 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Junio C Hamano, Git Mailing List, Heiko Voigt
In-Reply-To: <4B61FFA7.4090205@web.de>
Jens Lehmann <Jens.Lehmann@web.de> wrote:
> In do_git_gui() the path of the git executable has to be put into a list,
> otherwise calling it will fail when when spaces are present in its path.
>
> Reported-by: Heiko Voigt <hvoigt@hvoigt.net>
> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
> ---
>
>
> Am 28.01.2010 03:56, schrieb Shawn O. Pearce:
> > Jens Lehmann (2):
> > git-gui: Use git diff --submodule when available
> > git-gui: Add a special diff popup menu for submodules
>
> Today Heiko reported me this bug I introduced with the second patch.
> Sorry for the hassle.
Applied, thanks.
--
Shawn.
^ permalink raw reply
* Re: Questions about branches in git
From: Nanako Shiraishi @ 2010-01-29 0:03 UTC (permalink / raw)
To: Mike Linck; +Cc: Jens Lehmann, Michael Witten, git
In-Reply-To: <69b754db1001281338l58eb4b84t5a5725de294b6cc5@mail.gmail.com>
Quoting Mike Linck <mgl@absolute-performance.com>
> Could anyone point me to a good book that actually describes the style
> of code management that git was intended to support?
You may want to add the result of googling
"Fun with" site:gitster.livejournal.com
to the list of Git documents you read. "Fork from the oldest branch" is one of the techniques Junio teaches often and many of his other techiniques are built upon.
He not just teaches useful techniques but explains a lot about the reasoning behind them in his Git book. His blog articles have similar explanations on many topics I saw in his book but not in other places. It is a useful substitute until his book gets translated to English for people who don't read Japanese.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: Questions about branches in git
From: Mike Linck @ 2010-01-29 1:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v636lls8d.fsf@alter.siamese.dyndns.org>
On Thu, Jan 28, 2010 at 4:33 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Mike Linck <mgl@absolute-performance.com> writes:
>
>> I understand that there are mechanism kind of available to address
>> this problem. If we (all developers in my company) remember always to
>> rebase -i before they merge their topic branches back in, then it
>> could be squashed making it easier to identify and cherry pick onto
>> other branches, or *if* we always remember to rebase before we merge
>> and then create a patch set and store that on the topic branch, we
>> could kind of organize our change sets that way.
>
> On the quite contrary, probably an easier way is to pick a the oldest
> commit that a fix or enhancement would apply, build a topic that deals
> with only the fix or enhancement in question without doing anything else
> on top of it, and merge the resulting topic. The choice of the fork point
> needs to be made wisely in such a way that the resulting topic would not
> cause too much undue conflicts when merged to a modern mainline but old
> enough that you _could_ merge the result to any older maintenance branch
> if you choose to.
>
> One implication is that you do _not_ rebase the series to newer codebase
> because doing so would make the result unmergeable to older releases even
> if you later realize that the fix/enhancement would be suitable to them.
>
> And if you fork from older commit than tip, you will automatically get a
> non-ff merge when you merge it back to the mainline, which would delineate
> the history of the side branch from the integration branches rather
> nicely.
>
nice!
^ permalink raw reply
* [PATCH] request-pull: avoid mentioning that the start point is a single commit
From: Miklos Vajna @ 2010-01-29 1:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Previously we ran shortlog on the start commit which always printed
"(1)" after the start commit, which gives no information, but makes the
output less easy to read. Avoid doing so.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
So for example the 'git request-pull master~2 . master' output diff is
the following here:
The following changes since commit 68186857a9bb0a71e9456155623e02d398a5b817:
- Junio C Hamano (1):
- Merge branch 'il/maint-colon-address'
+ Junio C Hamano: Merge branch 'il/maint-colon-address'
are available in the git repository at:
git-request-pull.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-request-pull.sh b/git-request-pull.sh
index 630cedd..8475919 100755
--- a/git-request-pull.sh
+++ b/git-request-pull.sh
@@ -66,7 +66,7 @@ if [ -z "$branch" ]; then
fi
echo "The following changes since commit $baserev:"
-git shortlog --max-count=1 $baserev | sed -e 's/^\(.\)/ \1/'
+git log --max-count=1 --pretty=format:" %an: %s%n%n" $baserev
echo "are available in the git repository at:"
echo
--
1.6.6.1
^ permalink raw reply related
* Re: [PATCH] request-pull: avoid mentioning that the start point is a single commit
From: Shawn O. Pearce @ 2010-01-29 1:19 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, git
In-Reply-To: <20100129011817.GT12429@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> wrote:
> Previously we ran shortlog on the start commit which always printed
> "(1)" after the start commit, which gives no information, but makes the
> output less easy to read. Avoid doing so.
>
> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
> ---
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Nice fix, that was annoying me too, but I didn't care enough to
write a patch. :-)
> -git shortlog --max-count=1 $baserev | sed -e 's/^\(.\)/ \1/'
> +git log --max-count=1 --pretty=format:" %an: %s%n%n" $baserev
--
Shawn.
^ permalink raw reply
* [PATCH] fast-import: Stream very large blobs directly to pack
From: Shawn O. Pearce @ 2010-01-29 1:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nicolas Pitre
If a blob is larger than the configured big-file-threshold, instead
of reading it into a single buffer obtained from malloc, stream it
onto the end of the current pack file. Streaming the larger objects
into the pack avoids the 4+ GiB memory footprint that occurs when
fast-import is processing 2+ GiB blobs.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
Documentation/git-fast-import.txt | 6 ++
fast-import.c | 174 +++++++++++++++++++++++++++++++++----
t/t5705-clone-2gb.sh | 2 +-
t/t9300-fast-import.sh | 46 ++++++++++
4 files changed, 210 insertions(+), 18 deletions(-)
diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
index e6d364f..16d3596 100644
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@ -50,6 +50,12 @@ OPTIONS
importers may wish to lower this, such as to ensure the
resulting packfiles fit on CDs.
+--big-file-threshold=<n>::
+ Maximum size of a blob that fast-import will attempt to
+ create a delta for, expressed in MiB. The default is 512.
+ Some importers may wish to lower this on systems with
+ constrained memory.
+
--depth=<n>::
Maximum delta depth, for blob and tree deltification.
Default is 10.
diff --git a/fast-import.c b/fast-import.c
index 60d0aa2..8114f93 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -280,6 +280,7 @@ struct recent_command
/* Configured limits on output */
static unsigned long max_depth = 10;
static off_t max_packsize = (1LL << 32) - 1;
+static uintmax_t big_file_threshold = 512 * 1024 * 1024;
static int force_update;
static int pack_compression_level = Z_DEFAULT_COMPRESSION;
static int pack_compression_seen;
@@ -1003,7 +1004,7 @@ static void cycle_packfile(void)
static size_t encode_header(
enum object_type type,
- size_t size,
+ uintmax_t size,
unsigned char *hdr)
{
int n = 1;
@@ -1159,6 +1160,121 @@ static int store_object(
return 0;
}
+static void truncate_pack(off_t to)
+{
+ if (ftruncate(pack_data->pack_fd, to)
+ || lseek(pack_data->pack_fd, to, SEEK_SET) != to)
+ die_errno("cannot truncate pack to skip duplicate");
+ pack_size = to;
+}
+
+static void stream_blob(
+ uintmax_t len,
+ unsigned char *sha1out,
+ uintmax_t mark)
+{
+ size_t in_sz = 64 * 1024, out_sz = 64 * 1024;
+ unsigned char *in_buf = xmalloc(in_sz);
+ unsigned char *out_buf = xmalloc(out_sz);
+ struct object_entry *e;
+ unsigned char sha1[20];
+ unsigned long hdrlen;
+ off_t offset;
+ git_SHA_CTX c;
+ z_stream s;
+ int status = Z_OK;
+
+ /* Determine if we should auto-checkpoint. */
+ if ((pack_size + 60 + len) > max_packsize
+ || (pack_size + 60 + len) < pack_size)
+ cycle_packfile();
+
+ offset = pack_size;
+
+ hdrlen = snprintf((char *)out_buf, out_sz, "blob %" PRIuMAX, len) + 1;
+ if (out_sz <= hdrlen)
+ die("impossibly large object header");
+
+ git_SHA1_Init(&c);
+ git_SHA1_Update(&c, out_buf, hdrlen);
+
+ memset(&s, 0, sizeof(s));
+ deflateInit(&s, pack_compression_level);
+
+ hdrlen = encode_header(OBJ_BLOB, len, out_buf);
+ if (out_sz <= hdrlen)
+ die("impossibly large object header");
+
+ s.next_out = out_buf + hdrlen;
+ s.avail_out = out_sz - hdrlen;
+
+ while (status != Z_STREAM_END) {
+ if (0 < len && !s.avail_in) {
+ size_t cnt = in_sz < len ? in_sz : (size_t)len;
+ size_t n = fread(in_buf, 1, cnt, stdin);
+ if (!n && feof(stdin))
+ die("EOF in data (%" PRIuMAX " bytes remaining)", len);
+
+ git_SHA1_Update(&c, in_buf, n);
+ s.next_in = in_buf;
+ s.avail_in = n;
+ len -= n;
+ }
+
+ status = deflate(&s, len ? 0 : Z_FINISH);
+
+ if (!s.avail_out || status == Z_STREAM_END) {
+ size_t n = s.next_out - out_buf;
+ write_or_die(pack_data->pack_fd, out_buf, n);
+ pack_size += n;
+ s.next_out = out_buf;
+ s.avail_out = out_sz;
+ }
+
+ switch (status) {
+ case Z_OK:
+ case Z_BUF_ERROR:
+ case Z_STREAM_END:
+ continue;
+ default:
+ die("unexpected deflate failure: %d", status);
+ }
+ }
+ deflateEnd(&s);
+ git_SHA1_Final(sha1, &c);
+
+ if (sha1out)
+ hashcpy(sha1out, sha1);
+
+ e = insert_object(sha1);
+
+ if (mark)
+ insert_mark(mark, e);
+
+ if (e->offset) {
+ duplicate_count_by_type[OBJ_BLOB]++;
+ truncate_pack(offset);
+
+ } else if (find_sha1_pack(sha1, packed_git)) {
+ e->type = OBJ_BLOB;
+ e->pack_id = MAX_PACK_ID;
+ e->offset = 1; /* just not zero! */
+ duplicate_count_by_type[OBJ_BLOB]++;
+ truncate_pack(offset);
+
+ } else {
+ e->depth = 0;
+ e->type = OBJ_BLOB;
+ e->pack_id = pack_id;
+ e->offset = offset;
+ object_count++;
+ object_count_by_type[OBJ_BLOB]++;
+ }
+
+ free(in_buf);
+ free(out_buf);
+}
+
/* All calls must be guarded by find_object() or find_mark() to
* ensure the 'struct object_entry' passed was written by this
* process instance. We unpack the entry by the offset, avoiding
@@ -1704,7 +1820,7 @@ static void parse_mark(void)
next_mark = 0;
}
-static void parse_data(struct strbuf *sb)
+static int parse_data(struct strbuf *sb, uintmax_t limit, uintmax_t *len_res)
{
strbuf_reset(sb);
@@ -1728,9 +1844,15 @@ static void parse_data(struct strbuf *sb)
free(term);
}
else {
- size_t n = 0, length;
+ uintmax_t len = strtoumax(command_buf.buf + 5, NULL, 10);
+ size_t n = 0, length = (size_t)len;
- length = strtoul(command_buf.buf + 5, NULL, 10);
+ if (limit && limit < len) {
+ *len_res = len;
+ return 0;
+ }
+ if (length < len)
+ die("data is too large to use in this context");
while (n < length) {
size_t s = strbuf_fread(sb, length - n, stdin);
@@ -1742,6 +1864,7 @@ static void parse_data(struct strbuf *sb)
}
skip_optional_lf();
+ return 1;
}
static int validate_raw_date(const char *src, char *result, int maxlen)
@@ -1806,14 +1929,31 @@ static char *parse_ident(const char *buf)
return ident;
}
-static void parse_new_blob(void)
+static void parse_and_store_blob(
+ struct last_object *last,
+ unsigned char *sha1out,
+ uintmax_t mark)
{
static struct strbuf buf = STRBUF_INIT;
+ uintmax_t len;
+
+ if (parse_data(&buf, big_file_threshold, &len))
+ store_object(OBJ_BLOB, &buf, last, sha1out, mark);
+ else {
+ if (last) {
+ strbuf_release(&last->data);
+ last->offset = 0;
+ last->depth = 0;
+ }
+ stream_blob(len, sha1out, mark);
+ }
+}
+static void parse_new_blob(void)
+{
read_next_command();
parse_mark();
- parse_data(&buf);
- store_object(OBJ_BLOB, &buf, &last_blob, NULL, next_mark);
+ parse_and_store_blob(&last_blob, NULL, next_mark);
}
static void unload_one_branch(void)
@@ -1924,15 +2064,12 @@ static void file_change_m(struct branch *b)
* another repository.
*/
} else if (inline_data) {
- static struct strbuf buf = STRBUF_INIT;
-
if (p != uq.buf) {
strbuf_addstr(&uq, p);
p = uq.buf;
}
read_next_command();
- parse_data(&buf);
- store_object(OBJ_BLOB, &buf, &last_blob, sha1, 0);
+ parse_and_store_blob(&last_blob, sha1, 0);
} else if (oe) {
if (oe->type != OBJ_BLOB)
die("Not a blob (actually a %s): %s",
@@ -2058,15 +2195,12 @@ static void note_change_n(struct branch *b)
die("Invalid ref name or SHA1 expression: %s", p);
if (inline_data) {
- static struct strbuf buf = STRBUF_INIT;
-
if (p != uq.buf) {
strbuf_addstr(&uq, p);
p = uq.buf;
}
read_next_command();
- parse_data(&buf);
- store_object(OBJ_BLOB, &buf, &last_blob, sha1, 0);
+ parse_and_store_blob(&last_blob, sha1, 0);
} else if (oe) {
if (oe->type != OBJ_BLOB)
die("Not a blob (actually a %s): %s",
@@ -2232,7 +2366,7 @@ static void parse_new_commit(void)
}
if (!committer)
die("Expected committer but didn't get one");
- parse_data(&msg);
+ parse_data(&msg, 0, NULL);
read_next_command();
parse_from(b);
merge_list = parse_merge(&merge_count);
@@ -2353,7 +2487,7 @@ static void parse_new_tag(void)
tagger = NULL;
/* tag payload/message */
- parse_data(&msg);
+ parse_data(&msg, 0, NULL);
/* build the tag object */
strbuf_reset(&new_data);
@@ -2473,6 +2607,10 @@ static int git_pack_config(const char *k, const char *v, void *cb)
pack_compression_seen = 1;
return 0;
}
+ if (!strcmp(k, "core.bigfilethreshold")) {
+ long n = git_config_int(k, v);
+ big_file_threshold = 0 < n ? n : 0;
+ }
return git_default_config(k, v, cb);
}
@@ -2518,6 +2656,8 @@ int main(int argc, const char **argv)
}
else if (!prefixcmp(a, "--max-pack-size="))
max_packsize = strtoumax(a + 16, NULL, 0) * 1024 * 1024;
+ else if (!prefixcmp(a, "--big-file-threshold="))
+ big_file_threshold = strtoumax(a + 21, NULL, 0) * 1024 * 1024;
else if (!prefixcmp(a, "--depth=")) {
max_depth = strtoul(a + 8, NULL, 0);
if (max_depth > MAX_DEPTH)
diff --git a/t/t5705-clone-2gb.sh b/t/t5705-clone-2gb.sh
index 9f52154..adfaae8 100755
--- a/t/t5705-clone-2gb.sh
+++ b/t/t5705-clone-2gb.sh
@@ -31,7 +31,7 @@ test_expect_success 'setup' '
echo "data 5" &&
echo ">2gb" &&
cat commit) |
- git fast-import &&
+ git fast-import --big-file-threshold=2 &&
test ! -f exit-status
'
diff --git a/t/t9300-fast-import.sh b/t/t9300-fast-import.sh
index b49815d..513db86 100755
--- a/t/t9300-fast-import.sh
+++ b/t/t9300-fast-import.sh
@@ -1254,4 +1254,50 @@ test_expect_success \
'Q: verify note for third commit' \
'git cat-file blob refs/notes/foobar:$commit3 >actual && test_cmp expect actual'
+##
+## R: very large blobs
+##
+blobsize=$((2*1024*1024 + 53))
+test-genrandom bar $blobsize >expect
+cat >input <<INPUT_END
+commit refs/heads/big-file
+committer $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE
+data <<COMMIT
+R - big file
+COMMIT
+
+M 644 inline big1
+data $blobsize
+INPUT_END
+cat expect >>input
+cat >>input <<INPUT_END
+M 644 inline big2
+data $blobsize
+INPUT_END
+cat expect >>input
+echo >>input
+
+test_expect_success \
+ 'R: blob bigger than threshold' \
+ 'test_create_repo R &&
+ git --git-dir=R/.git fast-import --big-file-threshold=1 <input'
+test_expect_success \
+ 'R: verify created pack' \
+ ': >verify &&
+ for p in R/.git/objects/pack/*.pack;
+ do
+ git verify-pack -v $p >>verify || exit;
+ done'
+test_expect_success \
+ 'R: verify written objects' \
+ 'git --git-dir=R/.git cat-file blob big-file:big1 >actual &&
+ test_cmp expect actual &&
+ a=$(git --git-dir=R/.git rev-parse big-file:big1) &&
+ b=$(git --git-dir=R/.git rev-parse big-file:big2) &&
+ test $a = $b'
+test_expect_success \
+ 'R: blob appears only once' \
+ 'n=$(grep $a verify | wc -l) &&
+ test 1 = $n'
+
test_done
--
1.7.0.rc0.170.g7207c
--
Shawn.
^ permalink raw reply related
* Stepping through a single file's history
From: Ron Garret @ 2010-01-29 1:28 UTC (permalink / raw)
To: git
Hello,
Is there an easy way to step through the history of a single file? To be more specific:
Suppose I have a repository with a bunch of files and bunch of commits in a simple linear sequence, but with changes to various files interleaved within that sequence of commits. I want to be able to step through the history of ONE of the files in the repository without disturbing the other files in the working directory, and without changing the index. (The use case here is remembering that back in the day there was some useful code in this file that I want to retrieve, but not remembering exactly when it was deleted. So I want to step back through this file's history and do diffs against HEAD.)
So I want to be able to do something like...
git rollback [filename]
and have the copy of the file in the working directory roll back one version. Then I want to be able to do a 'git diff' and see what was different between that rolled-back version and the most recent one (which I want to then be able to return to somehow, preferably in a more elegant way than git checkout HEAD, but I'll settle for that).
It seems that this should be possible, but I can't figure out how to do it. The closest I've been able to come is doing:
git rev-list HEAD -- [filename]
and then manually going back through the list of commits and doing a git checkout on each one in turn. There are two problems with this. First, I have to manually keep track of where I am in the list, which is a PITA if the list is long. And second, because I've checked the file out, it not only appears in my working directory, but it also gets placed in the index, which is not what I want (because I want to be able to do a git diff against the HEAD to see the code that changed between the old and new versions).
Git does everything, so surely there's a way to do this. Can anyone offer me a hint as to how?
Thanks,
rg
^ permalink raw reply
* Re: Stepping through a single file's history
From: John Tapsell @ 2010-01-29 1:58 UTC (permalink / raw)
Cc: git
In-Reply-To: <5699F80A-4B27-4BAB-BEE8-5C48938A970B@flownet.com>
2010/1/29 Ron Garret <ron@flownet.com>:
> Hello,
>
> Is there an easy way to step through the history of a single file? To be more specific:
...
> (The use case here is remembering that back in the day there was some useful code in this file that I want to retrieve, but not remembering exactly when it was deleted. So I want to step back through this file's history and do diffs against HEAD.)
How about simply doing:
git log -p filename
and then you can search by pressing "/" and then typing whatever you remember.
John
^ permalink raw reply
* Re: [PATCH] fast-import: Stream very large blobs directly to pack
From: Nicolas Pitre @ 2010-01-29 2:33 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20100129012350.GD20488@spearce.org>
On Thu, 28 Jan 2010, Shawn O. Pearce wrote:
> If a blob is larger than the configured big-file-threshold, instead
> of reading it into a single buffer obtained from malloc, stream it
> onto the end of the current pack file. Streaming the larger objects
> into the pack avoids the 4+ GiB memory footprint that occurs when
> fast-import is processing 2+ GiB blobs.
Yeah. I've had that item on my todo list for ages now. This
big-file-threshold principle has to be applied to 'git add' too so a big
blob is stored in pack file form right away, and used to bypass delta
searching in 'git pack-objects', used to skip the diff machinery, and so
on.
Nicolas
^ permalink raw reply
* Major git-svn fail
From: Rafael Kitover @ 2010-01-29 1:50 UTC (permalink / raw)
To: git
Hello,
I'm trying to convert an SVK repo to git using the steps described here:
http://blog.woobling.org/2009/06/git-svn-abandon.html
I'm using the latest devel git from git as the svk reparenting stuff
seems to have gotten merged already.
When I used the old code from samv's github
(http://github.com/samv/git/tree/svn-merge-attrs) it ran through the
clone all the way, but I had a core file in the directory, so I don't
really trust the results.
This is the command I'm using and the results:
git svn clone --authors-file=sl-authors.txt
--branches='http://dev.catalyst.perl.org/repos/bast/branches/DBIx-Class-Schema-Loader/'
--tags='http://dev.catalyst.perl.org/repos/bast/DBIx-Class-Schema-Loader/tags/'
--trunk='http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class-Schema-Loader'
'http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class-Schema-Loader'
sl
Initialized empty Git repository in
/home/rkitover/src/git-conversion/sl/.git/
Using higher level of URL:
http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class-Schema-Loader
=> http://dev.catalyst.perl.org/repos/bast
perl:
/tmp/buildd/subversion-1.6.9dfsg/subversion/libsvn_subr/path.c:115:
svn_path_join: Assertion `svn_path_is_canonical(component, pool)'
failed.
error: git-svn died of signal 6
The authors file I'm using is:
http://cachemiss.com/files/sl-authors.txt
These svn URLs are for a public repo, so hopefully you can reproduce my
results.
Any help much appreciated.
^ permalink raw reply
* Re: [PATCH] fast-import: Stream very large blobs directly to pack
From: Shawn O. Pearce @ 2010-01-29 2:37 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LFD.2.00.1001282125410.1681@xanadu.home>
Nicolas Pitre <nico@fluxnic.net> wrote:
> On Thu, 28 Jan 2010, Shawn O. Pearce wrote:
>
> > If a blob is larger than the configured big-file-threshold, instead
> > of reading it into a single buffer obtained from malloc, stream it
> > onto the end of the current pack file. Streaming the larger objects
> > into the pack avoids the 4+ GiB memory footprint that occurs when
> > fast-import is processing 2+ GiB blobs.
>
> Yeah. I've had that item on my todo list for ages now. This
> big-file-threshold principle has to be applied to 'git add' too so a big
> blob is stored in pack file form right away, and used to bypass delta
> searching in 'git pack-objects', used to skip the diff machinery, and so
> on.
Yea, there are a lot of places we should improve for bigger files.
gfi just happened to be the first one I got a bug report on from
a user...
--
Shawn.
^ permalink raw reply
* Re: Questions about branches in git
From: Junio C Hamano @ 2010-01-29 3:03 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Mike Linck, Jens Lehmann, Michael Witten, git
In-Reply-To: <20100129090345.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting Mike Linck <mgl@absolute-performance.com>
>
>> Could anyone point me to a good book that actually describes the style
>> of code management that git was intended to support?
>
> You may want to add the result of googling
>
> "Fun with" site:gitster.livejournal.com
>
> to the list of Git documents you read. "Fork from the oldest branch" is
> one of the techniques Junio teaches often and many of his other
> techiniques are built upon.
> ... It is a useful substitute until his book gets translated to English
> for people who don't read Japanese.
Quite honestly, I don't think my blog articles are all that good;
certainly not as good as the book, as I don't draw pictures.
For this particular topic, I would instead recommend:
http://nvie.com/archives/323 (A successful Git branching model)
What it teaches isn't anything earth-shattering (it's the same old "how to
use topic branch effectively" and I don't necessarily agree with the
choice of fork points of topic branches depicted in the article), but
people seem to like its graphics very much and it is scoring quite high in
delicio.us.
^ permalink raw reply
* Re: Major git-svn fail
From: Tay Ray Chuan @ 2010-01-29 3:08 UTC (permalink / raw)
To: Rafael Kitover; +Cc: git
In-Reply-To: <20100129015016.GD759@hlagh.dongs>
Hi,
On Fri, Jan 29, 2010 at 9:50 AM, Rafael Kitover <rkitover@io.com> wrote:
> This is the command I'm using and the results:
> git svn clone --authors-file=sl-authors.txt
> --branches='http://dev.catalyst.perl.org/repos/bast/branches/DBIx-Class-Schema-Loader/'
> --tags='http://dev.catalyst.perl.org/repos/bast/DBIx-Class-Schema-Loader/tags/'
> --trunk='http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class-Schema-Loader'
> 'http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class-Schema-Loader'
> sl
> Initialized empty Git repository in
> /home/rkitover/src/git-conversion/sl/.git/
> Using higher level of URL:
> http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class-Schema-Loader
> => http://dev.catalyst.perl.org/repos/bast
> perl:
> /tmp/buildd/subversion-1.6.9dfsg/subversion/libsvn_subr/path.c:115:
> svn_path_join: Assertion `svn_path_is_canonical(component, pool)'
> failed.
> error: git-svn died of signal 6
>
> The authors file I'm using is:
> http://cachemiss.com/files/sl-authors.txt
I ran this:
$ git svn --version
git-svn version 1.6.6.1.436.gaba7d (svn 1.6.6)
$ git svn clone --authors-file=sl-authors.txt \
--branches=http://dev.catalyst.perl.org/repos/bast/branches/DBIx-Class-Schema-Loader/
\
--tags=http://dev.catalyst.perl.org/repos/bast/tags/ \
--trunk=http://dev.catalyst.perl.org/repos/bast/trunk/ \
http://dev.catalyst.perl.org/repos/bast/
This is what I got:
Initialized empty Git repository in /home/Owner/tmp/foo/bast/.git/
Using higher level of URL:
http://dev.catalyst.perl.org/repos/bast/trunk =>
http://dev.catalyst.perl.org/repos/bast
r1 = f48f2e41631e82bec48ad96ec206faf0b5893226 (refs/remotes/trunk)
....
Looks ok.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: Stepping through a single file's history
From: John Tapsell @ 2010-01-29 3:47 UTC (permalink / raw)
To: John Tapsell; +Cc: git
In-Reply-To: <43d8ce651001281758x79965b5fn8760b69d4fe82a36@mail.gmail.com>
2010/1/29 John Tapsell <johnflux@gmail.com>:
> 2010/1/29 Ron Garret <ron@flownet.com>:
>> Hello,
>>
>> Is there an easy way to step through the history of a single file? To be more specific:
> ...
>> (The use case here is remembering that back in the day there was some useful code in this file that I want to retrieve, but not remembering exactly when it was deleted. So I want to step back through this file's history and do diffs against HEAD.)
>
> How about simply doing:
>
> git log -p filename
You can also do like:
git show HEAD~3:path/filename
where path is the path from the top of the git repository. This would
show the file as it was 3 revisions ago.
You can also do like:
git checkout HEAD~3 filename
to checkout the first as it was 3 revisions ago.
^ permalink raw reply
* Re: [PATCH] fast-import: Stream very large blobs directly to pack
From: Junio C Hamano @ 2010-01-29 5:29 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Nicolas Pitre
In-Reply-To: <20100129012350.GD20488@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> +static void stream_blob(
> + uintmax_t len,
> + unsigned char *sha1out,
> + uintmax_t mark)
A funny way to indent and line wrap...
> +{
> + ...
> + /* Determine if we should auto-checkpoint. */
> + if ((pack_size + 60 + len) > max_packsize
> + || (pack_size + 60 + len) < pack_size)
> + cycle_packfile();
What's "60" in this math?
If the data is not compressible, we could even grow and the end result
might be more than (pack_size + len), busting max_packsize. As we are
streaming out, we cannot say "oops, let me try again after truncating and
closing the current file and then opening a new file", and instead may
have to copy the data from the current one to a new one, and truncate the
current one. Is this something worth worrying about?
^ permalink raw reply
* Re: [PATCH] request-pull: avoid mentioning that the start point is a single commit
From: Junio C Hamano @ 2010-01-29 7:33 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20100129011817.GT12429@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> Previously we ran shortlog on the start commit which always printed
> "(1)" after the start commit, which gives no information, but makes the
> output less easy to read. Avoid doing so.
>
> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
> ---
>
> So for example the 'git request-pull master~2 . master' output diff is
> the following here:
>
> The following changes since commit 68186857a9bb0a71e9456155623e02d398a5b817:
> - Junio C Hamano (1):
> - Merge branch 'il/maint-colon-address'
> + Junio C Hamano: Merge branch 'il/maint-colon-address'
>
> are available in the git repository at:
>
> git-request-pull.sh | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/git-request-pull.sh b/git-request-pull.sh
> index 630cedd..8475919 100755
> --- a/git-request-pull.sh
> +++ b/git-request-pull.sh
> @@ -66,7 +66,7 @@ if [ -z "$branch" ]; then
> fi
>
> echo "The following changes since commit $baserev:"
> -git shortlog --max-count=1 $baserev | sed -e 's/^\(.\)/ \1/'
> +git log --max-count=1 --pretty=format:" %an: %s%n%n" $baserev
A few comments:
- Modernising implementation by using tools different from what the
original used (i.e. shortlog -> log) is fine, but I'd recommend doing
so even more thoroughly. Use "show -s" instead of "log -1" and
"--format=" instead of "--pretty=format:", for example.
- If the stated goal of the change is to remove " (1)" which is
distracting with no useful information, remove that and only that,
without changing anything else in the output.
- On the other hand, if you find that "AuthorName: " part is less useful
in identifying the commit than its title to help the requestee, change
the whole thing to make it even more useful.
So I'd suggest either:
git show -s --format=" %an:%n %s" $baserev
to be conservative, or
git show -s --format=" %s (%an)" $baserev
or even to this:
git show -s --format=" %s (%ci)" $baserev
I suspect that the last one would be the easiest for the requestee to
judge the freshness of the branch.
Why isn't the "The following changes..." line not part of the --format
thing, by the way? From the POV of readability of the code (not
necessarily the output), doing it this way might be the cleanest:
-- >8 --
git show -s --format='The following changes since %H
%s (%ci)
are available in the git repository at:' $baserev
echo " $url $branch"
-- 8< --
^ permalink raw reply
* Re: [PATCH v2] Windows: improve performance by avoiding a static dependency on ws2_32.dll and advapi32.dll
From: Johannes Sixt @ 2010-01-29 7:44 UTC (permalink / raw)
To: Michael Lukashov; +Cc: Johannes Schindelin, git
In-Reply-To: <63cde7731001280247w51d32475ob5fa22f796fa50b7@mail.gmail.com>
Michael Lukashov schrieb:
> The runtime of 'make -j2 test' went down from 35:19min
> to 32:39min on my machine.
Sorry, I can't back this claim. In my tests, 'make -j2 test' did not go
down. My timings were between 13:40min and 13:50min with and without the
patch, and I tried multiple times.
For the MinGW version, I'd rather not apply this patch. People interested
in optimizing the MSVC version could link with /delayload:ws_32.dll to
achieve the same effect without any change to the code.
-- Hannes
^ permalink raw reply
* build warnings
From: Michael Wookey @ 2010-01-29 9:03 UTC (permalink / raw)
To: Git Mailing List, Johannes Sixt
FYI,
With current master (dace5dd1), the following build warnings appear on
Ubuntu 9.10 (x86):
run-command.c: In function ‘notify_parent’:
run-command.c:70: warning: ignoring return value of ‘write’,
declared with attribute warn_unused_result
run-command.c: In function ‘die_child’:
run-command.c:80: warning: ignoring return value of ‘write’,
declared with attribute warn_unused_result
run-command.c:81: warning: ignoring return value of ‘write’,
declared with attribute warn_unused_result
run-command.c:82: warning: ignoring return value of ‘write’,
declared with attribute warn_unused_result
These warnings were introduced by the following commits:
2b541bf8 ("start_command: detect execvp failures early")
a5487ddf ("start_command: report child process setup errors to the
parent's stderr")
The GCC details are:
~$ gcc --version
gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1
^ permalink raw reply
* Re: Questions about branches in git
From: Peter Krefting @ 2010-01-29 10:06 UTC (permalink / raw)
To: Mike Linck; +Cc: Git Mailing List
In-Reply-To: <69b754db1001281044y39e52f77hcc8f83144776c78f@mail.gmail.com>
Mike Linck:
> It seems that after a topic or bug branch is merged back into its parent,
> especially if it was fast forwarded, it becomes hard to determine what
> changes were made in it, to resolve the problem that it was created to
> address.
If you keep the branch name somewhere (either pushed to the master
repository, or to a side-repository used to store old "dead" branches), then
you at least have the pointer to the last commit on that particular branch.
You can then backtrack through the commits to the previous merge-point, or
branch head, in the history to find the point where it, most likely, was
branched off from.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: Questions about branches in git
From: Peter Krefting @ 2010-01-29 10:07 UTC (permalink / raw)
To: Michael Witten; +Cc: Mike Linck, Git Mailing List
In-Reply-To: <b4087cc51001281203q1f467480sdf848c9d3ced323b@mail.gmail.com>
Michael Witten:
> However, I've been thinking for a while that it would be useful to have
> übercommits (they don't exist) that are treated like single commits but
> that actually encapsulate multiple continguous commits.
Your "übercommits" can easily be faked by wrapping the project up in a git
submodule. The supermodule (which would just contain one entry -- the
project you are "übercommit-tracking") would then contain one single commit
for each set of commits you wish to publish.
I'm not sure such a work-flow makes much sense, though. Annotated tags are
probably a better idea.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* [PATCH 0/3] valgrind bug roundup
From: Jeff King @ 2010-01-29 10:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20100128145216.GA29727@coredump.intra.peff.net>
On Thu, Jan 28, 2010 at 09:52:16AM -0500, Jeff King wrote:
> I'm running the whole test suite under valgrind for the current
> 'master'. This was the first hit, but it's very s-l-o-w, so there might
> be more as the day progresses.
And here they are. The first two are actual bugs, the third silences a
false positive:
[1/3]: fix memcpy of overlapping area
[2/3]: fix off-by-one allocation error
[3/3]: add shebang line to git-mergetool--lib.sh
It really has been a while since I've run the whole test suite under
valgrind. The breakage in 3/3 dates back to last April. The bug in 1/3
is also quite old (v1.5.0). I'm not sure why I didn't find it in
previous valgrind runs; perhaps it is only recent valgrinds that have
grown support for finding overlapping memcpy. The bug in 2/3 is new, and
has never been in a released version.
-Peff
^ permalink raw reply
* threaded-grep cause msys build failure
From: Zoltán Füzesi @ 2010-01-29 10:27 UTC (permalink / raw)
To: git lista
Hi,
Building git in msys environment fails:
...
LINK git.exe
builtin-grep.o: In function `wait_all':
D:\devel\msysgit\git/builtin-grep.c:260: undefined reference to
`pthread_cond_broadcast'
collect2: ld returned 1 exit status
make: *** [git.exe] Error 1
I guess compat/win32/pthread.c misses pthread_cond_broadcast implementation.
Zé
^ permalink raw reply
* [PATCH 1/3] fix memcpy of overlapping area
From: Jeff King @ 2010-01-29 10:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <20100129102518.GA5875@coredump.intra.peff.net>
Caught by valgrind in t5500, but it is pretty obvious from
reading the code that this is shifting elements of an array
to the left, which needs memmove.
Signed-off-by: Jeff King <peff@peff.net>
---
This was introduced in f53514b (allow deepening of a shallow repository,
2006-10-30), released as part of v1.5.0. So probably 'maint'-worthy.
commit.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/commit.c b/commit.c
index 632061c..731191e 100644
--- a/commit.c
+++ b/commit.c
@@ -224,7 +224,7 @@ int unregister_shallow(const unsigned char *sha1)
if (pos < 0)
return -1;
if (pos + 1 < commit_graft_nr)
- memcpy(commit_graft + pos, commit_graft + pos + 1,
+ memmove(commit_graft + pos, commit_graft + pos + 1,
sizeof(struct commit_graft *)
* (commit_graft_nr - pos - 1));
commit_graft_nr--;
--
1.7.0.rc0.41.g538720
^ permalink raw reply related
* [PATCH 2/3] fix off-by-one allocation error
From: Jeff King @ 2010-01-29 10:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jan Krüger, git
In-Reply-To: <20100129102518.GA5875@coredump.intra.peff.net>
Caught by valgrind in t5516. Reading the code shows we
malloc enough for our string, but not trailing NUL.
Signed-off-by: Jeff King <peff@peff.net>
---
This bug was introduced in f517f1f (builtin-push: add --delete as
syntactic sugar for :foo, 2009-12-30), not released yet but part of
1.7.0-rc0. So no need for a 'maint' fix.
An obvious alternative would be to convert it to strbuf (which could
also be used to clean up other non-buggy string generation earlier in
the function).
builtin-push.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-push.c b/builtin-push.c
index 5df6608..5633f0a 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -52,7 +52,7 @@ static void set_refspecs(const char **refs, int nr)
} else if (deleterefs && !strchr(ref, ':')) {
char *delref;
int len = strlen(ref)+1;
- delref = xmalloc(len);
+ delref = xmalloc(len+1);
strcpy(delref, ":");
strcat(delref, ref);
ref = delref;
--
1.7.0.rc0.41.g538720
^ permalink raw reply related
* [PATCH 3/3] add shebang line to git-mergetool--lib.sh
From: Jeff King @ 2010-01-29 10:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, David Aguilar, git
In-Reply-To: <20100129102518.GA5875@coredump.intra.peff.net>
Even though this script is expected to be sourced instead of
executed on its own, the #!/bin/sh line provides simple
documentation about what format the file is in.
In particular, the lack of such a line was confusing the
valgrind support of our test scripts, which assumed that any
executable without a #!-line should be intercepted and run
through valgrind. So during valgrind-enabled tests, any
script sourcing this file actually sourced the valgrind
interception script instead.
Signed-off-by: Jeff King <peff@peff.net>
---
The valgrind script could perhaps be a bit smarter instead, but checking
#!-lines is nice and simple, and this change makes other programs like
"file" happier, too.
This problem has been around since 21d0ba7 (difftool/mergetool: refactor
commands to use git-mergetool--lib, 2009-04-08), released in v1.6.3. But
since it is only about our internal tests, and even then only about
running them with valgrind enabled, I don't know if it is worth a fix on
'maint'.
git-mergetool--lib.sh | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index 5b62785..51dd0d6 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -1,3 +1,4 @@
+#!/bin/sh
# git-mergetool--lib is a library for common merge tool functions
diff_mode() {
test "$TOOL_MODE" = diff
--
1.7.0.rc0.41.g538720
^ permalink raw reply related
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