* Re: v1.5.4 plans
From: Johannes Schindelin @ 2007-12-11 12:57 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LFD.0.99999.0712102249180.555@xanadu.home>
Hi,
On Mon, 10 Dec 2007, Nicolas Pitre wrote:
> On Mon, 10 Dec 2007, Junio C Hamano wrote:
>
> > There are outstanding issues that need to be resolved:
> >
> > * We need to do something about "gc --aggressive". The documentation
> > removal patch from Linus, if it ever materializes, would be better
> > than nothing, but I have this nagging suspicion that the explosion is
> > merely a bad interation between -A and -f option to the repack, which
> > are not meant to be used together.
>
> Well, with the gcc repo, simply using 'git repack -a -f' with current
> default window size does produce a 2.1GB pack, while changing the window
> size to 100 (keeping default delta depth) produces a 400MB pack for me.
>
> So this is really a matter of not having a sufficiently large window for
> some data sets.
So my dumb patch to simply default to window and depth 250 with
aggressive was not _that_ dumb after all?
Ciao,
Dscho
^ permalink raw reply
* Re: Building git-1.5.3.7 on HP-UX 11.00
From: H.Merijn Brand @ 2007-12-11 12:57 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Junio C Hamano, Johannes Schindelin, Andreas Ericsson, git,
Sam Vilain, arjen
In-Reply-To: <20071211085440.GK14735@spearce.org>
On Tue, 11 Dec 2007 03:54:40 -0500, "Shawn O. Pearce" <spearce@spearce.org>
wrote:
> Junio C Hamano <gitster@pobox.com> wrote:
> > "H.Merijn Brand" <h.m.brand@xs4all.nl> writes:
> >
> > > 3 I am willing to believe that HP_UX' vsnprintf () is broken, or
> > > at least does not conform to the expectations in the GNU world,
> > > but chickening out like the way strbuf_addf () does is maybe a
> > > bit too rude, so I forced a minimum of 64bytes available. That
> > > fixes a lot!
> > >
> > > but it still breaks t4013 :(
> >
> > I think Shawn had something similar for Solaris, and if it is a small
> > cost to help portability, it does not feel so bad.
>
> My Solaris change is already in your tree; on Solaris vnsprintf
> will return -1 if the input buffer we gave it had a length of 0.
> This can happen at odd times, depending on what is already in the
> strbuf and how its buffer is. :)
>
> The fix for Solaris turned out to be just make sure there is at
> least 1 byte in the buffer before calling vsnprintf().
>
> > > + git-index-pack -o tmp.idx test-2-7f8ead892057e78576c0329a70cc83afb113f117.pack
> > > fatal: serious inflate inconsistency
> >
> > That sounds like a broken zlib X-<.
libz is version 1.2.3
> I think this is actually a broken pread(). Its been reported
> multiple times by different people on HP-UX. Compiling with
> NO_PREAD=1 resolves the issues for everyone who has tried it.
:)
* passed all 114 test(s)
> Jakub asked me for an autoconf test to look for this sort of
> breakage in pread(), I have yet to come up with a theory for
> what sort of breakage HP-UX is showing us here, let alone write
> a test for it.
For now, the HP section in Makefile for 11.00 now looks like
ifeq ($(uname_S),HP-UX)
# HP-UX
BASIC_LDFLAGS += -L/usr/local/ssl/lib -L/usr/local/lib
# EXTLIBS += -lc_r -lgcc
NO_HSTRERROR = YesPlease
NO_ICONV = YesPlease
NO_INET_NTOP = YesPlease
NO_INET_PTON = YesPlease
NO_UNSETENV = YesPlease
NO_STRTOULL = YesPlease
NO_STRTOUMAX = YesPlease
NO_PREAD = YesPlease
endif
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using & porting perl 5.6.2, 5.8.x, 5.10.x on HP-UX 10.20, 11.00, 11.11,
& 11.23, SuSE 10.1 & 10.2, AIX 5.2, and Cygwin. http://qa.perl.org
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org
http://www.goldmark.org/jeff/stupid-disclaimers/
^ permalink raw reply
* Re: [PATCH] Adding menu for Emacs git.el
From: Alexandre Julliard @ 2007-12-11 13:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Remi Vanicat, git
In-Reply-To: <7vhciphh4k.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Alex, what is the current status of this patch?
Patch v3 looked good but the patch file was corrupted. Here's the latest
version, I have moved things around a bit to use only one menu and to be
more similar to pcl-cvs.
From 0a67dfc88a8bbf479c37ba76521ebe39fa67f577 Mon Sep 17 00:00:00 2001
From: Alexandre Julliard <julliard@winehq.org>
Date: Tue, 11 Dec 2007 13:56:09 +0100
Subject: [PATCH] git.el: Added a menu for git-status-mode.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Originally written by Rémi Vanicat, I just changed the layout a little.
Signed-off-by: Rémi Vanicat <vanicat@debian.org>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
contrib/emacs/git.el | 43 ++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 42 insertions(+), 1 deletions(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index e147da0..ae58f1c 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -49,6 +49,7 @@
(eval-when-compile (require 'cl))
(require 'ewoc)
(require 'log-edit)
+(require 'easymenu)
;;;; Customizations
@@ -1297,7 +1298,47 @@ Return the list of files that haven't been handled."
(define-key toggle-map "i" 'git-toggle-show-ignored)
(define-key toggle-map "k" 'git-toggle-show-unknown)
(define-key toggle-map "m" 'git-toggle-all-marks)
- (setq git-status-mode-map map)))
+ (setq git-status-mode-map map))
+ (easy-menu-define git-menu git-status-mode-map
+ "Git Menu"
+ `("Git"
+ ["Refresh" git-refresh-status t]
+ ["Commit" git-commit-file t]
+ ("Merge"
+ ["Next Unmerged File" git-next-unmerged-file t]
+ ["Prev Unmerged File" git-prev-unmerged-file t]
+ ["Mark as Resolved" git-resolve-file t]
+ ["Interactive Merge File" git-find-file-imerge t]
+ ["Diff Against Common Base File" git-diff-file-base t]
+ ["Diff Combined" git-diff-file-combined t]
+ ["Diff Against Merge Head" git-diff-file-merge-head t]
+ ["Diff Against Mine" git-diff-file-mine t]
+ ["Diff Against Other" git-diff-file-other t])
+ "--------"
+ ["Add File" git-add-file t]
+ ["Revert File" git-revert-file t]
+ ["Ignore File" git-ignore-file t]
+ ["Remove File" git-remove-file t]
+ "--------"
+ ["Find File" git-find-file t]
+ ["View File" git-view-file t]
+ ["Diff File" git-diff-file t]
+ ["Interactive Diff File" git-diff-file-idiff t]
+ ["Log" git-log-file t]
+ "--------"
+ ["Mark" git-mark-file t]
+ ["Mark All" git-mark-all t]
+ ["Unmark" git-unmark-file t]
+ ["Unmark All" git-unmark-all t]
+ ["Toggle All Marks" git-toggle-all-marks t]
+ ["Hide Handled Files" git-remove-handled t]
+ "--------"
+ ["Show Uptodate Files" git-toggle-show-uptodate :style toggle :selected git-show-uptodate]
+ ["Show Ignored Files" git-toggle-show-ignored :style toggle :selected git-show-ignored]
+ ["Show Unknown Files" git-toggle-show-unknown :style toggle :selected git-show-unknown]
+ "--------"
+ ["Quit" git-status-quit t])))
+
;; git mode should only run in the *git status* buffer
(put 'git-status-mode 'mode-class 'special)
--
1.5.3.7.959.gdf7e-dirty
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
* Re: backups with git and inotify
From: David Tweed @ 2007-12-11 13:24 UTC (permalink / raw)
To: Luciano Rocha; +Cc: Björn Steinbrink, git
In-Reply-To: <20071211102546.GA5811@bit.office.eurotux.com>
On Dec 11, 2007 10:25 AM, Luciano Rocha <luciano@eurotux.com> wrote:
> On Mon, Dec 10, 2007 at 10:57:46PM +0100, Björn Steinbrink wrote:
> > On 2007.12.10 20:29:11 +0000, Luciano Rocha wrote:
> FWIW, I also think that trying to keep a coherent stat with automatic
> commits isn't possible. As for the temporary, unneeded files, a
> exclusion pattern will suffice, and using .git directly, instead of a
> (FUSE) filesystem, will allow permanent storage of those temporary
> files, until explicitly removed.
As a data point, I find it easier for my work to have rules that
specify the files you DO want to keep. (I actually have a set of
common suffixes to ignore that's checked first but purely for
efficiency: it's quicker to throw out the usual suspects like *~, *.o,
*.pyc, etc, immediately rather than fail to match all the more
complicated "keep this" rules every single time.) One advantage of
this is that if I do something stupid like drop a 2G video file into
the tracked tree it's doesn't get sucked in to the git repo.
--
cheers, dave tweed__________________________
david.tweed@gmail.com
Rm 124, School of Systems Engineering, University of Reading.
"we had no idea that when we added templates we were adding a Turing-
complete compile-time language." -- C++ standardisation committee
^ permalink raw reply
* Re: Something is broken in repack
From: Nicolas Pitre @ 2007-12-11 13:31 UTC (permalink / raw)
To: Jon Smirl; +Cc: Junio C Hamano, gcc, Git Mailing List
In-Reply-To: <9e4733910712102129v140c2affqf2e73e75855b61ea@mail.gmail.com>
On Tue, 11 Dec 2007, Jon Smirl wrote:
> I added the gcc people to the CC, it's their repository. Maybe they
> can help up sort this out.
Unless there is a Git expert amongst the gcc crowd, I somehow doubt it.
And gcc people with an interest in Git internals are probably already on
the Git mailing list.
Nicolas
^ permalink raw reply
* Re: Building git-1.5.3.7 on HP-UX 11.00
From: H.Merijn Brand @ 2007-12-11 13:33 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Andreas Ericsson, git, Sam Vilain, arjen
In-Reply-To: <7vfxy9fxh3.fsf@gitster.siamese.dyndns.org>
On Tue, 11 Dec 2007 00:26:48 -0800, Junio C Hamano <gitster@pobox.com> wrote:
> "H.Merijn Brand" <h.m.brand@xs4all.nl> writes:
>
> > Summary of the changes:
> >
> > 1 Added a section for HP-UX in the Makefile. Note that this will
> > cover most of HP-UX, but might need several changes for both
> > newer HP-UX versions and 64bit environments. Will come to that
> > once I've got it all running
> >
> > 2 HP-UX does not have <sys/select.h>. I mentioned this before
>
> Unfortunate. It is even in POSIX.
The *include* file, or the function? HP-UX has the function, but
not the include file.
> But nothing "make -DNO_SYS_SELECT=Unfortunately" cannot fix.
I didn't see any #ifdef/#ifndef around the include, otherwise I
would have found that already I think.
> > 3 I am willing to believe that HP_UX' vsnprintf () is broken, or
> > at least does not conform to the expectations in the GNU world,
> > but chickening out like the way strbuf_addf () does is maybe a
> > bit too rude, so I forced a minimum of 64bytes available. That
> > fixes a lot!
> >
> > but it still breaks t4013 :(
>
> I think Shawn had something similar for Solaris, and if it is a small
> cost to help portability, it does not feel so bad.
:)
> > 4 'tr' doesn't like '\0', but wants '\000' instead.
> > 5 'tr' cannot deal with character classes
>
> Ok, that's odd (and not old fashioned, which makes even odder), but
> "\000" is not too bad (unless we have to do that million places).
> perl -MFile::Find -e'find(sub{m/\.sh$/ or return;local@ARGV=($_);while(<>){/\btr\b.*\\\d(?\!\d\d)/&&print"$File::Find::name\t$.\t$_"}},".")'
./git-filter-branch.sh 293 git diff-index -r $commit | cut -f 2- | tr '\n' '\0' | \
./test-sha1.sh 13 tr '[\0]' '[g]'
./test-sha1.sh 58 tr '[\0]' '[g]'
./t/diff-lib.sh 24 tr '\0' '\012' <"$1" | sed -e "$sanitize_diff_raw_z" >.tmp-1
./t/diff-lib.sh 25 tr '\0' '\012' <"$2" | sed -e "$sanitize_diff_raw_z" >.tmp-2
./t/t2001-checkout-cache-clash.sh 33 sed -e 's/^\([0-9]*\) [^ ]* [0-9a-f]* /tr: \1 /'
./t/t3300-funny-names.sh 57 'git ls-files -z | tr \\0 \\012 >current &&
./t/t3300-funny-names.sh 86 'git diff-index -z --name-status $t0 | tr \\0 \\012 >current &&
./t/t3300-funny-names.sh 90 'git diff-tree -z --name-status $t0 $t1 | tr \\0 \\012 >current &&
./t/t4020-diff-external.sh 102 echo NULZbetweenZwords | tr Z '\0' > file
./t/t4103-apply-binary.sh 27 tr 'x' '\0' <file1 >file3
./t/t4103-apply-binary.sh 30 tr '\0' 'v' <file3 >file1
./t/t4116-apply-reverse.sh 15 tr "[ijk]" '\''[\0\1\2]'\'' <file1 >file2 &&
./t/t4116-apply-reverse.sh 22 tr "[mon]" '\''[\0\1\2]'\'' <file1 >file2 &&
./t/t4200-rerere.sh 132 echo "$sha1 a1" | tr '\012' '\0' > .git/rr-cache/MERGE_RR
./t/t5300-pack-object.sh 18 dd if=/dev/zero bs=4k count=1 | tr "\\0" $i >$i &&
So with the recent history in the back of my mind, I'd expect all tr commands
with character class like notations to fail. Patch below.
> > 6 I don't know how to attack another HP specific problem: HP has
> > a system command called 'patch' and it is *very* incompatible
> > with GNU patch. Very.
>
> I do not think there is any reason for us to rely on "GNU patch"
> anymore. 4109 can have precomputed test vector instead of comparing our
> output with what GNU patch of the day happens to do.
\o/
> > 7 What do you expect for LOCALE's?
>
> I am not opposed to a change that makes these tests to conditionally
> skip on systems (not necessarily "platforms" but individual
> "installations") that do not have locales necessary to run tests
> installed, just like cvs or svn tests are skipped when they are not
> installed. Especially you are not using iconv...
\o/
BTW it is rather unlikely to find Tcl and/or Tk on most HP-UX systems.
Having perl already required, would you cheer an attempt to rewrite
git-gui to Perl/Tk? (I didn't have a look at it yet, but that should
make git-gui an awful lot more portable and when used on windows with
ActivePerl, Tk is already available in all builds)
I have put the output of
% make -i test | & perl -ne'm/^\*\s+ok\s+\d+:/ or print' > git-make-test.log
on http://www.xs4all.nl/~procura/git-make-test.log
which leaves only the following tests as failures:
t3901-i18n-patch.sh t4201-shortlog.sh t5100-mailinfo.sh
t5405-send-pack-rewind.sh t5500-fetch-pack.sh t5505-remote.sh
t5510-fetch.sh t5515-fetch-merge-logic.sh t5516-fetch-push.sh
t5520-pull.sh t5600-clone-fail-cleanup.sh t5700-clone-reference.sh
t5701-clone-local.sh t6002-rev-list-bisect.sh t6003-rev-list-topo-order.sh
t6022-merge-rename.sh t6026-merge-attr.sh t6200-fmt-merge-msg.sh
t7003-filter-branch.sh t9300-fast-import.sh t9301-fast-export.sh
t9500-gitweb-standalone-no-errors.sh
How close am I to success?
--8<--- git-tr.diff
--- git-2007-12-10_01/git-filter-branch.sh 2007-12-09 10:23:48 +0100
+++ git-2007-12-10/git-filter-branch.sh 2007-12-11 13:39:02 +0100
@@ -290,7 +290,7 @@ while read commit parents; do
eval "$filter_tree" < /dev/null ||
die "tree filter failed: $filter_tree"
- git diff-index -r $commit | cut -f 2- | tr '\n' '\0' | \
+ git diff-index -r $commit | cut -f 2- | tr '\n' '\000' | \
xargs -0 git update-index --add --replace --remove
git ls-files -z --others | \
xargs -0 git update-index --add --replace --remove
--- git-2007-12-10_01/test-sha1.sh 2007-12-09 10:23:48 +0100
+++ git-2007-12-10/test-sha1.sh 2007-12-11 13:39:29 +0100
@@ -10,7 +10,7 @@ do
{
test -z "$pfx" || echo "$pfx"
dd if=/dev/zero bs=1048576 count=$cnt 2>/dev/null |
- tr '[\0]' '[g]'
+ tr '\000' 'g'
} | ./test-sha1 $cnt
`
if test "$expect" = "$actual"
@@ -55,7 +55,7 @@ do
{
test -z "$pfx" || echo "$pfx"
dd if=/dev/zero bs=1048576 count=$cnt 2>/dev/null |
- tr '[\0]' '[g]'
+ tr '\000' 'g'
} | sha1sum |
sed -e 's/ .*//'
`
--- git-2007-12-10_01/t/diff-lib.sh 2007-12-09 10:23:48 +0100
+++ git-2007-12-10/t/diff-lib.sh 2007-12-11 13:39:56 +0100
@@ -21,8 +21,8 @@ compare_diff_raw_z () {
# Also we do not check SHA1 hash generation in this test, which
# is a job for t0000-basic.sh
- tr '\0' '\012' <"$1" | sed -e "$sanitize_diff_raw_z" >.tmp-1
- tr '\0' '\012' <"$2" | sed -e "$sanitize_diff_raw_z" >.tmp-2
+ tr '\000' '\012' <"$1" | sed -e "$sanitize_diff_raw_z" >.tmp-1
+ tr '\000' '\012' <"$2" | sed -e "$sanitize_diff_raw_z" >.tmp-2
git diff .tmp-1 .tmp-2 && rm -f .tmp-1 .tmp-2
}
--- git-2007-12-10_01/t/t3300-funny-names.sh 2007-12-09 10:23:48 +0100
+++ git-2007-12-10/t/t3300-funny-names.sh 2007-12-11 13:40:32 +0100
@@ -54,7 +54,7 @@ echo 'just space
no-funny
tabs ," (dq) and spaces' >expected
test_expect_success 'git ls-files -z with-funny' \
- 'git ls-files -z | tr \\0 \\012 >current &&
+ 'git ls-files -z | tr \\000 \\012 >current &&
git diff expected current'
t1=`git write-tree`
@@ -83,11 +83,11 @@ test_expect_success 'git diff-tree with-
echo 'A
tabs ," (dq) and spaces' >expected
test_expect_success 'git diff-index -z with-funny' \
- 'git diff-index -z --name-status $t0 | tr \\0 \\012 >current &&
+ 'git diff-index -z --name-status $t0 | tr \\000 \\012 >current &&
git diff expected current'
test_expect_success 'git diff-tree -z with-funny' \
- 'git diff-tree -z --name-status $t0 $t1 | tr \\0 \\012 >current &&
+ 'git diff-tree -z --name-status $t0 $t1 | tr \\000 \\012 >current &&
git diff expected current'
cat > expected <<\EOF
--- git-2007-12-10_01/t/t4020-diff-external.sh 2007-12-09 10:23:48 +0100
+++ git-2007-12-10/t/t4020-diff-external.sh 2007-12-11 13:40:44 +0100
@@ -99,7 +99,7 @@ test_expect_success 'no diff with -diff'
git diff | grep Binary
'
-echo NULZbetweenZwords | tr Z '\0' > file
+echo NULZbetweenZwords | tr Z '\000' > file
test_expect_success 'force diff with "diff"' '
echo >.gitattributes "file diff" &&
--- git-2007-12-10_01/t/t4103-apply-binary.sh 2007-12-09 10:23:48 +0100
+++ git-2007-12-10/t/t4103-apply-binary.sh 2007-12-11 13:40:57 +0100
@@ -24,10 +24,10 @@ git update-index --add --remove file1 fi
git-commit -m 'Initial Version' 2>/dev/null
git-checkout -b binary
-tr 'x' '\0' <file1 >file3
+tr 'x' '\000' <file1 >file3
cat file3 >file4
git add file2
-tr '\0' 'v' <file3 >file1
+tr '\000' 'v' <file3 >file1
rm -f file2
git update-index --add --remove file1 file2 file3 file4
git-commit -m 'Second Version'
--- git-2007-12-10_01/t/t4116-apply-reverse.sh 2007-12-09 10:23:48 +0100
+++ git-2007-12-10/t/t4116-apply-reverse.sh 2007-12-11 13:42:13 +0100
@@ -12,14 +12,14 @@ test_description='git apply in reverse
test_expect_success setup '
for i in a b c d e f g h i j k l m n; do echo $i; done >file1 &&
- tr "[ijk]" '\''[\0\1\2]'\'' <file1 >file2 &&
+ tr "ijk" '\''\000\001\002'\'' <file1 >file2 &&
git add file1 file2 &&
git commit -m initial &&
git tag initial &&
for i in a b c g h i J K L m o n p q; do echo $i; done >file1 &&
- tr "[mon]" '\''[\0\1\2]'\'' <file1 >file2 &&
+ tr "mon" '\''\000\001\002'\'' <file1 >file2 &&
git commit -a -m second &&
git tag second &&
--- git-2007-12-10_01/t/t4200-rerere.sh 2007-12-09 10:23:48 +0100
+++ git-2007-12-10/t/t4200-rerere.sh 2007-12-11 13:42:28 +0100
@@ -129,7 +129,7 @@ test_expect_success 'rerere kicked in' "
test_expect_success 'rerere prefers first change' 'git diff a1 expect'
rm $rr/postimage
-echo "$sha1 a1" | tr '\012' '\0' > .git/rr-cache/MERGE_RR
+echo "$sha1 a1" | tr '\012' '\000' > .git/rr-cache/MERGE_RR
test_expect_success 'rerere clear' 'git rerere clear'
--- git-2007-12-10_01/t/t5300-pack-object.sh 2007-12-09 10:23:48 +0100
+++ git-2007-12-10/t/t5300-pack-object.sh 2007-12-11 13:42:46 +0100
@@ -15,7 +15,7 @@ test_expect_success \
'rm -f .git/index*
for i in a b c
do
- dd if=/dev/zero bs=4k count=1 | tr "\\0" $i >$i &&
+ dd if=/dev/zero bs=4k count=1 | tr "\\000" $i >$i &&
git update-index --add $i || return 1
done &&
cat c >d && echo foo >>d && git update-index --add d &&
-->8--- git-tr.diff
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using & porting perl 5.6.2, 5.8.x, 5.10.x on HP-UX 10.20, 11.00, 11.11,
& 11.23, SuSE 10.1 & 10.2, AIX 5.2, and Cygwin. http://qa.perl.org
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org
http://www.goldmark.org/jeff/stupid-disclaimers/
^ permalink raw reply
* [ANNOUNCE] ugit: a pyqt-based git gui // was: Re: If you would write git from scratch now, what would you change?
From: David @ 2007-12-11 13:48 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
On Dec 4, 2007 3:00 AM, Andy Parkins <andyparkins@gmail.com> wrote:
>
> Qt puts a common face on threading, process control, networking, file
> systems, internationalisation, rendering, openGL, and of course the GUI
> itself. Tcl/Tk (to take the most wicked example) gives you applications
> that are much harder to make run on Windows than on UNIX.
>
> Anyway, I don't want to sound like a strange Qt fan boy; the above is simply
> my justification for putting "git-gui in Qt" on my wish list.
>
> Andy
> --
> Dr Andy Parkins, M Eng (hons), MIET
> andyparkins@gmail.com
For whatever it's worth, I've written a PyQt4-based git gui. For lack
of a better name I call it ugit, as in "I git, you git, we all git
with ugit" (or something silly like that).
Though there's still a few things remaining to be implemented, the
bulk of the initial groundwork is already done. All you need to
build/run it is python and pyqt4 (pyuic4). I've deliberately tried to
keep the interface similar to git-gui for now since it is obviously
based on it, but that's not a requirement.
Of course there are some notable things missing (such as proper i18n),
but it's not too bad for a first draft.
For more details (and the code) see:
http://repo.or.cz/w/ugit.git
Enjoy,
-- David A.
^ permalink raw reply
* Re: Something is broken in repack
From: Nicolas Pitre @ 2007-12-11 13:49 UTC (permalink / raw)
To: Jon Smirl; +Cc: Junio C Hamano, gcc, Git Mailing List
In-Reply-To: <9e4733910712102301p5e6c4165v6afb32d157478828@mail.gmail.com>
On Tue, 11 Dec 2007, Jon Smirl wrote:
> Switching to the Google perftools malloc
> http://goog-perftools.sourceforge.net/
>
> 10% 30 828M
> 20% 15 831M
> 30% 10 834M
> 40% 50 1014M
> 50% 80 1086M
> 60% 80 1500M
> 70% 200 1.53G
> 80% 200 1.85G
> 90% 260 1.87G
> 95% 520 1.97G
> 100% 1335 2.24G
>
> Google allocator knocked 600MB off from memory use.
> Memory consumption did not fall during the write out phase like it did with gcc.
>
> Since all of this is with the same code except for changing the
> threading split, those runs where memory consumption went to 4.5GB
> with the gcc allocator must have triggered an extreme problem with
> fragmentation.
Did you mean the glibc allocator?
> Total CPU time 196 CPU minutes vs 190 for gcc. Google's claims of
> being faster are not true.
>
> So why does our threaded code take 20 CPU minutes longer (12%) to run
> than the same code with a single thread? Clock time is obviously
> faster. Are the threads working too close to each other in memory and
> bouncing cache lines between the cores? Q6600 is just two E6600s in
> the same package, the caches are not shared.
Of course there'll always be a certain amount of wasted cycles when
threaded. The locking overhead, the extra contention for IO, etc. So
12% overhead (3% per thread) when using 4 threads is not that bad I
would say.
> Why does the threaded code need 2.24GB (google allocator, 2.85GB gcc)
> with 4 threads? But only need 950MB with one thread? Where's the extra
> gigabyte going?
I really don't know.
Did you try with pack.deltacachesize set to 1 ?
And yet, this is still missing the actual issue. The issue being that
the 2.1GB pack as a _source_ doesn't cause as much memory to be
allocated even if the _result_ pack ends up being the same.
I was able to repack the 2.1GB pack on my machine which has 1GB of ram.
Now that it has been repacked, I can't repack it anymore, even when
single threaded, as it start crowling into swap fairly quickly. It is
really non intuitive and actually senseless that Git would require twice
as much RAM to deal with a pack that is 7 times smaller.
Nicolas (still puzzled)
^ permalink raw reply
* Re: Building git-1.5.3.7 on HP-UX 11.00
From: Johannes Sixt @ 2007-12-11 13:53 UTC (permalink / raw)
To: H.Merijn Brand
Cc: Junio C Hamano, Johannes Schindelin, Andreas Ericsson, git,
Sam Vilain, arjen
In-Reply-To: <20071211143323.27c860db@pc09.procura.nl>
H.Merijn Brand schrieb:
> I have put the output of
>
> % make -i test | & perl -ne'm/^\*\s+ok\s+\d+:/ or print' > git-make-test.log
>
> on http://www.xs4all.nl/~procura/git-make-test.log
>
> which leaves only the following tests as failures:
>
> t3901-i18n-patch.sh t4201-shortlog.sh t5100-mailinfo.sh
> t5405-send-pack-rewind.sh t5500-fetch-pack.sh t5505-remote.sh
> t5510-fetch.sh t5515-fetch-merge-logic.sh t5516-fetch-push.sh
> t5520-pull.sh t5600-clone-fail-cleanup.sh t5700-clone-reference.sh
> t5701-clone-local.sh t6002-rev-list-bisect.sh t6003-rev-list-topo-order.sh
> t6022-merge-rename.sh t6026-merge-attr.sh t6200-fmt-merge-msg.sh
> t7003-filter-branch.sh t9300-fast-import.sh t9301-fast-export.sh
> t9500-gitweb-standalone-no-errors.sh
>
> How close am I to success?
There are a number of tests that pass only if you have iconv, most notably
t3901 and t5100. pull, clone, merge, filter-branch are shell scripts with
plenty of opportunities to stumble over incompatible/unportable constructs.
-- Hannes
^ permalink raw reply
* Re: v1.5.4 plans
From: Nicolas Pitre @ 2007-12-11 13:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.2903301355300.27959@racer.site>
On Fri, 30 Mar 2029, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 10 Dec 2007, Nicolas Pitre wrote:
>
> > On Mon, 10 Dec 2007, Junio C Hamano wrote:
> >
> > > There are outstanding issues that need to be resolved:
> > >
> > > * We need to do something about "gc --aggressive". The documentation
> > > removal patch from Linus, if it ever materializes, would be better
> > > than nothing, but I have this nagging suspicion that the explosion is
> > > merely a bad interation between -A and -f option to the repack, which
> > > are not meant to be used together.
> >
> > Well, with the gcc repo, simply using 'git repack -a -f' with current
> > default window size does produce a 2.1GB pack, while changing the window
> > size to 100 (keeping default delta depth) produces a 400MB pack for me.
> >
> > So this is really a matter of not having a sufficiently large window for
> > some data sets.
>
> So my dumb patch to simply default to window and depth 250 with
> aggressive was not _that_ dumb after all?
Probably not, although this might be rather wasteful on some
repositories. But that's what expectations are for --aggressive.
I wish we could find a way to set some good window default dynamically
though. Or perhaps the filename hashing needs improvements.
Nicolas
^ permalink raw reply
* Re: git-bisect feature suggestion: "git-bisect diff"
From: Ingo Molnar @ 2007-12-11 14:05 UTC (permalink / raw)
To: Jeff King
Cc: Pierre Habouzit, Jakub Narebski, Christian Couder, git,
Junio C Hamano
In-Reply-To: <20071211122539.GA13945@sigill.intra.peff.net>
* Jeff King <peff@peff.net> wrote:
> On Tue, Dec 11, 2007 at 12:59:14PM +0100, Pierre Habouzit wrote:
>
> > > Not exactly, as it does not give us email address.
> >
> > maybe it should be "fixed" so that it does, not to mention that other
> > concerns ingo raised look legit to me.
>
> Perhaps Junio is a time-traveller.
>
> $ git show 4602c17d
> commit 4602c17d8911e14d537f6f87db02faab6e3f5d69
> Author: Junio C Hamano <gitster@pobox.com>
> Date: Fri Dec 7 17:19:31 2007 -0800
>
> git-shortlog -e: show e-mail address as well
>
> This option shows the author's email address next to the name.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
please switch around the column too so that the commit count comes
first, this is way too ugly:
Junio C Hamano: 4826
Shawn O. Pearce: 1146
Linus Torvalds: 950
Johannes Schindelin: 497
Eric Wong: 383
Jakub Narebski: 317
Simon Hausmann: 243
Nicolas Pitre: 235
Ingo
^ permalink raw reply
* [PATCH] Fix typo: we require Python 2.4, not 2.5
From: Karl Hasselström @ 2007-12-11 14:23 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Git Mailing List
In-Reply-To: <b0943d9e0712100340p78326b4avf2b7e64008bba6d6@mail.gmail.com>
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
On 2007-12-10 11:40:41 +0000, Catalin Marinas wrote:
> This release requires at least Python 2.4 and GIT 1.5.2.
Yeah. So 0.14.1 (to be released very soon) should probably have this
fix. :-)
diff --git a/stgit/version.py b/stgit/version.py
index edd79e0..2e49e76 100644
--- a/stgit/version.py
+++ b/stgit/version.py
@@ -2,4 +2,4 @@ version = '0.13'
# minimum version requirements
git_min_ver = '1.5.2'
-python_min_ver = '2.5'
+python_min_ver = '2.4'
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply related
* Re: [PATCH] Fix typo: we require Python 2.4, not 2.5
From: Catalin Marinas @ 2007-12-11 14:27 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Git Mailing List
In-Reply-To: <20071211142347.GA22879@diana.vm.bytemark.co.uk>
On 11/12/2007, Karl Hasselström <kha@treskal.com> wrote:
> Signed-off-by: Karl Hasselström <kha@treskal.com>
>
> ---
>
> On 2007-12-10 11:40:41 +0000, Catalin Marinas wrote:
>
> > This release requires at least Python 2.4 and GIT 1.5.2.
>
> Yeah. So 0.14.1 (to be released very soon) should probably have this
> fix. :-)
Oops, I did some tests and forgot to revert it to 2.4. This would only
affect people using the source tarball. The rpm and deb packages
should be fine.
Is the GIT version OK or just too restrictive?
Thanks.
--
Catalin
^ permalink raw reply
* [PATCH] Invert numbers and names in the git-shortlog summary mode.
From: Pierre Habouzit @ 2007-12-11 14:43 UTC (permalink / raw)
To: Ingo Molnar
Cc: Jeff King, Jakub Narebski, Christian Couder, git, Junio C Hamano
In-Reply-To: <20071211140508.GA12204@elte.hu>
[-- Attachment #1: Type: text/plain, Size: 1633 bytes --]
Also make it `cut` friendly using a tab to separate the numbers and names.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
On Tue, Dec 11, 2007 at 02:05:08PM +0000, Ingo Molnar wrote:
> please switch around the column too so that the commit count comes
> first, this is way too ugly:
>
> Junio C Hamano: 4826
> Shawn O. Pearce: 1146
> Linus Torvalds: 950
[...]
Agreed, here is the patch that does that, and a sample output is:
$ git shortlog -n -s -e HEAD -- builtin-commit.c
11 Junio C Hamano <gitster@pobox.com>
6 Johannes Schindelin <Johannes.Schindelin@gmx.de>
6 Kristian Høgsberg <krh@redhat.com>
2 Jeff King <peff@peff.net>
1 Alex Riesen <raa.lkml@gmail.com>
1 Pierre Habouzit <madcoder@debian.org>
1 Shawn Bohrer <shawn.bohrer@gmail.com>
1 Wincent Colaiuta <win@wincent.com>
builtin-shortlog.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-shortlog.c b/builtin-shortlog.c
index 13df0c6..90666cb 100644
--- a/builtin-shortlog.c
+++ b/builtin-shortlog.c
@@ -265,7 +265,7 @@ int cmd_shortlog(int argc, const char **argv, const char *prefix)
struct path_list *onelines = list.items[i].util;
if (summary) {
- printf("%s: %d\n", list.items[i].path, onelines->nr);
+ printf("%6d\t%s\n", onelines->nr, list.items[i].path);
} else {
printf("%s (%d):\n", list.items[i].path, onelines->nr);
for (j = onelines->nr - 1; j >= 0; j--) {
--
1.5.3.7.2226.g8312-dirty
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: [PATCH] Fix typo: we require Python 2.4, not 2.5
From: Jakub Narebski @ 2007-12-11 14:47 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Karl Hasselström, Git Mailing List
In-Reply-To: <b0943d9e0712110627g70ad0aecyfeaafd8b8655fb57@mail.gmail.com>
"Catalin Marinas" <catalin.marinas@gmail.com> writes:
> On 11/12/2007, Karl Hasselström <kha@treskal.com> wrote:
> > On 2007-12-10 11:40:41 +0000, Catalin Marinas wrote:
> >
> > > This release requires at least Python 2.4 and GIT 1.5.2.
> >
> > Yeah. So 0.14.1 (to be released very soon) should probably have this
> > fix. :-)
>
> Oops, I did some tests and forgot to revert it to 2.4. This would only
> affect people using the source tarball. The rpm and deb packages
> should be fine.
Hmmm...
$ rpm -Uhv --test stgit-0.14-1.noarch.rpm
error: Failed dependencies:
python(abi) = 2.5 is needed by stgit-0.14-1.noarch
Although I guess that it is something that rpmbuild sets (if not set)
automatically during building.
I'll just download SRPMS (which is available, just not linked from
download area on homepage).
P.S. By the way: [application/x-wais-source]?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Invert numbers and names in the git-shortlog summary mode.
From: Ingo Molnar @ 2007-12-11 14:57 UTC (permalink / raw)
To: Pierre Habouzit, Jeff King, Jakub Narebski, Christian Couder, git,
Junio C Hamano <g
In-Reply-To: <20071211144351.GA15448@artemis.madism.org>
* Pierre Habouzit <madcoder@debian.org> wrote:
> Agreed, here is the patch that does that, and a sample output is:
>
> $ git shortlog -n -s -e HEAD -- builtin-commit.c
> 11 Junio C Hamano <gitster@pobox.com>
> 6 Johannes Schindelin <Johannes.Schindelin@gmx.de>
> 6 Kristian Høgsberg <krh@redhat.com>
> 2 Jeff King <peff@peff.net>
> 1 Alex Riesen <raa.lkml@gmail.com>
> 1 Pierre Habouzit <madcoder@debian.org>
> 1 Shawn Bohrer <shawn.bohrer@gmail.com>
> 1 Wincent Colaiuta <win@wincent.com>
great - this looks really neat!
btw., stupid question: why are the git-shortlog command line arguments
different from git-log? I got used to things like:
git-log kernel/
so for me it would be natural to just do:
git-shortlog -n -s kernel/
but this currently produces this output:
$ git-shortlog -n -s kernel/
(reading log to summarize from standard input)
which is quite a bit confusing to someone who'd like to keep as few
details of command line arguments in his head as possible :-)
Ingo
^ permalink raw reply
* Re: Something is broken in repack
From: Nicolas Pitre @ 2007-12-11 15:00 UTC (permalink / raw)
To: Jon Smirl; +Cc: Junio C Hamano, gcc, Git Mailing List
In-Reply-To: <alpine.LFD.0.99999.0712110832251.555@xanadu.home>
On Tue, 11 Dec 2007, Nicolas Pitre wrote:
> And yet, this is still missing the actual issue. The issue being that
> the 2.1GB pack as a _source_ doesn't cause as much memory to be
> allocated even if the _result_ pack ends up being the same.
>
> I was able to repack the 2.1GB pack on my machine which has 1GB of ram.
> Now that it has been repacked, I can't repack it anymore, even when
> single threaded, as it start crowling into swap fairly quickly. It is
> really non intuitive and actually senseless that Git would require twice
> as much RAM to deal with a pack that is 7 times smaller.
OK, here's something else for you to try:
core.deltabasecachelimit=0
pack.threads=2
pack.deltacachesize=1
With that I'm able to repack the small gcc pack on my machine with 1GB
of ram using:
git repack -a -f -d --window=250 --depth=250
and top reports a ~700m virt and ~500m res without hitting swap at all.
It is only at 25% so far, but I was unable to get that far before.
Would be curious to know what you get with 4 threads on your machine.
Nicolas
^ permalink raw reply
* Re: [PATCH] Fix typo: we require Python 2.4, not 2.5
From: Karl Hasselström @ 2007-12-11 15:01 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Git Mailing List
In-Reply-To: <b0943d9e0712110627g70ad0aecyfeaafd8b8655fb57@mail.gmail.com>
On 2007-12-11 14:27:08 +0000, Catalin Marinas wrote:
> Is the GIT version OK or just too restrictive?
The only restriction I've checked is this one:
commit 9a6bcbe26b6032c39031773da020fd7bf4015953
Author: Karl Hasselström <kha@treskal.com>
Date: Sat Sep 22 10:22:18 2007 +0200
Properly remove all config for a deleted branch
This uses "git-config --remove-section", which was first released in
git 1.5.1-rc1. I'm not sure if this is later than what we used to
depend on; we already use "git-config --rename-section", but that's
been in since git 1.5.0-rc0.
So I guess we should require at least 1.5.1. But I don't think
requiring 1.5.2 is that bad.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] Fix typo: we require Python 2.4, not 2.5
From: Catalin Marinas @ 2007-12-11 15:02 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Karl Hasselström, Git Mailing List
In-Reply-To: <m3r6hts2yk.fsf@roke.D-201>
On 11/12/2007, Jakub Narebski <jnareb@gmail.com> wrote:
> $ rpm -Uhv --test stgit-0.14-1.noarch.rpm
> error: Failed dependencies:
> python(abi) = 2.5 is needed by stgit-0.14-1.noarch
I use Ubuntu 7.10, not the best system for building RPMs.
> Although I guess that it is something that rpmbuild sets (if not set)
> automatically during building.
Yes. If you know what to add to setup.py, please let me know.
> I'll just download SRPMS (which is available, just not linked from
> download area on homepage).
It's not linked as I always thought people would use the .tar.gz.
What about adding it to cheeseshop.python.org and only run
"easy_install stgit"? The drawback of easy_install is that there is no
easy_uninstall yet.
> P.S. By the way: [application/x-wais-source]?
I don't control the web server my ISP provides. I should move
everything to gna.org but I was too lazy to modify my release script
(for Debian, gna.org even gives information on how to set up an apt
repository).
--
Catalin
^ permalink raw reply
* Re: [PATCH] Fix typo: we require Python 2.4, not 2.5
From: Karl Hasselström @ 2007-12-11 15:03 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Git Mailing List
In-Reply-To: <b0943d9e0712110627g70ad0aecyfeaafd8b8655fb57@mail.gmail.com>
On 2007-12-11 14:27:08 +0000, Catalin Marinas wrote:
> This would only affect people using the source tarball. The rpm and
> deb packages should be fine.
Ah, they don't run the install script?
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] Fix typo: we require Python 2.4, not 2.5
From: Jakub Narebski @ 2007-12-11 15:03 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Karl Hasselström, Git Mailing List
In-Reply-To: <m3r6hts2yk.fsf@roke.D-201>
Jakub Narebski <jnareb@gmail.com> writes:
> "Catalin Marinas" <catalin.marinas@gmail.com> writes:
>
> > On 11/12/2007, Karl Hasselström <kha@treskal.com> wrote:
> > > On 2007-12-10 11:40:41 +0000, Catalin Marinas wrote:
> > >
> > > > This release requires at least Python 2.4 and GIT 1.5.2.
> > >
> > > Yeah. So 0.14.1 (to be released very soon) should probably have this
> > > fix. :-)
> >
> > Oops, I did some tests and forgot to revert it to 2.4. This would only
> > affect people using the source tarball. The rpm and deb packages
> > should be fine.
>
> Hmmm...
>
> $ rpm -Uhv --test stgit-0.14-1.noarch.rpm
> error: Failed dependencies:
> python(abi) = 2.5 is needed by stgit-0.14-1.noarch
>
> Although I guess that it is something that rpmbuild sets (if not set)
> automatically during building.
>
> I'll just download SRPMS (which is available, just not linked from
> download area on homepage).
Ooops... I think I'd have to wait for 0.14.1
$ rpmbuild --rebuild --target=noarch stgit-0.14-1.src.rpm
[...]
Python version 2.5 or newer required. Found 2.4.3.final.0
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Fix typo: we require Python 2.4, not 2.5
From: Catalin Marinas @ 2007-12-11 15:06 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Karl Hasselström, Git Mailing List
In-Reply-To: <m3myshs27c.fsf@roke.D-201>
On 11/12/2007, Jakub Narebski <jnareb@gmail.com> wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
> Ooops... I think I'd have to wait for 0.14.1
>
> $ rpmbuild --rebuild --target=noarch stgit-0.14-1.src.rpm
> [...]
> Python version 2.5 or newer required. Found 2.4.3.final.0
Or just change the string in stgit/version.py.
--
Catalin
^ permalink raw reply
* Re: Using git with Eclipse
From: Jing Xue @ 2007-12-11 15:14 UTC (permalink / raw)
To: Wink Saville; +Cc: Shawn O. Pearce, git
In-Reply-To: <475E265D.5090106@saville.com>
Quoting Wink Saville <wink@saville.com>:
> Shawn,
> I added .metadata to exclude then used git rm to remove
> .metadata from the repository. I then cloned that
> repository to see how Eclipse would work. (As part of my
> workflow I use git as a backup so I wanted to see what would
> happen when I "restored".)
One way to deal with this might be (after excluding it from the
workspace repository) creating a sub-repository under .metadata, and
use that one for your local backup.
> As I'm sure you know with the metadata gone my existing projects
> in the Ui were gone and they have to be recreated as well as
> some Eclipse and plugin specific configuration.
> I understand you and others are working on an Eclipse plugin
> for git, will it also ignore . metadata?
>
> Do you need any testing done or is it too early? I'd be glad to
> test if you feel its solid enough that I won't lose data or if it
> uses a separate different repo then I could use both.
Egit is an Eclipse plugin, so you can always test it in an isolated
"sandbox" workspace.
Cheers.
--
Jing Xue
^ permalink raw reply
* Re: [PATCH] Invert numbers and names in the git-shortlog summary mode.
From: Pierre Habouzit @ 2007-12-11 15:24 UTC (permalink / raw)
To: Ingo Molnar
Cc: Jeff King, Jakub Narebski, Christian Couder, git, Junio C Hamano
In-Reply-To: <20071211145709.GB19427@elte.hu>
[-- Attachment #1: Type: text/plain, Size: 2023 bytes --]
On Tue, Dec 11, 2007 at 02:57:09PM +0000, Ingo Molnar wrote:
>
> * Pierre Habouzit <madcoder@debian.org> wrote:
>
> > Agreed, here is the patch that does that, and a sample output is:
> >
> > $ git shortlog -n -s -e HEAD -- builtin-commit.c
> > 11 Junio C Hamano <gitster@pobox.com>
> > 6 Johannes Schindelin <Johannes.Schindelin@gmx.de>
> > 6 Kristian Høgsberg <krh@redhat.com>
> > 2 Jeff King <peff@peff.net>
> > 1 Alex Riesen <raa.lkml@gmail.com>
> > 1 Pierre Habouzit <madcoder@debian.org>
> > 1 Shawn Bohrer <shawn.bohrer@gmail.com>
> > 1 Wincent Colaiuta <win@wincent.com>
>
> great - this looks really neat!
>
> btw., stupid question: why are the git-shortlog command line arguments
> different from git-log? I got used to things like:
>
> git-log kernel/
>
> so for me it would be natural to just do:
>
> git-shortlog -n -s kernel/
>
> but this currently produces this output:
>
> $ git-shortlog -n -s kernel/
> (reading log to summarize from standard input)
>
> which is quite a bit confusing to someone who'd like to keep as few
> details of command line arguments in his head as possible :-)
Because git-shortlog insists on you passing a reference first, HEAD is
not implicit if you pass something that looks like a path first. This is
arguably wrong. What you meant here is:
$ git-shortlog -n -s HEAD kernel/
The reason IIRC is that git-shortlog once only read things on stdin, and
this keeps backward compatbility to `git-shortlog` without any
arguments.
Sometimes history hurts :) I don't think there is much we can do on a
short timescale. Maybe the old way can be slowly deprecated, and then
git-shortlog will be able to act like git-log.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: v1.5.4 plans
From: Kristian Høgsberg @ 2007-12-11 15:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmysijhwq.fsf_-_@gitster.siamese.dyndns.org>
On Mon, 2007-12-10 at 14:37 -0800, Junio C Hamano wrote:
> * We have a handful deprecation notices in the draft release notes, but
> if I recall correctly, Nico wanted to add a few more. We need to
> come up with a wording that is easy to understand for the end users
> to decide which ancient versions will be affected.
Can we deprecate .git/branches?
Kristian
^ 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