* Re: [PATCH] cogito: Add cg-undo command
From: Petr Baudis @ 2005-05-08 20:59 UTC (permalink / raw)
To: Matt Porter; +Cc: git
In-Reply-To: <20050503224007.B637@cox.net>
Dear diary, on Wed, May 04, 2005 at 07:40:07AM CEST, I got a letter
where Matt Porter <mporter@kernel.crashing.org> told me that...
> Signed-off-by: Matt Porter <mporter@kernel.crashing.org>
Thanks. I took it, hacked upon it for a while and then committed
something similar but largely rewritten as cg-admin-uncommit. ;-)
--
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 0/2] core-git documentation update
From: David Greaves @ 2005-05-08 21:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vhdhd5wzm.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>Quick question. Is this against the tip of Linus tree?
>
>
>
>
yes
--
^ permalink raw reply
* Re: Broken adding of cache entries
From: Junio C Hamano @ 2005-05-08 21:06 UTC (permalink / raw)
To: Petr Baudis; +Cc: Kay Sievers, git
In-Reply-To: <20050508165915.GW9495@pasky.ji.cz>
>>>>> "PB" == Petr Baudis <pasky@ucw.cz> writes:
PB> Dear diary, on Sun, May 08, 2005 at 07:22:31AM CEST, I got a letter
PB> where Junio C Hamano <junkio@cox.net> told me that...
>> Ok, I have two updates pushed out at git-jc archive at
>> http://members.cox.net/junkio/git-jc.git/
PB> I wanted to merge with you, but I'd like to make some (mostly minor)
PB> nitpicks first.
I've addressed the points you raised and pushed them out.
Thanks again for the review.
^ permalink raw reply
* Re: Commit template
From: Marcel Holtmann @ 2005-05-08 21:09 UTC (permalink / raw)
To: Petr Baudis; +Cc: Sean, GIT Mailing List
In-Reply-To: <20050508204043.GJ9495@pasky.ji.cz>
Hi Petr,
> > > > > my argument is; not to mess up with the CG: lines created by cg-commit.
> > > > > If you wanna insert a warning then you can of course add additional CG:
> > > > > lines to the commit template.
> > > >
> > > > Well, i'd argue that anyone making their own commit should be responsible
> > > > for making it look however they like. Maybe they want to only use only 60
> > > > character wide lines and are tired of seeing the notice about CG: being
> > > > ignored. Gives the power user a tad more flexibility. But I really
> > > > don't care much either way.
> > >
> > > I'm with Sean on this one - implemented (with current cg-commit, and I
> > > used .git/commit-template file instead), committed, pushed out.
> >
> > then please do a "touch .git/commit-template" and call cg-commit. Now
> > you will see what I mean. It is too easy to screw up.
>
> So don't touch .git/commit-template. It's not like it stops working, you
> just don't get the top stuff. Which you probably wanted, why would you
> touch .git/commit-template otherwise?
maybe I am the only one who sees a problem here and thinks that it is a
mis-design. Let me try one last time to explain it. We speak here about
end users of Cogito, right? They don't know what is inside the scripts
and how they work. So you tell them that they can create a commit
template that will be presented at every commit time. So lets do it.
---snip---
[PATCH]
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---snip---
I would create a file like this and save it as .git/commit-template,
because I don't really know about the CG: lines and actually I don't
really care, because they get deleted anyway. Stupid as I am, I am
expecting now something like this:
---snip---
[PATCH]
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
CG: -----------------------------------------------------------------------
CG: Lines beginning with the CG: prefix are removed automatically
CG:
CG: Modified files:
CG: Makefile
CG: -----------------------------------------------------------------------
---snip---
But instead I am getting this:
---snip---
[PATCH]
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
CG:
CG: Modified files:
CG: Makefile
CG: -----------------------------------------------------------------------
---snip---
As an end user, what would you say?
> > Why not leave the list of modified files in the hand of the cg-commit
> > and people that wanna extra text inside their commit-template add
> > something like:
> >
> > CG: ---
> > CG: This is my testing tree, don't commit
> >
> > This will look much prettier and gives people the same possibilities to
> > change everything.
>
> But you have extra stuff both before and after the list of modified
> files.
Adding extra CG: lines in a commit template is only good for reminding
you of something, right? Why else would you add them?
> > If you wanna make the modified files list into a full configurable
> > template, then I think you must introduce place holders.
>
> That's what I was thinking about, actually - @@MODIFIED@@ and such, and
> it replaces _all_ the CG: stuff. Just decided that I have better things
> to do now personally.
I understand that :)
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] Really *do* nothing in while loop
From: Junio C Hamano @ 2005-05-08 21:08 UTC (permalink / raw)
To: Michael Tokarev; +Cc: jdow, James Purser, Thomas Glanzmann, LKML, GIT
In-Reply-To: <427DFAB8.5050000@tls.msk.ru>
>>>>> "MT" == Michael Tokarev <mjt@tls.msk.ru> writes:
MT> As I already said, deflate() in this case does only ONE iteration.
MT> stream.avail_in is NOT changed in the loop (except of the deflate()
MT> itself, where it will be set to 0 - provided out buffer have enouth
MT> room)....
Just a stupid question, but what happens when we do not have
enough room in the buffer?
^ permalink raw reply
* Re: [PATCH Cogito] Make use of external editor work like CVS
From: Petr Baudis @ 2005-05-08 21:08 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: GIT Mailing List
In-Reply-To: <1115584015.8949.43.camel@pegasus>
Dear diary, on Sun, May 08, 2005 at 10:26:55PM CEST, I got a letter
where Marcel Holtmann <marcel@holtmann.org> told me that...
> Hi Petr,
Hi,
> > > look at the attached patch. We should use "fmt -s" to keep newlines that
> > > are inside the commit message and there is one unneeded empty CG: line.
> >
> > thanks, fixed and pushed out.
>
> cool. Now I have everything I am used to from CVS, but ...
Excellent.
> @@ -113,7 +113,9 @@
> # TODO: Prepend a letter describing whether it's addition,
> # removal or update. Or call git status on those files.
> echo "CG: $file" >>$LOGMSG
> - [ "$msgs" ] && echo $file
> + if [ "$msgs" ] && ! [ "$forceeditor" ]; then
> + echo $file
> + fi
> done
> fi
>
> There is no need to print out the files if we start the editor anyway.
Thanks, fixed.
> @@ -122,10 +124,10 @@
> if tty -s; then
> if ! [ "$msgs" ] || [ "$forceeditor" ]; then
> ${EDITOR:-vi} $LOGMSG2
> - fi
> - if ! [ "$msgs" ] && ! [ $LOGMSG2 -nt $LOGMSG ]; then
> - rm $LOGMSG $LOGMSG2
> - die 'Commit message not modified, commit aborted'
> + if ! [ $LOGMSG2 -nt $LOGMSG ]; then
> + rm $LOGMSG $LOGMSG2
> + die 'Commit message not modified, commit aborted'
> + fi
> fi
> else
>
> If you provide a commit message via -m and then close the editor without
> changing it, it will commit the message. I think that will not be the
> intention of the user.
Now, this is a pretty difficult question. The only other place in the
Cogito toolkit which uses cg-commit -e is now cg-init when doing the
initial commit - and you definitively want to commit even if the message
was not modified in that case. Also, what if you want to just review
how the -m stuff flows like before committing?
OTOH, we might want to stay consistent in behaviour and always abandon
action when the file was not modified (except for the initial commit).
Perhaps some -E for that? Other thoughts?
> /*
> * Remove empty lines from the beginning and end.
> *
> * Turn multiple consecutive empty lines into just one
> * empty line.
> */
Bah, that's even easier when you want to squeeze the empty lines inside
of the commit message. I don't, though.
--
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] Really *do* nothing in while loop
From: Daniel Barkalow @ 2005-05-08 21:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael Tokarev, jdow, James Purser, Thomas Glanzmann, GIT
In-Reply-To: <7vy8ap4e8l.fsf@assigned-by-dhcp.cox.net>
On Sun, 8 May 2005, Junio C Hamano wrote:
> >>>>> "MT" == Michael Tokarev <mjt@tls.msk.ru> writes:
>
> MT> As I already said, deflate() in this case does only ONE iteration.
> MT> stream.avail_in is NOT changed in the loop (except of the deflate()
> MT> itself, where it will be set to 0 - provided out buffer have enouth
> MT> room)....
>
> Just a stupid question, but what happens when we do not have
> enough room in the buffer?
We must have enough room; we sized the buffer with deflateBound to fit the
worst case.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH Cogito] Make use of external editor work like CVS
From: Marcel Holtmann @ 2005-05-08 21:19 UTC (permalink / raw)
To: Petr Baudis; +Cc: GIT Mailing List
In-Reply-To: <20050508210857.GL9495@pasky.ji.cz>
Hi Petr,
> > @@ -122,10 +124,10 @@
> > if tty -s; then
> > if ! [ "$msgs" ] || [ "$forceeditor" ]; then
> > ${EDITOR:-vi} $LOGMSG2
> > - fi
> > - if ! [ "$msgs" ] && ! [ $LOGMSG2 -nt $LOGMSG ]; then
> > - rm $LOGMSG $LOGMSG2
> > - die 'Commit message not modified, commit aborted'
> > + if ! [ $LOGMSG2 -nt $LOGMSG ]; then
> > + rm $LOGMSG $LOGMSG2
> > + die 'Commit message not modified, commit aborted'
> > + fi
> > fi
> > else
> >
> > If you provide a commit message via -m and then close the editor without
> > changing it, it will commit the message. I think that will not be the
> > intention of the user.
>
> Now, this is a pretty difficult question. The only other place in the
> Cogito toolkit which uses cg-commit -e is now cg-init when doing the
> initial commit - and you definitively want to commit even if the message
> was not modified in that case. Also, what if you want to just review
> how the -m stuff flows like before committing?
>
> OTOH, we might want to stay consistent in behaviour and always abandon
> action when the file was not modified (except for the initial commit).
> Perhaps some -E for that? Other thoughts?
I think using -E to commit even when you don't modify the commit message
is a good idea. The alternative way is to ask the user like CVS does.
> > /*
> > * Remove empty lines from the beginning and end.
> > *
> > * Turn multiple consecutive empty lines into just one
> > * empty line.
> > */
>
> Bah, that's even easier when you want to squeeze the empty lines inside
> of the commit message. I don't, though.
You can do that with "cat -s", I know. But then you still have to look
at the first and the last line and delete it if they are empty.
I think it is a good idea to squeeze empty lines, because multi empty
lines are not useful for commit messages anyway. What do you think?
Regards
Marcel
^ permalink raw reply
* Re: Broken adding of cache entries
From: Petr Baudis @ 2005-05-08 21:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Kay Sievers, git
In-Reply-To: <7v3bsx5sxx.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sun, May 08, 2005 at 11:06:02PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> >>>>> "PB" == Petr Baudis <pasky@ucw.cz> writes:
>
> PB> Dear diary, on Sun, May 08, 2005 at 07:22:31AM CEST, I got a letter
> PB> where Junio C Hamano <junkio@cox.net> told me that...
>
> >> Ok, I have two updates pushed out at git-jc archive at
> >> http://members.cox.net/junkio/git-jc.git/
>
> PB> I wanted to merge with you, but I'd like to make some (mostly minor)
> PB> nitpicks first.
>
> I've addressed the points you raised and pushed them out.
> Thanks again for the review.
Great, thanks.
Still, I'd like to know why the checking in write-tree is necessary.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* [BUG] in asciidoc was Re: [FILES] core-git documentation update
From: David Greaves @ 2005-05-08 21:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7vpsw15xdf.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>>>>>>"DG" == David Greaves <david@dgreaves.com> writes:
>>>>>>
>>>>>>
>
>DG> it just makes across the board changes easier and at the minute the
>DG> stuff I've been doing is systemic.
>DG> I have no problems with breaking it up - hence the script...
>
>Monolithic version is easier to work with when there is only one
>or very few people working on it but when the document matures
>enough to describe the current state of affairs accurately
>enough, further changes would come almost solely from changing
>the programs the document describes. At that point having
>separate files describing each program is easier to work with,
>and I think that point is now.
>
>
I was waiting for comments on this set in case there were comments like:
every document should have 'x' or change all 'y' to 'z'
I fully intend to split it out...
I will send patches next time.
One thing I failed to mention.
There's a minor bug in asciidoc for which I've submitted a patch to the
author. IIRC the bug causes problems with the -man option and is
cosmetically wrong with the html.
>From the asciidoc docs:
The first manpage section is mandatory and must be called /NAME/ and
contain a single paragraph (usually a single line) consisting of a list
of one or more comma separated command name(s) separated from the
command purpose by a dash character. **The dash must have at least one
white space character on either side.**
However this is not enforced (or indeed possible) at the moment - the
NAME section seems to split on the first hyphen.
This patch fixes that for me.
--- /usr/bin/asciidoc.orig 2005-05-08 17:03:42.666249974 +0100
+++ /usr/bin/asciidoc 2005-05-08 16:56:00.518923960 +0100
@@ -1067,7 +1067,7 @@
error('malformed NAME section body')
lines = reader.read_until(r'^$')
s = string.join(lines)
- mo = re.match(r'^(?P<manname>.*?)-(?P<manpurpose>.*)$',s)
+ mo =
re.match(r'^(?P<manname>.*?)\s+-\s+(?P<manpurpose>.*)$',s)
if not mo:
error('malformed NAME section body')
attrs['manname'] = string.strip(mo.group('manname'))
^ permalink raw reply
* Re: [PATCH 0/2] core-git documentation update
From: David Greaves @ 2005-05-08 21:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5s15up8.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1226 bytes --]
Junio C Hamano wrote:
>David, thanks for taking time to update the document. I ended
>up hand merging your two patches since I had a bit more
>documentation updates in git-jc tree, so I'd like you to
>proofread the result.
>
>
This merged fine.
Purely for editorial consistency I added "" around the command - see patch
The intention now was for me to go through Linus' HEAD and verify the
docs actually documented the HEAD.
Then I think comparing the HEAD to jit-jc and preparing patches for that?
>It is my understanding that if I have a correct patch result
>from your patch 1 and patch 2, I can throw away this message:
>
> Subject: [FILES] core-git documentation update
>
>Am I correct?
>
>
yes - that was just to assist people in reading the docs without having
to apply patches etc etc.
>I intend to keep not-so-controvercial stuff in git-jc tree, so
>that when Linus returns he can pull from it instead of patching
>from a pile of e-mails, potentially risking to leave good stuff
>in his mailbox during that process.
>
>
I had hoped you'd pick this up in that manner - thanks
David
PS Removed Linus from cc
Add quotes for editorial consistency
Signed-off-by: David Greaves <david@dgreaves.com>
---
[-- Attachment #2: core-git_editorial.patch --]
[-- Type: text/x-patch, Size: 614 bytes --]
Documentation/core-git.txt: needs update
Index: Documentation/core-git.txt
===================================================================
--- 08cd7ce14ca4da7db37dce88e416e67b01f3452a/Documentation/core-git.txt (mode:100644 sha1:e046119fcdd948dec81b11376ec9198e76a109af)
+++ uncommitted/Documentation/core-git.txt (mode:100644)
@@ -503,7 +503,7 @@
-m::
By default, files recorded in the index but not checked
out are reported as deleted. This flag makes
- git-diff-cache say that all non-checked-out files are up
+ "git-diff-cache" say that all non-checked-out files are up
to date.
Output format
^ permalink raw reply
* Re: [PATCH] Really *do* nothing in while loop
From: Junio C Hamano @ 2005-05-08 21:35 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Michael Tokarev, jdow, James Purser, Thomas Glanzmann, GIT
In-Reply-To: <Pine.LNX.4.21.0505081713070.30848-100000@iabervon.org>
>>>>> "DB" == Daniel Barkalow <barkalow@iabervon.org> writes:
DB> On Sun, 8 May 2005, Junio C Hamano wrote:
>>
MT> As I already said, deflate() in this case does only ONE iteration.
MT> stream.avail_in is NOT changed in the loop (except of the deflate()
MT> itself, where it will be set to 0 - provided out buffer have enouth
MT> room)....
>>
>> Just a stupid question, but what happens when we do not have
>> enough room in the buffer?
DB> We must have enough room; we sized the buffer with deflateBound to fit the
DB> worst case.
Thanks for the explanation. Then do we still need to express it
as a while loop?
^ permalink raw reply
* Re: [PATCH Cogito] Make use of external editor work like CVS
From: Marcel Holtmann @ 2005-05-08 21:43 UTC (permalink / raw)
To: Petr Baudis; +Cc: GIT Mailing List
In-Reply-To: <20050508200334.GG9495@pasky.ji.cz>
Hi Petr,
> #/bin/sh
>
> leading=1
> emptylines=0
> while read line; do
> if ! [ "$line" ]; then
> [ "$leading" ] && continue
> emptylines=$(($emptylines + 1))
> else
> leading=0
> while [ $emptylines -gt 0 ]; do
> echo ""
> emptylines=$(($emptylines - 1))
> done
> echo $line
> fi
> done
>
> or something? (Based on someone else's script since I was too lazy. ;-)
@@ -134,7 +134,7 @@
else
cat >>$LOGMSG2
fi
-grep -v ^CG: $LOGMSG2 >$LOGMSG
+grep -v ^CG: $LOGMSG2 | sed '/./,${/./b;:a;$d;N;/\n$/ba;b;};d' >$LOGMSG
rm $LOGMSG2
If you don't wanna squeeze then you can do it with a one-line in sed.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH Cogito] Make use of external editor work like CVS
From: Sean @ 2005-05-08 21:46 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Petr Baudis, GIT Mailing List
In-Reply-To: <1115584015.8949.43.camel@pegasus>
On Sun, May 8, 2005 4:26 pm, Marcel Holtmann said:
> /*
> * Remove empty lines from the beginning and end.
> *
> * Turn multiple consecutive empty lines into just one
> * empty line.
> */
sed ' 1{:a;s/^[ \t]*$//;T;N;s/\n//;ta}
/^[ \t]*$/{:b;$d;N;s/\n[ \t]*$//;tb}' filename
There's probably shorter... but it's mothers day.. time to go!
Cheers,
Sean
^ permalink raw reply
* Re: Broken adding of cache entries
From: Junio C Hamano @ 2005-05-08 22:18 UTC (permalink / raw)
To: Petr Baudis; +Cc: Kay Sievers, git
In-Reply-To: <20050508212202.GM9495@pasky.ji.cz>
>>>>> "PB" == Petr Baudis <pasky@ucw.cz> writes:
PB> Still, I'd like to know why the checking in write-tree is necessary.
The following is just a rephrase of what I wrote in my previous
message <7vll6q70mg.fsf@assigned-by-dhcp.cox.net>.
------------ test.sh ------------
#!/bin/sh
test="++testdir"
rm -fr $test
mkdir $test
cd $test || exit
show () {
echo "# ls ($1)"
ls -F
echo "# git-ls-files --stage ($1)"
git-ls-files --stage
case "$2" in
'') ;;
?*)
echo "# git-ls-tree -r ($1)"
git-ls-tree -r $2
;;
esac
}
echo "# Original"
git-init-db
date >not-so-interesting
git-update-cache --add not-so-interesting
original=$(echo Original | git-commit-tree $(git-write-tree))
show Original $original
rm -rf path not-so-interesting
echo "# Branch A"
git-read-tree $original
git-checkout-cache -f -a
date >path
git-update-cache --add path
branchA=$(echo Branch A Changes |
git-commit-tree $(git-write-tree) -p $original)
show 'Branch A' $branchA
rm -rf path not-so-interesting
echo "# Branch B"
git-read-tree $original
git-checkout-cache -f -a
mkdir path
date >path/file
git-update-cache --add path/file
branchB=$(echo Branch B Changes |
git-commit-tree $(git-write-tree) -p $original)
show 'Branch B' $branchB
rm -rf path not-so-interesting
echo "# Attempt merge O A B"
mb=$(git-merge-base $branchA $branchB)
echo "Original $original"
echo "Branch-A $branchA"
echo "Branch-B $branchB"
echo "MergeBase $mb"
git-read-tree -m $mb $branchA $branchB
show "Merge"
------------ test.out ------------
# Original
defaulting to local storage area
Committing initial tree 682c2247823f37e4cf64f240009c9ba932b04fe0
# ls (Original)
not-so-interesting
# git-ls-files --stage (Original)
100644 9bcc8fabbbb587ba312a45b144dce8f4d9191da5 0 not-so-interesting
# git-ls-tree -r (Original)
100644 blob 9bcc8fabbbb587ba312a45b144dce8f4d9191da5 not-so-interesting
# Branch A
# ls (Branch A)
not-so-interesting
path
# git-ls-files --stage (Branch A)
100644 9bcc8fabbbb587ba312a45b144dce8f4d9191da5 0 not-so-interesting
100644 9bcc8fabbbb587ba312a45b144dce8f4d9191da5 0 path
# git-ls-tree -r (Branch A)
100644 blob 9bcc8fabbbb587ba312a45b144dce8f4d9191da5 not-so-interesting
100644 blob 9bcc8fabbbb587ba312a45b144dce8f4d9191da5 path
# Branch B
# ls (Branch B)
not-so-interesting
path/
# git-ls-files --stage (Branch B)
100644 9bcc8fabbbb587ba312a45b144dce8f4d9191da5 0 not-so-interesting
100644 9bcc8fabbbb587ba312a45b144dce8f4d9191da5 0 path/file
# git-ls-tree -r (Branch B)
100644 blob 9bcc8fabbbb587ba312a45b144dce8f4d9191da5 not-so-interesting
040000 tree f4e939c9b65aff9a59118f3f3f299ef30744adfa path
100644 blob 9bcc8fabbbb587ba312a45b144dce8f4d9191da5 path/file
# Attempt merge O A B
Original 40c1d8a0e79df9e681667e0074664266b6bd9935
Branch-A 88b3e7e4ce0ba55c60fe4de6523968ecabb1cc78
Branch-B 0faa7f6b7f68ce2951fe3f26f937766ee53dc11c
MergeBase 40c1d8a0e79df9e681667e0074664266b6bd9935
# ls (Merge)
# git-ls-files --stage (Merge)
100644 9bcc8fabbbb587ba312a45b144dce8f4d9191da5 0 not-so-interesting
100644 9bcc8fabbbb587ba312a45b144dce8f4d9191da5 2 path
100644 9bcc8fabbbb587ba312a45b144dce8f4d9191da5 3 path/file
^ permalink raw reply
* Re: Broken adding of cache entries
From: Junio C Hamano @ 2005-05-08 22:22 UTC (permalink / raw)
To: Petr Baudis; +Cc: Kay Sievers, git
In-Reply-To: <7v7ji94b1d.fsf@assigned-by-dhcp.cox.net>
>>>>> "JCH" == Junio C Hamano <junkio@cox.net> writes:
>>>>> "PB" == Petr Baudis <pasky@ucw.cz> writes:
PB> Still, I'd like to know why the checking in write-tree is necessary.
Ok, having thought about it a bit more, I think we can yank it
out. I'd rather keep ourselves cautious, though; there may be
some other ways we haven't thought of to create such nonsense,
and it would not hurt to be cautious before writing a tree out.
^ permalink raw reply
* Re: Broken adding of cache entries
From: Junio C Hamano @ 2005-05-08 22:42 UTC (permalink / raw)
To: Petr Baudis; +Cc: Kay Sievers, git
In-Reply-To: <7v3bsx4aum.fsf@assigned-by-dhcp.cox.net>
>>>>> "JCH" == Junio C Hamano <junkio@cox.net> writes:
JCH> Ok, having thought about it a bit more, I think we can yank it
JCH> out. I'd rather keep ourselves cautious, though; there may be
JCH> some other ways we haven't thought of to create such nonsense,
JCH> and it would not hurt to be cautious before writing a tree out.
Here is a revert you can apply after merging with the tip of my
tree if you wanted to. As you pointed out correctly, three-way
read-tree would not produce the situation as I feared, and the
attempt to postprocess the result by git-merge-one-file-script
git-merge-cache calls would be caught with the changes we made
to git-update-cache, so there is no need for the extra check by
write-tree in that workflow example. Sorry for being ultra
dense.
The only reason why I am holding off from pushing this out is
because I still cannot convince myself that we eradicated _all_
the possibile paths to create such nonsense in the index, and I
feel safer to keep the check this patch is reverting, at least
for now.
---
Author: Junio C Hamano <junkio@cox.net>
Date: Sun May 8 15:34:17 2005 -0700
Revert the extra-careful check in write-tree.c
I am not particularly fond of reverting this, but with the
git-update-cache changes it is unlikely that we will have file
vs directory conflicts in the index anymore, so there may be no
point in being extra careful when writing the tree out.
Signed-off-by: Junio C Hamano <junkio@cox.net>
--- a/write-tree.c
+++ b/write-tree.c
@@ -84,7 +84,7 @@ static int write_tree(struct cache_entry
int main(int argc, char **argv)
{
- int i, funny;
+ int i, unmerged;
int entries = read_cache();
unsigned char sha1[20];
@@ -92,45 +92,18 @@ int main(int argc, char **argv)
die("write-tree: no cache contents to write");
/* Verify that the tree is merged */
- funny = 0;
+ unmerged = 0;
for (i = 0; i < entries; i++) {
struct cache_entry *ce = active_cache[i];
if (ntohs(ce->ce_flags) & ~CE_NAMEMASK) {
- if (10 < ++funny) {
+ if (++unmerged > 10) {
fprintf(stderr, "...\n");
break;
}
fprintf(stderr, "%s: unmerged (%s)\n", ce->name, sha1_to_hex(ce->sha1));
}
}
- if (funny)
- die("write-tree: not able to write tree");
-
- /* Also verify that the cache does not have path and path/file
- * at the same time. At this point we know the cache has only
- * stage 0 entries.
- */
- funny = 0;
- for (i = 0; i < entries - 1; i++) {
- /* path/file always comes after path because of the way
- * the cache is sorted. Also path can appear only once,
- * which means conflicting one would immediately follow.
- */
- const char *this_name = active_cache[i]->name;
- const char *next_name = active_cache[i+1]->name;
- int this_len = strlen(this_name);
- if (this_len < strlen(next_name) &&
- strncmp(this_name, next_name, this_len) == 0 &&
- next_name[this_len] == '/') {
- if (10 < ++funny) {
- fprintf(stderr, "...\n");
- break;
- }
- fprintf(stderr, "You have both %s and %s\n",
- this_name, next_name);
- }
- }
- if (funny)
+ if (unmerged)
die("write-tree: not able to write tree");
/* Ok, write it out */
^ permalink raw reply
* Pointers to CVS 2 GIT imports and gateways
From: Martin Langhoff @ 2005-05-08 23:16 UTC (permalink / raw)
To: git
I am looking into importing a cvs repo HEAD history into git using
cvsps. I read throught the thread where Ingo discussed his import of
the kernel sources, but I couldn't find any pointers to what kind of
shell magic or other associated scripts were used, and google hasn't
helped much either.
How do I feed the patchsets into GIT preserving commit msgs and other metadata?
A related question follows: is anyone running git -> cvs gateways, and how?
pointers to TFM will be much appreciated ;)
cheers,
martin
^ permalink raw reply
* Re: [PATCH] Add exclude file support to cg-status
From: Junio C Hamano @ 2005-05-08 23:28 UTC (permalink / raw)
To: Petr Baudis; +Cc: Matt Porter, git
In-Reply-To: <20050508015016.GL9495@pasky.ji.cz>
>>>>> "PB" == Petr Baudis <pasky@ucw.cz> writes:
PB> ... since I *don't* think you want to share this. The very
PB> fact it is in the .git/ directory implies here that these
PB> are your local exclude patterns which are likely
PB> temporary...
Is it really the case? I recall that Linux kernel started
shipping with the standard dontdiff file for everybody's use
some time ago, after enough people wanted it included in the
upstream release. Maybe you would want to read from both?
PB> The fact that we have no support for version-tracked exclude file can't
PB> stop me! ;-)
What darcs folks do is that they have a per-tree configuration
(kept in ./_darcs, which is similar to our ./.git) that says
which file is the exclude list, and by setting configuration
item to point at a file which _is_ version controlled they can
share the exclude file.
^ permalink raw reply
* [ANNOUNCE] Cogito-0.10
From: Petr Baudis @ 2005-05-08 23:34 UTC (permalink / raw)
To: git
Hello,
I'm happy to announce new release of Cogito, my SCM-like layer upon
the Linus' GIT tree history storage engine, aiming for user-friendliness.
Get it at
http://www.kernel.org/pub/software/scm/cogito
or cg-update if you already have any decently fresh version.
The highlights are cg-logging of individual files, cg-export
foo.tar.gz, fixed cg-init of fresh trees (it makes an initial commit
now), cg-commit message processing enhancements (in cooperation mainly
with Marcel Holtmann), cg-restore, cg-admin-uncommit, and cg-X* stuff in
a library directory. And also merge with Linus, which brings some stuff
chronologically pre-cogito-0.9, but I forgot to pull before release.
Usage changes:
* cg-update without parameters now does not recover lost files;
that functionality was moved to cg-restore which can do that
with individual files only too.
* cg-update and cg-pull w/o arguments default to "origin" again.
Everyone rejoices.
* cg-init SOURCE_LOC is now deprecated, cg-init should not be
called directly for the cloning stuff anymore. Use it only for
creating new repositories now.
* cg-clone can take a -s argument now which makes it to clone to
the current directory instead of a subdirectory.
I think the usage is very stabilized by now, and is actually quite
unlikely to change anymore - you can safely start to get used to it. The
only change still queued is removing cg-init SOURCE_LOC functionality
altogether; I'm delaying that yet mainly because of the
http://www.kernel.org/git/ text. ;-)
I think we are overall stabilizing very nicely, and might actually
be nearing cogito-1.0 (but let that not stop you doing anything yet...
perhaps except rewriting the whole thing in Befunge).
Please note that my patch queue is basically empty now. The only
things I have marked for consideration yet are:
4778 N Apr 22 Morten Welinder ( 7.0K) [PATCH] Constify
5607 N T Apr 28 Philip Pokorny ( 2.5K) PATCH[*/4]: Allow tree-id to return the ID of a tree object
So if you have a patch you think I should have in my tree too, please
resend it. Do not forget to put the patch inline to the mail body or as
a text/plain attachment, and to sign it off.
Have fun,
--
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 0/2] core-git documentation update
From: Junio C Hamano @ 2005-05-08 23:35 UTC (permalink / raw)
To: David Greaves; +Cc: git
In-Reply-To: <427E83EA.2000104@dgreaves.com>
>>>>> "DG" == David Greaves <david@dgreaves.com> writes:
DG> The intention now was for me to go through Linus' HEAD and verify the
DG> docs actually documented the HEAD.
DG> Then I think comparing the HEAD to jit-jc and preparing patches for that?
That one is up to you, but if your patches are against git-jc,
it would make _my_ life simpler and hopefully would make merge
easier for Linus when he returns.
After he returns, it would probably not make much sense sending
patch against git-jc, unless all of the following conditions
hold true: (1) what is already merged to git-jc conflicts with
what you are modifying, (2) all changes in git-jc are trivially
correct and veriy likely to hit Linus tree without being
rejected, and (3) Linus is too busy and lags behind git-jc.
^ permalink raw reply
* Re: [PATCH] Add exclude file support to cg-status
From: Petr Baudis @ 2005-05-08 23:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matt Porter, git
In-Reply-To: <7vfywx2t77.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Mon, May 09, 2005 at 01:28:44AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> >>>>> "PB" == Petr Baudis <pasky@ucw.cz> writes:
>
> PB> ... since I *don't* think you want to share this. The very
> PB> fact it is in the .git/ directory implies here that these
> PB> are your local exclude patterns which are likely
> PB> temporary...
>
> Is it really the case? I recall that Linux kernel started
> shipping with the standard dontdiff file for everybody's use
> some time ago, after enough people wanted it included in the
> upstream release. Maybe you would want to read from both?
Of course. You should combine them both, the .git/ one having the
ultimate precedence (if we support the CVS-like ! stuff too).
That is, in CVS the version-controlled files are per-directory, which
can be very nice too; things are getting harder now, though, since we
should have some per-project ignore file too.
> PB> The fact that we have no support for version-tracked exclude file can't
> PB> stop me! ;-)
>
> What darcs folks do is that they have a per-tree configuration
> (kept in ./_darcs, which is similar to our ./.git) that says
> which file is the exclude list, and by setting configuration
> item to point at a file which _is_ version controlled they can
> share the exclude file.
That is certainly a good idea (at least for kernel, where you probably
just want to give it dontdiff), but we need a sensible default.
--
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: cg-log patches
From: Jonas Fonseca @ 2005-05-08 23:49 UTC (permalink / raw)
To: Sean; +Cc: Petr Baudis, GIT Mailing List
In-Reply-To: <1742.10.10.10.24.1115573750.squirrel@linux1>
Sean <seanlkml@sympatico.ca> wrote Sun, May 08, 2005:
> commit 33762f33ee87377c0cfcea51382bad04d7c9ba8d
>
> Fix cg-log -f option so that a complete list of files is
> displayed when a commit has more than one parent.
This sounds great.
> Move the list of files so they're displayed after the
> commit message
The reason I put it at the top was to make it more similar to GNU-style
changelogs (if there is such a style).
> List the files in columns, instead of one big line of comma-
> separated files.
I think that will make `-f' less usable because of the extra scrolling.
Assuming use of wc will not create more dependency nightmares and the
extra overhead is acceptable here is a patch that will wrap file listing
lines near the 80th column.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
--- d4119364a7fbf5a4b8f00f061e4f5d58fa4abd0e/cg-log (mode:100755)
+++ uncommitted/cg-log (mode:100755)
@@ -64,8 +64,16 @@
fi
echo
$list_cmd | while read modes type sha1s file; do
- echo -n "$sep$file"
+ echo -n "$sep"
sep=", "
+ if [ $(echo "$line$sep$file" | wc -c) -lt 75 ]; then
+ line="$line$sep$file"
+ echo -n "$file"
+ else
+ line="$file"
+ echo "$coldefault"
+ echo -n " $colfiles$file"
+ fi
done
echo "$coldefault:"
}
--
Jonas Fonseca
^ permalink raw reply
* [PATCH Cogito] Use cg-commit -E to invoke editor and always commit
From: Marcel Holtmann @ 2005-05-09 0:25 UTC (permalink / raw)
To: Petr Baudis; +Cc: GIT Mailing List
[-- Attachment #1: Type: text/plain, Size: 251 bytes --]
Hi Petr,
the attached patch introduces the -E parameter to cg-commit and then
uses it in cg-init. If you use -E instead of -e the editor is invoked
and it will do the commit even it the default commit messages has not
been changed.
Regards
Marcel
[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 1618 bytes --]
cg-commit: needs update
cg-init: needs update
Index: cg-commit
===================================================================
--- 00b94eea5b99d5dd1d1bbe9c9ca3502d11aec581/cg-commit (mode:100755)
+++ uncommitted/cg-commit (mode:100755)
@@ -13,6 +13,8 @@
# appended to a single commit message, each as separate paragraph.
# -e forces the editor to be brought up even when -m parameters were
# passed to cg-commit.
+# -E forces the editor to be brought up and it will do the commit
+# even if the default commit message is not changed.
. ${COGITO_LIB}cg-Xlib
@@ -21,6 +23,7 @@
forceeditor=
ignorecache=
+commitalways=
msgs=()
while [ "$1" ]; do
case "$1" in
@@ -32,6 +35,11 @@
forceeditor=1
shift
;;
+ -E)
+ forceeditor=1
+ commitalways=1
+ shift
+ ;;
-m*)
msgs=("${msgs[@]}" "${1#-m}")
shift
@@ -126,10 +134,10 @@
if tty -s; then
if ! [ "$msgs" ] || [ "$forceeditor" ]; then
${EDITOR:-vi} $LOGMSG2
- fi
- if ! [ "$msgs" ] && ! [ $LOGMSG2 -nt $LOGMSG ]; then
- rm $LOGMSG $LOGMSG2
- die 'Commit message not modified, commit aborted'
+ if ! [ "$commitalways" ] && ! [ $LOGMSG2 -nt $LOGMSG ]; then
+ rm $LOGMSG $LOGMSG2
+ die 'Commit message not modified, commit aborted'
+ fi
fi
else
cat >>$LOGMSG2
Index: cg-init
===================================================================
--- 00b94eea5b99d5dd1d1bbe9c9ca3502d11aec581/cg-init (mode:100755)
+++ uncommitted/cg-init (mode:100755)
@@ -32,6 +32,6 @@
else
git-read-tree # Seed the dircache
find * | xargs cg-add
- cg-commit -C -m"Initial commit" -e
+ cg-commit -C -m"Initial commit" -E
fi
exit 0
^ permalink raw reply
* [PATCH Cogito] Remove heading and trailing empty lines from commit messages
From: Marcel Holtmann @ 2005-05-09 0:28 UTC (permalink / raw)
To: Petr Baudis; +Cc: GIT Mailing List
[-- Attachment #1: Type: text/plain, Size: 137 bytes --]
Hi Petr,
the attached patch removes heading and trailing empty lines from the
commit message before doing the commit.
Regards
Marcel
[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 389 bytes --]
cg-commit: needs update
Index: cg-commit
===================================================================
--- 00b94eea5b99d5dd1d1bbe9c9ca3502d11aec581/cg-commit (mode:100755)
+++ uncommitted/cg-commit (mode:100755)
@@ -134,7 +134,7 @@
else
cat >>$LOGMSG2
fi
-grep -v ^CG: $LOGMSG2 >$LOGMSG
+grep -v ^CG: $LOGMSG2 | sed '/./,${/./b;:a;$d;N;/\n$/ba;b;};d' >$LOGMSG
rm $LOGMSG2
^ 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