* Re: Anyone running GIT on native Windows
From: Asger Ottar Alstrup @ 2007-05-08 18:21 UTC (permalink / raw)
To: git
In-Reply-To: <463F14FF.F8DF11EB@eudaptics.com>
Johannes Sixt wrote:
> The next big thing to think about is an installer. Does anyone have a
> suggestion for a free installer tool? I only know about Microsoft's WiX
> (wix.sf.net), but it requires .NET (for the developer, not the user).
The relevant choices are:
- WiX - http://wix.sourceforge.net/
- NSIS - http://nsis.sourceforge.net/
- Inno Setup - http://www.jrsoftware.org/isinfo.php
NSIS is very low level, and thus has a pretty steep learning curve. You
are more or less programming machine code. However, if you invest the
time and energy, the NSIS installers are best of class: fast, small and
it can do anything you want.
WiX is based on .MSI technology, which is somewhat slow, but of course
it works, since it's the "official" Microsoft installation format.
Inno Setup is worth a second look. I think this might be the best choice
for you: relatively simple to approach, and the installers are good.
Regards,
Asger Ottar Alstrup
^ permalink raw reply
* Re: [PATCH] Add a birdview-on-the-source-code section to the user manual
From: Karl Hasselström @ 2007-05-08 21:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: bfields, junio, git
In-Reply-To: <Pine.LNX.4.64.0705081709230.4167@racer.site>
On 2007-05-08 17:10:47 +0200, Johannes Schindelin wrote:
> + char *`, but is actually expected to be a pointer to `unsigned
> + char[20]`. This variable will contain the big endian version of the
> + 40-character hex string representation of the SHA-1.
Either it should be "unsigned char[40]" (or possibly 41 with a
terminating \0), or else you shouldn't be talking about hexadecimal
since it's just a 20-byte big-endian unsigned integer. (A third
possibility is that I'm totally confused.)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] Add a birdview-on-the-source-code section to the user manual
From: Johannes Schindelin @ 2007-05-08 21:07 UTC (permalink / raw)
To: Karl Hasselström; +Cc: bfields, junio, git
In-Reply-To: <20070508210153.GA3969@diana.vm.bytemark.co.uk>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 686 bytes --]
Hi,
On Tue, 8 May 2007, Karl Hasselström wrote:
> On 2007-05-08 17:10:47 +0200, Johannes Schindelin wrote:
>
> > + char *`, but is actually expected to be a pointer to `unsigned
> > + char[20]`. This variable will contain the big endian version of the
> > + 40-character hex string representation of the SHA-1.
>
> Either it should be "unsigned char[40]" (or possibly 41 with a
> terminating \0), or else you shouldn't be talking about hexadecimal
> since it's just a 20-byte big-endian unsigned integer. (A third
> possibility is that I'm totally confused.)
It is 40 hex-character, but 20 _byte_. If you have any ideas how to
formulate that better than I did...
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Change all git-status output to be "comments"
From: Junio C Hamano @ 2007-05-08 21:07 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20070508021355.GA22383@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> You wouldn't believe how many of my merge commits end with
> the following message from git-status:
>
> "nothing to commit (working directory clean)"
>
> This happens because of the way I sometimes create (and resolve)
> some types of merges. My commit message buffer gets prepped with
> the output of git-status, which has this nice message way down at the
> bottom of the file, below a large-ish block of lines that start with
> "#". Since git-commit strips those lines, I always fail to see the
> trailing line that doesn't start with "#" and consequently fail to
> see that "nothing to commit ..." will be part of my merge message.
>
> So always comment out the output of git-status.
I think a better change would be to remove the 'nothing to
commit' when recording a merge. The tool strongly discourage
creating an empty commit (iow, "diff-tree it^ it" is empty) for
a single parent case, while a merge that ends up (even when you
did not use "ours" strategy but resolved "fixing the same bug,
but differently" conflicts by hand) nullifying everything the
other side did is a perfectly normal merge.
I do not have a strong feeling against saying '# ' in front of
'nothing to commit' in the non-merge cases, other than that the
current one makes the 'nothing to commit' message itself stand
out in 'git status' output. There also is a small issue of
updating the documentation and retraining people. We need to
grep and replace them in the documentation and tutorial, and
start telling people who learn older copies of documentation
google finds that the older git said things slightly
differently.
^ permalink raw reply
* Re: [PATCH] Add --no-reuse-delta, --window, and --depth options to
From: Junio C Hamano @ 2007-05-08 21:12 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Theodore Ts'o, Git Mailing List
In-Reply-To: <alpine.LFD.0.99.0705081005400.24220@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> In which case, it is git-gc that needs to get a bit smarter. Maybe
> something like this:
I agree git-gc should be tuned to "one size fits all well enough"
default, rather than getting more complicated parameters to fine
tune its behaviour to satisfy power users.
> @@ -65,7 +65,20 @@ int cmd_gc(int argc, const char **argv, const char *prefix)
> if (run_command_v_opt(argv_reflog, RUN_GIT_CMD))
> return error(FAILED_RUN, argv_reflog[0]);
>
> - if (run_command_v_opt(argv_repack, RUN_GIT_CMD))
> + if (num_loose_objects() > 0) {
> + do_repack = 1;
> + } else {
> + struct packed_git *p;
> + unsigned long num_pack = 0;
> + if (!packed_git)
> + prepare_packed_git();
> + for (p = packed_git; p; p = p->next)
> + if (p->pack_local)
> + num_pack++;
> + if (num_pack > 1)
> + do_repack = 1;
> + }
> + if (do_repack && run_command_v_opt(argv_repack, RUN_GIT_CMD))
> return error(FAILED_RUN, argv_repack[0]);
>
> if (prune && run_command_v_opt(argv_prune, RUN_GIT_CMD))
Is this even correct?
When your repository is fully packed, if you decided to discard
one of your topic branches with "git branch -D", what does this
code do? We see no loose objects, we see only one pack, so the
unreachable objects are left in the pack?
^ permalink raw reply
* Re: [PATCH] Add a birdview-on-the-source-code section to the user manual
From: Karl Hasselström @ 2007-05-08 21:31 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: bfields, junio, git
In-Reply-To: <Pine.LNX.4.64.0705082306100.4167@racer.site>
On 2007-05-08 23:07:04 +0200, Johannes Schindelin wrote:
> On Tue, 8 May 2007, Karl Hasselström wrote:
>
> > On 2007-05-08 17:10:47 +0200, Johannes Schindelin wrote:
> >
> > > + char *`, but is actually expected to be a pointer to `unsigned
> > > + char[20]`. This variable will contain the big endian version of the
> > > + 40-character hex string representation of the SHA-1.
> >
> > Either it should be "unsigned char[40]" (or possibly 41 with a
> > terminating \0), or else you shouldn't be talking about
> > hexadecimal since it's just a 20-byte big-endian unsigned integer.
> > (A third possibility is that I'm totally confused.)
>
> It is 40 hex-character, but 20 _byte_. If you have any ideas how to
> formulate that better than I did...
I think this is less confusing:
This variable will contain the 160-bit SHA-1.
It avoids talking of hex, since it's not really stored in hex format
any more than any other binary number with a number of bits divisible
by four. And it avoids saying big-endian, which is not relevant anyway
since we don't use hashes as integers.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: git rebase chokes on directory -> symlink -> directory
From: Alex Riesen @ 2007-05-08 21:50 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Git Mailing List
In-Reply-To: <463FCD7C.4020009@zytor.com>
H. Peter Anvin, Tue, May 08, 2007 03:08:12 +0200:
> The following tree:
>
> http://git.kernel.org/?p=linux/kernel/git/hpa/linux-2.6-newsetup.git;a=summary
>
> ... has one commit which changes arch/x86_64/boot from a directory to a
> symlink, and another one which changes it back. Apparently as a result,
> git rebase dies horribly; on the first change it requires manual fixup,
> but it crashes on the second, with or without -m.
What kind of manual fixup did you do? I tried to reproduce it, and did
the following:
git clone --reference ~/linux.git git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-newsetup.git
cd linux-2.6-newsetup.git
git rebase a989705c4cf6e6c1a339c95f9daf658b4ba88ca8
It stopped at 'Revert "x86-64: Make arch/x86-64/boot a symlink to
arch/i386/boot"' aka cd312503f8e8a88895b12bf810677406284142e6.
I went on:
rm arch/x86-64/boot
git checkout cd312503f8e8a88895b12bf810677406284142e6 arch/x86-64/boot
git rebase --continue
And then it just continued until all commits were rebased.
I have a very recent git, so maybe that's why it worked.
^ permalink raw reply
* [PATCH v2] Custom compression levels for objects and packs
From: Dana How @ 2007-05-08 22:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, danahow
Add config variables pack.compression and core.loosecompression .
Loose objects will be compressed using level
isset(core.loosecompression) ? core.loosecompression :
isset(core.compression) ? core.compression : Z_BEST_SPEED
and objects in packs will be compressed using level
isset(pack.compression) ? pack.compression :
isset(core.compression) ? core.compression : Z_DEFAULT_COMPRESSION
pack-objects also accepts --compression=N which
overrides the latter expression.
This applies on top of the git-repack --max-pack-size patchset.
Signed-off-by: Dana L. How <danahow@gmail.com>
---
builtin-pack-objects.c | 32 +++++++++++++++++++++++++++++++-
cache.h | 2 ++
config.c | 18 +++++++++++++++++-
environment.c | 4 +++-
4 files changed, 53 insertions(+), 3 deletions(-)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 8824793..e80a1d6 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -70,6 +70,8 @@ static uint32_t pack_size_limit;
static int pack_to_stdout;
static int num_preferred_base;
static struct progress progress_state;
+static int pack_compression_level = Z_DEFAULT_COMPRESSION;
+static int pack_compression_seen;
/*
* The object names in objects array are hashed with this hashtable,
@@ -444,6 +446,10 @@ static unsigned long write_object(struct sha1file *f,
* and we do not need to deltify it.
*/
+ /* differing core & pack compression when loose object -> must recompress */
+ if (!entry->in_pack && pack_compression_level != zlib_compression_level)
+ to_reuse = 0;
+ else
if (!entry->in_pack && !entry->delta) {
unsigned char *map;
unsigned long mapsize;
@@ -492,7 +498,7 @@ static unsigned long write_object(struct sha1file *f,
}
/* compress the data to store and put compressed length in datalen */
memset(&stream, 0, sizeof(stream));
- deflateInit(&stream, zlib_compression_level);
+ deflateInit(&stream, pack_compression_level);
maxsize = deflateBound(&stream, size);
out = xmalloc(maxsize);
/* Compress it */
@@ -1624,6 +1630,16 @@ static int git_pack_config(const char *k, const char *v)
window = git_config_int(k, v);
return 0;
}
+ if (!strcmp(k, "pack.compression")) {
+ int level = git_config_int(k, v);
+ if (level == -1)
+ level = Z_DEFAULT_COMPRESSION;
+ else if (level < 0 || level > Z_BEST_COMPRESSION)
+ die("bad pack compression level %d", level);
+ pack_compression_level = level;
+ pack_compression_seen = 1;
+ return 0;
+ }
return git_default_config(k, v);
}
@@ -1734,6 +1750,8 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
rp_ac = 2;
git_config(git_pack_config);
+ if (!pack_compression_seen && core_compression_seen)
+ pack_compression_level = core_compression_level;
progress = isatty(2);
for (i = 1; i < argc; i++) {
@@ -1761,6 +1779,18 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
usage(pack_usage);
continue;
}
+ if (!prefixcmp(arg, "--compression=")) {
+ char *end;
+ int level = strtoul(arg+14, &end, 0);
+ if (!arg[14] || *end)
+ usage(pack_usage);
+ if (level == -1)
+ level = Z_DEFAULT_COMPRESSION;
+ else if (level < 0 || level > Z_BEST_COMPRESSION)
+ die("bad pack compression level %d", level);
+ pack_compression_level = level;
+ continue;
+ }
if (!prefixcmp(arg, "--window=")) {
char *end;
window = strtoul(arg+9, &end, 0);
diff --git a/cache.h b/cache.h
index 8e76152..2b3f359 100644
--- a/cache.h
+++ b/cache.h
@@ -283,6 +283,8 @@ extern int warn_ambiguous_refs;
extern int shared_repository;
extern const char *apply_default_whitespace;
extern int zlib_compression_level;
+extern int core_compression_level;
+extern int core_compression_seen;
extern size_t packed_git_window_size;
extern size_t packed_git_limit;
extern size_t delta_base_cache_limit;
diff --git a/config.c b/config.c
index 70d1055..5627ed6 100644
--- a/config.c
+++ b/config.c
@@ -12,6 +12,8 @@
static FILE *config_file;
static const char *config_file_name;
static int config_linenr;
+static int zlib_compression_seen;
+
static int get_next_char(void)
{
int c;
@@ -304,13 +306,27 @@ int git_default_config(const char *var, const char *value)
return 0;
}
- if (!strcmp(var, "core.compression")) {
+ if (!strcmp(var, "core.loosecompression")) {
int level = git_config_int(var, value);
if (level == -1)
level = Z_DEFAULT_COMPRESSION;
else if (level < 0 || level > Z_BEST_COMPRESSION)
die("bad zlib compression level %d", level);
zlib_compression_level = level;
+ zlib_compression_seen = 1;
+ return 0;
+ }
+
+ if (!strcmp(var, "core.compression")) {
+ int level = git_config_int(var, value);
+ if (level == -1)
+ level = Z_DEFAULT_COMPRESSION;
+ else if (level < 0 || level > Z_BEST_COMPRESSION)
+ die("bad zlib compression level %d", level);
+ core_compression_level = level;
+ core_compression_seen = 1;
+ if (!zlib_compression_seen)
+ zlib_compression_level = level;
return 0;
}
diff --git a/environment.c b/environment.c
index 2231659..b7aeb1a 100644
--- a/environment.c
+++ b/environment.c
@@ -24,7 +24,9 @@ const char *git_commit_encoding;
const char *git_log_output_encoding;
int shared_repository = PERM_UMASK;
const char *apply_default_whitespace;
-int zlib_compression_level = Z_DEFAULT_COMPRESSION;
+int zlib_compression_level = Z_BEST_SPEED;
+int core_compression_level;
+int core_compression_seen;
size_t packed_git_window_size = DEFAULT_PACKED_GIT_WINDOW_SIZE;
size_t packed_git_limit = DEFAULT_PACKED_GIT_LIMIT;
size_t delta_base_cache_limit = 16 * 1024 * 1024;
--
1.5.2.rc0.787.g0014
^ permalink raw reply related
* Re: [PATCH] Add a birdview-on-the-source-code section to the user manual
From: Johannes Schindelin @ 2007-05-08 23:10 UTC (permalink / raw)
To: Karl Hasselström; +Cc: bfields, junio, git
In-Reply-To: <20070508213158.GB3969@diana.vm.bytemark.co.uk>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1510 bytes --]
Hi,
On Tue, 8 May 2007, Karl Hasselström wrote:
> On 2007-05-08 23:07:04 +0200, Johannes Schindelin wrote:
>
> > On Tue, 8 May 2007, Karl Hasselström wrote:
> >
> > > On 2007-05-08 17:10:47 +0200, Johannes Schindelin wrote:
> > >
> > > > + char *`, but is actually expected to be a pointer to `unsigned
> > > > + char[20]`. This variable will contain the big endian version of the
> > > > + 40-character hex string representation of the SHA-1.
> > >
> > > Either it should be "unsigned char[40]" (or possibly 41 with a
> > > terminating \0), or else you shouldn't be talking about
> > > hexadecimal since it's just a 20-byte big-endian unsigned integer.
> > > (A third possibility is that I'm totally confused.)
> >
> > It is 40 hex-character, but 20 _byte_. If you have any ideas how to
> > formulate that better than I did...
>
> I think this is less confusing:
>
> This variable will contain the 160-bit SHA-1.
>
> It avoids talking of hex, since it's not really stored in hex format
> any more than any other binary number with a number of bits divisible
> by four. And it avoids saying big-endian, which is not relevant anyway
> since we don't use hashes as integers.
Well, I do not buy into that. First, we _have_ to say that it is
big-endian. It was utterly confusing to _me_ that the hash was not little
endian, as I expected on an Intel processor.
And I'd rather mention the hex representation (what you see in git-log and
git-ls-tree). This helps debugging, believe me.
Ciao,
Dscho
^ permalink raw reply
* Re: git-clean fails to remove a file whose name contains \\, ", or \n, TAB, etc.
From: Jan Hudec @ 2007-05-08 23:11 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Jim Meyering, git
In-Reply-To: <86k5vj9gzu.fsf@blue.stonehenge.com>
[-- Attachment #1: Type: text/plain, Size: 1827 bytes --]
On Tue, May 08, 2007 at 13:51:01 -0700, Randal L. Schwartz wrote:
> >>>>> "Jim" == Jim Meyering <jim@meyering.net> writes:
>
> Jim> Not that it matters (or maybe this is a feature :-), because people
> Jim> who create such files in their working directory deserve what they
> Jim> get, Eh? :-)
>
> The problem is the newline in the string, since
>
> git-ls-files --others --directory $excl ${excl_info:+"$excl_info"} -- "$@" |
> while read -r file; do
>
> is using newline as a delimiter. Any file with a newline would mess this up.
>
> Not being a shell programming expert, is there a way we could use -z and xargs
> -0 here instead?
Unfortunately read does not have zero-delimited mode (at all). Unfortunately
the backquote expansion does not preserve whitespace correctly, so it's not
possible to use something like head.
Unfortunately there does not seem to be a way to feed newline to read
(without -r flag), because the rules say that '\<NL>' => '' and
'\<something>' => '<something>'.
Than I can't think of anything other than xargs -0. Unfortunately that is an
external command, which only handles simple commands. So the question becomes
how to give it a simple command. Well, there would be two ways:
- A simple command might be:
sh -c 'arbitrarily complex command' dummy arguments...
(the "dummy" will become $0),
so you can simply put the whole loop in single quotes, use for file; do
instead of while read -r file; do and be done.
- Reinvoke the program with special argument meaning it should run the inner
loop. Ie. add an option --inner-loop option, that would run the
inner loop and terminate and use xargs -0 "$0" --inner-loop
Both solutions require exporting all the necessary variables.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git-clean fails to remove a file whose name contains \\, ", or \n, TAB, etc.
From: Randal L. Schwartz @ 2007-05-08 23:18 UTC (permalink / raw)
To: Jan Hudec; +Cc: Jim Meyering, git
In-Reply-To: <20070508231115.GA14900@efreet.light.src>
>>>>> "Jan" == Jan Hudec <bulb@ucw.cz> writes:
Jan> Than I can't think of anything other than xargs -0.
git-ls-files -z .... |
perl -0lne '
$_ is each name here
'
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: [PATCH] Add a birdview-on-the-source-code section to the user manual
From: Karl Hasselström @ 2007-05-08 23:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: bfields, junio, git
In-Reply-To: <Pine.LNX.4.64.0705090105450.4167@racer.site>
On 2007-05-09 01:10:13 +0200, Johannes Schindelin wrote:
> On Tue, 8 May 2007, Karl Hasselström wrote:
>
> > I think this is less confusing:
> >
> > This variable will contain the 160-bit SHA-1.
> >
> > It avoids talking of hex, since it's not really stored in hex
> > format any more than any other binary number with a number of bits
> > divisible by four. And it avoids saying big-endian, which is not
> > relevant anyway since we don't use hashes as integers.
>
> Well, I do not buy into that. First, we _have_ to say that it is
> big-endian. It was utterly confusing to _me_ that the hash was not
> little endian, as I expected on an Intel processor.
If you think of it as a integer and not a byte array, then yes. But
fair enough, if it confused you, it'd probably confuse others as well.
> And I'd rather mention the hex representation (what you see in
> git-log and git-ls-tree). This helps debugging, believe me.
But that byte array doesn't store the hex representation!
There is a trivial transformation that will convert a 20-byte integer
to a 40-character hex string representation of that integer: translate
each nibble to one hex digit. But the code snippet you gave uses the
former representation, and that's the point I thought you were trying
to make in the first place.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: git-clean fails to remove a file whose name contains \\, ", or \n, TAB, etc.
From: Karl Hasselström @ 2007-05-08 23:27 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Jan Hudec, Jim Meyering, git
In-Reply-To: <86wszi9a5r.fsf@blue.stonehenge.com>
On 2007-05-08 16:18:40 -0700, Randal L. Schwartz wrote:
> >>>>> "Jan" == Jan Hudec <bulb@ucw.cz> writes:
>
> Jan> Than I can't think of anything other than xargs -0.
>
> git-ls-files -z .... |
> perl -0lne '
> $_ is each name here
> '
Have you seen this?
http://xkcd.com/c224.html
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: git-clean fails to remove a file whose name contains \\, ", or \n, TAB, etc.
From: Randal L. Schwartz @ 2007-05-08 23:29 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Jan Hudec, Jim Meyering, git
In-Reply-To: <20070508232702.GB5866@diana.vm.bytemark.co.uk>
>>>>> "Karl" == Karl Hasselström <kha@treskal.com> writes:
Karl> Have you seen this?
Karl> http://xkcd.com/c224.html
Yes. You would be, oh, the 92nd person to point that out to me. :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* [StGIT PATCH] Fix popping on non-active branches
From: Karl Hasselström @ 2007-05-08 23:32 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
Resetting HEAD on the current branch when popping a patch on another
branch isn't a great idea.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
stgit/git.py | 8 ++++++--
stgit/stack.py | 13 +++++++------
2 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/stgit/git.py b/stgit/git.py
index d7eb48e..837f927 100644
--- a/stgit/git.py
+++ b/stgit/git.py
@@ -298,14 +298,18 @@ def set_head_file(ref):
[os.path.join('refs', 'heads', ref)]) != 0:
raise GitException, 'Could not set head to "%s"' % ref
+def set_branch(branch, val):
+ """Point branch at a new commit object."""
+ if __run('git-update-ref', [branch, val]) != 0:
+ raise GitException, 'Could not update %s to "%s".' % (branch, val)
+
def __set_head(val):
"""Sets the HEAD value
"""
global __head
if not __head or __head != val:
- if __run('git-update-ref HEAD', [val]) != 0:
- raise GitException, 'Could not update HEAD to "%s".' % val
+ set_branch('HEAD', val)
__head = val
# only allow SHA1 hashes
diff --git a/stgit/stack.py b/stgit/stack.py
index 3e9fc4f..76704e8 100644
--- a/stgit/stack.py
+++ b/stgit/stack.py
@@ -1063,12 +1063,13 @@ class Series(StgitObject):
patch = Patch(name, self.__patch_dir, self.__refs_dir)
- # only keep the local changes
- if keep and not git.apply_diff(git.get_head(), patch.get_bottom()):
- raise StackException, \
- 'Failed to pop patches while preserving the local changes'
-
- git.switch(patch.get_bottom(), keep)
+ if git.get_head_file() == self.get_branch():
+ if keep and not git.apply_diff(git.get_head(), patch.get_bottom()):
+ raise StackException(
+ 'Failed to pop patches while preserving the local changes')
+ git.switch(patch.get_bottom(), keep)
+ else:
+ git.set_branch(self.get_branch(), patch.get_bottom())
# save the new applied list
idx = applied.index(name) + 1
^ permalink raw reply related
* Re: git-clean fails to remove a file whose name contains \\, ", or \n, TAB, etc.
From: Karl Hasselström @ 2007-05-08 23:38 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Jan Hudec, Jim Meyering, git
In-Reply-To: <86sla699oc.fsf@blue.stonehenge.com>
On 2007-05-08 16:29:07 -0700, Randal L. Schwartz wrote:
> >>>>> "Karl" == Karl Hasselström <kha@treskal.com> writes:
>
> Karl> Have you seen this?
> Karl> http://xkcd.com/c224.html
>
> Yes. You would be, oh, the 92nd person to point that out to me. :)
Ah well. At least I sent it to the list too, so everyone can have
their choice of snickering at the comic, or me, whichever seems
silliest. :-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Perl code for git-clean
From: Randal L. Schwartz @ 2007-05-08 23:51 UTC (permalink / raw)
To: git
OK, this is untested, but I usually get this stuff right
by eyeballing it. :)
export cleandir;
git-ls-files -z --others --directory $excl ${excl_info:+"$excl_info"} -- "$@" |
perl -ln0e '
use File::Path qw(rmtree);
if (-d and not -L) {
if (not $ENV{cleandir}) {
print "Not removing $_";
next;
}
print "Removing $_";
rmtree($_);
} else {
print "Removing $_";
unlink($_);
}
'
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: [PATCH v2] Custom compression levels for objects and packs
From: Junio C Hamano @ 2007-05-08 23:56 UTC (permalink / raw)
To: Dana How; +Cc: Git Mailing List
In-Reply-To: <4640FBDE.1000609@gmail.com>
Dana How <danahow@gmail.com> writes:
> Add config variables pack.compression and core.loosecompression .
> Loose objects will be compressed using level
> isset(core.loosecompression) ? core.loosecompression :
> isset(core.compression) ? core.compression : Z_BEST_SPEED
> and objects in packs will be compressed using level
> isset(pack.compression) ? pack.compression :
> isset(core.compression) ? core.compression : Z_DEFAULT_COMPRESSION
> pack-objects also accepts --compression=N which
> overrides the latter expression.
Do you think the above is readable?
Compression level for loose objects is controlled by variable
core.loosecompression (or core.compression, if the former is
missing), and defaults to best-speed.
or something like that?
> This applies on top of the git-repack --max-pack-size patchset.
Hmph, that makes the --max-pack-size patchset take this more
trivial and straightforward improvements hostage. In general,
I'd prefer more elaborate ones based on less questionable
series.
> @@ -444,6 +446,10 @@ static unsigned long write_object(struct sha1file *f,
> * and we do not need to deltify it.
> */
>
> + /* differing core & pack compression when loose object -> must recompress */
> + if (!entry->in_pack && pack_compression_level != zlib_compression_level)
> + to_reuse = 0;
> + else
I am not sure if that is worth it, as you do not know if the
loose object you are looking at were compressed with the current
settings.
> diff --git a/cache.h b/cache.h
> index 8e76152..2b3f359 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -283,6 +283,8 @@ extern int warn_ambiguous_refs;
> extern int shared_repository;
> extern const char *apply_default_whitespace;
> extern int zlib_compression_level;
> +extern int core_compression_level;
> +extern int core_compression_seen;
Could we somehow remove _seen? Perhaps by initializing the
_level to -1?
> +int core_compression_level;
> +int core_compression_seen;
Same here.
^ permalink raw reply
* Re: [PATCH] Add --no-reuse-delta, --window, and --depth options to
From: Nicolas Pitre @ 2007-05-08 23:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Theodore Ts'o, Git Mailing List
In-Reply-To: <7vwszj10kn.fsf@assigned-by-dhcp.cox.net>
On Tue, 8 May 2007, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > @@ -65,7 +65,20 @@ int cmd_gc(int argc, const char **argv, const char *prefix)
> > if (run_command_v_opt(argv_reflog, RUN_GIT_CMD))
> > return error(FAILED_RUN, argv_reflog[0]);
> >
> > - if (run_command_v_opt(argv_repack, RUN_GIT_CMD))
> > + if (num_loose_objects() > 0) {
> > + do_repack = 1;
> > + } else {
> > + struct packed_git *p;
> > + unsigned long num_pack = 0;
> > + if (!packed_git)
> > + prepare_packed_git();
> > + for (p = packed_git; p; p = p->next)
> > + if (p->pack_local)
> > + num_pack++;
> > + if (num_pack > 1)
> > + do_repack = 1;
> > + }
> > + if (do_repack && run_command_v_opt(argv_repack, RUN_GIT_CMD))
> > return error(FAILED_RUN, argv_repack[0]);
> >
> > if (prune && run_command_v_opt(argv_prune, RUN_GIT_CMD))
>
> Is this even correct?
>
> When your repository is fully packed, if you decided to discard
> one of your topic branches with "git branch -D", what does this
> code do? We see no loose objects, we see only one pack, so the
> unreachable objects are left in the pack?
Right. OK, scrap that.
Nicolas
^ permalink raw reply
* Re: [PATCH v2] Custom compression levels for objects and packs
From: Nicolas Pitre @ 2007-05-09 0:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Dana How, Git Mailing List
In-Reply-To: <7vk5vi27ko.fsf@assigned-by-dhcp.cox.net>
On Tue, 8 May 2007, Junio C Hamano wrote:
> Dana How <danahow@gmail.com> writes:
>
> > @@ -444,6 +446,10 @@ static unsigned long write_object(struct sha1file *f,
> > * and we do not need to deltify it.
> > */
> >
> > + /* differing core & pack compression when loose object -> must recompress */
> > + if (!entry->in_pack && pack_compression_level != zlib_compression_level)
> > + to_reuse = 0;
> > + else
>
> I am not sure if that is worth it, as you do not know if the
> loose object you are looking at were compressed with the current
> settings.
I was about to make the same comment.
> > diff --git a/cache.h b/cache.h
> > index 8e76152..2b3f359 100644
> > --- a/cache.h
> > +++ b/cache.h
> > @@ -283,6 +283,8 @@ extern int warn_ambiguous_refs;
> > extern int shared_repository;
> > extern const char *apply_default_whitespace;
> > extern int zlib_compression_level;
> > +extern int core_compression_level;
> > +extern int core_compression_seen;
>
> Could we somehow remove _seen? Perhaps by initializing the
> _level to -1?
-1 is a valid value for compression. Actually it is equivalent to
Z_DEFAULT_COMPRESSION.
If we want the fallback logic to work, at some point we must remember if
the current value is the default or if it is the result of an explicit
config option.
Nicolas
^ permalink raw reply
* Re: [PATCH v2] Custom compression levels for objects and packs
From: Dana How @ 2007-05-09 0:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, danahow
In-Reply-To: <7vk5vi27ko.fsf@assigned-by-dhcp.cox.net>
On 5/8/07, Junio C Hamano <junkio@cox.net> wrote:
> Dana How <danahow@gmail.com> writes:
> > Add config variables pack.compression and core.loosecompression .
> > Loose objects will be compressed using level
> > isset(core.loosecompression) ? core.loosecompression :
> > isset(core.compression) ? core.compression : Z_BEST_SPEED
> > and objects in packs will be compressed using level
> > isset(pack.compression) ? pack.compression :
> > isset(core.compression) ? core.compression : Z_DEFAULT_COMPRESSION
> > pack-objects also accepts --compression=N which
> > overrides the latter expression.
>
> Do you think the above is readable?
> Compression level for loose objects is controlled by variable
> core.loosecompression (or core.compression, if the former is
> missing), and defaults to best-speed.
> or something like that?
Your phrasing is much better.
> > This applies on top of the git-repack --max-pack-size patchset.
> Hmph, that makes the --max-pack-size patchset take this more
> trivial and straightforward improvements hostage. In general,
> I'd prefer more elaborate ones based on less questionable
> series.
The max-pack-size and pack.compression patches touch the same lines.
I thought my options were:
* Submit independently and make you merge; or
* Make one precede the other.
Since max-pack-size has been out there since April 4 and
the first acceptable version was May 1 (suggested by 0 comments),
I didn't realize it was a "questionable series".
I think it should be straightforward for me to re-submit this
based on current master.
> > + /* differing core & pack compression when loose object -> must recompress */
> > + if (!entry->in_pack && pack_compression_level != zlib_compression_level)
> > + to_reuse = 0;
> > + else
> I am not sure if that is worth it, as you do not know if the
> loose object you are looking at were compressed with the current
> settings.
You do not know for certain, that is correct. However, config
settings setting unequal compression levels signal that you
care differently about the two cases. (For me, I want the
compression investment to correspond to the expected lifetime of the file.)
Also, *if* we have the knobs we want in the config file,
I don't think we're going to be changing these settings all that often.
If I didn't have this check forcing recompression in the pack,
then in the absence of deltification each object would enter the pack
by being copied (in the preceding code block) and pack.compression
would have little effect. I actually experienced this the very first
time I imported a large dataset into git (I was trying to achieve the
effect of this patch by changing core.compression dynamically, and
was a bit mystified for a while by the result).
Thus, if core.loosecompression is set to speed up git-add, I should
take the time to recompress the object when packing if pack.compression
is different (of course the hit of not doing so will be lessened by
deltification
which forces a new compression).
> > diff --git a/cache.h b/cache.h
> > index 8e76152..2b3f359 100644
> > --- a/cache.h
> > +++ b/cache.h
> > @@ -283,6 +283,8 @@ extern int warn_ambiguous_refs;
> > extern int shared_repository;
> > extern const char *apply_default_whitespace;
> > extern int zlib_compression_level;
> > +extern int core_compression_level;
> > +extern int core_compression_seen;
>
> Could we somehow remove _seen? Perhaps by initializing the
> _level to -1?
>
> > +int core_compression_level;
> > +int core_compression_seen;
>
> Same here.
I agree completely. But, what magic value should I use
to initialize the _level variables so I know they are not set?
All valid settings come from zlib.h through #define's but
there is no "invalid" defined. Maybe I'll use -99.
Thanks,
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* Re: [PATCH v2] Custom compression levels for objects and packs
From: Dana How @ 2007-05-09 0:29 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, Git Mailing List, danahow
In-Reply-To: <alpine.LFD.0.99.0705082010230.24220@xanadu.home>
On 5/8/07, Nicolas Pitre <nico@cam.org> wrote:
> On Tue, 8 May 2007, Junio C Hamano wrote:
> > Dana How <danahow@gmail.com> writes:
> > > + /* differing core & pack compression when loose object -> must recompress */
> > > + if (!entry->in_pack && pack_compression_level != zlib_compression_level)
> > > + to_reuse = 0;
> > > + else
> > I am not sure if that is worth it, as you do not know if the
> > loose object you are looking at were compressed with the current
> > settings.
> I was about to make the same comment.
I was bitten by *not* doing this. Please see the more verbose
reply to Junio's comment.
> > Could we somehow remove _seen? Perhaps by initializing the
> > _level to -1?
>
> -1 is a valid value for compression. Actually it is equivalent to
> Z_DEFAULT_COMPRESSION.
>
> If we want the fallback logic to work, at some point we must remember if
> the current value is the default or if it is the result of an explicit
> config option.
I can leave as-is, or use a magic value like -99 and
depend on it not colliding with values in zlib.h.
Thanks,
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* Re: [PATCH v2] Custom compression levels for objects and packs
From: Petr Baudis @ 2007-05-09 0:30 UTC (permalink / raw)
To: Dana How; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <4640FBDE.1000609@gmail.com>
On Wed, May 09, 2007 at 12:38:22AM CEST, Dana How wrote:
> diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
> index 8824793..e80a1d6 100644
> --- a/builtin-pack-objects.c
> +++ b/builtin-pack-objects.c
> @@ -444,6 +446,10 @@ static unsigned long write_object(struct sha1file *f,
> * and we do not need to deltify it.
> */
>
> + /* differing core & pack compression when loose object -> must recompress */
> + if (!entry->in_pack && pack_compression_level != zlib_compression_level)
> + to_reuse = 0;
> + else
> if (!entry->in_pack && !entry->delta) {
Style: the else and if should be probably on the same line.
> unsigned char *map;
> unsigned long mapsize;
> @@ -1624,6 +1630,16 @@ static int git_pack_config(const char *k, const char *v)
> window = git_config_int(k, v);
> return 0;
> }
> + if (!strcmp(k, "pack.compression")) {
> + int level = git_config_int(k, v);
> + if (level == -1)
> + level = Z_DEFAULT_COMPRESSION;
> + else if (level < 0 || level > Z_BEST_COMPRESSION)
> + die("bad pack compression level %d", level);
> + pack_compression_level = level;
> + pack_compression_seen = 1;
> + return 0;
> + }
> return git_default_config(k, v);
> }
>
Where is this documented?
> @@ -1761,6 +1779,18 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
> usage(pack_usage);
> continue;
> }
> + if (!prefixcmp(arg, "--compression=")) {
> + char *end;
> + int level = strtoul(arg+14, &end, 0);
> + if (!arg[14] || *end)
> + usage(pack_usage);
> + if (level == -1)
> + level = Z_DEFAULT_COMPRESSION;
> + else if (level < 0 || level > Z_BEST_COMPRESSION)
> + die("bad pack compression level %d", level);
> + pack_compression_level = level;
> + continue;
> + }
> if (!prefixcmp(arg, "--window=")) {
> char *end;
> window = strtoul(arg+9, &end, 0);
Where is this documented?
> diff --git a/config.c b/config.c
> index 70d1055..5627ed6 100644
> --- a/config.c
> +++ b/config.c
> @@ -304,13 +306,27 @@ int git_default_config(const char *var, const char *value)
> return 0;
> }
>
> - if (!strcmp(var, "core.compression")) {
> + if (!strcmp(var, "core.loosecompression")) {
Is this config variable documented?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
-- Samuel Beckett
^ permalink raw reply
* Re: [PATCH v2] Custom compression levels for objects and packs
From: Nicolas Pitre @ 2007-05-09 1:03 UTC (permalink / raw)
To: Dana How; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <56b7f5510705081729t34a585c6y9ca9e2f9963d24a2@mail.gmail.com>
On Tue, 8 May 2007, Dana How wrote:
> On 5/8/07, Nicolas Pitre <nico@cam.org> wrote:
> > On Tue, 8 May 2007, Junio C Hamano wrote:
> > If we want the fallback logic to work, at some point we must remember if
> > the current value is the default or if it is the result of an explicit
> > config option.
> I can leave as-is, or use a magic value like -99 and
> depend on it not colliding with values in zlib.h.
And where would you set those variables to a sensible default in the
absence of any config option?
Nicolas
^ permalink raw reply
* [PATCH] Optimized cvsexportcommit: calling 'cvs status' only once instead of once per changed file.
From: Steffen Prohaska @ 2007-05-08 23:59 UTC (permalink / raw)
To: git
The old implementation executed 'cvs status' for each file touched by
the patch
to be applied. The new code calls 'cvs status' only once and parses
cvs's
output to collect status information of all files contained in the
cvs working
copy.
Runtime is now independent of the number of modified files. A
drawback is that
the new code retrieves status information for all files even if only
a few are
touched. The old implementation may be noticeably faster for small
patches to
large workingcopies. However, the old implementation doesn't scale if
more
files are touched, especially in remotely located cvs repositories.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
git-cvsexportcommit.perl | 45 ++++++++++++++++++++++++++++++++++
+----------
1 files changed, 35 insertions(+), 10 deletions(-)
diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
index 6ed4719..f2c4bc4 100755
--- a/git-cvsexportcommit.perl
+++ b/git-cvsexportcommit.perl
@@ -160,36 +160,61 @@ foreach my $p (@afiles) {
}
}
+# ... check dirs,
foreach my $d (@dirs) {
if (-e $d) {
$dirty = 1;
warn "$d exists and is not a directory!\n";
}
}
+# ... query and store status of files by parsing output of 'cvs
status',
+my @cvsoutput;
+my %cvsstat;
+open CVSSTAT, "cvs status 2>&1 |" || die "failed to query cvs status";
+@cvsoutput=<CVSSTAT>;
+close CVSSTAT || die "failed to query cvs status";
+my ( $dir, $status, $file );
+foreach my $f (@cvsoutput) {
+# cvs reports directories on stderr before reporting file status on
stdout
+# using basename of 'Repository revision:' should be a safe way to
deal with whitespace in filenames.
+ chomp $f;
+ if ( $f =~ /^cvs status: Examining (.*)$/ ) {
+ $dir = $1;
+ if ( $dir ne "." ) {
+ $dir .= "/";
+ } else {
+ $dir = "";
+ }
+ } elsif ( $f =~ /Status: (.*)$/ ) {
+ $status = $1;
+ } elsif ( $f =~ /^ Repository revision:/ ) {
+ $f =~ s/,v$//;
+ $f =~ /([^\/]*)$/;
+ $file = $1;
+ $cvsstat{"$dir$file"} = $status;
+ }
+}
+
+# ... validate new files,
foreach my $f (@afiles) {
# This should return only one value
if ($f =~ m,(.*)/[^/]*$,) {
my $p = $1;
next if (grep { $_ eq $p } @dirs);
}
- my @status = grep(m/^File/, safe_pipe_capture(@cvs, '-q',
'status' ,$f));
- if (@status > 1) { warn 'Strange! cvs status returned more than
one line?'};
- if (-d dirname $f and $status[0] !~ m/Status: Unknown$/
- and $status[0] !~ m/^File: no file /) {
+ if (defined ($cvsstat{$f})) {
$dirty = 1;
warn "File $f is already known in your CVS checkout -- perhaps it
has been added by another user. Or this may indicate that it exists
on a different branch. If this is the case, use -f to force the merge.
\n";
- warn "Status was: $status[0]\n";
+ warn "Status was: $cvsstat{$f}\n";
}
}
-
+# ... validate known files.
foreach my $f (@files) {
next if grep { $_ eq $f } @afiles;
# TODO:we need to handle removed in cvs
- my @status = grep(m/^File/, safe_pipe_capture(@cvs, '-q',
'status' ,$f));
- if (@status > 1) { warn 'Strange! cvs status returned more than
one line?'};
- unless ($status[0] =~ m/Status: Up-to-date$/) {
+ unless (defined ($cvsstat{$f}) and $cvsstat{$f} eq "Up-to-date") {
$dirty = 1;
- warn "File $f not up to date in your CVS checkout!\n";
+ warn "File $f not up to date but has status '$cvsstat{$f}' in your
CVS checkout!\n";
}
}
if ($dirty) {
--
1.5.1.2
^ 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