Re: [RFC/PATCH] merge: Add '--continue' option as a synonym for 'git commit'
Am 12.12.2016 um 09:34 schrieb Chris Packham:
> Teach 'git merge' the --continue option which allows 'continuing' a
> merge by completing it. The traditional way of completing a merge after
> resolving conflicts is to use 'git commit'. Now with commands like 'git
> rebase' and 'git cherry-pick' having a '--continue' option adding such
> an option to 'git merge' presents a consistent UI.
Like.
While Junio is entirely right that this is redundant, the inner workings of Git
are just voodoo for a (guessed) 95% of users out there, so a consistent UI is
important.
> DESCRIPTION
> ---
> @@ -61,6 +62,9 @@ reconstruct the original (pre-merge) changes. Therefore:
> discouraged: while possible, it may leave you in a state that is hard to
> back out of in the case of a conflict.
>
> +The fourth syntax ("`git merge --continue`") can only be run after the
> +merge has resulted in conflicts. 'git merge --continue' will take the
> +currently staged changes and complete the merge.
I think this should mention the equivalence to 'git commit'.
Markus
--
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. (FH) Markus Hitter
http://www.jump-ing.de/
Re: Resend: Gitk: memory consumption improvements
Am 09.12.2016 um 18:57 schrieb Stefan Beller: > On Fri, Dec 9, 2016 at 3:51 AM, Markus Hitter wrote: >> >> It's a month now since I sent three patches to this list for reducing memory >> consumption of Gitk considerably: >> >> https://public-inbox.org/git/de7cd593-0c10-4e93-1681-7e123504f...@jump-ing.de/ >> https://public-inbox.org/git/e09a5309-351d-d246-d272-f527f50ad...@jump-ing.de/ >> https://public-inbox.org/git/8e1c5923-d2a6-bc77-97ab-3f154b41d...@jump-ing.de/ >> https://public-inbox.org/git/2cb7f76f-0004-a5b6-79f1-9bb4f979c...@jump-ing.de/ >> >> Everybody cheered, but apparently nobody picked these patches up and applied >> them to either the Git or Gitk repository. They don't appear in the regular >> "what's cooking" post either. > > The "What's cooking" email is done by Junio (the Git maintainer) > describing the development of Git, whereas gitk is maintained by Paul > if I understand correctly. TBH, there might be no Gitk maintenance at all, because the last commit in either repository dates February 2016. It's a bit hard to believe there was not a single contribution in 10 months. > I'd love to see those patches in use here (via a regular upstream update). > > So I guess the way to go for you is to keep bugging Paul for an ack? Like: Hey hey Paul! Come and get the goal! Fetch the patch and get applied to our all's delight! or like Macke- Macke- Mackerras! Come here and join with us! It's just a simple 'git am' and you are the man! Another encouraging poem? Markus -- - - - - - - - - - - - - - - - - - - - Dipl. Ing. (FH) Markus Hitter http://www.jump-ing.de/
Resend: Gitk: memory consumption improvements
It's a month now since I sent three patches to this list for reducing memory consumption of Gitk considerably: https://public-inbox.org/git/de7cd593-0c10-4e93-1681-7e123504f...@jump-ing.de/ https://public-inbox.org/git/e09a5309-351d-d246-d272-f527f50ad...@jump-ing.de/ https://public-inbox.org/git/8e1c5923-d2a6-bc77-97ab-3f154b41d...@jump-ing.de/ https://public-inbox.org/git/2cb7f76f-0004-a5b6-79f1-9bb4f979c...@jump-ing.de/ Everybody cheered, but apparently nobody picked these patches up and applied them to either the Git or Gitk repository. They don't appear in the regular "what's cooking" post either. Anything missing? I'd like to put a 'done' checkmark behind this. Markus -- - - - - - - - - - - - - - - - - - - - Dipl. Ing. (FH) Markus Hitter http://www.jump-ing.de/
Re: [PATCH 5/6] config docs: Provide for config to specify tags not to abbreviate
Am 10.11.2016 um 00:31 schrieb Ian Jackson: > I am proposing to set this configuration setting automatically in > dgit. Other tools that work with particular git tags would do the > same. There would be no need for users to do anything. > > Having this as an option in a menu would be quite wrong, because it > would end up with the user and the tooling fighting. This is why I > don't want to put this in gitk's existing config file mechanism. Having this conversation watched for a while I get the impression that your point is essentially about introducing another type of references, next to branches and (ordinary) tags. Let's call them "interesting tags", "itags". The logical path to get this, IMHO, isn't to add some configuration variable, but to store such interesting tags in .git/refs/itags/, just like the other reference types. Then one would create such interesting tags with git tag -i or git tag --interesting To reduce the backwards compatibility problem these itags could be stored in .git/refs/tags as well, itag-aware tools would sort the duplicates out. Markus -- - - - - - - - - - - - - - - - - - - - Dipl. Ing. (FH) Markus Hitter http://www.jump-ing.de/
Re: [PATCH 0/3] gitk: memory consumption improvements
Am 08.11.2016 um 22:37 schrieb Junio C Hamano: > Are all semi-modern Tcl/Tk in service have this -undo thing so that > we can pass unconditionally to the text widget like the patch does? Good point. As far as my research goes, this flag was introduced in Nov. 2001: http://core.tcl.tk/tk/info/5265df93d207cec0 To defend Gitk developers, the Tk guys apparently change their mind on the default value from time to time. Official documentation says nothing about a default, the proposal from 2001 talks about -undo 0 as default and there are recent commits changing this default: http://core.tcl.tk/tk/info/549d2f56757408f3 Markus -- - - - - - - - - - - - - - - - - - - - Dipl. Ing. (FH) Markus Hitter http://www.jump-ing.de/
Re: Bug: git config does not respect read-only .gitconfig file
Am 08.11.2016 um 16:22 schrieb Jonathan Word:
> Proposal:
>
> Part 1) Add a .gitconfig variable to respect a read-only gitconfig
> file and optional "--force" override option for the `git config`
> command
>
> Such a gitconfig variable could be defined as:
> config.respectFileMode: [ "never", "allow-override", "always" ]
> [...]
> Thoughts?
I'd consider disrespecting file permissions to be a bug. Only very few tools
allow to do so ('rm' is the only other one coming to mind right now), for good
reason. If they do, only with additional parameters or by additional user
interaction. Git should follow this strategy.
Which means: respect file permissions, no additional config variable and only
if there's very substantial reason, add a --force. KISS.
That said, disrespecting permissions requires additional code, so it'd be
interesting to know why this code was added. The relevant commit in the git.git
repo should tell.
Markus
--
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. (FH) Markus Hitter
http://www.jump-ing.de/
Re: [PATCH 0/6] Provide for config to specify tags not to abbreviate
Am 08.11.2016 um 01:54 schrieb Ian Jackson: > Please find in the following mails patches which provide a way to make > gitk display certain tags in full, even if they would normally be > abbreviated. TBH, I see a violation of tool independence with the choice of preference storage. Abbreviation of tags isn't a property of the repository, but a pure visual thing (screen real estate, whatever), so it should be handled by the tool doing the visuals, only. Your use case looks like a nice opportunity for - adding a Gitk user preference on how long displayed tags are allowed to be (instead of distinguishing between abbreviated and unabbreviated ones; set it to 999 for your use case) and/or - even better, abbreviate them depending on the size of the visible area, like a web browser would do, and/or - considering whether tags should be abbreviated on the left instead of on the right and/or - finding a mechanism to show them in full length even on small visible areas. The latter could be done by a tooltip appearing when hovering with the mouse over an abbreviated tag or by allowing multiple lines for a single commit in the list of commits. Trying to enforce long names just means they're not cut off by the abbreviation algorithm, but by the right boundary of the visible area. My $0.02, Markus -- - - - - - - - - - - - - - - - - - - - Dipl. Ing. (FH) Markus Hitter http://www.jump-ing.de/
[PATCH 3/3] gitk: clear array 'commitinfo' on reload
>From 8359452f426c68cc02250f25f20eaaacd2ddd001 Mon Sep 17 00:00:00 2001
From: Markus Hitter
Date: Mon, 7 Nov 2016 19:02:51 +0100
Subject: [PATCH 3/3] gitk: clear array 'commitinfo' on reload
After a reload we might have an entirely different set of commits,
so keeping all of them leaks memory. Remove them all because
re-creating them is not more expensive than testing wether they're
still valid. Lazy (re-)creation is already well established, so
a missing entry can't cause harm.
Signed-off-by: Markus Hitter
---
gitk | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gitk b/gitk
index 518a4ce..aef6db6 100755
--- a/gitk
+++ b/gitk
@@ -588,7 +588,7 @@ proc updatecommits {} {
proc reloadcommits {} {
global curview viewcomplete selectedline currentid thickerline
global showneartags treediffs commitinterest cached_commitrow
-global targetid
+global targetid commitinfo
set selid {}
if {$selectedline ne {}} {
@@ -609,6 +609,7 @@ proc reloadcommits {} {
getallcommits
}
clear_display
+unset -nocomplain commitinfo
unset -nocomplain commitinterest
unset -nocomplain cached_commitrow
unset -nocomplain targetid
--
2.9.3
[PATCH 2/3] gitk: remove closed file descriptors from $blobdifffd
>From 0a463fcd977dc9558835c373e24a095e35ca3c82 Mon Sep 17 00:00:00 2001
From: Markus Hitter
Date: Mon, 7 Nov 2016 16:01:17 +0100
Subject: [PATCH 2/3] gitk: remove closed file descriptors from $blobdifffd
One shouldn't have descriptors of already closed files around.
The first idea to deal with this (previously) ever growing array
was to remove it entirely, but it's needed to detect start of a
new diff with ths old diff not yet done. This happens when a user
clicks on the same commit in the commit list repeatedly without
delay.
Signed-off-by: Markus Hitter
---
gitk | 5 +
1 file changed, 5 insertions(+)
diff --git a/gitk b/gitk
index 8654e29..518a4ce 100755
--- a/gitk
+++ b/gitk
@@ -8069,7 +8069,11 @@ proc getblobdiffline {bdf ids} {
$ctext conf -state normal
while {[incr nr] <= 1000 && [gets $bdf line] >= 0} {
if {$ids != $diffids || $bdf != $blobdifffd($ids)} {
+ # Older diff read. Abort it.
catch {close $bdf}
+ if {$ids != $diffids} {
+ array unset blobdifffd $ids
+ }
return 0
}
parseblobdiffline $ids $line
@@ -8078,6 +8082,7 @@ proc getblobdiffline {bdf ids} {
blobdiffmaybeseehere [eof $bdf]
if {[eof $bdf]} {
catch {close $bdf}
+ array unset blobdifffd $ids
return 0
}
return [expr {$nr >= 1000? 2: 1}]
--
2.9.3
[PATCH 1/3] gitk: turn off undo manager in the text widget
>From e965e1deb9747bbc2b40dc2de95afb65aee9f7fd Mon Sep 17 00:00:00 2001
From: Markus Hitter
Date: Sun, 6 Nov 2016 20:38:03 +0100
Subject: [PATCH 1/3] gitk: turn off undo manager in the text widget
The diff text widget is read-only, so there's zero point in
building an undo stack. This change reduces memory consumption of
this widget by about 95%.
Memory usage of the whole program for viewing a reference commit
before; 579'692'744 bytes, after: 32'724'446 bytes.
Test procedure:
- Choose a largish commit and check it out. In this case one with
90'802 lines, 5'006'902 bytes.
- Have a Tcl version with memory debugging enabled. This is,
build one with --enable-symbols=mem passed to configure.
- Instrument Gitk to regularly show a memory dump. E.g. by adding
these code lines at the very bottom:
proc memDump {} {
catch {
set output [memory info]
puts $output
}
after 3000 memDump
}
memDump
- Start Gitk, it'll load this largish commit into the diff text
field automatically (because it's the current commit).
- Wait until memory consumption levels out and note the numbers.
Note that the numbers reported by [memory info] are much smaller
than the ones reported in 'top' (1.75 GB vs. 105 MB in this case),
likely due to all the instrumentation coming with the debug
version of Tcl.
Signed-off-by: Markus Hitter
---
gitk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gitk b/gitk
index 805a1c7..8654e29 100755
--- a/gitk
+++ b/gitk
@@ -2403,7 +2403,7 @@ proc makewindow {} {
set ctext .bleft.bottom.ctext
text $ctext -background $bgcolor -foreground $fgcolor \
- -state disabled -font textfont \
+ -state disabled -undo 0 -font textfont \
-yscrollcommand scrolltext -wrap none \
-xscrollcommand ".bleft.bottom.sbhorizontal set"
if {$have_tk85} {
--
2.9.3
[PATCH 0/3] gitk: memory consumption improvements
List, Paul, after searching for a while on why Gitk sometimes consumes exorbitant amounts of memory I found a pair of minor issues and also a big one: the text widget comes with an unlimited undo manager, which is turned on be default. Considering that each line is inserted seperately, this piles up a huuuge undo stack ... for a read-only text widget. Simply turning off this undo manager saves about 95% of memory when viewing large commits (with tens of thousands of diff lines). 3 patches are about to follow: - turn off the undo manager, - forget already closed file descriptors and - forget the 'commitinfo' array on a reload to enforce reloading it. I hope this finds you appreciation. Markus -- - - - - - - - - - - - - - - - - - - - Dipl. Ing. (FH) Markus Hitter http://www.jump-ing.de/
Re: gitk: avoid obscene memory consumption
Am 07.11.2016 um 05:11 schrieb Paul Mackerras:
>> - Storing only the actually viewed diff. It's an interactive tool, so
>> there's no advantage in displaying the diff in 0.001 seconds over viewing it
>> in 0.1 seconds. As far as I can see, Gitk currently stores every diff it
>> gets a hold of forever.
> It does? That would be a bug. :)
>
So far I've found three arrays being populated lazily (which is good) but never
being released (which ignores changes to the underlying repo):
$commitinfo: one entry of about 500 bytes per line viewed in the list of
commits. Maximum size of the array is the number of commits. As far as I can
see, this array should be removed on a reload (Shift-F5).
$blobdifffd: one entry of about 45 bytes for every commit ever read. The
underlying file descriptor gets closed, but the entry in this array remains. So
far I didn't find the reason why this array exists at all. It's also not
removed on a reload.
$treediffs: always the same number of entries as $blobdiffd, but > 1000
bytes/entry. Removed/refreshed on a reload (good!), different number of entries
from that point on.
In case you want to play as well, here's the code I wrote for the
investigation, it can be appended right at the bottom of the gitk script:
--8<---
proc variableSizes {} {
# Add variable here to get them shown.
global diffcontext diffids blobdifffd currdiffsubmod commitinfo
global diffnexthead diffnextnote difffilestart
global diffinhdr treediffs
puts "---"
foreach V [info vars] {
if { ! [info exists $V] } {
continue
}
set count 0
set bytes 0
if [array exists $V] {
set count [array size $V]
foreach I [array get $V] {
set bytes [expr $bytes + [string bytelength $I]]
}
} elseif [catch {llength [set $V]}] {
set count [llength [set $V]]
# set bytes [string bytelength [list {*}[set $V]]]
} else {
set bytes [string bytelength [set $V]]
}
puts [format "%20s: %5d items, %10d bytes" $V $count $bytes]
}
#catch {
# set output [memory info]
# puts $output
#}
after 3000 variableSizes
}
variableSizes
-->8---
[memory info] requires a Tcl with memory debug enabled.
Markus
--
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. (FH) Markus Hitter
http://www.jump-ing.de/
Re: gitk: avoid obscene memory consumption
Am 05.11.2016 um 12:08 schrieb Paul Mackerras: > On Fri, Nov 04, 2016 at 03:45:09PM -0700, Stefan Beller wrote: >> On Fri, Nov 4, 2016 at 12:49 PM, Markus Hitter wrote: >>> >>> Hello all, >> >> +cc Paul Mackeras, who maintains gitk. > > Thanks. > >>> >>> after Gitk brought my shabby development machine (Core2Duo, 4 GB RAM, >>> Ubuntu 16.10, no swap to save the SSD) to its knees once more than I'm >>> comfortable with, I decided to investigate this issue. >>> >>> Result of this investigation is, my Git repo has a commit with a diff of >>> some 365'000 lines and Gitk tries to display all of them, consuming more >>> than 1.5 GB of memory. >>> >>> The solution is to cut off diffs at 50'000 lines for the display. This >>> consumes about 350 MB RAM, still a lot. These first 50'000 lines are shown, >>> followed by a copyable message on how to view the full diff on the command >>> line. Diffs shorter than this limit are displayed as before. > > That sounds reasonable. > >> >> Bikeshedding: I'd argue to even lower the number to 5-10k lines. > > I could go with 10k. Thanks for the positive comments. TBH, the more I think about the problem, the less I'm satisfied with the solution I provided. Including two reasons: - The list of files affected to the right is still complete and clicking a file name further down results in nothing ... as if the file wasn't part of the diff. - Local searches. Cutting off diffs makes them unreliable. Global searches still work, but actually viewing a search result in the skipped section is no longer possible. So I'm watching out for better solutions. So far I can think of these: - Storing only the actually viewed diff. It's an interactive tool, so there's no advantage in displaying the diff in 0.001 seconds over viewing it in 0.1 seconds. As far as I can see, Gitk currently stores every diff it gets a hold of forever. - View the diff sparsely. Like rendering only the actually visible portion. - Enhancing ctext. This reference diff has 28 million characters, so there should be a way to store this with color information in, let's say, 29 MB of memory. Any additional ideas? Markus -- - - - - - - - - - - - - - - - - - - - Dipl. Ing. (FH) Markus Hitter http://www.jump-ing.de/
gitk: avoid obscene memory consumption
Hello all,
after Gitk brought my shabby development machine (Core2Duo, 4 GB RAM, Ubuntu
16.10, no swap to save the SSD) to its knees once more than I'm comfortable
with, I decided to investigate this issue.
Result of this investigation is, my Git repo has a commit with a diff of some
365'000 lines and Gitk tries to display all of them, consuming more than 1.5 GB
of memory.
The solution is to cut off diffs at 50'000 lines for the display. This consumes
about 350 MB RAM, still a lot. These first 50'000 lines are shown, followed by
a copyable message on how to view the full diff on the command line. Diffs
shorter than this limit are displayed as before.
To test the waters whether such a change is welcome, here's the patch as I
currently use it. If this patch makes sense I'll happily apply change requests
and bring it more in line with Git's patch submission expectations. The patch
is made against git(k) version 2.9.3, the one coming with latest Ubuntu. Please
also note that this is the first time I wrote some Tcl code, so the strategy
used might not follow best Tcl practices.
$ diff -uw /usr/bin/gitk.org /usr/bin/gitk
--- /usr/bin/gitk.org 2016-08-16 22:32:47.0 +0200
+++ /usr/bin/gitk 2016-11-04 20:06:14.805920404 +0100
@@ -7,6 +7,15 @@
# and distributed under the terms of the GNU General Public Licence,
# either version 2, or (at your option) any later version.
+# Markus: trying to limit memory consumption. It happened that
+# complex commits led to more than 1.5 GB of memory usage.
+#
+# The problem was identified to be caused by extremely long diffs. The
+# commit leading to this research had some 365'000 lines of diff, consuming
+# these 1.5 GB when drawn into the canvas. The solution is to limit diffs to
+# 50'000 lines and skipping the rest. In case of a cutoff, a CLI command for
+# getting the full diff is shown.
+
package require Tk
proc hasworktree {} {
@@ -7956,6 +7965,7 @@
proc getblobdiffs {ids} {
global blobdifffd diffids env
+global parseddifflines
global treediffs
global diffcontext
global ignorespace
@@ -7987,6 +7997,7 @@
}
fconfigure $bdf -blocking 0 -encoding binary -eofchar {}
set blobdifffd($ids) $bdf
+set parseddifflines 0
initblobdiffvars
filerun $bdf [list getblobdiffline $bdf $diffids]
}
@@ -8063,20 +8074,34 @@
proc getblobdiffline {bdf ids} {
global diffids blobdifffd
+global parseddifflines
global ctext
set nr 0
+set maxlines 5
$ctext conf -state normal
while {[incr nr] <= 1000 && [gets $bdf line] >= 0} {
+incr parseddifflines
+if {$parseddifflines >= $maxlines} {
+break
+}
if {$ids != $diffids || $bdf != $blobdifffd($ids)} {
catch {close $bdf}
return 0
}
parseblobdiffline $ids $line
}
+if {$parseddifflines >= $maxlines} {
+$ctext insert end "\n--" hunksep
+$ctext insert end " Lines exceeding $maxlines skipped " hunksep
+$ctext insert end "--\n\n" hunksep
+$ctext insert end "To get a full diff, run\n\n" hunksep
+$ctext insert end " git diff-tree -p -C --cc $ids\n\n" hunksep
+$ctext insert end "on the command line.\n" hunksep
+}
$ctext conf -state disabled
blobdiffmaybeseehere [eof $bdf]
-if {[eof $bdf]} {
+if {[eof $bdf] || $parseddifflines >= $maxlines} {
catch {close $bdf}
return 0
}
@@ -9093,6 +9118,7 @@
proc diffcommits {a b} {
global diffcontext diffids blobdifffd diffinhdr currdiffsubmod
+global parseddifflines
set tmpdir [gitknewtmpdir]
set fna [file join $tmpdir "commit-[string range $a 0 7]"]
@@ -9114,6 +9140,7 @@
set blobdifffd($diffids) $fd
set diffinhdr 0
set currdiffsubmod ""
+set parseddifflines 0
filerun $fd [list getblobdiffline $fd $diffids]
}
Cheers,
Markus
--
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. (FH) Markus Hitter
http://www.jump-ing.de/
Re: Git on Mac OS X 10.4.10
Am 15.08.2014 um 00:29 schrieb Jonathan Nieder:
> Orthogonal to that: a patch to the Darwin section of config.mak.uname
> so you can build without the 'make configure' would be even more
> welcome. :)
On this one. You need at least NO_GETTEXT and NO_EXPAT. I've attached a
config.mak.autogen to show what's needed.
However, if somebody chooses to install gettext or expat after OS installation,
how is the build process expected to detect this? IMHO, checking for OS version
number instead of actually available features is the wrong thing to do.
Markus
--
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. (FH) Markus Hitter
http://www.jump-ing.de/
# git Makefile configuration, included in main Makefile
# config.mak.autogen. Generated from config.mak.in by configure.
CC = cc
CFLAGS = -g -O2
CPPFLAGS =
LDFLAGS =
AR = ar
TAR = tar
DIFF = diff
PACKAGE_TARNAME = git
#INSTALL = @INSTALL@# needs install-sh or install.sh in sources
prefix = /usr/local
exec_prefix = ${prefix}
bindir = ${exec_prefix}/bin
gitexecdir = ${exec_prefix}/libexec/git-core
datarootdir = @datarootdir@
template_dir = ${prefix}/share/git-core/templates
sysconfdir = ${prefix}/etc
docdir = @docdir@
mandir = ${prefix}/man
htmldir = @htmldir@
AUTOCONFIGURED=YesPlease
INLINE=
CC_LD_DYNPATH=
TCLTK_PATH=wish
NEEDS_SSL_WITH_CRYPTO=
NO_OPENSSL=
NO_CURL=
NO_EXPAT=YesPlease
NEEDS_LIBICONV=YesPlease
NO_ICONV=
NO_DEFLATE_BOUND=
NEEDS_SOCKET=
NO_INET_NTOP=
NO_INET_PTON=
NO_HSTRERROR=
NEEDS_RESOLV=
NEEDS_LIBGEN=
LIBC_CONTAINS_LIBINTL=
NO_GETTEXT=YesPlease
NO_SYS_SELECT_H=
NO_SYS_POLL_H=
NO_INTTYPES_H=
OLD_ICONV=UnfortunatelyYes
SOCKLEN_T=
NO_D_INO_IN_DIRENT=
NO_D_TYPE_IN_DIRENT=
NO_GECOS_IN_PWENT=
NO_SOCKADDR_STORAGE=
NO_IPV6=
NO_REGEX=
FREAD_READS_DIRECTORIES=
SNPRINTF_RETURNS_BOGUS=
NO_LIBGEN_H=
HAVE_PATHS_H=YesPlease
HAVE_LIBCHARSET_H=YesPlease
HAVE_STRINGS_H=YesPlease
CHARSET_LIB=-liconv
NO_STRCASESTR=
NO_MEMMEM=YesPlease
NO_STRLCPY=
NO_UINTMAX_T=
NO_STRTOUMAX=
NO_SETENV=
NO_UNSETENV=
NO_MKDTEMP=
NO_MKSTEMPS=
NO_INITGROUPS=
PTHREAD_CFLAGS=
PTHREAD_LIBS=
NO_PTHREADS=
Re: Git on Mac OS X 10.4.10
Am 15.08.2014 um 09:46 schrieb Kyle J. McKay: > The below patch does the right thing. Conveniently there's already > a test for 10.4 and earlier so only a single line need be added. I can confirm this patch works. Thank you very much. > 8< > Subject: [PATCH] config.mak.uname: set NO_APPLE_COMMON_CRYPTO on older systems > > Older MacOS systems prior to 10.5 do not have the CommonCrypto > support Git uses so set NO_APPLE_COMMON_CRYPTO on those systems. > > Signed-off-by: Kyle J. McKay > --- > config.mak.uname | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/config.mak.uname b/config.mak.uname > index 7846bd76..f8e12c96 100644 > --- a/config.mak.uname > +++ b/config.mak.uname > @@ -88,6 +88,7 @@ ifeq ($(uname_S),Darwin) > NEEDS_LIBICONV = YesPlease > ifeq ($(shell expr "$(uname_R)" : '[15678]\.'),2) > OLD_ICONV = UnfortunatelyYes > + NO_APPLE_COMMON_CRYPTO = YesPlease > endif > ifeq ($(shell expr "$(uname_R)" : '[15]\.'),2) > NO_STRLCPY = YesPlease > -- - - - - - - - - - - - - - - - - - - - Dipl. Ing. (FH) Markus Hitter http://www.jump-ing.de/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git on Mac OS X 10.4.10
Am 14.08.2014 um 16:39 schrieb Torsten Bögershausen: > On 08/14/2014 02:13 PM, Markus Hitter wrote: >> Issue 2: I need this simple patch ... >> >> --- compat/apple-common-crypto.h.org2014-07-30 23:19:53.0 >> +0200 >> +++ compat/apple-common-crypto.h2014-08-14 12:57:37.0 +0200 >> @@ -2,7 +2,7 @@ >> #define OPENSSL_NO_MD5 >> #define HEADER_HMAC_H >> #define HEADER_SHA_H >> -#include >> +//#include >> #define HMAC_CTX CCHmacContext >> #define HMAC_Init(hmac, key, len, algo) CCHmacInit(hmac, algo, key, >> len) >> #define HMAC_Update CCHmacUpdate > The is in Mac OS X 10.6 .. 10.9, > but not in 10.4 (I don't know about 10.5). > You can try to tweak the "makefiles", search for NO_APPLE_COMMON_CRYPTO, > and set NO_APPLE_COMMON_CRYPTO, but only for Darwin 10.3 (or below) Thanks. This: export NO_APPLE_COMMON_CRYPTO=yes make configure CFLAGS=-O2 ./configure --without-tcltk --prefix=/usr/global make all compiles fine on 10.4.10. Would a configure patch checking for the existence of CommonHMAC.h and, if not found, defining this variable, be acceptable? Googling around, it's a bit unclear to me on how to contribute something to Git. Markus -- - - - - - - - - - - - - - - - - - - - Dipl. Ing. (FH) Markus Hitter http://www.jump-ing.de/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Git on Mac OS X 10.4.10
I'm new to this list, so: Hello everybody! My backup servers run Mac OS X 10.4.10. Yes, these are old, but very reliable and easily up to the task. And Mac OS X 10.4 is the latest OS supported there (PowerPC G3). Recently I tried to upgrade to v2.0.4 (from 1.7.11.4). Issue 1: I get many of these warnings: LINK [many cases] /usr/bin/ld: warning multiple definitions of symbol _regcomp libgit.a(regex.o) definition of _regcomp in section (__TEXT,__text) /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libSystem.dylib(regcomp.So) definition of _regcomp /usr/bin/ld: warning multiple definitions of symbol _regexec libgit.a(regex.o) definition of _regexec in section (__TEXT,__text) /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libSystem.dylib(regexec.So) definition of _regexec /usr/bin/ld: warning multiple definitions of symbol _regfree libgit.a(regex.o) definition of _regfree in section (__TEXT,__text) /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libSystem.dylib(regfree.So) definition of _regfree Is this expected? Issue 2: I need this simple patch ... --- compat/apple-common-crypto.h.org2014-07-30 23:19:53.0 +0200 +++ compat/apple-common-crypto.h2014-08-14 12:57:37.0 +0200 @@ -2,7 +2,7 @@ #define OPENSSL_NO_MD5 #define HEADER_HMAC_H #define HEADER_SHA_H -#include +//#include #define HMAC_CTX CCHmacContext #define HMAC_Init(hmac, key, len, algo) CCHmacInit(hmac, algo, key, len) #define HMAC_Update CCHmacUpdate ... and this command sequence ... make all touch imap-send.o touch git-imap-send make all ... to get it compiling. All, except git-imap-send, obviously, which is no loss for my purposes. I tried many releases, the patch requirement started with about v1.9.1, the git-imap-send failure somewhere between 1.8.1.6 and 1.8.4.3. Trying to be a good Open Source citizen, how would I proceed? Thanks, Markus P.S.1: error without the patch is: In file included from git-compat-util.h:330, from cache.h:4, from advice.c:1: compat/apple-common-crypto.h:5:37: error: CommonCrypto/CommonHMAC.h: No such file or directory P.S.2: error without faking git-imap-send is: CC imap-send.o imap-send.c: In function ‘cram’: imap-send.c:881: error: ‘CCHmacContext’ undeclared (first use in this function) imap-send.c:881: error: (Each undeclared identifier is reported only once imap-send.c:881: error: for each function it appears in.) imap-send.c:881: error: parse error before ‘hmac’ imap-send.c:896: error: ‘hmac’ undeclared (first use in this function) imap-send.c:896: error: ‘kCCHmacAlgMD5’ undeclared (first use in this function) make: *** [imap-send.o] Error 1 -- - - - - - - - - - - - - - - - - - - - Dipl. Ing. (FH) Markus Hitter http://www.jump-ing.de/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
