[EMAIL PROTECTED] (Eric W. Biederman) writes:
> This patch adds a command git-id for use on
> the command line to see what git will set your id too,
> and for use in scripts (git-tag-script) so they can get your git id.
>
> The common code for computing the git-id is moved to ident.c
>
> Fix parse
Hi, Marc Singer wrote:
> v2.6.11, 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c
You can create your own parent-less commit for that tree.
(It's what I did...)
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://sm
* Petr Baudis ([EMAIL PROTECTED]) wrote:
> here is Cogito 0.12.1, another desperate attempt to keep pace with
> '@' or Linus, the named Human Master Coder. (Linus, the Human Master
> Coder, mumbles arcane do { formulae } while (0)! Some kind of force
> seems to attack your mind. Everything sudd
# git-diff-cache HEAD
is really nice. But, do I really have to invoke git-update-cache with
every modified file? I could write a script to cul the filenames from
git-diff-cache, but I'm having a hard time believing that that is how
others are preparing their commits.
-
To unsubscribe from this
On Mon, Jul 11, 2005 at 09:59:25PM -0700, Linus Torvalds wrote:
>
>
> On Mon, 11 Jul 2005, Marc Singer wrote:
> >
> > Does it make sense to think about this branch as an flow of commits?
> > Or is it just a starting point for a line of development?
>
> It's really a flow of commits. Nothing wil
I switched to using the git version in source control.
Checkout/branching works great. :-)
But, this version of git doesn't let me do
# git checkout -f v2.6.11
error: Object 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is a tree, not a commit
Needed a single revision
which I suspect is protec
On Mon, 11 Jul 2005, Marc Singer wrote:
>
> Does it make sense to think about this branch as an flow of commits?
> Or is it just a starting point for a line of development?
It's really a flow of commits. Nothing will ever really remember what the
starting point was at some later date if you ha
On Mon, 11 Jul 2005, Eric W. Biederman wrote:
>
> Looking closer it appears that commit_list_insert is recursive
> and that is what I missed.
Actually, it's "pop_most_recent_commit()" that ends up being the
"recursive" part: it will pop the top-most entry, but as it is popping it
it will push
On Mon, Jul 11, 2005 at 09:34:33PM -0700, Linus Torvalds wrote:
>
>
> On Mon, 11 Jul 2005, Linus Torvalds wrote:
> >
> > Of course, if you want to create a new branch "my-branch" and _not_
> > check it out, you could have done so with just
> >
> > git-rev-parse v2.6.12^0 > .git/
This patch adds a command git-id for use on
the command line to see what git will set your id too,
and for use in scripts (git-tag-script) so they can get your git id.
The common code for computing the git-id is moved to ident.c
Fix parse_date to not mind being passed a constant date
to parse.
On Mon, 11 Jul 2005, Linus Torvalds wrote:
>
> Of course, if you want to create a new branch "my-branch" and _not_
> check it out, you could have done so with just
>
> git-rev-parse v2.6.12^0 > .git/refs/heads/my-branch
>
> which I think I will codify as "git branch".
And
On Mon, Jul 11, 2005 at 08:41:43PM -0700, Junio C Hamano wrote:
> When I start working on something I often do not know what the
> thing I am going to work on ends up to be. So I would start
> from v2.6.12 tag, do random hacking, and when I got into a
> reasonable shape, I would say ``Ok, this is
On Mon, 11 Jul 2005, Junio C Hamano wrote:
>
> I do not quite follow your objections. I do not think I am
> forcing anybody to name an old thing.
Sure you are. You're forcing them to make a choice, where both choices
are bad. Either:
- name an old thing (that you may not even have worked on
On Mon, 11 Jul 2005, Linus Torvalds wrote:
> On Mon, 11 Jul 2005, Marc Singer wrote:
> >
> > From my POV, what I want is a branch with the tag v2.6.12 as the basis
> > of the branch. I'm guessing that -b means "make me a branch and call
> > it this".
>
> Yup. That would be the interface.
>
>
Linus Torvalds <[EMAIL PROTECTED]> writes:
> So at least to me it makes much more sense to say "ok, I'll start
> something new, and call it xyzzy", than "ok, I'll start something new, and
> I'll save the old under 'old'".
>
> The "old" thing might not even be anything you worked on (it might be
>
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Mon, 11 Jul 2005, Eric W. Biederman wrote:
>>
>> The question:
>> Does git-upload-pack which gets it's list of objects
>> with "git-rev-list --objects needed1 needed2 needed3 ^has1 ^has2 ^has3"
>> get any history beyond the top of tree of each branc
On Mon, 11 Jul 2005, Junio C Hamano wrote:
>
> > Opinions?
>
> How about treating "master" a temporary thing --- "whatever I
> happen to be working on right now"?
I'd not mind with this in theory, but it has the fundamental problem that
we can end up losing sight of commits we have, and then h
On Mon, 11 Jul 2005, Eric W. Biederman wrote:
>
> The question:
> Does git-upload-pack which gets it's list of objects
> with "git-rev-list --objects needed1 needed2 needed3 ^has1 ^has2 ^has3"
> get any history beyond the top of tree of each branch.
>
> As I read the code it does not.
It d
On Mon, 11 Jul 2005, Marc Singer wrote:
>
> From my POV, what I want is a branch with the tag v2.6.12 as the basis
> of the branch. I'm guessing that -b means "make me a branch and call
> it this".
Yup. That would be the interface.
> # git checkout -b BRANCH_NAME [TAG]
>
> If the TAG is omi
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Mon, 11 Jul 2005, Eric W. Biederman wrote:
>>
>> Actually I was looking at doing a git-ident thing that will
>> just compute who git thinks you are. And then git-commit-tree can
>> just popen it to share code. That looks like how the logic has
>>
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Mon, 11 Jul 2005, Eric W. Biederman wrote:
>> > So if you only get one branch, it will leave the objects that are specific
>> > to other branches alone.
>>
>> Hmm. As I recall reading the code it grabs everything that is
>> in .git/refs/*.
>
> Onl
Linus Torvalds <[EMAIL PROTECTED]> writes:
> But what about the branch name? Should we just ask the user? Together with
> a flag, like
>
> git checkout -b new-branch v2.6.12
>
> for somebody who wants to specify the branch name? Or should we pick a
> random name and add a helper function t
On Mon, Jul 11, 2005 at 06:43:23PM -0700, Linus Torvalds wrote:
>
>
> On Mon, 11 Jul 2005, Linus Torvalds wrote:
> >
> > No, git-checkout-script _shouldn't_ have done that. It will do the
> > read-tree on the tag (which will do the right thing), but it won't change
> > the HEAD itself.
>
> In
On Mon, 11 Jul 2005, Darrin Thompson wrote:
> On Sun, 2005-07-10 at 15:56 -0400, Daniel Barkalow wrote:
> > + curl_easy_setopt(curl, CURLOPT_FILE, indexfile);
> > + curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, fwrite);
> > + curl_easy_setopt(curl, CURLOPT_URL, url);
>
> I was hoping to sen
On Mon, 11 Jul 2005, Linus Torvalds wrote:
>
> No, git-checkout-script _shouldn't_ have done that. It will do the
> read-tree on the tag (which will do the right thing), but it won't change
> the HEAD itself.
In preparation of actually updating the HEAD, I just made "git checkout"
verify that
On Mon, 11 Jul 2005, Eric W. Biederman wrote:
>
> Actually I was looking at doing a git-ident thing that will
> just compute who git thinks you are. And then git-commit-tree can
> just popen it to share code. That looks like how the logic has
> been accomplished in other places.
I hate popen(
On Mon, 11 Jul 2005, Eric W. Biederman wrote:
>
> Ok. Only the dumb methods are allowed.
Well, no, you can actually do git-clone-pack by hand in that git archive,
and it will use the smart packing to get the other end, even if it is
totally unrelated to the current project.
But you have to do
On Mon, 11 Jul 2005, Junio C Hamano wrote:
>
> - we allow git-checkout-script with a tag; I think we store the tag
>object without dereferencing in .git/HEAD;
No, git-checkout-script _shouldn't_ have done that. It will do the
read-tree on the tag (which will do the right thing), but it wo
Hello,
here is Cogito 0.12.1, another desperate attempt to keep pace with
'@' or Linus, the named Human Master Coder. (Linus, the Human Master
Coder, mumbles arcane do { formulae } while (0)! Some kind of force
seems to attack your mind. Everything suddenly looks so different...
You are conf
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Mon, 11 Jul 2005, Eric W. Biederman wrote:
>
>> Are you still up for a patch that records who and when made a tag?
>> I sent one but it seems to have been lost.
>
> I'd really actually prefer for the code to be shared with the commit code,
> so that
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Mon, 11 Jul 2005, Eric W. Biederman wrote:
>>
>> A couple of pieces. The dist target has assumes git-tar-tree is in the
>> path. Making it so you have to have git installed to build the rpm.
>
> Yes. Maybe we could relax that requirement by using
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Mon, 11 Jul 2005, Eric W. Biederman wrote:
>>
>> I guess I was expecting to pull from one tree into another unrelated
>> tree. Getting a tree with two heads and then be able to merge them
>> together.
>
> You can do it, but you have to do it by han
Dear diary, on Fri, Jul 08, 2005 at 01:00:55AM CEST, I got a letter
where Wolfgang Denk <[EMAIL PROTECTED]> told me that...
> Hello,
Hello,
> I have problems with Cogito-0.12 when trying to clone a "local" tree:
sorry for the late reply.
> When I try to create a local clone I get lots of error
This is leftover from early naming, and is no longer relevant.
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
diff --git a/cogito.spec.in b/cogito.spec.in
--- a/cogito.spec.in
+++ b/cogito.spec.in
@@ -7,7 +7,6 @@ License:GPL
Group: Development/Tools
URL: h
Dear diary, on Mon, Jul 11, 2005 at 10:44:45PM CEST, I got a letter
where Marc Singer <[EMAIL PROTECTED]> told me that...
> It complained when I cloned across devices.
>
> `/git/cogito/.git/refs/tags/cogito-0.8' -> `.git/refs/tags/cogito-0.8'
> cp: cannot create link `.git/refs/tags/cogito-0
On Tue, 2005-07-12 at 01:31 +0200, Petr Baudis wrote:
> But if the depth will be less than that, won't the user end up with some
> (plenty) of the objects duplicated?
Some, yes, many, no. It's pretty easy to tune how many, afaict.
-t
-
To unsubscribe from this list: send the line "unsubs
Linus Torvalds <[EMAIL PROTECTED]> wrote:
> On Mon, 11 Jul 2005, Eric W. Biederman wrote:
> > A couple of pieces. The dist target has assumes git-tar-tree is in the
> > path. Making it so you have to have git installed to build the rpm.
> Yes. Maybe we could relax that requirement by using "./gi
On Mon, 11 Jul 2005, Bryan Larsen wrote:
>
> >
> > Most everything includes git-sh-setup-script anyway by now.
> >
> > However, what are the features that break the default apple tools anyway?
> > Maybe we should avoid using them? OSX clearly comes with "cp" and "xargs"
> > regardless, what
On Mon, 11 Jul 2005, Linus Torvalds wrote:
>
>
> On Mon, 11 Jul 2005, Daniel Barkalow wrote:
> > On Sun, 10 Jul 2005, Linus Torvalds wrote:
> >
> > >
> > > You really _mustn't_ try to create the pack directly to the
> > > $GIT_DIR/objects/pack subdirectory - that would make git itself start
>
Bryan Larsen <[EMAIL PROTECTED]> writes:
> Last night, I couldn't think of alternatives to these, but I obviously
> didn't try very hard. xargs -r can probably happen via a temporary
> file and cp -u can probably be simulated using rsync.
The only user of "xargs -r" in the Linus GIT is git-prune
The only user of "cp -l" in the Linus GIT is git-clone-script
local optimization. I could revert it to the version that I
originally sent to the list, which uses cpio -pld, if your cpio
groks that flag.
Those options are in the man page, at least.
Bryan
-
To unsubscribe from this list: send t
It complained when I cloned across devices.
`/git/cogito/.git/refs/tags/cogito-0.8' -> `.git/refs/tags/cogito-0.8'
cp: cannot create link `.git/refs/tags/cogito-0.8': Invalid cross-device link
`/git/cogito/.git/refs/tags/cogito-0.9' -> `.git/refs/tags/cogito-0.9'
cp: cannot create link `
On Mon, 11 Jul 2005, Marc Singer wrote:
>
> I picked 2.6.12
>
> # git checkout -f v2.6.12
>
> applied the patch and was greeted with an error about being unable to
> commit telling me that I LONG_HEX_NUMBER is not a valid commit object.
> Isn't 2.6.12 later than 2.6.12-rcX?
Yes.
However, t
Dan Holmsand <[EMAIL PROTECTED]> writes:
> I did a little experiment. I cloned Linus' current tree, and git
> repacked everything (that's 63M + 3.3M worth of pack files). Then I
> got something like 25 or so of Jeff's branches. That's 6.9M of object
> files, and 1.4M packed. Total size: 70M for th
Dear diary, on Mon, Jul 11, 2005 at 11:36:56PM CEST, I got a letter
where Thomas Lord <[EMAIL PROTECTED]> told me that...
> On Mon, 2005-07-11 at 21:39 +0200, Petr Baudis wrote:
> > Dear diary, on Sat, Jul 09, 2005 at 04:20:13PM CEST, I got a letter
> > where Thomas Lord <[EMAIL PROTECTED]> told me
Junio C Hamano <[EMAIL PROTECTED]> writes:
>
> - git-commit-tree says check_valid("commit") and barfs.
>
> My current preference is to keep .git/refs/heads tag free. At
> least, I do not think we should ever write non commits to
> .git/*_HEAD.
>
> What do you think? An alternative would be to a
Marc Singer <[EMAIL PROTECTED]> writes:
> I picked 2.6.12
>
> # git checkout -f v2.6.12
>
> applied the patch and was greeted with an error about being unable to
> commit telling me that I LONG_HEX_NUMBER is not a valid commit object.
> Isn't 2.6.12 later than 2.6.12-rcX?
Aha. Marc is not doin
On Mon, Jul 11, 2005 at 03:36:53PM -0700, Junio C Hamano wrote:
> Marc Singer <[EMAIL PROTECTED]> writes:
>
> > Looks like something's borked.
>
> Cogito I slurped about half hour ago has a quite different
> git-clone-script from your 4-line version. It is not surprising
> "git clone -l" would n
Marc Singer <[EMAIL PROTECTED]> writes:
> Looks like something's borked.
Cogito I slurped about half hour ago has a quite different
git-clone-script from your 4-line version. It is not surprising
"git clone -l" would not work with it ;-).
I just checked. Are you using Cogito 0.12 by any chance
On Fri, Jul 08, 2005 at 06:43:54PM -0700, Linus Torvalds wrote:
>
>
> On Fri, 8 Jul 2005, Marc Singer wrote:
> >
> > In working through a usage example on my way to producing bonafide
> > patches, I've found that commit is complaining. Here's what I've done.
> >
> > o Fetched and built cogito
On Mon, Jul 11, 2005 at 03:11:23PM -0700, Junio C Hamano wrote:
> Marc Singer <[EMAIL PROTECTED]> writes:
>
> > [EMAIL PROTECTED] /git > git clone
> > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> > linux-2.6
> > defaulting to local storage area
> > ssh: rsync:
Marc Singer <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] /git > git clone
> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> linux-2.6
> defaulting to local storage area
> ssh: rsync: Name or service not known
> fatal: unexpected EOF
Hmph. "git clone rsync:
* Linus Torvalds ([EMAIL PROTECTED]) wrote:
> On Mon, 11 Jul 2005, Eric W. Biederman wrote:
> >
> > A couple of pieces. The dist target has assumes git-tar-tree is in the
> > path. Making it so you have to have git installed to build the rpm.
>
> Yes. Maybe we could relax that requirement by us
Bryan Larsen <[EMAIL PROTECTED]> writes:
> For the record, "${XARGS} -0r" may be uglier than "xargs -0r", but
> replacing it with several lines of shell magic is a loss.
OK, OK, the one I suggested for xargs was _U_G_L_Y_.
The one Linus suggested looks to me the cleanest. That is, to
give an ex
On Sun, 2005-07-10 at 15:56 -0400, Daniel Barkalow wrote:
> + curl_easy_setopt(curl, CURLOPT_FILE, indexfile);
> + curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, fwrite);
> + curl_easy_setopt(curl, CURLOPT_URL, url);
I was hoping to send in a patch which would turn on user auth and turn
On Mon, 2005-07-11 at 21:39 +0200, Petr Baudis wrote:
> Dear diary, on Sat, Jul 09, 2005 at 04:20:13PM CEST, I got a letter
> where Thomas Lord <[EMAIL PROTECTED]> told me that...
> > The prereq graph is, indeed, an improvement.
> ..snip..
> But object retrieval can be potentially as much as lin
[EMAIL PROTECTED] /git > git clone
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
linux-2.6
defaulting to local storage area
ssh: rsync: Name or service not known
fatal: unexpected EOF
I've read several messages that this is changing, but it still isn't
clear wh
Junio C Hamano wrote:
Junio C Hamano <[EMAIL PROTECTED]> writes:
The only user of "cp -l" in the Linus GIT is git-clone-script
local optimization. I could revert it to the version that I
originally sent to the list, which uses cpio -pld, if your cpio
groks that flag.
Bryan, does this work
* Eric W. Biederman ([EMAIL PROTECTED]) wrote:
> Linus Torvalds <[EMAIL PROTECTED]> writes:
>
> > Ok, I tagged a "v0.99" thing, and pushed it out. I've also made trial
> > RPM's of it: src, ppc64 and x86. They're build on whatever random machines
> > I had, and on the ppc64 I chose to do it on m
Junio C Hamano <[EMAIL PROTECTED]> writes:
> The only user of "cp -l" in the Linus GIT is git-clone-script
> local optimization. I could revert it to the version that I
> originally sent to the list, which uses cpio -pld, if your cpio
> groks that flag.
Bryan, does this work for you?
--
* Petr Baudis ([EMAIL PROTECTED]) wrote:
> Ok, cg-pull didn't quite handle this. I've fixed it so that it should
> reasonably handle it now. Hopefully.
Is this plus the zero-sized fix worth making cogito-0.12-2 rpm release?
IOW, these two patches...
diff-tree 291ec0f2d2ce65e5ccb876b46d6468af49dd
Linus Torvalds wrote:
On Mon, 11 Jul 2005, Junio C Hamano wrote:
I am not yet convinced "one variable per GNU program" is the
right way to do (I do agree it is a problem and I appreciate
your trying to solving it; an obvious alternative cop-out would
be to fix this in the user's environment, b
Dear diary, on Sat, Jul 09, 2005 at 04:20:13PM CEST, I got a letter
where Thomas Lord <[EMAIL PROTECTED]> told me that...
> The prereq graph is, indeed, an improvement.
..snip..
But object retrieval can be potentially as much as linear to the depth
of the prereq graph, right? I don't think any o
Junio C Hamano wrote:
Bryan Larsen <[EMAIL PROTECTED]> writes:
+ for file in $(SCRIPTS); do \
+ sed -e "s/DATE\=date/DATE=$${DATE}/" -e "s/CP\=cp/CP=$${CP}/" -e
"s/XARGS\=xargs/XARGS=$${XARGS}/" -e "s/STAT\=stat/STAT=$${STAT}/" $$file > $$file.new; \
+ cat $$fi
Bryan Larsen <[EMAIL PROTECTED]> writes:
> Update the git Makefile to put the results of config.sh into the scripts.
> config.sh searches for gnu utilities cp, stat, date and xargs.
>
> Signed-off-by: Bryan Larsen <[EMAIL PROTECTED]>
> +install: $(PROG) $(SCRIPTS) config
> $(INSTALL) -m75
On Mon, 11 Jul 2005, Junio C Hamano wrote:
>
> I am not yet convinced "one variable per GNU program" is the
> right way to do (I do agree it is a problem and I appreciate
> your trying to solving it; an obvious alternative cop-out would
> be to fix this in the user's environment, but there might
This seems reasonable to me. I have thought this would be useful on
several occasions and haven't yet conceived of a counterexample where
it would break something.
On 7/11/05, Junio C Hamano <[EMAIL PROTECTED]> wrote:
> When we allow a tag object in place of a commit object, we only
> dereferenced
git-cvsimport-script: add "import only" option.
Acked-by: Matthias Urlichs <[EMAIL PROTECTED]>
Signed-off-by: Sven Verdoolaege <[EMAIL PROTECTED]>
---
commit 1be6fbebb010083a083d8e2ee69fced7b6ae1261
tree a69017b2d10fd0a2655070d177f7cf59ab21882f
parent a3eb250f996bf5e12376ec88622c4ccaabf20ea8
auth
On Mon, 11 Jul 2005, Eric W. Biederman wrote:
>
> I'm having the worst time putting together a mental model of how git
> works, and the documentation is spotty enough that it hasn't been
> helpful. So I am wading through the code. It seems every time I turn
> a corner there is another rough sp
On Mon, 11 Jul 2005, Daniel Barkalow wrote:
> On Sun, 10 Jul 2005, Linus Torvalds wrote:
>
> >
> > You really _mustn't_ try to create the pack directly to the
> > $GIT_DIR/objects/pack subdirectory - that would make git itself start
> > possibly using that pack before the index is all done, and
> The big problem, however, comes when Jeff (or anyone else) decides to
> repack. Then, if you fetch both his repo and Linus', you might end up
> with several really big pack files, that mostly overlap. That could
> easily mean storing most objects many times, if you don't do some smart
> selective
On Mon, 11 Jul 2005, Eric W. Biederman wrote:
>
> A couple of pieces. The dist target has assumes git-tar-tree is in the
> path. Making it so you have to have git installed to build the rpm.
Yes. Maybe we could relax that requirement by using "./git-tar-tree" or
something? That still require
On Mon, 11 Jul 2005, Eric W. Biederman wrote:
>
> I guess I was expecting to pull from one tree into another unrelated
> tree. Getting a tree with two heads and then be able to merge them
> together.
You can do it, but you have to do it by hand. It's a valid operation, but
it's not an operati
Junio C Hamano wrote:
One very minor problem I have with Holmsand approach [*1*] is
that the original Barkalow puller allowed a really dumb http
server by not requiring directory index at all. For somebody
like me with a cheap ISP account [*2*], it was great that I did
not have to update 256 ind
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Sat, 9 Jul 2005, Eric W. Biederman wrote:
>>
>> The current intelligent fetch currently has a problem that it cannot
>> be used to bootstrap a repository. If you don't have an ancestor
>> of what you are fetching you can't fetch it.
>
> Sure you ca
Linus Torvalds <[EMAIL PROTECTED]> writes:
> Ok, I tagged a "v0.99" thing, and pushed it out. I've also made trial
> RPM's of it: src, ppc64 and x86. They're build on whatever random machines
> I had, and on the ppc64 I chose to do it on my FC4 machine that has newer
> libraries than my YDL one
Update the git Makefile to put the results of config.sh into the scripts.
config.sh searches for gnu utilities cp, stat, date and xargs.
Signed-off-by: Bryan Larsen <[EMAIL PROTECTED]>
---
Makefile | 13 +++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/Makefile b
A Portfile for darwinports.
Signed-off-by: Bryan Larsen <[EMAIL PROTECTED]>
---
Makefile|2 ++
Portfile.in | 25 +
2 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -240,6 +240,8 @@ dist: cogito.
Patch git so that the utilities 'cp' 'stat' 'xargs' and 'date' are
configurable. Git requires the gnu versions of these tools, and on some BSD
derived systems, the gnu versions of these tools have a different name.
Signed-off-by: Bryan Larsen <[EMAIL PROTECTED]>
---
git-clone-script |4 ++
Cogito and git rely on the gnu version of 4 standard utilities: cp,
date, stat and xargs. On most non-Linux based Unix's, the gnu tools
are optional installs, and are installed under different names.
These patches parameterize the names of these 4 tools, determine what
name should be used, and v
Patch cogito so that the utilities 'cp' 'stat' 'xargs' and 'date' are
configurable. Cogito requires the gnu versions of these tools, and on some BSD
derived systems, the gnu versions of these tools have a different name.
Signed-off-by: Bryan Larsen <[EMAIL PROTECTED]>
---
cg-Xlib| 15 ++
Update the cogito Makefile to put the results of config.sh into the scripts.
config.sh searches for gnu utilities cp, stat, date and xargs.
Signed-off-by: Bryan Larsen <[EMAIL PROTECTED]>
---
Makefile | 18 ++
1 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/Ma
Add config.sh which searches for gnu versions of 'cp' 'stat' 'date' and 'xargs'.
Signed-off-by: Bryan Larsen <[EMAIL PROTECTED]>
---
config.sh | 65 +
1 files changed, 65 insertions(+), 0 deletions(-)
diff --git a/config.sh b/config.
Dave Jones daily snapshot of git solved the problem, available from:
http://www.codemonkey.org.uk/projects/git-snapshots/git/
I realise that Jeff's howto suggested updating git using git, but it
suggested doing this after following the intermediate steps. I also find
it ironic that the version of
On Sun, 2005-07-10 at 10:31 -0700, Linus Torvalds wrote:
> No it's not, as far as I can tell:
>
> [EMAIL PROTECTED]:/home/dwmw2/git/mail-2.6(0)$ cat
> .git/branches/origin
> rsync://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>
> so your scripts will go out to
This reverses the order of object lookup, to check pack index
first and then go to the filesystem to find .git/objects/??/
hierarchy. When most of the objects are packed, this saves
quite many stat() calls and negative dcache entries; while the
price this approach has to pay is negligible, even wh
86 matches
Mail list logo
