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
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:
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. The
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 operation
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, 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 that
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 spot.
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
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 of
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,
* 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 my FC4
[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
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 allow tags
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 that...
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 the
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, that's
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
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
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
possibly using
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
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
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.8':
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:
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:
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 the user
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
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
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, 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() if
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 it
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 send in a
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 preparation
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 to rename
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
been
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 omitted,
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 have no
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 does. It
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 branch.
As I
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
something you
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:
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 now we have
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, 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
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 have
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
45 matches
Mail list logo
