* Problem with cg-merge
From: Marcel Holtmann @ 2005-05-29 15:04 UTC (permalink / raw)
To: Petr Baudis; +Cc: GIT Mailing List
Hi Petr,
I saw that earlier, but I don't have any idea what's wrong here. If I do
a simple cg-update, I see something like this:
Tree change: cf1f29d97210d0594dcf5b2a734bdb714de6bf24:89a14a5bd2c880095d5c618a102319bb3dc03da9
:100755 100755 ceda2c50fc2c2941daa34a57722df251bf892c38 fea239b99d351502d1acb098abd725557f0af202 M cg-diff
:100755 100755 cc0c17beef75db41da3ad4ef8983bd7e222ac739 5f0bff77eb2110d52892793e5bef104acde7be32 M cg-help
Applying changes...
Fast-forwarding cf1f29d97210d0594dcf5b2a734bdb714de6bf24 -> 89a14a5bd2c880095d5c618a102319bb3dc03da9
on top of cf1f29d97210d0594dcf5b2a734bdb714de6bf24...
patching file cg-diff
patching file cg-help
cg-diff: needs update
cg-help: needs update
This is a little bit odd, because if I call "git-diff-cache HEAD" after
it, I will see that cg-diff and cg-help are modified. After calling
cg-cancel everything looks fine again.
Regards
Marcel
^ permalink raw reply
* Re: change of git-diff-tree and symlinks
From: Kay Sievers @ 2005-05-29 15:06 UTC (permalink / raw)
To: Jochen Roemling; +Cc: Git Mailing List
In-Reply-To: <4299CED5.5070508@roemling.net>
On Sun, May 29, 2005 at 04:16:53PM +0200, Jochen Roemling wrote:
> I'm planning to use cogito/git for tracking development of my (PHP
> based) website. Although this is the first time in my life I'm using
> something that smells like a SCM, it seems to work great. The only thing
> lacking is a working gitweb installation.
> I downloaded the gitweb.cgi script from
> kernel.org/pub/software/scm/gitweb, but it dates already May 23rd.
>
> In your mail below from May 25 you state that there have been quite some
> changes to git-diff-tree:
>
> Kay Sievers wrote:
> >
> >The new one shows simply nothing.
> >Shouldn't it print the mode changes like the old one?
> >
> and that might be the reason why I'm getting "nothing" when I'm clicking
> on a "commitdiff" link.
The kernel.org servers use Cogito which needs a new release. So the
version on kernel.org is always a working version with the current
release of Cogito as long as we don't get a git-core to provide the
binaries.
> After investigating further, I found out that the object type ("blob" in
> the example above) is no longer printed by git-diff-tree.
The format has changed, just get the latest version of gitweb from my box
instead.
> Also there is a new parameter '-p' that allows the output of a patch
> directly instead of creating it with the help of temporary files as you
> do it in gitweb.
Sure, gitweb did the diffs before git was able to do that. And it does
not really matter who is creating the temp-files, the cgi or the
git-binaries. :)
If things are stable some day, I may switch that over and maybe even
support the nice rename detection.
> Could you please post a downloadable current release of gitweb to
> kernel.org that works with the current git? If not, please tell me what
> git release is installed at kernel.org so that I can use that branch to
> get it to work with gitweb.
My latest version is here:
ftp://ehlo.org/gitweb.cgi
> And as a last side note it would be helpfull if you could include a
> release number in the gitweb footer as you did in the very beginning so
> that we know if something changed and there is new stuff to explore...
It is in the html-source, right at the top.
Thanks,
Kay
^ permalink raw reply
* Re: change of git-diff-tree and symlinks
From: Jochen Roemling @ 2005-05-29 16:06 UTC (permalink / raw)
To: Kay Sievers; +Cc: Git Mailing List, Sebastian Kuzminsky
In-Reply-To: <20050529150656.GA27127@vrfy.org>
[resending in plain-text]
Kay Sievers wrote:
>The kernel.org servers use Cogito which needs a new release. So the
>version on kernel.org is always a working version with the current
>release of Cogito as long as we don't get a git-core to provide the
>binaries.
>
>
Ah yes, I remember the discussion about that.
Sebastian, could you include a matching gitweb.cgi into your
Debian-Package?
And what about something like:
if (-e '/etc/gitweb.conf') { requite '/etc/gitweb.conf'; }
after the variable settings? The included file would then set
$projectroot and friends to the local values so that I don't have to
patch gitweb everytime I upgrade it. Since perl has no plain "include"
and the require doesn't really work for me (it seems to include the
file, but the variables stay the same), I leave it up to you (I would
have been so proud to provide you a patch, but obviously my perl
knowledge is worse than I thought).
>My latest version is here:
> ftp://ehlo.org/gitweb.cgi
>
>
Thanks for pointing that out. I had the impression, on ehlo.org is only
a installed version, not a downloadable one.
>>And as a last side note it would be helpfull if you could include a
>>release number in the gitweb footer as you did in the very beginning so
>>that we know if something changed and there is new stuff to explore...
>>
>>
>
>It is in the html-source, right at the top.
>
>
Good hiding-place....
Jochen
^ permalink raw reply
* Re: change of git-diff-tree and symlinks
From: Sebastian Kuzminsky @ 2005-05-29 16:14 UTC (permalink / raw)
To: Jochen Roemling; +Cc: Kay Sievers, Git Mailing List
In-Reply-To: <4299E88E.7090306@roemling.net>
Jochen Roemling <jochen@roemling.net> wrote:
> Sebastian, could you include a matching gitweb.cgi into your
> Debian-Package?
I'm planning to package gitweb as a separate Debian package. I'll try
to get to it next week.
--
Sebastian Kuzminsky
^ permalink raw reply
* Re: Problem with cg-merge
From: Sean @ 2005-05-29 16:30 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Petr Baudis, GIT Mailing List
In-Reply-To: <1117379092.7072.90.camel@pegasus>
On Sun, May 29, 2005 11:04 am, Marcel Holtmann said:
> Hi Petr,
>
> I saw that earlier, but I don't have any idea what's wrong here. If I do
> a simple cg-update, I see something like this:
>
> Tree change:
> cf1f29d97210d0594dcf5b2a734bdb714de6bf24:89a14a5bd2c880095d5c618a102319bb3dc03da9
> :100755 100755 ceda2c50fc2c2941daa34a57722df251bf892c38
> fea239b99d351502d1acb098abd725557f0af202 M cg-diff
> :100755 100755 cc0c17beef75db41da3ad4ef8983bd7e222ac739
> 5f0bff77eb2110d52892793e5bef104acde7be32 M cg-help
>
> Applying changes...
> Fast-forwarding cf1f29d97210d0594dcf5b2a734bdb714de6bf24 ->
> 89a14a5bd2c880095d5c618a102319bb3dc03da9
> on top of cf1f29d97210d0594dcf5b2a734bdb714de6bf24...
> patching file cg-diff
> patching file cg-help
> cg-diff: needs update
> cg-help: needs update
>
> This is a little bit odd, because if I call "git-diff-cache HEAD" after
> it, I will see that cg-diff and cg-help are modified. After calling
> cg-cancel everything looks fine again.
Marcel,
Any chance you've installed a copy of git core in addition to your
original install of Cogito? That looks like a problem i saw when using a
newer git installed overtop of Cogito.
Sean
^ permalink raw reply
* [COGITO PATCH] Allow file list for cg-add through stdin
From: Jochen Roemling @ 2005-05-29 17:40 UTC (permalink / raw)
To: Git Mailing List
|Hello,
how is the preferred way to add a whole new directory to a
git-repository using cogito?
Currently cg-add expects all new files on the command line.
The following patch allows to feed files through stdin, which allows to do
find mynewdir -type f | cg-add -
What about a functionality to specify a directory on the command line
and all files are
recursively added?
Signed-off-by: Jochen Roemling <jochen@roemling.net>
--- a/cg-add 2005-05-29 19:27:17.000000000 +0200
+++ b/cg-add 2005-05-29 19:32:42.000000000 +0200
@@ -10,12 +10,24 @@
[ "$1" ] || die "usage: cg-add FILE..."
-for file in "$@"; do
- if [ -f "$file" ] || [ -h "$file" ]; then
- echo "Adding file $file"
- else
- die "$file does not exist"
- fi
-done
+if [ "$1" == '-' ]; then
+ set $@ ""
+ while read file; do
+ if [ -f "$file" ] || [ -h "$file" ]; then
+ echo "Adding file $file"
+ set $@ "$file"
+ else
+ die "$file does not exist"
+ fi
+ done
+else
+ for file in "$@"; do
+ if [ -f "$file" ] || [ -h "$file" ]; then
+ echo "Adding file $file"
+ else
+ die "$file does not exist"
+ fi
+ done
+fi
git-update-cache --add -- "$@"
|
^ permalink raw reply
* Re: [COGITO PATCH] Allow file list for cg-add through stdin
From: Petr Baudis @ 2005-05-29 18:04 UTC (permalink / raw)
To: Jochen Roemling; +Cc: Git Mailing List
In-Reply-To: <4299FE8A.1060207@roemling.net>
Dear diary, on Sun, May 29, 2005 at 07:40:26PM CEST, I got a letter
where Jochen Roemling <jochen@roemling.net> told me that...
> |Hello,
Hello,
> how is the preferred way to add a whole new directory to a
> git-repository using cogito?
> Currently cg-add expects all new files on the command line.
> The following patch allows to feed files through stdin, which allows to do
>
> find mynewdir -type f | cg-add -
if you really want to do that, pass it through xargs...
> What about a functionality to specify a directory on the command line
> and all files are
> recursively added?
...but I think this is definitively the right way to go.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: -p diff output and the 'Index:' line
From: Junio C Hamano @ 2005-05-29 18:04 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050529120248.GD1036@pasky.ji.cz>
>>>>> "PB" == Petr Baudis <pasky@ucw.cz> writes:
>> Like Linus, I do "/^diff --git .*" in my less sessions, which
>> gives a very nice highlighted separator line without wasting a
>> single line on the terminal. If any of the readers on the list
>> didn't know about this trick (especially the trailing .* part),
>> please try it. I'm certain everybody would love it.
PB> When I do just cg-diff to see what I changed I usually do not pipe it to
PB> less, and typing that / stuff seems insane (although /^d.* could give a
PB> good approximation).
You said you do not do "less", so the following may not apply to
your usage, but I disagree your comment about "typing that /
stuff seems insane". Sean's workaround to use "less -p '^diff
--git .*'" in a script, combined with typing 'n' in a "less"
session to find the next such line, would make it very pleasant
to use.
PB> OTOH I think I'll go for the diff output colorification (at
PB> the Cogito level), so the separator indeed isn't strictly
PB> necessary. I can live without it. :-)
When I want to make a customized diff output out of the "diff-*
-p' command, I find it a lot easier to use the GIT_EXTERNAL_DIFF
mechanism than parsing what comes out of "diff-* -p" and munging
it. I am not _telling_, _ordering_, nor even _asking_ you to
use GIT_EXTERNAL_DIFF; just suggesting you to consider that as a
way to possibly make your implementation easier. I'd start from
the supplied git-external-diff-script and go from there.
^ permalink raw reply
* Re: Problem with cg-merge
From: Jonas Fonseca @ 2005-05-29 18:07 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Petr Baudis, GIT Mailing List
In-Reply-To: <1117379092.7072.90.camel@pegasus>
Marcel Holtmann <marcel@holtmann.org> wrote Sun, May 29, 2005:
> Hi Petr,
>
> I saw that earlier, but I don't have any idea what's wrong here. If I do
> a simple cg-update, I see something like this:
>
> Tree change: cf1f29d97210d0594dcf5b2a734bdb714de6bf24:89a14a5bd2c880095d5c618a102319bb3dc03da9
> :100755 100755 ceda2c50fc2c2941daa34a57722df251bf892c38 fea239b99d351502d1acb098abd725557f0af202 M cg-diff
> :100755 100755 cc0c17beef75db41da3ad4ef8983bd7e222ac739 5f0bff77eb2110d52892793e5bef104acde7be32 M cg-help
>
> Applying changes...
> Fast-forwarding cf1f29d97210d0594dcf5b2a734bdb714de6bf24 -> 89a14a5bd2c880095d5c618a102319bb3dc03da9
> on top of cf1f29d97210d0594dcf5b2a734bdb714de6bf24...
> patching file cg-diff
> patching file cg-help
> cg-diff: needs update
> cg-help: needs update
>
> This is a little bit odd, because if I call "git-diff-cache HEAD" after
> it, I will see that cg-diff and cg-help are modified. After calling
> cg-cancel everything looks fine again.
The following change fixes cg-update for me. This is in tree_timewarp().
--- 0ca4ae56fa7bbd8d10e2c2791e389bc19977e460/cg-Xlib (mode:100755)
+++ uncommitted/cg-Xlib (mode:100755)
@@ -66,7 +66,7 @@
# XXX: This may be suboptimal, but it is also non-trivial to keep
# the adds/removes properly. So this is just a quick hack to get it
# working without much fuss.
- cg-diff -r $branch >$patchfile
+ cg-diff >$patchfile
fi
git-read-tree -m "$branch" || die "$branch: bad commit"
--
Jonas Fonseca
^ permalink raw reply
* Re: Problem with cg-merge
From: Marcel Holtmann @ 2005-05-29 18:17 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Petr Baudis, GIT Mailing List
In-Reply-To: <20050529180742.GA31388@diku.dk>
Hi Jonas,
> > I saw that earlier, but I don't have any idea what's wrong here. If I do
> > a simple cg-update, I see something like this:
> >
> > Tree change: cf1f29d97210d0594dcf5b2a734bdb714de6bf24:89a14a5bd2c880095d5c618a102319bb3dc03da9
> > :100755 100755 ceda2c50fc2c2941daa34a57722df251bf892c38 fea239b99d351502d1acb098abd725557f0af202 M cg-diff
> > :100755 100755 cc0c17beef75db41da3ad4ef8983bd7e222ac739 5f0bff77eb2110d52892793e5bef104acde7be32 M cg-help
> >
> > Applying changes...
> > Fast-forwarding cf1f29d97210d0594dcf5b2a734bdb714de6bf24 -> 89a14a5bd2c880095d5c618a102319bb3dc03da9
> > on top of cf1f29d97210d0594dcf5b2a734bdb714de6bf24...
> > patching file cg-diff
> > patching file cg-help
> > cg-diff: needs update
> > cg-help: needs update
> >
> > This is a little bit odd, because if I call "git-diff-cache HEAD" after
> > it, I will see that cg-diff and cg-help are modified. After calling
> > cg-cancel everything looks fine again.
>
> The following change fixes cg-update for me. This is in tree_timewarp().
>
> --- 0ca4ae56fa7bbd8d10e2c2791e389bc19977e460/cg-Xlib (mode:100755)
> +++ uncommitted/cg-Xlib (mode:100755)
> @@ -66,7 +66,7 @@
> # XXX: This may be suboptimal, but it is also non-trivial to keep
> # the adds/removes properly. So this is just a quick hack to get it
> # working without much fuss.
> - cg-diff -r $branch >$patchfile
> + cg-diff >$patchfile
> fi
>
> git-read-tree -m "$branch" || die "$branch: bad commit"
this looks better now. Petr, please apply this patch.
Regards
Marcel
^ permalink raw reply
* Re: Problem with cg-merge
From: Marcel Holtmann @ 2005-05-29 18:17 UTC (permalink / raw)
To: Sean; +Cc: Petr Baudis, GIT Mailing List
In-Reply-To: <3798.10.10.10.24.1117384256.squirrel@linux1>
Hi Sean,
> > I saw that earlier, but I don't have any idea what's wrong here. If I do
> > a simple cg-update, I see something like this:
> >
> > Tree change:
> > cf1f29d97210d0594dcf5b2a734bdb714de6bf24:89a14a5bd2c880095d5c618a102319bb3dc03da9
> > :100755 100755 ceda2c50fc2c2941daa34a57722df251bf892c38
> > fea239b99d351502d1acb098abd725557f0af202 M cg-diff
> > :100755 100755 cc0c17beef75db41da3ad4ef8983bd7e222ac739
> > 5f0bff77eb2110d52892793e5bef104acde7be32 M cg-help
> >
> > Applying changes...
> > Fast-forwarding cf1f29d97210d0594dcf5b2a734bdb714de6bf24 ->
> > 89a14a5bd2c880095d5c618a102319bb3dc03da9
> > on top of cf1f29d97210d0594dcf5b2a734bdb714de6bf24...
> > patching file cg-diff
> > patching file cg-help
> > cg-diff: needs update
> > cg-help: needs update
> >
> > This is a little bit odd, because if I call "git-diff-cache HEAD" after
> > it, I will see that cg-diff and cg-help are modified. After calling
> > cg-cancel everything looks fine again.
>
> Any chance you've installed a copy of git core in addition to your
> original install of Cogito? That looks like a problem i saw when using a
> newer git installed overtop of Cogito.
no, I don't.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] Adjust diff-helper to diff-tree -v -z changes.
From: Linus Torvalds @ 2005-05-29 18:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvf54xael.fsf_-_@assigned-by-dhcp.cox.net>
On Fri, 27 May 2005, Junio C Hamano wrote:
>
> The latest change to diff-tree -z output adds an extra line
> termination after non diff-raw material (the header and the
> commit message). To compensate for this change, stop adding the
> output termination of our own. "diff-tree -v -z" piped to
> "diff-helper -z" would give different result from "diff-tree -v"
> piped to "diff-helper" without this change.
I think this is really a bug in your "read_line()" interface.
You should include the terminating character in the line count.
This also fixes and simplifies "EOF" handling.
Linus
^ permalink raw reply
* Re: [PATCH-RFC] Rewrite ls-tree to behave more like "/bin/ls -a"
From: Junio C Hamano @ 2005-05-29 18:44 UTC (permalink / raw)
To: Jason McMullan; +Cc: git
In-Reply-To: <1117317729.11542.32.camel@jmcmullan.timesys>
>>>>> "JM" == Jason McMullan <jason.mcmullan@timesys.com> writes:
JM> On Sat, 2005-05-28 at 00:05 -0700, Junio C Hamano wrote:
>> - Unlike the old ls-tree behaviour that used paths arguments to
>> restrict output (not that it worked as intended---as pointed
>> out in the mailing list discussion, it was quite incoherent),
>> this rewrite uses paths arguments to specify what to show.
>> ...
JM> This behavior pattern is very agreeable. I'll take it!
Glad to know we are in agreement.
BTW, long after finishing the rewrite, I realized that all of
the problems you raised did not exist in the very original
version of ls-tree, but were bugs in _your_ patch that added the
paths restriction. I was merely cleaning up your mess for you
without knowing what I was doing. ;-) Not that I do not like
what the resulting code does, though.
I am not going to re-submit this to Linus right now, since he
seems to be quiet here and spending more time and attention to
the kernel, which is what I want to see. When Linus starts
pulling in update for GIT, and if you see this one not applied
to his tree, please remind him.
^ permalink raw reply
* Re: [COGITO PATCH] Allow file list for cg-add through stdin
From: Petr Baudis @ 2005-05-29 18:46 UTC (permalink / raw)
To: Jochen Roemling; +Cc: Git Mailing List
In-Reply-To: <429A0818.6080807@roemling.net>
Dear diary, on Sun, May 29, 2005 at 08:21:12PM CEST, I got a letter
where Jochen Roemling <jochen@roemling.net> told me that...
> Petr Baudis wrote:
>
> >>how is the preferred way to add a whole new directory to a
> >>git-repository using cogito?
> >>Currently cg-add expects all new files on the command line.
> >>The following patch allows to feed files through stdin, which allows to do
> >>
> >> find mynewdir -type f | cg-add -
> >>
> >>
> >
> >if you really want to do that, pass it through xargs...
> >
> >
> >
> We have 32° in this room and my xargs must have been melted down.
It's awfully hot here too. :/
> How could I forget about one of my favorite commands?
> I promise I will not post to this list anymore today to avoid a bigger mess.
But a patch for cg-add processing directories recursively would be great
anyway... ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: Problem with cg-merge
From: Petr Baudis @ 2005-05-29 18:48 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Jonas Fonseca, GIT Mailing List
In-Reply-To: <1117390650.7072.100.camel@pegasus>
Dear diary, on Sun, May 29, 2005 at 08:17:30PM CEST, I got a letter
where Marcel Holtmann <marcel@holtmann.org> told me that...
> Hi Jonas,
>
> > > I saw that earlier, but I don't have any idea what's wrong here. If I do
> > > a simple cg-update, I see something like this:
> > >
> > > Tree change: cf1f29d97210d0594dcf5b2a734bdb714de6bf24:89a14a5bd2c880095d5c618a102319bb3dc03da9
> > > :100755 100755 ceda2c50fc2c2941daa34a57722df251bf892c38 fea239b99d351502d1acb098abd725557f0af202 M cg-diff
> > > :100755 100755 cc0c17beef75db41da3ad4ef8983bd7e222ac739 5f0bff77eb2110d52892793e5bef104acde7be32 M cg-help
> > >
> > > Applying changes...
> > > Fast-forwarding cf1f29d97210d0594dcf5b2a734bdb714de6bf24 -> 89a14a5bd2c880095d5c618a102319bb3dc03da9
> > > on top of cf1f29d97210d0594dcf5b2a734bdb714de6bf24...
> > > patching file cg-diff
> > > patching file cg-help
> > > cg-diff: needs update
> > > cg-help: needs update
> > >
> > > This is a little bit odd, because if I call "git-diff-cache HEAD" after
> > > it, I will see that cg-diff and cg-help are modified. After calling
> > > cg-cancel everything looks fine again.
> >
> > The following change fixes cg-update for me. This is in tree_timewarp().
> >
> > --- 0ca4ae56fa7bbd8d10e2c2791e389bc19977e460/cg-Xlib (mode:100755)
> > +++ uncommitted/cg-Xlib (mode:100755)
> > @@ -66,7 +66,7 @@
> > # XXX: This may be suboptimal, but it is also non-trivial to keep
> > # the adds/removes properly. So this is just a quick hack to get it
> > # working without much fuss.
> > - cg-diff -r $branch >$patchfile
> > + cg-diff >$patchfile
> > fi
> >
> > git-read-tree -m "$branch" || die "$branch: bad commit"
>
> this looks better now. Petr, please apply this patch.
Bah. Well if your imaginary friend in your head told you this is
obviously just a no-go workaround, (s)he was right for once. You just
broke cg-admin-uncommit with this one, the real fix is to tell
tree_timewarp to rollback the tree (or rather rollforth here ;-). This
way the right branch of this if will be invoked.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [PATCH] Do not show empty diff in diff-cache uncached.
From: Linus Torvalds @ 2005-05-29 18:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vis13wth4.fsf_-_@assigned-by-dhcp.cox.net>
On Sat, 28 May 2005, Junio C Hamano wrote:
>
> Pre- "diff --git" built-in diff did not add any extended header
> on its own, so it did not show anything for unmodified but
> stat-dirty file from diff-cache command without --cached flag.
>
> Recent diff-cache produces "diff --git" header internally before
> calling the "diff" command, which results in an empty diff for
> such a file, cluttering the output. This patch fixes this.
I'm not sure I like this.
I actually _expect_ that "git-diff-files" will show files that don't match
the index, even if they happen to have the exact content that the index
points to. It's how I know whether the index is up-to-date or not.
The exact same thing is trye of git-diff-cache. If something isn't
up-to-date in the cache, you should show it, since certain operations
depend on the cache being updated.
Linus
^ permalink raw reply
* [GIT PATCH] Fix git-mktag to take the object input spliced arbitrarily
From: Petr Baudis @ 2005-05-29 18:52 UTC (permalink / raw)
To: torvalds; +Cc: git
Before, git-mktag would just try to get all the input through a single
read(), which is obviously broken, since the I/O layer may give you
only part of the input through such a read(). This made it basically
impossible to type the input in manually, for example.
Signed-off-by: Petr Baudis <pasky@ucw.cz>
---
commit f67b8ea0f157813d50371bed494452160c47744d
tree e29e13f259279737dd62ca1b10ede1f8d5e2adb8
parent bf36ee6ccc0dae5725edd7f5d56844a0eae158ad
author Petr Baudis <pasky@ucw.cz> Sun, 29 May 2005 01:39:04 +0200
committer Petr Baudis <xpasky@machine.sinus.cz> Sun, 29 May 2005 01:39:04 +0200
mktag.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
Index: mktag.c
===================================================================
--- 01d01f6cebf110348cfa23c86d521118a00336ba/mktag.c (mode:100644)
+++ e29e13f259279737dd62ca1b10ede1f8d5e2adb8/mktag.c (mode:100644)
@@ -98,7 +98,7 @@
int main(int argc, char **argv)
{
- unsigned long size;
+ unsigned long size, readsize;
char buffer[MAXSIZE];
unsigned char result_sha1[20];
@@ -106,7 +106,11 @@
usage("cat <signaturefile> | git-mktag");
// Read the signature
- size = read(0, buffer, MAXSIZE);
+ size = 0;
+ do {
+ readsize = read(0, buffer + size, MAXSIZE - size);
+ size += readsize;
+ } while (readsize);
// Verify it for some basic sanity: it needs to start with "object <sha1>\ntype "
if (verify_tag(buffer, size) < 0)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [PATCH] Add -O<orderfile> option to diff-* brothers.
From: Linus Torvalds @ 2005-05-29 18:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzmufwu8w.fsf@assigned-by-dhcp.cox.net>
On Sat, 28 May 2005, Junio C Hamano wrote:
>
> A new diffcore filter diffcore-order is introduced. This takes
> a text file each of whose line is a shell glob pattern. Patches
> matching the glob pattern on an earlier line in the file are
> output before patches matching the glob pattern on a later line,
> and patches not matching any glob pattern is output last.
This smells to me like a "cool feature, because we can" rather than a
"this is useful because of xxx".
You could equally well do it with
git-diff-cache .. | sort-filenames | git-diff-helper
in porcelain, if somebody really wants this (but I can't see people
clamoring for it, since nobody else has ever done soemthing like this,
afaik).
In other words: what is the problem this is trying to solve?
Linus
^ permalink raw reply
* Re: change of git-diff-tree and symlinks
From: Junio C Hamano @ 2005-05-29 18:55 UTC (permalink / raw)
To: Kay Sievers; +Cc: Jochen Roemling, Git Mailing List
In-Reply-To: <20050529150656.GA27127@vrfy.org>
>>>>> "KS" == Kay Sievers <kay.sievers@vrfy.org> writes:
>> Also there is a new parameter '-p' that allows the output of a patch
>> directly instead of creating it with the help of temporary files as you
>> do it in gitweb.
KS> Sure, gitweb did the diffs before git was able to do that. And it does
KS> not really matter who is creating the temp-files, the cgi or the
KS> git-binaries. :)
I agree that you are doing the right thing here. In a scripted
environment it usually is more sensible not to use '-p' unless
generating the diff is the _only_ thing you are doing. '-p' is
primarily for people who ends up using the bare plumbing
interactively.
KS> If things are stable some day, I may switch that over and maybe even
KS> support the nice rename detection.
Sorry for being the primary culprit for the disruption ;-).
You do not have to use '-p' to be able to use rename detection
nor any other diffcore stuff. If you are processing
"git-diff-tree -r" output right now, you can already process
"git-diff-tree -r -B -M -S'foo' -Oorder" output just fine and
leave your downstream processing the same as is.
^ permalink raw reply
* Re: -p diff output and the 'Index:' line
From: Petr Baudis @ 2005-05-29 19:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vekbpq56r.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sun, May 29, 2005 at 08:04:44PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> You said you do not do "less", so the following may not apply to
> your usage, but I disagree your comment about "typing that /
> stuff seems insane". Sean's workaround to use "less -p '^diff
> --git .*'" in a script, combined with typing 'n' in a "less"
> session to find the next such line, would make it very pleasant
> to use.
(As long as you don't want to search for something else. ;-)
But yes, I like the less -p hack.
> PB> OTOH I think I'll go for the diff output colorification (at
> PB> the Cogito level), so the separator indeed isn't strictly
> PB> necessary. I can live without it. :-)
>
> When I want to make a customized diff output out of the "diff-*
> -p' command, I find it a lot easier to use the GIT_EXTERNAL_DIFF
> mechanism than parsing what comes out of "diff-* -p" and munging
> it. I am not _telling_, _ordering_, nor even _asking_ you to
> use GIT_EXTERNAL_DIFF; just suggesting you to consider that as a
> way to possibly make your implementation easier. I'd start from
> the supplied git-external-diff-script and go from there.
It's just something along the lines of "Me Og. Og sees /^+/. Og makes
the line green." written in gawk (actually I'm not sure if pure awk
wouldn't do, but I actually don't know the language), so I don't think
the external diff thing would've helped me with that in any way.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: Problem with cg-merge
From: Marcel Holtmann @ 2005-05-29 19:48 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jonas Fonseca, GIT Mailing List
In-Reply-To: <20050529184830.GM1036@pasky.ji.cz>
Hi Petr,
> > > > I saw that earlier, but I don't have any idea what's wrong here. If I do
> > > > a simple cg-update, I see something like this:
> > > >
> > > > Tree change: cf1f29d97210d0594dcf5b2a734bdb714de6bf24:89a14a5bd2c880095d5c618a102319bb3dc03da9
> > > > :100755 100755 ceda2c50fc2c2941daa34a57722df251bf892c38 fea239b99d351502d1acb098abd725557f0af202 M cg-diff
> > > > :100755 100755 cc0c17beef75db41da3ad4ef8983bd7e222ac739 5f0bff77eb2110d52892793e5bef104acde7be32 M cg-help
> > > >
> > > > Applying changes...
> > > > Fast-forwarding cf1f29d97210d0594dcf5b2a734bdb714de6bf24 -> 89a14a5bd2c880095d5c618a102319bb3dc03da9
> > > > on top of cf1f29d97210d0594dcf5b2a734bdb714de6bf24...
> > > > patching file cg-diff
> > > > patching file cg-help
> > > > cg-diff: needs update
> > > > cg-help: needs update
> > > >
> > > > This is a little bit odd, because if I call "git-diff-cache HEAD" after
> > > > it, I will see that cg-diff and cg-help are modified. After calling
> > > > cg-cancel everything looks fine again.
> > >
> > > The following change fixes cg-update for me. This is in tree_timewarp().
> > >
> > > --- 0ca4ae56fa7bbd8d10e2c2791e389bc19977e460/cg-Xlib (mode:100755)
> > > +++ uncommitted/cg-Xlib (mode:100755)
> > > @@ -66,7 +66,7 @@
> > > # XXX: This may be suboptimal, but it is also non-trivial to keep
> > > # the adds/removes properly. So this is just a quick hack to get it
> > > # working without much fuss.
> > > - cg-diff -r $branch >$patchfile
> > > + cg-diff >$patchfile
> > > fi
> > >
> > > git-read-tree -m "$branch" || die "$branch: bad commit"
> >
> > this looks better now. Petr, please apply this patch.
>
> Bah. Well if your imaginary friend in your head told you this is
> obviously just a no-go workaround, (s)he was right for once. You just
> broke cg-admin-uncommit with this one, the real fix is to tell
> tree_timewarp to rollback the tree (or rather rollforth here ;-). This
> way the right branch of this if will be invoked.
I had no idea if the patch was correct or not, but it was working for
me. I also tested your fix for it and it works for me and I am happy
again.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] Do not show empty diff in diff-cache uncached.
From: Junio C Hamano @ 2005-05-29 20:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0505291151250.10545@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> I'm not sure I like this.
LT> I actually _expect_ that "git-diff-files" will show files that don't match
LT> the index, even if they happen to have the exact content that the index
LT> points to. It's how I know whether the index is up-to-date or not.
LT> The exact same thing is trye of git-diff-cache. If something isn't
LT> up-to-date in the cache, you should show it, since certain operations
LT> depend on the cache being updated.
Let me make sure that we are on the same page. I am only
talking about '-p' (diff-patch) case in this patch. The code
should continue to show the 0{40} SHA1 on the right hand side in
diff-raw output. Do you still want to see the header in that
case to match the diff-raw exactly?
^ permalink raw reply
* Re: [PATCH] Adjust diff-helper to diff-tree -v -z changes.
From: Junio C Hamano @ 2005-05-29 20:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0505291129520.10545@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> I think this is really a bug in your "read_line()" interface.
LT> You should include the terminating character in the line count.
What the patch changed:
You give me a non diff-raw material "foo\nbar\n" when you
are not doing -z. I read that without -z. read_line()
drops the EOL so I get "foo" and "bar" on separate lines,
both of which I spit out with my own '\n' using "%s\n".
You give me "foo\nbar\n\0" to express the same under -z, and
I read that with -z. I get "foo\nbar\n" after read_line()
drops the EOL. I should spit it out without my own '\n',
i.e. not using "%s\n" but "%s".
If read_line() interface changes to include EOL, then...
You give me "foo\nbar\n" without -z. I read that without
-z. Fixed read_line() retains the EOL and I get "foo\n" and
"bar\n", and I do not have to add my own '\n' anymore; I
just do fputs().
You give me "foo\nbar\n\0" under -z, and I read that with
-z. Fixed read_line() retains the EOL so I get
"foo\nbar\n\0". I just do fputs() and it would drop the
'\0'.
What the last sentence does feels a bit hacky, but does the
right thing. It's a good fix.
Please discard the patch you are responding to unless you
already have applied it.
^ permalink raw reply
* Re: [COGITO PATCH] Allow file list for cg-add through stdin
From: Jochen Roemling @ 2005-05-29 20:22 UTC (permalink / raw)
To: Petr Baudis; +Cc: Git Mailing List
In-Reply-To: <20050529184642.GL1036@pasky.ji.cz>
Petr Baudis wrote:
>But a patch for cg-add processing directories recursively would be great
>anyway... ;-)
>
>
>
Okay, okay, what about this one:
[Cogito PATCH] Add directories recursively with cg-add
Signed-off-by: Jochen Roemling <jochen@roemling.net>
--- a/cg-add
+++ b/cg-add
@@ -10,12 +10,11 @@
[ "$1" ] || die "usage: cg-add FILE..."
-for file in "$@"; do
- if [ -f "$file" ] || [ -h "$file" ]; then
- echo "Adding file $file"
- else
- die "$file does not exist"
- fi
-done
+TMPFILE="${TMP:-/tmp}/$(basename $0).$$.tmp"
-git-update-cache --add -- "$@"
+find $@ -type f > $TMPFILE || die "not all files do exist, nothing added"
+
+cat $TMPFILE | awk '{print "Adding file " $0}'
+cat $TMPFILE | xargs git-update-cache --add --
+
+rm -f $TMPFILE
^ permalink raw reply
* Re: [PATCH] Add -O<orderfile> option to diff-* brothers.
From: Junio C Hamano @ 2005-05-29 20:32 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0505291154030.10545@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> This smells to me like a "cool feature, because we can"
LT> rather than a "this is useful because of xxx".
You could even do the rename/copy detection outside with a
standalone diff-raw filter, just like your "sort-filenames" pipe
example. Rename/copy is not done that way primarily for the
performance reasons. Pickaxe is not done that way because we
wanted to conditionally suppress diff-tree headers, and it is
easier to implement the suppression inside rather than as a
"sort-filename" like filter.
This diffcore-order is more like "cool feature, because we can,
_and_ it is simpler to do it inside rather than outside, now we
already have the infrastructure inside to do this kind of thing
for other purposes anyway".
^ 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