* Re: msysgit: does git gui work?
From: Steffen Prohaska @ 2007-08-09 21:23 UTC (permalink / raw)
To: Shawn O. Pearce, Johannes Schindelin; +Cc: Marius Storm-Olsen, Git Mailing List
In-Reply-To: <3CD6111C-13B5-444C-A28C-A7445C8A199B@zib.de>
On Aug 9, 2007, at 9:24 AM, Steffen Prohaska wrote:
> Does 'git gui' work for you in msysgit?
>
> I get
>
> Invalid command name "git-version"
> while executing
> "git-version >= 1.5.3"
> (in namespace eval "::blame" script line 36)
> [...]
>
> with msysgit (v1.5.3-rc2-690-g8ca1f6a)
Ok this is a bit complex but simple to solve: I created a
symlink from tclsh84.exe to tclsh.exe, that is
cd /mingw/bin
ln -s tclsh84.exe tclsh.exe
And than run
make install
[
offtopic:
I also hacked the Makefile to set GIT_VERSION to normal
version number, like 99.9, because git gui complained that
it failed to parse the version number.
I'll look into this later.
]
Now the long story.
mingw only contains tclsh84 but not tclsh. This causes
the Makefile in git-gui to fail on the creation of
lib/tclIndex. Therefore git gui decides to take the slow
path of sourcing the files in lib explicitly but this failes
because they are sourced before git-version is defined.
Therefore blame.tcl reports the error mentioned above.
Johannes (or someone else from the msysgit team),
We should modify mingw to contain the symlink to tclsh.
Or something similar, at least 'tclsh' should be there.
Shawn,
The fallback mechanism of sourcing files from lib is broken.
Either git-version must be defined before sourcing them, or
the auto_index must always work.
Steffen
^ permalink raw reply
* Re: 'pu' branch for StGIT
From: Catalin Marinas @ 2007-08-09 21:31 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Karl Hasselström, git, Yann Dirson
In-Reply-To: <1186665883.28228.31.camel@dv>
On 09/08/2007, Pavel Roskin <proski@gnu.org> wrote:
> On Thu, 2007-08-09 at 09:38 +0200, Karl Hasselström wrote:
>
> > I take it this all means you're actually using my branch? What's your
> > opinion on its usefulness?
>
> Well, I tried it, and then ran a script to update all local
> repositories. It converted everything to "version 3", so I'm sort of
> stuck with it. If the "version 3" code is not committed to the mainline
> StGIT, I'll have to convert my repositories back or even re-fetch them.
I'll merge many of Karl's patches for the next stable release (which I
hope to be sooner than the current 0.13) but I'm still on holiday for
one more week and can't do much work (busy with DIY).
Thanks to Karl for setting up this experimental branch. BTW, what does
'pu' mean?
--
Catalin
^ permalink raw reply
* Re: git and larger trees, not so fast?
From: Junio C Hamano @ 2007-08-09 21:37 UTC (permalink / raw)
To: Sean; +Cc: Linus Torvalds, moe, git
In-Reply-To: <20070809165218.9b76ebf7.seanlkml@sympatico.ca>
Sean <seanlkml@sympatico.ca> writes:
> This makes things _much_ better, however the final commit in the
> test script still shows a lot of user time:
I really do not have time to look into this for now until late
in the evening, but it is not surprising at all that per-path
partial commit is _always_ slower than the whole tree commit.
It simply needs to do _extra_ work, such as (1) re-initializing
a temporary index from the tree, (2) add the named entries to
that temporary index, and (3) add the same named entries to the
real index. After that it writes a tree out of the temporary
index but the cost for that is the same as writing out of the
real index that is done for the normal commit.
^ permalink raw reply
* Re: git and larger trees, not so fast?
From: Linus Torvalds @ 2007-08-09 21:41 UTC (permalink / raw)
To: Sean; +Cc: Junio C Hamano, moe, git
In-Reply-To: <20070809165218.9b76ebf7.seanlkml@sympatico.ca>
On Thu, 9 Aug 2007, Sean wrote:
>
> This makes things _much_ better, however the final commit in the
> test script still shows a lot of user time:
>
> ## time git commit -q -m 'buurrrrn' -a
> real 0m2.299s
> user 0m1.065s
> sys 0m1.317s
>
> ## time git commit -q -m 'hurry' 50/500
> real 0m16.944s
> user 0m15.466s
> sys 0m1.133s
In the case where we do a partial commit (never mind that it's all the
changes: when you give a path limiter, it's "partial"), "git commit" one
goes through another path, and triggers the same issue with
git read-tree --index-output=tmp-index -i -m HEAD
which has the same O(n**2) issue (except it uses "unpack_trees()" rather
than "read_tree()", so Junio's patch does nothing for it).
So "builtin-read-tree.c" (or rather unpack-trees.c) would need the same
kind of logic.
Linus
^ permalink raw reply
* Re: git and larger trees, not so fast?
From: Linus Torvalds @ 2007-08-09 21:46 UTC (permalink / raw)
To: Sean; +Cc: Junio C Hamano, moe, git
In-Reply-To: <alpine.LFD.0.999.0708091426050.25146@woody.linux-foundation.org>
On Thu, 9 Aug 2007, Linus Torvalds wrote:
>
> So "builtin-read-tree.c" (or rather unpack-trees.c) would need the same
> kind of logic.
The path seems to be:
cmd_read_tree ->
unpack_trees ->
unpack_trees_rec ->
[ recursive .. unpack_trees_rec ] ->
oneway_merge ->
keep_entry ->
add_index_entry()
and here again we end up having the same insertion sort issue.
Linus
^ permalink raw reply
* Re: git and larger trees, not so fast?
From: Junio C Hamano @ 2007-08-09 22:02 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Sean, moe, git
In-Reply-To: <alpine.LFD.0.999.0708091444550.25146@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Thu, 9 Aug 2007, Linus Torvalds wrote:
>>
>> So "builtin-read-tree.c" (or rather unpack-trees.c) would need the same
>> kind of logic.
>
> The path seems to be:
>
> cmd_read_tree ->
> unpack_trees ->
> unpack_trees_rec ->
> [ recursive .. unpack_trees_rec ] ->
> oneway_merge ->
> keep_entry ->
> add_index_entry()
>
> and here again we end up having the same insertion sort issue.
Quite honestly, I was this (shows the "thumb and index finger
almost touching" gesture) close to declare that unpack-trees is
unsalvageable, and was planning to redo the one-tree (and
perhaps two-tree) read-tree without using that mess after 1.5.3.
^ permalink raw reply
* Re: [PATCH] checkout-index needs a working tree
From: Uwe Kleine-König @ 2007-08-09 22:35 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: gitster, git
In-Reply-To: <Pine.LNX.4.64.0708042319470.14781@racer.site>
Johannes Schindelin wrote:
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>
> This fixes "git --work-tree=/some/where/else checkout-index".
>
> git.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/git.c b/git.c
> index 25b8274..f8c4545 100644
> --- a/git.c
> +++ b/git.c
> @@ -315,7 +315,8 @@ static void handle_internal_command(int argc, const char **argv)
> { "branch", cmd_branch, RUN_SETUP },
> { "bundle", cmd_bundle },
> { "cat-file", cmd_cat_file, RUN_SETUP },
> - { "checkout-index", cmd_checkout_index, RUN_SETUP },
> + { "checkout-index", cmd_checkout_index,
> + RUN_SETUP | NEED_WORK_TREE},
> { "check-ref-format", cmd_check_ref_format },
> { "check-attr", cmd_check_attr, RUN_SETUP | NEED_WORK_TREE },
> { "cherry", cmd_cherry, RUN_SETUP },
With this patch I'm not able to do
git checkout-index --prefix=/tmp/exportdir -a
to export an entire tree as described in git-checkout-index(1) in a bare
repo.
(Not that I need it, but I claimed on #git that it works, ... )
BTW: I didn't try if reverting this patch helps, but probably it does.
Best regards
Uwe
--
Uwe Kleine-König
http://www.google.com/search?q=72+PS+point+in+inch
^ permalink raw reply
* git and linux kernel source
From: Joe Perches @ 2007-08-09 23:11 UTC (permalink / raw)
To: git
A few linux kernel source and git questions:
What's the best procedure to handle a tree-wide source tranformation?
For instance:
git branch foo2bar
egrep -r -w --include=*.[ch] -l "foo" * | \
xargs perl -pi -e 's/\bfoo\b/bar/msg'
git commit -a -m "use bar not foo"
Is there a way to separate the resultant single patch into multiple
patches by subdirectory? Perhaps some git-rev-parse option?
git-format-patch -p --stat -o outputdir
Is there a way to automatically include the appropriate MAINTAINER and
mailing lists from the MAINTAINERS file for each subdirectory?
git-send-mail --to $APPROPRIATE_MAINTAINER \
-cc linux-kernel@vger.kernel.org
Any ideas or help?
^ permalink raw reply
* Re: git and linux kernel source
From: J. Bruce Fields @ 2007-08-09 23:17 UTC (permalink / raw)
To: Joe Perches; +Cc: git
In-Reply-To: <1186701106.3073.71.camel@localhost>
On Thu, Aug 09, 2007 at 04:11:46PM -0700, Joe Perches wrote:
> A few linux kernel source and git questions:
>
> What's the best procedure to handle a tree-wide source tranformation?
> For instance:
>
> git branch foo2bar
> egrep -r -w --include=*.[ch] -l "foo" * | \
> xargs perl -pi -e 's/\bfoo\b/bar/msg'
> git commit -a -m "use bar not foo"
> Is there a way to separate the resultant single patch into multiple
> patches by subdirectory? Perhaps some git-rev-parse option?
Something like
for each sub/dir:
git add sub/dir
git commit -m "use bar not foo in sub/dir"
should do it. (Of course, in the particular case above the patches you
ended up with probably wouldn't compile individually.)
--b.
^ permalink raw reply
* Re: git and larger trees, not so fast?
From: Junio C Hamano @ 2007-08-09 23:38 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Sean, moe, git
In-Reply-To: <7vtzr8wemb.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
>> On Thu, 9 Aug 2007, Linus Torvalds wrote:
>>>
>>> So "builtin-read-tree.c" (or rather unpack-trees.c) would need the same
>>> kind of logic.
>>
>> The path seems to be:
>>
>> cmd_read_tree ->
>> unpack_trees ->
>> unpack_trees_rec ->
>> [ recursive .. unpack_trees_rec ] ->
>> oneway_merge ->
>> keep_entry ->
>> add_index_entry()
>>
>> and here again we end up having the same insertion sort issue.
>
> Quite honestly, I was this (shows the "thumb and index finger
> almost touching" gesture) close to declare that unpack-trees is
> unsalvageable, and was planning to redo the one-tree (and
> perhaps two-tree) read-tree without using that mess after 1.5.3.
While I do not think the previous one was hacky at all, this one
IS a hack, not meant for inclusion. It makes the partial commit
codepath to use vanilla "git read-tree" without any single tree
merge semantics, and rewrite that codepath to use read_tree()
which was changed with my previous patch.
---
builtin-read-tree.c | 5 ++++-
git-commit.sh | 2 +-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/builtin-read-tree.c b/builtin-read-tree.c
index a3b17a3..61ea15c 100644
--- a/builtin-read-tree.c
+++ b/builtin-read-tree.c
@@ -258,7 +258,10 @@ int cmd_read_tree(int argc, const char **argv, const char *unused_prefix)
opts.head_idx = 1;
}
- unpack_trees(trees, &opts);
+ if (!opts.merge && !opts.prefix && trees && !trees->next)
+ read_tree((struct tree*) trees->item, 0, NULL);
+ else
+ unpack_trees(trees, &opts);
/*
* When reading only one tree (either the most basic form,
diff --git a/git-commit.sh b/git-commit.sh
index d7e7028..b50468f 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -386,7 +386,7 @@ t,)
if test -z "$initial_commit"
then
GIT_INDEX_FILE="$THIS_INDEX" \
- git read-tree --index-output="$TMP_INDEX" -i -m HEAD
+ git read-tree --index-output="$TMP_INDEX" HEAD
else
rm -f "$TMP_INDEX"
fi || exit
^ permalink raw reply related
* Problem with http-repos vs filesys-remote-repos
From: Evan Carroll @ 2007-08-09 23:40 UTC (permalink / raw)
To: git
A disclaimer:: I could have mucked with anything, I will not place the
blame on git as if I had strictly adhered to the tutorial
instructions. Anything I did was through the UI, there was no mucking
with files. Thanks in advance and good luck:
I have one repos located on /var/git/scraper.git, it houses a
small-inhouse project which I'm trying to use to sell git with.
Unfortunately, I've had a very difficult time doing everything with
git. Namely, pulling and pushing. It appears as if I git-clone this
using the file-system (fs) addressing I get a repos which `git log`
shows was last modified on Aug 9th. However, if I check this out with
a git-clone using apache, which is simply hosting
/var/git/scraper.git, I get a repos which was last updated on aug 7th
- thus it is missing *a lot* of devel time. Now the 7th was when I
created the --bare repos from my working directory git. All of the
gits involved are using the latest stable version 1.5.2.4, they all
built cleanly. The log is as follows:
AUG 7TH LAST COMMIT SHOWN WITH `git log`
ecarroll@x60s:~/git_clone$ git-clone "http://localhost:8080/scraper.git"
Initialized empty Git repository in /home/ecarroll/git_clone/test2/.git/
Getting alternates list for http://localhost:8080/scraper.git
Getting pack list for http://localhost:8080/scraper.git
Getting index for pack e1abd952a37bfe85805996e69bee52a2c6ca8b5e
Getting pack e1abd952a37bfe85805996e69bee52a2c6ca8b5e
which contains b7aa242f4934d8fd0fbd46f1da6ed6a9b067c7fd
walk b7aa242f4934d8fd0fbd46f1da6ed6a9b067c7fd
walk 03e5aa7139b0bac0d8ba0172deea269e9ae260d8
walk 440123ec8cc4914b01cefbb47becb17f323d5be0
walk 80bbe821fba30e0c441488b8587c76d4b158b419
walk 43a52216c1a257e167f07d8d3f6a21f4b7ca2e7d
walk d60274e965eee8ad4621297681a3fbfa34b5bf94
walk e2bbe073669dee862f0952b8b270109604c0ecb4
walk 8274ce6c3bfa09b61b5552aa37192bcfaff6c365
walk 4d4a5169d50e0311eb8e040e81d4a5ee169e571e
walk d19088ace71dd6253b9375fcc255aad562617215
walk f41ecbd9bcd77f752c580e7ea817932aee4c3a67
walk 3ca0832b9f3749358bf38362c682eb65d1178f06
walk a01f7090894aeb68c53a31aa47d829857b8941f8
walk 802e9e5da7500e009a60b3474b8810ce2e8919f6
walk a785f5356f04989d5e5f377b47ce511838966801
walk ec139d2ed248c4ac1cb9ac212de340beec5b98d0
walk 505070b2e973344d68167fa74b7d0677e696389f
walk d15f3cc11d321f85d7171370d39a6e1c84c9d404
walk 3c49542c1e792dafdb3550646112761405d2228c
walk abd521924488a67aedb7fb04b4c125419aac4b31
walk fcf61439f3e8b9056820f4c645e2b0708909a49b
walk 5b9403e4ce6a99fd796ee6431e046401b4f22654
walk 346efee6bc1b5b040f7f3216fb797b7fe47169f4
walk 907c664f95a67f543318c9d98c77afad6a42cde6
walk c7400a750462b74f7e3ca38944e99c1bad0ffb40
walk 00cf9ba3c7b1bef826f798872abfe0f6ae2c88cf
walk 7a11ff1ca92714502619e1efab81d010660f1d3a
walk a85d4c191b625c540aa7c6404d3a4077e40c54ad
walk a1f168e39b561e715ea211c816681ac9d3bb723b
walk 2b7d935254f3dd96c0ed9917ba9eeb4ebb6a435e
walk 142ebf8d6db33be291979763eb1c5ad148efd52a
walk 9c567513df3e1cde356a8b481ddc48427676a9cf
walk 058ce00fc69ec1c220cee1a6d1cd4a1dbf7ccf8d
walk bcffa5ee33a03021b15351275349003ebdf3b4c9
walk cb7085573783e385333c1e6fdda23abc98a1b4b5
walk c270169aa2031abb0baeedfe6b518482ec5fd6ab
walk 8399e6433890370194d63572ba94b9a211238d72
walk cc04ae74ce1c2f7430d4eed7b8ce8a46e8f0e04c
walk 6e9b3fb69d0fdd7f6d4c9184a4ed46713d685d30
walk 99b6b4627d9cebcb616d33956bd80f3756336985
walk b253c3ca8fb18c4e9a151a00ededa98300eb8ff0
walk cd2f1f880ad3f0771e4458d62d2add8cad1251bb
walk c4ef38a70079ba6408345ffccace89863f994220
walk de21695739e313a6eba9e67965b91dbbabde4455
walk dfa6f513114a67f873e1a8304b51110f3a5e4861
walk 17c9e0b434ab918dc566049115a522cbdf3f1686
walk 90f1cb3e801d54ebcc6fb9d6bb7ddf1df1ba0cca
walk d3da5763afbc5c22f2a69a4040ae4c7203c061ce
walk 07b5c81f66dbc025e22e51feb1911088b50e6eea
walk 29b78272554de6a2565ff392bd9f3d3c123e805d
walk 75721e0ce144d90f97bbd48663263da9a6ef9366
walk b4604048a6c0208288a2468de98e12500c7e1fc3
walk 132777acf1b8770774c3efb3a4783a575f8d013f
walk a1095219e06b9b62bb5e06338146bfe97719bd32
walk 2e625354fce8384bad459a26ec27e841ecd63609
walk be9e8d9233171bbd86a3dc473238bc86c2766567
walk d0ec8e0706f11fc0fb942e34d4f4fec338870a79
walk 6d4a3791943549d59f31a04b6d328d466d1ab554
walk 2a8eba32ae6a0d2b826dc3dd4c4a555b550b939e
walk 7fdbe0eb9806bc76d9f55527a83d4f0005502b28
walk fca1be7a710df50aeb86545348d859021adc2e29
walk 60eb65a60345727a3215c579d836d1e6ca6977f4
walk 2fea2cd7474131af90d791331dfe45f711711794
walk 7da3e7bc32ca0019bff07d5339504997ec711a06
walk 0647f6f9c1b2f9e09dbd26dd4f8e8c270cdda715
AUG 9TH LAST COMMIT SHOWN WITH `git log`.
ecarroll@x60s:~/git_clone$ git-clone /var/git/scraper.git/ ./test1
Initialized empty Git repository in /home/ecarroll/git_clone/test1/.git/
remote: Generating pack...
remote: Done counting 384 objects.
remote: Deltifying 384 objects...
Indexing 384 objects... done
remote: 00% (384/384) donene
Total 384 (delta 173), reused 359 (delta 157)
100% (384/384) done
Resolving 173 deltas...
100% (173/173) done
While you are chewing on that there are two things I want to see done
to the UI (my wishlist)::
more serious error messages -- they are so far off as is, if someone
could patch just the simple `git-clone` to error more intelligently if
it isn't addressed to the .git directory!! If someone hosts there WD
on a webhost, they intuitively think they should (i did) clone it by
addressing the curdir, and not the './.git', the undescriptive error
message stings.
"Perhaps git-update-server-info needs to be run there?" needs to be
accompinied by a more logical newbieish error of the sort "Are you
targetting the working directory."
My second complaint is everything reporting it is "up to date." If
everything is up to date say "everything", if both things are mimicked
the pedagogic term is "synchronized", if the repos isn't totally
synced, then tell me what you have updated/merged and where you put
what you received!
ecarroll@x60s:~/git_clone$ diff <(find ./test1 -printf "\n%f") <(find
./test2 -printf "\n%f" )
2c2
< test1
---
> test2
9a10
> Moose-extends
29,30c30,31
< pack-183aa1d0a0a7db1c379268003d9a1ad64ddb9063.pack
< pack-183aa1d0a0a7db1c379268003d9a1ad64ddb9063.idx
---
> pack-e1abd952a37bfe85805996e69bee52a2c6ca8b5e.idx
> pack-e1abd952a37bfe85805996e69bee52a2c6ca8b5e.pack
31a33
> b7
35a38
> Moose-extends
55d57
< CSV.pm
Please cc me in all responses me@evancarroll.com
--
Evan Carroll
System Lord of the Internets
me@evancarroll.com
832-445-8877
^ permalink raw reply
* Re: [PATCH] git-merge: do up-to-date check also for strategies ours, subtree.
From: Jeff King @ 2007-08-10 0:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Gerrit Pape, git
In-Reply-To: <7v3aysxvk3.fsf@assigned-by-dhcp.cox.net>
On Thu, Aug 09, 2007 at 02:11:24PM -0700, Junio C Hamano wrote:
> Right now I do not have time to dig mailing list archive around
> mid March 2006, and I do not recall the requestor's original
> rationale, but I have a vague recollection that we added this
> "no fast-forward check" specifically in response to a user
> request.
Maybe it was the "I'm using a custom merge strategy that might refuse
the merge, but fast-forwards don't even invoke my merge strategy"
request?
-Peff
^ permalink raw reply
* Re: git and larger trees, not so fast?
From: Junio C Hamano @ 2007-08-10 0:04 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Sean, moe, git
In-Reply-To: <7vps1wwa5w.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> While I do not think the previous one was hacky at all, this one
> IS a hack, not meant for inclusion. It makes the partial commit
> codepath to use vanilla "git read-tree" without any single tree
> merge semantics, and rewrite that codepath to use read_tree()
> which was changed with my previous patch.
Just in case anybody is wondering, this also passed all the
existing tests. Maybe it is going in the right direction of
slowly moving away from unpack_trees() where we can. I dunno.
I also do not know if it "fixes" the performance issue on that
testcase.
^ permalink raw reply
* Re: Problem with http-repos vs filesys-remote-repos
From: Julian Phillips @ 2007-08-10 0:04 UTC (permalink / raw)
To: Evan Carroll; +Cc: git
In-Reply-To: <428b865e0708091640x715a5950x128da5da493cef2@mail.gmail.com>
On Thu, 9 Aug 2007, Evan Carroll wrote:
> A disclaimer:: I could have mucked with anything, I will not place the
> blame on git as if I had strictly adhered to the tutorial
> instructions. Anything I did was through the UI, there was no mucking
> with files. Thanks in advance and good luck:
>
> I have one repos located on /var/git/scraper.git, it houses a
> small-inhouse project which I'm trying to use to sell git with.
> Unfortunately, I've had a very difficult time doing everything with
> git. Namely, pulling and pushing. It appears as if I git-clone this
> using the file-system (fs) addressing I get a repos which `git log`
> shows was last modified on Aug 9th. However, if I check this out with
> a git-clone using apache, which is simply hosting
> /var/git/scraper.git, I get a repos which was last updated on aug 7th
> - thus it is missing *a lot* of devel time. Now the 7th was when I
> created the --bare repos from my working directory git. All of the
> gits involved are using the latest stable version 1.5.2.4, they all
> built cleanly. The log is as follows:
Have you enabled the post-update hook on your server (chmod +X
/var/git/scraper.git/hooks/post-update)? You need to run "git
update-server-info" after updating a repo to allow clones via http to work
properly. The default post-update hook does this for you.
--
Julian
---
No, I do not know what the Schadenfreude is. Please tell me, because
I'm dying to know.
-- Homer Simpson
When Flanders Failed
^ permalink raw reply
* Re: [PATCH] Documentation/git-svn: Instructions for cloning a git-svn-created repository
From: Steven Grimm @ 2007-08-10 0:13 UTC (permalink / raw)
To: Eric Wong; +Cc: Adam Roben, git, Junio C Hamano, Shawn O. Pearce
In-Reply-To: <20070809193759.GA4545@untitled>
Eric Wong wrote:
> I personally believe using rsync to clone repositories created with
> git-svn is the simplest and best method for now.
But then you don't get to use alternates -- one of the things I like
about the idea of doing a "git clone" of a git-svn repository is that
you could do "git clone -s" and get the full svn history with a tiny
.git directory.
-Steve
^ permalink raw reply
* Re: 'pu' branch for StGIT
From: Karl Hasselström @ 2007-08-10 0:30 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Pavel Roskin, git, Yann Dirson
In-Reply-To: <b0943d9e0708091431k57ac095asa940cca73ad95b13@mail.gmail.com>
On 2007-08-09 22:31:09 +0100, Catalin Marinas wrote:
> I'll merge many of Karl's patches for the next stable release (which
> I hope to be sooner than the current 0.13) but I'm still on holiday
> for one more week and can't do much work (busy with DIY).
Great! Would you like me to select the "safe" topics and give you a
single integration branch to pull, or do you want to be the one that
does the selecting?
> Thanks to Karl for setting up this experimental branch. BTW, what
> does 'pu' mean?
Proposed Updates, as I recall. But I just used that to explain how my
branch is going to behave (meaning: it'll behave like Junio's pu
branch); it isn't actually called "pu". Not so pedagogical if no one
has heard of Junio's pu branch, I guess. :-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] checkout-index needs a working tree
From: Johannes Schindelin @ 2007-08-10 0:31 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: gitster, git
In-Reply-To: <20070809223530.GA29680@cassiopeia>
Hi,
On Fri, 10 Aug 2007, Uwe Kleine-K?nig wrote:
> Johannes Schindelin wrote:
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> >
> > This fixes "git --work-tree=/some/where/else checkout-index".
> >
> > git.c | 3 ++-
> > 1 files changed, 2 insertions(+), 1 deletions(-)
> >
> > diff --git a/git.c b/git.c
> > index 25b8274..f8c4545 100644
> > --- a/git.c
> > +++ b/git.c
> > @@ -315,7 +315,8 @@ static void handle_internal_command(int argc, const char **argv)
> > { "branch", cmd_branch, RUN_SETUP },
> > { "bundle", cmd_bundle },
> > { "cat-file", cmd_cat_file, RUN_SETUP },
> > - { "checkout-index", cmd_checkout_index, RUN_SETUP },
> > + { "checkout-index", cmd_checkout_index,
> > + RUN_SETUP | NEED_WORK_TREE},
> > { "check-ref-format", cmd_check_ref_format },
> > { "check-attr", cmd_check_attr, RUN_SETUP | NEED_WORK_TREE },
> > { "cherry", cmd_cherry, RUN_SETUP },
> With this patch I'm not able to do
>
> git checkout-index --prefix=/tmp/exportdir -a
>
> to export an entire tree as described in git-checkout-index(1) in a bare
> repo.
That is _completely_ expected. If it is a bare repository, you can _only_
override that check by GIT_WORK_TREE or --work-tree.
But I have to wonder: if you want to use git checkout-index, which is a
work-tree operation, why did you mark it as bare to begin with?
Ciao,
Dscho
^ permalink raw reply
* Re: git and larger trees, not so fast?
From: Linus Torvalds @ 2007-08-10 0:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sean, moe, git
In-Reply-To: <7vps1wwa5w.fsf@assigned-by-dhcp.cox.net>
On Thu, 9 Aug 2007, Junio C Hamano wrote:
>
> While I do not think the previous one was hacky at all, this one
> IS a hack, not meant for inclusion.
Ugh.
I had some time, so I tried to find out *why* that thing is so slow.
The fact is, "git read-tree -m HEAD" should be really really fast, because
it should never actually insert multiple entries into the same index
entry: it should just _replace_ the entry.
But why is it slow?
It doesn't actually replace the entry with "add_cache_entry()" at all.
What it does is to *remove* the entry entirely at unpack-trees.c, line
154, unpack_trees_rec(), which does a "remove_cache_entry_at(o->pos);".
That causes us to have to condense the index array, and is one big
memcpy() for a large index.
It then ADDS THE NEW ENTRY BACK! Which causes *another* expensive index
array memmove(), as it now needs to make room (at the same location that
it just compacted).
Sadly, that removal is required for some of the other cases, so it's not
like we can remove the remove. But we could *possibly* make things
ridiculously much faster by making the remove a lazy thing, and if the
next index operation just adds it back in, we wouldn't move things around.
A bit too subtle for my taste.
Linus
^ permalink raw reply
* Re: git and larger trees, not so fast?
From: Junio C Hamano @ 2007-08-10 0:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Sean, moe, git
In-Reply-To: <alpine.LFD.0.999.0708091734210.25146@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Thu, 9 Aug 2007, Junio C Hamano wrote:
>>
>> While I do not think the previous one was hacky at all, this one
>> IS a hack, not meant for inclusion.
> ...
> Sadly, that removal is required for some of the other cases, so it's not
> like we can remove the remove. But we could *possibly* make things
> ridiculously much faster by making the remove a lazy thing, and if the
> next index operation just adds it back in, we wouldn't move things around.
Heh, that makes the two of us. I have been wanting to revamp or
kill off unpack-trees for quite some time, and after all the
patch you are responding to might be a small first step in the
right direction ;-).
^ permalink raw reply
* Re: [PATCH] checkout-index needs a working tree
From: Junio C Hamano @ 2007-08-10 0:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Uwe Kleine-König, git
In-Reply-To: <Pine.LNX.4.64.0708100129200.21857@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> That is _completely_ expected. If it is a bare repository, you can _only_
> override that check by GIT_WORK_TREE or --work-tree.
>
> But I have to wonder: if you want to use git checkout-index, which is a
> work-tree operation, why did you mark it as bare to begin with?
I do not necessarily think --prefix=untar/it/here/ is a work
tree operation.
Perhaps we probably are better off if we add something that says
specifying GIT_DIR alone means you are at the top of work tree
(to resurrect the traditional behaviour), to alleviate fallouts
like this and the other cvsserver one? If one does not like
that traditional behaviour, the new GIT_WORK_TREE support can
be used override it.
^ permalink raw reply
* Re: git and larger trees, not so fast?
From: Linus Torvalds @ 2007-08-10 0:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sean, moe, git
In-Reply-To: <7vhcn8w6sw.fsf@assigned-by-dhcp.cox.net>
On Thu, 9 Aug 2007, Junio C Hamano wrote:
>
> Heh, that makes the two of us. I have been wanting to revamp or
> kill off unpack-trees for quite some time, and after all the
> patch you are responding to might be a small first step in the
> right direction ;-).
Well, the patch you sent out was not only hacky, it was kind of pointless.
Without the "-m" handling, it means that most users of git-read-tree won't
ever see the improvement. The merge with the old index is absolutely
critical for things like switching branches, for example. And I think you
probably screwed up performance with your change to git-commit to simply
not use it, because now the resulting index will be totally stale, and
while the *commit* may be fast as a result, the subsequent operations
might be horrible.
(I didn't test it, though, maybe I missed something).
So I do think that things like "git checkout <otherbranch>" need to have a
fully working (and fast) unpack-trees, and your hack doesn't really help
except for a pretty uninteresting special case.
Linus
^ permalink raw reply
* Re: [PATCH] checkout-index needs a working tree
From: Johannes Schindelin @ 2007-08-10 1:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Uwe Kleine-König, git
In-Reply-To: <7vd4xww6mr.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 9 Aug 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > That is _completely_ expected. If it is a bare repository, you can _only_
> > override that check by GIT_WORK_TREE or --work-tree.
> >
> > But I have to wonder: if you want to use git checkout-index, which is a
> > work-tree operation, why did you mark it as bare to begin with?
>
> I do not necessarily think --prefix=untar/it/here/ is a work
> tree operation.
>
> Perhaps we probably are better off if we add something that says
> specifying GIT_DIR alone means you are at the top of work tree
> (to resurrect the traditional behaviour), to alleviate fallouts
> like this and the other cvsserver one? If one does not like
> that traditional behaviour, the new GIT_WORK_TREE support can
> be used override it.
I think I sent a patch for that, but was negative about it, even if I
promised not to question your decision.
Ciao,
Dscho
^ permalink raw reply
* Re: git and larger trees, not so fast?
From: Daniel Barkalow @ 2007-08-10 1:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Sean, moe, git
In-Reply-To: <7vtzr8wemb.fsf@assigned-by-dhcp.cox.net>
On Thu, 9 Aug 2007, Junio C Hamano wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
> > On Thu, 9 Aug 2007, Linus Torvalds wrote:
> >>
> >> So "builtin-read-tree.c" (or rather unpack-trees.c) would need the same
> >> kind of logic.
> >
> > The path seems to be:
> >
> > cmd_read_tree ->
> > unpack_trees ->
> > unpack_trees_rec ->
> > [ recursive .. unpack_trees_rec ] ->
> > oneway_merge ->
> > keep_entry ->
> > add_index_entry()
> >
> > and here again we end up having the same insertion sort issue.
>
> Quite honestly, I was this (shows the "thumb and index finger
> almost touching" gesture) close to declare that unpack-trees is
> unsalvageable, and was planning to redo the one-tree (and
> perhaps two-tree) read-tree without using that mess after 1.5.3.
Yeah, that's probably the right thing to do; I wrote it with the idea that
we'd be doing many-parent merges with it, but merge-recursive turned out
to be a better idea, so I designed it to be comprehensible for a
complicated case we never actually do.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] Documentation/git-svn: Instructions for cloning a git-svn-created repository
From: Eric Wong @ 2007-08-10 1:43 UTC (permalink / raw)
To: Steven Grimm; +Cc: Adam Roben, git, Junio C Hamano, Shawn O. Pearce
In-Reply-To: <46BBADBB.6070502@midwinter.com>
Steven Grimm <koreth@midwinter.com> wrote:
> Eric Wong wrote:
> >I personally believe using rsync to clone repositories created with
> >git-svn is the simplest and best method for now.
>
> But then you don't get to use alternates -- one of the things I like
> about the idea of doing a "git clone" of a git-svn repository is that
> you could do "git clone -s" and get the full svn history with a tiny
> .git directory.
If I'm working on multiple directories on the same machine, I have
libflcow in my LD_PRELOAD and use cp -al (GNU-specific) to make hardlink
images of my working directory. I've been using fl-cow with cp -al
since long before I used git.
The new-ish git-new-workdir command could probably be a replacement
for git-clone / flcow + cp -al / rsync in these situations as well.
--
Eric Wong
^ permalink raw reply
* Re: git and linux kernel source
From: Joe Perches @ 2007-08-10 1:59 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git
In-Reply-To: <20070809231718.GH12875@fieldses.org>
On Thu, 2007-08-09 at 19:17 -0400, J. Bruce Fields wrote:
> > Is there a way to separate the resultant single patch into multiple
> > patches by subdirectory? Perhaps some git-rev-parse option?
> Something like
> for each sub/dir:
> git add sub/dir
> git commit -m "use bar not foo in sub/dir"
> should do it. (Of course, in the particular case above the patches you
> ended up with probably wouldn't compile individually.)
Nor would it likely survive a git bisect, but it's a start.
My goal is to eventually commit by maintainer.
Thanks, Joe
^ 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