* [PATCH] minor git-reset and git-commit documentation fixes
From: J. Bruce Fields @ 2006-01-21 23:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Minor copyediting of recent additions to git-commit and git-reset documentation
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
Documentation/git-commit.txt | 2 +-
Documentation/git-reset.txt | 8 ++++----
2 files changed, 5 insertions(+), 5 deletions(-)
18d55bf231ae7116e0f0c4da144de46fe0cb2cbf
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index e35984d..72f96fc 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -27,7 +27,7 @@ OPTIONS
-a|--all::
Update all paths in the index file. This flag notices
files that have been modified and deleted, but new files
- you have not told about git are not affected.
+ you have not told git about are not affected.
-c or -C <commit>::
Take existing commit object, and reuse the log message
diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
index 315683a..b4e737e 100644
--- a/Documentation/git-reset.txt
+++ b/Documentation/git-reset.txt
@@ -147,8 +147,8 @@ and resets the tip of the branch to that
Interrupted workflow::
+
-You can get interrupted by an ungent fix request while you are
-still in the middle of a large change. The files in your
+Suppose you are interrupted by an urgent fix request while you
+are in the middle of a large change. The files in your
working tree are not in any shape to be committed yet, but you
need to get to the other branch for a quick bugfix.
+
@@ -164,8 +164,8 @@ $ git reset --soft HEAD^ ;# go back to W
$ git reset <3>
<1> This commit will get blown away so a throw-away log message is OK.
-<2> This removes the 'WIP' commit from the commit history, and makes
- your working tree in the state just before you made that snapshot.
+<2> This removes the 'WIP' commit from the commit history, and sets
+ your working tree to the state just before you made that snapshot.
<3> After <2>, the index file still has all the WIP changes you
committed in <1>. This sets it to the last commit you were
basing the WIP changes on.
--
0.99.8b-g58e3
^ permalink raw reply related
* Re: What is in git.git
From: Josef Weidendorfer @ 2006-01-21 23:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vek31mkyg.fsf@assigned-by-dhcp.cox.net>
On Saturday 21 January 2006 20:37, you wrote:
> Alexander Litvinov <lan@ac-sw.com> writes:
> >> 1. Can I bind some branch instead of tag (commit) ?
> ...
> 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.
The original gitlink proposal did exactly this: it recorded
the place where a subproject is bound by putting a gitlink into
a tree. This way, the binding point can be changed, and is subject to
versioning itself.
I just realized that this is not currently possible with the bind lines.
What about the following usage szenario:
- in a superproject, I use a subproject X implementing some lib by
binding it at X/. My Makefile recurses into X/ for this.
This is recorded at commit point (A)
- later on, I realize I need another lib from a probject Y; I want
to put the libs X and Y into subdirectory lib/ of my superproject;
i.e. I bind Y at lib/Y/ and move the binding point of X to lib/X/.
The Makefile is changed accordingly to build the subprojects.
This is recorded at commit point (B)
A $GITDIR/bind alone will no work, as moving back to (A) would keep
the binding point of subproject, and make is broken.
I understand that "moving binding point of X from X/ to lib/X/" is not
representable within the index as a simple change. Is this the main issue
for your "against the whole git philosophy"?
I think it still is quite useful to put the binding point into bind lines of the
commit. Of course, moving a binding point has to go together with a new commit.
> 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/
What about putting $GITDIR/bind information directly into reference files?
$HOME/gitproj> cat .git/refs/heads/master
92347432598...
bind main=/
bind subpro=sub/
This way, you can rename/copy heads, and the binding info will stay with
the commit.
This also is nice for subprojects that do not need the bind lines, but similar
to current cogito subproject proposal:
92347432598...
main=/
subpro=sub/
would be the same superproject/subproject configuration without commiting
bind lines.
Josef
^ permalink raw reply
* Re: Remove "historical" objects from repository to save place
From: Andrey Borzenkov @ 2006-01-21 23:27 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20060121200615.GM28365@pasky.or.cz>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Saturday 21 January 2006 23:06, Petr Baudis wrote:
> 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?
this did not work for me, at least applied naively. May be, it is due to the
way I setup repository - first I created local version from 2.6.15 tree and
then pulled in remote one.
Anyway repacking and pruning resulted in over 500MB size reduction so its OK
for me so far. I'll probably try fetching cleanly later.
thank you and best regards
- -andrey
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFD0sN8R6LMutpd94wRAt1WAKC18LjAl+MbyfmvSvvNQGUF/mlbIgCfcu6s
nuZtYttRsd673Yqlq3aKr+A=
=B6jN
-----END PGP SIGNATURE-----
^ permalink raw reply
* 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
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