* Re: Performance issue: initial git clone causes massive repack
From: Jeff King @ 2009-04-05 19:57 UTC (permalink / raw)
To: Robin H. Johnson; +Cc: Git Mailing List
In-Reply-To: <20090404220743.GA869@curie-int>
On Sat, Apr 04, 2009 at 03:07:43PM -0700, Robin H. Johnson wrote:
> During an initial clone, I see that git-upload-pack invokes
> pack-objects, despite the ENTIRE repository already being packed - no
> loose objects whatsoever. git-upload-pack then seems to buffer in
> memory.
We need to run pack-objects even if the repo is fully packed because we
don't know what's _in_ the existing pack (or packs). In particular we
want to:
- combine multiple packs into a single pack; this is more efficient on
the network, because you can find more deltas, and I believe is
required because the protocol sends only a single pack.
- cull any objects which are not actually part of the reachability
chain from the refs we are sending
If no work needs to be done for either case, then pack-objects should
basically just figure that out and then send the existing pack (the
expensive bit is doing deltas, and we don't consider objects in the same
pack for deltas, as we know we have already considered that during the
last repack). It does mmap the whole pack, so you will see your virtual
memory jump, but nothing should require the whole pack being in memory
at once.
pack-objects streams the output to upload-pack, which should only ever
have an 8K buffer of it in memory at any given time.
At least that is how it is all supposed to work, according to my
understanding. So if you are seeing very high memory usage, I wonder if
there is a bug in pack-objects or upload-pack that can be fixed.
Maybe somebody more knowledgeable than me about packing can comment.
> During 'remote: Counting objects: 4886949, done.', git-upload-pack peaks at
> 2474216KB VSZ and 1143048KB RSS.
> Shortly thereafter, we get 'remote: Compressing objects: 0%
> (1328/1994284)', git-pack-objects with ~2.8GB VSZ and ~1.8GB RSS. Here,
> the CPU burn also starts. On our test server machine (w/ git 1.6.0.6),
> it takes about 200 minutes walltime to finish the pack, IFF the OOM
> doesn't kick in.
Have you tried with a more recent git to see if it is any better? There
have been a number of changes since 1.6.0.6, although it looks like
mostly dealing with better recovery from corrupted packs.
> Given that the repo is entirely packed already, I see no point in doing
> this.
>
> For the initial clone, can the git-upload-pack algorithm please send
> existing packs, and only generate a pack containing the non-packed
> items?
I believe that would require a change to the protocol to allow multiple
packs. However, it may be possible to munge the pack header in such a
way that you basically concatenate multiple packs. You would still want
to peek in the big pack to try deltas from the non-packed items, though.
I think all of this falls into the realm of the GSOC pack caching project.
There have been other discussions on the list, so you might want to look
through those for something useful.
-Peff
^ permalink raw reply
* Re: [RFC/PATCH 0/2] New 'stage' command
From: Junio C Hamano @ 2009-04-05 19:59 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <7v7i1yrj3t.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> On Sun, Apr 5, 2009 at 10:02 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>>
>>>> This is the list of actions I've mapped:
>>>>
>>>> * add: git stage = git stage add (git add)
>>>> * rm: (git rm --cached)
>>>> * diff: (git rm --cached)
>>>> * import: stage all files; modified, deleted, new
>>>> * ls: (git ls-files --stage)
>>>
>>> I do not think these are good ideas at all, as it just spreads more
>>> confusion, not less.
>>
>> Do you agree that there's already a lot of confusion? (stage, cache,
>> index, etc.)
>>
>> And do you agree that many git newbies don't use the stage? Actually
>> most of them don't even know what it is, and just do "git commit -a".
>>
>> If so, how do you think these issues should be handled?
>
> Perhaps not spreading "stage" even wider? That is the newest confusing
> term that caused the most harm.
This probably needs clarification for new people who do not know the
history.
Before Linus published the very original git, he was designing a system
that can work with the tarball+patches workflow, and dircache (which was
the name of the .git directory) was a mechanism to give various snapshots
a faster access by using the git object machinery by "caching" the result
of applying sequence of patches to certain point of history. The file
inside the .dircache that records the object names that correspond to the
state in the work tree state was .dircache/index.
We've been living with the cache/index, and many user visible actions have
been called in sentences like "adding contents to the cache" or "comparing
with the index" that used cache/index more or less interchangeably. Later
we started to standardizing on the term "index" primarily because that is
the entity on the filesystem the end user is aware of (as opposed to
"cache" that still live throughout the code).
Some operations however needed to have two modes of operation, one being
working on both work tree files and the index and another being working
only on the index. Most of the time, the former was the default (and the
only mode implemented) and the latter mode needed an explicit option to
ask for. --cached is used when you ask them to ignore work tree
(i.e. "git apply --cached", "git diff --cached"). Unfortunately apply has
a third variant that works only on the work tree and because it is meant
as a replacement of GNU patch that works outside a git repository, that
mode is the default, and you need to ask with "git apply --index" to
affect both the index and the work tree.
If we were already well into "standardize on index, not telling the
end-users about cache" journey back then, and --cached should have been
called --index-only, but unfortunately the history was the other way
around.
Later, some outside people started "git training industry" without talking
with the git development community and started using a new term "to stage"
as a verb to describe "add to the index". Addition of "git diff --staged"
was supposed to lesson the confusion resulted from this mess, but as we
can see from your patch it had a reverse effect.
I do not think "to stage" as the name of the _concept_ is a bad thing
per-se. But the name of the concept and the command verb (and option
name) does not have to agree with each other.
cf. http://gitster.livejournal.com/19427.html
In retrospect, I think it might have been less problematic if we firmly
rejected "stage" as an option name, but instead renamed the --cached
option to --index-only and made the former a synonym to the latter to
really standardize on "index". I think it still is Ok to use the word "to
stage" to colloquially call the act of "adding to index", but if we did
not add that to the UI but kept it strictly at the concept level, it would
have made the UI less confusing, not more.
^ permalink raw reply
* Re: [PATCH 1/4] sha1-lookup: add new "sha1_pos" function to efficiently lookup sha1
From: Jeff King @ 2009-04-05 19:59 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Junio C Hamano, Christian Couder, git, Johannes Schindelin
In-Reply-To: <fabb9a1e0904051206l11a629cald95a794815c2d76f@mail.gmail.com>
On Sun, Apr 05, 2009 at 09:06:56PM +0200, Sverre Rabbelier wrote:
> > It is an assert, and I think Peff's die("BUG: ...") would be a good idea.
>
> As long as the <something that makes sense to the user> does indeed
> make sense, right :).
I think:
die("BUG: assertion failed in binary search")
would be sufficient to tell the user what is going on, and let them
inform the list what happened.
However, if this "oops" has been there for 2 years and nobody has seen
it, it's entirely possible that somebody actually got the binary search
code right in the first place. ;)
-Peff
^ permalink raw reply
* Re: [PATCH 1/4] sha1-lookup: add new "sha1_pos" function to efficiently lookup sha1
From: Junio C Hamano @ 2009-04-05 20:02 UTC (permalink / raw)
To: Reece Dunn
Cc: Felipe Contreras, Sverre Rabbelier, Christian Couder, git,
Johannes Schindelin
In-Reply-To: <3f4fd2640904051231x17117a4g3efe38067c8d3359@mail.gmail.com>
Reece Dunn <msclrhd@googlemail.com> writes:
> 2009/4/5 Felipe Contreras <felipe.contreras@gmail.com>:
>> On Sun, Apr 5, 2009 at 9:59 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> U3ZlcnJlIFJhYmJlbGllciA8c3JhYmJlbGllckBnbWFpbC5jb20+IHdyaXRlczoNCg0KPiBPbiBT
>>> YXQsIEFwciA0LCAyMDA5IGF0IDIyOjU5LCBDaHJpc3RpYW4gQ291ZGVyIDxjaHJpc2Nvb2xAdHV4
>>> ZmFtaWx5Lm9yZz4gd3JvdGU6DQo+PiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
>>> IMKgIMKgIMKgIMKgIGlmIChsbyA8PSBtaSAmJiBtaSA8IGhpKQ0KPj4gKyDCoCDCoCDCoCDCoCDC
>>> oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBicmVhazsNCj4+ICsg
>>> wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZGllKCJvb3BzIik7
>>> DQo+DQo+IFRoYXQncyBnb2luZyB0byBiZSBhbiBvZmZpY2lhbCBnaXQgZXJyb3IgbWVzc2FnZT8g
>>> V2h5IG5vdCBtYWtlIGl0ICJUaGUNCg0KSXQncyBub3QgImdvaW5nIHRvIGJlIiwgYnV0ICJoYXMg
>>> YmVlbiBzbyBmb3IgdGhlIGxhc3QgdHdvIHllYXJzIHNpbmNlDQo1ZDIzZTEzIi4NCg0KSXQgaXMg
>>> YW4gYXNzZXJ0LCBhbmQgSSB0aGluayBQZWZmJ3MgZGllKCJCVUc6IC4uLiIpIHdvdWxkIGJlIGEg
>>> Z29vZCBpZGVhLg0K
>>
>> Huh?
>
> I think Junio is trying to learn base64 :)!
I think that is what my Gnus/message-mode did. I do not know which letter
triggered it to decide it is UTF-8 to begin with, though. As far as I am
aware, I didn't type anything non-ascii in my message.
^ permalink raw reply
* Re: [PATCH 1/4] sha1-lookup: add new "sha1_pos" function to efficiently lookup sha1
From: Sverre Rabbelier @ 2009-04-05 20:05 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Christian Couder, git, Johannes Schindelin
In-Reply-To: <20090405195908.GB4716@coredump.intra.peff.net>
Heya,
On Sun, Apr 5, 2009 at 21:59, Jeff King <peff@peff.net> wrote:
> die("BUG: assertion failed in binary search")
Given that we now only have one binary search (which should be re-used
everywhere), I think it's fair enough to describe it like that.
> However, if this "oops" has been there for 2 years and nobody has seen
> it, it's entirely possible that somebody actually got the binary search
> code right in the first place. ;)
Hehe, never underestimate the difficulty of writing a proper binary
search! :P But I do agree two years of 'testing' is more than more
binary searches get before being 'released' ;).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 1/4] sha1-lookup: add new "sha1_pos" function to efficiently lookup sha1
From: Jeff King @ 2009-04-05 20:17 UTC (permalink / raw)
To: Reece Dunn
Cc: Felipe Contreras, Junio C Hamano, Sverre Rabbelier,
Christian Couder, git, Johannes Schindelin
In-Reply-To: <3f4fd2640904051231x17117a4g3efe38067c8d3359@mail.gmail.com>
On Sun, Apr 05, 2009 at 08:31:06PM +0100, Reece Dunn wrote:
> This is what `base64 -d` gives:
> [...]
> It's not "going to be", but "has been so for the last two years since
> 5d23e13".
>
> It is an assert, and I think Peff's die("BUG: ...") would be a good idea.
Interestingly, I get a bunch of unprintable crap at the end. The culprit
seems to be that vger stupidly adds:
--
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
to the bottom, regardless of transfer-encoding. At best, this is
pointless and invisible, as the reader will just show the base64
content. But some decoders (like mutt) actually treat non-base64
characters not as "end of base64" but as "ignore and keep looking for
more base64". So this decodes into a bunch of random characters. And to
make it even more fun, it only happens if the message is a certain
length; otherwise, it needs "=" fill characters at the end, which
unambiguously signal the end.
"openssl base64 -d" stops decoding at the cruft. But I think what mutt
is doing is right. According to RFC 2045:
The encoded output stream must be represented in lines of no more
than 76 characters each. All line breaks or other characters not
found in Table 1 must be ignored by decoding software. In base64
data, characters other than those in Table 1, line breaks, and
other white space probably indicate a transmission error, about
which a warning message or even a message rejection might be
appropriate under some circumstances.
I don't know if it is worth trying to get vger to be smarter. According
to this, they consider base64 text parts not worth handling:
http://lkml.indiana.edu/hypermail/linux/kernel/0304.0/0901.html
So maybe it is worth trying to get Junio not to send base64 mail. ;)
-Peff
^ permalink raw reply
* Re: non-ascii filenames issue
From: Jay Soffian @ 2009-04-05 20:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: John Tapsell, Teemu Likonen, git
In-Reply-To: <7vfxgmrjb7.fsf@gitster.siamese.dyndns.org>
> I do not think the message gives enough information on the issue
Of course you are correct. I was perturbed by John's message, but your
thoughtful reply is much more beneficial than my silly link. Thank you
for providing the level-headed response as always.
j.
^ permalink raw reply
* Re: [EGIT PATCH 2/5] quickdiff - Don't add GitDocument as repository listener more than once
From: Shawn O. Pearce @ 2009-04-05 20:24 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <1238697991-12990-3-git-send-email-robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> Doing so was very costly and led to sessions being locked
> for a long time while refreshing the reference document used
> by Eclipse's quickdiff feature.
...
> --- a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
> +++ b/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
> @@ -1132,6 +1132,7 @@ public File getWorkDir() {
> * @param l
> */
> public void addRepositoryChangedListener(final RepositoryListener l) {
> + assert !listeners.contains(l);
> listeners.add(l);
> }
>
> @@ -1150,6 +1151,7 @@ public void removeRepositoryChangedListener(final RepositoryListener l) {
> * @param l
> */
> public static void addAnyRepositoryChangedListener(final RepositoryListener l) {
> + assert !allListeners.contains(l);
> allListeners.add(l);
> }
That's a race condition. The two collections are Vectors so another
thread can add the listener between your assertion point and the
add call.
Also, if this really is considered to be very bad behavior on the
part of the application, maybe these should be real tests with
exceptions thrown, so they can't be disabled when assertions are
turned off in the JRE?
--
Shawn.
^ permalink raw reply
* Re: [PATCH 1/4] sha1-lookup: add new "sha1_pos" function to efficiently lookup sha1
From: Jeff King @ 2009-04-05 20:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Reece Dunn, Sverre Rabbelier, Christian Couder, git
In-Reply-To: <7vocvaq36x.fsf@gitster.siamese.dyndns.org>
On Sun, Apr 05, 2009 at 01:02:30PM -0700, Junio C Hamano wrote:
> > I think Junio is trying to learn base64 :)!
>
> I think that is what my Gnus/message-mode did. I do not know which letter
> triggered it to decide it is UTF-8 to begin with, though. As far as I am
> aware, I didn't type anything non-ascii in my message.
Actually, it is Sverre's fault. :)
You quoted his message, quoting Christian's message. Christian's message
was 7bit. But for some reason, Sverre's quoting of Christian's message
contains weird iso8859 space characters (0xa0).
But it is probably worth configuring Gnus to use QP instead of base64.
It's more efficient (for mostly ascii text), more readable to humans
looking at the encoded form, and is less likely to make you look like a
spammer. :)
-Peff
^ permalink raw reply
* Gnus content transfer encoding (was: [PATCH 1/4] sha1-lookup: add new "sha1_pos" function to efficiently lookup sha1)
From: Teemu Likonen @ 2009-04-05 20:28 UTC (permalink / raw)
To: Junio C Hamano
Cc: Reece Dunn, Felipe Contreras, Sverre Rabbelier, Christian Couder,
git, Johannes Schindelin
In-Reply-To: <7vocvaq36x.fsf@gitster.siamese.dyndns.org>
On 2009-04-05 13:02 (-0700), Junio C Hamano wrote:
> Reece Dunn <msclrhd@googlemail.com> writes:
>> I think Junio is trying to learn base64 :)!
>
> I think that is what my Gnus/message-mode did. I do not know which
> letter triggered it to decide it is UTF-8 to begin with, though. As
> far as I am aware, I didn't type anything non-ascii in my message.
You can customize the encoding decision mechanism, for example:
(setq mm-body-charset-encoding-alist
'((iso-8859-1 . 8bit)
(utf-8 . 8bit)))
For more info, see:
C-h v mm-body-charset-encoding-alist RET
^ permalink raw reply
* Re: [PATCH 1/4] sha1-lookup: add new "sha1_pos" function to efficiently lookup sha1
From: Jay Soffian @ 2009-04-05 20:34 UTC (permalink / raw)
To: Reece Dunn
Cc: Felipe Contreras, Junio C Hamano, Sverre Rabbelier,
Christian Couder, git, Johannes Schindelin
In-Reply-To: <3f4fd2640904051231x17117a4g3efe38067c8d3359@mail.gmail.com>
On Sun, Apr 5, 2009 at 3:31 PM, Reece Dunn <msclrhd@googlemail.com> wrote:
> 2009/4/5 Felipe Contreras <felipe.contreras@gmail.com>:
>> On Sun, Apr 5, 2009 at 9:59 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> U3ZlcnJlIFJhYmJlbGllciA8c3JhYmJlbGllckBnbWFpbC5jb20+IHdyaXRlczoNCg0KPiBPbiBT
>>> YXQsIEFwciA0LCAyMDA5IGF0IDIyOjU5LCBDaHJpc3RpYW4gQ291ZGVyIDxjaHJpc2Nvb2xAdHV4
>>> ZmFtaWx5Lm9yZz4gd3JvdGU6DQo+PiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
>>> IMKgIMKgIMKgIMKgIGlmIChsbyA8PSBtaSAmJiBtaSA8IGhpKQ0KPj4gKyDCoCDCoCDCoCDCoCDC
>>> oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBicmVhazsNCj4+ICsg
>>> wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZGllKCJvb3BzIik7
>>> DQo+DQo+IFRoYXQncyBnb2luZyB0byBiZSBhbiBvZmZpY2lhbCBnaXQgZXJyb3IgbWVzc2FnZT8g
>>> V2h5IG5vdCBtYWtlIGl0ICJUaGUNCg0KSXQncyBub3QgImdvaW5nIHRvIGJlIiwgYnV0ICJoYXMg
>>> YmVlbiBzbyBmb3IgdGhlIGxhc3QgdHdvIHllYXJzIHNpbmNlDQo1ZDIzZTEzIi4NCg0KSXQgaXMg
>>> YW4gYXNzZXJ0LCBhbmQgSSB0aGluayBQZWZmJ3MgZGllKCJCVUc6IC4uLiIpIHdvdWxkIGJlIGEg
>>> Z29vZCBpZGVhLg0K
>>
>> Huh?
>
> I think Junio is trying to learn base64 :)!
Junio's _original_ message was fine. The problem is that vger
(majordomo) appends the mailing list footer which technically corrupts
the message. Respectable MUA's can deal with the corruption, but
gmail's web-interface just shows the raw base64 (previously it used to
just show an empty message). I've filed a bug against gmail, but who
knows.
The other options are:
- fix majordomo on vger
- replace majordomo on vger with a decent MLM
- disable the mailing list footer
- deal with it if you're a gmail user
j.
^ permalink raw reply
* Re: [PATCH 1/4] sha1-lookup: add new "sha1_pos" function to efficiently lookup sha1
From: Sverre Rabbelier @ 2009-04-05 20:35 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Reece Dunn, Christian Couder, git
In-Reply-To: <20090405202551.GD4716@coredump.intra.peff.net>
Heya,
On Sun, Apr 5, 2009 at 22:25, Jeff King <peff@peff.net> wrote:
> Actually, it is Sverre's fault. :)
Fine, blame the Dutch, why not! :P
> You quoted his message, quoting Christian's message. Christian's message
> was 7bit. But for some reason, Sverre's quoting of Christian's message
> contains weird iso8859 space characters (0xa0).
*points at GMail*, I ain't dun nothing funny! It's always been funny
WRT to vger and encoding issues though, so I'm not surprised.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [EGIT PATCH 5/5] Cache resolved ids in quickdiff document for faster update
From: Shawn O. Pearce @ 2009-04-05 20:36 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <1238697991-12990-6-git-send-email-robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> We do this by caching the commit, tree and blob ids and can then
> very quickly decide whether a change in baseline actually results in a
> changed version of the reference blob used for quickdiff.
...
> @@ -31,6 +34,11 @@
>
> class GitDocument extends Document implements RepositoryListener {
> private final IResource resource;
> +
> + private AnyObjectId lastCommit;
> + private AnyObjectId lastTree;
> + private AnyObjectId lastBlob;
Should have been "ObjectId"; I amended the patch.
> + Commit baselineCommit = repository.mapCommit(commitId);
> + Tree baselineTree = baselineCommit.getTree();
> + TreeEntry blobEntry = baselineTree.findBlobMember(gitPath);
Arrrgh. We're still using Commit/Tree/TreeEntry to read file paths?
I'm applying this as-is, but we really need to start to transition
away from them. I wanted to start deleting the mapCommit and its
friends from the Repository class.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 1/4] sha1-lookup: add new "sha1_pos" function to efficiently lookup sha1
From: Reece Dunn @ 2009-04-05 20:39 UTC (permalink / raw)
To: Junio C Hamano
Cc: Felipe Contreras, Sverre Rabbelier, Christian Couder, git,
Johannes Schindelin
In-Reply-To: <7vocvaq36x.fsf@gitster.siamese.dyndns.org>
2009/4/5 Junio C Hamano <gitster@pobox.com>:
> Reece Dunn <msclrhd@googlemail.com> writes:
>
>> 2009/4/5 Felipe Contreras <felipe.contreras@gmail.com>:
>>>
>>> Huh?
>>
>> I think Junio is trying to learn base64 :)!
>
> I think that is what my Gnus/message-mode did. I do not know which letter
> triggered it to decide it is UTF-8 to begin with, though. As far as I am
> aware, I didn't type anything non-ascii in my message.
Ok, so digging a little deeper, `base64 -d | od -t x1` gives the
following (partial) output:
0000200 6f 74 65 3a 0d 0a 3e 3e 20 2b 20 c2 a0 20 c2 a0
The key entry here is the a0 character (NO-BREAK SPACE) or NBSP.
This is at:
$ base64 -d test | od -t x1 | grep a0 | head -n 1 | xxd -r
ote:
>> +
So looks like it is in the patch you are quoting. NOTE: I have removed
the spaces after the +. Also, according to www.unicode.org, c2 is A^
(A with a circumflex) -- not sure what that is doing there, though.
- Reece
^ permalink raw reply
* Re: [RFC/PATCH 0/2] New 'stage' command
From: Felipe Contreras @ 2009-04-05 20:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzleuq3ci.fsf@gitster.siamese.dyndns.org>
On Sun, Apr 5, 2009 at 10:59 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>
>>> On Sun, Apr 5, 2009 at 10:02 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>>>
>>>>> This is the list of actions I've mapped:
>>>>>
>>>>> * add: git stage = git stage add (git add)
>>>>> * rm: (git rm --cached)
>>>>> * diff: (git rm --cached)
>>>>> * import: stage all files; modified, deleted, new
>>>>> * ls: (git ls-files --stage)
>>>>
>>>> I do not think these are good ideas at all, as it just spreads more
>>>> confusion, not less.
>>>
>>> Do you agree that there's already a lot of confusion? (stage, cache,
>>> index, etc.)
>>>
>>> And do you agree that many git newbies don't use the stage? Actually
>>> most of them don't even know what it is, and just do "git commit -a".
>>>
>>> If so, how do you think these issues should be handled?
>>
>> Perhaps not spreading "stage" even wider? That is the newest confusing
>> term that caused the most harm.
>
> This probably needs clarification for new people who do not know the
> history.
Thanks for the clarification.
<snip/>
Consider this:
== cache ==
This word is barely used in the English language, perhaps only used in
computing nowadays. The 'cache' is often referred to a place for
temporary storage, the purpose being rapid access. It is usually
transparent to the user.
Git uses the term in a completely different manner and the --cached
option is used in important command such as rm and diff. However,
people rarely use the term "git cache", probably because it
immediately evokes multiple caches for better performances.
== index ==
It is unclear to me what the word means in English language, but it is
generally used as a list of things, the purpose being for easy
retrieval.
Again, git is using the term in a different manner, however it is the
most widely used term to identify the concept "the git index",
probably due to the fact that the word "index" evokes a single entity.
But for some reason it's not used in any important commands as
'--index' or '--indexed'.
== stage ==
The word "stage" is used widely in the English language, and it
immediately evokes a theatrical stage. Generally, it means a different
(upper) level.
In git it is barely used, mostly on the "documentation industry"
probably because it's easier to understand for most people (even
non-native-English speakers).
Ideally the term should evoke the concept of a *single* area that has
no other purpose to differentiate from the contents of the working
directory. Also, the action to add and remove content from this area
should sound natural.
That rules out "cache" since "uncache" makes no sense. Something
similar happens with "unindex", although it doesn't sound completely
bad. On the other hand "stage" and "unstage" sound perfectly fine.
> I do not think "to stage" as the name of the _concept_ is a bad thing
> per-se. But the name of the concept and the command verb (and option
> name) does not have to agree with each other.
>
> cf. http://gitster.livejournal.com/19427.html
>
> In retrospect, I think it might have been less problematic if we firmly
> rejected "stage" as an option name, but instead renamed the --cached
> option to --index-only and made the former a synonym to the latter to
> really standardize on "index". I think it still is Ok to use the word "to
> stage" to colloquially call the act of "adding to index", but if we did
> not add that to the UI but kept it strictly at the concept level, it would
> have made the UI less confusing, not more.
Why is it so natural to co-relate "stage" to "adding to the index"?
Would such a relation make sense outside of the git world? No. It is
natural to you because you already know what is the "git index"... it
is a *staging* area for commit preparation, logically it's natural to
co-relate this area with the action "to stage".
Please note it is not an _indexing_ area, nor a _caching_ area.
I agree that the internal (plumbing) term does not need to match the
conceptual term (used in documentation, tutorials, etc.), but the
higher level (porcelain) term *must* match in order for new comers to
grasp it quickly and avoid confusion.
I understand there are historic reasons for the names "cache" and
"index" and those should be thought before considering any change.
But also consider that I'm not proposing any big change... the term
"stage" is already being used, and there's already a "git stage"
command. I'm only proposing to add a few more options :)
I would be very pleased if you could at least try the patch for a few
days, and try "git stage diff" (or "git s diff" with an alias). I've
become very fond of "git s" "git s diff" and "git s -p -u".
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: Performance issue: initial git clone causes massive repack
From: Robin H. Johnson @ 2009-04-05 20:43 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <20090405190213.GA12929@vidovic>
[-- Attachment #1: Type: text/plain, Size: 4679 bytes --]
On Sun, Apr 05, 2009 at 09:02:13PM +0200, Nicolas Sebrecht wrote:
> > Before I answer the rest of your post, I'd like to note that the matter
> > of which choice between single-repo, repo-per-package, repo-per-category
> > has been flogged to death within Gentoo.
> >
> > I did not come to the Git mailing list to rehash those choices. I came
> > here to find a solution to the performance problem.
> I understand. I know two ways to resolve this:
> - by resolving the performance problem itself,
> - by changing the workflow to something more accurate and more suitable
> against the facts.
>
> My point is that going from a centralized to a decentralized SCM
> involves breacking strongly how developers and maintainers work. What
> you're currently suggesting is a way to work with Git in a centralized
> way. This sucks. To get the things right with Git I would avoid shared
> and global repositories. Gnome is doing it this way:
> http://gitorious.org/projects/gnome-svn-hooks/repos/mainline/trees/master
The entire matter of splitting the repository comes down to what should
be considered an atomic unit. For GNOME, KDE and all of the other large
Git consumers that I'm aware of, there atomic units are individual
packages - specifically because they make sense to be consumed without
having all the rest of the packages. For the gentoo tree, it is an
atomic unit in itself. Changes to the profiles/ directory (for package
masks, USE keys are frequently related and need to be always committed
and received atomically with changes to one or more packages.
> > The GSoC 2009 ideas contain a potential project for caching the
> > generated packs, which, while having value in itself, could be partially
> > avoided by sending suitable pre-built packs (if they exist) without any
> > repacking.
> Right. It could be an option to wait and see if the GSoC gives
> something.
How hard is it to just look at the git-upload-pack code and make it
realize that it doesn't need to repack at all for this case.
> > A quick bit of stats run show that while some developers only touch a
> > few packages, there are at least 200 developers that have done a major
> > change to 100 or more packages.
> That's a point that has to be reconsidered. Not the fact that at least
> 200 developers work on over 100 packages (this is really not an issue)¹
> but the fact that they do that directly on the main repo/server. The
> good way to achieve this is to send his work to the maintainer². The main
> issue is a better code reviewing.
This has been shot down by our developer base. One of the grounds is
that there is no developer with sufficient time to take a merge-master
role on a regular basis like that.
> 1. Some or all repo-per-category can be tracked with a simple script.
> 2. Maintainers could be - or not be - the same developers as today.
> Adding a layer of maintainers in charge of EAPI review (for example) up
> to the packages-maintainers could help in fixing a lot of portage issues
> and would avoid "simple developers" to do crap on the main repo(s) that
> users download.
You imply that there is a problem in that field already, which I
disagree with.
> > > One repo per category could be a good compromise assuming one seperate
> > > branch per package, then.
> > Other downsides to repo-per-category and repo-per-package:
> Let's forget a repo-per-package.
One downside unique to repo-per-category is that when a package moves
cross-category, you end up with it consuming space in packs on both
sides.
> > - Raises difficulty in adding a new package/category.
> > You cannot just do 'mkdir && vi ... && git add && git commit' anymore.
> Right, but categories are not evolving that much.
There's demand to evolve them, but bulk package moves are painful with
CVS, so it's been waiting for Git.
> A repo-per-category local workflow would be:
> [...]
> $ git checkout package_one
> $ tree -a
> |-- .git
> | |-- [...]
> | [...]
> `-- package_one
> |-- ChangeLog
> |-- Manifest
> |-- metadata.xml
> |-- package_one-0.4.ebuild
> `-- package_one-0.5.ebuild
Umm, why does package_two not exist in the other branch?
If package_one depends on package_two, and you're in for a world of fail
the moment it you changes branches here.
> > - Does NOT present a good base for anybody wanting to branch the entire
> > tree themselves.
> Scriptable.
You dropped my cvsserver list item.
--
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
[-- Attachment #2: Type: application/pgp-signature, Size: 330 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH 0/2] New 'stage' command
From: Jay Soffian @ 2009-04-05 20:55 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Junio C Hamano, git
In-Reply-To: <94a0d4530904051341s7e8718c2uced945a16c26670e@mail.gmail.com>
On Sun, Apr 5, 2009 at 4:41 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> == stage ==
>
> The word "stage" is used widely in the English language, and it
> immediately evokes a theatrical stage. Generally, it means a different
> (upper) level.
>
> In git it is barely used, mostly on the "documentation industry"
> probably because it's easier to understand for most people (even
> non-native-English speakers).
Would an index by any other name smell as sweet?
http://www.merriam-webster.com/dictionary/staging%20area
:-)
j.
^ permalink raw reply
* Re: [EGIT] [PATCH RFC v1 0/5] Add (static) ignore functionality to EGit
From: Shawn O. Pearce @ 2009-04-05 21:02 UTC (permalink / raw)
To: Ferry Huberts; +Cc: git, Robin Rosenberg
In-Reply-To: <cover.1238102327.git.ferry.huberts@pelagic.nl>
Ferry Huberts <ferry.huberts@pelagic.nl> wrote:
> This is the first - early - code that adds ignore functionality to EGit.
> Currently it reads in all ignore patterns upon workspace startup into an
> ignore cache. From this cache the ignore state of a resource is evaluated
> in the same fashion as git does.
>
> The code does not yet react to changes in ignore files but I'm planning to add
> that soon and I can share a lot of code for that.
>
> I send this code to receive feedback and to give you insight into what I'm
> doing with it. I'm new both to EGit programming and Eclipse programming so
> there might be things that could be done more elegantly :-)
Ok, I finally got a chance to review this series.
We really want as much of the Git specific logic as we can in JGit
under the BSD license. This has already been raised elsewhere in
this thread.
JGit and EGit are holding the line on Java 5 support; that means
that String.isEmpty() must be spelled as String.length() == 0
(isEmpty was added in Java 6).
Style nit: Don't put /* Constructors */, /* Methods */ or
/ * Public Methods */ comments in code, e.g.
IgnoreProjectCache l.52-54 or GitIgnoreData l.58-61.
Style nit: Don't assign fields to their default values.
E.g. Exclude.java l.25,33,42,.. these are being set to the
same value that the JRE sets the field to if the field is not
explicitly initialized. We find it much easier to read code when
the defaults are assumed.
Style nit: Don't use "this." to refer to members.
Your IDE should highlight field references differently than
parameters, and a parameter should never shadow a field name,
thus "this." is unnecessary and makes the code much more verbose
to read. E.g. see Exclude.java 's constructor on l.87-108; I can't
see the forest (the code) due to all the trees (this.) appearing.
IgnoreFileOutside: Ugh, our own implementation of IFile ?
I'm worried about the long-term stability of the IFile API.
Is it really frozen enough that we can implement it ourselves?
Of course, this may be moot if much of the code was moved back
to JGit.
IgnoreRepositoryCache: Why not put this into RepositoryMapping?
Instead of caching it inside a static HashMap of GitIgnoreData,
wouldn't it be better to put it into RepositoryMapping?
The TrackOperation for example already has the RepositoryMapping
handle in scope, saving a few lookup operations, and avoiding
needing to manage this new additional static HashMap against leaks.
I kind of wanted to tie exclude processing (and attribute processing)
into a TreeWalk, so that we can do an n-way merge against trees and
working directories by tossing all of their AbstractTreeIterators
into a single walk, possibly apply a path filter, and let the walk
handle the per-directory ignore rules as it goes.
Most of your code seems to be built around the Eclipse IResource
model, and the idea that it gets called for a single file path
at a time, which may make it less efficient when we put it into a
TreeWalk and apply the notion of entering and exiting a subdirectory.
OK, that's about all I have for now. Its reasonable, but still an
early series.
--
Shawn.
^ permalink raw reply
* Re: Performance issue: initial git clone causes massive repack
From: Shawn O. Pearce @ 2009-04-05 21:08 UTC (permalink / raw)
To: Robin H. Johnson; +Cc: Git Mailing List
In-Reply-To: <20090405204325.GA31344@curie-int>
"Robin H. Johnson" <robbat2@gentoo.org> wrote:
> > > The GSoC 2009 ideas contain a potential project for caching the
> > > generated packs, which, while having value in itself, could be partially
> > > avoided by sending suitable pre-built packs (if they exist) without any
> > > repacking.
> > Right. It could be an option to wait and see if the GSoC gives
> > something.
>
> How hard is it to just look at the git-upload-pack code and make it
> realize that it doesn't need to repack at all for this case.
I don't need to go look. I know that code.
Its harder than you think.
I'll tell you what, *you* go look at the git-upload-pack code and
come back with a patch that doesn't need to repack at all for this
case, *and* which Junio will actually apply. If its any good,
Junio would apply it pretty quickly.
Nobody else has managed to create such a patch just yet. Because its
extremely non-trivial. Its pretty much never the case that an active
repository is fully repacked, so we always have to enumerate some
number of loose objects and put them into a single outgoing pack
for the network. Its also considered to be a security feature of
Git that we only transmit reachable objects.
--
Shawn.
^ permalink raw reply
* [PATCH (GIT-GUI BUG)] git-gui: use of undeclared variable in handle_empty_diff
From: Joerg Bornemann @ 2009-04-05 20:20 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 381 bytes --]
Commit 584fa9cc ("git-gui: Avoid an infinite rescan loop in
handle_empty_diff.") introduced the global variable diff_empty_count, which
is used in diff.tcl. But this variable isn't declared anywhere which
results in an ugly error message box instead of the intended informative
message. This patch fixes this and removes the unnecessary second
initialization of current_diff_path.
[-- Attachment #2: diff.txt --]
[-- Type: text/plain, Size: 442 bytes --]
diff --git a/git-gui.sh b/git-gui.sh
index b3aa732..b0d5028 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -1104,10 +1104,10 @@ set commit_type {}
set empty_tree {}
set current_branch {}
set is_detached 0
-set current_diff_path {}
set is_3way_diff 0
set is_conflict_diff 0
set selected_commit_type new
+set diff_empty_count 0
set nullid "0000000000000000000000000000000000000000"
set nullid2 "0000000000000000000000000000000000000001"
^ permalink raw reply related
* Re: git-{diff,merge} refactor round 2
From: David Aguilar @ 2009-04-05 21:15 UTC (permalink / raw)
To: Junio C Hamano, Johannes.Schindelin
Cc: Markus Heidelberg, charles, git, msysgit
In-Reply-To: <7vzlevv3fy.fsf@gitster.siamese.dyndns.org>
On 0, Junio C Hamano <gitster@pobox.com> wrote:
> David Aguilar <davvid@gmail.com> writes:
>
> I'll try to queue all the outstanding da/difftool patches tonight, but I
> think the patches in the series are getting to the point of needing a
> fresh redoing. Patches like "oops, these non-user scripts should have
> been named with double-dash" can and should disappear.
>
> Currently they are:
>
> $ git log --oneline next..da/difftool
> 736e6b6 mergetool--lib: add new merge tool TortoiseMerge
> b3ef7cc mergetool--lib: make (g)vimdiff workable under Windows
> c4d690e mergetool--lib: consolidate the last redundant bits in {diff,merge}tool
> def88c8 mergetool-lib: specialize opendiff options when in diff mode
> bd52fab mergetool-lib: refactor run_mergetool and check_unchanged
> e87266c bash completion: add git-difftool
> 04c3b54 {diff,merge}tool: rename helpers to remove them from tab-completion
> 2a83022 mergetool-lib: add diffuse as merge and diff tool
> 73c59d9 mergetool-lib: specialize xxdiff options when in diff mode
> 273e7a2 mergetool-lib: specialize kdiff3 options when in diff mode
> 99511d8 mergetool: use run_mergetool from git-mergetool-lib
> 37c48c7 difftool: use run_mergetool from git-mergetool-lib
> 4e314b5 mergetool-lib: introduce run_mergetool
> 588954e difftool: use valid_tool from git-mergetool-lib
> 8af4556 mergetool: use valid_tool from git-mergetool-lib
> 72286b5 difftool: use get_mergetool_path from git-mergetool-lib
> d03b97f mergetool: use get_mergetool_path from git-mergetool-lib
> c6afc72 Add a mergetool-lib scriptlet for holding common merge tool functions
> 6108b75 mergetool: use $( ... ) instead of `backticks`
> 73786e2 difftool: add support for a difftool.prompt config variable
> 472ff62 difftool: add a -y shortcut for --no-prompt
> de2b85d difftool: use perl built-ins when testing for msys
> 9df990e difftool: add various git-difftool tests
> 8ac77f2 difftool: add git-difftool to the list of commands
It goes back even farther...
d3b8cec difftool: move 'git-difftool' out of contrib
d3db8cec is currently sitting in 'next' and is where the
"oops, I should have used double-dash" lack of foresight
began.
I like the *result* of what's currently sitting in
da/difftool, so rewriting history is easy now that we know
exactly where we're going.
I think we have a couple of options here. I won't be able to
get to it until sometime tonight, but I'll throw my plan out
here to get a feel for what's the better way to do it.
I think we have a couple of options. I'm open to any of
these:
1. Base it on the current master, completely throwing away
the existing da/difftool branch. That would include throwing
away the commit that's in next if we really want to be clean
about the history. In the process, move Markus' mergetool
fixes for windows to the top so that they can be applied
independently if necessary. This series would then depend
on them.
This would probably mean a merge conflict with next at some
point.
2. Base the series on next, keeping the 'move out of contrib'
patch intact. That'll minimize conflicts but will have an
extra commit that renames difftool-helper. I can still push
the fixes-for-windows patches up to the top so that it makes
it easier on msysgit since we already have those two patches
in the msysgit 'tortoisemerge' branch.
3. Any others?
Regardless of which it's based on, it's obvious that there'll
be some squashing going on. Tentatively,
Will be squashed:
588954e difftool: use valid_tool from git-mergetool-lib
8af4556 mergetool: use valid_tool from git-mergetool-lib
Will be squashed:
72286b5 difftool: use get_mergetool_path from git-mergetool-lib
d03b97f mergetool: use get_mergetool_path from git-mergetool-lib
c6afc72 Add a mergetool-lib scriptlet for holding common merge tool functions
Will be squashed:
99511d8 mergetool: use run_mergetool from git-mergetool-lib
37c48c7 difftool: use run_mergetool from git-mergetool-lib
4e314b5 mergetool-lib: introduce run_mergetool
Will be squashed:
def88c8 mergetool-lib: specialize opendiff options when in diff mode
73c59d9 mergetool-lib: specialize xxdiff options when in diff mode
273e7a2 mergetool-lib: specialize kdiff3 options when in diff mode
I'll go with whatever you guys think makes the series easiest to manage.
I think my preference would be to resend the entires series
based on 'master', but I don't want to make it any harder to
manage 'next'.
Thoughts?
--
David
^ permalink raw reply
* Re: [PATCH (GIT-GUI BUG)] git-gui: use of undeclared variable in handle_empty_diff
From: Sverre Rabbelier @ 2009-04-05 21:20 UTC (permalink / raw)
To: Joerg Bornemann; +Cc: git
In-Reply-To: <0337ff5648e5e0dc583e255a44573dbf@mb8-2.1blu.de>
Heya,
On Sun, Apr 5, 2009 at 22:20, Joerg Bornemann <git@jbornemann.de> wrote:
> Commit 584fa9cc ("git-gui: Avoid an infinite rescan loop in
Please submit your patch as documented by SubmittingPatches (e.g.,
include a "Signed off by" line, use the formatting as generated by
'git format-patch', inline the patch rather than attaching it, etc).
Thanks!
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [question] how can i verify whether a local branch is tracking a remote branch?
From: Paolo Ciarrocchi @ 2009-04-05 21:25 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20090405144413.GC2076@sigill.intra.peff.net>
On 4/5/09, Jeff King <peff@peff.net> wrote:
> On Sun, Apr 05, 2009 at 12:32:29PM +0200, Paolo Ciarrocchi wrote:
>
>> is there a way to verify, using the UI, whether a local branch is
>> tracking a remote branch?
>
> Do you mean "whether it is tracking any branch", or "whether the branch
> is is tracking is remote"?
I mean whether it is tracking a branch and if it is I want to know
which branch is being tracked.
> If the former, then I think if one of branch.$branch.{merge,rebase}
> is set, it is tracking something. The tracked thing is remote unless
> branch.$branch.remote is ".".
An example:
$ git clone -n URL temp
$ cd temp
$ git branch -r
origin/master
origin/foo
Origin/bar
$ git checkout --track -b foo origin/foo
Now, how can I know that foo is tracking origin/foo ?
Thanks.
Ciao,
--
Paolo
http://paolo.ciarrocchi.googlepages.com/
http://mypage.vodafone.it/
^ permalink raw reply
* Re: Performance issue: initial git clone causes massive repack
From: david @ 2009-04-05 21:28 UTC (permalink / raw)
To: Nicolas Sebrecht; +Cc: Robin H. Johnson, Git Mailing List
In-Reply-To: <20090405190213.GA12929@vidovic>
On Sun, 5 Apr 2009, Nicolas Sebrecht wrote:
> On Sun, Apr 05, 2009 at 12:04:12AM -0700, Robin H. Johnson wrote:
>
>> Before I answer the rest of your post, I'd like to note that the matter
>> of which choice between single-repo, repo-per-package, repo-per-category
>> has been flogged to death within Gentoo.
>>
>> I did not come to the Git mailing list to rehash those choices. I came
>> here to find a solution to the performance problem.
>
> I understand. I know two ways to resolve this:
> - by resolving the performance problem itself,
> - by changing the workflow to something more accurate and more suitable
> against the facts.
>
> My point is that going from a centralized to a decentralized SCM
> involves breacking strongly how developers and maintainers work. What
> you're currently suggesting is a way to work with Git in a centralized
> way. This sucks. To get the things right with Git I would avoid shared
> and global repositories. Gnome is doing it this way:
> http://gitorious.org/projects/gnome-svn-hooks/repos/mainline/trees/master
guys, back off a little on telling the gentoo people to change. the kernel
developers don't split th kernel into 'core' 'drivers' etc pieces just
because some people only work on one area. I see the gentoo desire to keep
things in one repo as being something very similar.
the problem here is a real one, if you have a large repo, git send-pack
will always generate a new pack, even if it doesn't need to (with the
extreme case being the the repo is fully packed)
>> The GSoC 2009 ideas contain a potential project for caching the
>> generated packs, which, while having value in itself, could be partially
>> avoided by sending suitable pre-built packs (if they exist) without any
>> repacking.
>
> Right. It could be an option to wait and see if the GSoC gives
> something.
the GSOC project is not the same thing. in this case the packs are already
'cached' (they are stored on disk), what is needed is some option to let
git send existing pack(s) if they exist rather then taking the time to
try and generate an 'optimal' pack.
I'm actually aurprised that this is happening, I thought that the
recommendation was that the public repository should do a very agressive
pack (that takes a lot of resources) for the old content so that people
cloning from it get the advantage of the tight packing without having to
do it themselves.
if the server _always_ re-generates the pack from scratch then this is a
waste of time (except for people who clone via the dumb, unsafe
mechanisms)
David Lang
^ permalink raw reply
* Re: [PATCH (GIT-GUI BUG)] git-gui: use of undeclared variable in handle_empty_diff
From: Johannes Schindelin @ 2009-04-05 21:35 UTC (permalink / raw)
To: Joerg Bornemann; +Cc: git
In-Reply-To: <0337ff5648e5e0dc583e255a44573dbf@mb8-2.1blu.de>
Hi,
On Sun, 5 Apr 2009, Joerg Bornemann wrote:
> Commit 584fa9cc ("git-gui: Avoid an infinite rescan loop in
> handle_empty_diff.") introduced the global variable diff_empty_count,
> which is used in diff.tcl. But this variable isn't declared anywhere
> which results in an ugly error message box instead of the intended
> informative message. This patch fixes this and removes the unnecessary
> second initialization of current_diff_path.
Under which circumstances does this bug trigger? I never saw it happen.
Ciao,
Dscho
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox