* Re: What is in git.git
From: Junio C Hamano @ 2006-01-21 22:22 UTC (permalink / raw)
To: Alexander Litvinov; +Cc: git
In-Reply-To: <7vek31mkyg.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Alexander Litvinov <lan@ac-sw.com> writes:
>...
>> subpro and main are separate projects and master is the join
>> of them. If I want to modify subpro I have to checkout subpro
>> branch, edit files. When I have to got to master and bind new
>> version of subpro to it.
>
> I do not see any problem with this....
>...
>> Worse, if I will edit subpro's files bined to master branch
>> changes will go to master branch instead of subpro's history.
>
> Simply untrue.
Sorry, these came out somewhat in a wrong way, so let me
clarify.
What I meant was that there isn't anything coded so far that
makes your worries real issues yet, and I do not intend to code
Porcelainish scripts that are broken in the ways you see as
problems in your message.
The point you raised are valid concerns. You need to keep them
in mind when you start writing subproject aware version of
git-checkout, git-commit and git-merge commands (among other
things I might have forgotten, but I think these three covers
pretty much everything). You are welcome to beat me to it,
since I am not planning to do them right away.
^ permalink raw reply
* Re: cg-update bug?
From: walt @ 2006-01-21 21:59 UTC (permalink / raw)
To: git
In-Reply-To: <20060121203519.GN28365@pasky.or.cz>
Petr Baudis wrote:
> Dear diary, on Sat, Jan 21, 2006 at 04:03:59PM CET, I got a letter
> where walt <wa1ter@myrealbox.com> said that...
>> Thanks for adding the flag, Petr. I tried it on git and
>> the kernel this morning, and in each case cg-update -v
>> printed the name of only one file. From looking at the
>> logs I'm pretty sure there were multiple files updated,
>> not just one. Does it print all filenames for you?
> It prints all the filenames for me, but only the fetched ones. If you
> fetched without merge earlier, it will list only the newly fetched
> stuff. That is rather confusing, so now I added also cg-merge -v and
> cg-update will pass its -v to cg-merge instead of cg-fetch.
Well, I was anxious to try your new changes so I did cg-update on
your cogito repository and I saw *six* updated files print out.
I guess that both git and the kernel really did have only *one*
updated file this morning, after all. A really bizarre coincidence!
Thanks again for the update, and I hope your exam went well :o)
^ permalink raw reply
* Re: Remove "historical" objects from repository to save place
From: Andrey Borzenkov @ 2006-01-21 21:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wz1mjy8.fsf@assigned-by-dhcp.cox.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Saturday 21 January 2006 22:58, Junio C Hamano wrote:
>
> You might be able to cauterize the history at a specific commit
> and then re-clone. I've talked about how in "[QUESTION] about
> ..git/info/grafts file" thread yesterday, so I won't repeat that.
thank you, quite complete description. One question - any caveats in using git
ls-remote to fetch graft point?
echo $(git ls-remote
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git v2.6.15
| cut -f1) > .git/info/grafts
etc
this avoids downloading over 1G in the first place.
regards
- -andrey
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFD0qu6R6LMutpd94wRAtuzAJoCT15+8d9BcIEhOxmD9lrRGWE6EQCghg5l
SR5g1+nAUNlltYyXydxsFAs=
=U2cu
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: Remove "historical" objects from repository to save place
From: Junio C Hamano @ 2006-01-21 21:46 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86slrhe270.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
>>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
>
> Junio> Most likely what the original requestor cloned from Linus has
> Junio> been already packed so git-prune would not do much.
>
> Wait. Does that mean that:
>
> $ git-checkout -b playground
> $ work work work
> $ git-commit -m 'snapshot'
> $ git-checkout -b master
> $ git-repack -a -d
>
> means that even if I do
>
> $ git-branch -d playground
> $ git-repack -a -d
>
> I still have the commit from playground as objects inside my one big pack?
Repack retraces from all the available refs, so that is fine.
Pasky was talking about prune, which is a different animal.
^ permalink raw reply
* Re: problem installing latest cogito
From: Petr Baudis @ 2006-01-21 21:46 UTC (permalink / raw)
To: dave morgan; +Cc: blaisorblade, proski, git
In-Reply-To: <ep45t15q8ojs215f39ir9sli98163m4b87@4ax.com>
Dear diary, on Sat, Jan 21, 2006 at 09:08:52PM CET, I got a letter
where dave morgan <morgad@eclipse.co.uk> said that...
> and then make-install worked, and I seem to have a working cogito ...
> but 'make test' fails -
Thanks for the notice; I do not run make test very frequently (except
before every release). This was introduced in
[PATCH] Unclutter cg status with --directory as GIT does
and I've fixed it by making it optional for list_untracked_files,
explicitly requesting it in cg-status and not in other users (that
change also broke cg-add and cg-init), and make cg-status use
list_untracked_files directly.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: problem installing latest cogito
From: dave morgan @ 2006-01-21 21:22 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git, sean
In-Reply-To: <20060121210622.GO28365@pasky.or.cz>
On Sat, 21 Jan 2006 22:06:22 +0100, Petr Baudis <pasky@suse.cz> wrote:
>Dear diary, on Sat, Jan 21, 2006 at 09:12:28PM CET, I got a letter
>where Junio C Hamano <junkio@cox.net> said that...
>> I got a complaint or two that some version of sed does not like
>> ';' to concatenate more than one commands, and have been trying
>> to train myself to do either multiple -e options or multi-line
>> scripts. E.g when I am tempted to say:
>>
>> sed -e 's/foo/bar/;s/baz/boa/' froboz
>>
>> Instead, I say either
>>
>> sed -e 's/foo/bar/' -e 's/baz/boa/' froboz
>
>Good idea, thanks. Hopefully this will fix Dave Morgan's problem.
>Committed and pushed out.
david@tower2:~/cogito$ cg-update -v
Fetching head...
Fetching objects...
progress: 27 objects, 33087 bytes
Fetching tags...
Tree change:
d1a89167fbe0287cc43609bf37534ba1a98614d9:3311308023fcbd526b37dfdc61e641ca18bc7f99
:100644 100644 f1fc272... 25a1d21... M Makefile
:100755 100755 2970d86... 0021080... M cg-admin-uncommit
:100755 100755 c7423ee... 8c2e852... M cg-fetch
:100755 100755 9296e0f... 3b6defd... M cg-merge
:100755 100755 5fd3f5b... 317d7e6... M cg-push
:100755 100755 06a16fe... a2df345... M cg-update
Applying changes...
Fast-forwarding a9c75f3b8b1adb01859ff2c9b028f72a247837c6 ->
3311308023fcbd526b37dfdc61e641ca18bc7f99
on top of a9c75f3b8b1adb01859ff2c9b028f72a247837c6...
david@tower2:~/cogito$ make install
Generating cg-version...
install -m755 -d /home/david/bin
install cg-object-id cg-add cg-admin-lsobj cg-admin-uncommit
cg-branch-add cg-branch-ls cg-reset cg-clone cg-commit cg-diff
cg-export cg-help cg-init cg-log cg-merge cg-mkpatch cg-patch cg-fetch
cg-restore cg-rm cg-seek cg-status cg-tag cg-tag-ls cg-update cg
cg-admin-ls cg-push cg-branch-chg cg-admin-cat cg-clean
cg-admin-setuprepo cg-switch cg-version /home/david/bin
for i in 'cg-cancel:cg-reset' 'commit-id:cg-object-id' \
'tree-id:cg-object-id' 'parent-id:cg-object-id' \
'cg-commit-id:cg-object-id' \
'cg-tree-id:cg-object-id' 'cg-parent-id:cg-object-id'
\
'cg-pull:cg-fetch'; do \
old=`echo $i | cut -d : -f 1`; \
new=`echo $i | cut -d : -f 2`; \
rm -f /home/david/bin/$old; \
ln -s $new /home/david/bin/$old; \
done
install -m755 -d /home/david/lib/cogito
install cg-Xlib cg-Xmergefile cg-Xfetchprogress /home/david/lib/cogito
cd /home/david/bin; \
for file in cg-object-id cg-add cg-admin-lsobj
cg-admin-uncommit cg-branch-add cg-branch-ls cg-reset cg-clone
cg-commit cg-diff cg-export cg-help cg-init cg-log cg-merge cg-mkpatch
cg-patch cg-fetch cg-restore cg-rm cg-seek cg-status cg-tag cg-tag-ls
cg-update cg cg-admin-ls cg-push cg-branch-chg cg-admin-cat cg-clean
cg-admin-setuprepo cg-switch cg-version; do \
sed -e
's/\${COGITO_LIB}/\${COGITO_LIB:-\/home\/david\/lib\/cogito\/}/g' \
-e
's/\${COGITO_SHARE}/\${COGITO_SHARE:-\/home\/david\/share\/cogito\/}/g'
\
$file > $file.new; \
cat $file.new > $file; rm $file.new; \
done
cd /home/david/lib/cogito; \
for file in cg-Xlib cg-Xmergefile cg-Xfetchprogress; do \
sed -e
's/\${COGITO_LIB}/\${COGITO_LIB:-\/home\/david\/lib\/cogito\/}/g' \
-e
's/\${COGITO_SHARE}/\${COGITO_SHARE:-\/home\/david\/share\/cogito\/}/g'
\
$file > $file.new; \
cat $file.new > $file; rm $file.new; \
done
install -m755 -d /home/david/share/cogito
install -m644 default-exclude /home/david/share/cogito
david@tower2:~/cogito$
works for me :-)
many thanks to all for sorting it out
best regards
Dave
^ permalink raw reply
* Re: problem installing latest cogito
From: Petr Baudis @ 2006-01-21 21:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: morgad, git, sean
In-Reply-To: <7vmzhpl4r7.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sat, Jan 21, 2006 at 09:12:28PM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> I got a complaint or two that some version of sed does not like
> ';' to concatenate more than one commands, and have been trying
> to train myself to do either multiple -e options or multi-line
> scripts. E.g when I am tempted to say:
>
> sed -e 's/foo/bar/;s/baz/boa/' froboz
>
> Instead, I say either
>
> sed -e 's/foo/bar/' -e 's/baz/boa/' froboz
Good idea, thanks. Hopefully this will fix Dave Morgan's problem.
Committed and pushed out.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: Remove "historical" objects from repository to save place
From: Randal L. Schwartz @ 2006-01-21 20:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7virsdl44q.fsf@assigned-by-dhcp.cox.net>
>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
Junio> Most likely what the original requestor cloned from Linus has
Junio> been already packed so git-prune would not do much.
Wait. Does that mean that:
$ git-checkout -b playground
$ work work work
$ git-commit -m 'snapshot'
$ git-checkout -b master
$ git-repack -a -d
means that even if I do
$ git-branch -d playground
$ git-repack -a -d
I still have the commit from playground as objects inside my one big pack?
Ick. How do I make that go away?
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: cg-update bug?
From: Petr Baudis @ 2006-01-21 20:35 UTC (permalink / raw)
To: walt; +Cc: git
In-Reply-To: <dqtih0$i80$1@sea.gmane.org>
Dear diary, on Sat, Jan 21, 2006 at 04:03:59PM CET, I got a letter
where walt <wa1ter@myrealbox.com> said that...
> walt wrote:
> > ...there is no -v flag for cg-update. Could it be added
> > so I can get the old behavior back?
>
> Thanks for adding the flag, Petr. I tried it on git and
> the kernel this morning, and in each case cg-update -v
> printed the name of only one file. From looking at the
> logs I'm pretty sure there were multiple files updated,
> not just one. Does it print all filenames for you?
It prints all the filenames for me, but only the fetched ones. If you
fetched without merge earlier, it will list only the newly fetched
stuff. That is rather confusing, so now I added also cg-merge -v and
cg-update will pass its -v to cg-merge instead of cg-fetch.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: Remove "historical" objects from repository to save place
From: Junio C Hamano @ 2006-01-21 20:25 UTC (permalink / raw)
To: git
In-Reply-To: <20060121200615.GM28365@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
>> You might be able to cauterize the history at a specific commit
>> and then re-clone. I've talked about how in "[QUESTION] about
>> .git/info/grafts file" thread yesterday, so I won't repeat that.
>
> Shouldn't the git-prune be sufficient after cauterizing the history?
Logically yes, but practically no.
Most likely what the original requestor cloned from Linus has
been already packed so git-prune would not do much.
^ permalink raw reply
* Re: problem installing latest cogito
From: Junio C Hamano @ 2006-01-21 20:12 UTC (permalink / raw)
To: Petr Baudis; +Cc: morgad, git, sean
In-Reply-To: <BAYC1-PASMTP061F43C7F760A9FB73B616AE1E0@CEZ.ICE>
sean <seanlkml@sympatico.ca> writes:
> On Sat, 21 Jan 2006 20:48:26 +0100
> Petr Baudis <pasky@suse.cz> wrote:
>
>> > sed -e
>> > 's/\${COGITO_LIB}/\${COGITO_LIB:-\/home\/david\/lib\/cogito\/}/g; \
>> >
>> > s/\${COGITO_SHARE}/\${COGITO_SHARE:-\/home\/david\/share\/cogito\/}/g'
>> > \
>> > $file > $file.new; \
>> > cat $file.new > $file; rm $file.new; \
>> > done
>> > sed: -e expression #1, char 145: unterminated address regex
>
> The problem seems to go away if you remove the quoted end-of-line:
That is not "the quoted end-of-line". Backslashes do not have
any special meaning inside a single quote pair for bourne shell
quoting. The script is passing the backslash to sed.
IIRC, make seems to do different things for the backslash at the
end of line depending on vintage, so if this scriptlet appears
in a Makefile you may have another version dependency. I
usually cop out of this problem by having a separate shell
script and run it from the Makefile, instead of spelling out the
sed commandline in the Makefile.
I got a complaint or two that some version of sed does not like
';' to concatenate more than one commands, and have been trying
to train myself to do either multiple -e options or multi-line
scripts. E.g when I am tempted to say:
sed -e 's/foo/bar/;s/baz/boa/' froboz
Instead, I say either
sed -e 's/foo/bar/' -e 's/baz/boa/' froboz
or
sed -e '
s/foo/bar
s/baz/boa/
' froboz
I do not know how much of the above applies to your immediate
problem, but I hope some of it helps.
^ permalink raw reply
* Re: problem installing latest cogito
From: dave morgan @ 2006-01-21 20:08 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060121194826.GK28365@pasky.or.cz>
On Sat, 21 Jan 2006 20:48:26 +0100, Petr Baudis <pasky@suse.cz> wrote:
>Dear diary, on Sat, Jan 21, 2006 at 03:08:27PM CET, I got a letter
>where dave morgan <morgad@eclipse.co.uk> said that...
>> sed -e
>> 's/\${COGITO_LIB}/\${COGITO_LIB:-\/home\/david\/lib\/cogito\/}/g; \
>>
>> s/\${COGITO_SHARE}/\${COGITO_SHARE:-\/home\/david\/share\/cogito\/}/g'
>> \
>> $file > $file.new; \
>> cat $file.new > $file; rm $file.new; \
>> done
>> sed: -e expression #1, char 145: unterminated address regex
>
>(145 is the total expression length.) Now, I'm at loss - this works here
>and I can see nothing wrong on the regexp - does anyone have any idea?
>
>What is your sed version?
~/cogito$ sed --version
GNU sed version 4.1.2
(from Debian/testing)
>
>> net result - a pile of zero length files in /home/david/bin/ :-(
>>
>> can I just copy the cg-files from to cogito directory over?
>
>No, you would have to also set $COGITO_LIB and $COGITO_SHARE (or put
>cg-X* scripts to your bin directory as well).
I blundered about for 30 minutes with git-reset, and ended up here -
david@tower2:~/cogito$ cg-log | head
commit a9c75f3b8b1adb01859ff2c9b028f72a247837c6
tree c0c2b743d5dbacc33bced6ace62347724664c817
parent 653b039dbf989696160db56bb196a1584932fdeb
author Petr Baudis <pasky@suse.cz> Sat, 21 Jan 2006 02:28:30 +0100
committer Petr Baudis <xpasky@machine.or.cz> Sat, 21 Jan 2006 02:28:30
+0100
Add support for cg-update -v
Makes it call cg-fetch with -v as well, to list all the changes
being
pulled.
and then make-install worked, and I seem to have a working cogito ...
but 'make test' fails -
*** t9400-clean.sh ***
* ok 1: initialize repo
* ok 2: cg-clean -n in top-level dir
* ok 3: cg-clean -Ddxqn in top-level dir
* ok 4: cg-clean -n in subdir
* FAIL 5: cg-clean in subdir
(cd 'repo dir' && cg-clean && check_loss)
* ok 6: cg-clean -d in subdir
* FAIL 7: cg-clean -x in subdir
(cd 'repo dir' && cg-clean -x && check_loss)
* FAIL 8: cg-clean in top-level dir
(cg-clean && check_loss)
* FAIL 9: cg-clean -x in top-level dir
(cg-clean -x && check_loss)
* FAIL 10: cg-clean -d in top-level dir
(cg-clean -d && check_loss)
* ok 11: cg-clean -D in top-level dir
* failed 5 among 11 test(s)
make[1]: *** [all] Error 1
make[1]: Leaving directory `/home/david/cogito/t'
make: *** [test] Error 2
is this expected?
best regards
Dave
^ permalink raw reply
* Re: problem installing latest cogito
From: sean @ 2006-01-21 20:01 UTC (permalink / raw)
To: Petr Baudis; +Cc: morgad, git
In-Reply-To: <20060121200345.GL28365@pasky.or.cz>
On Sat, 21 Jan 2006 21:03:45 +0100
Petr Baudis <pasky@suse.cz> wrote:
>
> Yes, the problem goes away because then make will split that to two
> lines, causing:
>
> sed -e 's/\${COGITO_LIB}/\${COGITO_LIB:-\/home\/xpasky\/lib\/cogito\/}/g;
> /bin/sh: -c: line 0: unexpected EOF while looking for matching `''
> /bin/sh: -c: line 1: syntax error: unexpected end of file
>
Ah sorry I didn't test it in within the makefile context. However, just
typing the above on the command line works, whereas the one with the
quoted end-of-line gives the error message mentioned in the initial report
so I suspect it's at least a clue to the real problem.
Sean
^ permalink raw reply
* Re: Remove "historical" objects from repository to save place
From: Petr Baudis @ 2006-01-21 20:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andrey Borzenkov, git
In-Reply-To: <7v1wz1mjy8.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sat, Jan 21, 2006 at 08:58:55PM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> You might be able to cauterize the history at a specific commit
> and then re-clone. I've talked about how in "[QUESTION] about
> .git/info/grafts file" thread yesterday, so I won't repeat that.
Shouldn't the git-prune be sufficient after cauterizing the history?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: problem installing latest cogito
From: Petr Baudis @ 2006-01-21 20:03 UTC (permalink / raw)
To: sean; +Cc: morgad, git
In-Reply-To: <20060121144901.33b03395.seanlkml@sympatico.ca>
Dear diary, on Sat, Jan 21, 2006 at 08:49:01PM CET, I got a letter
where sean <seanlkml@sympatico.ca> said that...
> On Sat, 21 Jan 2006 20:48:26 +0100
> Petr Baudis <pasky@suse.cz> wrote:
>
> > > sed -e
> > > 's/\${COGITO_LIB}/\${COGITO_LIB:-\/home\/david\/lib\/cogito\/}/g; \
> > >
> > > s/\${COGITO_SHARE}/\${COGITO_SHARE:-\/home\/david\/share\/cogito\/}/g'
> > > \
> > > $file > $file.new; \
> > > cat $file.new > $file; rm $file.new; \
> > > done
> > > sed: -e expression #1, char 145: unterminated address regex
>
> The problem seems to go away if you remove the quoted end-of-line:
>
> sed -e 's/\${COGITO_LIB}/\${COGITO_LIB:-\/home\/david\/lib\/cogito\/}/g;
> s/\${COGITO_SHARE}/\${COGITO_SHARE:-\/home\/david\/share\/cogito\/}/g'
>
>
> where the following, doesn't:
>
> sed -e 's/\${COGITO_LIB}/\${COGITO_LIB:-\/home\/david\/lib\/cogito\/}/g; \
> s/\${COGITO_SHARE}/\${COGITO_SHARE:-\/home\/david\/share\/cogito\/}/g'
Yes, the problem goes away because then make will split that to two
lines, causing:
sed -e 's/\${COGITO_LIB}/\${COGITO_LIB:-\/home\/xpasky\/lib\/cogito\/}/g;
/bin/sh: -c: line 0: unexpected EOF while looking for matching `''
/bin/sh: -c: line 1: syntax error: unexpected end of file
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: Remove "historical" objects from repository to save place
From: Junio C Hamano @ 2006-01-21 19:58 UTC (permalink / raw)
To: Andrey Borzenkov; +Cc: git
In-Reply-To: <200601212218.51055.arvidjaar@mail.ru>
Andrey Borzenkov <arvidjaar@mail.ru> writes:
> Description of git-prune suggests that it may be possible by removing tags
> from refs/tags
If the documentation suggests that, then it is misleading.
> OTOH I may have commit chain that will prevent them.
Correct.
> Also
> won't those tags come back after git fetch --tags?
Correct.
You might be able to cauterize the history at a specific commit
and then re-clone. I've talked about how in "[QUESTION] about
.git/info/grafts file" thread yesterday, so I won't repeat that.
^ permalink raw reply
* Re: problem installing latest cogito
From: sean @ 2006-01-21 19:49 UTC (permalink / raw)
To: Petr Baudis; +Cc: morgad, git
In-Reply-To: <20060121194826.GK28365@pasky.or.cz>
On Sat, 21 Jan 2006 20:48:26 +0100
Petr Baudis <pasky@suse.cz> wrote:
> > sed -e
> > 's/\${COGITO_LIB}/\${COGITO_LIB:-\/home\/david\/lib\/cogito\/}/g; \
> >
> > s/\${COGITO_SHARE}/\${COGITO_SHARE:-\/home\/david\/share\/cogito\/}/g'
> > \
> > $file > $file.new; \
> > cat $file.new > $file; rm $file.new; \
> > done
> > sed: -e expression #1, char 145: unterminated address regex
The problem seems to go away if you remove the quoted end-of-line:
sed -e 's/\${COGITO_LIB}/\${COGITO_LIB:-\/home\/david\/lib\/cogito\/}/g;
s/\${COGITO_SHARE}/\${COGITO_SHARE:-\/home\/david\/share\/cogito\/}/g'
where the following, doesn't:
sed -e 's/\${COGITO_LIB}/\${COGITO_LIB:-\/home\/david\/lib\/cogito\/}/g; \
s/\${COGITO_SHARE}/\${COGITO_SHARE:-\/home\/david\/share\/cogito\/}/g'
Sean
^ permalink raw reply
* Re: problem installing latest cogito
From: Petr Baudis @ 2006-01-21 19:48 UTC (permalink / raw)
To: dave morgan; +Cc: git
In-Reply-To: <fof4t15q95qkakgk6b7fbfuqh3r6q7ei17@4ax.com>
Dear diary, on Sat, Jan 21, 2006 at 03:08:27PM CET, I got a letter
where dave morgan <morgad@eclipse.co.uk> said that...
> sed -e
> 's/\${COGITO_LIB}/\${COGITO_LIB:-\/home\/david\/lib\/cogito\/}/g; \
>
> s/\${COGITO_SHARE}/\${COGITO_SHARE:-\/home\/david\/share\/cogito\/}/g'
> \
> $file > $file.new; \
> cat $file.new > $file; rm $file.new; \
> done
> sed: -e expression #1, char 145: unterminated address regex
(145 is the total expression length.) Now, I'm at loss - this works here
and I can see nothing wrong on the regexp - does anyone have any idea?
What is your sed version?
> net result - a pile of zero length files in /home/david/bin/ :-(
>
> can I just copy the cg-files from to cogito directory over?
No, you would have to also set $COGITO_LIB and $COGITO_SHARE (or put
cg-X* scripts to your bin directory as well).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: What is in git.git
From: Junio C Hamano @ 2006-01-21 19:37 UTC (permalink / raw)
To: Alexander Litvinov; +Cc: git
In-Reply-To: <200601211636.02340.lan@ac-sw.com>
I suspect there is an misunderstanding or two, because I did not
repeat what the other parts (Porcelain-ish) would do and
everything fits together. For that, you need to refer to a
couple of earlier messages from me on the "RFC: Subprojects"
thread [*1*], and perhas use some imagination, because the
outline I did back then was done without having much of what are
in "pu" today and I may have got some details wrong. The
message you are responding to was to give a demonstation of the
current status of how the core part works.
Alexander Litvinov <lan@ac-sw.com> writes:
>> 1. Can I bind some branch instead of tag (commit) ?
The "bind" line describes relationship among specific points in
development histories of subprojects and superprojects so it
needs to use commit object names.
If you mean by "binding a branch", to record how each subproject
relates to the toplevel project (i.e. "the subproject bound to
X/ subdirectory of the toplevel project comes from branch Y"),
that information needs to be somewhere, but recording it in the
commit object goes against the whole git philosophy.
Branch naming is a local matter. "master" in my repository
represents a different development history of the project from
what your "master" does. The subproject I happen to use the
"subpro" branch to keep track of might be called "sub" in yours.
Recording the name "subpro" on a "bind" line in a commit object
makes that commit object useless when you fetch such a commit
from my repository.
>> 2. Is it possible to commit changes of subpro's file in
>> master branch into subpro branch to make this changes visible
>> to master-2 ?
You are way ahead of what I am putting in "pu". That is all
responsibility of the scripting part that use the core part;
refer to the outline in earlier messages on the subprojects
thread.
I think the above relates to this part of what you said:
> subpro and main are separate projects and master is the join
> of them. If I want to modify subpro I have to checkout subpro
> branch, edit files. When I have to got to master and bind new
> version of subpro to it.
I do not see any problem with this. The core level tools in
"pu" supports that mode of operation. They also support another
mode of operation, checking out the whole thing and making a
commit for subprojects.
> Worse, if I will edit subpro's files bined to master branch
> changes will go to master branch instead of subpro's history.
Simply untrue.
Even though I will use present tense (e.g. "the checkout command
notices") in the following, you should remember that the current
set of barebone Porcelainish scripts have not been taught about
any of this.
You need to keep a file that describes how your repository is
tracking the development histories of each subproject in
$GIT_DIR/bind, that would look like:
master main=/ subpro=sub/
meaning:
In this repository, the project whose history is kept
track of by "master" branch binds the projects whose
history is kept track of by "subpro" branch at sub/ and
another project that holds the rest whose history is
kept track by "main" branch.
You can have more than one branches for subprojects and the
combined project. Just have more lines in $GIT_DIR/bind,
like so, to achieve that [*2*]:
master main=/ subpro=sub/
master20 main2=/ subpro=sub/
master02 main2=/ subpro2=sub/
...
To work on the example project, there are two alternative
workflows that can be supported:
1. You can be on "master" branch (i.e. checking out everything
at the right place), and make necessary changes, be they at
toplevel or sub/ directory.
The checkout command notices you are on "master" branch, and
you are checking out a bound commit which has "bind" lines
for / and sub/ directories. When committing, a single "git
commit" may make potentially three commits. (1) If you want
to commit changes you made to sub/ part, that is committed to
"subpro" branch; (2) If you want to commit changes to the
rest, that is committed to "main" branch; (3) and a commit to
the "master" branch is made to record the state of the whole
thing.
2. You can work on an individual subproject without bothering
the combined project. You can have another repository to do
developments of the project this repository uses "subpro"
branch to keep track of. When that work in the other
repository on a subproject is ready to be integrated into the
whole, you would fetch/merge the subproject part into this
repository from there, advancing "subpro" branch head in this
repository.
When this happens, you can notice that the commit on the
"bind" line for sub/ part does not match the branch head that
keeps track of that part of the tree (i.e. "subpro")
anymore, and can update sub/ part by merging.
> One more comment: it seems to me it is not possible to make
> two branches on separate subprojects with the same name.
This is precisely why I said "the branch naming is a local
issue", and the commit object does not record branch name. In
the above workflow #2, there is no reason for the other
repository that develops the sub/ subproject part to name its
primary branch "subpro". Most likely it is named "master"
there, and the combined project would fetch its advancement by
issuing:
$ git fetch ../subprorepo master:subpro
If you have more than one branches in the other repository and
would want to use that instead, you would fetch from that branch
not from master there.
You can also keep more than one branch for a subproject inside
the combined repository and have more than one $GIT_DIR/bind
lines that describe different superprojects that bind different
branches of the same subproject at the same location in the
corresponding superproject branch..
[Footnote]
*1* Here are a couple of key messages in the thread, that
attempt to describe how the things would fit together:
http://article.gmane.org/gmane.comp.version-control.git/14781
http://article.gmane.org/gmane.comp.version-control.git/14809
*2* Theoretically you could have NxMxOx... master project
branches for subprojects with N, M, O,... branches, but in
practice, the combined project is an integration field, and most
of the combinations are not something you are interested in.
Not all of the N branches in a subproject need to be directly
integrated into the whole --- most of them are used only while
coming up with the version of the subproject that is suitable
for the integration.
^ permalink raw reply
* Re: [PATCH] AsciiDoc fixes for the git-svnimport manpage
From: Florian Weimer @ 2006-01-21 19:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslrho038.fsf@assigned-by-dhcp.cox.net>
* Junio C. Hamano:
> Florian Weimer <fw@deneb.enyo.de> writes:
>
>> Change "SVN:: Perl" to "SVN::Perl", wrap a long line, and clean up the
>> description of positional arguments.
>
> Thanks. Is this the part you mean by "positional arguments"?
Uhm, "positional arguments" are non-option arguments.
>> -<SVN_repository_URL>::
>> - The URL of the SVN module you want to import. For local
>> - repositories, use "file:///absolute/path".
>> -
>> -<path>
>> +<path>::
>> The path to the module you want to check out.
>
> This looks to me as if we do not allow non file:/// URL like
> svn:// anymore, or we never supported it but the documentation
> pretended we did. Is that what you intended to fix?
No, there was a :: missing, and the SVN_repository_URL part was
duplicated. The documentation tries to remind the reader that the
"/absolute/path" syntax does not work and you have to use a real URL.
(I haven't got git-svnimport to work so far, but the Subversion RA
layer is transport-agnostic, so if it works for file://, it will also
work for svn:// or http://).
^ permalink raw reply
* Re: [PATCH] AsciiDoc fixes for the git-svnimport manpage
From: Junio C Hamano @ 2006-01-21 19:24 UTC (permalink / raw)
To: Florian Weimer; +Cc: git
In-Reply-To: <E1F0O43-0002pn-7O@mid.deneb.enyo.de>
Florian Weimer <fw@deneb.enyo.de> writes:
> Change "SVN:: Perl" to "SVN::Perl", wrap a long line, and clean up the
> description of positional arguments.
Thanks. Is this the part you mean by "positional arguments"?
> -<SVN_repository_URL>::
> - The URL of the SVN module you want to import. For local
> - repositories, use "file:///absolute/path".
> -
> -<path>
> +<path>::
> The path to the module you want to check out.
This looks to me as if we do not allow non file:/// URL like
svn:// anymore, or we never supported it but the documentation
pretended we did. Is that what you intended to fix?
I am a bit confused...
^ permalink raw reply
* Re: git-grep documentation
From: sean @ 2006-01-21 19:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzmlpo0y4.fsf@assigned-by-dhcp.cox.net>
On Sat, 21 Jan 2006 11:06:27 -0800
Junio C Hamano <junkio@cox.net> wrote:
> I've thought about this but it is not any more correct than what
> we have now (both are technically incorrect). If you do not use
> an `-e` and let a non-option terminate the option processing,
> double dashes are not removed, so you do not want it there.
I think this should be fixed rather than requiring the user
to remember such an obscure detail. It's easy to fix git-grep
to deal with it instead (see below).
> Does it? I think if you give -- without -e it will look for a
> path that matches -- because we pass our own -- to ls-files.
>
You're right, in the patch below I added a specific test to handle
this case so the documentation can be simplified and the user is
free to use any combination of -e and --.
> When people make an improvement proposal, I'd often prefer to
> see a patch that is on top of the patch being discussed, not a
> replacement.
>
Yes, I can see how that would be easier to review. Below
is a patch on top of your original that now includes the tweak
mentioned above:
diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt
index 55d3bed..7fd675b 100644
--- a/Documentation/git-grep.txt
+++ b/Documentation/git-grep.txt
@@ -8,7 +8,7 @@ git-grep - print lines matching a patter
SYNOPSIS
--------
-'git-grep' [<option>...] [-e] <pattern> [<path>...]
+'git-grep' [<option>...] [-e] <pattern> [--] [<path>...]
DESCRIPTION
-----------
@@ -24,26 +24,18 @@ OPTIONS
<option>...::
Either an option to pass to `grep` or `git-ls-files`.
- Some `grep` options, such as `-C` and `-m`, that take
- parameters are known to `git-grep`. Among options
- applicable to git-ls-files`, `--others` and
- `--exclude=*` (and other variants of exclusion) may be
- of interest. Only `-o` is recognized as an option to
- `git-ls-files` in the short form (e.g. `-d` and `-m` are
- given to `grep`, not to `git-ls-files` as synonym
- for `--deleted` and `--modifed`), so you need to spell
- out `git-ls-files` options in longer form
- e.g. `--deleted`.
+
+ The following are the specific `git-ls-files` options
+ that may be given: `-o`, `--cached`, `--deleted`, `--others`,
+ `--killed`, `--ignored`, `--modified`, `--exclude=*`,
+ `--exclude-from=*`, and `--exclude-per-directory=*`.
+
+ All other options will be passed to `grep`.
<pattern>::
The pattern to look for. The first non option is taken
as the pattern; if your pattern begins with a dash, use
- `-e <pattern>`. When a pattern is found without `-e`, it
- also terminates the option processing and the rest of
- the parameters are used as the `<path>...`, and you do
- not specifically add `--` to protect the path limiter
- that happens to begin with a dash from being mistaken as
- an option.
+ `-e <pattern>`.
<path>...::
Optional paths to limit the set of files to be searched;
diff --git a/git-grep.sh b/git-grep.sh
index 23b1e03..4f06093 100755
--- a/git-grep.sh
+++ b/git-grep.sh
@@ -36,7 +36,7 @@ while : ; do
shift
;;
--)
- # The rest are git-ls-files paths (or flags)
+ # The rest are git-ls-files paths
shift
break
;;
@@ -49,6 +49,7 @@ while : ; do
got_pattern "$1"
shift
fi
+ [ "$1" = -- ] && shift
break
;;
esac
^ permalink raw reply related
* Remove "historical" objects from repository to save place
From: Andrey Borzenkov @ 2006-01-21 19:18 UTC (permalink / raw)
To: git
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Is it possible to conserve space by removing old versions? Let's say I am not
interested in kernel versions before 2.6.15 - is it possible to remove them
from repository cloned from one of "official" ones (Linus or stable).
Description of git-prune suggests that it may be possible by removing tags
from refs/tags; OTOH I may have commit chain that will prevent them. Also
won't those tags come back after git fetch --tags?
TIA
- -andrey
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFD0okaR6LMutpd94wRAqEZAKC5VAkNMlL9TEmgELynIUf24Dd9oQCeOejQ
Mdmc4lFsYXBHqofjQhgEIlU=
=2j5N
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: git-grep documentation
From: Junio C Hamano @ 2006-01-21 19:06 UTC (permalink / raw)
To: sean; +Cc: git
In-Reply-To: <BAYC1-PASMTP031BAB23C3237DA15F88D3AE1E0@CEZ.ICE>
sean <seanlkml@sympatico.ca> writes:
> So your new patch should also fix that comment to remove the
> "(or flags)" portion.
Probably.
> Since you comment on the -- marker here I think it should
> also appear in the command line above:
>
> 'git-grep' [<option>...] [-e] <pattern> [--] [<path>...]
I've thought about this but it is not any more correct than what
we have now (both are technically incorrect). If you do not use
an `-e` and let a non-option terminate the option processing,
double dashes are not removed, so you do not want it there.
> Instead it is more useful for them to be told _specificly_ which
> git-ls-files options are available and that all others will be
> passed to grep. Somthing like:
I like it.
> ... Your patch fixes the problem case and
> there is no reason now to warn the user away from supplying the --
> marker in addition to the "-e"; it'll work properly in either case.
Does it? I think if you give -- without -e it will look for a
path that matches -- because we pass our own -- to ls-files.
> That's it and the rest looked good. In case you agree with anything
> i've said here, find an amended version of your patch below.
Thanks.
When people make an improvement proposal, I'd often prefer to
see a patch that is on top of the patch being discussed, not a
replacement.
^ permalink raw reply
* [PATCH] AsciiDoc fixes for the git-svnimport manpage
From: Florian Weimer @ 2006-01-21 19:06 UTC (permalink / raw)
Change "SVN:: Perl" to "SVN::Perl", wrap a long line, and clean up the
description of positional arguments.
Signed-off-by: Florian Weimer <fw@deneb.enyo.de>
---
Documentation/git-svnimport.txt | 12 ++++--------
1 files changed, 4 insertions(+), 8 deletions(-)
592699f759a61aee33060d91cfe13ff432c147cf
diff --git a/Documentation/git-svnimport.txt b/Documentation/git-svnimport.txt
index db1ce38..63e28b8 100644
--- a/Documentation/git-svnimport.txt
+++ b/Documentation/git-svnimport.txt
@@ -21,7 +21,7 @@ DESCRIPTION
Imports a SVN repository into git. It will either create a new
repository, or incrementally import into an existing one.
-SVN access is done by the SVN:: Perl module.
+SVN access is done by the SVN::Perl module.
git-svnimport assumes that SVN repositories are organized into one
"trunk" directory where the main development happens, "branch/FOO"
@@ -74,8 +74,8 @@ When importing incrementally, you might
-l <max_rev>::
Specify a maximum revision number to pull.
- Formerly, this option controlled how many revisions to pull, due to
- SVN memory leaks. (These have been worked around.)
+ Formerly, this option controlled how many revisions to pull,
+ due to SVN memory leaks. (These have been worked around.)
-v::
Verbosity: let 'svnimport' report what it is doing.
@@ -100,11 +100,7 @@ with a 40x error pretty quickly.
If you're using the "-d" or "-D" option, this is the URL of the SVN
repository itself; it usually ends in "/svn".
-<SVN_repository_URL>::
- The URL of the SVN module you want to import. For local
- repositories, use "file:///absolute/path".
-
-<path>
+<path>::
The path to the module you want to check out.
-h::
--
1.1.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox