Re: [PATCH] git-repack-script: Add option to repack all objects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Junio C Hamano wrote: Frank Sorenson [EMAIL PROTECTED] writes: This patch adds an option to git-repack-script to repack all objects, including both packed and unpacked. This allows a full repack of a git archive (current cogito packs from 39MB to 4.5MB, and git packs from 4.4MB to 3.8MB). Signed-off-by: Frank Sorenson [EMAIL PROTECTED] While I agree that giving more flexibility to repack objects is a good idea, I am not sure rolling all existing objects into one pack and removing the existing one is a good way to go. It reduces the disk space requirement significantly (linux packs from 135MB to 73MB), and I'm seeing speed improvements as well (probably because cache-cold operation requires far less seeking, and the caching requirements are smaller). What are the benefits to keeping old packs? I'd do this slightly differently. I do not think removing existing pack belongs to this command. We would probably want a separate tool to find extra/redundant packs and remove them, or more generally optimize packs by selectively exploding them and repacking them (pack optimizer). I disagree about not removing old packs. When you repack your suitcase, you take everything out and put it back in again, so a command named repack should remove all existing objects, and put them back again. Okay, so the pack algorithm could be better, but that only means that repacking the entire set of objects would improve things more, making some sort of git-repack-all an even more valuable operation. Frank - -- Frank Sorenson - KD7TZK Systems Manager, Computer Science Department Brigham Young University [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDErwnaI0dwg4A47wRAkVGAKDqDjQ5IBTO+DC/nKpYl+69w7RESgCg6omQ xwbQqnXJnfxITC1TAjRtLSk= =tCyP -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-repack-script: Add option to repack all objects.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Junio C Hamano wrote: This originally came from Frank Sorenson but with a bit of rework to allow future enhancement to the command without changing the external interface for removal part. With the '-a' option, all objects in the current repository are packed into a single pack. When the '-d' option is given at the same time, existing packs that were made redundant by this round of repacking are deleted. Since we currently have only two repacking strategies, one '-a' (everything into one) and the other not '-a' (incrementally pack only the unpacked ones), '-d' is meaningful only used with '-a' and removes all the existing packs before repacking for now. Thank you for explaining the reasoning, and reworking the patch. This does make more sense, and I can see the logic for leaving around the packs. Coming from the perspective of the end user, I would probably want to repack quite a bit more often to take advantage of the size and speed advantages, while large public repositories will probably want to repack at much longer periods. Thanks for seeing both perspectives. I like your updated patch. Frank - -- Frank Sorenson - KD7TZK Systems Manager, Computer Science Department Brigham Young University [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDE1r3aI0dwg4A47wRAldNAJ9J7wmyQMsMm5G0FgvOggc+QDtg/QCg0T+w y6A/46LYEr1zhFgxK6uKX0I= =z8uM -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] git-rev-list: Don't die on a bad tag
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The current cogito tree contains an invalid tag
(junio-gpg-pub = 0918385dbd9656cab0d1d81ba7453d49bbc16250), and
git-repack-script (and probably others) will die when git-rev-list
tries to dump the objects. This patch changes it to complain, but
continue.
Signed-off-by: Frank Sorenson [EMAIL PROTECTED]
diff --git a/rev-list.c b/rev-list.c
- --- a/rev-list.c
+++ b/rev-list.c
@@ -418,8 +418,10 @@ static struct commit *get_commit_referen
if (tag_objects !(object-flags UNINTERESTING))
add_pending_object(object, tag-tag);
object = parse_object(tag-tagged-sha1);
- - if (!object)
- - die(bad object %s, sha1_to_hex(tag-tagged-sha1));
+ if (!object) {
+ fprintf(stderr, Bad tag: %s\n,
sha1_to_hex(tag-tagged-sha1));
+ return NULL;
+ }
}
/*
Frank
- --
Frank Sorenson - KD7TZK
Systems Manager, Computer Science Department
Brigham Young University
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDECF9aI0dwg4A47wRAncdAKCIcNFzihLm9cy7RWRKakM6INikigCfcCvu
R/XG+XlMsbgWesEvZcFBmQY=
=OY7G
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Barebone Porcelain. Where to stop?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Junio C Hamano wrote: Catalin Marinas [EMAIL PROTECTED] writes: I don't see git going towards stgit at all. Indeed, it gets closer to cogito but I still like cogito over plain git since it's easier to use (my goal, though, is to add pull/clone commands to stgit so that one doesn't need to rely on directly using other tools). All good to hear. I do not speak for Linus, but I think core should not be competing with Porcelain. To me, there are four purposes for the barebone Porcelain layer: (1) provide the end user a minimum UI to do essential things. (2) codify the BCP/convention to use the core by higher level SCMs to help them stay compatible with each other where possible (e.g. what .git/HEAD means, when it gets updated, and to what was discussed recently). (3) serve as an example for people interested in learning the core GIT (i.e. they may be starting their own Porcelain). (4) implement operations that are heavy on logic/convention but does not have much UI need so that higher level SCMs can implement their own UI by just being a thin wrapper around them (e.g. clone/fetch and push). These all sound good. Along the lines of #4, one potential purpose I've been curious about is the possibility of pulling these core operations out into a library that Porcelain could use directly. This way, Porcelain, including the minimum git UI (your #1), could directly link in and call the needed functions, and rather than stringing sequences of git-whatever commands together in a shell script. This would allow Porcelain to take advantage of the core git more directly, and would improve the speed of Porcelain. The minimum UI (#1) would be a much simpler example (#3), since it would only be the front-end, rather than the front-end/back-end combination it is now. Is this something we want to consider, or am I out in left field? :) Frank - -- Frank Sorenson - KD7TZK Systems Manager, Computer Science Department Brigham Young University [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC3BfFaI0dwg4A47wRApyQAKD3yXqYfcm7TgJ5GnIZsw5ZcB+P/wCgpM75 cjPHXi8jd0VthQjKNFITFxU= =Jxx/ -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Add commify function to cg-Xlib
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Here is a patch to add a commify function to cg-Xlib. I'll follow
this up with a patch that uses the new function to commify the
number and size of objects pulled in cg-pull.
Signed-off-by: Frank Sorenson [EMAIL PROTECTED]
Add a commify function to cg-Xlib
- ---
commit de4fd646c830137b9a4c1b5735f9573167f6
tree 1b9d3d0db498fde457d60f6658f616a1aa6b9fe3
parent b21855b8734ca76ea08c0c17e4a204191b6e3add
author Frank Sorenson [EMAIL PROTECTED] Wed, 06 Jul 2005 00:38:16 -0600
committer Frank Sorenson [EMAIL PROTECTED] Wed, 06 Jul 2005 00:38:16 -0600
cg-Xlib |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/cg-Xlib b/cg-Xlib
- --- a/cg-Xlib
+++ b/cg-Xlib
@@ -128,6 +128,9 @@ update_index () {
git-update-cache --refresh | sed 's/needs update$/locally modified/'
}
+commify() {
+ echo $1 | sed ':a;s/\B[0-9]\{3\}\/,/;ta'
+}
print_help () {
which cg-$1 /dev/null 21 || exit 1
Frank
- --
Frank Sorenson - KD7TZK
Systems Manager, Computer Science Department
Brigham Young University
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCy4GiaI0dwg4A47wRAg+vAJ9ZCn7ptBARMY+ELyS+uQ893/aDLgCgsk8b
dhfcgflxQRURowVFP2qiRe4=
=u7ap
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add commify function to cg-Xlib
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Petr Baudis wrote: I don't know. Could you give some supporting argumentation, please? Is it really that hard to read for the Americans without the commas? It is at least harder to read for me as an European - we don't have any commas in there, just spaces (if anything at all). Besides, the number is usually not in higher order than thousands, so... why is it worth it? Okay. Not a problem. It just cleaned things up a little for me. If I want to keep it, I'll probably just maintain it in my local tree. Frank - -- Frank Sorenson - KD7TZK Systems Manager, Computer Science Department Brigham Young University [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCzBumaI0dwg4A47wRAmKKAJ90HJymEjSHwvpKq7pjQkXf9wz7sACfXl8F BttVqvdhovFaGYEn9PibeC0= =N90S -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
