* Re: [PATCH 1/2] Add feature release instructions to MaintNotes addendum
From: Raman Gupta @ 2009-03-26 13:51 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git
In-Reply-To: <20090326121017.6117@nanako3.lavabit.com>
Nanako Shiraishi wrote:
> Quoting rocketraman@fastmail.fm:
>
>> + - The 'maint' branch is updated to the new release.
>> +
>> + $ git checkout maint
>> + $ git merge master
>> +
>> + This is equivalent to deleting maint and recreating it from
>> + master, but it preserves the maint reflog.
>
> After giving a recipe that is better than an alternative, what's
> the point of describing an inferior alternative as "equivalent",
> when it is obviously not "equivalent"?
Is this better:
The resulting maint tree is equivalent to deleting maint and
recreating it from the tip of master, but merging from master
preserves the maint reflog.
Cheers,
Raman
^ permalink raw reply
* Re: svn clone Checksum mismatch question
From: Sverre Rabbelier @ 2009-03-26 13:54 UTC (permalink / raw)
To: Gilbert Liddell, Johannes Schindelin, Johannes Sixt
Cc: Björn Steinbrink, git
In-Reply-To: <D92CD911394B11428C65AFB4222835AE01255586@mercury.totalrepair.co.uk>
Heya,
[We do not top post on this list, instead it is customary to reply
inline, as I and Björn have done]
2009/3/26 Gilbert Liddell <gliddell@totalrepair.co.uk>:
>2009/3/26 Björn Steinbrink <B.Steinbrink@gmx.de>:
>> On 2009.03.26 03:31:53 -0700, Gilbert Liddell wrote:
>>> This morning i decided to test the clone with the full project i'm working
>>> on (11,000 files) and I get the error message Checksum mismatch: vn2.sln
>>> 0f7a82f1d38b819 expected: fde799e5ba0d1d07e6b539016bea3260
>>> got: e71db1010a0da06ea76d4163c452df72
>>>
>>> Can someone help with why this error is happening? Is there an issue with
>>> the GIT clone and large repositories?
>>
>> Which git version is that? There was some bug in git-svn that caused it
>> to fill the disk with temporary files, without noticing that those files
>> get truncated when the disk is full. That was fixed in some 1.6.0.x
>> release IIRC.
>
> Thanks for the reply, i'm using git version 1.6.2.msysgit.0.186.gf7512
Seems like it could be one of the known bugs of git-svn on windows?
(ccing Dscho and J6t)
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* RE: svn clone Checksum mismatch question
From: Gilbert Liddell @ 2009-03-26 14:18 UTC (permalink / raw)
To: Sverre Rabbelier, Johannes Schindelin, Johannes Sixt
Cc: Björn Steinbrink, git
In-Reply-To: <fabb9a1e0903260654n5e682c49hbad3d2ece093af3f@mail.gmail.com>
>2009/3/26 Gilbert Liddell <gliddell@totalrepair.co.uk>:
>>2009/3/26 Björn Steinbrink <B.Steinbrink@gmx.de>:
>>> On 2009.03.26 03:31:53 -0700, Gilbert Liddell wrote:
>>>> This morning i decided to test the clone with the full project i'm working
>>>> on (11,000 files) and I get the error message Checksum mismatch: vn2.sln
>>>> 0f7a82f1d38b819 expected: fde799e5ba0d1d07e6b539016bea3260
>>>> got: e71db1010a0da06ea76d4163c452df72
>>>>
>>>> Can someone help with why this error is happening? Is there an issue with
>>>> the GIT clone and large repositories?
>>>
>>> Which git version is that? There was some bug in git-svn that caused it
>>> to fill the disk with temporary files, without noticing that those files
>>> get truncated when the disk is full. That was fixed in some 1.6.0.x
>>> release IIRC.
>>
>> Thanks for the reply, i'm using git version 1.6.2.msysgit.0.186.gf7512
>
>Seems like it could be one of the known bugs of git-svn on windows?
> (ccing Dscho and J6t)
>
>--
>Cheers,
>
>Sverre Rabbelier
Hi,
Apologies for the Top Posting.
I've not been able to find any info about this being a but with git-svn on Windows. I stumbled across this post that appears to be the same/similar issue -
http://lists-archives.org/git/668493-git-svn-checksum-mismatch-importing-large-file.html
Gilbert.
Registered in Scotland
32 Fountain Drive
Inchinnan Business Park
Renfrewshire,PA4 9RF.
Company number:SC112872
This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom
they are addressed.
If you have received this e-mail in error please notify the
originator of the message. This footer also confirms that this
e-mail message has been scanned for the presence of computer viruses.
Any views expressed in this message are those of the individual
sender, except where the sender specifies and with authority,
states them to be the views of Total Repair Solutions.
Scanning of this message and addition of this footer is performed
by SurfControl E-mail Filter software in conjunction with
virus detection software.
^ permalink raw reply
* Re: [PATCH TopGit] hooks/pre-commit.sh: fix bashism
From: Bert Wesarg @ 2009-03-26 14:21 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: Uwe Kleine-König, Petr Baudis, git, martin f krafft,
Marc Kleine-Budde
In-Reply-To: <49CB4B12.3020408@pengutronix.de>
2009/3/26 Marc Kleine-Budde <mkl@pengutronix.de>:
> Uwe Kleine-König wrote:
>> This was introduced in fcb488d51e72c7414f9beb40ad06bf529b8b38dc.
>> A similar fix was suggested by martin f krafft, too.
>
> Works here on ubuntu bin /bin/sh is a link to /bin/dash
>
>> Reported-by: Bert Wesarg <bert.wesarg@googlemail.com>
>> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> Tested-by: Marc Kleine-Budde <mkl@pengutronix.de>
Acked-by: Bert Wesarg <bert.wesarg@googlemail.com>
Tested-by: Bert Wesarg <bert.wesarg@googlemail.com>
Thanks Uwe.
Bert
^ permalink raw reply
* Re: Reference for git.git release process
From: Raman Gupta @ 2009-03-26 14:29 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, git
In-Reply-To: <49CB3766.5090109@op5.se>
Andreas Ericsson wrote:
> Junio C Hamano wrote:
>>
>> In addition, you can keep older maintenance track around, i.e.
>>
>> git branch maint-X.Y.(Z-1) maint
>> git checkout maint
>> git merge master
>>
>> so that maintenance releases for even older codebase _could_ be issued
>> _if_ necessary.
>>
>
> Assuming one tags ones releases (which one should, and git.git does),
> creating maint-X.Y.Z when it's actually needed is a far better approach.
This is only correct if the current tip of the maint branch is in fact
the last tagged release i.e. that there is nothing pending on the
maint branch that is intended for a maintenance release on the older
codebase.
Cheers,
Raman
^ permalink raw reply
* Re: svn clone Checksum mismatch question
From: Peter Harris @ 2009-03-26 14:34 UTC (permalink / raw)
To: Gilbert Liddell; +Cc: git
In-Reply-To: <22719363.post@talk.nabble.com>
On Thu, Mar 26, 2009 at 6:31 AM, Gilbert Liddell wrote:
>
> This morning i decided to test the clone with the full project i'm working
> on (11,000 files) and I get the error message Checksum mismatch: vn2.sln
> 0f7a82f1d38b819 expected: fde799e5ba0d1d07e6b539016bea3260
> got: e71db1010a0da06ea76d4163c452df72
>
> Can someone help with why this error is happening? Is there an issue with
> the GIT clone and large repositories?
(since you mentioned msysgit in another reply) What is your
core.autocrlf setting? Did you default it to 'true' or 'input' when
you installed msysgit?
Try "git config core.autocrlf false" and resume the import process
(with "git svn fetch" or similar).
Importing from svn with autocrlf on only works if every text file has
svn:eol-style=native set in every revision. *.sln files are even
worse, since they look like text to git, but they're really binary (so
nobody sets svn:eol-style on them).
Peter Harris
^ permalink raw reply
* Re: svn clone Checksum mismatch question
From: Johannes Schindelin @ 2009-03-26 14:34 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Gilbert Liddell, Johannes Sixt, Björn Steinbrink, git
In-Reply-To: <fabb9a1e0903260654n5e682c49hbad3d2ece093af3f@mail.gmail.com>
Hi,
On Thu, 26 Mar 2009, Sverre Rabbelier wrote:
> Seems like it could be one of the known bugs of git-svn on windows?
> (ccing Dscho and J6t)
EOUTOFGITTIME,
Dscho
^ permalink raw reply
* Re: svn clone Checksum mismatch question
From: Anton Gyllenberg @ 2009-03-26 14:35 UTC (permalink / raw)
To: Björn Steinbrink, git; +Cc: Gilbert Liddell
In-Reply-To: <20090326130213.GC3114@atjola.homenet>
2009/3/26 Björn Steinbrink <B.Steinbrink@gmx.de>:
> On 2009.03.26 03:31:53 -0700, Gilbert Liddell wrote:
>> This morning i decided to test the clone with the full project i'm working
>> on (11,000 files) and I get the error message Checksum mismatch: vn2.sln
>> 0f7a82f1d38b819 expected: fde799e5ba0d1d07e6b539016bea3260
>> got: e71db1010a0da06ea76d4163c452df72
>>
>> Can someone help with why this error is happening? Is there an issue with
>> the GIT clone and large repositories?
>
> Which git version is that? There was some bug in git-svn that caused it
> to fill the disk with temporary files, without noticing that those files
> get truncated when the disk is full. That was fixed in some 1.6.0.x
> release IIRC.
I don't know if this is the same issue, but the I get a similar error
on the public twisted-python repository on both windows and linux,
with several different versions and plenty of free disk space. As this
is a publicly accessible repository it should be easy to reproduce:
git svn init -s svn://svn.twistedmatrix.com/svn/Twisted twisted
cd twisted
git svn fetch -r 13611:HEAD
This ultimately dies with the following error:
W: +empty_dir: trunk/doc/core/howto/listings/finger/finger
r13612 = f6d995ac255e3dfa08a517a6e72fbcfe63feaaa0 (trunk)
Checksum mismatch:
branches/foom/--omg-optimized/twisted/internet/cdefer/cdefer.pyx
264b0c5f7b3a00d401d1a5dcce67a3734f0eede3
expected: c7ccddd195f132926e20bab573da7ef3
got: f006323ff4714ca52c0228ce6390d415
I found this a long time ago but never got around to analyze or report it.
Anton
^ permalink raw reply
* Re: [PATCH 2/2] Add feature release instructions to gitworkflows man page
From: Raman Gupta @ 2009-03-26 14:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7veiwksrsr.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> rocketraman@fastmail.fm writes:
>
>> +Release Tagging
>> +~~~~~~~~~~~~~~~
>> +
>> +The new feature release is tagged on 'master' with a tag matching
>> +vX.Y.Z, where X.Y.Z is the new feature release version.
>> +
>> +.Release tagging
>> +[caption="Recipe: "]
>> +==========================================
>> +`git tag -s -m GIT "vX.Y.Z" vX.Y.Z`
>> +==========================================
>
> I actually always do:
>
> git tag -s -m "GIT X.Y.Z" vX.Y.Z master
>
> The argument to -m in your descriptoin is incorrectly quoted, and has an
> extra v. I also spell out 'master' to avoid mistakes, and I would be
> happy to encourage others to follow it.
Fixed.
>> +Maintenance branch update
>> +~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +The current maintenance branch is optionally tracked with the older
>> +release version number to allow for further maintenance releases on
>> +the older codebase.
>> +
>> +.Track maint
>> +[caption="Recipe: "]
>> +=====================================
>> +`git branch maint-X.Y.(Z-1) maint`
>> +=====================================
>
> This creates maint-X.Y.(Z-1) from maint, but calling this step "track
> maint" entirely misses the point.
>
> When people use the word "track", the intention is that they intend to
> merge subsequent changes to the original branch (in this case, 'maint') to
> the new branch ('maint-X.Y.(Z-1)') from time to time.
>
> That is exactly opposite to what I create maint-X.Y.(Z-1) branch for.
> This new "branch to maintain an older codebase" will *never* merge from
> 'maint' after it forks.
Yeah, I originally had written "Copy maint" but copy seemed to be more
subversion-speak rather than git-speak so I changed it. However it
does seem to accurately describe the operation. Would "Copy maint" be
acceptable terminology?
>> +Update next branch
>> +~~~~~~~~~~~~~~~~~~
>> +
>> +The 'next' branch may be rebuilt from the tip of 'master' using the
>> +surviving topics on 'next'.
>> +
>> +This step is optional. If it is done by the maintainer, then a public
>> +announcement will be made indicating that 'next' was rebased.
>
> The wording I use is more like 'rewound and rebuilt'.
Fixed.
Cheers,
Raman
^ permalink raw reply
* [PATCH 0/2] chmod cleanup (Was: [BUG?] How to make a shared/restricted repo?)
From: Johan Herland @ 2009-03-26 15:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <49CB51E2.9010903@viscovery.net>
On Thursday 26 March 2009, Johannes Sixt wrote:
> Johan Herland schrieb:
> > In the above patch, I've passed mode == -1 to finalize_temp_file()
> > from all callsites where there was no corresponding (f)chmod(foo,
> > 0444). However, after looking at the context (these are all either
> > packs or loose objects), I'm wondering if we shouldn't pass mode ==
> > 0444 for all of these. At which point we could replace the above
> > patch with this much simpler version:
>
> Indeed!
>
> > (We could also add an optional "mode" argument to
> > adjust_shared_perm(), to get rid of the double chmod().)
>
> And I think you should do that, otherwise you have a short time
> window where the permissions of a pack or loose object is less
> restrictive than you want.
Ok, here's a cleaned-up series on top of Junio's patch. It should resolve
the chmod()-after-adjust_shared_perm() issue in Junio's patch, as well as
the rename-after-chmod Windows issue reported by Hannes.
The first patch is the second alternative I sent in an earlier mail.
The second patch resolves the double chmod() left by the first patch.
Johan Herland (2):
Move chmod(foo, 0444) into move_temp_to_file()
Resolve double chmod() in move_temp_to_file()
cache.h | 1 +
fast-import.c | 3 ---
http-push.c | 1 -
http-walker.c | 1 -
index-pack.c | 7 +++----
path.c | 26 +++++++++++++++++++-------
sha1_file.c | 3 +--
7 files changed, 24 insertions(+), 18 deletions(-)
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* [PATCH 1/2] Move chmod(foo, 0444) into move_temp_to_file()
From: Johan Herland @ 2009-03-26 15:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <200903261602.37857.johan@herland.net>
When writing out a loose object or a pack (index), move_temp_to_file() is
called to finalize the resulting file. These files (loose files and packs)
should all have permission mode 0444 (modulo adjust_shared_perm()).
Therefore, instead of doing chmod(foo, 0444) explicitly from each callsite
(or even forgetting to chmod() at all), do the chmod() call from within
move_temp_to_file().
Signed-off-by: Johan Herland <johan@herland.net>
---
fast-import.c | 3 ---
http-push.c | 1 -
http-walker.c | 1 -
index-pack.c | 7 +++----
sha1_file.c | 3 +--
5 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index db44da3..23c496d 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -903,9 +903,6 @@ static char *keep_pack(char *curr_index_name)
static const char *keep_msg = "fast-import";
int keep_fd;
- chmod(pack_data->pack_name, 0444);
- chmod(curr_index_name, 0444);
-
keep_fd = odb_pack_keep(name, sizeof(name), pack_data->sha1);
if (keep_fd < 0)
die("cannot create keep file");
diff --git a/http-push.c b/http-push.c
index 6ce5a1d..e465b20 100644
--- a/http-push.c
+++ b/http-push.c
@@ -748,7 +748,6 @@ static void finish_request(struct transfer_request *request)
aborted = 1;
}
} else if (request->state == RUN_FETCH_LOOSE) {
- fchmod(request->local_fileno, 0444);
close(request->local_fileno); request->local_fileno = -1;
if (request->curl_result != CURLE_OK &&
diff --git a/http-walker.c b/http-walker.c
index 0dbad3c..c5a3ea3 100644
--- a/http-walker.c
+++ b/http-walker.c
@@ -231,7 +231,6 @@ static void finish_object_request(struct object_request *obj_req)
{
struct stat st;
- fchmod(obj_req->local, 0444);
close(obj_req->local); obj_req->local = -1;
if (obj_req->http_code == 416) {
diff --git a/index-pack.c b/index-pack.c
index 7546822..6e93ee6 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -823,8 +823,7 @@ static void final(const char *final_pack_name, const char *curr_pack_name,
}
if (move_temp_to_file(curr_pack_name, final_pack_name))
die("cannot store pack file");
- }
- if (from_stdin)
+ } else if (from_stdin)
chmod(final_pack_name, 0444);
if (final_index_name != curr_index_name) {
@@ -835,8 +834,8 @@ static void final(const char *final_pack_name, const char *curr_pack_name,
}
if (move_temp_to_file(curr_index_name, final_index_name))
die("cannot store index file");
- }
- chmod(final_index_name, 0444);
+ } else
+ chmod(final_index_name, 0444);
if (!from_stdin) {
printf("%s\n", sha1_to_hex(sha1));
diff --git a/sha1_file.c b/sha1_file.c
index 12e0dfd..87ac53b 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2252,7 +2252,7 @@ int move_temp_to_file(const char *tmpfile, const char *filename)
/* FIXME!!! Collision check here ? */
}
- if (adjust_shared_perm(filename))
+ if (chmod(filename, 0444) || adjust_shared_perm(filename))
return error("unable to set permission to '%s'", filename);
return 0;
}
@@ -2278,7 +2278,6 @@ static void close_sha1_file(int fd)
{
if (fsync_object_files)
fsync_or_die(fd, "sha1 file");
- fchmod(fd, 0444);
if (close(fd) != 0)
die("error when closing sha1 file (%s)", strerror(errno));
}
--
1.6.1.2.461.g5bad6
^ permalink raw reply related
* [PATCH 2/2] Resolve double chmod() in move_temp_to_file()
From: Johan Herland @ 2009-03-26 15:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <200903261602.37857.johan@herland.net>
move_temp_to_file() used to chmod(foo, 0444) immediately before calling
adjust_shared_perm() which potentially does another call to chmod().
This patch splits a new function (called get_shared_perm()) out of
adjust_shared_perm(). The new function adjusts a given file mode value
according to the shared_repository setting, and returns the resulting
mode. It is used in move_temp_file() to generate the correct and final
permissions to pass to chmod() in a single call.
Signed-off-by: Johan Herland <johan@herland.net>
---
cache.h | 1 +
path.c | 26 +++++++++++++++++++-------
sha1_file.c | 2 +-
3 files changed, 21 insertions(+), 8 deletions(-)
diff --git a/cache.h b/cache.h
index 9cf5a13..b24eb3a 100644
--- a/cache.h
+++ b/cache.h
@@ -623,6 +623,7 @@ enum sharedrepo {
PERM_EVERYBODY = 0664,
};
int git_config_perm(const char *var, const char *value);
+int get_shared_perm(int mode);
int adjust_shared_perm(const char *path);
int safe_create_leading_directories(char *path);
int safe_create_leading_directories_const(const char *path);
diff --git a/path.c b/path.c
index 42898e0..497db19 100644
--- a/path.c
+++ b/path.c
@@ -311,16 +311,13 @@ char *enter_repo(char *path, int strict)
return NULL;
}
-int adjust_shared_perm(const char *path)
+int get_shared_perm(int mode)
{
- struct stat st;
- int mode, tweak, shared;
+ int tweak, shared;
if (!shared_repository)
- return 0;
- if (lstat(path, &st) < 0)
- return -1;
- mode = st.st_mode;
+ return mode;
+
if (shared_repository < 0)
shared = -shared_repository;
else
@@ -343,6 +340,21 @@ int adjust_shared_perm(const char *path)
mode |= FORCE_DIR_SET_GID;
}
+ return mode;
+}
+
+int adjust_shared_perm(const char *path)
+{
+ struct stat st;
+ int mode, tweak, shared;
+
+ if (!shared_repository)
+ return 0;
+ if (lstat(path, &st) < 0)
+ return -1;
+
+ mode = get_shared_perm(st.st_mode);
+
if (((shared_repository < 0
? (st.st_mode & (FORCE_DIR_SET_GID | 0777))
: (st.st_mode & mode)) != mode) &&
diff --git a/sha1_file.c b/sha1_file.c
index 87ac53b..05af3c5 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2252,7 +2252,7 @@ int move_temp_to_file(const char *tmpfile, const char *filename)
/* FIXME!!! Collision check here ? */
}
- if (chmod(filename, 0444) || adjust_shared_perm(filename))
+ if (chmod(filename, get_shared_perm(0444)))
return error("unable to set permission to '%s'", filename);
return 0;
}
--
1.6.1.2.461.g5bad6
^ permalink raw reply related
* [RFC] Interactive difftool
From: Ping Yin @ 2009-03-26 15:29 UTC (permalink / raw)
To: Git Mailing List, davvid
Before git-difftool goes to master, i want to propose a new feature to
add to or replace the current behaviour of difftool. With current
difftool, we can only see the diff one by one. However, sometimes what
we want is to see the diff of selected files, or in a different order,
just like what we can do in the gui. So here is what i propose
$ git difftool --interactive [options]
[1] diff.c | 10 +++++++++-
[2] t/t4020-diff-external.sh | 8 ++++++++
Choose the file you want to see the diff of: 2
When the user types 2 and then <enter>, the external diff program is called
Further more, instead of just type a number, a letter can be prepended
to the number to represent different ways of diff. For example
t2 (tool 2): see the diff for file 2 with the configured diff tool
p2 (patch 2): see the diff for file 2 in the patch format
What do you think?
Ping Yin
^ permalink raw reply
* Re: [JGIT PATCH 3/5] Test case for pack index CRC32 when written by PackWriter
From: Daniel Cheng @ 2009-03-26 15:35 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1238030515-31768-3-git-send-email-spearce@spearce.org>
Shawn O. Pearce wrote:
> Suggested-by: Daniel Cheng (aka SDiZ) <j16sdiz+freenet@gmail.com>
> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
> ---
> .../tst/org/spearce/jgit/lib/PackWriterTest.java | 33 ++++++++++++++++++++
> 1 files changed, 33 insertions(+), 0 deletions(-)
>
Thanks.
^ permalink raw reply
* RE: Help designing work flow
From: John Dlugosz @ 2009-03-26 15:38 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <49B4F5A9.5060304@op5.se>
> You can tell "git log" to only show one line of history too, but
> besides
> that, micro-details are good. You definitely want to be able to search
> the micro-details when things go awry (and they will), so you see
> exactly
> why some particular algorithm changed later.
>
I misread that the first time. I thought you meant that you can tell
git log to follow down the left parents only.
So, how would you do that? List the completed merged topic nodes only,
not the detailed nodes that make it up?
--John
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
If you received this in error, please contact the sender and delete the material from any computer.
^ permalink raw reply
* Re: [JGIT PATCH 3/5] Test case for pack index CRC32 when written by PackWriter
From: Daniel Cheng @ 2009-03-26 15:35 UTC (permalink / raw)
To: git; +Cc: git
In-Reply-To: <1238030515-31768-3-git-send-email-spearce@spearce.org>
Shawn O. Pearce wrote:
> Suggested-by: Daniel Cheng (aka SDiZ) <j16sdiz+freenet@gmail.com>
> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
> ---
> .../tst/org/spearce/jgit/lib/PackWriterTest.java | 33 ++++++++++++++++++++
> 1 files changed, 33 insertions(+), 0 deletions(-)
>
Thanks.
--
^ permalink raw reply
* Re: large(25G) repository in git
From: Marcel M. Cary @ 2009-03-26 15:43 UTC (permalink / raw)
To: Adam Heath; +Cc: git@vger.kernel.org
In-Reply-To: <49C7FAB3.7080301@brainfood.com>
Adam Heath wrote:
> We maintain a website in git. This website has a bunch of backend
> server code, and a bunch of data files. Alot of these files are full
> videos.
>
> We use git, so that the distributed nature of website development can
> be supported. Quite often, you'll have a production server, with
> online changes occurring(we support in-browser editting of content), a
> preview server, where large-scale code changes can be previewed, then
> a development server, one per programmer(or more).
My company manages code in a similar way, except we avoid this kind of
issue (with 100 gigabytes of user-uploaded images and other data) by not
checking in the data. We even went so far is as to halve the size of
our repository by removing 2GB of non-user-supplied images -- rounded
corners, background gradients, logos, etc, etc. This made Git
noticeably faster.
While I'd love to be able to handle your kind of use case and data size
with Git in that way, it's a little beyond the intended usage to handle
hundreds of gigabytes of binary data, I think.
I imagine as your web site grows, which I'm assuming is your goal, your
problems with scaling Git will continue to be a challenge.
Maybe you can find a way to:
* Get along with less data in your non-production environments; we're
hoping to be able to do this eventually
* Find other ways to copy it; we use rsync even though it does take
forever to crawl over the file system
* Put your data files in a separate Git repository, at least, assuming
your checkin, update, and release code more often than your video files.
That way you'll experience pain less often, and maybe even be able to
tune your repository differently.
Marcel
^ permalink raw reply
* Re: [PATCH 01/10] refs: add "for_each_bisect_ref" function
From: Michael J Gruber @ 2009-03-26 15:50 UTC (permalink / raw)
To: Christian Couder
Cc: Sverre Rabbelier, Junio C Hamano, git, John Tapsell,
Johannes Schindelin
In-Reply-To: <200903260848.42104.chriscool@tuxfamily.org>
Christian Couder venit, vidit, dixit 26.03.2009 08:48:
> Hi Sverre,
>
> Le jeudi 26 mars 2009, Sverre Rabbelier a écrit :
>> Heya
>>
>> On Thu, Mar 26, 2009 at 05:55, Christian Couder <chriscool@tuxfamily.org>
> wrote:
>>> Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
>>
>> A 10 patches series with no cover letter?
>
> I am not a big fan of cover letters. Usually I prefer adding comments in the
> patches.
I'm sorry I have to say that, but your individual preferences don't
matter. Many of us would do things differently, each in their own way,
but people adjust to the list's preferences. It's a matter of attitude.
So, please...
Cheers,
Michael
>
>> And no description of the
>> individual patches either!
>
> There is a commit message in each patch. And many of the patches are very
> small.
>
>> C'mon Christian, you know better than that
>> ;).
>
> If some commit messages are not clear enough, please tell me and I will try
> to improve them ;)
>
> Regards,
> Christian.
^ permalink raw reply
* Re: Improve tags
From: Michael J Gruber @ 2009-03-26 16:02 UTC (permalink / raw)
To: Etienne Vallette d'Osia; +Cc: git
In-Reply-To: <49CB798B.4090107@gmail.com>
Etienne Vallette d'Osia venit, vidit, dixit 26.03.2009 13:48:
> Hi,
>
> I search a way to track commits in function of their aim.
>
> I tried to use branches (test, debugger, etc).
> For example if I search the commits related to tests,
> I can search all commits what are in branch test and not in branch debugger,
> but it's boring (I need to exclude all other branches than test)
> Moreover, if I remove a branch, it will complicate the search.
>
> In addition, branches are a way to specify streams,
> not a way to specify an aim for a commit.
> (like in ruby a class is a method container, not a type)
> So branch names are often like next, pu, dev, test, stupid-idea, etc.
> They are totally useless for tracking aims.
>
> The method used in every repositories I looked into
> is to use the "aim: subject" form in their commit messages.
> So search all commits related to a specific aim is equivalent
> to grep "my-aim:" in commit messages.
> The problem is that this method is not used in all commits
> ("aim - subject" or just "subject" are used too),
> so I can't assume to find all commits with a such method...
> And if a search a more generic form ("test"), I might find
> useless commits that will pollute my results...
>
> The last method I can find, is to use tags.
> But, as CVS and many others do, tags are unique.
> It is usefull for tagging a software version number,
> but not for tracking.
>
> So, we have branches, which are not stable,
> tags, which are unique,
> and commit messages, which are not normalized.
>
> What can we do ?
>
> In my mind, the good ways are to improve the commit message way,
> or, better, to change the current tag concept.
>
> One improvement could be to add a mechanism similar to "signed-off-by:"
> message: add an option in git-commit to facilitate the creation of "tags"
> and make sure these "tags" will be normalized...
> example: `git commit -t test,debugger -m "add test for debugger"`
> this will create a commit and add automatically
> "test: debugger:" at begin or
> "tags: test, debugger" at end of the message
> (like the "signed-off-by: xxx" lines)
> It's not really better this current solution,
> but it's a first step to normalization.
>
> There is still a big problem with this solution : this tags are immutable,
> as they are stored inside the commit.
>
> An other improvement would be to create new version of tags.
> `git tag v1.6.3` would create a unique tag, and
> `git tag --no-unique test` would create a simple tag.
> (until we can change the default)
> The -t option of git-commit is still possible,
> but it will call the new git-tag.
>
> Note: Theses tags may be treated like refs (git log fault-tolerance),
> but they can't be stored in $GIT_DIR/refs directory,
> as they reference a list a commits...
>
> So, I see 2 solutions:
> - Normalize the way to write tags but keep them into commit message:
> (-) There will be 2 sorts of tags: static immutable and dynamic unique
> (+) This way is totally retro-compatible
> - Change the tags concept:
> (-) Need to change the tag object format (ouch)
> (+) More powerful
>
> Maybe I have missed a better tool to do my job ?
> Or there is a better improvement which is more simple ?
>
>
> Best regards,
>
>
> Etienne Vallette d'Osia
>
> ps: I'm really sorry if my message is full of English errors...
You described your motivation and use case very clearly!
Maybe "label" would be an appropriate name for "non-unique tags". I
assume they should be local and non-versioned. It sounds as if a file
storing a list of sha1s could be the simplest approach (one file per
label in a new subdir of .git), although this may not scale well. A
first step could be implementing a command "git label" in shell which
sets and displays labels. Later on, various builtins would need to be
taught about it if you want labels displayed in log etc.
Michael
^ permalink raw reply
* Re: large(25G) repository in git
From: Adam Heath @ 2009-03-26 16:35 UTC (permalink / raw)
To: Marcel M. Cary; +Cc: git@vger.kernel.org
In-Reply-To: <49CBA2AB.30304@oak.homeunix.org>
Marcel M. Cary wrote:
> My company manages code in a similar way, except we avoid this kind of
> issue (with 100 gigabytes of user-uploaded images and other data) by not
> checking in the data. We even went so far is as to halve the size of
> our repository by removing 2GB of non-user-supplied images -- rounded
> corners, background gradients, logos, etc, etc. This made Git
> noticeably faster.
Disk space is cheap.
> While I'd love to be able to handle your kind of use case and data size
> with Git in that way, it's a little beyond the intended usage to handle
> hundreds of gigabytes of binary data, I think.
>
> I imagine as your web site grows, which I'm assuming is your goal, your
> problems with scaling Git will continue to be a challenge.
>
> Maybe you can find a way to:
>
> * Get along with less data in your non-production environments; we're
> hoping to be able to do this eventually
We do that by only cloning/checking out certain modules.
However, as is always the case, sometimes a bug occurs with production
data, and you need to use the real data to track it down.
> * Find other ways to copy it; we use rsync even though it does take
> forever to crawl over the file system
>
> * Put your data files in a separate Git repository, at least, assuming
> your checkin, update, and release code more often than your video files.
> That way you'll experience pain less often, and maybe even be able to
> tune your repository differently.
As already mentioned, our sub-sites *are* in separate repos. There's
a base repository, that has just the event/backend code. Then 32
*other* repositories, where the actual websites are.
We want to use *some* kind of versioning system. Being able to have
history of *all* changes is extremely useful. Not to mention being
able to track what each separate user does as they modify their files
thru their browser.
subversion is just right out. It's centralized. It leaves poop all
over the place.
mercurial is just right out. If you do several *separate* commits of
*separate* files, but don't push for some time period, then eventually
do a push/pull, where the sum total of the changes is larger than some
value, mercurial will fail when it tries to then update the local
directory. This limit is based on 2G, a hard-coded python limit(even
on a 64-bit host), because mercurial reads the entire set of changes
into a python string.
git mmaps files, does window scanning of the pack files. It *might*
read a single file all into memory, for compression purposes; I'm not
certain on this. We certainly haven't hit any limits that cause it to
fail outright.
I haven't tried any others.
^ permalink raw reply
* Re: [PATCH] format-patch: add arbitrary email headers
From: Michael Hendricks @ 2009-03-26 16:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3ad11kqh.fsf@gitster.siamese.dyndns.org>
On Wed, Mar 25, 2009 at 12:11:02PM -0700, Junio C Hamano wrote:
> Michael Hendricks <michael@ndrix.org> writes:
>
> > format-patch supports the format.headers configuration for adding
> > arbitrary email headers to the patches it outputs. This patch adds
> > support for a --header argument which makes the same feature available
> > from the command line. This is useful when the content of custom
> > email headers must change from branch to branch.
>
> How should this interact with the configuration variable?
>
> Typically we allow command line options to override the matching config
> variable, so that people can say "here are the settings I ordinarily use"
> in the config file, and say "but I do not want the usual values to take
> effect for this particular invocation; please use these _instead_" with
> command line options.
>
> Note that the above question is "how should this interact"; not "how does
> this interact". I can see you chose to make this cumulative in your patch
> and the documentaiton.
>
> I am asking if that is what the users want, overriding is preferred, or
> perhaps another option to clear extra headers (say, "--no-extra-headers")
> is necessary to allow both.
In all the cases where I use custom headers on patch emails, I want
the command line headers to be cumulative with the config headers. I
only configure headers which are constant (such as "X-Project:
project-name"). The ones that vary have no reasonable default value
since they typically represent a bug tracking number or something
similar.
Perhaps --add-header is a better name for this argument. That name at
least makes it clear that headers specified on the command line are
cumulative. If someone has a use case for --no-extra-headers, they
can add it later and --add-header retains the same meaning.
Follow-up patch coming shortly.
--
Michael
^ permalink raw reply
* Re: [PATCH 3/8] Documentation: rename docbook-xsl-172 attribute to git-asciidoc-no-roff
From: Junio C Hamano @ 2009-03-26 16:47 UTC (permalink / raw)
To: Jeff King; +Cc: Chris Johnsen, git
In-Reply-To: <20090326094322.GB14292@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Mar 24, 2009 at 02:48:52PM -0500, Chris Johnsen wrote:
>
>> I am not opposed to providing more version-specific controls, but I am not
>> sure which versions are important enough to justify their own variables.
>> Are you indicating that 1.73 is important enough because it was a "return
>> to sanity" after 1.72?
>
> No, mainly because it is what is shipped in the last version of Debian,
> which means it is a major enough version that there will be a lot of
> people using it.
>
> But let's just start with adding the tweakable knobs (which your series
> is already doing), and see in what ways they need to be tweaked for
> popular platforms before going overboard.
When I was trying out the series yesterday, I was wondering if this is
something we can autodetect.
Output from "asciidoc --version" is easily machine parsable for giving
asciidoc7compatible aka ASCIIDOC8, but I couldn't come up with anything
simpler than probing a few hardcoded paths under /usr/share/sgml; that
approach is unacceptable because would not work if your stylesheets are in
somewhere we do not know about. Ideally, we should be able to ask the
tools we invoke (e.g. xmlto) to get that information.
^ permalink raw reply
* [PATCH] format-patch: add arbitrary email headers
From: Michael Hendricks @ 2009-03-26 16:51 UTC (permalink / raw)
To: gitster, git; +Cc: Michael Hendricks
In-Reply-To: <20090326164212.GF29569@ginosko.ndrix.org>
format-patch supports the format.headers configuration for adding
arbitrary email headers to the patches it outputs. This patch adds
support for an --add-header argument which makes the same feature
available from the command line. This is useful when the content of
custom email headers must change from branch to branch.
This patch has been sponsored by Grant Street Group
Signed-off-by: Michael Hendricks <michael@ndrix.org>
---
Documentation/git-format-patch.txt | 5 +++++
builtin-log.c | 2 ++
t/t4014-format-patch.sh | 15 +++++++++++++++
3 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index c2eb5fa..51fd716 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -161,6 +161,11 @@ if that is not set.
Add a "Cc:" header to the email headers. This is in addition
to any configured headers, and may be used multiple times.
+--add-header=<header>::
+ Add an arbitrary header to the email headers. This is in addition
+ to any configured headers, and may be used multiple times.
+ For example, --add-header="Organization: git-foo"
+
--cover-letter::
In addition to the patches, generate a cover letter file
containing the shortlog and the overall diffstat. You can
diff --git a/builtin-log.c b/builtin-log.c
index c7a5772..27bc0dc 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -918,6 +918,8 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
cover_letter = 1;
else if (!strcmp(argv[i], "--no-binary"))
no_binary_diff = 1;
+ else if (!prefixcmp(argv[i], "--add-header="))
+ add_header(argv[i] + 13);
else
argv[j++] = argv[i];
}
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index f187d15..11061dd 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -128,6 +128,21 @@ test_expect_success 'additional command line cc' '
grep "^ *S. E. Cipient <scipient@example.com>$" patch5
'
+test_expect_success 'command line headers' '
+
+ git config --unset-all format.headers &&
+ git format-patch --add-header="Cc: R. E. Cipient <rcipient@example.com>" --stdout master..side | sed -e "/^$/q" >patch6 &&
+ grep "^Cc: R. E. Cipient <rcipient@example.com>$" patch6
+'
+
+test_expect_success 'configuration headers and command line headers' '
+
+ git config --replace-all format.headers "Cc: R. E. Cipient <rcipient@example.com>" &&
+ git format-patch --add-header="Cc: S. E. Cipient <scipient@example.com>" --stdout master..side | sed -e "/^$/q" >patch7 &&
+ grep "^Cc: R. E. Cipient <rcipient@example.com>,$" patch7 &&
+ grep "^ *S. E. Cipient <scipient@example.com>$" patch7
+'
+
test_expect_success 'multiple files' '
rm -rf patches/ &&
--
1.6.2.1.317.ga1cbc
^ permalink raw reply related
* Re: [PATCH 01/10] refs: add "for_each_bisect_ref" function
From: Johannes Schindelin @ 2009-03-26 16:52 UTC (permalink / raw)
To: Michael J Gruber
Cc: Christian Couder, Sverre Rabbelier, Junio C Hamano, git,
John Tapsell
In-Reply-To: <49CBA42D.3000404@drmicha.warpmail.net>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1362 bytes --]
Hi,
On Thu, 26 Mar 2009, Michael J Gruber wrote:
> Christian Couder venit, vidit, dixit 26.03.2009 08:48:
>
> > Le jeudi 26 mars 2009, Sverre Rabbelier a écrit :
> >
> >> A 10 patches series with no cover letter?
> >
> > I am not a big fan of cover letters. Usually I prefer adding comments
> > in the patches.
>
> I'm sorry I have to say that, but your individual preferences don't
> matter. Many of us would do things differently, each in their own way,
> but people adjust to the list's preferences. It's a matter of attitude.
> So, please...
Actually, a better way to ask for a cover letter would have been to
convince Christian. So I'll try that.
>From the patch series' titles (especially when they are cropped due to the
text window being too small to fit the indented thread), it is not all
that obvious what you want to achieve with those 10 patches.
>From recent discussions, I seem to remember that you wanted to have some
cute way to mark commits as non-testable during a bisect, and I further
seem to remember that Junio said that very method should be usable outside
of bisect, too.
Unfortunately, that does not reveal to me, quickly, what is the current
state of affairs, and what you changed since the last time.
In addition, I am very sorry that I cannot review your patches; day job is
killing me right now.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 01/10] refs: add "for_each_bisect_ref" function
From: Sverre Rabbelier @ 2009-03-26 16:54 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Michael J Gruber, Christian Couder, Junio C Hamano, git,
John Tapsell
In-Reply-To: <alpine.DEB.1.00.0903261748280.12753@intel-tinevez-2-302>
Heya,
On Thu, Mar 26, 2009 at 17:52, Johannes Schindelin
<Johannes.Schindelin@gmx.de> > From the patch series' titles
(especially when they are cropped due to the
> text window being too small to fit the indented thread), it is not all
> that obvious what you want to achieve with those 10 patches.
<snip>
> Unfortunately, that does not reveal to me, quickly, what is the current
> state of affairs, and what you changed since the last time.
This is exactly what I meant to say, only worded much much better,
thanks Johannes! :)
--
Cheers,
Sverre Rabbelier
^ 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