* Re: remove perl from git-commit.sh
From: Nikolai Weibull @ 2006-07-12 11:17 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano
In-Reply-To: <81b0412b0607120415g243f2160tf42c40e52b8bc9ac@mail.gmail.com>
On 7/12/06, Alex Riesen <raa.lkml@gmail.com> wrote:
> Otherwise I'd better suggest to add another
> quoting style (replacing only \t, \n and backslash)
One could always do the quoting with sed, or am I missing something?
nikolai
^ permalink raw reply
* Re: remove perl from git-commit.sh
From: Alex Riesen @ 2006-07-12 11:23 UTC (permalink / raw)
To: Nikolai Weibull; +Cc: git, Junio C Hamano
In-Reply-To: <dbfc82860607120417m19c0ecefydb4b3f4cf60d646a@mail.gmail.com>
On 7/12/06, Nikolai Weibull <now@bitwi.se> wrote:
> > Otherwise I'd better suggest to add another
> > quoting style (replacing only \t, \n and backslash)
>
> One could always do the quoting with sed, or am I missing something?
>
No, but if look closely at this list you'll find a lot of incompatibilities
in sed too. So the less, the better
^ permalink raw reply
* Re: remove perl from git-commit.sh
From: Nikolai Weibull @ 2006-07-12 11:35 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano
In-Reply-To: <81b0412b0607120423q8c75ecl7d42dfd67f99a549@mail.gmail.com>
On 7/12/06, Alex Riesen <raa.lkml@gmail.com> wrote:
> On 7/12/06, Nikolai Weibull <now@bitwi.se> wrote:
> > > Otherwise I'd better suggest to add another
> > > quoting style (replacing only \t, \n and backslash)
> > One could always do the quoting with sed, or am I missing something?
> No, but if look closely at this list you'll find a lot of incompatibilities
> in sed too. So the less, the better
Well, that's true, of course, but something as "simple" as what is
needed in this case should be possible. Anyway, I was just wondering
what the motives were, not questioning them ;-).
nikolai
^ permalink raw reply
* Re: remove perl from git-commit.sh
From: Alex Riesen @ 2006-07-12 11:41 UTC (permalink / raw)
To: Nikolai Weibull; +Cc: git, Junio C Hamano
In-Reply-To: <dbfc82860607120435v5482ce31pdf002f049c51669a@mail.gmail.com>
On 7/12/06, Nikolai Weibull <now@bitwi.se> wrote:
> Anyway, I was just wondering
> what the motives were, not questioning them ;-).
Being forced to use ActiveState Perl on a W2K in a
corporate environment.
^ permalink raw reply
* Re: remove perl from git-commit.sh
From: Petr Baudis @ 2006-07-12 11:48 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano
In-Reply-To: <81b0412b0607120415g243f2160tf42c40e52b8bc9ac@mail.gmail.com>
Dear diary, on Wed, Jul 12, 2006 at 01:15:03PM CEST, I got a letter
where Alex Riesen <raa.lkml@gmail.com> said that...
> ---
BTW, why people so often want to keep stuff like the following from
commit messages?
> git-commit.sh has only ohne place where perl is used
> and it can actually quite trivially be done in sh.
> git-ls-files without "-z" produces quoted output, even if
> is different from that produced by perl code it could be
> enough. Otherwise I'd better suggest to add another
> quoting style (replacing only \t, \n and backslash)
Of course getting rid of Perl from the "essentials" is an option...
> than having to constantly patch git-commit.sh for binmode
> or perl path (Windows has no stable tool set, and perl
> for instance often resides "somewhere").
...but I would prefer much better if we could actually fix the problem.
I'm not sure what "patching for binmode" takes but it sounds that we
should do it for the other Perl scripts anyway. If Cygwin usually really
doesn't have stable Perl path, you could special-case PERL_PATH in
Makefile for Cygwin to be just "perl" (or perhaps that's the issue only
for non-source packages so you might want to simply set PERL_PATH to
perl when building those).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: remove perl from git-commit.sh
From: Alex Riesen @ 2006-07-12 12:23 UTC (permalink / raw)
To: Petr Baudis; +Cc: git, Junio C Hamano
In-Reply-To: <20060712114805.GD13776@pasky.or.cz>
On 7/12/06, Petr Baudis <pasky@suse.cz> wrote:
> BTW, why people so often want to keep stuff like the following from
> commit messages?
Well, strictly speaking it isn't the description of what the patch does.
> > than having to constantly patch git-commit.sh for binmode
> > or perl path (Windows has no stable tool set, and perl
> > for instance often resides "somewhere").
>
> ...but I would prefer much better if we could actually fix the problem.
> I'm not sure what "patching for binmode" takes but it sounds that we
ActiveState Perl normally replaces \n in the output with \r\n, which is
annoying, as the rest of git does output \n verbatim.
> should do it for the other Perl scripts anyway. If Cygwin usually really
> doesn't have stable Perl path, you could special-case PERL_PATH in
It's not cygwin. It's an organization typical for windows environements:
stinky trash can.
> Makefile for Cygwin to be just "perl" (or perhaps that's the issue only
> for non-source packages so you might want to simply set PERL_PATH to
> perl when building those).
I did. I didn't mention it because the patch was about the binmode.
sh is from cygwin here, so just removing this one dependency helps
a lot. I will change other scripts as soon as they get problematic.
Another small problem is with windows pathnames (activestate perl
expects _windows_ path, but allows forward slashes in it: c:/a/b/c).
I have calls to cygpath (converts cygwin path to windows and vice
versa) all over (not everywhere, just clone, rerere, mv, shortlog and
fmt-merge-msg. The tools that were important to me) just to deal
with this. It's a horribly unstable and poorly tested and breaks from
time to time but it mostly works. As I saw no complaints here about
the same problem I have never submitted the changes. Maybe I am
just unlucky to have to deal with windows so often.
^ permalink raw reply
* Sharing repositories later on
From: Erik Mouw @ 2006-07-12 13:28 UTC (permalink / raw)
To: git
Hi,
I just learned out about "git clone -s" to share objects between
repositories. How do I use that with already existing repositories?
Right now I have a "linux-2.6" repository to track Linus's 2.6 kernel
tree and an "elinux-2.6" tree that pulls from linux-2.6 and holds my
own changes. I created a file .git/objects/info/alternates that
contains the line "/home/erik/git/linux-2.6/.git/objects". Now how do I
get rid of the "old" objects and packs without loosing my changes?
Erik
--
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
^ permalink raw reply
* Re: [PATCH] Remove more gcc extension usage.
From: Paul Jakma @ 2006-07-12 13:46 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Jan-Benedict Glaw, Junio C Hamano, git
In-Reply-To: <20060710052255.GA15173@spearce.org>
On Mon, 10 Jul 2006, Shawn Pearce wrote:
> So Monday turned out to be today. The compiler version:
>
> $ cc -V
> cc: Forte Developer 7 C 5.4 2002/03/09
> usage: cc [ options] files. Use 'cc -flags' for details
> and from `man cc`:
>
> -xc99 enables C99 features:
Only a subset of C99.
You need SOS10 for full C99 support, Sun have made SOS freely
downloadable since version 10.
regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
It is easier to change the specification to fit the program than vice versa.
^ permalink raw reply
* Re: [PATCH 2/3] sha1_file: add the ability to parse objects in "pack file format"
From: Linus Torvalds @ 2006-07-12 15:13 UTC (permalink / raw)
To: Peter Baumann; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <slrneb96rd.dma.Peter.B.Baumann@xp.machine.xx>
On Wed, 12 Jul 2006, Peter Baumann wrote:
>
> This doesn't match the logic used in unpack_object_header, which is used
> in the packs:
Yeah, good point. I reversed the meaning of the high bit by mistake. In
pack-files, the high bit is a "there is more to come" bit, and in my new
code it was a "this is the last byte" bit.
It doesn't matter for the ultimate reason for this (being able to re-use
the actual _bulk_ of the data), but having it be different would be stupid
and confusing, and means that we can't later try to use the same routines
for packing/unpacking the objects.
Junio - do you want me to send an updated patch, or do you want to reverse
bit#7 yourself?
Linus
^ permalink raw reply
* Re: Sharing repositories later on
From: Junio C Hamano @ 2006-07-12 15:21 UTC (permalink / raw)
To: Erik Mouw; +Cc: git
In-Reply-To: <20060712132800.GA7328@harddisk-recovery.com>
Erik Mouw <erik@harddisk-recovery.com> writes:
> Hi,
>
> I just learned out about "git clone -s" to share objects between
> repositories. How do I use that with already existing repositories?
>
> Right now I have a "linux-2.6" repository to track Linus's 2.6 kernel
> tree and an "elinux-2.6" tree that pulls from linux-2.6 and holds my
> own changes. I created a file .git/objects/info/alternates that
> contains the line "/home/erik/git/linux-2.6/.git/objects". Now how do I
> get rid of the "old" objects and packs without loosing my changes?
repack -a -d -l perhaps?
^ permalink raw reply
* Re: [PATCH 2/3] sha1_file: add the ability to parse objects in "pack file format"
From: Junio C Hamano @ 2006-07-12 15:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0607120810320.5623@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Junio - do you want me to send an updated patch, or do you want to reverse
> bit#7 yourself?
Pushed out in "pu" already, thanks.
^ permalink raw reply
* Re: Re : 2 questions on git-send-email usage
From: Linus Torvalds @ 2006-07-12 15:43 UTC (permalink / raw)
To: Franck Bui-Huu; +Cc: Junio C Hamano, git
In-Reply-To: <44B4A6CA.3020206@innova-card.com>
On Wed, 12 Jul 2006, Franck Bui-Huu wrote:
>
> [PATCH] Add a newline before appending "Signed-off-by:"
>
> It looks nicer.
Yes. However, I think the sign-off detection is a bit broken (quite
independently of your patch).
A number of people end up capitalizing the sign-off differently, so you
have lines like "Signed-Off-By: Xy Zzy <xyzzy@example.org>".
Also, at least for the kernel, we often have alternative formats, like
Acked-by: Elliot Xavier Ample <example@dummy.org>
and for that case, adding the extra newline is actually bad.
So I would suggest a totally different approach: instead of using
"strstr(comments, signed_off_by)", it would probably be much better to
just look for the last non-empty line, and see if it matches the format
"^[nonspace]*: .*@.*$"
(yeah, that's not a valid regexp, but you get the idea).
On a slightly related note, I absolutely _hate_ how cherry-picking adds
"(cherry-picked from commit <sha1>)" at the end. It's wrong for so many
reasons, one of them being that it then breaks things like this, but the
main one being that <sha1> will quite often actually end up not even
_existing_ in the resulting archive (you cherry-picked from your private
branch, and even if you keep your branch, you don't necessarily push it
out).
Junio, can we make the default _not_ to do it, please?
Linus
^ permalink raw reply
* Re: Sharing repositories later on
From: Linus Torvalds @ 2006-07-12 15:47 UTC (permalink / raw)
To: Erik Mouw; +Cc: git
In-Reply-To: <20060712132800.GA7328@harddisk-recovery.com>
On Wed, 12 Jul 2006, Erik Mouw wrote:
>
> I just learned out about "git clone -s" to share objects between
> repositories. How do I use that with already existing repositories?
Do
echo "/source/git/project/.git/objects/" > .git/objects/info/alternates
and then follow it up with
git repack -a -d -l
where the "-l" means that it will only put _local_ objects in the
pack-file (strictly speaking, it will put any loose objects from the
alternate tree too, so you'll have a fully packed archive, but it won't
duplicate objects that are already packed in the alternate tree).
Linus
^ permalink raw reply
* Re: Sharing repositories later on
From: Erik Mouw @ 2006-07-12 15:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpsgazw5j.fsf@assigned-by-dhcp.cox.net>
On Wed, Jul 12, 2006 at 08:21:28AM -0700, Junio C Hamano wrote:
> Erik Mouw <erik@harddisk-recovery.com> writes:
> > Right now I have a "linux-2.6" repository to track Linus's 2.6 kernel
> > tree and an "elinux-2.6" tree that pulls from linux-2.6 and holds my
> > own changes. I created a file .git/objects/info/alternates that
> > contains the line "/home/erik/git/linux-2.6/.git/objects". Now how do I
> > get rid of the "old" objects and packs without loosing my changes?
>
> repack -a -d -l perhaps?
Thanks, that did the trick. I now have a small pack with around 100
objects.
Erik
--
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
^ permalink raw reply
* Re: Re : 2 questions on git-send-email usage
From: Junio C Hamano @ 2006-07-12 16:19 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Franck Bui-Huu
In-Reply-To: <Pine.LNX.4.64.0607120834200.5623@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On a slightly related note, I absolutely _hate_ how cherry-picking adds
> "(cherry-picked from commit <sha1>)" at the end. It's wrong for so many
> reasons, one of them being that it then breaks things like this, but the
> main one being that <sha1> will quite often actually end up not even
> _existing_ in the resulting archive (you cherry-picked from your private
> branch, and even if you keep your branch, you don't necessarily push it
> out).
>
> Junio, can we make the default _not_ to do it, please?
I understand that it can be annoying.
I was hoping that however when you do something like this:
git log --filter-backported-commits v2.6.16.9..v2.6.17
an improved log-inspection tool could notice and filter out the
ones that was backported from the mainline to the maintenance
branch.
But I realize that is probably a faulty logic. First of all,
not all backports are cherry-picked (the same patch can be
applied from an e-mail, for example), so if we really want to do
the above filtering, we would need to be able to detect the same
patch anyway without "cherry-picked from" information.
To a certain degree, git-patch-id would help detecting such a
duplicated patch, but it would not help you detect "moral
equivalent" changes that are textually different. A cherry-pick
after a conflict resolution that ends up applying a textually
different patch would still leave the "cherry-picked from"
message in the commit log (or a "note " header if we implement
it to reduce cluttering the log message), which would be the
only advantage of recording the information somehow. But that
is probably not worth it -- it means "moral equivalent" changes
need to be recorded somehow by hand, which is unnecessarly
developer burden if it is rare enough to want to filter such
duplicates when inspecting the log.
Do people find "cherry-picked from" information useful? Does
anybody mind if we change the default not to record it?
^ permalink raw reply
* Re: Re : 2 questions on git-send-email usage
From: Junio C Hamano @ 2006-07-12 16:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Franck Bui-Huu
In-Reply-To: <Pine.LNX.4.64.0607120834200.5623@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Yes. However, I think the sign-off detection is a bit broken (quite
> independently of your patch).
>
> A number of people end up capitalizing the sign-off differently, so you
> have lines like "Signed-Off-By: Xy Zzy <xyzzy@example.org>".
>
> Also, at least for the kernel, we often have alternative formats, like
>
> Acked-by: Elliot Xavier Ample <example@dummy.org>
>
> and for that case, adding the extra newline is actually bad.
>
> So I would suggest a totally different approach: instead of using
> "strstr(comments, signed_off_by)", it would probably be much better to
> just look for the last non-empty line, and see if it matches the format
>
> "^[nonspace]*: .*@.*$"
Documentation/SubmittingPatches (the kernel one) does not show
the ugly Camel-Case-With-Hyphen spelling, and I've been wondring
why people do that. A hidden agenda by me was to migrate people
away from that practice, but that is an independent issue ;-).
I like your "detect lines that looks like a RFC2822 header that
has some e-mail address" approach quite a lot.
^ permalink raw reply
* Re: [PATCH 2/3] sha1_file: add the ability to parse objects in "pack file format"
From: Linus Torvalds @ 2006-07-12 16:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzmffz5xe.fsf@assigned-by-dhcp.cox.net>
On Tue, 11 Jul 2006, Junio C Hamano wrote:
>
> You seem to have forgotten one file (fetch-pack.c) but that was
> trivial. I'll apply and push it out shortly.
Actually, it was fetch.c, not fetch-pack.c, and I forgot that due to a
very real (and totally separate) bug.
The makefile doesn't have any dependencies for "fetch.o" and "rsh.o", so
when you change the headers, they never get rebuilt.
I think fetch.o and rsh.o should either get added to the library files, or
we need something like this..
(I didn't check that I caught all the appropriate *.o files, but this
should be better than what we have now).
Even better would be to make the dependancies automatic. The kernel does
that really well with some GNU Makefile magic, but it also depends on
magic gcc command line flags ("-Wp,-MD,$(depfile)")
Linus
---
diff --git a/Makefile b/Makefile
index e75fb13..854e0af 100644
--- a/Makefile
+++ b/Makefile
@@ -236,6 +236,9 @@ BUILTIN_OBJS = \
builtin-cat-file.o builtin-mailsplit.o builtin-stripspace.o \
builtin-update-ref.o builtin-fmt-merge-msg.o
+MISC_OBJS = \
+ fetch.o rsh.o http-fetch.o http-push.o
+
GITLIBS = $(LIB_FILE) $(XDIFF_LIB)
LIBS = $(GITLIBS) -lz
@@ -615,7 +618,7 @@ git-http-push$X: revision.o http.o http-
$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
$(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)
-$(LIB_OBJS) $(BUILTIN_OBJS): $(LIB_H)
+$(LIB_OBJS) $(BUILTIN_OBJS) $(MISC_OBJS): $(LIB_H)
$(patsubst git-%$X,%.o,$(PROGRAMS)): $(LIB_H) $(wildcard */*.h)
$(DIFF_OBJS): diffcore.h
^ permalink raw reply related
* Re: Re : 2 questions on git-send-email usage
From: Linus Torvalds @ 2006-07-12 16:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Franck Bui-Huu
In-Reply-To: <7v1wsqzt8f.fsf@assigned-by-dhcp.cox.net>
On Wed, 12 Jul 2006, Junio C Hamano wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
> >
> > A number of people end up capitalizing the sign-off differently, so you
> > have lines like "Signed-Off-By: Xy Zzy <xyzzy@example.org>".
>
> Documentation/SubmittingPatches (the kernel one) does not show
> the ugly Camel-Case-With-Hyphen spelling, and I've been wondring
> why people do that.
Yeah, I actually try to edit it to the "proper" format when I notice it
(which is not most of the time, but it's pretty rare to begin with).
More commonly, people mistype their own email addresses, and
_occasionally_ just mis-type the whole Signed-off-by: line (we've got a
few semi-colons instead of colons in the kernel, for example, and some
lines that are missing the final '>' in the email etc.
So being somewhat forgiving might help, but I think another thing that
migth help is a flag to "git-am" to _not_ apply a patch that lacks a
previous sign-off.
I, for example, don't use the --signoff flag, partly because I want to
make sure that I sign of only on patches that already have a sign-off from
the previous person when it comes as email (or I add the sign-off only
after looking at the patch closely). But if there was a
"--error-on-no-signoff" flag, I could use it.
Linus
^ permalink raw reply
* Re: [PATCH] gitweb.css: Courer fonts for commits and tree-diff
From: Luben Tuikov @ 2006-07-12 17:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vac7f1htw.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> Luben Tuikov <ltuikov@yahoo.com> writes:
>
> > Courer fonts for the commit header, commit message,
> > and tree-diff.
> >
> > Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
>
> I really do not want to be in the position to judge a patch like
> this, whose evaluation is solely based on "prettiness" factor.
>
> But if I really have to, I would say this makes things uglier
> and less readable. Maybe asking for monospace is less yucky but
> naming Courier explicitly?
Sometimes people would put ASCII art in their commit messages,
things like a simple table, compiler output, log output, etc,
and I wanted to _preserve_ the intent of such output. This is why
I changed it to Courier. (sorry for the misspelling of Courier)
> BTW what tool do you use to generate and send your patches? I
> remember another patch from you recently did not apply and it
> turned out the problem was that the last hunk had line numbers
> wrong. This patch has exactly the same problem and I am
> wondering why.
I use git. Those patches are against a one-off branch, which I created
for the purpose of sending you the patches.
The original patches are against my "git-lt" branch, which has
the File::MMagic changes in it -- it is my working branch.
So I generated a patch off of "git-lt", applied it to "one-off-gitweb",
which is identical to the git "master" branch, and sent the patches.
Luben
>
> I count 10 lines of original and 15 lines of new material in
> this hunk but the hunk header claims to have 11 lines of
> original text.
>
> ---
> gitweb/gitweb.css | 9 ++++++++-
> 1 files changed, 8 insertions(+), 1 deletions(-)
> diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
> index 98410f5..b51282b 100644
> --- a/gitweb/gitweb.css
> +++ b/gitweb/gitweb.css
> ...
> @@ -142,11 +144,15 @@ table {
> padding: 8px 4px;
> }
>
> -table.project_list, table.diff_tree {
> +table.project_list {
> border-spacing: 0;
> }
>
> +table.diff_tree {
> + border-spacing: 0;
> + font-family: courier;
> +}
> +
> table.blame {
> border-collapse: collapse;
> }
> --
> 1.4.1.g9ca3
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] gitweb.cgi: Teach tree->raw to not require the hash of the blob
From: Luben Tuikov @ 2006-07-12 17:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64i31h6f.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> Luben Tuikov <ltuikov@yahoo.com> writes:
>
> > Teach tree->raw to not require the hash of the blob, but to
> > figure it out from the file name. This allows to externally
> > link to files into the repository, such that the hash is not
> > required. I.e. the file obtained would be as of the HEAD
> > commit.
> >
> > In contrast tree->blob for binary files passes the hash, as
> > does tree->blob->plain for "text/*" files.
> >
> > Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
> > ---
> > gitweb/gitweb.cgi | 20 ++++++++++++++++----
> > 1 files changed, 16 insertions(+), 4 deletions(-)
>
> This has exactly the same line number problem.
[cut]
> Hand-applied, tried, got confused and dropped.
I'll regenerate and send it to the list.
> I think _allowing_ to accept filename not hash is a sane change,
> and would be useful if you want to allow linking to always the
> HEAD version from external sites,
Indeed, it is useful.
> but I do not think listing the
> raw link in the tree view without the hash is a good idea. It
> makes things quite confusing that "blob" link in its
> neighbourhood gives the blob from that specific version, but
> "raw" gives the version from HEAD, even when you are browsing
> something other than HEAD.
I just thought it to be an easy place to put the "raw"-no-hash
link.
BTW, Junio, it would be a shame to lose this capability. How
would you like to proceed with this? Where would you like to
see this kind of link go?
> BTW, can somebody volunteer to be a gitweb/ "subsystem
> maintainer"?
Make sure you pick someone liberal without personal aspirations
or turning it into a personal crusade. Service to the community
(not self, or company XYZ) is best.
Luben
^ permalink raw reply
* Re: [PATCH] gitweb.cgi: Teach tree->raw to not require the hash of the blob
From: Luben Tuikov @ 2006-07-12 18:02 UTC (permalink / raw)
To: Jakub Narebski, junkio; +Cc: git
In-Reply-To: <e92c1e$lvk$1@sea.gmane.org>
--- Jakub Narebski <jnareb@gmail.com> wrote:
> Junio C Hamano wrote:
>
> > Luben Tuikov <ltuikov@yahoo.com> writes:
> >
> >> Teach tree->raw to not require the hash of the blob, but to
> >> figure it out from the file name. This allows to externally
> >> link to files into the repository, such that the hash is not
> >> required. I.e. the file obtained would be as of the HEAD
> >> commit.
> >>
> >> In contrast tree->blob for binary files passes the hash, as
> >> does tree->blob->plain for "text/*" files.
>
> > I think _allowing_ to accept filename not hash is a sane change,
> > and would be useful if you want to allow linking to always the
> > HEAD version from external sites, but I do not think listing the
> > raw link in the tree view without the hash is a good idea. It
> > makes things quite confusing that "blob" link in its
> > neighbourhood gives the blob from that specific version, but
> > "raw" gives the version from HEAD, even when you are browsing
> > something other than HEAD.
> >
> > BTW, can somebody volunteer to be a gitweb/ "subsystem
> > maintainer"?
>
> I think the change to raw aka. blob_plain and not to plain is because in
> plain view you have this HEAD link which takes us to HEAD revision of the
> file (even if we are on different branch IIRC).
>
> Workaround for either format is to remove 'h' (hash) parameter entirely, and
> put in 'hb' (hashbase aka headref aka branch) the branch name. Gitweb then
> shows the contents of latest version of the file.
>
> BTW. sometimes you want to link to specific version of the file, and
> sometimes to newest. I think it would be best (if possible, feasible, and
> not too much resource consuming) that links from tree specified by hash be
> to specified by hash version of file, while links from tree specified by
> headref and name only would have links to latest version of the file.
You seem to have hand-edited the mail headers to remove
Junio and myself from the CC/To headers list, but leave git@vger.
Please don't do that. Just click Reply-All and continue with your
message.
Thanks,
Luben
P.S. Restored.
^ permalink raw reply
* Re: [PATCH] gitweb.cgi: Teach tree->raw to not require the hash of the blob
From: Jakub Narebski @ 2006-07-12 18:12 UTC (permalink / raw)
To: ltuikov, junkio, git
In-Reply-To: <20060712180204.23953.qmail@web31801.mail.mud.yahoo.com>
On 7/12/06, Luben Tuikov <ltuikov@yahoo.com> wrote:
> You seem to have hand-edited the mail headers to remove
> Junio and myself from the CC/To headers list, but leave git@vger.
>
> Please don't do that. Just click Reply-All and continue with your
> message.
No, I've just replied from newsreader (not mail client) via GMane news
interface to git mailing list (gmane.comp.version-control.git), and I forgot
to use Reply-All, i.e. use mail as well as news interface.
Besides I seem to have problems trying to configure KNode to send
mail, especially with mixed mail+news sending.
--
Jakub Narebski
^ permalink raw reply
* Re: git-daemon problem
From: Matthias Lederhofer @ 2006-07-12 19:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlkqz1lja.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> This breaks the newer clients that knows how to do side-band
> doesn't it?
Probably, this patch is just to give a starting point where the
problem could be.
> Would this replacement patch help?
[use write instead of safe_write]
This seems to fix it. Perhaps it should be xwrite instead of write.
> Maybe we should check if fd 2 is sane at daemon startup, and
> otherwise open /dev/null for writing and dup2 it to fd 2?
daemon startup is probably not the right place because as long as the
terminal is open this will be fine.
^ permalink raw reply
* [PATCH] documentation about exclude/ignore files
From: Matthias Lederhofer @ 2006-07-12 19:54 UTC (permalink / raw)
To: git
---
Use .git/info/exclude in the example in git-ls-files.txt as .gitignore
is used there and update the list of commands looking at
.git/info/exclude in repository-layout.txt.
---
Documentation/git-ls-files.txt | 4 ++--
Documentation/repository-layout.txt | 8 +++++---
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
index 4d8a2ad..8520b97 100644
--- a/Documentation/git-ls-files.txt
+++ b/Documentation/git-ls-files.txt
@@ -207,7 +207,7 @@ An exclude pattern is of the following f
An example:
--------------------------------------------------------------
- $ cat .git/ignore
+ $ cat .git/info/exclude
# ignore objects and archives, anywhere in the tree.
*.[oa]
$ cat Documentation/.gitignore
@@ -217,7 +217,7 @@ An example:
!foo.html
$ git-ls-files --ignored \
--exclude='Documentation/*.[0-9]' \
- --exclude-from=.git/ignore \
+ --exclude-from=.git/info/exclude \
--exclude-per-directory=.gitignore
--------------------------------------------------------------
diff --git a/Documentation/repository-layout.txt b/Documentation/repository-layout.txt
index b52dfdc..275d18b 100644
--- a/Documentation/repository-layout.txt
+++ b/Documentation/repository-layout.txt
@@ -120,9 +120,11 @@ info/grafts::
info/exclude::
This file, by convention among Porcelains, stores the
- exclude pattern list. `git status` looks at it, but
- otherwise it is not looked at by any of the core git
- commands.
+ exclude pattern list. `.gitignore` is the per-directory
+ ignore file. `git status`, `git add`, `git rm` and `git
+ clean` look at it but the core git commands do not look
+ at it. See also: gitlink:git-ls-files[1] `--exclude-from`
+ and `--exclude-per-directory`.
remotes::
Stores shorthands to be used to give URL and default
--
1.4.1.gb16f
^ permalink raw reply related
* Note on "git grep"
From: Linus Torvalds @ 2006-07-12 21:33 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
Heh. Since I've been bisecting a laptop of mine that keeps having ACPI
problems, I notived something fun about "git grep".
Using the external "grep" is about 10 times faster for the hot-cache case,
but for cold-cache, forcing the internal one is actually a _lot_ faster
because a fully packed kernel archive just gets wonderfully better IO
patterns than the "real filesystem" image.
So doing "git grep some-random-string HEAD" takes about 16 seconds
cold-cache, and 11 seconds hot-cache.
In contrast, doing "git grep some-random-string" takes over a minute
cold-cache, and about 2 seconds hot-cache. It's kind of sad that we can't
dynamically notice which case we have, since the hot-cache case is _so_
much better for the external grep, but then cold-cache sucks for it..
I just thought I'd point this out to people, since I found it interesting
how the built-in grep functionality actually outperforms the "real" one
under some circumstances.
Linus
^ 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