* Re: [PATCH] Make --color available to git-status
From: Matthieu Moy @ 2007-05-06 13:58 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0705051956200.4015@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Sat, 5 May 2007, Matthieu Moy wrote:
>
>> Git has a nice colored output for status, using
>>
>> $ git runstatus --color
>>
>> However, this --color is not made available to git-status itself.
>
> AFAIR there have been attempts to enable this by default, when git-status
> is run interactively (i.e. its output is not piped). However, this proved
> to be remarkably complex, given that the output of runstatus _is_ piped.
It would definitely be cool to have it enabled by default, but just
having the option (which means in particular that users can use it in
an alias) should be the minimum.
I don't have enough experience with git hacking to do all the way you
suggest, so I'm starting with easy things ;-).
--
Matthieu
^ permalink raw reply
* Re: [PATCH] git-config: read remote config files over HTTP
From: Sven Verdoolaege @ 2007-05-06 13:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7virb6fnkv.fsf@assigned-by-dhcp.cox.net>
On Sat, May 05, 2007 at 11:55:28PM -0700, Junio C Hamano wrote:
> Sven Verdoolaege <skimo@liacs.nl> writes:
> > +static int config_from_http(config_fn_t fn, char *dest)
> > +{
> > + static char *config_temp = "config.temp";
> > + if (git_http_fetch_config(dest, config_temp))
> > + return 1;
> > + git_config_from_file(fn, config_temp);
> > + unlink(config_temp);
> > + return 0;
> > +}
>
> Not mkstemp()?
I more or less copy-pasted the way "index" is handled now.
I'll use mkstemp in the next round.
> > + if (!prefixcmp(dest, "http://"))
> > + return config_from_http(fn, dest);
> > +
>
> Shouldn't this also work for other protocols we handle via curl?
I don't think I copied the required setup for https, but ftp should work.
> > +#ifdef USE_CURL_MULTI
> > +void (*fill_active_slots)(void) = NULL;
> > +#endif
> > +
>
> I wonder if we could lose USE_CURL_MULTI around this one,...
I wondered about that too, but I wanted to make my changes as minimal
as possible. I'll drop the #ifdef in the next round.
skimo
^ permalink raw reply
* Re: [StGIT PATCH] Test "stg rebase" after "stg commit"
From: Yann Dirson @ 2007-05-06 13:39 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Catalin Marinas, git
In-Reply-To: <20070506131554.GF19253@nan92-1-81-57-214-146.fbx.proxad.net>
On Sun, May 06, 2007 at 03:15:54PM +0200, Yann Dirson wrote:
> That said, I have not looked at your testcase yet, I'll try to do this
> soon.
Oh, timeslot allocated :)
Well, this case clearly falls in the category of "actions outside
stgit that make it possible to rebase without a loss". But then it is
also clear that the action of tagging makes the committed patch
reachable, and thus the rebase loss-less.
The safety check could be possibly be rewritten as "check if current
base is reachable without using any refs from current series".
Best regards,
--
Yann.
^ permalink raw reply
* Re: [StGIT PATCH] Test "stg rebase" after "stg commit"
From: Yann Dirson @ 2007-05-06 13:15 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Catalin Marinas, git
In-Reply-To: <20070506122116.GA18883@diana.vm.bytemark.co.uk>
On Sun, May 06, 2007 at 02:21:16PM +0200, Karl Hasselström wrote:
> On 2007-05-04 10:13:21 +0200, Karl Hasselström wrote:
>
> > 2. Try to commit a patch, and then rebase. This doesn't work,
> > because "stg rebase" aborts if orig-base != base, and "stg
> > commit" doesn't update orig-base. (It does work if "stg rebase"
> > is given the --force flag.)
> >
> > (2) shows a bug in "stg rebase"'s safety logic. I'm not sure how to
> > fix it, because I don't know how it's supposed to work in the first
> > place. (An obvious fix would be to update it whenever the base
> > changes, but that'll take some work, and I'm not convinced it can't
> > be done with les work. Yes, I'm lazy.) Yann, could you explain?
The idea of the safety logic is that by default stgit should not loose
a commit without the user knowing. That is, if you used "stg commit",
the patch you committed is most probably only reachable through the
head of your stack, and rebasing may make it unreachable (unless you
have explicitely added a new ref to it, in which case you know what
you're doing and you know you can "rebase --force").
> Another reason why this is impractical is that it's not only stgit
> that's allowed to change the base. For example, doing "stg pop -a &&
> git reset --hard foobar && stg rebase qwrtflsptk" will also trigger
> the alarm.
Sure, but "pop -a && git reset" is exactly a "rebase -n". If you use
stgit in this case instead of the plumbing, the rebase safety will not
trigger. If you use the plumbing, you're out the scope of stgit which
cannot guess what you really want, and you should use --force because
you're supposed to know better.
But well, that's the general idea, and this safety mechanism is quite
young, it is surely possible to make it better. But IMHO the base
principle when dealing with this is that we should make every effort
so the user does not unkwingly loose a commit (which was the case
without the safety). OTOH, it is sure that the safety must not be
overly zealous, or we'll just end up teaching users to --force without
thinking.
That said, I have not looked at your testcase yet, I'll try to do this
soon.
Best regards,
--
Yann.
^ permalink raw reply
* Documentation Bugs
From: Uwe Kleine-König @ 2007-05-06 13:09 UTC (permalink / raw)
To: Git Mailing List
Hello,
1) git-fetch(1) (from maint) states:
-q, --quiet
Pass --quiet to git-fetch-pack and silence any other internally
used programs.
but git-fetch doesn't like -q. (master has
a858c006fae17cef44dd63737771f2bebb6eeae8, but maint only has
42905294de0c1885f5636319c4790f184d767875)
Maybe more difficult:
2) rebase a merged tree:
If I made a local commit and pulled from origin, I get:
zeisberg@cassiopeia:~/gsrc/git$ git show
commit 15386213004a20dfdf92c654c737795079202545
Merge: 9d740f0... 9159afb...
Author: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
Date: Sun May 6 14:49:59 2007 +0200
Merge branch 'master' of git://git.kernel.org/pub/scm/git/git
zeisberg@cassiopeia:~/gsrc/git$ git rebase junio/master
Current branch master is up to date.
(where junio/master is the tracking branch for
git://git.kernel.org/pub/scm/git/git) but git-rebase(1) states:
All changes made by commits in the current branch but that are
not in <upstream> are saved to a temporary area. This is the
same set of commits that would be shown by git log
<upstream>..HEAD.
and git-log junio/master..HEAD is not empty.
I didn't have the time to look into 2). So I only report it for now.
Best regards
Uwe
--
Uwe Kleine-König
http://www.google.com/search?q=sin%28pi%2F2%29
^ permalink raw reply
* Re: FFmpeg considering GIT
From: Karl Hasselström @ 2007-05-06 13:03 UTC (permalink / raw)
To: Marco Costalba; +Cc: Carl Worth, Michael Niedermayer, git, Pavel Roskin
In-Reply-To: <20070506125938.GA19317@diana.vm.bytemark.co.uk>
On 2007-05-06 14:59:38 +0200, Karl Hasselström wrote:
> Nope, no luck. I get the same error messages from autoreconf:
>
> kha@yoghurt:~/qgit> autoreconf -i
> automake: configure.ac: installing `config/install-sh'
> automake: configure.ac: installing `config/mkinstalldirs'
> automake: configure.ac: installing `config/missing'
> automake: configure.ac: installing `config/config.guess'
> automake: configure.ac: installing `config/config.sub'
> automake: Makefile.am: installing `./INSTALL'
> automake: Makefile.am: required file `./NEWS' not found
> automake: Makefile.am: required file `./AUTHORS' not found
> configure.ac: 9: required file `./[config.h].in' not found
> src/Makefile.am:30: invalid unused variable name: `nodist_qgit_SOURCES'
> autoreconf: automake failed with exit status: 1
Well, actually some luck. This line was first in my previous output,
but doesn't appear with your patch:
configure.ac: 9: `automake requires `AM_CONFIG_HEADER', not `AC_CONFIG_HEADER'
But there seems to be more stuff to fix. :-(
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: FFmpeg considering GIT
From: Karl Hasselström @ 2007-05-06 12:59 UTC (permalink / raw)
To: Marco Costalba; +Cc: Carl Worth, Michael Niedermayer, git, Pavel Roskin
In-Reply-To: <e5bfff550705060533x18f63c09rc6a742058b82f712@mail.gmail.com>
On 2007-05-06 14:33:59 +0200, Marco Costalba wrote:
> After googling a little bit....
>
> Please apply this patch before to run 'autoreconf -i' on a *fresh
> cloned* repository
>
> diff --git a/configure.ac b/configure.ac
> index e352eba..95f45d1 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -6,7 +6,7 @@ AC_INIT(qgit, 1.5.5)
> AC_CONFIG_AUX_DIR(config)
> AM_INIT_AUTOMAKE(foreign 1.8)
> AC_CONFIG_SRCDIR([src/annotate.cpp])
> -AC_CONFIG_HEADER([config.h])
> +AM_CONFIG_HEADER([config.h])
>
> # Checks for programs.
> AC_LANG(C++)
>
>
> On my box it compiles the same and perhaps you can avoid the
> reported errors. Please, let me know how it goes.
Nope, no luck. I get the same error messages from autoreconf:
kha@yoghurt:~/qgit> autoreconf -i
automake: configure.ac: installing `config/install-sh'
automake: configure.ac: installing `config/mkinstalldirs'
automake: configure.ac: installing `config/missing'
automake: configure.ac: installing `config/config.guess'
automake: configure.ac: installing `config/config.sub'
automake: Makefile.am: installing `./INSTALL'
automake: Makefile.am: required file `./NEWS' not found
automake: Makefile.am: required file `./AUTHORS' not found
configure.ac: 9: required file `./[config.h].in' not found
src/Makefile.am:30: invalid unused variable name: `nodist_qgit_SOURCES'
autoreconf: automake failed with exit status: 1
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: FFmpeg considering GIT
From: Marco Costalba @ 2007-05-06 12:33 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Carl Worth, Michael Niedermayer, git, Pavel Roskin
In-Reply-To: <e5bfff550705060519s2c1abd7cl7ecedeb497e10e3b@mail.gmail.com>
On 5/6/07, Marco Costalba <mcostalba@gmail.com> wrote:
> On 5/6/07, Karl Hasselström <kha@treskal.com> wrote:
> > On 2007-05-06 10:15:16 +0200, Marco Costalba wrote:
> >
> > > Use qgit ;-)
> >
> > Do I have to use any particular autoconf version? With
> >
>
After googling a little bit....
Please apply this patch before to run 'autoreconf -i' on a *fresh
cloned* repository
diff --git a/configure.ac b/configure.ac
index e352eba..95f45d1 100644
--- a/configure.ac
+++ b/configure.ac
@@ -6,7 +6,7 @@ AC_INIT(qgit, 1.5.5)
AC_CONFIG_AUX_DIR(config)
AM_INIT_AUTOMAKE(foreign 1.8)
AC_CONFIG_SRCDIR([src/annotate.cpp])
-AC_CONFIG_HEADER([config.h])
+AM_CONFIG_HEADER([config.h])
# Checks for programs.
AC_LANG(C++)
On my box it compiles the same and perhaps you can avoid the reported errors.
Please, let me know how it goes.
Marco
^ permalink raw reply related
* Re: FFmpeg considering GIT
From: Karl Hasselström @ 2007-05-06 12:33 UTC (permalink / raw)
To: Marco Costalba; +Cc: Carl Worth, Michael Niedermayer, git, Pavel Roskin
In-Reply-To: <e5bfff550705060519s2c1abd7cl7ecedeb497e10e3b@mail.gmail.com>
On 2007-05-06 14:19:55 +0200, Marco Costalba wrote:
> In the mean time you can download the released tarball from
> http://prdownloads.sourceforge.net/qgit/qgit-1.5.5.tar.bz2?download
>
> You don't need autoreconf in that case and can go directly with
>
> configure/make/make install-strip
Works like a charm. Thanks.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [StGIT PATCH] Test "stg rebase" after "stg commit"
From: Karl Hasselström @ 2007-05-06 12:21 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, Yann Dirson
In-Reply-To: <20070504081021.14786.77675.stgit@yoghurt>
On 2007-05-04 10:13:21 +0200, Karl Hasselström wrote:
> 2. Try to commit a patch, and then rebase. This doesn't work,
> because "stg rebase" aborts if orig-base != base, and "stg
> commit" doesn't update orig-base. (It does work if "stg rebase"
> is given the --force flag.)
>
> (2) shows a bug in "stg rebase"'s safety logic. I'm not sure how to
> fix it, because I don't know how it's supposed to work in the first
> place. (An obvious fix would be to update it whenever the base
> changes, but that'll take some work, and I'm not convinced it can't
> be done with les work. Yes, I'm lazy.) Yann, could you explain?
Another reason why this is impractical is that it's not only stgit
that's allowed to change the base. For example, doing "stg pop -a &&
git reset --hard foobar && stg rebase qwrtflsptk" will also trigger
the alarm.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: FFmpeg considering GIT
From: Marco Costalba @ 2007-05-06 12:19 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Carl Worth, Michael Niedermayer, git, Pavel Roskin
In-Reply-To: <20070506111411.GC17498@diana.vm.bytemark.co.uk>
On 5/6/07, Karl Hasselström <kha@treskal.com> wrote:
> On 2007-05-06 10:15:16 +0200, Marco Costalba wrote:
>
> > Use qgit ;-)
>
> Do I have to use any particular autoconf version? With
>
Sorry but I cannot reproduce the misbehaviour, my logs are below.
The only difference is that my autoreconf is 2.61 instead of 2.60
Pavel, some ideas?
In the mean time you can download the released tarball from
http://prdownloads.sourceforge.net/qgit/qgit-1.5.5.tar.bz2?download
You don't need autoreconf in that case and can go directly with
configure/make/make install-strip
My log:
bash-3.1$ git clone git://git.kernel.org/pub/scm/qgit/qgit.git
Initialized empty Git repository in /home/marco/tmp/qgit/.git/
remote: Generating pack...
remote: Done counting 5723 objects.
remote: Deltifying 5723 objects.
remote: 100% (5723/5723) done
Indexing 5723 objects...
remote: Total 5723 (delta 4541), reused 5612 (delta 4461)
100% (5723/5723) done
Resolving 4541 deltas...
100% (4541/4541) done
bash-3.1$ cd qgit
bash-3.1$ autoreconf --version
autoreconf (GNU Autoconf) 2.61
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software. You may redistribute copies of it under the terms of
the GNU General Public License <http://www.gnu.org/licenses/gpl.html>.
There is NO WARRANTY, to the extent permitted by law.
Written by David J. MacKenzie and Akim Demaille.
bash-3.1$ autoreconf -i
configure.ac: installing `config/install-sh'
configure.ac: installing `config/missing'
src/Makefile.am: installing `config/depcomp'
bash-3.1$ ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for g++... g++
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 g++ accepts -g... yes
checking for style of include used by make... GNU
checking dependency style of g++... gcc3
checking for a BSD-compatible install... /usr/bin/install -c
checking for prefix by checking for qgit... /home/marco/bin/qgit
checking how to run the C++ preprocessor... g++ -E
checking for X... libraries , headers
checking for gethostbyname... yes
checking for connect... yes
checking for remove... yes
checking for shmat... yes
checking for IceConnectionNumber in -lICE... yes
checking for Qt includes... /usr/lib/qt3//include
checking Qt version... 3.3.8
checking for moc... /usr/lib/qt3//bin/moc
checking for uic... /usr/lib/qt3//bin/uic
checking for pthread_exit in -lpthread... yes
checking for XftFontOpen in -lXft... yes
checking for main in -lqt-mt... yes
configure: QT_CPPFLAGS = -I/usr/lib/qt3//include -D_REENTRANT
-DQT_THREAD_SUPPORT
configure: QT_LDFLAGS = -L/usr/lib/qt3//lib
configure: QT_LIBS = -lqt-mt -lpthread -lXft -lSM -lICE -lX11
configure: creating ./config.status
config.status: creating Makefile
config.status: creating src/Makefile
config.status: creating config.h
config.status: executing depfiles commands
bash-3.1$ make
make all-recursive
make[1]: Entering directory `/home/marco/tmp/qgit'
Making all in src
make[2]: Entering directory `/home/marco/tmp/qgit/src'
/usr/lib/qt3//bin/uic -o commitbase.h commitbase.ui
/usr/lib/qt3//bin/uic -o consolebase.h consolebase.ui
-------------- cut ---------------------
if g++ -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -I/usr/lib/qt3//include
-D_REENTRANT -DQT_THREAD_SUPPORT -g -O2 -Wall -Wno-non-virtual-dtor
-W -Wno-long-long -pedantic -frepo -MT settingsbase.uic.o -MD -MP -MF
".deps/settingsbase.uic.Tpo" -c -o settingsbase.uic.o
settingsbase.uic.cc; \
then mv -f ".deps/settingsbase.uic.Tpo"
".deps/settingsbase.uic.Po"; else rm -f ".deps/settingsbase.uic.Tpo";
exit 1; fi
g++ -g -O2 -Wall -Wno-non-virtual-dtor -W -Wno-long-long -pedantic
-frepo -L/usr/lib/qt3//lib -o qgit annotate.o cache.o commitimpl.o
consoleimpl.o customactionimpl.o dataloader.o domain.o
exceptionmanager.o filecontent.o filelist.o fileview.o git.o
git_startup.o lanes.o listview.o mainimpl.o myprocess.o
namespace_def.o patchview.o qgit.o rangeselectimpl.o revdesc.o
revsview.o settingsimpl.o treeview.o commitbase.moc.o
consolebase.moc.o customactionbase.moc.o filebase.moc.o helpbase.moc.o
mainbase.moc.o patchbase.moc.o rangeselectbase.moc.o revbase.moc.o
settingsbase.moc.o annotate.moc.o commitimpl.moc.o consoleimpl.moc.o
customactionimpl.moc.o dataloader.moc.o domain.moc.o filecontent.moc.o
filelist.moc.o fileview.moc.o git.moc.o listview.moc.o mainimpl.moc.o
myprocess.moc.o patchview.moc.o rangeselectimpl.moc.o revdesc.moc.o
revsview.moc.o settingsimpl.moc.o treeview.moc.o commitbase.uic.o
consolebase.uic.o customactionbase.uic.o filebase.uic.o helpbase.uic.o
mainbase.uic.o patchbase.uic.o rangeselectbase.uic.o revbase.uic.o
settingsbase.uic.o -lqt-mt -lpthread -lXft -lSM -lICE -lX11
collect: recompiling patchview.cpp
collect: recompiling mainimpl.cpp
collect: recompiling git_startup.cpp
collect: recompiling git.cpp
-------------- cut ---------------------
collect: relinking
collect: recompiling mainimpl.cpp
collect: recompiling git_startup.cpp
collect: recompiling git.cpp
collect: recompiling annotate.cpp
collect: relinking
make[3]: Leaving directory `/home/marco/tmp/qgit/src'
make[2]: Leaving directory `/home/marco/tmp/qgit/src'
make[2]: Entering directory `/home/marco/tmp/qgit'
make[2]: Nothing to be done for `all-am'.
make[2]: Leaving directory `/home/marco/tmp/qgit'
make[1]: Leaving directory `/home/marco/tmp/qgit'
bash-3.1$ make install-strip
make INSTALL_PROGRAM="/bin/sh /home/marco/tmp/qgit/config/install-sh -c -s" \
install_sh_PROGRAM="/bin/sh
/home/marco/tmp/qgit/config/install-sh -c -s" INSTALL_STRIP_FLAG=-s \
`test -z '' || \
echo "INSTALL_PROGRAM_ENV=STRIPPROG=''"` install
make[1]: Entering directory `/home/marco/tmp/qgit'
Making install in src
make[2]: Entering directory `/home/marco/tmp/qgit/src'
make install-am
-------------- cut ---------------------
make[2]: Leaving directory `/home/marco/tmp/qgit'
make[1]: Leaving directory `/home/marco/tmp/qgit'
bash-3.1$ qgit
Found GNU source-highlight 2.5
Saving cache. Please wait...
Compressing data...
Done.
bash-3.1$
^ permalink raw reply
* Re: FFmpeg considering GIT
From: Karl Hasselström @ 2007-05-06 11:14 UTC (permalink / raw)
To: Marco Costalba; +Cc: Carl Worth, Michael Niedermayer, git
In-Reply-To: <e5bfff550705060115o60fdd637h6c7393d06f75c55@mail.gmail.com>
On 2007-05-06 10:15:16 +0200, Marco Costalba wrote:
> Use qgit ;-)
Do I have to use any particular autoconf version? With
kha@yoghurt:~/qgit> autoreconf --version
autoreconf (GNU Autoconf) 2.60
I get a few warnings and errors when I run "autoreconf -i", and the
generated configure script has bugs that prevent it from finishing
successfully. (I'm trying to build qgit
4facdd5fc1731662ff9cdf096a576d40b938885c.)
Output follows:
kha@yoghurt:~/qgit> autoreconf -i
configure.ac: 9: `automake requires `AM_CONFIG_HEADER', not `AC_CONFIG_HEADER'
automake: configure.ac: installing `config/install-sh'
automake: configure.ac: installing `config/mkinstalldirs'
automake: configure.ac: installing `config/missing'
automake: configure.ac: installing `config/config.guess'
automake: configure.ac: installing `config/config.sub'
automake: Makefile.am: installing `./INSTALL'
automake: Makefile.am: required file `./NEWS' not found
automake: Makefile.am: required file `./AUTHORS' not found
configure.ac: 9: required file `./[config.h].in' not found
src/Makefile.am:30: invalid unused variable name: `nodist_qgit_SOURCES'
autoreconf: automake failed with exit status: 1
kha@yoghurt:~/qgit> ./configure --prefix=/usr/local/stow/qgit
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets $(MAKE)... yes
./configure: line 1874: 1.8: command not found
checking for working aclocal-1.4... found
checking for working autoconf... found
checking for working automake-1.4... found
checking for working autoheader... found
checking for working makeinfo... found
checking for g++... g++
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 g++ accepts -g... yes
checking for a BSD-compatible install... /usr/bin/install -c
checking how to run the C++ preprocessor... g++ -E
checking for X... libraries , headers
checking for gethostbyname... yes
checking for connect... yes
checking for remove... yes
checking for shmat... yes
checking for IceConnectionNumber in -lICE... yes
checking for Qt includes... /usr/share/qt3/include
checking Qt version... 3.3.6
checking for moc... /usr/share/qt3/bin/moc
checking for uic... /usr/share/qt3/bin/uic
checking for pthread_exit in -lpthread... yes
checking for XftFontOpen in -lXft... yes
checking for main in -lqt-mt... yes
configure: QT_CPPFLAGS = -I/usr/share/qt3/include -D_REENTRANT -DQT_THREAD_SUPPORT
configure: QT_LDFLAGS = -L/usr/share/qt3/lib
configure: QT_LIBS = -lqt-mt -lpthread -lXft -lSM -lICE -lX11
configure: creating ./config.status
config.status: creating Makefile
config.status: WARNING: Makefile.in seems to ignore the --datarootdir setting
config.status: creating src/Makefile
config.status: WARNING: src/Makefile.in seems to ignore the --datarootdir setting
config.status: creating config.h
kha@yoghurt:~/qgit> make
make[1]: Entering directory `/home/kha/qgit'
cd . && autoheader
make[1]: Leaving directory `/home/kha/qgit'
cd . \
&& CONFIG_FILES= CONFIG_HEADERS=[config.h] \
/bin/bash ./config.status
config.status: error: cannot find input file: [config.h].in
make: *** [stamp-h] Error 1
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [RFC PATCH] Rename "bury" back to "sink".
From: Karl Hasselström @ 2007-05-06 10:49 UTC (permalink / raw)
To: Yann Dirson; +Cc: Jakub Narebski, Catalin Marinas, git
In-Reply-To: <20070505201307.GE19253@nan92-1-81-57-214-146.fbx.proxad.net>
On 2007-05-05 22:13:07 +0200, Yann Dirson wrote:
> The whole debate around burying, sinking and floating patches made
> me think a bit more about this. So we have:
>
> float: move specified patches to top of stack
> bury/float: move specified patches to bottom of stack or any place
> in the stack identified by a nearby patch
>
> All in all, that all "move specified patches to a specified place".
> So wouldn't it be possible to end the debate by merging those
> commands into a single "stg move" command ?
I like that idea.
stg move patch1 --bottom
stg move patch1 --top
stg move patch1 --before other-patch
stg move patch1 --after other-patch
stg move patch1 --position 17 # move to absolute pos. 17 (bottom is 0)
stg move patch1 --up 3 # move 3 steps up
stg move patch1 --down 2 # move 2 steps down
Or something. It could also be made to work with patch ranges as well
as single patches.
> Side note about the "stg move" name: yes it could possible to
> mistake it for "move file" (especially as we don't have "stg mv").
> My current state of mind would be to drop add/rm/cp from stgit, and
> move the "stg cp" logic to a new git-cp command. This way, stgit
> would just be about handling series of patches, with git being used
> for the working-copy. Any opinions on this ?
I would be in favor; I like to think of stgit as extending rather than
providing a complete replacement for the plain git porcelain. But as I
recall, Catalin didn't share my view on this. Better let him answer
the question himself than rely on my memory, though. ;-)
> Now to the new command. We could have something like:
>
> stg move -t base <patches> <=> stg sink <patches>
> stg move -t <patch> <patches> <=> stg sink -t <patch> <patches>
> stg move -t current <patches> <=> stg float <patches>
>
> Note the introduction of a new "curent" stg_id for the tip of the
> stack.
Ah, I wrote my suggested syntax above before reading yours. I like
mine better, though. :-)
> "-s [<series>]" would be allowed as an alternative to <patches>, so
> "move" would be a strict superset of "float".
Another useful option would be to have --interactive open up an editor
with the patch names in it; the user could rearrange the lines any way
she pleased, and when the editor exits, the patch series is rearranged
to match.
> If the target point is in $unapplied, then the command will be
> equivalent to "stg pop <patches>" with those patches reordered at
> the target (ie. no need to really execute steps 2 and 3 above).
> That's no rocket science, but a useful I have already missed, eg.
> when I just want to move the patches away from my working set
> (nowadays we could hide them, but that may not be always adequate).
Sounds very good.
> Opinions?
Lots, as you just saw. :-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: FFmpeg considering GIT
From: Karl Hasselström @ 2007-05-06 10:19 UTC (permalink / raw)
To: Linus Torvalds
Cc: Paul Mackerras, Junio C Hamano, Carl Worth, Michael Niedermayer,
Git Mailing List
In-Reply-To: <alpine.LFD.0.98.0705051019580.3819@woody.linux-foundation.org>
On 2007-05-05 10:26:12 -0700, Linus Torvalds wrote:
> The "-S" thing doesn't really interact well with "gitk", because it
> doesn't rewrite the parent information (it is basically just a "hide
> commits that don't pass this criteria"). As such, gitk, which
> requires parent information to generate the graph, is not very
> amenable to using "-S" and such.
>
> That said, you can apply this fairly trivial patch to "gitk" to make
> it parse the output of "git log" rather than "git rev-list", and
> that will actually get you working -S'xyz' parsing automatically.
> It's just that the commit history window will look like crap.
OK, now I've tested it, and just as you said, it works (and is _very_
useful) but looks like crap. :-)
Is there any fundamental reason why
gitk -- some/path/name
generates a nice, connected graph, while
gitk -S'some string'
generates disconnected spaghetti? Or could the latter be made to use
the same parent-rewriting logic as the first?
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: 'upstream' branches.
From: Alex Riesen @ 2007-05-06 9:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Woodhouse, git, Linus Torvalds
In-Reply-To: <7vy7k2e606.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano, Sun, May 06, 2007 10:00:25 +0200:
>
> > Is that possible? I'm fairly sure it used to be.
>
> I doubt we had that bug. If you allowed overwriting with +, it
> would not have prevented a rewind (i.e. pull from Linus and then
> pull from somebody who pulled from Linus earlier than you did).
> If you didn't, then it would have failed the fetch.
>
Maybe we should not fail in the case the remote repo is older then
local, but just to try to fast-forward local reference after a fetch
and fail only if the fast-forward fails?
Or introduce a new syntax for the strict reference succession and make
fetch+fast-forward the default?
Or the other way around, use something like "-from:to" to ignore
fast-forwards failed because the "from" already has all the "to" has,
which has precedents: make and its "-include", which ignores errors
from non-existing files.
Let us the local repo being in history younger then the remote:
Whole history (anywhere) : A--B--C--D
Local has (branch Tracking) : A--B
Remote1 (where the Local is doing a fetch from): A--B--C
Normal case, fetch will just update its reference in Local. It is now
at C.
Now suppose we have another remote Remote2, which is on B still. If
Local does a fetch from that, usually the operation will fail. But if
we do, for example, a fetch from Remote2 and store its reference
locally somewhere and then try to merge Local with the stored
reference, it shall result in nothing: everything's already merged:
$ git branch
* master
Tracking
$ git fetch Remote1 master:Tracking
...reference Tracking updated
$ git fetch Remote2 master:tmp
$ git checkout Tracking
$ git merge tmp
Already up-to-date.
$ git branch -d tmp
$ git checkout master
^ permalink raw reply
* What's cooking in git.git (topics)
From: Junio C Hamano @ 2007-05-06 8:53 UTC (permalink / raw)
To: git
In-Reply-To: <7v3b2jdo9h.fsf@assigned-by-dhcp.cox.net>
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'. The topics list the commits in reverse chronological
order.
As I have been sick and am mostly concentrating on fixes on
'master' anyway, there aren't much to see here. Indeed,
'master' and 'next' still have identical trees.
* fl/cvsserver (Wed May 2 02:45:22 2007 +0200) 1 commit
- cvsserver: Add test cases for git-cvsserver
I need to ask k.org people to install sqlite and
libdvd-sqlite-perl before I can advance this to 'next'.
* jc/blame (Fri Apr 20 16:25:50 2007 -0700) 4 commits
- blame: show log as it goes
- git-blame: optimize get_origin() from linear search to hash-
lookup.
- git-blame: pass "struct scoreboard *" pointers around.
- blame: lift structure definitions up
^ permalink raw reply
* What's in git.git (stable)
From: Junio C Hamano @ 2007-05-06 8:53 UTC (permalink / raw)
To: git
In-Reply-To: <7v4pmzdo9o.fsf@assigned-by-dhcp.cox.net>
Master is at v1.5.2-rc2; maint is probably ready to produce
v1.5.1.4, but not tonight.
Here are two draft release notes, followed by the usual "What's in"
summaries.
----------------------------------------------------------------
GIT v1.5.1.4 Release Notes (draft)
==========================
Fixes since v1.5.1.3
--------------------
* Bugfixes
- "git-http-fetch" did not work around a bug in libcurl
earlier than 7.16 (curl_multi_remove_handle() was broken).
- "git cvsserver" handles a file that was once removed and
then added again correctly.
- import-tars script (in contrib/) handles GNU tar archives
that contain pathnames longer than 100 bytes (long-link
extension) correctly.
- xdelta test program did not build correctly.
- gitweb sometimes tried incorrectly to apply function to
decode utf8 twice, resulting in corrupt output.
- "git blame -C" mishandled text at the end of a group of
lines.
- "git log/rev-list --boundary" did not produce output
correctly without --left-right option.
----------------------------------------------------------------
GIT v1.5.2 Release Notes (draft)
========================
Updates since v1.5.1
--------------------
* Plumbing level subproject support.
You can include a subdirectory that has an independent git
repository in your index and tree objects as a
"subproject". This plumbing (i.e. "core") level subproject
support explicitly excludes recursive behaviour.
The "subproject" entries in the index and trees are
incompatible with older versions of git. Experimenting with
the plumbing level support is encouraged, but be warned that
unless everybody in your project updates to this release or
later, using this feature would make your project
inaccessible by people with older versions of git.
* Plumbing level gitattributes support.
The gitattributes mechanism allows you to add 'attributes' to
paths in your project, and affect the way certain git
operations work. Currently you can influence if a path is
considered a binary or text (the former would be treated by
'git diff' not to produce textual output; the latter can go
through the line endings conversion process in repositories
with core.autocrlf set), expand and unexpand '$ident$' keyword
with blob object name, specify a custom 3-way merge driver,
and specify a custom diff driver. You can also apply
arbitrary filter to contents on check-in/check-out codepath
but this feature is an extremely sharp-edged razor and needs
to be handled with caution (do not use it unless you
understand the earlier mailing list discussion on keyward
expansion).
* The packfile format now optionally suports 64-bit index.
This release supports the "version 2" format of the .idx
file. This is automatically enabled when a huge packfile
needs more than 32-bit to express offsets of objects in the
pack
* New commands and options.
- "git bisect start" can optionally take a single bad commit and
zero or more good commits on the command line.
- "git shortlog" can optionally be told to wrap its output.
- "subtree" merge strategy allows another project to be merged in as
your subdirectory.
- "git format-patch" learned a new --subject-prefix=<string>
option, to override the built-in "[PATCH]".
- "git add -u" is a quick way to do the first stage of "git
commit -a" (i.e. update the index to match the working
tree); it obviously does not make a commit.
- "git clean" honors a new configuration, "clean.requireforce". When
set to true, this makes "git clean" a no-op, preventing you
from losing files by typing "git clean" when you meant to
say "make clean". You can still say "git clean -f" to
override this.
- "git log" family of commands learned --date={local,relative,default}
option. --date=relative is synonym to the --relative-date.
--date=local gives the timestamp in local timezone.
* Updated behavior of existing commands.
- When $GIT_COMMITTER_EMAIL or $GIT_AUTHOR_EMAIL is not set
but $EMAIL is set, the latter is used as a substitute.
- "git diff --stat" shows size of preimage and postimage blobs
for binary contents. Earlier it only said "Bin".
- "git lost-found" shows stuff that are unreachable except
from reflogs.
- "git checkout branch^0" now detaches HEAD at the tip commit
on the named branch, instead of just switching to the
branch (use "git checkout branch" to switch to the branch,
as before).
- "git bisect next" can be used after giving only a bad commit
without giving a good one (this starts bisection half-way to
the root commit). We used to refuse to operate without a
good and a bad commit.
- "git push", when pushing into more than one repository, does
not stop at the first error.
- "git archive" does not insist you to give --format parameter
anymore; it defaults to "tar".
- "git cvsserver" can use backends other than sqlite.
- "gitview" (in contrib/ section) learned to better support
"git-annotate".
- "git diff $commit1:$path2 $commit2:$path2" can now report
mode changes between the two blobs.
- Local "git fetch" from a repository whose object store is
one of the alternates (e.g. fetching from the origin in a
repository created with "git clone -l -s") avoids
downloading objects unnecessary.
- "git blame" uses .mailmap to canonicalize the author name
just like "git shortlog" does.
* Builds
- git-p4import has never been installed; now there is an
installation option to do so.
- gitk and git-gui can be configured out.
- Generated documentation pages automatically get version
information from GIT_VERSION
- Parallel build with "make -j" descending into subdirectory
was fixed.
* Performance Tweaks
- Optimized "git-rev-list --bisect" (hence "git-bisect").
- Optimized "git-add $path" in a large directory, most of
whose contents are ignored.
- The recursive merge strategy updated a worktree file that
was changed identically in two branches, when one of them
renamed it. We do not do that when there is no rename, so
match that behaviour.
Fixes since v1.5.1
------------------
All of the fixes in v1.5.1 maintenance series are included in
this release, unless otherwise noted.
* Bugfixes
- Switching branches with "git checkout" refused to work when
a path changes from a file to a directory between the
current branch and the new branch, in order not to lose
possible local changes in the directory that is being turned
into a file with the switch. We now allow such a branch
switch after making sure that there is no locally modified
file nor un-ignored file in the directory. This has not
been backported to 1.5.1.x series, as it is rather an
intrusive change.
- Merging branches that have a file in one and a directory in
another at the same path used to get quite confused. We
handle such a case a bit more carefully, even though that is
still left as a conflict for the user to sort out. This
will not be backported to 1.5.1.x series, as it is rather an
intrusive change.
- git-fetch had trouble with a remote with insanely large number
of refs.
[[[jc: I'll probably copy&paste v1.5.1.X release notes here, or
refer readers to those separate documents. I haven't decided
which way I would go, but I am inclined to do the latter.]]]
----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.
Alex Riesen (1):
Small correction in reading of commit headers
Alexandre Julliard (1):
http-fetch: Disable use of curl multi support for libcurl < 7.16.
Arjen Laarhoven (1):
Document 'opendiff' value in config.txt and git-mergetool.txt
Bryan Larsen (2):
Allow PERL_PATH="/usr/bin/env perl"
posix compatibility for t4200
Carl Worth (1):
Mention version 1.5.1 in tutorial and user-manual
Daniel Barkalow (1):
Make xstrndup common
Frank Lichtenheld (1):
cvsserver: Handle re-added files correctly
Ismail Dönmez (1):
gitweb: use decode_utf8 directly
Jakub Narebski (1):
diff format documentation: describe raw combined diff format
James Bowes (1):
Documentation: fix typo in git-remote.txt
Johannes Schindelin (1):
Teach import-tars about GNU tar's @LongLink extension.
Junio C Hamano (4):
diff.c: fix "size cache" handling.
blame: Notice a wholesale incorporation of an existing file.
blame: -C -C -C
Add test for blame corner cases.
Karl Hasselström (2):
Fix markup in git-svn man page
Add --no-rebase option to git-svn dcommit
Linus Torvalds (1):
Fix --boundary output
Martin Koegler (1):
Fix compilation of test-delta
* The 'master' branch has these since the last announcement
in addition to the above.
Alex Riesen (1):
Handle return code of parse_commit in revision machinery
Dana L. How (1):
Create pack-write.c for common pack writing code
Jonas Fonseca (1):
git-tag(1): -v option is a subcommand; fix code block
Junio C Hamano (2):
blame: use .mailmap unconditionally
GIT v1.5.2-rc2
Shawn O. Pearce (3):
Reuse fixup_pack_header_footer in index-pack
Don't use seq in tests, not everyone has it
Improve request-pull to handle non-rebased branches
^ permalink raw reply
* [PATCH] diff: use filespec as in-place size cache
From: Junio C Hamano @ 2007-05-06 8:51 UTC (permalink / raw)
To: git
In-Reply-To: <7vr6pucp9e.fsf@assigned-by-dhcp.cox.net>
When we have a filespec primed with size, later size_only
request should be fillable without recomputing it.
---
diff --git a/diff.c b/diff.c
index 0f8c68f..fb3eba5 100644
--- a/diff.c
+++ b/diff.c
@@ -1515,6 +1515,9 @@ int diff_populate_filespec(struct diff_filespec *s, int size_only)
if (s->data)
return err;
+ if (size_only && 0 < s->size)
+ return err;
+
if (S_ISDIRLNK(s->mode))
return diff_populate_gitlink(s, size_only);
^ permalink raw reply related
* [PATCH] diff.c: truly honor size_only request for populate_filespec.
From: Junio C Hamano @ 2007-05-06 8:49 UTC (permalink / raw)
To: git
In-Reply-To: <7vr6pucp9e.fsf@assigned-by-dhcp.cox.net>
For some reason we did not honor size_only requests when "size cache"
was in use. They should be independent.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* I think this is a right fix. When used together with other
patches, it seems to help reducing the memory footprint a
bit, but by itself not that much and it seems to have
slightly negative performance impact.
diff.c | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/diff.c b/diff.c
index 7bbe759..02c9467 100644
--- a/diff.c
+++ b/diff.c
@@ -1503,9 +1503,6 @@ int diff_populate_filespec(struct diff_filespec *s, int size_only)
if (S_ISDIR(s->mode))
return -1;
- if (!use_size_cache)
- size_only = 0;
-
if (s->data)
return err;
--
1.5.2.rc1.697.g5086
^ permalink raw reply related
* [PATCH] diff: release blobs after generating textual diff.
From: Junio C Hamano @ 2007-05-06 8:47 UTC (permalink / raw)
To: git
This reduces the memory pressure when dealing with many paths.
An unscientific test of running "diff-tree --stat --summary -M"
between v2.6.19 and v2.6.20-rc1 in the linux kernel repository
indicates that the number of minor faults are reduced by 2/3
(153k vs 49k).
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* This is still a WIP, not in the sense that it breaks anything
(it doesn't seem to), but in the sense that it is not known
if it is useful in general and would make that much of a
difference with a project much larger than the kernel.
diff --git a/diff.c b/diff.c
index 7bbe759..9de053c 100644
--- a/diff.c
+++ b/diff.c
@@ -1236,6 +1236,8 @@ static void builtin_diff(const char *name_a,
}
free_ab_and_return:
+ diff_free_filespec_data(one);
+ diff_free_filespec_data(two);
free(a_one);
free(b_two);
return;
@@ -1262,7 +1264,7 @@ static void builtin_diffstat(const char *name_a, const char *name_b,
diff_populate_filespec(two, 0);
data->deleted = count_lines(one->data, one->size);
data->added = count_lines(two->data, two->size);
- return;
+ goto free_and_return;
}
if (fill_mmfile(&mf1, one) < 0 || fill_mmfile(&mf2, two) < 0)
die("unable to read files to diff");
@@ -1284,6 +1286,10 @@ static void builtin_diffstat(const char *name_a, const char *name_b,
ecb.priv = diffstat;
xdl_diff(&mf1, &mf2, &xpp, &xecfg, &ecb);
}
+
+ free_and_return:
+ diff_free_filespec_data(one);
+ diff_free_filespec_data(two);
}
static void builtin_checkdiff(const char *name_a, const char *name_b,
@@ -1306,7 +1312,7 @@ static void builtin_checkdiff(const char *name_a, const char *name_b,
die("unable to read files to diff");
if (file_is_binary(two))
- return;
+ goto free_and_return;
else {
/* Crazy xdl interfaces.. */
xpparam_t xpp;
@@ -1320,6 +1326,9 @@ static void builtin_checkdiff(const char *name_a, const char *name_b,
ecb.priv = &data;
xdl_diff(&mf1, &mf2, &xpp, &xecfg, &ecb);
}
+ free_and_return:
+ diff_free_filespec_data(one);
+ diff_free_filespec_data(two);
}
struct diff_filespec *alloc_filespec(const char *path)
^ permalink raw reply related
* Re: 'upstream' branches.
From: David Woodhouse @ 2007-05-06 8:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, git
In-Reply-To: <7vy7k2e606.fsf@assigned-by-dhcp.cox.net>
On Sun, 2007-05-06 at 01:00 -0700, Junio C Hamano wrote:
> Ahh, I did not mean by "mtd's idea" _your_ repository, but I
> meant whichever one that was overwriting your 'linus' tracking
> branch you are using to track fetch from Linus's tree.
Ah, right.
> The cleanest way to view "what do we really have since the
> latest of Linus, regardless of how and from whom we learned
> where the tip of Linus is", would be not to let other trees to
> disturb the tracking branch you use for Linus's tree with each
> other.
>
> [remote "a"] fetch = refs/heads/linus:refs/remotes/a/linus
> [remote "b"] fetch = refs/heads/linus:refs/remotes/b/linus
> [remote "c"] fetch = refs/heads/linus:refs/remotes/c/linus
> ...
You're speaking from the point of view of the git implementation.
>From the point of view of the _user_, I would violently disagree :)
Having pulled that into my local repository, how do I then set it up to
push the latest commit of refs/remotes/*/linus into the 'linus' branch
of the origin, when I push back to my public tree on the server? Or do
you expect _everyone_ who pulls from that public tree to also do stuff
like:
> git log master --not remotes/a/linus remotes/b/linus remotes/c/linus
Can't I instruct it to _merge_ the 'linus' branch of each remote into my
own 'linus' branch? Of course that merge would only ever be a
fast-forward or a no-op, in practice.
--
dwmw2
^ permalink raw reply
* Re: FFmpeg considering GIT
From: Marco Costalba @ 2007-05-06 8:15 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Carl Worth, Michael Niedermayer, git
In-Reply-To: <20070505133543.GC3379@diana.vm.bytemark.co.uk>
On 5/5/07, Karl Hasselström <kha@treskal.com> wrote:
> On 2007-05-04 11:17:05 -0700, Carl Worth wrote:
>
> I know that I can ask it to highlight commits that insert or remove
> "snippet of interest", but frequently the highlighted commits are ten
> out of ten thousand, and not that easy to find even when boldfaced.
> What I want is to make it display only those commits.
>
Use qgit ;-)
^ permalink raw reply
* Re: 'upstream' branches.
From: Junio C Hamano @ 2007-05-06 8:00 UTC (permalink / raw)
To: David Woodhouse; +Cc: Alex Riesen, git
In-Reply-To: <1178436926.17680.74.camel@shinybook.infradead.org>
David Woodhouse <dwmw2@infradead.org> writes:
> So that 'git-diff linus..' or 'git-log linus..' will show me what's
> outstanding against the master('s) tree. And scripts feeding the commits
> list can ignore those commits, etc.
>
>> On the other hand, I think it is perfectly reasonable thing to
>> want to track where the tip of Linus's tree is "from mtd tree's
>> point of view". Then diff between "mtd's idea of Linus's tip"
>> and "mtd's tip" would represent what mtd people did, regardless
>> of what Linus did in his tree, before mtd people had a chance to
>> sync again with Linus.
>
> Right. That's what I'm trying to track. And that 'idea of Linus' tip'
> needs to get updated whenever we pull from Linus' tree into our
> mtd-2.6.git tree on the server -- by whatever route, even if it's
> indirectly through another repo.
Ahh, I did not mean by "mtd's idea" _your_ repository, but I
meant whichever one that was overwriting your 'linus' tracking
branch you are using to track fetch from Linus's tree.
The cleanest way to view "what do we really have since the
latest of Linus, regardless of how and from whom we learned
where the tip of Linus is", would be not to let other trees to
disturb the tracking branch you use for Linus's tree with each
other.
[remote "a"] fetch = refs/heads/linus:refs/remotes/a/linus
[remote "b"] fetch = refs/heads/linus:refs/remotes/b/linus
[remote "c"] fetch = refs/heads/linus:refs/remotes/c/linus
...
Then
git log master --not remotes/a/linus remotes/b/linus remotes/c/linus
> Is that possible? I'm fairly sure it used to be.
I doubt we had that bug. If you allowed overwriting with +, it
would not have prevented a rewind (i.e. pull from Linus and then
pull from somebody who pulled from Linus earlier than you did).
If you didn't, then it would have failed the fetch.
^ permalink raw reply
* Re: FFmpeg considering GIT
From: Karl Hasselström @ 2007-05-06 7:56 UTC (permalink / raw)
To: Linus Torvalds
Cc: Paul Mackerras, Junio C Hamano, Carl Worth, Michael Niedermayer,
Git Mailing List
In-Reply-To: <alpine.LFD.0.98.0705051019580.3819@woody.linux-foundation.org>
Thanks for the patch! I haven't had time to try it out yet, but ...
On 2007-05-05 10:26:12 -0700, Linus Torvalds wrote:
> - error_popup "Can't parse git rev-list output: {$shortcmit}"
> + error_popup "Can't parse git git log output: {$shortcmit}"
... this error message should probably lose one of its two "git "s.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: FFmpeg considering GIT
From: Junio C Hamano @ 2007-05-06 7:49 UTC (permalink / raw)
To: Linus Torvalds
Cc: Karl Hasselstr?m, Paul Mackerras, Carl Worth, Michael Niedermayer,
Git Mailing List
In-Reply-To: <alpine.LFD.0.98.0705051524300.17381@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
>> and have the commits colored appropriately. That would be cool, but it
>> might need more tcl/tk knowledge than I actually possess).
>
> Ok, that turned out to be the case.
>
> Here's an updated patch to gitk, which at least *parses* the
> "--left-right" data properly, it just doesn't use it.
This on top of yours makes it use it.
gitk | 31 ++++++++++++++++++++++++++-----
1 files changed, 26 insertions(+), 5 deletions(-)
diff --git a/gitk b/gitk
index 0bf00ee..a6e762d 100755
--- a/gitk
+++ b/gitk
@@ -74,7 +74,7 @@ proc getcommits {} {
proc getcommitlines {fd view} {
global commitlisted nextupdate
global leftover commfd
- global displayorder commitidx commitrow commitdata
+ global displayorder commitidx commitrow commitdata commitside
global parentlist childlist children curview hlview
global vparentlist vchildlist vdisporder vcmitlisted
@@ -178,6 +178,7 @@ proc getcommitlines {fd view} {
}
set commitdata($id) [string range $cmit [expr {$j + 1}] end]
set commitrow($view,$id) $commitidx($view)
+ set commitside($id) $leftright
incr commitidx($view)
if {$view == $curview} {
lappend parentlist $olds
@@ -2986,7 +2987,7 @@ proc drawlines {id} {
proc drawcmittext {id row col rmx} {
global linespc canv canv2 canv3 canvy0 fgcolor
- global commitlisted commitinfo rowidlist
+ global commitlisted commitinfo commitside rowidlist
global rowtextx idpos idtags idheads idotherrefs
global linehtag linentag linedtag
global mainfont canvxmax boldrows boldnamerows fgcolor
@@ -2995,9 +2996,29 @@ proc drawcmittext {id row col rmx} {
set x [xc $row $col]
set y [yc $row]
set orad [expr {$linespc / 3}]
- set t [$canv create oval [expr {$x - $orad}] [expr {$y - $orad}] \
- [expr {$x + $orad - 1}] [expr {$y + $orad - 1}] \
- -fill $ofill -outline $fgcolor -width 1 -tags circle]
+
+ if {[info exists commitside($id)]} {
+ set leftright $commitside($id)
+ } else {
+ set leftright 0
+ }
+ if {$leftright == 0} {
+ set t [$canv create oval [expr {$x - $orad}] [expr {$y - $orad}] \
+ [expr {$x + $orad - 1}] [expr {$y + $orad - 1}] \
+ -fill $ofill -outline $fgcolor -width 1 -tags circle]
+ } elseif {$leftright < 0} {
+ set t [$canv create polygon \
+ [expr {$x - $orad}] $y \
+ [expr {$x + $orad - 1}] [expr {$y - $orad}] \
+ [expr {$x + $orad - 1}] [expr {$y + $orad - 1}] \
+ -fill $ofill -outline $fgcolor -width 1 -tags circle]
+ } else {
+ set t [$canv create polygon \
+ [expr {$x + $orad - 1}] $y \
+ [expr {$x - $orad}] [expr {$y - $orad}] \
+ [expr {$x - $orad}] [expr {$y + $orad - 1}] \
+ -fill $ofill -outline $fgcolor -width 1 -tags circle]
+ }
$canv raise $t
$canv bind $t <1> {selcanvline {} %x %y}
set xt [xc $row [llength [lindex $rowidlist $row]]]
^ 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