* Re: [PATCH] Make cvsexportcommit work with filenames containing spaces.
From: Junio C Hamano @ 2006-09-29 6:37 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <200609290128.56217.robin.rosenberg@dewire.com>
Please do not do more than one patch per e-mail; I'll have to
save the attachment in separate files and manually make commits,
which is more work.
The build procedure for the release to build rpms runs testsuite
as part of it, so I need to think a bit how to proceed with this
patch. Leaving the test failing on FC5 means I won't be able to
cut binary releases. Checking early in the test script to see
if "patch" can grok a diff for a file with whitespaces, and
skipping the whitespace test if we have a bad "patch", seems to
the best workaround.
BTW, the addition of TAB to the patch tail is done by "git diff"
automatically for files with whitespace in them in the proposed
updates version in "pu" (and it is done conditionally only for
files whose names have whitespace), so I think your fix will
become redundant when it graduates to "master".
^ permalink raw reply
* Re: Fix approxidate() to understand more extended numbers
From: Linus Torvalds @ 2006-09-29 6:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Morten Welinder, Git Mailing List
In-Reply-To: <7vd59fp5b9.fsf@assigned-by-dhcp.cox.net>
On Thu, 28 Sep 2006, Junio C Hamano wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > On Thu, 28 Sep 2006, Morten Welinder wrote:
> >>
> >> Just don't hack at 12am or 12pm.
> >
> > I think 12pm is correct, but 12am probably isn't (12am should _subtract_
> > 12, while 12pm does _not_ add 12).
>
> But you have "if (hour > 0 && hour < 12)" in both am and pm so
> assignment to tm would not trigger...
That's not the point.
If you write
12:30 am
you really _should_ subtract 12, leaving you with 0:30. We don't. So we
end up with a 24-hour time of 12:30, which is obviously _pm_, and wrong.
And "12 am" or "12 pm" doesn't work at all.
> > That said, I have a rice cooker that avoids the problem by saying "0:10 PM"
> > for ten minutes past midday ;)
>
> You eat rice?
Ok, is it just me, or is that just a very odd question?
I can see the question "You eat uni?". That really _does_ take a bit of
getting used to. And Natto I really _really_ don't see the point of.
But rice? Afaik, it's the most common food-staple in the world. It's not
exactly odd and exotic..
> > Of course, all sane and civilized countries just use 24-hour format
> > anyway.
>
> You are referring to the US, but neither is Japan sane nor
> civilized ;-).
Yeah, well, they've been learning bad habits. But at least they are
metric.
Linus
^ permalink raw reply
* Re: Notes on Using Git with Subprojects
From: Martin Waitz @ 2006-09-29 7:04 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: Shawn Pearce, Daniel Barkalow, git
In-Reply-To: <451C30EF.8050305@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 868 bytes --]
hoi :)
On Thu, Sep 28, 2006 at 01:30:39PM -0700, A Large Angry SCM wrote:
> If the submodule refs in the parent are the actual submodule refs then
> the submodule is not independent of the parent.
ok, it's not independent in that sense that you can move the directory
away and expect the submodule to work even when the parent does not
exist any more.
But you can do normal GIT work as before.
You can create new branches (they will be stored in the parent
but you have to "git add .gitmodule/..." explicitly in order
to track the branch in the parent), fetch/pull from other sides,
create commits, etc.
So in your normal workflow you do not have to do anything in the
parent while you work in the submodule. That's what I've called
"independent".
I hope the intention is clear now, perhaps I've been sloppy
with words.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Fix approxidate() to understand more extended numbers
From: Junio C Hamano @ 2006-09-29 7:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0609282330440.3952@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
>> > I think 12pm is correct, but 12am probably isn't (12am should _subtract_
>> > 12, while 12pm does _not_ add 12).
>>
>> But you have "if (hour > 0 && hour < 12)" in both am and pm so
>> assignment to tm would not trigger...
>
> That's not the point.
>
> If you write
>
> 12:30 am
>
> you really _should_ subtract 12, leaving you with 0:30. We don't. So we
> end up with a 24-hour time of 12:30, which is obviously _pm_, and wrong.
>
> And "12 am" or "12 pm" doesn't work at all.
Ah, that's what you meant. My brain a bit too tired from the
day job tonight X-<.
>> > That said, I have a rice cooker that avoids the problem by saying "0:10 PM"
>> > for ten minutes past midday ;)
>>
>> You eat rice?
>
> Ok, is it just me, or is that just a very odd question?
Having rice cooker implied eating the stuff regularly and I just
did not expect that from a north european. Just showing my
ignorance -- I've never been to Europe.
^ permalink raw reply
* Re: [PATCH] Make cvsexportcommit work with filenames containing spaces.
From: Robin Rosenberg @ 2006-09-29 7:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy7s3npo9.fsf@assigned-by-dhcp.cox.net>
fredag 29 september 2006 08:37 skrev Junio C Hamano:
> Please do not do more than one patch per e-mail; I'll have to
> save the attachment in separate files and manually make commits,
> which is more work.
>
> The build procedure for the release to build rpms runs testsuite
> as part of it, so I need to think a bit how to proceed with this
> patch. Leaving the test failing on FC5 means I won't be able to
> cut binary releases. Checking early in the test script to see
> if "patch" can grok a diff for a file with whitespaces, and
> skipping the whitespace test if we have a bad "patch", seems to
> the best workaround.
>
> BTW, the addition of TAB to the patch tail is done by "git diff"
> automatically for files with whitespace in them in the proposed
> updates version in "pu" (and it is done conditionally only for
> files whose names have whitespace), so I think your fix will
> become redundant when it graduates to "master".
But, then I can stop here, because that sounds like a much better solution. My
hack is kind-of-kludgy anyway. I'll look in the pu branch. Still want the test
cases, although not complete?
-- robin
^ permalink raw reply
* Re: What's in git.git
From: Junio C Hamano @ 2006-09-29 7:34 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060928093623.GJ20017@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> FWIW, I'd say kill it all (perhaps except BASIC_*, I don't know about
> that one) - we indeed can easily resurrect this, and that was the
> presumption with which I've killed the rest of Git.xs. There's no point
> in keeping legacy cruft around when we can take it back from the
> history.
I came up with this to apply on top of "next". Extra sets of
eyeballs very much appreciated.
-- >8 --
Remove -fPIC which was only needed for Git.xs
The distinction between BASIC_ vs ALL_ is still kept, since it
is not Git.xs specific -- we could face the same issue when we
do other language bindings (e.g. Python).
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
INSTALL | 13 -------------
Makefile | 13 -------------
config.mak.in | 1 -
configure.ac | 7 -------
4 files changed, 0 insertions(+), 34 deletions(-)
diff --git a/INSTALL b/INSTALL
index 0d432d7..fa9bf74 100644
--- a/INSTALL
+++ b/INSTALL
@@ -38,19 +38,6 @@ Issues of note:
has been actively developed since 1997, and people have moved over to
graphical file managers.
- - You can use git after building but without installing if you
- wanted to. Various git commands need to find other git
- commands and scripts to do their work, so you would need to
- arrange a few environment variables to tell them that their
- friends will be found in your built source area instead of at
- their standard installation area. Something like this works
- for me:
-
- GIT_EXEC_PATH=`pwd`
- PATH=`pwd`:$PATH
- GITPERLLIB=`pwd`/perl/blib/lib:`pwd`/perl/blib/arch/auto/Git
- export GIT_EXEC_PATH PATH GITPERLLIB
-
- Git is reasonably self-sufficient, but does depend on a few external
programs and libraries:
diff --git a/Makefile b/Makefile
index 8a7f29b..1875965 100644
--- a/Makefile
+++ b/Makefile
@@ -60,9 +60,6 @@ # a bundled SHA1 routine coming from Moz
# on non-x86 architectures (e.g. PowerPC), while the OpenSSL version (default
# choice) has very fast version optimized for i586.
#
-# Define USE_PIC if you need the main git objects to be built with -fPIC
-# in order to build and link perl/Git.so. x86-64 seems to need this.
-#
# Define NEEDS_SSL_WITH_CRYPTO if you need -lcrypto with -lssl (Darwin).
#
# Define NEEDS_LIBICONV if linking with libc is not enough (Darwin).
@@ -112,7 +109,6 @@ uname_P := $(shell sh -c 'uname -p 2>/de
# CFLAGS and LDFLAGS are for the users to override from the command line.
CFLAGS = -g -O2 -Wall
-PIC_FLAG = -fPIC
LDFLAGS =
ALL_CFLAGS = $(CFLAGS)
ALL_LDFLAGS = $(LDFLAGS)
@@ -402,12 +398,6 @@ endif
ifneq (,$(findstring arm,$(uname_M)))
ARM_SHA1 = YesPlease
endif
-ifeq ($(uname_M),sun4u)
- USE_PIC = YesPlease
-endif
-ifeq ($(uname_M),x86_64)
- USE_PIC = YesPlease
-endif
-include config.mak.autogen
-include config.mak
@@ -546,9 +536,6 @@ else
endif
endif
endif
-ifdef USE_PIC
- ALL_CFLAGS += $(PIC_FLAG)
-endif
ifdef NO_ACCURATE_DIFF
BASIC_CFLAGS += -DNO_ACCURATE_DIFF
endif
diff --git a/config.mak.in b/config.mak.in
index addda4f..fecae80 100644
--- a/config.mak.in
+++ b/config.mak.in
@@ -3,7 +3,6 @@ # @configure_input@
CC = @CC@
CFLAGS = @CFLAGS@
-PIC_FLAG = @PIC_FLAG@
AR = @AR@
TAR = @TAR@
#INSTALL = @INSTALL@ # needs install-sh or install.sh in sources
diff --git a/configure.ac b/configure.ac
index 0f93f6f..8192826 100644
--- a/configure.ac
+++ b/configure.ac
@@ -96,13 +96,6 @@ ## Checks for programs.
AC_MSG_NOTICE([CHECKS for programs])
#
AC_PROG_CC([cc gcc])
-if test -n "$GCC"; then
- PIC_FLAG="-fPIC"
-else
- AC_CHECK_DECL(__SUNPRO_C, [CFLAGS="$CFLAGS -xO3"; PIC_FLAG="-KPIC"])
-fi
-AC_SUBST(PIC_FLAG)
-
#AC_PROG_INSTALL # needs install-sh or install.sh in sources
AC_CHECK_TOOL(AR, ar, :)
AC_CHECK_PROGS(TAR, [gtar tar])
^ permalink raw reply related
* Re: git and time
From: Andreas Ericsson @ 2006-09-29 7:52 UTC (permalink / raw)
To: Linus Torvalds
Cc: Matthew L Foster, Shawn Pearce, Junio C Hamano, git, Jeff King,
Jakub Narebski
In-Reply-To: <Pine.LNX.4.64.0609271918350.3952@g5.osdl.org>
Linus Torvalds wrote:
>
> On Wed, 27 Sep 2006, Matthew L Foster wrote:
>> From a web display/generic notion of integrity perspective time order
>> matters to me but it looks like I am the only one. Keeping track of
>> _local_ commit time would not add any dependencies.
>
> Actually, I think one problem here is that anybody why looks at just the
> gitweb interface may not realize how git works.
>
> If you use gitk as your primary way of learning about a git problem, the
> whole time issue just goes away, because gitk shows the _real_
> relationships so well.
>
> I used gitk in all my initial explanations of git, because it turned a
> fairly abstract "here, let me explain how it works" into a "See? Look at
> this" kind of situation.
>
True that. I would have had a hard time introducing git as The SCM in
the company if it hadn't been for gitk and qgit. They both let you just
skip over 90% of that initial steep part of the learning curve and jump
straight to work.
> I think gitweb is great (in a way I have _never_ felt about any of the CVS
> web interfaces I have ever seen), but gitweb doesn't really explain how
> things work as well as gitk does.
>
Someone started hacking on a web-thingie to show the graph. Whatever
happened to that? If it's no longer alive, perhaps we could add some
qgit/gitk screenshots to the git wiki/docs so the people who spend most
of their lives in browsers can get some visual aid in understanding the
way git works.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: What's in git.git
From: Junio C Hamano @ 2006-09-29 8:09 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060928093623.GJ20017@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Dear diary, on Thu, Sep 28, 2006 at 09:39:11AM CEST, I got a letter
> where Junio C Hamano <junkio@cox.net> said that...
>> -
>
> BTW, what's the difference between '-' and '+'?
quoting myself...
|| * The 'next' branch, in addition, has these. I think the ones
|| marked with + could be 1.4.3-rc1 material:
^ permalink raw reply
* Re: git and time
From: Andreas Ericsson @ 2006-09-29 8:16 UTC (permalink / raw)
To: Matthew L Foster; +Cc: Johannes Schindelin, Linus Torvalds, Rogan Dawes, git
In-Reply-To: <20060928194316.42986.qmail@web51004.mail.yahoo.com>
Matthew L Foster wrote:
> --- Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
>> On Thu, 28 Sep 2006, Matthew L Foster wrote:
>>
>>> It should be possible to export git data, through say a web interface,
>>> in a such a way that local time order is consistent with commit order.
>> Why?
>
> - So exported data is never/rarely in an inconsistent state with respect to commit order and local
> time order (data integrity).
>
Moot point (it has been iterated so many times that I can't be asked to
repeat it again).
> - To encourage people to care about/prefer local commit time rather than remote creation/emailed
> time
>
Most people use ntp, and are in general concerned with keeping their
clocks in sync as lots of other software depend on it (calender
functions, fe). It shouldn't be the task of project leaders to make sure
that the ~50000 random people around the world that submit patches to
opensource projects every day all have their clocks in sync.
> - So people that user repo X, or binaries from repo X, know when bug fix Y/fancy new feature Z was
> committed/merged locally
>
Can be done using reflog. Feel free to submit patches. Make sure you
sync your clock to whatever ntp-server or other timekeeping mechanism
Junio uses before you commit and send your patch though. ;-)
> - In many situations "history" is incomplete without local commit time. If a company has a new
> driver they would probably prefer to know when the main kernel repo has it, not when they
> created/emailed it or when a remote repo committed it.
>
See the reflog response and, again, feel free to submit patches.
To get you started, I think the easiest way would be to teach gitweb
about the reflog, and then insert a line saying
"--- pushed to this repo $date ---"
or something like that in the summary page whenever a commit is found
that is also in the reflog. This should also be fairly CPU efficient if
my guesses on how gitweb and the reflog works are correct. CBA to check,
since I sincerely and whole-heartedly don't care about it myself.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: What's in git.git
From: Petr Baudis @ 2006-09-29 8:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhcyrnn1g.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Fri, Sep 29, 2006 at 09:34:51AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> diff --git a/INSTALL b/INSTALL
> index 0d432d7..fa9bf74 100644
> --- a/INSTALL
> +++ b/INSTALL
> @@ -38,19 +38,6 @@ Issues of note:
> has been actively developed since 1997, and people have moved over to
> graphical file managers.
>
> - - You can use git after building but without installing if you
> - wanted to. Various git commands need to find other git
> - commands and scripts to do their work, so you would need to
> - arrange a few environment variables to tell them that their
> - friends will be found in your built source area instead of at
> - their standard installation area. Something like this works
> - for me:
> -
> - GIT_EXEC_PATH=`pwd`
> - PATH=`pwd`:$PATH
> - GITPERLLIB=`pwd`/perl/blib/lib:`pwd`/perl/blib/arch/auto/Git
> - export GIT_EXEC_PATH PATH GITPERLLIB
> -
> - Git is reasonably self-sufficient, but does depend on a few external
> programs and libraries:
>
The passage should be kept and even GITPERLLIB - just drop the second
path after the colon.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* git sometimes stripping one path component in commit mails
From: Geert Uytterhoeven @ 2006-09-29 8:41 UTC (permalink / raw)
To: git, Linux Kernel Development
Hi,
I noticed git sometimes strips one path component from the filenames in the
patches mailed to the git-commits mailing lists. This causes problems when
piping these mails through diffstat.
Here is a part of an actual mail received through
git-commits-head@vger.kernel.org to demonstrate this issue:
Is this a current git bug, or a bug in the version used for those mailing
lists?
| commit 94c12cc7d196bab34aaa98d38521549fa1e5ef76
| tree 8e0cec0ed44445d74a2cb5160303d6b4dfb1bc31
| parent 25d83cbfaa44e1b9170c0941c3ef52ca39f54ccc
| author Martin Schwidefsky <schwidefsky@de.ibm.com> 1159455403 +0200
| committer Martin Schwidefsky <schwidefsky@de.ibm.com> 1159455403 +0200
| diff --git a/include/asm-s390/irqflags.h b/include/asm-s390/irqflags.h
| dissimilarity index 65%
| index 3b566a5..3f26131 100644
| --- include/asm-s390/irqflags.h
| +++ include/asm-s390/irqflags.h
^^
woops
| diff --git a/include/asm-s390/lowcore.h b/include/asm-s390/lowcore.h
| index 18695d1..06583ed 100644
| --- a/include/asm-s390/lowcore.h
| +++ b/include/asm-s390/lowcore.h
^^
OK
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: git sometimes stripping one path component in commit mails
From: Junio C Hamano @ 2006-09-29 9:08 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: git
In-Reply-To: <Pine.LNX.4.62.0609291034020.28814@pademelon.sonytel.be>
Geert Uytterhoeven <geert@linux-m68k.org> writes:
> Is this a current git bug, or a bug in the version used for those mailing
> lists?
>
> | commit 94c12cc7d196bab34aaa98d38521549fa1e5ef76
>...
> | diff --git a/include/asm-s390/irqflags.h b/include/asm-s390/irqflags.h
> | dissimilarity index 65%
> | index 3b566a5..3f26131 100644
> | --- include/asm-s390/irqflags.h
> | +++ include/asm-s390/irqflags.h
> ^^
> woops
This is a current git bug (and git bug ever since it started to
say "dissimilarity index"). Thanks for noticing, and very sorry
for the trouble. It seems that a complete rewrite diff never
worked and nobody seriously looked at them.
This should fix it.
-- >8 --
[PATCH] git-diff -B output fix.
Geert noticed that complete rewrite diff missed the usual a/ and b/
leading paths. Pickaxe says it never worked, ever.
Embarrassing.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/diff.c b/diff.c
index 2464238..17f5a91 100644
--- a/diff.c
+++ b/diff.c
@@ -208,7 +208,7 @@ static void emit_rewrite_diff(const char
diff_populate_filespec(two, 0);
lc_a = count_lines(one->data, one->size);
lc_b = count_lines(two->data, two->size);
- printf("--- %s\n+++ %s\n@@ -", name_a, name_b);
+ printf("--- a/%s\n+++ b/%s\n@@ -", name_a, name_b);
print_line_count(lc_a);
printf(" +");
print_line_count(lc_b);
--
1.4.2.1.gce47b
^ permalink raw reply related
* Re: [PATCH 3/3] diff --stat: sometimes use non-linear scaling.
From: Andreas Ericsson @ 2006-09-29 10:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin Waitz, git
In-Reply-To: <7v64f8xs7p.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Martin Waitz <tali@admingilde.org> writes:
>
>>> It should at least never be superlinear, I believe.
>> So if we want to keep the logarithmic scale we can do some maths:
>> ...
>> But only I have not succeeded in solving these equations, I always stop
>> at the last invariant :-(
>
> There is another constraint you did not mention. Here is the
> output from my another failed experiment:
>
> .gitignore | 1 -
> Documentation/git-tar-tree.txt | 3 +++
> Documentation/git-upload-tar.txt | 39 -----------------------------
> Documentation/git.txt | 4 ----
> Makefile | 1 -
> builtin-tar-tree.c | 130 +++++++++++++++-----------------------
> builtin-upload-tar.c | 74 ----------------------------------
> git.c | 1 -
> 8 files changed, 53 insertions(+), 200 deletions(-)
>
> The deletion from Documentation/git-upload-tar.txt looks much
> larger than addition to builtin-tar-tree.c in the above, but
> there are 50 lines added to builtin-tar-tree.c (which is why
> this experiment is a failure).
>
> Because we are dealing with non-linear scaling, the total of
> scaled adds and scaled deletes does not equal to scaled total.
> We can deal with this in two ways. Scale the total and
> distribute it, or scale adds and deletes individually and make
> sure the sum of scaled adds and deletes never exceed the width.
> Obviously the former is easier to implement but it was _wrong_.
>
> The fitting algorithm in the posted patch scales the total to
> fit the alloted width and then distributes the result to adds
> and deletes.
>
Why not just take the stupid and simple solution and make it:
file1 | +31,-19 +++
file2 | +19,-106 ---
file3 | +10,-10 ###
That is, show the number of lines that actually changed, and print a
fixed number of plusses or minuses after the numbers to make it easy to,
at a glance, check if more lines were added than deleted or vice versa.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [ANNOUNCE] Cogito-0.18
From: Petr Baudis @ 2006-09-29 12:06 UTC (permalink / raw)
To: git; +Cc: linux-kernel
Hello,
I just released cogito-0.18 - new feature release of the Cogito
user-friendly Git user interface. The biggest highlights are
super-duper cg-log, tagging interface and cg-patch -m. Contrary to my
plan, this unfortunately does NOT contain three big things yet that are
missing but will be in cogito-0.19 (which should be already quite near
the ever-approaching version 1.0):
- Rigorous three-way merging of uncommitted local changes
instead of stashing local changes in patches
(stashing produces harder-to-resolve conflicts and can
in some extreme circumstances lead to loss or almost-loss
of your local changes which is highly evil; this is my
priority now; if you want to be absolutely safe, do not
update/merge/switch your tree while having uncommitted
changes in it)
- Support for cg-clone -a (clone all remote branches)
- Support for auto-pushing tags
So, now for things that ARE part of 0.18: :-)
First, a simple README update is the only difference from 0.18rc2.
* INCOMPATIBLE: $COGITO_COLORS is renamed to $CG_COLORS
* INCOMPATIBLE: cg-log now by default hides merges, -M behaviour is
reversed
* All kinds of very stale command aliases that were deprecated for eons
were removed
* .git/author is deprecated (use .git/config to set it up)
* We now officially depend on 1.4.2 (we use git-*-fetch --stdin which makes
fetching tags _MUCH_ faster)
* cg-log was reworked to support cg-log -d (show diffs inline),
cg-log -S (pickaxe) and renames following (does not quite work, though;
I decided not to fix it and wait for revisions.c in Git to support it
since the perl script which takes care of this is quite a hack)
* cg-switch -l to stash your local changes when switching branches
* cg-commit --amend
* Tagging interface (cg-tag, cg-tag-ls, cg-tag-show) was greatly enhanced
* cg-patch -m for applying mailboxes
* cg-clone -l now sets up an alternate instead of symlinking the object db
* Support for cg-clone --reference
* cg-admin-setuprepo supports setting up repositories over SSH
* Support fetching over FTP
* Other cool stuff!
Happy hacking,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: Fix approxidate() to understand more extended numbers
From: Johannes Schindelin @ 2006-09-29 14:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vslibno88.fsf@assigned-by-dhcp.cox.net>
Hi,
On Fri, 29 Sep 2006, Junio C Hamano wrote:
> Having rice cooker implied eating the stuff regularly and I just
> did not expect that from a north european. Just showing my
> ignorance -- I've never been to Europe.
Actually, yesterday I saw a digital wrist watch for the first time in my
life! Amazing! ;-)
There is even a running joke about Great Britain: "Oh yes, I _love_
English dishes; especially the Chinese ones!"
Ciao,
Dscho
^ permalink raw reply
* Re: git and time
From: Johannes Schindelin @ 2006-09-29 14:09 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Linus Torvalds, Matthew L Foster, Shawn Pearce, Junio C Hamano,
git, Jeff King, Jakub Narebski
In-Reply-To: <451CD0C2.2020805@op5.se>
Hi,
On Fri, 29 Sep 2006, Andreas Ericsson wrote:
> Someone started hacking on a web-thingie to show the graph. Whatever
> happened to that?
It is called git-browser, and was done by Artem Khodush. See
http://straytree.com/.
I asked Artem what the plans are, since some features are not yet
implemented, but he said that the thing is too slow, and he'll probably
not continue to work on it.
Ciao,
Dscho
^ permalink raw reply
* Re: git and time
From: Andreas Ericsson @ 2006-09-29 14:21 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Linus Torvalds, Matthew L Foster, Shawn Pearce, Junio C Hamano,
git, Jeff King, Jakub Narebski
In-Reply-To: <Pine.LNX.4.63.0609291605390.14200@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Fri, 29 Sep 2006, Andreas Ericsson wrote:
>
>> Someone started hacking on a web-thingie to show the graph. Whatever
>> happened to that?
>
> It is called git-browser, and was done by Artem Khodush. See
> http://straytree.com/.
>
> I asked Artem what the plans are, since some features are not yet
> implemented, but he said that the thing is too slow, and he'll probably
> not continue to work on it.
>
Ah well. I hope he keeps that page running though, and I hope the
"time-is-importan" people find it.
For reference, it gives a crude (and indeed slow) picture of what gitk
and qgit does.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* problem with cvsimport
From: picca Frédéric @ 2006-09-29 15:25 UTC (permalink / raw)
To: git
hello
When I tried to import the tango-cs project from sourceforge with this command:
git cvsimport -p --no-cvs-direct -v -d :pserver:anonymous@tango-cs.cvs.sourceforge.net/cvsroot/tango-cs -C . tango
The import stop with:
skip patchset 3711: 1159522098 before 1159522323
skip patchset 3712: 1159522157 before 1159522323
skip patchset 3713: 1159522283 before 1159522323
skip patchset 3714: 1159522323 before 1159522323
DONE.
fatal: Needed a single revision
fatal: Needed a single revision
What is the problème.
I am using git 1.4.1.1
Have a good day.
^ permalink raw reply
* Re: [PATCH] gitweb: tree view: hash_base and hash are now context sensitive
From: Luben Tuikov @ 2006-09-29 16:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <7vmz8jp5p3.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> > What are the objections to this patch?
>
> No objections from me --- rather lack of objections from Jakub ;-)
We haven't heard anything from him, and on our last correspondence
in this thread it seemed we're in agreement.
> But the fragments do not appear to apply anymore.
[...]
> There is no call to create blob_plain link with hash_base
> hardcoded to "HEAD" in git-print-tree-entry.
>
> Care to re-spin?
Doing it right now.
Thanks,
Luben
^ permalink raw reply
* [PATCH] gitweb: tree view: hash_base and hash are now context sensitive
From: Luben Tuikov @ 2006-09-29 16:57 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 354 bytes --]
In tree view, by default, hash_base is HEAD and hash is the
entry equivalent. Else the user had selected a hash_base or
hash, say by clicking on a revision or commit, in which case
those values are used.
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
---
gitweb/gitweb.perl | 18 +++++++++---------
1 files changed, 9 insertions(+), 9 deletions(-)
[-- Attachment #2: 1207600725-p1.txt --]
[-- Type: text/plain, Size: 1129 bytes --]
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index be336f6..44991b1 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1672,9 +1672,9 @@ sub git_print_tree_entry {
"history");
}
print " | " .
- $cgi->a({-href => href(action=>"blob_plain",
- hash=>$t->{'hash'}, file_name=>"$basedir$t->{'name'}")},
- "raw");
+ $cgi->a({-href => href(action=>"blob_plain", hash_base=>$hash_base,
+ file_name=>"$basedir$t->{'name'}")},
+ "raw");
print "</td>\n";
} elsif ($t->{'type'} eq "tree") {
@@ -2745,14 +2745,14 @@ sub git_blob {
sub git_tree {
my $have_snapshot = gitweb_have_snapshot();
+ if (!defined $hash_base) {
+ $hash_base = "HEAD";
+ }
if (!defined $hash) {
- $hash = git_get_head_hash($project);
if (defined $file_name) {
- my $base = $hash_base || $hash;
- $hash = git_get_hash_by_path($base, $file_name, "tree");
- }
- if (!defined $hash_base) {
- $hash_base = $hash;
+ $hash = git_get_hash_by_path($hash_base, $file_name, "tree");
+ } else {
+ $hash = $hash_base;
}
}
$/ = "\0";
^ permalink raw reply related
* Re: git and time
From: Jan Harkes @ 2006-09-29 17:37 UTC (permalink / raw)
To: Sean; +Cc: Junio C Hamano, David Lang, git
In-Reply-To: <20060926224133.714337eb.seanlkml@sympatico.ca>
On Tue, Sep 26, 2006 at 10:41:33PM -0400, Sean wrote:
> It is interesting information for some people though. For instance
> someone wondering how long ago Linus published a certain security fix.
> To be able to say to easily query gitweb and be able to report,
> "Linus published that security fix X day ago etc.."
I don't see the point in knowing how many days ago the security fix was
published, since I'd really care if my machine is running a kernel that
contains the fix.
So I can see how I might want to know which branches (and/or tags) in my
repository contain the security fix. And this is pretty easy,
#!/bin/sh
fix="$(git-rev-parse --verify $1)"
git ls-remote . | while read sha ref ; do
[ "$fix" == "$(git-merge-base "$fix" "$sha")" ] && echo $ref
done
Of course this could be cleaned up and extended quite a bit, possibly
allowing a user to specify if he cares about only branches, or tags or
some specific branch.
Jan
^ permalink raw reply
* Re: git and time
From: Sean @ 2006-09-29 17:46 UTC (permalink / raw)
To: Jan Harkes; +Cc: Junio C Hamano, David Lang, git
In-Reply-To: <20060929173736.GA13635@delft.aura.cs.cmu.edu>
On Fri, 29 Sep 2006 13:37:36 -0400
Jan Harkes <jaharkes@cs.cmu.edu> wrote:
> I don't see the point in knowing how many days ago the security fix was
> published, since I'd really care if my machine is running a kernel that
> contains the fix.
It was just a single example, one maybe not important to you. In fact
it might be interesting to someone who isn't even running _any_ Linux
kernel themselves; a security researcher or journalist for instance.
There are other examples as well. Maybe none of them would apply to
your needs, but there are people who would find it interesting and
convenient.
Sean
^ permalink raw reply
* [PATCH 0/5] fetch & co: misc output cleanup
From: Santi Béjar @ 2006-09-29 18:05 UTC (permalink / raw)
To: git
Hi *,
this patchset includes:
fetch: Reset remote refs list each time fetch_main is called
fetch & co: Use "hash1..hash2" instead of "from hash1 to hash2"
fetch & co: Use short sha1 in the output
fetch: Add output for the not fast forward case
fetch: Clean output
The first one is actually a bugfix (at least for me), but needed for the
last one.
git-fetch.sh | 19 ++++++++++++++-----
git-merge.sh | 2 +-
git-resolve.sh | 2 +-
3 files changed, 16 insertions(+), 7 deletions(-)
^ permalink raw reply
* [PATCH 1/5] fetch: Reset remote refs list each time fetch_main is called
From: Santi Béjar @ 2006-09-29 18:05 UTC (permalink / raw)
To: git
In-Reply-To: <87r6xu1rci.fsf@gmail.com>
This prevents the fetch of the heads again in the second call of fetch_main.
Signed-off-by: Santi Béjar <sbejar@gmail.com>
---
git-fetch.sh | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/git-fetch.sh b/git-fetch.sh
index bcc67ab..f1522bd 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -257,6 +257,7 @@ fi
fetch_main () {
reflist="$1"
refs=
+ rref=
for ref in $reflist
do
--
1.4.2.1.g38049
^ permalink raw reply related
* [PATCH 2/5] fetch & co: Use "hash1..hash2" instead of "from hash1 to hash2"
From: Santi Béjar @ 2006-09-29 18:06 UTC (permalink / raw)
To: git
In-Reply-To: <87r6xu1rci.fsf@gmail.com>
I find it shorter, easier to copy&paste and cleaner.
Signed-off-by: Santi Béjar <sbejar@gmail.com>
---
git-fetch.sh | 2 +-
git-merge.sh | 2 +-
git-resolve.sh | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/git-fetch.sh b/git-fetch.sh
index f1522bd..08d86cd 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -182,7 +182,7 @@ fast_forward_local () {
;;
*,$local)
echo >&2 "* $1: fast forward to $3"
- echo >&2 " from $local to $2"
+ echo >&2 " $local..$2"
git-update-ref -m "$rloga: fast-forward" "$1" "$2" "$local"
;;
*)
diff --git a/git-merge.sh b/git-merge.sh
index 5b34b4d..fd587c5 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -197,7 +197,7 @@ f,*)
;;
?,1,"$head",*)
# Again the most common case of merging one remote.
- echo "Updating from $head to $1"
+ echo "Updating $head..$1"
git-update-index --refresh 2>/dev/null
new_head=$(git-rev-parse --verify "$1^0") &&
git-read-tree -u -v -m $head "$new_head" &&
diff --git a/git-resolve.sh b/git-resolve.sh
index 729ec65..6e4fb02 100755
--- a/git-resolve.sh
+++ b/git-resolve.sh
@@ -46,7 +46,7 @@ case "$common" in
exit 0
;;
"$head")
- echo "Updating from $head to $merge"
+ echo "Updating $head..$merge"
git-read-tree -u -m $head $merge || exit 1
git-update-ref -m "resolve $merge_name: Fast forward" \
HEAD "$merge" "$head"
--
1.4.2.1.g38049
^ 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