* Re: Improving merge failure message
From: Nanako Shiraishi @ 2009-09-08 10:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7veiqhgb4y.fsf@alter.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>
> Notable points are:
>
> - End the messages with "Aborting."; they are given when the three-way
> merge stops without harming the work tree;
>
> - Do not give the extra message after unpack_trees() already errored out.
> This "merging of trees failed" message was primarily for debugging
> merge-recursive itself, and the end user cannot do much with the object
> names given in the message anyway.
>
> But do give it under higher verbosity level, or when it happens during
> the inner merge (the "recursive" one), as unpack_trees() should not
> fail for the inner merge under normal conditions.
>
> We could later add instructions on how to recover (i.e. "stash changes
> away or commit on a side branch and retry") instead of the silent
> exit(128) I have down there, and then use Peff's advice.* mechanism to
> squelch it (e.g. "advice.mergeindirtytree"), but they are separate topics.
Thank you for a quick response. The patch works fine here, so if you want
please add:
Tested-by: Nanako Shiraishi <nanako3@lavabit.com>
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* [ANNOUNCE] GitX v0.7 released
From: Johannes Gilger @ 2009-09-08 9:38 UTC (permalink / raw)
To: Git Mailing List
Hello git-community,
most of you will already have noticed it (through the builtin
update-functionality) but I'd thought I make a quick announcement here
as well: GitX 0.7, a git-GUI for Mac OS X, was released yesterday.
To see what's changed have a look at the Release History [1]. I also
wrote up a blog-post [2] describing the most obvious changes with
screenshots. If you're a GitX-user, consider taking our short survey [3]
which we set up for the release of 0.7.
If you're thinking about contributing to GitX have a look at our fairly
new mailinglist [4], which is supposed to become the main means of
coordination for us. We have a few big features that have been requested
by users time and again, so it would be a perfect chance to make a big
impression on a relatively young and small open-source project.
Thanks to the git-community for providing us with broad and steady
shoulders to stand on ;)
Greetings,
Jojo
[1] - http://gitx.frim.nl/release_history.html
[2] - http://heipei.net/2009/09/07/gitx-0-7-released/
[3] - http://www.survs.com/survey?id=DCJKLP2B&channel=Q065KU8XL1
[4] - http://groups.google.com/group/gitx
--
Johannes Gilger <heipei@hackvalue.de>
http://heipei.net
GPG-Key: 0x42F6DE81
GPG-Fingerprint: BB49 F967 775E BB52 3A81 882C 58EE B178 42F6 DE81
^ permalink raw reply
* Re: Gitweb linking to bug-tracking system
From: Arnaud Bailly @ 2009-09-08 12:12 UTC (permalink / raw)
To: git
In-Reply-To: <81b0412b0909080222u58c7e0bey81a5b127b04d6031@mail.gmail.com>
Thanks.
--
Arnaud Bailly -- OQube
<software engineering>
http://www.oqube.com/
^ permalink raw reply
* Re: [PATCHv5 00/14] git notes
From: Johan Herland @ 2009-09-08 12:36 UTC (permalink / raw)
To: Johannes Schindelin
Cc: git, Junio C Hamano, trast, tavestbo, git, chriscool, spearce
In-Reply-To: <alpine.DEB.1.00.0909081100020.4330@intel-tinevez-2-302>
Hi,
On Tuesday 08 September 2009, Johannes Schindelin wrote:
> On Tue, 8 Sep 2009, Johan Herland wrote:
> > Algorithm / Notes tree git log -n10 (x100) git log --all
> > ------------------------------------------------------------
> > next / no-notes 4.77s 63.84s
> >
> > before / no-notes 4.78s 63.90s
> > before / no-fanout 56.85s 65.69s
> >
> > 16tree / no-notes 4.77s 64.18s
> > 16tree / no-fanout 30.35s 65.39s
> > 16tree / 2_38 5.57s 65.42s
> > 16tree / 2_2_36 5.19s 65.76s
> >
> > flexible / no-notes 4.78s 63.91s
> > flexible / no-fanout 30.34s 65.57s
> > flexible / 2_38 5.57s 65.46s
> > flexible / 2_2_36 5.18s 65.72s
> > flexible / ym 5.13s 65.66s
> > flexible / ym_2_38 5.08s 65.63s
> > flexible / ymd 5.30s 65.45s
> > flexible / ymd_2_38 5.29s 65.90s
> > flexible / y_m 5.11s 65.72s
> > flexible / y_m_2_38 5.08s 65.67s
> > flexible / y_m_d 5.06s 65.50s
> > flexible / y_m_d_2_38 5.07s 65.79s
>
> It's good to see that the no-notes behaves roughly like baseline.
Agreed.
> I can see that some people may think that date-based fan-out is the
> cat's ass, but I have to warn that we have no idea how notes will be
> used,
I don't agree. Although we will certainly see many more use cases for
notes, I believe that the vast majority of them can be placed in one of
two categories:
1. Looking up a few (1 - 10) notes on an individual basis. In this case,
performance will always be "good enough", and I don't believe it's
worth spending much time optimizing for this case.
2. Looking up many notes in a sequence based on the chronology of the
objects (commits) they annotate. This is what 'git log' does, and I
believe this is the case we should optimize for.
Once you work from this assumption, it is clear that date-based fanout
beats pure SHA1-based fanout, because it changes the notes lookup
process from random-access to near-streaming. This is clearly reflected
in the memory usage graphs I posted.
Also note that the "flexible" code to some degree resolves the whole
date-based fanout vs. SHA1-based fanout discussion: We are now free to
choose -- at runtime -- which notes tree structure is more optimal for
a given collection of notes.
> and the date-based fan-out is rather limiting in certain respects:
>
> - for the typical nightly-build-generated notes, this fan-out is
> pretty inefficient memory-wise.
Yes and no. A y/m/d/40 structure with 1 note for every y/m/d is indeed
wasteful, but using a y/40 structure instead creates a much better
situation with a "healthy" ~365 notes per year level. And the y/40
still preserves some of the 'streaming' aspects mentioned above.
> - I find the restriction to commits rather limiting.
I see your point, but I don't agree until I see a compelling case for
annotating a non-commit.
In any case, the flexible lookup code still allow us to organize notes
purely by SHA1-based fanout, so annotated trees/blobs could still be
supported by the same code (modulo a small s/struct commit/struct
object/ patch) provided that they are stored in a notes tree that
simply does not use date-based fanout.
> - most of the performance difference between the date-based and the
> SHA-1 based fan-out looks to me as if the issue was the top-level
> tree. Basically, this tree has to be read _every_ time _anybody_
> wants to read a note.
Not sure what you're trying to say here. The top-level notes tree is
read (as in fill_tree_descriptor()) exactly _once_. After that, it is
cached by the internal data structure (until free_commit_notes() or
end-of-process).
In the SHA1-based case, each notes lookup does indeed start at the root
of the data structure (corresponding to the top-level tree), but in the
date-based case, we keep a pointer (cur_node) to the innermost
date-based tree that was most recently used. Thus, if the next note is
within the same date-based tree (which I assume is the common case),
then we don't need to look at the root of the data structure.
> Maybe a finer-grained fan-out (finer than 16-bits) could help.
> After all, if you have 16 different notes, chances are that they have
> 16 different first letters, but all have the same commit year.
> That's where the top-level notes with a fan-out perform incredibly
> bad.
Not really, the first lookup would start at the root node, and navigate
into the year node, but all subsequent lookups would start directly at
the year node (and only backtrack if the commit year doesn't match the
year node).
BTW, when you mention "finer than 16-bits", do you mean moving from a
16-tree to a, say, 32-tree or 64-tree structure? That will complicate
the tree navigation somewhat, and increase memory waste. (Remember, I
started out with a 256-tree idea, but scrapped it because of memory
waste).
> But I think that having a dynamic fan-out that can even put blobs
> into the top-level tree (nothing prevents us from doing that, right?)
Well, the "flexible" code does add the new requirement that all entries
in a notes (sub)tree object must follow the same scheme, i.e. you
cannot have:
/12/34567890123456789012345678901234567890
/2345/678901234567890123456789012345678901
but you can have
/12/34567890123456789012345678901234567890
/23/45/678901234567890123456789012345678901
> would _outperform_ the date-based one, at least with less than 1
> note/commit (and maybe even then, because the year-based fan-out
> results in pretty varying entropies per fan-out depth).
>
> The real question for me, therefore, is: what is the optimal way to
> strike the balance between size of the tree objects (which we want
> to be small, so that unpacking them is fast) and depth of the
> fan-out (which we want to be shallow to avoid reading worst-case 39
> tree objects to get at one single note).
s/39/19/ (each fanout must use at least 2 chars of the 40-char SHA1)
Yes, the challenge is indeed striking the correct balance. I believe
that the notes code should be taught to write (and automatically
re-organize) the notes tree so that it is optimized for the current
collection of notes.
> - related to the previous point is my gut feeling that the date-based
> fan-out has nothing to do with any theoretical optimum. I am
> pretty certain that the optimal fan-out strategy depends heavily on
> the SHA-1s of the annotated objects (if you have 10,000 notes in
> 2009, but only 1 in 2008, the year-based fan-out _must_ be
> suboptimal) and maybe is something like a sibling to the Fibonacci
> heap.
Yes, it is trivial to create scenarios where any rigid date-based fanout
is suboptimal. However, it is equally trivial to create scenarios where
any SHA1-based fanout will perform worse than a carefully chosen
date-based fanout. I believe the best way forward is to design for
flexibility in the notes tree structure, and then teach the notes
_writing_ code to choose a notes tree structure that is good/optimal
for the given set of notes.
> - I'd love to see performance numbers for less than 157118 notes.
> Don't get me wrong, it is good to see the worst-case scenario in
> terms of notes/commits ratio. But it will hardly be the common case,
> and I very much would like to optimize for the common case.
>
> So, I'd appreciate if you could do the tests with something like
> 500 notes, randomly spread over the commits (rationale: my original
> understanding was that the notes could amend commit messages, and
> that is much more likely to be done with relatively old commits that
> you cannot change anymore).
Ok. I will try to test that.
> Please understand that I might not have the time to participate in
> this thread as much as I would like to. The next 4 days will be
> especially hard.
Thanks for the feedback! I appreciate any time you're able to spend on
this. And I don't mind waiting for a few days for more feedback.
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: Issue 323 in msysgit: Can't clone over http
From: Jakub Narebski @ 2009-09-08 12:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Tay Ray Chuan, git, msysgit, Tom Preston-Werner
In-Reply-To: <7v7hwatw0v.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Tay Ray Chuan <rctay89@gmail.com> writes:
>
> > Just to clarify: the "check" of CURLE_OK in http-walker.c::fetch_index()
> > in v1.6.3 is fundamentally different from the check we have in 48188c2
> > (http-walker: verify remote packs, 2009-06-06).
> >
> > The first "check" is a full-blooded GET request, and we do get back
> > actual data (in this case, the pack index file). The second check isn't
> > a GET request, just an inconsequential HEAD request; we don't get back
> > any real data.
>
> Yeah, I realized after I wrote the message you are responding to and ran
> some experiments with github repository myself to see for some of their
> URLs HEAD gives 500 when GET gives the contents just fine.
>
> Tom, sorry to have given a confusing list of issues in my earlier message.
> Please disregard it. The only funny your HTTP server folks may want to
> look into is that GET request to fetch the following URL gives the
> contents just fine, but HEAD request to it results in an Internal Server
> Error.
>
> http://github.com/tekkub/addontemplate.git/objects/pack/pack-382c25c935b744e909c749532578112d72a4aff9.pack
>
> Sorry about the confusion.
[...]
> On the other hand, if a HEAD request to a URL results in an unauthorized,
> what plausible excuse the server operator could give for allowing a GET
> request to the same URL? If we are going to keep the check if *.pack that
> corresponds to the *.idx will be available, shouldn't we trust whatever
> check we perform?
500 Internal Server Error doesn't look right (well, it can indicate
bug in server code), but would git respond to correct error code other
than 404 Not Found, like 405 Method Not Allowed, or 501 Not Implemented?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Issue 323 in msysgit: Can't clone over http
From: Tay Ray Chuan @ 2009-09-08 13:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, msysgit, Tom Preston-Werner
In-Reply-To: <7v7hwatw0v.fsf@alter.siamese.dyndns.org>
Hi,
On Tue, Sep 8, 2009 at 3:06 AM, Junio C Hamano<gitster@pobox.com> wrote:
> I am torn about this.
>
> On one hand, if we are going to treat such a half failure as nothing
> conclusive, I do not see a point to keep that check to begin with.
>
> On the other hand, if a HEAD request to a URL results in an unauthorized,
> what plausible excuse the server operator could give for allowing a GET
> request to the same URL? If we are going to keep the check if *.pack that
> corresponds to the *.idx will be available, shouldn't we trust whatever
> check we perform?
I am in favour or removing this check, not just due to its
unreliability, but for the sake of consistency (we very rarely send a
HEAD request to poll data before doing a GET).
Do disregard the patch included earlier, if you haven't already done so.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2009, #02; Mon, 07)
From: Jakub Narebski @ 2009-09-08 13:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtyzexnhm.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> * jn/gitweb-show-size (2009-09-07) 1 commit
> - gitweb: Add 'show-sizes' feature to show blob sizes in tree view
This is an RFC, because of a) feature naming, and b) tests.
It does work correctly, though.
> * jn/gitweb-blame (2009-09-01) 5 commits
> - gitweb: Minify gitweb.js if JSMIN is defined
> - gitweb: Create links leading to 'blame_incremental' using JavaScript
> (merged to 'next' on 2009-09-07 at 3622199)
I plan on reverting the order of those two patches, as JSMIN patch is
more ready than 'blame_incremental' linking.
With JSMIN there is perhaps question of documenting it, and whether
git-instaweb.sh should use minified JavaScript or not (curently it
does not). With 'blame_incremental' linking there are quite a few
issues:
1. When to do JavaScript detection
a. on load (current solution)
b. on click (via event handler)
2. How to invoke actions requiring JavaScript
a. add 'js=1' parameter (perhaps limiting URLs, as not to
add it e.g. to http://git-scm.com/ $home_link)
b. rewrite action parameter, e.g. from 'blame' to
'blame_incremental' (troubles with path_info URLs)
c. use cookies
Current solution works, but I think is suboptimal.
> + gitweb: Colorize 'blame_incremental' view during processing
> + gitweb: Incremental blame (using JavaScript)
> + gitweb: Add optional "time to generate page" info in footer
>
> Ajax-y blame.
I'd very much like for others to check if it works with other browsers
(Internet Explorer 6, 7, 8; Opera 9, 10; Safari; Firefox 2, 3, 3.5)
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2009, #02; Mon, 07)
From: Sverre Rabbelier @ 2009-09-08 13:17 UTC (permalink / raw)
To: Shawn O. Pearce, Junio C Hamano; +Cc: git
In-Reply-To: <7vtyzexnhm.fsf@alter.siamese.dyndns.org>
Heya,
On Tue, Sep 8, 2009 at 02:56, Junio C Hamano<gitster@pobox.com> wrote:
> * sr/gfi-options (2009-09-06) 6 commits
> (merged to 'next' on 2009-09-07 at 5f6b0ff)
> + fast-import: test the new option command
> + fast-import: add option command
> + fast-import: test the new feature command
> + fast-import: add feature command
> + fast-import: put marks reading in it's own function
> + fast-import: put option parsing code in separate functions
>
> Perhaps 1.6.5 material but I wasn't sure.
Shawn, what's your opinion of v7? I think it handles pretty much
everything we need for at least a draft and is good for 1.6.5, but
it's up to you of course :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Issue 323 in msysgit: Can't clone over http
From: Tay Ray Chuan @ 2009-09-08 13:18 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git, msysgit, Tom Preston-Werner
In-Reply-To: <m3ocplvbmj.fsf@localhost.localdomain>
Hi,
On Tue, Sep 8, 2009 at 8:57 PM, Jakub Narebski<jnareb@gmail.com> wrote:
> 500 Internal Server Error doesn't look right (well, it can indicate
> bug in server code), but would git respond to correct error code other
> than 404 Not Found, like 405 Method Not Allowed, or 501 Not Implemented?
I believe you're referring to git response to such error codes for GET requests?
For 404, we'll try using alternates (objects/info/http-alternates,
objects/info/alternates).
For the rest, we'll just abort the request. I'm not really sure of the
specific responses by git, like if we do ask for authentication, in
the case of 401s.
--
Cheers,
Ray Chuan
^ permalink raw reply
* [PATCH] Makefile: Add NEEDS_CRYPTO_WITH_SSL
From: Brian Gernhardt @ 2009-09-08 13:54 UTC (permalink / raw)
To: Git List; +Cc: Junio C Hamano
The Makefile comment for NEEDS_SSL_WITH_CRYPTO says to define it "if
you need -lcrypto with -lssl (Darwin)." However, what it actually
does is add -lssl when you use -lcrypto and not the other way around.
However, libcrypto contains a majority of the ERR_* functions from
OpenSSL (at least on OS X) so we need it both ways.
So, add NEEDS_CRYPTO_WITH_SSL which adds -lcrypto to the OpenSSL link
flags and clarify the difference between it and NEEDS_SSL_WITH_CRYPTO.
Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com>
---
Compilation using BLK_SHA1 on OS X 10.5 and 10.6 (at least) is still
broken without this patch.
Alex Riesen <raa.lkml@gmail.com> pointed out that just adding LIB_4_CRYPTO
to git-imap-send is simpler, but judging from the fact that nobody else
has complained about this issue, I'm guessing that the need for -lcrypto
when using -lssl is not widespread. (Or BLK_SHA1 isn't getting used much
or those who do don't compile git-imap-send with SSL.)
Makefile | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index ce882d0..121be04 100644
--- a/Makefile
+++ b/Makefile
@@ -91,7 +91,9 @@ all::
# Define PPC_SHA1 environment variable when running make to make use of
# a bundled SHA1 routine optimized for PowerPC.
#
-# Define NEEDS_SSL_WITH_CRYPTO if you need -lcrypto with -lssl (Darwin).
+# Define NEEDS_CRYPTO_WITH_SSL if you need -lcrypto when using -lssl (Darwin).
+#
+# Define NEEDS_SSL_WITH_CRYPTO if you need -lssl when using -lcrypto (Darwin).
#
# Define NEEDS_LIBICONV if linking with libc is not enough (Darwin).
#
@@ -707,6 +709,7 @@ ifeq ($(uname_S),SCO_SV)
TAR = gtar
endif
ifeq ($(uname_S),Darwin)
+ NEEDS_CRYPTO_WITH_SSL = YesPlease
NEEDS_SSL_WITH_CRYPTO = YesPlease
NEEDS_LIBICONV = YesPlease
ifeq ($(shell expr "$(uname_R)" : '[15678]\.'),2)
@@ -1009,6 +1012,9 @@ ifndef NO_OPENSSL
else
OPENSSL_LINK =
endif
+ ifdef NEEDS_CRYPTO_WITH_SSL
+ OPENSSL_LINK += -lcrypto
+ endif
else
BASIC_CFLAGS += -DNO_OPENSSL
BLK_SHA1 = 1
--
1.6.4.2.420.g30ecf
^ permalink raw reply related
* Re: [PATCH] Add more instructions about how to install git.
From: Thiago Farina @ 2009-09-08 14:24 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Alex Riesen, git
In-Reply-To: <vpqhbvekldk.fsf@bauges.imag.fr>
On Tue, Sep 8, 2009 at 3:20 AM, Matthieu
Moy<Matthieu.Moy@grenoble-inp.fr> wrote:
> Your commit message doesn't say what's wrong with
>
> | Alternatively you can use autoconf generated ./configure script to
> | set up install paths (via config.mak.autogen), so you can write
> | instead
> |
> | $ make configure ;# as yourself
> | $ ./configure --prefix=/usr ;# as yourself
> | $ make all doc ;# as yourself
> | # make install install-doc install-html;# as root
>
> which is already in INSTALL a few lines after what your patch adds.
I tried to being more explicit about what the new users has to do. The
first instruction that the text says is: "Normaly you can just do
"make"".
But the new user, cloning git won't have a configure file, so he can't
just do "make".
And then, the text says: "so you can write instead". This brings me to
one alternative (not what I really should do), when in fact it should
be (I guess) the first instructions that new users need to follow.
^ permalink raw reply
* Re: [PATCH] Add more instructions about how to install git.
From: Erik Faye-Lund @ 2009-09-08 14:37 UTC (permalink / raw)
To: Thiago Farina; +Cc: Matthieu Moy, Alex Riesen, git
In-Reply-To: <a4c8a6d00909080724q1c792f6bs641ea9d000d08b5a@mail.gmail.com>
On Tue, Sep 8, 2009 at 4:24 PM, Thiago Farina<tfransosi@gmail.com> wrote:
> I tried to being more explicit about what the new users has to do. The
> first instruction that the text says is: "Normaly you can just do
> "make"".
> But the new user, cloning git won't have a configure file, so he can't
> just do "make".
I think you are confused. There's a default Makefile there, so a
normal user CAN just call "make". What a new user can't do, is to call
"./configure" without generating the configure-script first. There are
already instructions on how to do this.
--
Erik "kusma" Faye-Lund
kusmabite@gmail.com
(+47) 986 59 656
^ permalink raw reply
* Re: [PATCH] Add more instructions about how to install git.
From: Johannes Sixt @ 2009-09-08 14:38 UTC (permalink / raw)
To: Thiago Farina; +Cc: Matthieu Moy, Alex Riesen, git
In-Reply-To: <a4c8a6d00909080724q1c792f6bs641ea9d000d08b5a@mail.gmail.com>
Thiago Farina schrieb:
> I tried to being more explicit about what the new users has to do. The
> first instruction that the text says is: "Normaly you can just do
> "make"".
> But the new user, cloning git won't have a configure file, so he can't
> just do "make".
>
> And then, the text says: "so you can write instead". This brings me to
> one alternative (not what I really should do), when in fact it should
> be (I guess) the first instructions that new users need to follow.
Then guessed wrong. You really only have to say "make". The use of
autoconf and ./configure is purely optional and not necessary.
-- Hannes
^ permalink raw reply
* Re: [PATCH] Add more instructions about how to install git.
From: Thiago Farina @ 2009-09-08 14:52 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Matthieu Moy, Alex Riesen, git
In-Reply-To: <4AA66C54.4060101@viscovery.net>
On Tue, Sep 8, 2009 at 10:38 AM, Johannes Sixt<j.sixt@viscovery.net> wrote:
> Thiago Farina schrieb:
>> I tried to being more explicit about what the new users has to do. The
>> first instruction that the text says is: "Normaly you can just do
>> "make"".
>> But the new user, cloning git won't have a configure file, so he can't
>> just do "make".
>>
>> And then, the text says: "so you can write instead". This brings me to
>> one alternative (not what I really should do), when in fact it should
>> be (I guess) the first instructions that new users need to follow.
>
> Then guessed wrong. You really only have to say "make". The use of
> autoconf and ./configure is purely optional and not necessary.
I don't think so.
Running only "make".
$ make
GIT_VERSION = 1.6.5.rc0
* new build flags or prefix
CC fast-import.o
In file included from builtin.h:4,
from fast-import.c:143:
git-compat-util.h:129:25: error: openssl/ssl.h: No such file or directory
git-compat-util.h:130:25: error: openssl/err.h: No such file or directory
In file included from builtin.h:6,
from fast-import.c:143:
cache.h:8:21: error: openssl/sha.h: No such file or directory
In file included from fast-import.c:152:
csum-file.h:10: error: expected specifier-qualifier-list before ‘SHA_CTX’
fast-import.c: In function ‘create_index’:
fast-import.c:850: error: ‘SHA_CTX’ undeclared (first use in this function)
fast-import.c:850: error: (Each undeclared identifier is reported only once
fast-import.c:850: error: for each function it appears in.)
fast-import.c:850: error: expected ‘;’ before ‘ctx’
fast-import.c:886: warning: implicit declaration of function ‘SHA1_Init’
fast-import.c:886: error: ‘ctx’ undeclared (first use in this function)
fast-import.c:891: warning: implicit declaration of function ‘SHA1_Update’
fast-import.c:896: warning: implicit declaration of function ‘SHA1_Final’
fast-import.c: In function ‘store_object’:
fast-import.c:1035: error: ‘SHA_CTX’ undeclared (first use in this function)
fast-import.c:1035: error: expected ‘;’ before ‘c’
fast-import.c:1040: error: ‘c’ undeclared (first use in this function)
fast-import.c: In function ‘validate_raw_date’:
fast-import.c:1750: warning: ignoring return value of ‘strtoul’,
declared with attribute warn_unused_result
fast-import.c:1758: warning: ignoring return value of ‘strtoul’,
declared with attribute warn_unused_result
make: *** [fast-import.o] Error 1
Running configure and then make
$ make configure
GIT_VERSION = 1.6.5.rc0.dirty
GEN configure
$ make
CC fast-import.o
In file included from builtin.h:4,
from fast-import.c:143:
git-compat-util.h:129:25: error: openssl/ssl.h: No such file or directory
git-compat-util.h:130:25: error: openssl/err.h: No such file or directory
In file included from builtin.h:6,
from fast-import.c:143:
cache.h:8:21: error: openssl/sha.h: No such file or directory
In file included from fast-import.c:152:
csum-file.h:10: error: expected specifier-qualifier-list before ‘SHA_CTX’
fast-import.c: In function ‘create_index’:
fast-import.c:850: error: ‘SHA_CTX’ undeclared (first use in this function)
fast-import.c:850: error: (Each undeclared identifier is reported only once
fast-import.c:850: error: for each function it appears in.)
fast-import.c:850: error: expected ‘;’ before ‘ctx’
fast-import.c:886: warning: implicit declaration of function ‘SHA1_Init’
fast-import.c:886: error: ‘ctx’ undeclared (first use in this function)
fast-import.c:891: warning: implicit declaration of function ‘SHA1_Update’
fast-import.c:896: warning: implicit declaration of function ‘SHA1_Final’
fast-import.c: In function ‘store_object’:
fast-import.c:1035: error: ‘SHA_CTX’ undeclared (first use in this function)
fast-import.c:1035: error: expected ‘;’ before ‘c’
fast-import.c:1040: error: ‘c’ undeclared (first use in this function)
fast-import.c: In function ‘validate_raw_date’:
fast-import.c:1750: warning: ignoring return value of ‘strtoul’,
declared with attribute warn_unused_result
fast-import.c:1758: warning: ignoring return value of ‘strtoul’,
declared with attribute warn_unused_result
make: *** [fast-import.o] Error 1
Now autconf, ./configure, make.
$ autoconf
$ ./configure
configure: Setting lib to 'lib' (the default)
configure: Will try -pthread then -lpthread to enable POSIX Threads.
configure: CHECKS for site configuration
configure: CHECKS for programs
checking for cc... cc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether cc accepts -g... yes
checking for cc option to accept ISO C89... none needed
checking if linker supports -R... no
checking if linker supports -Wl,-rpath,... yes
checking for gar... no
checking for ar... ar
checking for gtar... no
checking for tar... tar
checking for asciidoc... asciidoc
checking for asciidoc version... asciidoc 8.2.7 > 7
configure: CHECKS for libraries
checking for SHA1_Init in -lcrypto... no
checking for SHA1_Init in -lssl... no
checking for curl_global_init in -lcurl... yes
checking for XML_ParserCreate in -lexpat... yes
checking for iconv in -lc... yes
checking for deflateBound in -lz... yes
checking for socket in -lc... yes
checking for hstrerror in -lc... yes
checking for basename in -lc... yes
configure: CHECKS for header files
checking how to run the C preprocessor... cc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking sys/select.h usability... yes
checking sys/select.h presence... yes
checking for sys/select.h... yes
checking for old iconv()... no
configure: CHECKS for typedefs, structures, and compiler characteristics
checking for struct dirent.d_ino... yes
checking for struct dirent.d_type... yes
checking for struct sockaddr_storage... yes
checking for struct addrinfo... yes
checking for getaddrinfo... yes
checking for library containing getaddrinfo... none required
checking whether formatted IO functions support C99 size specifiers... yes
checking whether system succeeds to read fopen'ed directory... no
checking whether snprintf() and/or vsnprintf() return bogus value... no
configure: CHECKS for library functions
checking libgen.h usability... yes
checking libgen.h presence... yes
checking for libgen.h... yes
checking for strcasestr... yes
checking for library containing strcasestr... none required
checking for memmem... yes
checking for library containing memmem... none required
checking for strlcpy... no
checking for uintmax_t... yes
checking for strtoumax... yes
checking for library containing strtoumax... none required
checking for setenv... yes
checking for library containing setenv... none required
checking for unsetenv... yes
checking for library containing unsetenv... none required
checking for mkdtemp... yes
checking for library containing mkdtemp... none required
checking for mkstemps... no
checking Checking for POSIX Threads with '-pthread'... yes
configure: creating ./config.status
config.status: error: cannot find input file: config.mak.in
$ make
Now it compiles everything.
^ permalink raw reply
* Re: [PATCH] Add more instructions about how to install git.
From: Mikael Magnusson @ 2009-09-08 14:56 UTC (permalink / raw)
To: Thiago Farina; +Cc: Johannes Sixt, Matthieu Moy, Alex Riesen, git
In-Reply-To: <a4c8a6d00909080752p5b663fc8r8bf1c60023ef39b4@mail.gmail.com>
2009/9/8 Thiago Farina <tfransosi@gmail.com>:
> On Tue, Sep 8, 2009 at 10:38 AM, Johannes Sixt<j.sixt@viscovery.net> wrote:
>> Thiago Farina schrieb:
>>> I tried to being more explicit about what the new users has to do. The
>>> first instruction that the text says is: "Normaly you can just do
>>> "make"".
>>> But the new user, cloning git won't have a configure file, so he can't
>>> just do "make".
>>>
>>> And then, the text says: "so you can write instead". This brings me to
>>> one alternative (not what I really should do), when in fact it should
>>> be (I guess) the first instructions that new users need to follow.
>>
>> Then guessed wrong. You really only have to say "make". The use of
>> autoconf and ./configure is purely optional and not necessary.
> I don't think so.
> Running only "make".
> $ make
> GIT_VERSION = 1.6.5.rc0
> * new build flags or prefix
> CC fast-import.o
> In file included from builtin.h:4,
> from fast-import.c:143:
> git-compat-util.h:129:25: error: openssl/ssl.h: No such file or directory
> git-compat-util.h:130:25: error: openssl/err.h: No such file or directory
[snip]
You need to edit the Makefile if your system needs tweaks, there are tons
of comments.
> Running configure and then make
> $ make configure
> GIT_VERSION = 1.6.5.rc0.dirty
> GEN configure
> $ make
> CC fast-import.o
> In file included from builtin.h:4,
> from fast-import.c:143:
> git-compat-util.h:129:25: error: openssl/ssl.h: No such file or directory
> git-compat-util.h:130:25: error: openssl/err.h: No such file or directory
You forgot to run configure.
> Now autconf, ./configure, make.
> $ autoconf
> $ ./configure
> configure: Setting lib to 'lib' (the default)
> configure: Will try -pthread then -lpthread to enable POSIX Threads.
> configure: CHECKS for site configuration
> configure: CHECKS for programs
[...]
> checking for mkstemps... no
> checking Checking for POSIX Threads with '-pthread'... yes
> configure: creating ./config.status
> config.status: error: cannot find input file: config.mak.in
> $ make
>
> Now it compiles everything.
--
Mikael Magnusson
^ permalink raw reply
* Re: [PATCH] Add more instructions about how to install git.
From: Brian Gernhardt @ 2009-09-08 15:19 UTC (permalink / raw)
To: Thiago Farina; +Cc: Johannes Sixt, Matthieu Moy, Alex Riesen, git
In-Reply-To: <a4c8a6d00909080752p5b663fc8r8bf1c60023ef39b4@mail.gmail.com>
On Sep 8, 2009, at 10:52 AM, Thiago Farina wrote:
> On Tue, Sep 8, 2009 at 10:38 AM, Johannes Sixt<j.sixt@viscovery.net>
> wrote:
>> Then guessed wrong. You really only have to say "make". The use of
>> autoconf and ./configure is purely optional and not necessary.
> I don't think so.
> Running only "make".
> $ make
> GIT_VERSION = 1.6.5.rc0
> * new build flags or prefix
> CC fast-import.o
> In file included from builtin.h:4,
> from fast-import.c:143:
> git-compat-util.h:129:25: error: openssl/ssl.h: No such file or
> directory
> git-compat-util.h:130:25: error: openssl/err.h: No such file or
> directory
You don't have OpenSSL, a perquisite mentioned in the INSTALL file at
line 55. You can do the following:
make NO_OPENSSL=Yes
or save the option so you don't have to retype it each time:
echo "NO_OPENSSL=Yes" > config.mak
make
Or install OpenSSL or run the autoconf.
The Makefile tries it's best to be as smart as possible without being
a configure script of it's own (see ll. 656-925), and it's highly
commented at the beginning so that only a minimal knowledge of make is
required (ll. 4-198). I suppose we could note that the defines
should be put in a config.mak file.
> Running configure and then make
> $ make configure
> GIT_VERSION = 1.6.5.rc0.dirty
> GEN configure
$ ./configure
[lots of output]
> $ make
> CC fast-import.o
As pointed out before, you forgot to run the generated configure
script (as already documented at Makefile:20).
However, it's generally considered preferable to hand-create a
config.mak for the few options you need on a regular basis and let the
Makefile do it's work. The autoconf files occasionally lag behind the
rest of development as they're not widely used by git developers
(AFAICT).
I'd personally argue that we should point out in INSTALL that git can
be configured via a hand-written config.mak using the defines
described at the top of the Makefile before we talk about using
autoconf. (Perhaps with quick notes about the most commonly used
defines.)
For example, my config.mak contains:
prefix=/usr/local
ASCIIDOC8=Yes
MAN_BOLD_LITERAL=Yes
BLK_SHA1=Yes
The rest of the configuration for my OS (OS X/Darwin, specifically)
are handled by the Makefile.
~~ Brian
^ permalink raw reply
* Re: [PATCHv5 00/14] git notes
From: Johannes Schindelin @ 2009-09-08 15:53 UTC (permalink / raw)
To: Johan Herland
Cc: git, Junio C Hamano, trast, tavestbo, git, chriscool, spearce
In-Reply-To: <200909081436.30761.johan@herland.net>
Hi,
On Tue, 8 Sep 2009, Johan Herland wrote:
> On Tuesday 08 September 2009, Johannes Schindelin wrote:
> > I can see that some people may think that date-based fan-out is the
> > cat's ass, but I have to warn that we have no idea how notes will be
> > used,
>
> I don't agree. Although we will certainly see many more use cases for
> notes, I believe that the vast majority of them can be placed in one of
> two categories:
My experience with Git is that having beliefs how my work is used was a
constant source of surprise.
> > - I find the restriction to commits rather limiting.
>
> I see your point, but I don't agree until I see a compelling case for
> annotating a non-commit.
My point is that it is too late by then, if you don't allow for a flexible
and still efficient scheme.
> > - most of the performance difference between the date-based and the
> > SHA-1 based fan-out looks to me as if the issue was the top-level
> > tree. Basically, this tree has to be read _every_ time _anybody_
> > wants to read a note.
>
> Not sure what you're trying to say here. The top-level notes tree is
> read (as in fill_tree_descriptor()) exactly _once_. After that, it is
> cached by the internal data structure (until free_commit_notes() or
> end-of-process).
By that reasoning, we do not need any fan-out scheme.
Keep in mind: reading a large tree object takes a long time. That's why
we started fan-out. Reading a large number of tree objects also takes a
long time. That's why I propagated flexible fan-out that is only read-in
on demand.
> > But I think that having a dynamic fan-out that can even put blobs into
> > the top-level tree (nothing prevents us from doing that, right?)
>
> Well, the "flexible" code does add the new requirement that all entries
> in a notes (sub)tree object must follow the same scheme, i.e. you
> cannot have:
>
> /12/34567890123456789012345678901234567890
> /2345/678901234567890123456789012345678901
>
> but you can have
>
> /12/34567890123456789012345678901234567890
> /23/45/678901234567890123456789012345678901
Umm, why? Is there any good technical reason?
> > The real question for me, therefore, is: what is the optimal way to
> > strike the balance between size of the tree objects (which we want to
> > be small, so that unpacking them is fast) and depth of the fan-out
> > (which we want to be shallow to avoid reading worst-case 39 tree
> > objects to get at one single note).
>
> s/39/19/ (each fanout must use at least 2 chars of the 40-char SHA1)
That is another unnecessary restriction that could cost you dearly. Just
think what happens if it turns out that the optimal number of tree items
is closer to 16 than to 255...
> Yes, the challenge is indeed striking the correct balance. I believe
> that the notes code should be taught to write (and automatically
> re-organize) the notes tree so that it is optimized for the current
> collection of notes.
Of course! I never thought that the user should be allowed to make the
choice how to organize the notes.
Ciao,
Dscho
^ permalink raw reply
* [RFC PATCH 2/2] INSTALL: Describe a few knobs from the Makefile
From: Brian Gernhardt @ 2009-09-08 15:55 UTC (permalink / raw)
To: Git List; +Cc: Junio C Hamano
In-Reply-To: <1252425313-69793-1-git-send-email-brian@gernhardtsoftware.com>
We said that some of our dependencies were optional, but didn't say
how to turn them off. Add information for that and mention where to
save the options close to the top of the file.
Also, reorder the list so the absolutely required ones are at the top.
Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com>
---
I don't know if anyone wants this level of detail in the INSTALL file, or
if we'd prefer people actually RTFMakefile. It didn't take long to write
though, so I thought I'd throw it out and see if people liked it.
INSTALL | 33 +++++++++++++++++++++++----------
1 files changed, 23 insertions(+), 10 deletions(-)
diff --git a/INSTALL b/INSTALL
index 4a57e47..e08b990 100644
--- a/INSTALL
+++ b/INSTALL
@@ -13,6 +13,10 @@ that uses $prefix, the built results have some paths encoded,
which are derived from $prefix, so "make all; make prefix=/usr
install" would not work.
+There are many options that can be configured in the makefile using either
+command line defines or a config.mak file. These options are documented at
+the beginning of the Makefile.
+
Alternatively you can use autoconf generated ./configure script to
set up install paths (via config.mak.autogen), so you can write instead
@@ -48,12 +52,19 @@ Issues of note:
export GIT_EXEC_PATH PATH GITPERLLIB
- Git is reasonably self-sufficient, but does depend on a few external
- programs and libraries:
+ programs and libraries. Git can be used without most of them by adding
+ the approriate "NO_<LIBRARY>=YesPlease" to the make command line or
+ config.mak file.
- "zlib", the compression library. Git won't build without it.
- - "openssl". Unless you specify otherwise, you'll get the SHA1
- library from here.
+ - "ssh" is used to push and pull over the net
+
+ - A POSIX-compliant shell is needed to use most of the bare-bones
+ Porcelainish scripts.
+
+ - "openssl". Unless you specify otherwise (with NO_OPENSSL),
+ you'll get the SHA1 library from here.
If you don't have openssl, you can use one of the SHA1 libraries
that come with git (git includes one based on Mozilla's as well
@@ -62,18 +73,20 @@ Issues of note:
- libcurl library; git-http-fetch and git-fetch use them. You
might also want the "curl" executable for debugging purposes.
If you do not use http transfer, you are probably OK if you
- do not have them.
+ do not have them (use NO_CURL).
- expat library; git-http-push uses it for remote lock
- management over DAV. Similar to "curl" above, this is optional.
+ management over DAV. Similar to "curl" above, this is optional
+ (with NO_EXPAT).
- "wish", the Tcl/Tk windowing shell is used in gitk to show the
- history graphically, and in git-gui.
-
- - "ssh" is used to push and pull over the net
+ history graphically, and in git-gui. If you don't want gitk or
+ git-gui, you can use NO_TCLTK.
- - "perl" and POSIX-compliant shells are needed to use most of
- the bare-bones Porcelainish scripts.
+ - "perl" is used for several scripts that are useful, but not
+ required for git (e.g. "git add -i" and "git difftool"). If you
+ don't need the *.perl scripts or the library contained in perl/,
+ then use NO_PERL.
- Some platform specific issues are dealt with Makefile rules,
but depending on your specific installation, you may not
--
1.6.4.2.420.g30ecf
^ permalink raw reply related
* [PATCH 1/2] INSTALL: Update description of our SHA-1 code
From: Brian Gernhardt @ 2009-09-08 15:55 UTC (permalink / raw)
To: Git List; +Cc: Junio C Hamano
We haven't had Mozilla's code or an ARM optimized algorithm since
30ae47b. Reword the paragraph to give credit but not authorship to
Mozilla.
Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com>
---
Minor nit I noticed while in the INSTALL file.
INSTALL | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/INSTALL b/INSTALL
index ae7f750..4a57e47 100644
--- a/INSTALL
+++ b/INSTALL
@@ -56,8 +56,8 @@ Issues of note:
library from here.
If you don't have openssl, you can use one of the SHA1 libraries
- that come with git (git includes the one from Mozilla, and has
- its own PowerPC and ARM optimized ones too - see the Makefile).
+ that come with git (git includes one based on Mozilla's as well
+ as a PowerPC optimized one - see the Makefile).
- libcurl library; git-http-fetch and git-fetch use them. You
might also want the "curl" executable for debugging purposes.
--
1.6.4.2.420.g30ecf
^ permalink raw reply related
* Re: Improving merge failure message
From: Junio C Hamano @ 2009-09-08 16:34 UTC (permalink / raw)
To: Mike Ralphson; +Cc: Jeff King, Sverre Rabbelier, Nanako Shiraishi, git
In-Reply-To: <e2b179460909080059x62eb9d30t4d723d185e6316e3@mail.gmail.com>
Mike Ralphson <mike.ralphson@gmail.com> writes:
> 2009/9/8 Junio C Hamano <gitster@pobox.com>:
>> I'll leave the exact wording up to other people. My primary focus was to
>> end all of these messages with "Aborting."
>>
>> This turns out to be a continuation of an older discussion thread back in
>> May 2008, and I do not know if anybody took up the challenge back then. I
>> wouldn't be surprised if "checkout", which was the topic of the old
>> thread, has some other scary plumbing message still seeping through to the
>> UI layer. Perhaps there are some other commands that needs similar kind
>> of love.
>
> Just a note that Documentation/git-checkout.txt references this
> message in an example and should be kept in step with the final
> wording change. It would be ideal to be able to regression-test the
> examples in the documentation somehow but that might involve abusing
> the asciidoc markup somewhat.
Thanks.
> 2009/9/8 Jeff King <peff@peff.net>:
>> While we're picking apart your wording, is "clobbered" the word we want
>> to use?
>
> If we're debating 'clobbered', then maybe the non-word 'uptodate' is
> fair game too? 8-)
I think you added smiley because you already knew the answer, but if that
is not the case, please see
http://thread.gmane.org/gmane.comp.version-control.git/81100/focus=82358
^ permalink raw reply
* Re: [PATCH] Add test for ignoring pushInsteadOf when remote has explicit pushurl
From: Junio C Hamano @ 2009-09-08 16:34 UTC (permalink / raw)
To: Josh Triplett; +Cc: Junio C Hamano, git
In-Reply-To: <20090908074147.GB3236@feather>
Josh Triplett <josh@joshtriplett.org> writes:
> Done. Please add this to the queue, optionally squashing it into patch
> 2/2 if you prefer.
Thanks.
^ permalink raw reply
* Re: [PATCH] post-receive-email: do not call sendmail if no mail was generated
From: Junio C Hamano @ 2009-09-08 16:57 UTC (permalink / raw)
To: Lars Noschinski; +Cc: git
In-Reply-To: <20090908092059.GA8207@lars.home.noschinski.de>
Lars Noschinski <lars@public.noschinski.de> writes:
> * Lars Noschinski <lars@public.noschinski.de> [09-08-28 19:39]:
>> contrib/hooks/post-receive-email used to call the send_mail function
>> (and thus, /usr/sbin/sendmail), even if generate_mail returned an error.
>> This is problematic, as the sendmail binary provided by exim4 generates
>> an error mail if provided with an empty input.
>>
>> Therefore, this commit changes post-receive-email to only call sendmail
>> if generate_mail returned without error.
>>
>> Signed-off-by: Lars Noschinski <lars@public.noschinski.de>
>
> Is anything wrong with this patch? Or is it just queued to be committed
> some time?
It is not queued anywhere as far as I am concerned.
I was waiting for others to review the patch and nothing happened, so the
patch was in limbo. Thanks for sending a reminder message I am responding
to. You did the right thing when nothing happened to a patch that did not
see any discussion.
You can avoid this by CC'ing people who have been involved in the past
with the parts of the system you are patching in the initial posting of
your patch (I am not one of them, so CC'ing me didn't help).
Here are my knee-jerk reactions to the patch after a quick glance, without
thinking deeply nor looking at the other parts of the file you did not
touch, but looking only at the parts shown in your patch:
- Slurping generate_email's output into a shell variable is a bad taste.
You said that the message is always small enough but _how_ do we know
it?
- If this is to save us from a quirk in some but not all implementations
of /usr/lib/sendmail, then shouldn't the logic be made into a new
conditional?
- I do not see a direct link between "if generate_mail returned an error"
and "if ... an empty input". What if generate_mail started its output
but then failed halfway? We have some output so the send_mail won't be
fed empty, but $? would be not zero, so the patch is testing a
different condition from what the log message claims to be checking.
People who do use this script and people who have worked on it may have
other more useful comments.
Thanks.
^ permalink raw reply
* [PATCH] git-gui: store wm state and fix wm geometry
From: Alexey Borzenkov @ 2009-09-08 18:39 UTC (permalink / raw)
To: git; +Cc: spearce
I often close git gui window when it is maximized, and when I reopen
it next time the it would usually become out of place (e.g. a huge
window with a top-left corner somewhere close to the center of the
screen). Fix it by storing and restoring wm state in config, as well
as setting wm state to normal before retrieving wm geometry info.
Signed-off-by: Alexey Borzenkov <snaury@gmail.com>
---
I've been using this patch for almost a year on Windows now.
If you have any comments/questions please don't forget to cc me
as I'm not subscribed to this list.
git-gui.sh | 21 +++++++++++++++++++++
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index eae1f81..88d1025 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -2025,6 +2025,19 @@ proc do_quit {{rc {1}}} {
# -- Stash our current window geometry into this repository.
#
+ set cfg_wmstate [wm state .]
+ if {[catch {set rc_wmstate $repo_config(gui.wmstate)}]} {
+ set rc_wmstate {}
+ }
+ if {$cfg_wmstate ne $rc_wmstate} {
+ catch {git config gui.wmstate $cfg_wmstate}
+ }
+ if {$cfg_wmstate eq {zoomed}} {
+ # on Windows wm geometry will lie about window
+ # position (but not size) when window is zoomed
+ # restore the window before querying wm geometry
+ wm state . normal
+ }
set cfg_geometry [list]
lappend cfg_geometry [wm geometry .]
lappend cfg_geometry [lindex [.vpane sash coord 0] 0]
@@ -3264,6 +3277,14 @@ wm geometry . [lindex $gm 0]
unset gm
}
+# -- Load window state
+#
+catch {
+set gws $repo_config(gui.wmstate)
+wm state . $gws
+unset gws
+}
+
# -- Key Bindings
#
bind $ui_comm <$M1B-Key-Return> {do_commit;break}
--
1.6.4.2
^ permalink raw reply related
* Re: [PATCH] git.el: Use git-add-file for unmerged files, remove git-resolve-file
From: Alexandre Julliard @ 2009-09-08 18:43 UTC (permalink / raw)
To: Martin Nordholts; +Cc: git, Junio C Hamano
In-Reply-To: <4AA026AC.10907@gmail.com>
Martin Nordholts <enselic@gmail.com> writes:
> Use `git-add-file' to mark unmerged files as resolved in the
> *git-status* buffer to be consistent with git's CLI instructions. Also
> remove `git-resolve-file' to make it clear that that "R" is a now a
> free keybinding.
>
> Signed-off-by: Martin Nordholts <martinn@src.gnome.org>
Looks good, thanks.
Acked-by: Alexandre Julliard <julliard@winehq.org>
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply
* [PATCH] gitk: restore wm state to normal before saving geometry information
From: Alexey Borzenkov @ 2009-09-08 18:44 UTC (permalink / raw)
To: git; +Cc: Paul Mackerras
gitk now includes patches for saving and restoring wm state, however
because it saves wm geometry when window can still be maximized the
maximize/restore button becomes useless after restarting gitk (you
will get a huge displaced window if you try to restore it). This
patch fixes this issue by storing window geometry in normal state.
Signed-off-by: Alexey Borzenkov <snaury@gmail.com>
---
Please don't forget to cc me if you have comments/questions
gitk | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/gitk b/gitk
index 8c08310..fedeb88 100755
--- a/gitk
+++ b/gitk
@@ -2555,8 +2555,11 @@ proc savestuff {w} {
puts $f [list set extdifftool $extdifftool]
puts $f [list set perfile_attrs $perfile_attrs]
- puts $f "set geometry(main) [wm geometry .]"
puts $f "set geometry(state) [wm state .]"
+ if {[wm state .] eq {zoomed}} {
+ wm state . normal
+ }
+ puts $f "set geometry(main) [wm geometry .]"
puts $f "set geometry(topwidth) [winfo width .tf]"
puts $f "set geometry(topheight) [winfo height .tf]"
puts $f "set geometry(pwsash0) \"[.tf.histframe.pwclist sash
coord 0]\""
--
1.6.4.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox