* Re: [PATCH] cg-commit: fix signed off handling
From: Jonas Fonseca @ 2006-09-24 18:32 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060924174519.GW20017@pasky.or.cz>
Petr Baudis <pasky@suse.cz> wrote Sun, Sep 24, 2006:
> Dear diary, on Fri, Aug 25, 2006 at 02:27:40AM CEST, I got a letter
> where Jonas Fonseca <fonseca@diku.dk> said that...
> > Handle the sign off insertion before starting the CG: comment lines. Also,
> > fix typo in grepping for existing sign off lines.
> >
> > Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
> > ---
> >
> > The late calling of the add_signoff function has multiple problems,
> > since at that point comment lines has already been added and the sign
> > off line will end up in only one of the log message files.
>
> Well, the commit that moved this was
>
> Commit: 4cf220db10c0b937f9852513effc5565fcbb4f86
> Author: Petr Baudis <pasky@pixie.suse.cz> Thu, 20 Jul 2006 11:37:31 -0400
>
> * cg-commit:
>
> Add signoff past the message if getting it from stdin
>
> What about this?
The thing you committed seems to work, so I am happy again. :)
> diff --git a/cg-commit b/cg-commit
> index 43e6c6c..beedb6f 100755
> --- a/cg-commit
> +++ b/cg-commit
> @@ -402,10 +402,6 @@ if [ "$msgfile" ]; then
> written=1
> fi
>
> -# Always have at least one blank line, to ease the editing for
> -# the poor people whose text editor has no 'O' command.
> -[ "$written" ] || { tty -s && echo >>"$LOGMSG"; }
> -
> add_signoff() {
> if [ "$signoff" ] && ! grep -q -i "signed-off-by: $signoff" $LOGMSG; then
> grep -q -i sign-off-by $LOGMSG || echo
^^^^^^^^^^^
My patch also fixed this to grep for "signed-off-by".
--
Jonas Fonseca
^ permalink raw reply
* Re: cg-commit -p -m ignores -p
From: Petr Baudis @ 2006-09-24 17:48 UTC (permalink / raw)
To: git, 387515
In-Reply-To: <20060915132319.12117.qmail@7d60384c102e6d.315fe32.mid.smarden.org>
Dear diary, on Fri, Sep 15, 2006 at 03:23:19PM CEST, I got a letter
where Gerrit Pape <pape@smarden.org> said that...
> Hi, please see http:/bugs.debian.org/387515 or below. I agree that
> ideally cg-commit should behave differently.
>
> Thanks, Gerrit.
>
> ----- Forwarded message from Andrew Suffield <asuffield@suffields.me.uk> -----
>
> cg-commit -p -m ignores the -p argument and silently commits. Yes,
> this is documented, but it's still stupid behaviour; if the user had
> meant that, they would have just used -m alone.
>
> At the very least, it should abort with an error (on the basis that
> the command makes no sense); more sensibly, it should create a log
> message with the given string and then spawn an editor (and then since
> the user will probably exit without changing the file, the "Abort or
> commit?" message would appear as per usual, which seems to me to be
> appropriate behaviour).
>
>
> ----- End forwarded message -----
Thanks, fixed by making cg-commit -p imply -e.
--
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
* Re: [PATCH] Fixes git-cherry algorithmic flaws
From: Junio C Hamano @ 2006-09-24 17:47 UTC (permalink / raw)
To: Petr Baudis; +Cc: Ilpo Järvinen, git
In-Reply-To: <20060924111737.GL20017@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Hmm, well, what's curious is that the documentation says
>
> Every commit with a changeset that doesn't exist in the other branch
> has its id (sha1) reported, prefixed by a symbol. Those existing only
> in the <upstream> branch are prefixed with a minus (-) sign, and those
> that only exist in the <head> branch are prefixed with a plus (+)
> symbol.
>
> which is in contradiction of Ilpo's description of the old algorithm
> (and also your description of it). It would seem he just wants to fix it
> according to the documented behaviour.
>
> I guess the documentation is what's broken then?
Ah I did not realize that, but yes the documentation is
incorrect.
I wonder if we can kill it by introducing a new rev notation and
using regular rev-list family of commands instead.
What we want here is a way to say "give me commits that are in B
but not in A, but before returning a commit see if there is an
equivalent change in the set of commits that are in A but not in
B, and filter it out".
Time for "rev-list A....B"? ;-)
^ permalink raw reply
* Re: [PATCH] cg-commit: fix signed off handling
From: Petr Baudis @ 2006-09-24 17:45 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <20060825002740.GH2817@diku.dk>
Dear diary, on Fri, Aug 25, 2006 at 02:27:40AM CEST, I got a letter
where Jonas Fonseca <fonseca@diku.dk> said that...
> Handle the sign off insertion before starting the CG: comment lines. Also,
> fix typo in grepping for existing sign off lines.
>
> Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
> ---
>
> The late calling of the add_signoff function has multiple problems,
> since at that point comment lines has already been added and the sign
> off line will end up in only one of the log message files.
Well, the commit that moved this was
Commit: 4cf220db10c0b937f9852513effc5565fcbb4f86
Author: Petr Baudis <pasky@pixie.suse.cz> Thu, 20 Jul 2006 11:37:31 -0400
* cg-commit:
Add signoff past the message if getting it from stdin
What about this?
diff --git a/cg-commit b/cg-commit
index 43e6c6c..beedb6f 100755
--- a/cg-commit
+++ b/cg-commit
@@ -402,10 +402,6 @@ if [ "$msgfile" ]; then
written=1
fi
-# Always have at least one blank line, to ease the editing for
-# the poor people whose text editor has no 'O' command.
-[ "$written" ] || { tty -s && echo >>"$LOGMSG"; }
-
add_signoff() {
if [ "$signoff" ] && ! grep -q -i "signed-off-by: $signoff" $LOGMSG; then
grep -q -i sign-off-by $LOGMSG || echo
@@ -413,6 +409,16 @@ add_signoff() {
fi >> $LOGMSG
}
+if tty -s; then
+ # Always have at least one blank line, to ease the editing for
+ # the poor people whose text editor has no 'O' command.
+ [ "$written" ] || echo >>"$LOGMSG"
+ # Also, add the signoff line _now_ before spewing out CG: lines.
+ # (In case of non-tty input we do it later after taking the actual
+ # log message from stdin.)
+ add_signoff
+fi
+
# CG: -----------------------------------------------------------------------
editor_comment_start commit
@@ -472,7 +478,6 @@ editor_msg_end
cp "$LOGMSG" "$LOGMSG2"
if tty -s; then
- add_signoff
if [ "$editor" ] && ! editor $commitalways commit c; then
rm "$LOGMSG" "$LOGMSG2"
[ "$review" ] && rm "$PATCH"
--
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 related
* Re: [PATCH] cg-commit: Fix a typo that would inhibit running of post-commit script:
From: Petr Baudis @ 2006-09-24 17:39 UTC (permalink / raw)
To: Jim Meyering; +Cc: Jonas Fonseca, git
In-Reply-To: <87ac4zq237.fsf@rho.meyering.net>
Dear diary, on Sat, Sep 16, 2006 at 05:10:36PM CEST, I got a letter
where Jim Meyering <jim@meyering.net> said that...
> Jonas Fonseca <fonseca@diku.dk> wrote:
> > Jim Meyering <jim@meyering.net> wrote Thu, Aug 24, 2006:
> >> I tried cg-commit with a commit hook, but the hook never ran.
> >> The problem was a typo:
> >>
> >> Fix a typo that would inhibit running the post-commit script:
> >> s/commit-post/post-commit/.
> >
> > If I remember correctly, historically, the commit-post existed before
> > the post-commit appeared. You can see that it is documented in the man
> > page so it is not a typo.
> >
> > However, this should certainly be updated, but I think a better fix
> > would be to transitionally warn the user about the existence of the
> > commit-post hook before using it in favour of post-commit.
>
> How about this?
> Check for both and if there's exactly one, use that.
> If it's the old one, give a diagnostic suggesting to rename it.
> If both exist, execute neither, give a diagnostic and fail.
>
> If you like this, I'll prepare a patch.
That would be awesome. :-)
Thanks in advance,
--
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
* Re: Standard cogito + patches: Changes to 'master'
From: Petr Baudis @ 2006-09-24 17:28 UTC (permalink / raw)
To: Nico -telmich- Schottelius; +Cc: git
In-Reply-To: <20060818180143.GA4118@schottelius.org>
Dear diary, on Fri, Aug 18, 2006 at 08:01:43PM CEST, I got a letter
where Nico -telmich- Schottelius <nico-linux-git@schottelius.org> said that...
> nico-linux-git@schottelius.org [Fri, Aug 18, 2006 at 05:54:54PM -0000]:
> > [Commits]
>
> For those who do not know where to find that branch:
>
> Gitweb: http://unix.schottelius.org/cgi-bin/gitweb.cgi
> Git-repo:http://unix.schottelius.org/git/cogito-original.git/
I've decided to bite the bullet wrt. the messy history (since I feel so
lonely in the Cogito repository ;) and merged it. Thanks! :-)
Is there anything new in the POSIX shell porting mission?
--
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
* Re: [PATCH] Introducing cg-xxdiff for conflict resolution
From: Petr Baudis @ 2006-09-24 17:28 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Martin Langhoff, git
In-Reply-To: <46a038f90609241022i6ac11da1o1a1cba199595d036@mail.gmail.com>
Dear diary, on Sun, Sep 24, 2006 at 07:22:35PM CEST, I got a letter
where Martin Langhoff <martin.langhoff@gmail.com> said that...
> On 9/24/06, Petr Baudis <pasky@suse.cz> wrote:
> >In that case I think the most natural way for this tool to interface
> >would be in part of some kind of cg-resolve swiss-army knife for
> >resolving conflicts:
> >
> > cg-resolve --mine for taking just the version from _my_
> > side of the merge
> > cg-resolve --other dtto for the other side of the merge
> > cg-resolve -g graphically resolve
> > (vimdiff/xxdiff/meld/...)
> > surely more would be invented over time
>
> Sounds reasonable. But I think we have to keep in mind that you only
> know if the conflict is nasty after you have a go at fixing it. And I
> sometimes find that I try with cg-xxdiff... and I go back to the plain
> old conflict. That is why it doesn't clobber the file -- to protect a
> manual merge in process.
Oh yes, I wanted to complain about that. ;-)
Yes, sometimes it is useful to go back, but I guess most of the time
probably not (not speaking from the experience though) and I hate tools
which leave random copies of a file I have tracked in a VCS around and I
have to collect their garbage manually.
The tool should just have a way to tell it "cancel" in case of trouble
and restore the original state of the file. And of course
cg-resolve --remerge re-run the 3-way merge on the file
would be useful anyway.
> >But I can adjust such details when applying your patch.
>
> Great! -- I'm travelling and at an airport "free access" computer. It
> should be illegal to run airports without free wifi in this day and
> age.
Heartily agreed.
We should always suggest the locals to build yet another airport right
near the old one to promote free market and competition!
And when one of them bankrupts it could make for a nice paintball arena,
I guess.
--
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
* Re: [PATCH] Introducing cg-xxdiff for conflict resolution
From: Martin Langhoff @ 2006-09-24 17:22 UTC (permalink / raw)
To: Petr Baudis; +Cc: Martin Langhoff, git
In-Reply-To: <20060924171246.GY13132@pasky.or.cz>
On 9/24/06, Petr Baudis <pasky@suse.cz> wrote:
> In that case I think the most natural way for this tool to interface
> would be in part of some kind of cg-resolve swiss-army knife for
> resolving conflicts:
>
> cg-resolve --mine for taking just the version from _my_
> side of the merge
> cg-resolve --other dtto for the other side of the merge
> cg-resolve -g graphically resolve
> (vimdiff/xxdiff/meld/...)
> surely more would be invented over time
Sounds reasonable. But I think we have to keep in mind that you only
know if the conflict is nasty after you have a go at fixing it. And I
sometimes find that I try with cg-xxdiff... and I go back to the plain
old conflict. That is why it doesn't clobber the file -- to protect a
manual merge in process.
> Well, all the Cogito scripts should have some consistent form. :-)
heh - consistency? overrated! ;-)
> But I can adjust such details when applying your patch.
Great! -- I'm travelling and at an airport "free access" computer. It
should be illegal to run airports without free wifi in this day and
age.
cheers,
martin
^ permalink raw reply
* Re: [PATCH] Introducing cg-xxdiff for conflict resolution
From: Petr Baudis @ 2006-09-24 17:12 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Martin Langhoff, git
In-Reply-To: <46a038f90609241002i1db98ed6n118077089c9e417f@mail.gmail.com>
Dear diary, on Sun, Sep 24, 2006 at 07:02:28PM CEST, I got a letter
where Martin Langhoff <martin.langhoff@gmail.com> said that...
> On 9/24/06, Petr Baudis <pasky@suse.cz> wrote:
> >Hmm, I think this would be generally more useful during the actual merge
> >phase - if merge returns error, you fire up
> >git-magic-conflict-resolution-driver and have fun.
>
> Well, in many cases the conflict markers are just ok and exactly what
> I want. If the two sides of the conflict are clear, the resolution is
> usually clear as well. OTOH, it may be a big mess where xxdiff gives
> more visual cues as to WTF is going on...
>
> IOW I don't want it to be part of the merge automagically...
In that case I think the most natural way for this tool to interface
would be in part of some kind of cg-resolve swiss-army knife for
resolving conflicts:
cg-resolve --mine for taking just the version from _my_
side of the merge
cg-resolve --other dtto for the other side of the merge
cg-resolve -g graphically resolve
(vimdiff/xxdiff/meld/...)
surely more would be invented over time
> >> +. git-sh-setup
> >
> >Uh-oh. :-)
>
> Is that bad? <blush> I am not doing anything too cogito-specific, and
> I just don't know what cg-Xlib will do for me...
Well, all the Cogito scripts should have some consistent form. :-)
But I can adjust such details when applying your patch.
--
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
* Re: [PATCH] Introducing cg-xxdiff for conflict resolution
From: Martin Langhoff @ 2006-09-24 17:02 UTC (permalink / raw)
To: Petr Baudis; +Cc: Martin Langhoff, git
In-Reply-To: <20060924165037.GS20017@pasky.or.cz>
On 9/24/06, Petr Baudis <pasky@suse.cz> wrote:
> Hmm, I think this would be generally more useful during the actual merge
> phase - if merge returns error, you fire up
> git-magic-conflict-resolution-driver and have fun.
Well, in many cases the conflict markers are just ok and exactly what
I want. If the two sides of the conflict are clear, the resolution is
usually clear as well. OTOH, it may be a big mess where xxdiff gives
more visual cues as to WTF is going on...
IOW I don't want it to be part of the merge automagically...
> > +. git-sh-setup
>
> Uh-oh. :-)
Is that bad? <blush> I am not doing anything too cogito-specific, and
I just don't know what cg-Xlib will do for me...
> > +git cat-file blob `git rev-parse FETCH_HEAD`:$FILE > $FILE~branch
>
> Cogito does not use FETCH_HEAD.
eeek. you ar right. I mix and match git and cogito as you can see. Not
so smart. I see cg-merge uses merging, merge-base and merging-sym --
I'll rework it using those...
cheers,
martin
^ permalink raw reply
* Re: What will happen to git.git in the near future
From: Rene Scharfe @ 2006-09-24 16:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7iztbldm.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano schrieb:
> - We should deprecate git-tar-tree. However, it has been
> around and advertised for quite some time, so we need to make
> sure people would not get burned too badly. It might be
> worthwhile to rewrite git-tar-tree as a thin wrapper to
> "git-archive --format=tar" and remove git-upload-tar now (in
> other words, "git-tar-tree --remote" will continue to work,
> but it will talk with "git-upload-archive", not with
> "git-upload-tar" on the other end), release 1.4.3 with it
> with a deprecation warning, and then remove it in 1.4.5.
Hmm. The local case in git-tar-tree is already a thin wrapper.
How about something like this shell script as a replacement for
the entire command?
René
--- snip! --
#!/bin/sh
#
# Copyright (C) 2006 Rene Scharfe
USAGE='[--remote=<repo>] <tree-ish> [basedir]'
. git-sh-setup
case "$1" in
--remote=*) remote=1;;
*) remote=0;;
esac
case "$#,$remote" in
1,0) exec git-archive --format=tar "$1";;
2,0) exec git-archive --format=tar --prefix="$2"/ "$1";;
2,1) exec git-archive --format=tar "$1" "$2";;
3,1) exec git-archive --format=tar --prefix="$3"/ "$1" "$2";;
*) usage;;
esac
^ permalink raw reply
* Re: 2.6.18-mm1
From: Petr Baudis @ 2006-09-24 16:55 UTC (permalink / raw)
To: linux-kernel; +Cc: git
In-Reply-To: <20060924144710.GG25666@flint.arm.linux.org.uk>
Dear diary, on Sun, Sep 24, 2006 at 04:47:10PM CEST, I got a letter
where Russell King <rmk+lkml@arm.linux.org.uk> said that...
> On Sun, Sep 24, 2006 at 04:29:58PM +0200, Petr Baudis wrote:
> > Dear diary, on Sun, Sep 24, 2006 at 04:20:06PM CEST, I got a letter
> > where Russell King <rmk+lkml@arm.linux.org.uk> said that...
> > > I'm now told that the resulting tree after all the commits is correct.
> > > The problem is that all the files which were supposed to be deleted by
> > > previous patches ended up actually being deleted by the final patch in
> > > the series.
> > >
> > > So the resulting tree is fine, it's just that the history is rather
> > > broken.
> >
> > Well, that rewritehist batch should work fine even in this case.
> >
> > (Of course that's assuming that no change was supposed to happen to
> > those files in the last four days.)
> >
> > > I think a solution to this might be to use git-apply, but there's one
> > > draw back - I currently have the facility to unpatch at a later date,
> > > but git-apply doesn't support -R.
> >
> > Yes, if there's not too many patches perhaps using git-apply -R would be
> > simpler. git-apply in git-1.4.2.1 does support -R.
>
> I'm just experimenting with git-apply for the forward case, and I'm
> hitting a small problem. I can do:
>
> cat patch | git-apply --stat
>
> then I come to commit it:
>
> git commit -F -
>
> but if I just use that, _all_ changes which happen to be in the tree
> get committed, not just those which are in the index file. Manually
> doing each step of the commit is far too much work in perl...
Hmm, I'm sorry but I'm not all that well-versed in git commit inner
workings. The best way to get help is to cc' git@vger.kernel.org.
According to git-commit documentation, when you do what you wrote you
use, it _should_ commit just the index file...
--
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
* Re: [PATCH] Introducing cg-xxdiff for conflict resolution
From: Petr Baudis @ 2006-09-24 16:50 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <11546624471356-git-send-email-martin@catalyst.net.nz>
Dear diary, on Fri, Aug 04, 2006 at 05:34:07AM CEST, I got a letter
where Martin Langhoff <martin@catalyst.net.nz> said that...
> This is a bit of a crude but really useful shortcut for conflict resolution.
> The name is bad, but matches git-xxdiff which has been around for like... ages
Yes, the name is horrible. :-)
> As Cogito doesn't make use of the index during merges/applies, cg-xxdiff
> is somewhat more brittle and cannot not help during conflict resolution when
> using cg-patch.
>
> Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
Hmm, I think this would be generally more useful during the actual merge
phase - if merge returns error, you fire up
git-magic-conflict-resolution-driver and have fun.
Which reminds me that I should make some more effort to unify
cg-Xmergeonefile and git-merge-one-file...
> +. git-sh-setup
Uh-oh. :-)
> +git cat-file blob `git rev-parse FETCH_HEAD`:$FILE > $FILE~branch
Cogito does not use FETCH_HEAD.
--
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
* Re: [RFC/PATCH] gitweb: Add committags support
From: Jakub Narebski @ 2006-09-24 16:35 UTC (permalink / raw)
To: git
In-Reply-To: <ef5jkv$gep$1@sea.gmane.org>
Jakub Narebski wrote:
> Junio C Hamano wrote:
>
>> Jakub Narebski <jnareb@gmail.com> writes:
>>
>>> The idea of doing committag parsing, and preserving replacements
>>> from matching committag and being subject to HTML escaping by using
>>> reference to string has it's merits.
>>>
>>> I'd have to think about it.
>>
>> Good. My obviously buggy illustration would be easier to read
>> with this patch ;-).
>
> Don't forget about final s,\n,<br/>\n,gm if we parse it as a whole,
> and not line by line.
>
> By the way, I think that only the driver (i.e. format_log_line_html) has to
> be changed...
Yet another question is how to deal with commit message specific
"syntax highlighting". Currently, parsing commit message line by line,
we treat specially signoff lines (syntax highlighting, and removing
trailing empty lines after signoff), empty lines (we collapse consecutive
empty lines); the rest goes through format_log_line_html... and committags.
Tag messages have another specific syntax highlighting, namely PGP/GPG
signature part, which should be syntax highlighted I think (and not
subject to committags replacements).
Some of the problems of marking replacements as not to be committags
searched and not to be HTML escaped can be dealt with by changing the
order of committags. For example having 'URL' tag as first tag to check
we avoid invoking it on committag replacements links.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: The GPL: No shelter for the Linux kernel?
From: Linus Torvalds @ 2006-09-24 16:34 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Petr Baudis, David Schwartz, linux-kernel, git
In-Reply-To: <Pine.LNX.4.61.0609240952240.28459@yvahk01.tjqt.qr>
On Sun, 24 Sep 2006, Jan Engelhardt wrote:
>
> Would every file that does not contain an explicit license (this
> excludes MODULE_LICENSE) falls under COPYING?
Basically, yes. There's nothing to really say that you need to state your
copyright license in every individual file, especially if those files are
only ever distributed as a whole, together with other things (which souce
code obviously is - you generally cannot even use an individual *.c file
without the infrastructure it was written for).
If a file doesn't have a license mentioned, it doesn't mean that it's
"free for all" or not copyrighted, it just means that you need to find out
what the license is some other way (and if you can't find out, you
shouldn't be copying that file ;)
Of course, for clarity, a lot of projects end up adding at least a minimal
copyright header license everywhere, just to cover their *sses. It's not
required, but maybe it avoids some confusion, especially if that file is
later copied into some other project with other basic rules (but if you
do that, you really _should_ have added the information at that point!).
Me personally, I prefer to not see huge boiler-plate licenses at the top
of the file, so that every time I open a new file I just see the dang
license that has nothing to do with why I'm opening it. So I tend to do a
fairly minimal thing ("Copyright (C) Linus Torvalds 2006" or similar) but
sometimes I drop even that (ie I personally feel silly adding a copyright
message to a header file, so I usually don't - and sometimes I just
forget about it in real source files too)..
Others are more anal^H^H^H^Hcareful, and tend to add a few lines to tell
what the license is, the ubiqutous "all rights reserved" (which is just
idiocy), and a blinking gif advertisement for their company. Oh, and the
"no warranty" clause. And an aphorism or two.
In other words, I don't think there are any real rules. Different people
and different projects have more or less different rules. If you expect to
collect treble damages in the US, you might want to add a copyright notice
just about everywhere, "just in case", and to "show you really care".
IANAL, of course.
Linus
^ permalink raw reply
* Re: [PATCH] cg-commit --review may permanently delete changes
From: Petr Baudis @ 2006-09-24 15:50 UTC (permalink / raw)
To: Dennis Stosberg; +Cc: git
In-Reply-To: <20060728171152.G3a9ef049@leonov.stosberg.net>
Dear diary, on Fri, Jul 28, 2006 at 07:11:52PM CEST, I got a letter
where Dennis Stosberg <dennis@stosberg.net> said that...
> If the patch is changed in the editor in such a way that cg-patch
> can not apply it, all changes made since the last commit are
> irrecoverably lost, which is _really_ bad.
>
> This patch lets cg-commit reapply the old patch and keep the edited
> patch for manual fix-up.
>
> Signed-off-by: Dennis Stosberg <dennis@stosberg.net>
Hmm, good catch. Unfortunately, we can't safely patch the original patch
over that either, since bits of the edited patch _might_ got applied.
As the first step, I've prevented Cogito from deleting any of the
temporary files and now it instead reports their name to the user and
lets him fix up the situation.
As the second stage, we should restore the original state of the tree. I
will do it when I get to it, patches welcome. :-)
--
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
* [PATCH 2/2] git-tar-tree: Move code for git-archive --format=tar to archive-tar.c
From: Rene Scharfe @ 2006-09-24 15:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Franck Bui-Huu, Git Mailing List
This patch doesn't change any functionality, it only moves code around. It
makes seeing the few remaining lines of git-tar-tree code easier. ;-)
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
Makefile | 2
archive-tar.c | 325 ++++++++++++++++++++++++++++++++++++++++++++++++++++
builtin-tar-tree.c | 313 --------------------------------------------------
3 files changed, 326 insertions(+), 314 deletions(-)
diff --git a/Makefile b/Makefile
index 739d7e3..d4f6e01 100644
--- a/Makefile
+++ b/Makefile
@@ -254,7 +254,7 @@ LIB_OBJS = \
fetch-clone.o revision.o pager.o tree-walk.o xdiff-interface.o \
write_or_die.o trace.o list-objects.o \
alloc.o merge-file.o path-list.o help.o unpack-trees.o $(DIFF_OBJS) \
- color.o wt-status.o archive-zip.o
+ color.o wt-status.o archive-zip.o archive-tar.o
BUILTIN_OBJS = \
builtin-add.o \
diff --git a/archive-tar.c b/archive-tar.c
new file mode 100644
index 0000000..ff0f6e2
--- /dev/null
+++ b/archive-tar.c
@@ -0,0 +1,325 @@
+/*
+ * Copyright (c) 2005, 2006 Rene Scharfe
+ */
+#include <time.h>
+#include "cache.h"
+#include "commit.h"
+#include "strbuf.h"
+#include "tar.h"
+#include "builtin.h"
+#include "archive.h"
+
+#define RECORDSIZE (512)
+#define BLOCKSIZE (RECORDSIZE * 20)
+
+static char block[BLOCKSIZE];
+static unsigned long offset;
+
+static time_t archive_time;
+static int tar_umask;
+static int verbose;
+
+/* writes out the whole block, but only if it is full */
+static void write_if_needed(void)
+{
+ if (offset == BLOCKSIZE) {
+ write_or_die(1, block, BLOCKSIZE);
+ offset = 0;
+ }
+}
+
+/*
+ * queues up writes, so that all our write(2) calls write exactly one
+ * full block; pads writes to RECORDSIZE
+ */
+static void write_blocked(const void *data, unsigned long size)
+{
+ const char *buf = data;
+ unsigned long tail;
+
+ if (offset) {
+ unsigned long chunk = BLOCKSIZE - offset;
+ if (size < chunk)
+ chunk = size;
+ memcpy(block + offset, buf, chunk);
+ size -= chunk;
+ offset += chunk;
+ buf += chunk;
+ write_if_needed();
+ }
+ while (size >= BLOCKSIZE) {
+ write_or_die(1, buf, BLOCKSIZE);
+ size -= BLOCKSIZE;
+ buf += BLOCKSIZE;
+ }
+ if (size) {
+ memcpy(block + offset, buf, size);
+ offset += size;
+ }
+ tail = offset % RECORDSIZE;
+ if (tail) {
+ memset(block + offset, 0, RECORDSIZE - tail);
+ offset += RECORDSIZE - tail;
+ }
+ write_if_needed();
+}
+
+/*
+ * The end of tar archives is marked by 2*512 nul bytes and after that
+ * follows the rest of the block (if any).
+ */
+static void write_trailer(void)
+{
+ int tail = BLOCKSIZE - offset;
+ memset(block + offset, 0, tail);
+ write_or_die(1, block, BLOCKSIZE);
+ if (tail < 2 * RECORDSIZE) {
+ memset(block, 0, offset);
+ write_or_die(1, block, BLOCKSIZE);
+ }
+}
+
+static void strbuf_append_string(struct strbuf *sb, const char *s)
+{
+ int slen = strlen(s);
+ int total = sb->len + slen;
+ if (total > sb->alloc) {
+ sb->buf = xrealloc(sb->buf, total);
+ sb->alloc = total;
+ }
+ memcpy(sb->buf + sb->len, s, slen);
+ sb->len = total;
+}
+
+/*
+ * pax extended header records have the format "%u %s=%s\n". %u contains
+ * the size of the whole string (including the %u), the first %s is the
+ * keyword, the second one is the value. This function constructs such a
+ * string and appends it to a struct strbuf.
+ */
+static void strbuf_append_ext_header(struct strbuf *sb, const char *keyword,
+ const char *value, unsigned int valuelen)
+{
+ char *p;
+ int len, total, tmp;
+
+ /* "%u %s=%s\n" */
+ len = 1 + 1 + strlen(keyword) + 1 + valuelen + 1;
+ for (tmp = len; tmp > 9; tmp /= 10)
+ len++;
+
+ total = sb->len + len;
+ if (total > sb->alloc) {
+ sb->buf = xrealloc(sb->buf, total);
+ sb->alloc = total;
+ }
+
+ p = sb->buf;
+ p += sprintf(p, "%u %s=", len, keyword);
+ memcpy(p, value, valuelen);
+ p += valuelen;
+ *p = '\n';
+ sb->len = total;
+}
+
+static unsigned int ustar_header_chksum(const struct ustar_header *header)
+{
+ char *p = (char *)header;
+ unsigned int chksum = 0;
+ while (p < header->chksum)
+ chksum += *p++;
+ chksum += sizeof(header->chksum) * ' ';
+ p += sizeof(header->chksum);
+ while (p < (char *)header + sizeof(struct ustar_header))
+ chksum += *p++;
+ return chksum;
+}
+
+static int get_path_prefix(const struct strbuf *path, int maxlen)
+{
+ int i = path->len;
+ if (i > maxlen)
+ i = maxlen;
+ do {
+ i--;
+ } while (i > 0 && path->buf[i] != '/');
+ return i;
+}
+
+static void write_entry(const unsigned char *sha1, struct strbuf *path,
+ unsigned int mode, void *buffer, unsigned long size)
+{
+ struct ustar_header header;
+ struct strbuf ext_header;
+
+ memset(&header, 0, sizeof(header));
+ ext_header.buf = NULL;
+ ext_header.len = ext_header.alloc = 0;
+
+ if (!sha1) {
+ *header.typeflag = TYPEFLAG_GLOBAL_HEADER;
+ mode = 0100666;
+ strcpy(header.name, "pax_global_header");
+ } else if (!path) {
+ *header.typeflag = TYPEFLAG_EXT_HEADER;
+ mode = 0100666;
+ sprintf(header.name, "%s.paxheader", sha1_to_hex(sha1));
+ } else {
+ if (verbose)
+ fprintf(stderr, "%.*s\n", path->len, path->buf);
+ if (S_ISDIR(mode)) {
+ *header.typeflag = TYPEFLAG_DIR;
+ mode = (mode | 0777) & ~tar_umask;
+ } else if (S_ISLNK(mode)) {
+ *header.typeflag = TYPEFLAG_LNK;
+ mode |= 0777;
+ } else if (S_ISREG(mode)) {
+ *header.typeflag = TYPEFLAG_REG;
+ mode = (mode | ((mode & 0100) ? 0777 : 0666)) & ~tar_umask;
+ } else {
+ error("unsupported file mode: 0%o (SHA1: %s)",
+ mode, sha1_to_hex(sha1));
+ return;
+ }
+ if (path->len > sizeof(header.name)) {
+ int plen = get_path_prefix(path, sizeof(header.prefix));
+ int rest = path->len - plen - 1;
+ if (plen > 0 && rest <= sizeof(header.name)) {
+ memcpy(header.prefix, path->buf, plen);
+ memcpy(header.name, path->buf + plen + 1, rest);
+ } else {
+ sprintf(header.name, "%s.data",
+ sha1_to_hex(sha1));
+ strbuf_append_ext_header(&ext_header, "path",
+ path->buf, path->len);
+ }
+ } else
+ memcpy(header.name, path->buf, path->len);
+ }
+
+ if (S_ISLNK(mode) && buffer) {
+ if (size > sizeof(header.linkname)) {
+ sprintf(header.linkname, "see %s.paxheader",
+ sha1_to_hex(sha1));
+ strbuf_append_ext_header(&ext_header, "linkpath",
+ buffer, size);
+ } else
+ memcpy(header.linkname, buffer, size);
+ }
+
+ sprintf(header.mode, "%07o", mode & 07777);
+ sprintf(header.size, "%011lo", S_ISREG(mode) ? size : 0);
+ sprintf(header.mtime, "%011lo", archive_time);
+
+ /* XXX: should we provide more meaningful info here? */
+ sprintf(header.uid, "%07o", 0);
+ sprintf(header.gid, "%07o", 0);
+ strlcpy(header.uname, "git", sizeof(header.uname));
+ strlcpy(header.gname, "git", sizeof(header.gname));
+ sprintf(header.devmajor, "%07o", 0);
+ sprintf(header.devminor, "%07o", 0);
+
+ memcpy(header.magic, "ustar", 6);
+ memcpy(header.version, "00", 2);
+
+ sprintf(header.chksum, "%07o", ustar_header_chksum(&header));
+
+ if (ext_header.len > 0) {
+ write_entry(sha1, NULL, 0, ext_header.buf, ext_header.len);
+ free(ext_header.buf);
+ }
+ write_blocked(&header, sizeof(header));
+ if (S_ISREG(mode) && buffer && size > 0)
+ write_blocked(buffer, size);
+}
+
+static void write_global_extended_header(const unsigned char *sha1)
+{
+ struct strbuf ext_header;
+ ext_header.buf = NULL;
+ ext_header.len = ext_header.alloc = 0;
+ strbuf_append_ext_header(&ext_header, "comment", sha1_to_hex(sha1), 40);
+ write_entry(NULL, NULL, 0, ext_header.buf, ext_header.len);
+ free(ext_header.buf);
+}
+
+static int git_tar_config(const char *var, const char *value)
+{
+ if (!strcmp(var, "tar.umask")) {
+ if (!strcmp(value, "user")) {
+ tar_umask = umask(0);
+ umask(tar_umask);
+ } else {
+ tar_umask = git_config_int(var, value);
+ }
+ return 0;
+ }
+ return git_default_config(var, value);
+}
+
+static int write_tar_entry(const unsigned char *sha1,
+ const char *base, int baselen,
+ const char *filename, unsigned mode, int stage)
+{
+ static struct strbuf path;
+ int filenamelen = strlen(filename);
+ void *buffer;
+ char type[20];
+ unsigned long size;
+
+ if (!path.alloc) {
+ path.buf = xmalloc(PATH_MAX);
+ path.alloc = PATH_MAX;
+ path.len = path.eof = 0;
+ }
+ if (path.alloc < baselen + filenamelen) {
+ free(path.buf);
+ path.buf = xmalloc(baselen + filenamelen);
+ path.alloc = baselen + filenamelen;
+ }
+ memcpy(path.buf, base, baselen);
+ memcpy(path.buf + baselen, filename, filenamelen);
+ path.len = baselen + filenamelen;
+ if (S_ISDIR(mode)) {
+ strbuf_append_string(&path, "/");
+ buffer = NULL;
+ size = 0;
+ } else {
+ buffer = read_sha1_file(sha1, type, &size);
+ if (!buffer)
+ die("cannot read %s", sha1_to_hex(sha1));
+ }
+
+ write_entry(sha1, &path, mode, buffer, size);
+ free(buffer);
+
+ return READ_TREE_RECURSIVE;
+}
+
+int write_tar_archive(struct archiver_args *args)
+{
+ int plen = args->base ? strlen(args->base) : 0;
+
+ git_config(git_tar_config);
+
+ archive_time = args->time;
+ verbose = args->verbose;
+
+ if (args->commit_sha1)
+ write_global_extended_header(args->commit_sha1);
+
+ if (args->base && plen > 0 && args->base[plen - 1] == '/') {
+ char *base = xstrdup(args->base);
+ int baselen = strlen(base);
+
+ while (baselen > 0 && base[baselen - 1] == '/')
+ base[--baselen] = '\0';
+ write_tar_entry(args->tree->object.sha1, "", 0, base, 040777, 0);
+ free(base);
+ }
+ read_tree_recursive(args->tree, args->base, plen, 0,
+ args->pathspec, write_tar_entry);
+ write_trailer();
+
+ return 0;
+}
diff --git a/builtin-tar-tree.c b/builtin-tar-tree.c
index 82b4951..aa370e3 100644
--- a/builtin-tar-tree.c
+++ b/builtin-tar-tree.c
@@ -4,7 +4,6 @@
#include <time.h>
#include "cache.h"
#include "commit.h"
-#include "strbuf.h"
#include "tar.h"
#include "builtin.h"
#include "pkt-line.h"
@@ -16,251 +15,6 @@ #define BLOCKSIZE (RECORDSIZE * 20)
static const char tar_tree_usage[] =
"git-tar-tree [--remote=<repo>] <tree-ish> [basedir]";
-static char block[BLOCKSIZE];
-static unsigned long offset;
-
-static time_t archive_time;
-static int tar_umask;
-static int verbose;
-
-/* writes out the whole block, but only if it is full */
-static void write_if_needed(void)
-{
- if (offset == BLOCKSIZE) {
- write_or_die(1, block, BLOCKSIZE);
- offset = 0;
- }
-}
-
-/*
- * queues up writes, so that all our write(2) calls write exactly one
- * full block; pads writes to RECORDSIZE
- */
-static void write_blocked(const void *data, unsigned long size)
-{
- const char *buf = data;
- unsigned long tail;
-
- if (offset) {
- unsigned long chunk = BLOCKSIZE - offset;
- if (size < chunk)
- chunk = size;
- memcpy(block + offset, buf, chunk);
- size -= chunk;
- offset += chunk;
- buf += chunk;
- write_if_needed();
- }
- while (size >= BLOCKSIZE) {
- write_or_die(1, buf, BLOCKSIZE);
- size -= BLOCKSIZE;
- buf += BLOCKSIZE;
- }
- if (size) {
- memcpy(block + offset, buf, size);
- offset += size;
- }
- tail = offset % RECORDSIZE;
- if (tail) {
- memset(block + offset, 0, RECORDSIZE - tail);
- offset += RECORDSIZE - tail;
- }
- write_if_needed();
-}
-
-/*
- * The end of tar archives is marked by 2*512 nul bytes and after that
- * follows the rest of the block (if any).
- */
-static void write_trailer(void)
-{
- int tail = BLOCKSIZE - offset;
- memset(block + offset, 0, tail);
- write_or_die(1, block, BLOCKSIZE);
- if (tail < 2 * RECORDSIZE) {
- memset(block, 0, offset);
- write_or_die(1, block, BLOCKSIZE);
- }
-}
-
-static void strbuf_append_string(struct strbuf *sb, const char *s)
-{
- int slen = strlen(s);
- int total = sb->len + slen;
- if (total > sb->alloc) {
- sb->buf = xrealloc(sb->buf, total);
- sb->alloc = total;
- }
- memcpy(sb->buf + sb->len, s, slen);
- sb->len = total;
-}
-
-/*
- * pax extended header records have the format "%u %s=%s\n". %u contains
- * the size of the whole string (including the %u), the first %s is the
- * keyword, the second one is the value. This function constructs such a
- * string and appends it to a struct strbuf.
- */
-static void strbuf_append_ext_header(struct strbuf *sb, const char *keyword,
- const char *value, unsigned int valuelen)
-{
- char *p;
- int len, total, tmp;
-
- /* "%u %s=%s\n" */
- len = 1 + 1 + strlen(keyword) + 1 + valuelen + 1;
- for (tmp = len; tmp > 9; tmp /= 10)
- len++;
-
- total = sb->len + len;
- if (total > sb->alloc) {
- sb->buf = xrealloc(sb->buf, total);
- sb->alloc = total;
- }
-
- p = sb->buf;
- p += sprintf(p, "%u %s=", len, keyword);
- memcpy(p, value, valuelen);
- p += valuelen;
- *p = '\n';
- sb->len = total;
-}
-
-static unsigned int ustar_header_chksum(const struct ustar_header *header)
-{
- char *p = (char *)header;
- unsigned int chksum = 0;
- while (p < header->chksum)
- chksum += *p++;
- chksum += sizeof(header->chksum) * ' ';
- p += sizeof(header->chksum);
- while (p < (char *)header + sizeof(struct ustar_header))
- chksum += *p++;
- return chksum;
-}
-
-static int get_path_prefix(const struct strbuf *path, int maxlen)
-{
- int i = path->len;
- if (i > maxlen)
- i = maxlen;
- do {
- i--;
- } while (i > 0 && path->buf[i] != '/');
- return i;
-}
-
-static void write_entry(const unsigned char *sha1, struct strbuf *path,
- unsigned int mode, void *buffer, unsigned long size)
-{
- struct ustar_header header;
- struct strbuf ext_header;
-
- memset(&header, 0, sizeof(header));
- ext_header.buf = NULL;
- ext_header.len = ext_header.alloc = 0;
-
- if (!sha1) {
- *header.typeflag = TYPEFLAG_GLOBAL_HEADER;
- mode = 0100666;
- strcpy(header.name, "pax_global_header");
- } else if (!path) {
- *header.typeflag = TYPEFLAG_EXT_HEADER;
- mode = 0100666;
- sprintf(header.name, "%s.paxheader", sha1_to_hex(sha1));
- } else {
- if (verbose)
- fprintf(stderr, "%.*s\n", path->len, path->buf);
- if (S_ISDIR(mode)) {
- *header.typeflag = TYPEFLAG_DIR;
- mode = (mode | 0777) & ~tar_umask;
- } else if (S_ISLNK(mode)) {
- *header.typeflag = TYPEFLAG_LNK;
- mode |= 0777;
- } else if (S_ISREG(mode)) {
- *header.typeflag = TYPEFLAG_REG;
- mode = (mode | ((mode & 0100) ? 0777 : 0666)) & ~tar_umask;
- } else {
- error("unsupported file mode: 0%o (SHA1: %s)",
- mode, sha1_to_hex(sha1));
- return;
- }
- if (path->len > sizeof(header.name)) {
- int plen = get_path_prefix(path, sizeof(header.prefix));
- int rest = path->len - plen - 1;
- if (plen > 0 && rest <= sizeof(header.name)) {
- memcpy(header.prefix, path->buf, plen);
- memcpy(header.name, path->buf + plen + 1, rest);
- } else {
- sprintf(header.name, "%s.data",
- sha1_to_hex(sha1));
- strbuf_append_ext_header(&ext_header, "path",
- path->buf, path->len);
- }
- } else
- memcpy(header.name, path->buf, path->len);
- }
-
- if (S_ISLNK(mode) && buffer) {
- if (size > sizeof(header.linkname)) {
- sprintf(header.linkname, "see %s.paxheader",
- sha1_to_hex(sha1));
- strbuf_append_ext_header(&ext_header, "linkpath",
- buffer, size);
- } else
- memcpy(header.linkname, buffer, size);
- }
-
- sprintf(header.mode, "%07o", mode & 07777);
- sprintf(header.size, "%011lo", S_ISREG(mode) ? size : 0);
- sprintf(header.mtime, "%011lo", archive_time);
-
- /* XXX: should we provide more meaningful info here? */
- sprintf(header.uid, "%07o", 0);
- sprintf(header.gid, "%07o", 0);
- strlcpy(header.uname, "git", sizeof(header.uname));
- strlcpy(header.gname, "git", sizeof(header.gname));
- sprintf(header.devmajor, "%07o", 0);
- sprintf(header.devminor, "%07o", 0);
-
- memcpy(header.magic, "ustar", 6);
- memcpy(header.version, "00", 2);
-
- sprintf(header.chksum, "%07o", ustar_header_chksum(&header));
-
- if (ext_header.len > 0) {
- write_entry(sha1, NULL, 0, ext_header.buf, ext_header.len);
- free(ext_header.buf);
- }
- write_blocked(&header, sizeof(header));
- if (S_ISREG(mode) && buffer && size > 0)
- write_blocked(buffer, size);
-}
-
-static void write_global_extended_header(const unsigned char *sha1)
-{
- struct strbuf ext_header;
- ext_header.buf = NULL;
- ext_header.len = ext_header.alloc = 0;
- strbuf_append_ext_header(&ext_header, "comment", sha1_to_hex(sha1), 40);
- write_entry(NULL, NULL, 0, ext_header.buf, ext_header.len);
- free(ext_header.buf);
-}
-
-static int git_tar_config(const char *var, const char *value)
-{
- if (!strcmp(var, "tar.umask")) {
- if (!strcmp(value, "user")) {
- tar_umask = umask(0);
- umask(tar_umask);
- } else {
- tar_umask = git_config_int(var, value);
- }
- return 0;
- }
- return git_default_config(var, value);
-}
-
static int generate_tar(int argc, const char **argv, const char *prefix)
{
struct archiver_args args;
@@ -286,73 +40,6 @@ static int generate_tar(int argc, const
return result;
}
-static int write_tar_entry(const unsigned char *sha1,
- const char *base, int baselen,
- const char *filename, unsigned mode, int stage)
-{
- static struct strbuf path;
- int filenamelen = strlen(filename);
- void *buffer;
- char type[20];
- unsigned long size;
-
- if (!path.alloc) {
- path.buf = xmalloc(PATH_MAX);
- path.alloc = PATH_MAX;
- path.len = path.eof = 0;
- }
- if (path.alloc < baselen + filenamelen) {
- free(path.buf);
- path.buf = xmalloc(baselen + filenamelen);
- path.alloc = baselen + filenamelen;
- }
- memcpy(path.buf, base, baselen);
- memcpy(path.buf + baselen, filename, filenamelen);
- path.len = baselen + filenamelen;
- if (S_ISDIR(mode)) {
- strbuf_append_string(&path, "/");
- buffer = NULL;
- size = 0;
- } else {
- buffer = read_sha1_file(sha1, type, &size);
- if (!buffer)
- die("cannot read %s", sha1_to_hex(sha1));
- }
-
- write_entry(sha1, &path, mode, buffer, size);
- free(buffer);
-
- return READ_TREE_RECURSIVE;
-}
-
-int write_tar_archive(struct archiver_args *args)
-{
- int plen = args->base ? strlen(args->base) : 0;
-
- git_config(git_tar_config);
-
- archive_time = args->time;
- verbose = args->verbose;
-
- if (args->commit_sha1)
- write_global_extended_header(args->commit_sha1);
-
- if (args->base && plen > 0 && args->base[plen - 1] == '/') {
- char *base = xstrdup(args->base);
- int baselen = strlen(base);
-
- while (baselen > 0 && base[baselen - 1] == '/')
- base[--baselen] = '\0';
- write_tar_entry(args->tree->object.sha1, "", 0, base, 040777, 0);
- free(base);
- }
- read_tree_recursive(args->tree, args->base, plen, 0,
- args->pathspec, write_tar_entry);
- write_trailer();
-
- return 0;
-}
-
static const char *exec = "git-upload-tar";
static int remote_tar(int argc, const char **argv)
^ permalink raw reply related
* [PATCH 1/2] git-tar-tree: Remove duplicate git_config() call
From: Rene Scharfe @ 2006-09-24 15:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Franck Bui-Huu, Git Mailing List
generate_tar() eventually calls write_tar_archive() which does all the
"real" work and which also calls git_config(git_tar_config). We only
need to do this once.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
builtin-tar-tree.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/builtin-tar-tree.c b/builtin-tar-tree.c
index 437eb72..82b4951 100644
--- a/builtin-tar-tree.c
+++ b/builtin-tar-tree.c
@@ -267,8 +267,6 @@ static int generate_tar(int argc, const
int result;
char *base = NULL;
- git_config(git_tar_config);
-
memset(&args, 0, sizeof(args));
if (argc != 2 && argc != 3)
usage(tar_tree_usage);
^ permalink raw reply related
* Re: [PATCH] Kill git-resolve.sh
From: Petr Baudis @ 2006-09-24 13:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64fensge.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sun, Sep 24, 2006 at 12:12:01AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> On a very related note, we should prepare plan to deprecate
> merge-recursive.py.
While we are busy deprecating and removing stuff, we should also:
* probably finally get rid of git-ssh-upload and git-ssh-pull
(mentioned in another thread already)
* make git-annotate alias to git-blame -c? (and probably print
a deprecation warning)
--
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
* Re: [PATCH] proper C syntax (inline has to be placed before the return type).
From: Petr Baudis @ 2006-09-24 12:46 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <11563008693465-git-send-email-madcoder@debian.org>
Dear diary, on Wed, Aug 23, 2006 at 04:41:09AM CEST, I got a letter
where Pierre Habouzit <madcoder@debian.org> said that...
> Signed-off-by: Pierre Habouzit <madcoder@debian.org>
> ---
> strbuf.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/strbuf.c b/strbuf.c
> index 9d9d8be..c8174b4 100644
> --- a/strbuf.c
> +++ b/strbuf.c
> @@ -13,7 +13,7 @@ static void strbuf_begin(struct strbuf *
> strbuf_init(sb);
> }
>
> -static void inline strbuf_add(struct strbuf *sb, int ch) {
> +static inline void strbuf_add(struct strbuf *sb, int ch) {
> if (sb->alloc <= sb->len) {
> sb->alloc = sb->alloc * 3 / 2 + 16;
> sb->buf = xrealloc(sb->buf, sb->alloc);
Bogus, look at C99 A.2.2:
declaration-specifiers:
storage-class-specifier declaration-specifiers
type-specifier declaration-specifiers
type-qualifier declaration-specifiers
function-specifier declaration-specifiers
--
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
* Re: [PATCH] gitweb: Consolidate escaping/validation of query string
From: Jakub Narebski @ 2006-09-24 12:31 UTC (permalink / raw)
To: git
In-Reply-To: <20060924113932.11208.33780.stgit@rover>
Petr Baudis wrote:
> Consider:
>
> http://repo.or.cz/?p=glibc-cvs.git;a=tree;h=2609cb0411389325f4ee2854cc7159756eb0671e;hb=2609cb0411389325f4ee2854cc7159756eb0671e
>
> (click on the funny =__ify file)
>
> We ought to handle anything in filenames and I actually see no reason why
> we don't, modulo very little missing escaping that this patch hopefully
> also fixes.
>
> I have also made esc_param() escape [?=&;]. Not escaping [&;] was downright
> buggy and [?=] just feels better escaped. ;-) YMMV.
>
> Signed-off-by: Petr Baudis <pasky@suse.cz>
This patch contains a few unrelated changes:
* changing semantics of esc_param subroutine
* adding some esc_html where it could be needed
* removing $file_name and $file_parent validation
About change to esc_param: we need current version of esc_param, perhaps
to be named esc_url to be able to say esc_url($home_link) and soon
esc_url($githelp_url).
About adding esc_html where it could be needed: good change, see
my comments below.
About removing $file_name and $file_parent validation: those parameters
have exactly the same textual restrictions as $project parameter - they
are pathnames.
> @@ -2439,7 +2429,7 @@ sub git_blame2 {
> if ($ftype !~ "blob") {
> die_error("400 Bad Request", "Object is not a blob");
> }
> - open ($fd, "-|", git_cmd(), "blame", '-l', $file_name, $hash_base)
> + open ($fd, "-|", git_cmd(), "blame", '-l', '--', $file_name, $hash_base)
> or die_error(undef, "Open git-blame failed");
> git_header_html();
> my $formats_nav =
Slightly unrelated change. Shouldn't it be
open $fd, "-|", git_cmd(), "blame", '-l', $hash_base, "--", $file_name
by the way?
> @@ -3135,7 +3125,7 @@ sub git_blobdiff {
> -type => 'text/plain',
> -charset => 'utf-8',
> -expires => $expires,
> - -content_disposition => qq(inline; filename="${file_name}.patch"));
> + -content_disposition => qq(inline; filename=") . quotemeta($file_name) . qq(.patch"));
>
> print "X-Git-Url: " . $cgi->self_url() . "\n\n";
>
I'd check other places where we output Content-Disposition: header.
At least one place needs similar quotemeta somewhere.
> @@ -3585,7 +3575,7 @@ XML
> if (!($line =~ m/^:([0-7]{6}) ([0-7]{6}) ([0-9a-fA-F]{40}) ([0-9a-fA-F]{40}) (.)([0-9]{0,3})\t(.*)$/)) {
> next;
> }
> - my $file = validate_input(unquote($7));
> + my $file = esc_html(unquote($7));
> $file = decode("utf8", $file, Encode::FB_DEFAULT);
> print "$file<br/>\n";
> }
I'd say perhaps
my $file = unquote($7);
$file = decode("utf8", $file, Encode::FB_DEFAULT);
print esc_html($file) . "<br/>\n";
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] gitweb: Consolidate escaping/validation of query string
From: Jakub Narebski @ 2006-09-24 12:21 UTC (permalink / raw)
To: Petr Baudis, git
In-Reply-To: <20060924113613.GM20017@pasky.or.cz>
Petr "Pasky" Baudis wrote:
>>> I have also made esc_param() escape [?=&;]. Not escaping [&;] was downright
>>> buggy and [?=] just feels better escaped. ;-) YMMV.
> ..snip..
>> I'd rather have new esc_param() or esc_param_value() quote like escape
>> subroutine from CGI::Util, with the esception of _not_ escaping '/'
>> (it makes funny bookmark, and lot less readable query string), and rename
>> current esc_param() to esc_query_string() or esc_params().
>
> Huh, well, what's the point with the rename and why not keep it as it is
> with just removing the four characters above? Escaped stuff looks ugly
> in a URL. ;-)
There are few places where we escape whole URL (so I'd prefer esc_url() for
current implementation): esc_param($home_link) and soon esc_param($githelp_url)
(and _not_ esc_html($githelp_url)). And those URLs can contain query strings,
so we cannot escape '?', ';' and '&', '=' there.
Before introduction of href() subroutine we escaped using esc_param the whole
query string, hence esc_param did not escaped [?=&;].
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Git.pm: Kill Git.xs for now
From: Petr Baudis @ 2006-09-24 12:09 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, git
In-Reply-To: <20060924114834.GA5800@steel.home>
Dear diary, on Sun, Sep 24, 2006 at 01:48:34PM CEST, I got a letter
where Alex Riesen <fork0@t-online.de> said that...
> Aside from that, any chance of making Git.xs optional (enabled by
> default, but disableable)? Disabling Git.xs will disable related
> scripts, sure, but also gives you an installation with one external
> (libperl) dependency less (probably with ability to install git and
> Git.xs separately).
Absolutely.
Actually, as I noted in the patch comment, if we reintroduce Git.xs
again we should probably do it so that it is completely optional and the
equivalent functionality is also implemented in Git.pm in pure perl +
execing Git. I have been originally opposed to that but after all the
woes we had to go through I have changed my opinion.
--
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
* Re: [PATCH] Git.pm: Kill Git.xs for now
From: Alex Riesen @ 2006-09-24 12:07 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20060924114834.GA5800@steel.home>
Alex Riesen, Sun, Sep 24, 2006 13:48:34 +0200:
> Aside from that, any chance of making Git.xs optional (enabled by
> default, but disableable)? Disabling Git.xs will disable related
> scripts, sure, but also gives you an installation with one external
> (libperl) dependency less (probably with ability to install git and
> Git.xs separately).
I see that was already meantioned. Sorry, just have read the whole
discussion.
^ permalink raw reply
* Re: [RFC] git-publish
From: Petr Baudis @ 2006-09-24 12:06 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Daniel Barkalow, git
In-Reply-To: <46a038f90608131653k1a2d0480x411be91bdc3f60ca@mail.gmail.com>
Dear diary, on Mon, Aug 14, 2006 at 01:53:07AM CEST, I got a letter
where Martin Langhoff <martin.langhoff@gmail.com> said that...
> On 8/14/06, Daniel Barkalow <barkalow@iabervon.org> wrote:
> >Like how "pull" is "fetch" + "merge",
>
> Slightly OT... I thought git-publish host:/path/to/repo.git would be
> something to automate the initial "publishing" actions, which for me
> are:
>
> ssh host 'mkdir path/to/repo.git'
> ssh host 'GIT_DIR=path/to/repo.git git init-db'
> ssh host 'GIT_DIR=path/to/repo.git git repo-config someopts'
> git-push git+ssh://host:/path/to/repo.git
>
> Hmmmm. Would this be git publish-repo maybe?
Actually, this is a nice idea for cg-admin-setuprepo, thanks. :-) It now
accepts a git+ssh URL just as well as a local path. (It won't work with
git-shell, but that's a good thing.)
--
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
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