* Re: large(25G) repository in git
From: Sam Hocevar @ 2009-03-24 21:04 UTC (permalink / raw)
To: Adam Heath; +Cc: git
In-Reply-To: <49C7FAB3.7080301@brainfood.com>
On Mon, Mar 23, 2009, 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.
>
> [...]
>
> Last friday, I was doing a checkin on the production server, and found
> 1.6G of new files. git was quite able at committing that. However,
> pushing was problematic. I was pushing over ssh; so, a new ssh
> connection was open to the preview server. After doing so, git tried
> to create a new pack file. This took *ages*, and the ssh connection
> died. So did git, when it finally got done with the new pack, and
> discovered the ssh connection was gone.
As stated several times by Linus and others, Git was not designed
to handle large files. My stance on the issue is that before trying
to optimise operations so that they perform well on large files, too,
Git should usually avoid such operations, especially deltification.
One notable exception would be someone storing their mailbox in Git,
where deltification is a major space saver. But usually, these large
files are binary blobs that do not benefit from delta search (or even
compression).
Since I also need to handle large files (80 GiB repository), I am
cleaning up some fixes I did, which can be seen in the git-bigfiles
project (http://caca.zoy.org/wiki/git-bigfiles). I have not yet tried
to change git-push (because I submit through git-p4), but I hope to
address it, too. As time goes I believe some of them could make it into
mainstream Git.
In your particular case, I would suggest setting pack.packSizeLimit
to something lower. This would reduce the time spent generating a new
pack file if the problem were to happen again.
Regards,
--
Sam.
^ permalink raw reply
* Re: [PATCH v3 1/2] git-gui: various French translation fixes
From: Christian Couder @ 2009-03-24 21:00 UTC (permalink / raw)
To: Sam Hocevar, Shawn O. Pierce; +Cc: git, Christian Couder, Nicolas Sebrecht
In-Reply-To: <20090323233924.GA29922@zoy.org>
Hi Sam,
2009/3/24 Sam Hocevar <sam@zoy.org>:
> Mostly grammar, spelling and typography fixes, but also a few wording
> enhancements here and there.
> ---
> This patch includes everything acked by Christian and Nicolas, without
> the part that tried to find a better translation for "revert". These will
> need to be discussed later.
Thank you for this newer version. It's all good. Shawn please apply.
Acked-by: Christian Couder <chriscool@tuxfamily.org>
Best regards,
Christian.
^ permalink raw reply
* Re: large(25G) repository in git
From: Adam Heath @ 2009-03-24 20:55 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <alpine.LFD.2.00.0903241404080.26337@xanadu.home>
Nicolas Pitre wrote:
> Because it is way more complex for git to do that than for ssh to keep
> the connection alive. And normally there is no need as git is supposed
> to be faster than that.
Sure, I'll buy that.
>>>> So, to work around that, I ran git gc. When done, I discovered that
>>>> git repacked the *entire* repository. While not something I care for,
>>>> I can understand that, and live with it. It just took *hours* to do so.
>>>>
>>>> Then, what really annoys me, is that when I finally did the push, it
>>>> tried sending the single 27G pack file, when the remote already had
>>>> 25G of the repository in several different packs(the site was an
>>>> hg->git conversion). This part is just unacceptable.
>>> This shouldn't happen either. When pushing, git reconstruct a pack with
>>> only the necessary objects to transmit. Are you sure it was really
>>> trying to send a 27G pack?
>> Of course I'm sure. I wouldn't have sent the email if it didn't
>> happen. And, I have the bandwidthd graph and lost time to prove it.
>
> As much as I would like to believe you, this doesn't help fixing the
> problem if you don't provide more information about this. For example,
> the output from git during the whole operation might give us the
> beginning of a clue. Otherwise, all I can tell you is that such thing
> is not supposed to happen.
First off, you've put a bad tone on this. It appears that you are
saying I'm mistaken, and it didn't send all that data. "It can't
happen, so it didn't happen." Believe me, if it hadn't resent all
this data, I wouldn't have even sent the email.
In any event, we got lucky. I *do* have a log of the push side of
this problem. I doubt it's enough to figure out the actual cause tho.
==
ofbiz@lnxwww10:/job/@anon-site@> git push bf-yum
Counting objects: 96637, done.
Compressing objects: 6% (2413/34478) 478)
Read from remote host @anon-site-dev@.brainfood.com: Connection reset
by peer
Compressing objects: 27% (9458/34478)
Compressing objects: 100% (34478/34478), done.
error: pack-objects died with strange error
error: failed to push some refs to 'ssh://bf-yum/@anon-site@'
ofbiz@lnxwww10:/job/@anon-site@>
ofbiz@lnxwww10:/job/@anon-site@>
ofbiz@lnxwww10:/job/@anon-site@>
ofbiz@lnxwww10:/job/@anon-site@> git push bf-yum
Counting objects: 96637, done.
Killed by signal 2.: 5% (1866/34478)
ofbiz@lnxwww10:/job/@anon-site@> git gc
Counting objects: 96637, done.
Compressing objects: 27% (9453/34478)
Compressing objects: 100% (34478/34478), done.
Writing objects: 100% (96637/96637), done.
Total 96637 (delta 48713), reused 88929 (delta 43905)
Removing duplicate objects: 100% (256/256), done.
ofbiz@lnxwww10:/job/@anon-site@>
ofbiz@lnxwww10:/job/@anon-site@>
ofbiz@lnxwww10:/job/@anon-site@> du .git -sc
26797788 .git
26797788 total
ofbiz@lnxwww10:/job/@anon-site@> git push bf-yum
Counting objects: 96637, done.
Compressing objects: 100% (29670/29670), done.
Writing objects: 100% (96637/96637), 25.49 GiB | 226 KiB/s, done.
Total 96637 (delta 48713), reused 96637 (delta 48713)
To ssh://bf-yum/@anon-site@
* [new branch] master -> lnxwww10
==
ofbiz@lnxwww10:/job/@anon-site@> ls .git/objects/pack/ -l
total 26762436
-r--r--r-- 1 ofbiz users 3452052 2009-03-21 23:11
pack-0d7b399006ae0a57ff3df07fdcaedbaeb7e63d0a.idx
-r--r--r-- 1 ofbiz users 27374508409 2009-03-21 23:11
pack-0d7b399006ae0a57ff3df07fdcaedbaeb7e63d0a.pack
==
I have a bf-yum remote defined, that pushes to the remote branch; once
it gets there, I then do a merge on the target machine.
The 'killed by signal 2' is when I ctrl-c.
The second group was done from another window. There's only a single
pack file now.
The @anon-site@ stuff is me removing client identifiers. It's the
only editting I did to the screen log.
>
>> After I ran git push, ssh timed out, the temp pack that was created
>> was then removed, as git complained about the connection being gone.
>
> On a push, there is no creation of a temp pack. It is always produced
> on the fly and pushed straight via the ssh connection.
No. I saw a temp file in strace. It *was* created on the local disk,
and *not* sent on the fly.
>> I then decided to do a 'git gc', which collapsed all the separate
>> packs into one. This allowed git push to proceed quickly, but at that
>> point, it started sending the entire pack.
>
> If this was really the case, then this is definitely a bug. Please take
> a snapshot of your screen with git messages if this ever happens again.
See above.
>
>> It's entirely possible that the temp pack created by git push was
>> incremental; it just took too long to create it, so it got aborted.
>
> The push operation has multiple phases. You should see "counting
> objects", "compressing objects" and "writing objects". Could you give
> us an approximation of how long each of those phases took?
Well, counting was quick enough. compression took at *least* 2 hours,
might have been 4 or more. This all started friday evening. I was
watching it a bit at the beginning, but then went out, and it died
after I got back to it.
>> I forgot to mention previously, that the source machine was running
>> git 1.5.6.5, and was pushing to 1.5.6.3.
>>
>> I've tried duplicating this problem on a machine with 1.6.1.3, but
>> either I don't fully understand the issue enough to replicate it, or
>> the newer git doesn't have the problem.
>
> That's possible. Maybe others on the list might recall possible issues
> related to this that might have been fixed during that time.
Well, I looked at the release notes between all these versions.
Nothing stands out, but I'm aware that the changelog/release note
entry for some change doesn't always describe the actual bug that
caused the change to occur.
>> Um, if it's missing documentation, then how am I supposed to know
>> about it?
>
> Asking on the list, like you did. However this attribute should be
> documented as well of course. I even think that someone posted a patch
> for it a while ago which might have been dropped.
What I'd like, is a way to say a certain pattern of files should only
be deduped, and not deltafied. This would handle the case of exact
copies, or renames, which would still be a win for us, but generally
when a new video(or doc or pdf) is uploaded, it's alot of work to try
and deltafy, for very little benefit.
^ permalink raw reply
* Re: [PATCH] avoid possible overflow in delta size filtering computation
From: Nicolas Pitre @ 2009-03-24 20:52 UTC (permalink / raw)
To: Brandon Casey; +Cc: Junio C Hamano, Kjetil Barvik, git
In-Reply-To: <IJd5MMCs9G_oJF_jS9hZAHkoKM0IvDNHuvHhhQ3MnKbPbSQlMYjOAg@cipher.nrlssc.navy.mil>
On Tue, 24 Mar 2009, Brandon Casey wrote:
> Nicolas Pitre wrote:
> > On a 32-bit system, the maximum possible size for an object is less than
> > 4GB, while 64-bit systems may cope with larger objects. Due to this
> > limitation, variables holding object sizes are using an unsigned long
> > type (32 bits on 32-bit systems, or 64 bits on 64-bit systems).
>
> FYI: except on windows 64-bit where long is still 32 bits AFAIK
Whatever. Same issue.
Nicolas
^ permalink raw reply
* [PATCH] MinGW: Quote arguments for subprocesses that contain a single-quote
From: Johannes Sixt @ 2009-03-24 20:43 UTC (permalink / raw)
To: msysgit; +Cc: git
Before a process can be spawned by mingw_spawnve, arguments must be
surrounded by double-quotes if special characters are present. This is
necessary because the startup code of the spawned process will expand
arguments that look like glob patterns. "Normal" Windows command line
utilities expand only * and ?, but MSYS programs, including bash, are
different: They also expand braces, and this has already been taken care
of by compat/mingw.c:quote_arg().
But MSYS programs also treat single-quotes in a special way: Arguments
between single-quotes are spliced together (with spaces) into a word.
With this patch this treatment is avoided by quoting arguments that contain
single-quotes.
This lets t4252 pass on Windows.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
t4252 passes a --directory argument with a single-quote to git-am. As a
consequence, this argument was spliced into a single word with the
remaining arguments, including the mbox file name. Following that,
git-mailsplit was called without a mailbox, upon which it waited for input
on stdin.
-- Hannes
compat/mingw.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index 171fa85..2839d9d 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -457,7 +457,7 @@ static const char *quote_arg(const char *arg)
const char *p = arg;
if (!*p) force_quotes = 1;
while (*p) {
- if (isspace(*p) || *p == '*' || *p == '?' || *p == '{')
+ if (isspace(*p) || *p == '*' || *p == '?' || *p == '{' || *p == '\'')
force_quotes = 1;
else if (*p == '"')
n++;
--
1.6.2.1.224.g2225f
^ permalink raw reply related
* Re: [PATCH] avoid possible overflow in delta size filtering computation
From: Brandon Casey @ 2009-03-24 20:20 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, Kjetil Barvik, git
In-Reply-To: <alpine.LFD.2.00.0903241535010.26337@xanadu.home>
Nicolas Pitre wrote:
> On a 32-bit system, the maximum possible size for an object is less than
> 4GB, while 64-bit systems may cope with larger objects. Due to this
> limitation, variables holding object sizes are using an unsigned long
> type (32 bits on 32-bit systems, or 64 bits on 64-bit systems).
FYI: except on windows 64-bit where long is still 32 bits AFAIK
-brandon
^ permalink raw reply
* [PATCH] avoid possible overflow in delta size filtering computation
From: Nicolas Pitre @ 2009-03-24 19:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Kjetil Barvik, git
On a 32-bit system, the maximum possible size for an object is less than
4GB, while 64-bit systems may cope with larger objects. Due to this
limitation, variables holding object sizes are using an unsigned long
type (32 bits on 32-bit systems, or 64 bits on 64-bit systems).
When large objects are encountered, and/or people play with large delta
depth values, it is possible for the maximum allowed delta size
computation to overflow, especially on a 32-bit system. When this
occurs, surviving result bits may represent a value much smaller than
what it is supposed to be, or even zero. This prevents some objects
from being deltified although they do get deltified when a smaller depth
limit is used. Fix this by always performing a 64-bit multiplication.
Signed-off-by: Nicolas Pitre <nico@cam.org>
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 3a4bdbb..9fc3b35 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -1293,7 +1293,7 @@ static int try_delta(struct unpacked *trg, struct unpacked *src,
max_size = trg_entry->delta_size;
ref_depth = trg->depth;
}
- max_size = max_size * (max_depth - src->depth) /
+ max_size = (uint64_t)max_size * (max_depth - src->depth) /
(max_depth - ref_depth + 1);
if (max_size == 0)
return 0;
^ permalink raw reply related
* [PATCH] builtin-tag.c: remove global variable to use the callback data of git-config.
From: Carlos Rica @ 2009-03-24 19:54 UTC (permalink / raw)
To: git, johannes.schindelin, gitster
By using strbuf to save the signing-key id, now there's no limit
to the length of the string obtained from the config or command-line.
This string is then passed to gpg to sign the tag, when appropriate.
Signed-off-by: Carlos Rica <jasampler@gmail.com>
---
NOTES: As Johannes Schindelin suggested, now strbuf is correctly used,
using setlen() for chopping the end data of the committer info,
instead of just setting '\0' and forgetting the len field.
Although git_committer_info() seems to return always the email
field between <angle brackets>, I left unchanged the "if (bracket)"
condition (as in builtin-log.c) to prevent errors or future changes.
Trying to test it, I found that gpg accepts any non-empty substring
of the name or email to identify the signing key ID, just as it is
stated in its manpage at end of section HOW TO SPECIFY A USER ID.
builtin-tag.c | 41 +++++++++++++++++------------------------
1 files changed, 17 insertions(+), 24 deletions(-)
diff --git a/builtin-tag.c b/builtin-tag.c
index 01e7374..ad54e4a 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -21,8 +21,6 @@ static const char * const git_tag_usage[] = {
NULL
};
-static char signingkey[1000];
-
struct tag_filter {
const char *pattern;
int lines;
@@ -156,7 +154,7 @@ static int verify_tag(const char *name, const char *ref,
return 0;
}
-static int do_sign(struct strbuf *buffer)
+static int do_sign(struct strbuf *signingkey, struct strbuf *buffer)
{
struct child_process gpg;
const char *args[4];
@@ -164,13 +162,12 @@ static int do_sign(struct strbuf *buffer)
int len;
int i, j;
- if (!*signingkey) {
- if (strlcpy(signingkey, git_committer_info(IDENT_ERROR_ON_NO_NAME),
- sizeof(signingkey)) > sizeof(signingkey) - 1)
- return error("committer info too long.");
- bracket = strchr(signingkey, '>');
+ if (!signingkey->len) {
+ strbuf_addstr(signingkey,
+ git_committer_info(IDENT_ERROR_ON_NO_NAME));
+ bracket = strchr(signingkey->buf, '>');
if (bracket)
- bracket[1] = '\0';
+ strbuf_setlen(signingkey, bracket + 1 - signingkey->buf);
}
/* When the username signingkey is bad, program could be terminated
@@ -183,7 +180,7 @@ static int do_sign(struct strbuf *buffer)
gpg.out = -1;
args[0] = "gpg";
args[1] = "-bsau";
- args[2] = signingkey;
+ args[2] = signingkey->buf;
args[3] = NULL;
if (start_command(&gpg))
@@ -220,18 +217,12 @@ static const char tag_template[] =
"# Write a tag message\n"
"#\n";
-static void set_signingkey(const char *value)
-{
- if (strlcpy(signingkey, value, sizeof(signingkey)) >= sizeof(signingkey))
- die("signing key value too long (%.10s...)", value);
-}
-
static int git_tag_config(const char *var, const char *value, void *cb)
{
if (!strcmp(var, "user.signingkey")) {
if (!value)
return config_error_nonbool(var);
- set_signingkey(value);
+ strbuf_addstr((struct strbuf *) cb, value);
return 0;
}
@@ -266,9 +257,10 @@ static void write_tag_body(int fd, const unsigned char *sha1)
free(buf);
}
-static int build_tag_object(struct strbuf *buf, int sign, unsigned char *result)
+static int build_tag_object(struct strbuf *buf, int sign,
+ struct strbuf *signingkey, unsigned char *result)
{
- if (sign && do_sign(buf) < 0)
+ if (sign && do_sign(signingkey, buf) < 0)
return error("unable to sign the tag");
if (write_sha1_file(buf->buf, buf->len, tag_type, result) < 0)
return error("unable to write tag file");
@@ -277,6 +269,7 @@ static int build_tag_object(struct strbuf *buf, int sign, unsigned char *result)
static void create_tag(const unsigned char *object, const char *tag,
struct strbuf *buf, int message, int sign,
+ struct strbuf *signingkey,
unsigned char *prev, unsigned char *result)
{
enum object_type type;
@@ -331,7 +324,7 @@ static void create_tag(const unsigned char *object, const char *tag,
strbuf_insert(buf, 0, header_buf, header_len);
- if (build_tag_object(buf, sign, result) < 0) {
+ if (build_tag_object(buf, sign, signingkey, result) < 0) {
if (path)
fprintf(stderr, "The tag message has been left in %s\n",
path);
@@ -363,7 +356,7 @@ static int parse_msg_arg(const struct option *opt, const char *arg, int unset)
int cmd_tag(int argc, const char **argv, const char *prefix)
{
- struct strbuf buf = STRBUF_INIT;
+ struct strbuf buf = STRBUF_INIT, signingkey = STRBUF_INIT;
unsigned char object[20], prev[20];
char ref[PATH_MAX];
const char *object_ref, *tag;
@@ -403,14 +396,14 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
OPT_END()
};
- git_config(git_tag_config, NULL);
+ git_config(git_tag_config, &signingkey);
argc = parse_options(argc, argv, options, git_tag_usage, 0);
msgfile = parse_options_fix_filename(prefix, msgfile);
if (keyid) {
sign = 1;
- set_signingkey(keyid);
+ strbuf_addstr(&signingkey, keyid);
}
if (sign)
annotate = 1;
@@ -474,7 +467,7 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
if (annotate)
create_tag(object, tag, &buf, msg.given || msgfile,
- sign, prev, object);
+ sign, &signingkey, prev, object);
lock = lock_any_ref_for_update(ref, prev, 0);
if (!lock)
--
1.5.4.3
^ permalink raw reply related
* Re: [PATCH 3/8] Documentation: rename docbook-xsl-172 attribute to git-asciidoc-no-roff
From: Chris Johnsen @ 2009-03-24 19:48 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano
In-Reply-To: <20090324090440.GC1799@coredump.intra.peff.net>
On 2009 Mar 24, at 04:04, Jeff King wrote:
> On Tue, Mar 24, 2009 at 03:04:21AM -0500, Chris Johnsen wrote:
>
>> It seems that the ability to use raw roff codes in asciidoc.conf
>> was eliminated by docbook-xsl 1.72.0 _and later_. Unlike the
>> 1.72.0-specific XSLT problem, this behavior was not reverted in
>> later releases.
>>
>> This patch aims to make it clear that the affected asciidoc
>> attribute (flag) can be reasonably used with docbook-xsl versions
>> other than 1.72.0.
>
> Great, this looks like a definite improvement. Should we be respecting
> more DOCBOOK_XSL_* variables than just 172, then? I.e.,:
>
>> +# For docbook-xsl ...
>> +# -1.68.1, set ASCIIDOC_NO_ROFF? (based on changelog from 1.73.0)
>> +# 1.69.0-1.71.1, no extra settings are needed?
>> +# 1.72.0, set DOCBOOK_XSL_172.
>> +# 1.73.0-, set ASCIIDOC_NO_ROFF
>
> DOCBOOK_XSL_173, etc?
>
> I don't know that we need to cover _every_ version, but if we can have
> specific knobs for individual features (like ASCIIDOC_NO_ROFF), then
> maybe it makes sense to aggregate the settings for those knobs for
> a few
> common versions.
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?
The versions I listed in the comments were just the ones that the
tools' documentation described as needing one adjustment or another.
I thought the comments would be an easy way to start tracking which
versions were "interesting".
--
Chris
^ permalink raw reply
* Re: [PATCH 2/8] Documentation: use parametrized manpage-base.xsl with manpage-{1.72,normal}.xsl
From: Chris Johnsen @ 2009-03-24 19:42 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano
In-Reply-To: <20090324085751.GB1799@coredump.intra.peff.net>
On 2009 Mar 24, at 03:57, Jeff King wrote:
> On Tue, Mar 24, 2009 at 03:04:20AM -0500, Chris Johnsen wrote:
>
>> +<!-- manpage-1.72.xsl:
>> + special settings for manpages rendered from asciidoc+docbook
>> + must be used with manpage-base.xsl
>> + handles peculiarities in docbook-xsl 1.72.0 -->
>
> Hmm. I'm not sure I understood all of the issues you ran into that you
> mentioned in the commit message (but trust me, having tried to do
> anything with docbook, I can sympathize with the frustration you
> probably felt), so maybe I am missing something. But is it not
> possible
> to <xsl:include> manpage-base here, rather than a comment saying "Make
> sure you have already included it"?
Right. I went overboard with reworking the XSLT into "modules" for
xmlto.
--
Chris
^ permalink raw reply
* Re: [PATCH 1/8] Documentation: move callouts.xsl to manpage-{base,normal}.xsl
From: Chris Johnsen @ 2009-03-24 19:36 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano
In-Reply-To: <20090324085147.GA1799@coredump.intra.peff.net>
On 2009 Mar 24, at 03:51, Jeff King wrote:
> On Tue, Mar 24, 2009 at 03:04:19AM -0500, Chris Johnsen wrote:
>
>> Documentation/Makefile | 2 +-
>> Documentation/callouts.xsl | 30
>> ------------------------------
>> Documentation/manpage-base.xsl | 30 ++++++++++++++++++++++++++
>> ++++
>> Documentation/manpage-normal.xsl | 30 ++++++++++++++++++++++++++
>> ++++
>> 4 files changed, 61 insertions(+), 31 deletions(-)
>> delete mode 100644 Documentation/callouts.xsl
>> create mode 100644 Documentation/manpage-base.xsl
>> create mode 100644 Documentation/manpage-normal.xsl
>
> This is definitely a good change, though it would also be fine to
> actually munge the contents in the same patch rather than duplicate
> them
> (i.e., actually _split_ callouts.xsl instead of copying it to two
> places).
>
> I think it would have been much easier to read, though, by turning on
> rename detection in format-patch (i.e., "-M"). That yields:
Thank you for looking at these. I will incorporate your feedback and
resend in a couple of days.
I used -C -M in some early diffs to make sure it would "compress"
like that, but I failed to do so for the final send-email.
--
Chris
^ permalink raw reply
* Re: fatal: unable to write sha1 file git 1.6.2.1
From: Linus Torvalds @ 2009-03-24 19:31 UTC (permalink / raw)
To: Peter, Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <49C9246E.3030508@mycircuit.org>
On Tue, 24 Mar 2009, Peter wrote:
>
> I try to add a directory with lots of binary files to a git repository.
> I receive the error message:
> *
> fatal: unable to write sha1 file
>
> *This is git 1.6.2.1.
>
> Are there limits concerning binary files ( like executables , images ) for the
> inclusion in a git repo ?
If that is the only error message you got, then afaik the only way that
can happen is if "close(fd)" returns an error.
The only other "unable to write sha1 file" message happens if
write_buffer() fails, but if that happens then you should also have gotten
a
file write error (<error message goes here>)
message in addition to the "unable to write sha1 file".
What OS? What filesystem? Are you perhaps running out of space?
You could also try to apply this patch to get more information (Junio,
maybe worth doing regardless? We should try to avoid ambiguous error
messages that don't give full error information)
Linus
---
sha1_file.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 4563173..54972f9 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2287,7 +2287,7 @@ static void close_sha1_file(int fd)
fsync_or_die(fd, "sha1 file");
fchmod(fd, 0444);
if (close(fd) != 0)
- die("unable to write sha1 file");
+ die("error when closing sha1 file (%s)", strerror(errno));
}
/* Size of directory component, including the ending '/' */
^ permalink raw reply related
* Re: fatal: unable to write sha1 file git 1.6.2.1
From: Nicolas Pitre @ 2009-03-24 19:30 UTC (permalink / raw)
To: Peter; +Cc: git
In-Reply-To: <49C9246E.3030508@mycircuit.org>
On Tue, 24 Mar 2009, Peter wrote:
> Hi
> I try to add a directory with lots of binary files to a git repository.
> I receive the error message:
> *
> fatal: unable to write sha1 file
>
> *This is git 1.6.2.1.
>
> Are there limits concerning binary files ( like executables , images ) for the
> inclusion in a git repo ?
Currently, Git is unable to deal with files that it cannot load entirely
in memory.
What is the size of your largest file?
Nicolas
^ permalink raw reply
* fatal: unable to write sha1 file git 1.6.2.1
From: Peter @ 2009-03-24 18:20 UTC (permalink / raw)
To: git
Hi
I try to add a directory with lots of binary files to a git repository.
I receive the error message:
*
fatal: unable to write sha1 file
*This is git 1.6.2.1.
Are there limits concerning binary files ( like executables , images )
for the inclusion in a git repo ?
Thanks a lot for your help
Peter
^ permalink raw reply
* Re: large(25G) repository in git
From: david @ 2009-03-24 18:33 UTC (permalink / raw)
To: Adam Heath; +Cc: Nicolas Pitre, git
In-Reply-To: <49C91F87.3050105@brainfood.com>
On Tue, 24 Mar 2009, Adam Heath wrote:
> Nicolas Pitre wrote:
>
>> Strange. You could instruct ssh to keep the connection up with the
>> ServerAliveInterval option (see the ssh_config man page).
>
> Sure, could do that. Already have a separate ssh config entry for
> this host. But why should a connection be kept open for that long?
> Why not close and re-open?
what if the server you are connecting to is behind a load balancer? how do
you know that your new connection will go to the same server? if the
client never reconnects, how long should the server keep it's resources
tied up 'just in case'. if something connects to the server, how does it
know if it's something reconnecting or connecting for the first time? (or
someone connecting with the intent of messing up someone else's fetch)
having the client reconnect to finish a single transaction starts getting
_really_ ugly.
David Lang
^ permalink raw reply
* Re: large(25G) repository in git
From: Nicolas Pitre @ 2009-03-24 18:31 UTC (permalink / raw)
To: Adam Heath; +Cc: git
In-Reply-To: <49C91F87.3050105@brainfood.com>
On Tue, 24 Mar 2009, Adam Heath wrote:
> Nicolas Pitre wrote:
>
> > Strange. You could instruct ssh to keep the connection up with the
> > ServerAliveInterval option (see the ssh_config man page).
>
> Sure, could do that. Already have a separate ssh config entry for
> this host. But why should a connection be kept open for that long?
> Why not close and re-open?
Because it is way more complex for git to do that than for ssh to keep
the connection alive. And normally there is no need as git is supposed
to be faster than that.
> Consider the case of other protocol access. http/git/ssh. Should
> they *all* be changed to allow for this? Wouldn't it be simpler to
> just make git smarter?
Making git faster is the solution, not working around the issue.
> >> So, to work around that, I ran git gc. When done, I discovered that
> >> git repacked the *entire* repository. While not something I care for,
> >> I can understand that, and live with it. It just took *hours* to do so.
> >>
> >> Then, what really annoys me, is that when I finally did the push, it
> >> tried sending the single 27G pack file, when the remote already had
> >> 25G of the repository in several different packs(the site was an
> >> hg->git conversion). This part is just unacceptable.
> >
> > This shouldn't happen either. When pushing, git reconstruct a pack with
> > only the necessary objects to transmit. Are you sure it was really
> > trying to send a 27G pack?
>
> Of course I'm sure. I wouldn't have sent the email if it didn't
> happen. And, I have the bandwidthd graph and lost time to prove it.
As much as I would like to believe you, this doesn't help fixing the
problem if you don't provide more information about this. For example,
the output from git during the whole operation might give us the
beginning of a clue. Otherwise, all I can tell you is that such thing
is not supposed to happen.
> After I ran git push, ssh timed out, the temp pack that was created
> was then removed, as git complained about the connection being gone.
On a push, there is no creation of a temp pack. It is always produced
on the fly and pushed straight via the ssh connection.
> I then decided to do a 'git gc', which collapsed all the separate
> packs into one. This allowed git push to proceed quickly, but at that
> point, it started sending the entire pack.
If this was really the case, then this is definitely a bug. Please take
a snapshot of your screen with git messages if this ever happens again.
> It's entirely possible that the temp pack created by git push was
> incremental; it just took too long to create it, so it got aborted.
The push operation has multiple phases. You should see "counting
objects", "compressing objects" and "writing objects". Could you give
us an approximation of how long each of those phases took?
> But, doing git gc shouldn't cause things to be resent.
Indeed.
> The machines in question have done push before. Even small amounts;
> just the set of objects that are newer. It's just this time, when the
> 1.6G of new data was added, git ended up creating a new pack file,
> that contained the entire repo, and then tried sending that.
And this is wrong.
> I forgot to mention previously, that the source machine was running
> git 1.5.6.5, and was pushing to 1.5.6.3.
>
> I've tried duplicating this problem on a machine with 1.6.1.3, but
> either I don't fully understand the issue enough to replicate it, or
> the newer git doesn't have the problem.
That's possible. Maybe others on the list might recall possible issues
related to this that might have been fixed during that time.
> >> 2: Is there an option to tell git to *not* be so thorough when trying
> >> to find similiar files. videos/doc/pdf/etc aren't always very
> >> deltafiable, so I'd be happy to just do full content compares.
> >
> > Look at the gitattribute documentation. One thing that the doc appears
> > to be missing is information about the "delta" attribute. You can
> > disable delta compression on a file pattern that way.
>
> Um, if it's missing documentation, then how am I supposed to know
> about it?
Asking on the list, like you did. However this attribute should be
documented as well of course. I even think that someone posted a patch
for it a while ago which might have been dropped.
Nicolas
^ permalink raw reply
* Re: large(25G) repository in git
From: Adam Heath @ 2009-03-24 17:59 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <alpine.LFD.2.00.0903232056520.26337@xanadu.home>
Nicolas Pitre wrote:
> Strange. You could instruct ssh to keep the connection up with the
> ServerAliveInterval option (see the ssh_config man page).
Sure, could do that. Already have a separate ssh config entry for
this host. But why should a connection be kept open for that long?
Why not close and re-open?
Consider the case of other protocol access. http/git/ssh. Should
they *all* be changed to allow for this? Wouldn't it be simpler to
just make git smarter?
>> So, to work around that, I ran git gc. When done, I discovered that
>> git repacked the *entire* repository. While not something I care for,
>> I can understand that, and live with it. It just took *hours* to do so.
>>
>> Then, what really annoys me, is that when I finally did the push, it
>> tried sending the single 27G pack file, when the remote already had
>> 25G of the repository in several different packs(the site was an
>> hg->git conversion). This part is just unacceptable.
>
> This shouldn't happen either. When pushing, git reconstruct a pack with
> only the necessary objects to transmit. Are you sure it was really
> trying to send a 27G pack?
Of course I'm sure. I wouldn't have sent the email if it didn't
happen. And, I have the bandwidthd graph and lost time to prove it.
After I ran git push, ssh timed out, the temp pack that was created
was then removed, as git complained about the connection being gone.
I then decided to do a 'git gc', which collapsed all the separate
packs into one. This allowed git push to proceed quickly, but at that
point, it started sending the entire pack.
It's entirely possible that the temp pack created by git push was
incremental; it just took too long to create it, so it got aborted.
But, doing git gc shouldn't cause things to be resent.
The machines in question have done push before. Even small amounts;
just the set of objects that are newer. It's just this time, when the
1.6G of new data was added, git ended up creating a new pack file,
that contained the entire repo, and then tried sending that.
I forgot to mention previously, that the source machine was running
git 1.5.6.5, and was pushing to 1.5.6.3.
I've tried duplicating this problem on a machine with 1.6.1.3, but
either I don't fully understand the issue enough to replicate it, or
the newer git doesn't have the problem.
>> 2: Is there an option to tell git to *not* be so thorough when trying
>> to find similiar files. videos/doc/pdf/etc aren't always very
>> deltafiable, so I'd be happy to just do full content compares.
>
> Look at the gitattribute documentation. One thing that the doc appears
> to be missing is information about the "delta" attribute. You can
> disable delta compression on a file pattern that way.
Um, if it's missing documentation, then how am I supposed to know
about it? google does give me info, tho. Thanks for the pointer.
>
>> 3: delta packs seem to be poorly done. it seems that if one repo gets
>> repacked completely, that the entire new pack gets sent, when the
>> target has most of the objects already.
>
> This is not supposed to happen. Please provide more details if you can.
Well, I haven't been able to replicate it with a script. I might have
to actually clone this huge repo, do history removal, and reapply the
changes, just to see if I can get it to fail. But that will take time.
^ permalink raw reply
* Re: branch ahead in commits but push claims all up to date
From: Daniel Barkalow @ 2009-03-24 17:13 UTC (permalink / raw)
To: John Tapsell; +Cc: Irene Ros, git
In-Reply-To: <43d8ce650903240918q2ffdba44w241e0f378a11fd3d@mail.gmail.com>
On Tue, 24 Mar 2009, John Tapsell wrote:
> 2009/3/24 Irene Ros <imirene@gmail.com>:
> > Hi all,
> >
> > I've been using git for some time now and haven't run into this issue
> > before, perhaps someone else here has:
> >
> > I have a branch that is ahead of its origin by a few commits:
> >
> > $ git status
> > # On branch myBranch
> > # Your branch is ahead of 'origin/myBranch' by 10 commits.
>
> Tried running: git fetch ?
>
> For some weird reason "git push origin mybranch" doesn't actually
> update origin/mybranch. It's more annoying :-)
It should, so long as you're using the native transport and
origin/mybranch actually tracks mybranch on origin.
"git push" doesn't update it, but the code that implements the native
transport does update it if it succeeds.
(Actually, I'm not 100% sure that, if you update origin through some other
channel with exactly the commit that you now have in mybranch locally, and
then try the push, it will update the local tracking for that branch; is
that what you've hit?)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Project With Reusable Libraries
From: John Dlugosz @ 2009-03-24 16:40 UTC (permalink / raw)
To: git
Consider a directory tree something like this:
...
foo\
bar\
project-root\
app1\
contents of app1
app2\
contents of app2
lib1\
contents of library 1
lib2\
contents of library 2
Each project, whether application or library, has its own git repository
already. A program, say app1, is now dependant on the libraries. The
libraries are meant to be used in multiple applications.
This is not like what is described under subprojects, since the libs are
not "under" the application, but are peers in the directory structure.
It would be wrong to put lib1 and lib2 as subdirectories of app1 because
they are also used by app2, right?
Then again... if app1 and app2 are not always built as part of the same
set, they might have different versions of the libs specified. I
understand that the newer versions of msysgit do hard linking so having
multiple repositories for the same thing won't waste disk space, but
still requires fetching to keep them in sync?
Anyway, how would you do it?
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: [PATCH] git-cget: prints elements of C code in the git repository
From: Mike Ralphson @ 2009-03-24 16:37 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, Roel Kluin, git, Ping Yin, Steven Tweed
In-Reply-To: <alpine.DEB.1.00.0903241555360.7493@intel-tinevez-2-302>
2009/3/24 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>> This kind of pipeline has the benefit that it can actually work on the
>> *repository*, and not just the working copy (as per the posted script).
>
> Did I miss something? git ls-files pipes only the names to xargs, not the
> full contents, right?
See where I wrote "this kind of pipeline" vs "git ls-files" which was
just quoting Peff? 8-)
I dunno, maybe C folk using git would only be interested in the
index/working copy, but that tells me this script is even more
tenuously linked to git. We don't bundle a compiler just because it
can use git ls-files to work out what to compile...
The script might be best as a standalone tool which just happened to
take advantage of the VCS in use by reacting to its surroundings. Then
it would also be useful by hg, svn, cvs people etc.
If it actually used the information in the repository to be able to
run git blame on the definitions, or show a git log -p style list of
changes in the definition, that might be different.
Mike
^ permalink raw reply
* Re: [PATCH] git-cget: prints elements of C code in the git repository
From: Steven Tweed @ 2009-03-24 16:33 UTC (permalink / raw)
To: Mike Ralphson; +Cc: Jeff King, Roel Kluin, Johannes Schindelin, git
In-Reply-To: <e2b179460903240738x272c884q62a666931ce99c2f@mail.gmail.com>
On Tue, Mar 24, 2009 at 2:38 PM, Mike Ralphson <mike.ralphson@gmail.com> wrote:
> 2009/3/24 Jeff King <peff@peff.net>:
> This kind of pipeline has the benefit that it can actually work on the
> *repository*, and not just the working copy (as per the posted
> script).
Speaking of wanting things to work with the actual repository , one
thing that I've been meaning to continue work on if I get the time is
basically a 'show me any commit diff's that involve string s' (ie, the
locations in which a change involving s occurs rather than just
'current file contains s (in exactly the same ways the previous
version did). I'm extremely unlikely to actually produce anything
based on that in the near future. But one thing that struck me that
might be reasonably useful is some way of filtering the "context" that
a string occurs in (is it in generic code context, in a string or in a
comment). These are things that tend to be reasonably parametrisable
by regular expressions (although escaping string delimiters within in
strings makes completely correct behaviour tricky), so if git-grep
itself were to be extended I'd prefer something that can be specified
per search in a more generally usable way than something very C
specific. Of course this is a quite difficult task as the actual diff
may not contain enough lines to distinguish, eg, that it occurs within
a longer comment. (As already disclaimed, I'm unlikely to actually get
around to doing any of this work).
cheers, dave tweed
^ permalink raw reply
* Re: branch ahead in commits but push claims all up to date
From: John Tapsell @ 2009-03-24 16:18 UTC (permalink / raw)
To: Irene Ros; +Cc: git
In-Reply-To: <7001b7a00903240822w70a57349xcc66a02cef62dc70@mail.gmail.com>
2009/3/24 Irene Ros <imirene@gmail.com>:
> Hi all,
>
> I've been using git for some time now and haven't run into this issue
> before, perhaps someone else here has:
>
> I have a branch that is ahead of its origin by a few commits:
>
> $ git status
> # On branch myBranch
> # Your branch is ahead of 'origin/myBranch' by 10 commits.
Tried running: git fetch ?
For some weird reason "git push origin mybranch" doesn't actually
update origin/mybranch. It's more annoying :-)
John
> Oddly, when I try to do a push, I get a message saying that everything
> is up to date:
> $ git push origin myBranch
> Everything up-to-date
>
> Looking at the log for origin/myBranch I can tell those commits are
> missing, but I can't push them up, even with a --force flag. Any
> ideas?
> Here's the config entry for this branch:
>
> [branch "myBranch"]
> remote = origin
> merge = refs/heads/myBranch
>
> There's also nothing to pull from this branch, I'm the only one working on it.
> I use many other branches in this particular repo, and its just this
> one that's giving me trouble.
>
> Thanks so much!
> -- Irene
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] git-cget: prints elements of C code in the git repository
From: roel kluin @ 2009-03-24 16:17 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, git
In-Reply-To: <20090324135906.GA10644@coredump.intra.peff.net>
> Wouldn't it be a lot easier to base this on something like ctags, which
> already knows how to do all the parsing of C quirky C?
>
> I.e.:
>
> git ls-files | xargs ctags
> vi -t get_sha1
You are right, I'll see what I can do with it.
^ permalink raw reply
* Re: branch ahead in commits but push claims all up to date
From: Junio C Hamano @ 2009-03-24 16:12 UTC (permalink / raw)
To: Irene Ros; +Cc: git
In-Reply-To: <7001b7a00903240822w70a57349xcc66a02cef62dc70@mail.gmail.com>
Irene Ros <imirene@gmail.com> writes:
> Hi all,
>
> I've been using git for some time now and haven't run into this issue
> before, perhaps someone else here has:
>
> I have a branch that is ahead of its origin by a few commits:
>
> $ git status
> # On branch myBranch
> # Your branch is ahead of 'origin/myBranch' by 10 commits.
>
> Oddly, when I try to do a push, I get a message saying that everything
> is up to date:
> $ git push origin myBranch
> Everything up-to-date
>
> Looking at the log for origin/myBranch I can tell those commits are
> missing, but I can't push them up, even with a --force flag. Any
> ideas?
> Here's the config entry for this branch:
>
> [branch "myBranch"]
> remote = origin
> merge = refs/heads/myBranch
How does your
[remote "origin"]
part look like?
^ permalink raw reply
* Re: [StGit PATCH] Add the --merged option to goto
From: Catalin Marinas @ 2009-03-24 15:40 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20090324131640.GB4040@diana.vm.bytemark.co.uk>
2009/3/24 Karl Hasselström <kha@treskal.com>:
> On 2009-03-23 16:33:04 +0000, Catalin Marinas wrote:
>> Now I understand it better :-). Reading my explanation above, it
>> seems that only the T1..T2 case matters and it can be taken care of
>> in the check_merged() function. Checking whether the tree returned
>> by merge() is different than "ours" should be enough for all the
>> above cases.
>
> Hmm. If the tip of the branch is T1, and we reverse-apply the patch
> T1..T2, we get the merge (base T2, ours T1, theirs T1) ... yeah, I see
> what you mean. The problem isn't that we give T1 as the result of this
> merge -- that's actually the right thing to do -- the problem is that
> you don't actually want a merge. What you want is patch application.
> Maybe the apply_treediff method would do?
Yes, see below for an updated patch.
>> I had the impression that an Index object would hold some state and
>> didn't want to break it. It seems OK to use as long as I don't touch
>> self.temp_index_tree. See below for an updated patch:
>
> Yes, an Index object owns a git index file.
>
> And no, not quite. temp_index_tree is set to the tree we know is
> stored in temp_index right now (or None if we don't know). The idea is
> that we'll often want to read a tree into the index that's already
> there, and by keeping track of this we'll get better performance.
> (This works very well in practice.) Apologies if there aren't comments
> explaining this ... the merge method has some docs on the subject.
I figured this out eventually. Anyway, with apply_treedif() there is
no need for the temp_index_tree. In the updated patch below, I don't
even call write_tree() as it isn't needed (to my understanding).
Whatever is in the index after the check_merged() function doesn't
correspond to any tree so it would need to be re-read.
BTW, I implemented push and pop and it now passes all the "push
--merged" tests. I had to correct the "already_merged" case in
Transaction.push_patch() to generate an empty patch.
Add the --merged option to goto
This patch adds support for checking which patches were already merged
upstream. This checking is done by trying to reverse-apply the patches
in the index before pushing them onto the stack.
Signed-off-by: Catalin Marinas <catalin.marinas@gmail.com>
diff --git a/stgit/argparse.py b/stgit/argparse.py
index 85ee6e3..765579c 100644
--- a/stgit/argparse.py
+++ b/stgit/argparse.py
@@ -225,6 +225,10 @@ def keep_option():
short = 'Keep the local changes',
default = config.get('stgit.autokeep') == 'yes')]
+def merged_option():
+ return [opt('-m', '--merged', action = 'store_true',
+ short = 'Check for patches merged upstream')]
+
class CompgenBase(object):
def actions(self, var): return set()
def words(self, var): return set()
diff --git a/stgit/commands/goto.py b/stgit/commands/goto.py
index 66f49df..839b75c 100644
--- a/stgit/commands/goto.py
+++ b/stgit/commands/goto.py
@@ -28,7 +28,7 @@ Push/pop patches to/from the stack until the one
given on the command
line becomes current."""
args = [argparse.other_applied_patches, argparse.unapplied_patches]
-options = argparse.keep_option()
+options = argparse.keep_option() + argparse.merged_option()
directory = common.DirectoryHasRepositoryLib()
@@ -47,8 +47,14 @@ def func(parser, options, args):
assert not trans.pop_patches(lambda pn: pn in to_pop)
elif patch in trans.unapplied:
try:
- for pn in trans.unapplied[:trans.unapplied.index(patch)+1]:
- trans.push_patch(pn, iw, allow_interactive = True)
+ to_push = trans.unapplied[:trans.unapplied.index(patch)+1]
+ if options.merged:
+ merged = set(trans.check_merged(to_push))
+ else:
+ merged = set()
+ for pn in to_push:
+ trans.push_patch(pn, iw, allow_interactive = True,
+ already_merged = pn in merged)
except transaction.TransactionHalted:
pass
elif patch in trans.hidden:
diff --git a/stgit/lib/transaction.py b/stgit/lib/transaction.py
index b146648..e2d9b78 100644
--- a/stgit/lib/transaction.py
+++ b/stgit/lib/transaction.py
@@ -297,7 +297,8 @@ class StackTransaction(object):
out.info('Deleted %s%s' % (pn, s))
return popped
- def push_patch(self, pn, iw = None, allow_interactive = False):
+ def push_patch(self, pn, iw = None, allow_interactive = False,
+ already_merged = False):
"""Attempt to push the named patch. If this results in conflicts,
halts the transaction. If index+worktree are given, spill any
conflicts to them."""
@@ -305,11 +306,15 @@ class StackTransaction(object):
cd = orig_cd.set_committer(None)
oldparent = cd.parent
cd = cd.set_parent(self.top)
- base = oldparent.data.tree
- ours = cd.parent.data.tree
- theirs = cd.tree
- tree, self.temp_index_tree = self.temp_index.merge(
- base, ours, theirs, self.temp_index_tree)
+ if already_merged:
+ # the resulting patch is empty
+ tree = cd.parent.data.tree
+ else:
+ base = oldparent.data.tree
+ ours = cd.parent.data.tree
+ theirs = cd.tree
+ tree, self.temp_index_tree = self.temp_index.merge(
+ base, ours, theirs, self.temp_index_tree)
s = ''
merge_conflict = False
if not tree:
@@ -341,7 +346,9 @@ class StackTransaction(object):
else:
comm = None
s = ' (unmodified)'
- if not merge_conflict and cd.is_nochange():
+ if already_merged:
+ s = ' (merged)'
+ elif not merge_conflict and cd.is_nochange():
s = ' (empty)'
out.info('Pushed %s%s' % (pn, s))
def update():
@@ -379,3 +386,23 @@ class StackTransaction(object):
assert set(self.unapplied + self.hidden) == set(unapplied + hidden)
self.unapplied = unapplied
self.hidden = hidden
+
+ def check_merged(self, patches):
+ """Return a subset of patches already merged."""
+ merged = []
+ self.temp_index.read_tree(self.stack.head.data.tree)
+ # The self.temp_index is modified by apply_treediff() so force
+ # read_tree() the next time merge() is used.
+ self.temp_index_tree = None
+ for pn in reversed(patches):
+ # check whether patch changes can be reversed in the current index
+ cd = self.patches[pn].data
+ if cd.is_nochange():
+ continue
+ try:
+ self.temp_index.apply_treediff(cd.tree, cd.parent.data.tree,
+ quiet = True)
+ merged.append(pn)
+ except git.MergeException:
+ pass
+ return merged
Thanks.
--
Catalin
^ 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