* Re: [PATCH 1/5] Fixes for ancient versions of GNU make
From: Jason Riedy @ 2006-02-17 17:15 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0602171522020.24274@wbgn013.biozentrum.uni-wuerzburg.de>
And Johannes Schindelin writes:
-
- Some version of GNU make do not understand $(call), and have
- problems to interpret rules like this:
Is building a newer version of GNU make impossible on Irix?
Thankfully, I haven't had to deal with that OS in quite some
time.
Jason
^ permalink raw reply
* Re: [PATCH 0/5] Support ancient systems
From: Tim O'Callaghan @ 2006-02-17 17:03 UTC (permalink / raw)
To: git
In-Reply-To: <94fc236b0602170718t76e01204ib2b50e33eaa5eeaa@mail.gmail.com>
On Fri, Feb 17, 2006 at 04:18:35PM +0100, Adrien Beau wrote:
> On 2/17/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > I just got git to work on an Irix box. These are the changes I needed
> > to apply. Maybe some of them are of use for other ancient systems... You
> > know, I like ancient systems. And if I could get my hands on a VMS, I
> > would try to get git to work on it, too ;-)
>
> You can get free VMS accounts at the Deathrow Cluster:
> http://deathrow.vistech.net/
>
> If you're serious about using your account, you'll find that the admin
> team is pretty supportive and friendly.
You should check out polarhome.com if you want a variety of platforms
to muck about on, including IRIX, Plan 9, OpenVMS Vax, OpenVMS Alpha
etc.
I work on VMS systems at the moment and i thought of attempting to
port git for the hell of it. I decided not to bother for a variety of
reasons, but mostly because it looked like too much work :)
Tim.
^ permalink raw reply
* Re: Why can't git-rebase back up?
From: Andreas Ericsson @ 2006-02-17 16:30 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20060217153434.26359.qmail@science.horizon.com>
linux@horizon.com wrote:
>>>[[ This is because core git won't allow the checked-out HEAD to point
>>>to anything but a branch,
>
>
>>Yes it will. That's how "git reset" works (i.e. pointing HEAD to some
>>random object). Think of branches and tags as short and humanly
>>understandable names for certain points in the history. You can visit
>>any point in history without having a special short name for it.
>
>
> Er... say again? git reset doesn't touch the .git/HEAD symlink;
> it overwrites the file that .git/HEAD points to.
>
My bad. You're right.
> If you know a way to make the core git tools produce a .git/HEAD that
> is either not a symlink or does NOT begin with "refs/heads/", I'm quite
> curious.
>
The order of precedence works as such:
.git/<anchor-name>
.git/refs/<anchor-name>
.git/refs/tags/<tag-name>
.git/refs/heads/<branch-name>
sha1, with git magic to allow abbreviations
This is why you can't sanely have a branch named HEAD.
>
>>>and checking out something without having
>>>HEAD point to it is fragile and delicate. Cogito lets you do this with
>>>cg-seek. ]]
>
>
>>It's more than delicate. It's impossible (even for Cogito). You can take
>>snapshots of how the tree looked at a certain state and export that
>>using git-tar-tree if you wish, but other than that it's impossible to
>>visit a certain point in history without pointing HEAD to it (that's how
>>visiting that point is done, actually).
>
>
> Actually, you're right... Cogito uses refs/heads/cg-seek-point.
> But you can do it by hand with git-read-tree and git-checkout-index.
> (Very little in git is impossible; some things are just a Really Bad
> Idea.)
>
>
>>Now, if I want to migrate to a newer base version, I can always use
>>git-reset --hard v2.6.16-rc3, but that's a bit dangerous.
>>Preferable is to use git-rebase v2.6.16-rc3, which will preserve
>>any local edits.
>>
>>(I could also do it as a merge, but that seems like unnecessary history
>>clutter. It's not like local edits are common, anyway.)
>>
>>But suppose discover a nasty bug in -rc3 and want to move my build branch
>>back to -rc2. "git-rebase v2.6.16-rc2" does nothing. After a bit
>>of thought, I realize why, but sometime I do want to back up.
>>
>
>
>>I'd suggest doing something like this when changing base version (of any
>>project, really).
>
>
> [Use separate branch names for the two build versions.]
>
> That's certainly a possibility, but kind of annoying to remember what
> the "current" version is. Typically, there are no local changes,
> and I'm just using "build" as a conventional name to let me check
> out the version. Just like cg-seek-point.
>
Then make the current production be 'build', the "soon-to-become
production" to be 'devel' and tag the ones you're finished with so you
can revert to them easily if it becomes necessary. That's more or less
how all projects work, AFAIK.
>
>>However, branches and tags are cheap to create, efficient to use, easy
>>to remove once you're done with them. They make life easier. Use them.
>>You'll be glad you did.
>
>
> I don't really *want* a branch at all. I just want to export the
> right source tree and compile it.
$ git tar-tree v2.6.16-rc3 linux-2.6.16-rc3
OTOH, you could just download the released sources and patches from ftp.
> Local changes are more likely a
> mistake than anything else, but core git doesn't have Cogito's "blocked"
> flag. I'm just trying to avoid getting
> into the habit of typing "git reset --hard" a lot because that's
> dangerous.
>
I don't see why you should have to, even if you don't use a topic-branch
for fiddling with things. You can still do
$ git tar-tree <tag> linux-<tag>
to get the snapshot no matter how much you reset and muck about with the
working tree copy of the current HEAD.
If you're unsure about this, try
$ git checkout -b foo 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
$ gitk; # behold the dawn of time
$ git tar-tree v2.6.16-rc3 foo | gzip -9 > foo.tar.gz
Note that the first operation takes quite a while, as it has to update
all the files in the working tree.
> It's sort of along the lines of "any workflow that makes you type
> 'rm -rf *' on a regular basis is a recipe for disaster".
>
> The usual solution, of course, is to write a shell script wrapper with
> some safety checking. For example, I could see if git-name-rev --tags
> can come up with a name for the branch head before unleashing git-reset
> on it.
>
> But I thought I'd check if the tool already existed.
>
It does, and it doesn't. git checkout -b <name> <commit-ish> does what
you want, although it creates a branch. "git seek" isn't needed, since
creating branches is so cheap and far better than having to protect
certain branch- and tag-names for the sake of creating tools that offer
less power and flexibility than those already there.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Make git-reset delete empty directories
From: Shawn Pearce @ 2006-02-17 16:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20060217151654.GA26362@spearce.org>
Shawn Pearce <spearce@spearce.org> wrote:
> Junio C Hamano <junkio@cox.net> wrote:
> > I thought I said it would be a few-liner, but it appears I did
> > not send that message.
Actually its only a one line change if you accept Perl as Perl,
but not everyone likes having their loops do nothing in the loop
body whilest the condition does all of the work.
---
diff --git a/git-reset.sh b/git-reset.sh
index fe53fc8..e6471c0 100755
--- a/git-reset.sh
+++ b/git-reset.sh
@@ -88,6 +88,7 @@ case "$reset_type" in
# it is ok if this fails -- it may already
# have been culled by checkout-index.
unlink $_;
+ 1 while (s,/[^/]*$,, && rmdir $_);
}
}
' $tmp-exists
^ permalink raw reply related
* Re: [PATCH] pack-objects: reuse data from existing pack.
From: Linus Torvalds @ 2006-02-17 15:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu0ay8v4f.fsf@assigned-by-dhcp.cox.net>
On Thu, 16 Feb 2006, Junio C Hamano wrote:
>
> This one has one nasty data corruption bug, which fortunately I
> think I have figured out how to fix.
Circular deltas? What else can go wrong?
Linus
^ permalink raw reply
* Re: Why can't git-rebase back up?
From: linux @ 2006-02-17 15:34 UTC (permalink / raw)
To: ae, linux; +Cc: git
In-Reply-To: <43F5DF8B.6050307@op5.se>
>> [[ This is because core git won't allow the checked-out HEAD to point
>> to anything but a branch,
> Yes it will. That's how "git reset" works (i.e. pointing HEAD to some
> random object). Think of branches and tags as short and humanly
> understandable names for certain points in the history. You can visit
> any point in history without having a special short name for it.
Er... say again? git reset doesn't touch the .git/HEAD symlink;
it overwrites the file that .git/HEAD points to.
If you know a way to make the core git tools produce a .git/HEAD that
is either not a symlink or does NOT begin with "refs/heads/", I'm quite
curious.
>> and checking out something without having
>> HEAD point to it is fragile and delicate. Cogito lets you do this with
>> cg-seek. ]]
> It's more than delicate. It's impossible (even for Cogito). You can take
> snapshots of how the tree looked at a certain state and export that
> using git-tar-tree if you wish, but other than that it's impossible to
> visit a certain point in history without pointing HEAD to it (that's how
> visiting that point is done, actually).
Actually, you're right... Cogito uses refs/heads/cg-seek-point.
But you can do it by hand with git-read-tree and git-checkout-index.
(Very little in git is impossible; some things are just a Really Bad
Idea.)
> Now, if I want to migrate to a newer base version, I can always use
> git-reset --hard v2.6.16-rc3, but that's a bit dangerous.
> Preferable is to use git-rebase v2.6.16-rc3, which will preserve
> any local edits.
>
> (I could also do it as a merge, but that seems like unnecessary history
> clutter. It's not like local edits are common, anyway.)
>
> But suppose discover a nasty bug in -rc3 and want to move my build branch
> back to -rc2. "git-rebase v2.6.16-rc2" does nothing. After a bit
> of thought, I realize why, but sometime I do want to back up.
>
> I'd suggest doing something like this when changing base version (of any
> project, really).
[Use separate branch names for the two build versions.]
That's certainly a possibility, but kind of annoying to remember what
the "current" version is. Typically, there are no local changes,
and I'm just using "build" as a conventional name to let me check
out the version. Just like cg-seek-point.
> However, branches and tags are cheap to create, efficient to use, easy
> to remove once you're done with them. They make life easier. Use them.
> You'll be glad you did.
I don't really *want* a branch at all. I just want to export the
right source tree and compile it. Local changes are more likely a
mistake than anything else, but core git doesn't have Cogito's "blocked"
flag. I'm just trying to avoid getting
into the habit of typing "git reset --hard" a lot because that's
dangerous.
It's sort of along the lines of "any workflow that makes you type
'rm -rf *' on a regular basis is a recipe for disaster".
The usual solution, of course, is to write a shell script wrapper with
some safety checking. For example, I could see if git-name-rev --tags
can come up with a name for the branch head before unleashing git-reset
on it.
But I thought I'd check if the tool already existed.
^ permalink raw reply
* Re: [PATCH 0/5] Support ancient systems
From: Adrien Beau @ 2006-02-17 15:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0602171517580.24274@wbgn013.biozentrum.uni-wuerzburg.de>
On 2/17/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> I just got git to work on an Irix box. These are the changes I needed
> to apply. Maybe some of them are of use for other ancient systems... You
> know, I like ancient systems. And if I could get my hands on a VMS, I
> would try to get git to work on it, too ;-)
You can get free VMS accounts at the Deathrow Cluster:
http://deathrow.vistech.net/
If you're serious about using your account, you'll find that the admin
team is pretty supportive and friendly.
^ permalink raw reply
* Re: [PATCH] Make git-reset delete empty directories
From: Shawn Pearce @ 2006-02-17 15:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7j7u8koz.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> I thought I said it would be a few-liner, but it appears I did
> not send that message.
You did. Somehow I forgot that request. I wrote a simple approach
similar to what you show below then tried to make it slightly
more efficient by only attempting to delete each directory once.
Obviously that wasn't wise on my part. :-)
> This untested one is far simpler, if less efficient, isn't it?
>
> ---
>
> diff --git a/git-reset.sh b/git-reset.sh
> index fe53fc8..195d043 100755
> --- a/git-reset.sh
> +++ b/git-reset.sh
> @@ -88,6 +88,9 @@ case "$reset_type" in
> # it is ok if this fails -- it may already
> # have been culled by checkout-index.
> unlink $_;
> + while (s|/[^/]*$|| && $_ ne "") {
> + rmdir($_) or last;
> + }
> }
> }
> ' $tmp-exists
I just ran it through the test script (t7101-reset.sh) that I
included in my patch and it passed, so clearly the version above
would be the better version to include.
Since it was untested before you are welcome to include the test
script with your version. :-)
--
Shawn.
^ permalink raw reply
* Re: [PATCH 0/5] Support ancient systems
From: Andreas Ericsson @ 2006-02-17 14:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0602171517580.24274@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> I just got git to work on an Irix box. These are the changes I needed
> to apply. Maybe some of them are of use for other ancient systems... You
> know, I like ancient systems. And if I could get my hands on a VMS, I
> would try to get git to work on it, too ;-)
>
http://www.testdrive.hp.com/
You can sign up for a free account there and get (telnet and ftp) access
to all sorts of wonky and fun systems.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Why can't git-rebase back up?
From: Andreas Ericsson @ 2006-02-17 14:36 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20060217135938.7412.qmail@science.horizon.com>
linux@horizon.com wrote:
> Newbie question... In what I assume is a usual technique, I maintain a
> "build" branch off of the linux-2.6 history which is what I check out
> to build a kernel. I usually keep it at an official tagged releas,
> such as v2.6.16-rc2.
>
> [[ This is because core git won't allow the checked-out HEAD to point
> to anything but a branch,
Yes it will. That's how "git reset" works (i.e. pointing HEAD to some
random object). Think of branches and tags as short and humanly
understandable names for certain points in the history. You can visit
any point in history without having a special short name for it.
> and checking out something without having
> HEAD point to it is fragile and delicate. Cogito lets you do this with
> cg-seek. ]]
>
It's more than delicate. It's impossible (even for Cogito). You can take
snapshots of how the tree looked at a certain state and export that
using git-tar-tree if you wish, but other than that it's impossible to
visit a certain point in history without pointing HEAD to it (that's how
visiting that point is done, actually).
> Now, if I want to migrate to a newer base version, I can always use
> git-reset --hard v2.6.16-rc3, but that's a bit dangerous.
> Preferable is to use git-rebase v2.6.16-rc3, which will preserve
> any local edits.
>
> (I could also do it as a merge, but that seems like unnecessary history
> clutter. It's not like local edits are common, anyway.)
>
> But suppose discover a nasty bug in -rc3 and want to move my build branch
> back to -rc2. "git-rebase v2.6.16-rc2" does nothing. After a bit
> of thought, I realize why, but sometime I do want to back up.
>
I'd suggest doing something like this when changing base version (of any
project, really). Let's say you start, for the first time, with
v2.6.16-rc2. The workflow would look something like this:
$ git checkout -b mod-2.6.16-rc2 v2.6.16-rc2; # create a branch at the
desired point in history
$ apply your changes
2.6.16-rc3 is out, and you want to use that instead.
$ git checkout -b mod-2.6.16-rc3 v2.6.16-rc3; # new branch for new trial
$ git rebase mod-2.6.16-rc2; # apply patches you've already made
Now a couple of different things can happen:
1. The rebase works fine. Oh, joy of joy!
2. The rebase doesn't work, but a merge does:
$ git pull . mod-2.6.16-rc2
3. Neither merge or rebase works, but you can manually apply your
patches, drop the offending ones or resolve the conflicts.
4. There's a bug so you want to regress. Just do:
$ git checkout mod-2.6.16-rc2
In this scenario, only option 3 means trouble and that's inevitable no
matter how you work since your patches no longer apply.
> What's the best way to do that? Should git-rebase take an optional
> third argument which is the branch head we are moving away from?
> E.g. what I want to do would be
>
> git-rebase v2.6.16-rc2 build v2.6.16-rc3
>
> Or is there some other tool already suited to the job?
>
> (Yes, I'm aware the operations cannot be exact inverses, because if
> I applied a local patch that was also included in -rc3, git-rebase
> will delete the redundant copy from the build branch, and the backing
> up will have no way to know to put it back. If I wanted to do that,
> I would use a merge.)
>
If you merge a branch based on top of a later head you'd end up with the
same commits in your history anyways, since it would have to merge all
commits up to the merge-base. In essence, you'd do a complicated
fast-forward, but with reverse history to what I think you think (i.e.
you'd be pulling 2.6.16-rc3 in on top of your patches).
One way to accomplish this would be to do:
$ git checkout mod-2.6.16-rc3; # get to that point, one way or another
$ git format-patch -k --stdout v2.6.16-rc3 > 2.6.16-rc3.patches.mbox
$ git reset --hard v2.6.16-rc2; # get to that point, one way or another
$ git am -k 2.6.16-rc3.patches.mbox
However, branches and tags are cheap to create, efficient to use, easy
to remove once you're done with them. They make life easier. Use them.
You'll be glad you did.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: What's in git.git
From: linux @ 2006-02-17 14:28 UTC (permalink / raw)
To: junkio; +Cc: git
- "Rebase to different branch" (1 commit):
This was previously discussed on the list. With this command
line:
$ git rebase --onto master~1 master topic
would rebase this ancestry graph to:
A---B---C topic
/
D---E---F---G master
another graph that looks like this:
A'--B'--C' topic
/
D---E---F---G master
Earlier, you couldn't rebase to anywhere other than on top of
"the other branch".
Er... what does this do, again? I couldn't find the list discussion, and
I can get this exact effect in vanilla 1.2.1 with "git rebase master~1 topic".
AFAIK, $ARGV[1] of git-rebase only has to be a commit-ish, not a branch.
OTOH, I can imagine wanting
$ git-rebase master~1 topic topic~2
to produce
A B---C topic
/ /
D---E---F---G master
H'm... I wonder if the same syntax could be used to resolve the ambiguous
case where there are multiple possible common ancestors, e.g.
A---B---C topic
/ /
D---E---F---G master
as discussed in the "git rebase behaviour changed?" thread...
^ permalink raw reply
* [PATCH 5/5] Optionally work without python
From: Johannes Schindelin @ 2006-02-17 14:24 UTC (permalink / raw)
To: git, junkio
In some setups (notably server setups) you do not need that dependency.
Gracefully handle the absence of python when NO_PYTHON is defined.
Signed-off-by: Johannes E. Schindelin <Johannes.Schindelin@gmx.de>
---
Makefile | 8 +++++++-
git-merge.sh | 6 +++++-
t/Makefile | 5 +++++
t/t0000-basic.sh | 2 ++
t/t6021-merge-criss-cross.sh | 6 ++++++
t/t6022-merge-rename.sh | 6 ++++++
t/test-lib.sh | 2 ++
7 files changed, 33 insertions(+), 2 deletions(-)
aa0aef85a93da00f3afbbed9105b45ad41b8427c
diff --git a/Makefile b/Makefile
index 7e1990b..1ee61e6 100644
--- a/Makefile
+++ b/Makefile
@@ -58,6 +58,8 @@ all:
# Define NO_ACCURATE_DIFF if your diff program at least sometimes misses
# a missing newline at the end of the file.
#
+# Define NO_PYTHON if you want to loose all benefits of the recursive merge.
+#
# Define COLLISION_CHECK below if you believe that SHA1's
# 1461501637330902918203684832716283019655932542976 hashes do not give you
# sufficient guarantee that no collisions between objects will ever happen.
@@ -422,6 +424,9 @@ endif
ifdef NO_ACCURATE_DIFF
ALL_CFLAGS += -DNO_ACCURATE_DIFF
endif
+ifdef NO_PYTHON
+ TEST_DEFS += NO_PYTHON=YesPlease
+endif
# Shell quote (do not use $(call) to accomodate ancient setups);
@@ -462,6 +467,7 @@ $(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.
sed -e '1s|#!.*/sh|#!$(SHELL_PATH_QUOTED)|' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
-e 's/@@NO_CURL@@/$(NO_CURL)/g' \
+ -e 's/@@NO_PYTHON@@/$(NO_PYTHON)/g' \
$@.sh >$@
chmod +x $@
@@ -552,7 +558,7 @@ doc:
### Testing rules
test: all
- $(MAKE) -C t/ all
+ $(MAKE) -C t/ all $(TEST_DEFS)
test-date$X: test-date.c date.o ctype.o
$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) test-date.c date.o ctype.o
diff --git a/git-merge.sh b/git-merge.sh
index 74f0761..c0f53df 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -11,7 +11,11 @@ LF='
'
all_strategies='recursive octopus resolve stupid ours'
-default_strategies='recursive'
+if test -z "@@NO_PYTHON@@"; then
+ default_strategies='recursive'
+else
+ default_strategies='resolve'
+fi
use_strategies=
dropsave() {
diff --git a/t/Makefile b/t/Makefile
index d78404f..12e2c16 100644
--- a/t/Makefile
+++ b/t/Makefile
@@ -12,9 +12,14 @@ SHELL_PATH_QUOTED = '$(subst ','\'',$(SH
T = $(wildcard t[0-9][0-9][0-9][0-9]-*.sh)
+ifdef NO_PYTHON
+ GIT_TEST_OPTS += --no-python
+endif
+
all: $(T) clean
$(T):
+ echo $(SHELL_PATH_QUOTED) $@ $(GIT_TEST_OPTS)
@echo "*** $@ ***"; $(SHELL_PATH_QUOTED) $@ $(GIT_TEST_OPTS)
clean:
diff --git a/t/t0000-basic.sh b/t/t0000-basic.sh
index c339a36..fe7f448 100755
--- a/t/t0000-basic.sh
+++ b/t/t0000-basic.sh
@@ -42,11 +42,13 @@ fi
. ./test-lib.sh
+if test -z "$no_python"; then
"$PYTHON" -c 'import subprocess' || {
echo >&2 'Your python seem to lack "subprocess" module.
Please check INSTALL document.'
exit 1
}
+fi
################################################################
# init-db has been done in an empty repository.
diff --git a/t/t6021-merge-criss-cross.sh b/t/t6021-merge-criss-cross.sh
index e8606c7..2623813 100755
--- a/t/t6021-merge-criss-cross.sh
+++ b/t/t6021-merge-criss-cross.sh
@@ -10,6 +10,12 @@
test_description='Test criss-cross merge'
. ./test-lib.sh
+if test "$no_python"; then
+ echo "Skipping: no python => no recursive merge"
+ test_done
+ exit 0
+fi
+
test_expect_success 'prepare repository' \
'echo "1
2
diff --git a/t/t6022-merge-rename.sh b/t/t6022-merge-rename.sh
index 1292caf..a2d24b5 100755
--- a/t/t6022-merge-rename.sh
+++ b/t/t6022-merge-rename.sh
@@ -3,6 +3,12 @@
test_description='Merge-recursive merging renames'
. ./test-lib.sh
+if test "$no_python"; then
+ echo "Skipping: no python => no recursive merge"
+ test_done
+ exit 0
+fi
+
test_expect_success setup \
'
cat >A <<\EOF &&
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 7a58a86..43c8e55 100755
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -63,6 +63,8 @@ do
exit 0 ;;
-v|--v|--ve|--ver|--verb|--verbo|--verbos|--verbose)
verbose=t; shift ;;
+ --no-python)
+ no_python=t; shift ;;
*)
break ;;
esac
--
1.2.1.g09fe-dirty
^ permalink raw reply related
* [PATCH 4/5] Support Irix
From: Johannes Schindelin @ 2006-02-17 14:23 UTC (permalink / raw)
To: git, junkio
Signed-off-by: Johannes E. Schindelin <Johannes.Schindelin@gmx.de>
---
Makefile | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
83cb63120fb66c66d88f04c3d9c61e82b8f1837d
diff --git a/Makefile b/Makefile
index 6e00737..7e1990b 100644
--- a/Makefile
+++ b/Makefile
@@ -279,6 +279,16 @@ ifeq ($(uname_S),AIX)
NO_STRCASESTR=YesPlease
NEEDS_LIBICONV=YesPlease
endif
+ifeq ($(uname_S),IRIX64)
+ NO_IPV6=YesPlease
+ NO_SETENV=YesPlease
+ NO_STRCASESTR=YesPlease
+ NO_SOCKADDR_STORAGE=YesPlease
+ SHELL_PATH=/usr/gnu/bin/bash
+ ALL_CFLAGS += -DPATH_MAX=1024
+ # for now, build 32-bit version
+ ALL_LDFLAGS += -L/usr/lib32
+endif
ifneq (,$(findstring arm,$(uname_M)))
ARM_SHA1 = YesPlease
endif
--
1.2.1.g09fe-dirty
^ permalink raw reply related
* [PATCH 3/5] Optionally support old diffs
From: Johannes Schindelin @ 2006-02-17 14:23 UTC (permalink / raw)
To: git, junkio
Some versions of diff do not correctly detect a missing new-line at the end
of the file under certain circumstances.
When defining NO_ACCURATE_DIFF, work around this bug.
Signed-off-by: Johannes E. Schindelin <Johannes.Schindelin@gmx.de>
---
Makefile | 6 ++++++
apply.c | 8 ++++++++
2 files changed, 14 insertions(+), 0 deletions(-)
46183bd251ffe3fc3cbbf4d94467627f922d6d43
diff --git a/Makefile b/Makefile
index b3401ac..6e00737 100644
--- a/Makefile
+++ b/Makefile
@@ -55,6 +55,9 @@ all:
#
# Define NO_ICONV if your libc does not properly support iconv.
#
+# Define NO_ACCURATE_DIFF if your diff program at least sometimes misses
+# a missing newline at the end of the file.
+#
# Define COLLISION_CHECK below if you believe that SHA1's
# 1461501637330902918203684832716283019655932542976 hashes do not give you
# sufficient guarantee that no collisions between objects will ever happen.
@@ -405,6 +408,9 @@ else
LIBS += $(LIB_4_CRYPTO)
endif
endif
+endif
+ifdef NO_ACCURATE_DIFF
+ ALL_CFLAGS += -DNO_ACCURATE_DIFF
endif
# Shell quote (do not use $(call) to accomodate ancient setups);
diff --git a/apply.c b/apply.c
index 2ad47fb..1083d4f 100644
--- a/apply.c
+++ b/apply.c
@@ -1142,6 +1142,14 @@ static int apply_one_fragment(struct buf
size -= len;
}
+#ifdef NO_ACCURATE_DIFF
+ if (oldsize > 0 && old[oldsize - 1] == '\n' &&
+ newsize > 0 && new[newsize - 1] == '\n') {
+ oldsize--;
+ newsize--;
+ }
+#endif
+
offset = find_offset(buf, desc->size, old, oldsize, frag->newpos);
if (offset >= 0) {
int diff = newsize - oldsize;
--
1.2.1.g09fe-dirty
^ permalink raw reply related
* [PATCH 2/5] Fix cpio call
From: Johannes Schindelin @ 2006-02-17 14:22 UTC (permalink / raw)
To: git, junkio
To some cpio's, -a and -m options are mutually exclusive. Use only -m.
Signed-off-by: Johannes E. Schindelin <Johannes.Schindelin@gmx.de>
---
git-clone.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
d2f8d0558bcf8d0d207e89137a04e8a97fedae03
diff --git a/git-clone.sh b/git-clone.sh
index e192b08..cf410fa 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -153,7 +153,7 @@ yes,yes)
fi &&
rm -f "$GIT_DIR/objects/sample" &&
cd "$repo" &&
- find objects -depth -print | cpio -puamd$l "$GIT_DIR/" || exit 1
+ find objects -depth -print | cpio -pumd$l "$GIT_DIR/" || exit 1
;;
yes)
mkdir -p "$GIT_DIR/objects/info"
--
1.2.1.g09fe-dirty
^ permalink raw reply related
* [PATCH 1/5] Fixes for ancient versions of GNU make
From: Johannes Schindelin @ 2006-02-17 14:22 UTC (permalink / raw)
To: git, junkio
Some version of GNU make do not understand $(call), and have problems to
interpret rules like this:
some_target: CFLAGS += -Dsome=defs
Signed-off-by: Johannes E. Schindelin <Johannes.Schindelin@gmx.de>
---
Makefile | 71 +++++++++++++++++++++++++++++++++++++++---------------------
t/Makefile | 7 ++----
2 files changed, 48 insertions(+), 30 deletions(-)
b50c666c80ef6191e06c1c9ed88af534da7ea458
diff --git a/Makefile b/Makefile
index d7d79de..b3401ac 100644
--- a/Makefile
+++ b/Makefile
@@ -203,12 +203,6 @@ LIB_OBJS = \
LIBS = $(LIB_FILE)
LIBS += -lz
-# Shell quote;
-# Result of this needs to be placed inside ''
-shq = $(subst ','\'',$(1))
-# This has surrounding ''
-shellquote = '$(call shq,$(1))'
-
#
# Platform specific tweaks
#
@@ -413,7 +407,24 @@ endif
endif
endif
-ALL_CFLAGS += -DSHA1_HEADER=$(call shellquote,$(SHA1_HEADER)) $(COMPAT_CFLAGS)
+# Shell quote (do not use $(call) to accomodate ancient setups);
+
+# Result of this needs to be placed inside ''
+SHA1_HEADER_QUOTED = '$(subst ','\'',$(SHA1_HEADER))'
+template_dir_QUOTED = '$(subst ','\'',"$(template_dir)")'
+
+# These will be used inside ''
+SHELL_PATH_QUOTED = $(subst ','\'',$(SHELL_PATH))
+PERL_PATH_QUOTED = $(subst ','\'',$(PERL_PATH))
+PYTHON_PATH_QUOTED = $(subst ','\'',$(PYTHON_PATH))
+GIT_PYTHON_DIR_QUOTED = $(subst ','\'',$(GIT_PYTHON_DIR))
+
+# prepend DESTDIR to these
+DESTDIR_bindir_QUOTED = '$(subst ','\'',$(DESTDIR)$(bindir))'
+DESTDIR_gitexecdir_QUOTED = '$(subst ','\'',$(DESTDIR)$(gitexecdir))'
+DESTDIR_GIT_PYTHON_DIR_QUOTED = '$(subst ','\'',$(DESTDIR)$(GIT_PYTHON_DIR))'
+
+ALL_CFLAGS += -DSHA1_HEADER=$(SHA1_HEADER_QUOTED) $(COMPAT_CFLAGS)
LIB_OBJS += $(COMPAT_OBJS)
export prefix TAR INSTALL DESTDIR SHELL_PATH template_dir
### Build rules
@@ -432,7 +443,7 @@ git$X: git.c $(LIB_FILE)
$(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
rm -f $@
- sed -e '1s|#!.*/sh|#!$(call shq,$(SHELL_PATH))|' \
+ sed -e '1s|#!.*/sh|#!$(SHELL_PATH_QUOTED)|' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
-e 's/@@NO_CURL@@/$(NO_CURL)/g' \
$@.sh >$@
@@ -440,15 +451,15 @@ $(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.
$(patsubst %.perl,%,$(SCRIPT_PERL)) : % : %.perl
rm -f $@
- sed -e '1s|#!.*perl|#!$(call shq,$(PERL_PATH))|' \
+ sed -e '1s|#!.*perl|#!$(PERL_PATH_QUOTED)|' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
$@.perl >$@
chmod +x $@
$(patsubst %.py,%,$(SCRIPT_PYTHON)) : % : %.py
rm -f $@
- sed -e '1s|#!.*python|#!$(call shq,$(PYTHON_PATH))|' \
- -e 's|@@GIT_PYTHON_PATH@@|$(call shq,$(GIT_PYTHON_DIR))|g' \
+ sed -e '1s|#!.*python|#!$(PYTHON_PATH_QUOTED)|' \
+ -e 's|@@GIT_PYTHON_PATH@@|$(GIT_PYTHON_DIR_QUOTED)|g' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
$@.py >$@
chmod +x $@
@@ -474,32 +485,42 @@ git$X git.spec \
%.o: %.S
$(CC) -o $*.o -c $(ALL_CFLAGS) $<
-exec_cmd.o: ALL_CFLAGS += -DGIT_EXEC_PATH=\"$(gitexecdir)\"
+exec_cmd.o: exec_cmd.c
+ $(CC) -o $*.o -c $(ALL_CFLAGS) -DGIT_EXEC_PATH=\"$(gitexecdir)\" $<
git-%$X: %.o $(LIB_FILE)
$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
-git-mailinfo$X : SIMPLE_LIB += $(LIB_4_ICONV)
$(SIMPLE_PROGRAMS) : $(LIB_FILE)
$(SIMPLE_PROGRAMS) : git-%$X : %.o
$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
$(LIB_FILE) $(SIMPLE_LIB)
-git-http-fetch$X: fetch.o http.o
-git-http-push$X: http.o
+git-mailinfo$X: mailinfo.o $(LIB_FILE)
+ $(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
+ $(LIB_FILE) $(SIMPLE_LIB) $(LIB_4_ICONV)
+
git-local-fetch$X: fetch.o
git-ssh-fetch$X: rsh.o fetch.o
git-ssh-upload$X: rsh.o
git-ssh-pull$X: rsh.o fetch.o
git-ssh-push$X: rsh.o
-git-http-fetch$X: LIBS += $(CURL_LIBCURL)
-git-http-push$X: LIBS += $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)
-git-rev-list$X: LIBS += $(OPENSSL_LIBSSL)
+git-http-fetch$X: fetch.o http.o http-fetch.o
+ $(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
+ $(LIBS) $(CURL_LIBCURL)
+
+git-http-push$X: http.o http-push.o
+ $(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
+ $(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)
+
+git-rev-list$X: rev-list.o
+ $(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
+ $(LIBS) $(OPENSSL_LIBSSL)
init-db.o: init-db.c
$(CC) -c $(ALL_CFLAGS) \
- -DDEFAULT_GIT_TEMPLATE_DIR=$(call shellquote,"$(template_dir)") $*.c
+ -DDEFAULT_GIT_TEMPLATE_DIR=$(template_dir_QUOTED) $*.c
$(LIB_OBJS): $(LIB_H)
$(patsubst git-%$X,%.o,$(PROGRAMS)): $(LIB_H)
@@ -531,13 +552,13 @@ check:
### Installation rules
install: all
- $(INSTALL) -d -m755 $(call shellquote,$(DESTDIR)$(bindir))
- $(INSTALL) -d -m755 $(call shellquote,$(DESTDIR)$(gitexecdir))
- $(INSTALL) $(ALL_PROGRAMS) $(call shellquote,$(DESTDIR)$(gitexecdir))
- $(INSTALL) git$X gitk $(call shellquote,$(DESTDIR)$(bindir))
+ $(INSTALL) -d -m755 $(DESTDIR_bindir_QUOTED)
+ $(INSTALL) -d -m755 $(DESTDIR_gitexecdir_QUOTED)
+ $(INSTALL) $(ALL_PROGRAMS) $(DESTDIR_gitexecdir_QUOTED)
+ $(INSTALL) git$X gitk $(DESTDIR_bindir_QUOTED)
$(MAKE) -C templates install
- $(INSTALL) -d -m755 $(call shellquote,$(DESTDIR)$(GIT_PYTHON_DIR))
- $(INSTALL) $(PYMODULES) $(call shellquote,$(DESTDIR)$(GIT_PYTHON_DIR))
+ $(INSTALL) -d -m755 $(DESTDIR_GIT_PYTHON_DIR_QUOTED)
+ $(INSTALL) $(PYMODULES) $(DESTDIR_GIT_PYTHON_DIR_QUOTED)
install-doc:
$(MAKE) -C Documentation install
diff --git a/t/Makefile b/t/Makefile
index 5c5a620..d78404f 100644
--- a/t/Makefile
+++ b/t/Makefile
@@ -8,17 +8,14 @@ SHELL_PATH ?= $(SHELL)
TAR ?= $(TAR)
# Shell quote;
-# Result of this needs to be placed inside ''
-shq = $(subst ','\'',$(1))
-# This has surrounding ''
-shellquote = '$(call shq,$(1))'
+SHELL_PATH_QUOTED = '$(subst ','\'',$(SHELL_PATH))'
T = $(wildcard t[0-9][0-9][0-9][0-9]-*.sh)
all: $(T) clean
$(T):
- @echo "*** $@ ***"; $(call shellquote,$(SHELL_PATH)) $@ $(GIT_TEST_OPTS)
+ @echo "*** $@ ***"; $(SHELL_PATH_QUOTED) $@ $(GIT_TEST_OPTS)
clean:
rm -fr trash
--
1.2.1.g09fe-dirty
^ permalink raw reply related
* [PATCH 0/5] Support ancient systems
From: Johannes Schindelin @ 2006-02-17 14:22 UTC (permalink / raw)
To: git, junkio
Hi,
I just got git to work on an Irix box. These are the changes I needed
to apply. Maybe some of them are of use for other ancient systems... You
know, I like ancient systems. And if I could get my hands on a VMS, I
would try to get git to work on it, too ;-)
Ciao,
Dscho
^ permalink raw reply
* Why can't git-rebase back up?
From: linux @ 2006-02-17 13:59 UTC (permalink / raw)
To: git
Newbie question... In what I assume is a usual technique, I maintain a
"build" branch off of the linux-2.6 history which is what I check out
to build a kernel. I usually keep it at an official tagged releas,
such as v2.6.16-rc2.
[[ This is because core git won't allow the checked-out HEAD to point
to anything but a branch, and checking out something without having
HEAD point to it is fragile and delicate. Cogito lets you do this with
cg-seek. ]]
Now, if I want to migrate to a newer base version, I can always use
git-reset --hard v2.6.16-rc3, but that's a bit dangerous.
Preferable is to use git-rebase v2.6.16-rc3, which will preserve
any local edits.
(I could also do it as a merge, but that seems like unnecessary history
clutter. It's not like local edits are common, anyway.)
But suppose discover a nasty bug in -rc3 and want to move my build branch
back to -rc2. "git-rebase v2.6.16-rc2" does nothing. After a bit
of thought, I realize why, but sometime I do want to back up.
What's the best way to do that? Should git-rebase take an optional
third argument which is the branch head we are moving away from?
E.g. what I want to do would be
git-rebase v2.6.16-rc2 build v2.6.16-rc3
Or is there some other tool already suited to the job?
(Yes, I'm aware the operations cannot be exact inverses, because if
I applied a local patch that was also included in -rc3, git-rebase
will delete the redundant copy from the build branch, and the backing
up will have no way to know to put it back. If I wanted to do that,
I would use a merge.)
On a completely unrelated note, how do I find out what git thinks of a
particular file, such as linux-2.6/.config? It isn't listed in the
output of git-status or git-ls-files, but git-ls-files -i produces an error.
Very confusingly,
git-ls-files -i --exclude-per-directory=.gitignore -X .git/info/exclude .config
also produces no output, even though .* is listed in .gitignore.
^ permalink raw reply
* Re: contrib/ area
From: Aneesh Kumar @ 2006-02-17 12:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmzgq451m.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 410 bytes --]
On 2/17/06, Junio C Hamano <junkio@cox.net> wrote:
>
>
> One final request to Aneesh. Could you send a patch to add a
> bit of blurb and introductory text in contrib/gitview/README,
> please? As it stands, it would be hard to get as much exposure
> as we had hoped by just having it in git.git repository.
>
Attaching below the same in the form of patch generated by git format-patch
-aneesh
[-- Attachment #2: 0001-Add-a-README-for-gitview.txt --]
[-- Type: text/plain, Size: 1296 bytes --]
From nobody Mon Sep 17 00:00:00 2001
From: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Date: Fri Feb 17 18:18:36 2006 +0530
Subject: Add a README for gitview
---
contrib/gitview/gitview.txt | 38 ++++++++++++++++++++++++++++++++++++++
1 files changed, 38 insertions(+), 0 deletions(-)
create mode 100644 contrib/gitview/gitview.txt
36acfaffcbb86bb4c8d2634ea84306a451a9c19b
diff --git a/contrib/gitview/gitview.txt b/contrib/gitview/gitview.txt
new file mode 100644
index 0000000..171295a
--- /dev/null
+++ b/contrib/gitview/gitview.txt
@@ -0,0 +1,38 @@
+gitview(1)
+==========
+
+NAME
+----
+gitview - A GTK based repository browser for git
+
+SYNOPSIS
+--------
+'gitview' [options] [args]
+
+DESCRIPTION
+---------
+
+Dependencies
+
+* Python 2.4
+* PyGTK 2.8 or later
+* PyCairo 1.0 or later
+
+OPTIONS
+------
+ --without-diff
+ If the user doesn't want to list the commit diffs in the main window. This may speed up the repository browsing.
+
+ <args>
+ All the valid option for git-rev-list(1)
+
+EXAMPLES
+------
+ gitview v2.6.12.. include/scsi drivers/scsi
+ Show as the changes since version v2.6.12 that changed any file in the include/scsi
+ or drivers/scsi subdirectories
+
+ gitk --since=2.weeks.ago
+ Show the changes during the last two weeks
+
+
--
1.2.0-dirty
^ permalink raw reply related
* Re: contrib/ area
From: Martin Langhoff @ 2006-02-17 12:24 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: Junio C Hamano, git
In-Reply-To: <873biikx6k.fsf@wine.dyndns.org>
On 2/18/06, Alexandre Julliard <julliard@winehq.org> wrote:
> Is there interest in an emacs interface for git? I posted a first
> version (http://marc.theaimsgroup.com/?l=git&m=113313040724346&w=2)
> some time ago, I'd be happy to send you a patch with my latest version
> if you want to include it.
Yes, please. I'd really like to see it help handle conflicts, and
provide multi-pane views during merges. We are in love with emacs diff
mode for conflict resolution when you end up with .rej files, but it
doesn't kick in properly with the inline conflict markers :-(
cheers,
m
^ permalink raw reply
* Re: contrib/ area
From: Alexandre Julliard @ 2006-02-17 12:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmzgq451m.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> By the way, I have to admit that merging these two were a bit
> painful for me. They came as text attachments to e-mail
> messages, and I ended up hand committing with --author flag,
> while fixing up whitespaces in them [*1*]. I do not want to do
> that again. So if you have new things to add to the contrib/
> area, please first propose it on the list, and after a list
> discussion proves there are some general interests (it does not
> have to be a list-wide consensus for a tool targeted to a
> relatively narrow audience -- for example I do not work with
> projects whose upstream is svn, so I have no use for git-svn
> myself), submit a patch to create a subdirectory of contrib/ and
> put your stuff there.
Is there interest in an emacs interface for git? I posted a first
version (http://marc.theaimsgroup.com/?l=git&m=113313040724346&w=2)
some time ago, I'd be happy to send you a patch with my latest version
if you want to include it.
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply
* Re: Use case: GIT to manage transactions in a CMS?
From: Junio C Hamano @ 2006-02-17 11:44 UTC (permalink / raw)
To: J. David Ibáñez; +Cc: git
In-Reply-To: <43F5AF3C.5050507@itaapy.com>
"J. David Ibáñez" <jdavid@itaapy.com> writes:
> Maybe I could hack something, are there some docs explaining the
> internal format of git objects? or, where to look in the source to
> find this info?
The index file is mostly dealt with by read-cache.c (despite its
name, it has both read and write routines). The easiest way to
understand the tree object format is by reading write-tree.c.
But the format is the easiest part. You have to realize that
this is a nontrivial task.
The merge algorithm assumes that it can detect a presense of
directory by finding a blob under that. You need to teach
'read-tree -m' that sometimes there is an empty directory
recorded in the index file. This is very important to avoid
directory-file conflicts during the merge.
Tree object side is probably easier because we _can_ write an
empty tree object, and presumably three tree-walker
implementations (one used in read-tree and object layer, one in
diff-tree and another in merge-tree) should all handle empty
trees gracefully, but still its callers need to be verified.
> Another point, the application is written in Python, right now
> I have to open a shell to run the git commands.
I always have a shell open so it does not sound a big deal to me
;-).
> It would be nice if the core functionality was implemented in a C
> library, then with a Python wrapper I could use git without going
> through the shell.
>
> Is this something to be expected? There will be a "libgit" sometime
> in the future?
Yes, read the list archive.
But not yet. The core level has been fluctuating quite a bit. The
latest round being the object layer bookkeeping changes.
^ permalink raw reply
* Re: Use case: GIT to manage transactions in a CMS?
From: "J. David Ibáñez" @ 2006-02-17 11:10 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <43F31454.8060704@op5.se>
Andreas Ericsson wrote:
> J. David Ibáñez wrote:
>
>> Hello,
>>
>> I am working on a project (a content management system) where the data
>> is stored as files and folders.
>>
>> Currently, for persistance and transactions we use the ZODB [1] object
>> database. But our goal is to move away from the ZODB and use directly
>> the file system, as it will allow us to use all the good unix tools.
>>
>> We are using git to manage the source code. And now we are exploring git
>> to see if it can do the job of transactions, so that each transaction in
>> the system will be a git commit.
>>
>> One problem we have found is that we can not commit empty directories
>> (what
>> we need to do). Any idea how to solve or work-around this constraint?
>>
>
> $ touch empty/dir/.placeholder
>
>
I would like to have something better, no so much of a work-around.
Maybe I could hack something, are there some docs explaining the
internal format of git objects? or, where to look in the source to
find this info?
>> Any suggestions and input on this exotic use case for git will be very
>> welcomed.
>>
Another point, the application is written in Python, right now I
have to open a shell to run the git commands.
It would be nice if the core functionality was implemented in a C
library, then with a Python wrapper I could use git without going
through the shell.
Is this something to be expected? There will be a "libgit" sometime
in the future?
> Sounds cool. I'll have to give it a whirl when you've got something to
> show.
>
Probably I will have to hack something else to have ACID transactions,
in the short-term. But "git" is at least interesting, since it could
open a world of possibilities. If I ever have something to show, I will
tell you.
--
J. David Ibáñez
Itaapy <http://www.itaapy.com> Tel +33 (0)1 42 23 67 45
9 rue Darwin, 75018 Paris Fax +33 (0)1 53 28 27 88
^ permalink raw reply
* contrib/ area
From: Junio C Hamano @ 2006-02-17 11:07 UTC (permalink / raw)
To: git; +Cc: Aneesh Kumar
As some of you may be aware, I've added contrib/ area to git.git
repository. Currently there are git-svn from Eric and gitview
from Aneesh.
The intention is to keep interesting tools around git, maybe
even experimental ones, to give users an easier access to them,
and to give tools wider exposure, so that they can be improved
faster.
I am expecting not to touch them myself that much. As far as my
day-to-day operation is concerned, contrib/git-svn is owned by
Eric and contrib/gitview by Aneesh. I am willing to help if
users of these components and the contrib/ subtree "owners" have
technical/design issues to resolve, but the initiative to fix
and/or enhance things _must_ be on the side of the subtree
owners. IOW, I won't be actively looking for bugs and rooms for
enhancements in them as the git maintainer -- I may only do so
just as one of the users when I want to scratch my own itch. If
you have patches to things in contrib/ area, the patch should be
first sent to the primary author, and then the primary author
should ack and forward it to me (git pull request is nicer).
This is the same way as how I treated gitk, so you know the
drill.
I expect that things that start their life in the contrib/ area
to graduate out of contrib/ once they mature, either by becoming
projects on their own, or moving to the toplevel directory. On
the other hand, I expect I'll be proposing removal of disused
and inactive ones from time to time.
By the way, I have to admit that merging these two were a bit
painful for me. They came as text attachments to e-mail
messages, and I ended up hand committing with --author flag,
while fixing up whitespaces in them [*1*]. I do not want to do
that again. So if you have new things to add to the contrib/
area, please first propose it on the list, and after a list
discussion proves there are some general interests (it does not
have to be a list-wide consensus for a tool targeted to a
relatively narrow audience -- for example I do not work with
projects whose upstream is svn, so I have no use for git-svn
myself), submit a patch to create a subdirectory of contrib/ and
put your stuff there.
One final request to Aneesh. Could you send a patch to add a
bit of blurb and introductory text in contrib/gitview/README,
please? As it stands, it would be hard to get as much exposure
as we had hoped by just having it in git.git repository.
[Footnote]
*1* I _am_ picky about whitespaces, and I would encourage people
to enable the pre-commit example hook.
^ permalink raw reply
* [PATCH] pack-objects: finishing touches.
From: Junio C Hamano @ 2006-02-17 10:37 UTC (permalink / raw)
To: git
In-Reply-To: <7vu0ay8v4f.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> This one has one nasty data corruption bug, which fortunately I
> think I have figured out how to fix. Please do not use it for
> your production repository in the meantime.
It turns out that there wasn't a data corruption bug, but it can
create a pack with delta chains whose length exceeds twice the
specified depth. The data corruption bug was on my unpublished
WIP and killed even before it hit "pu" ;-). This addresses most
of the remaining issues and has been merged to "next" tonight.
-- >8 --
This introduces --no-reuse-delta option to disable reusing of
existing delta, which is a large part of the optimization
introduced by this series. This may become necessary if
repeated repacking makes delta chain too long. With this, the
output of the command becomes identical to that of the older
implementation.
It still allows reusing non-deltified representations; there is
no point uncompressing and recompressing the whole text.
It also adds a couple more statistics output, while squelching
it under -q flag, which the last round forgot to do.
One remaining minor issue when --no-reuse-delta option is not
used is that it can create a delta chain that is deeper than
specified.
A<--B<--C<--D E F G
Suppose we have a delta chain A to D (A is stored in full either
in a pack or as a loose object. B is depth1 delta relative to A,
C is depth2 delta relative to B...) with loose objects E, F, G.
And we are going to pack them.
B, C and D are left as delta against A, B and C respectively.
So A, E, F, and G are examined, and let's say we decided to keep
E expanded, and store the rest as deltas like this:
E<--F<--G<--A
Oops. We ended up making D a bit too deep, didn't we? B, C and
D form a chain on top of A!
This is because we did not know what the final depth of A would
be when checking objects and deciding to keep the existing
delta.
To prevent this from happening, we could say that A should be
kept expanded. But how would we tell that, cheaply?
To do this most precisely, after check_object() runs, each
object that is used as the base object of some existing delta
needs to be marked with the maximum depth of the objects we
decided to keep deltified (in this case, D is depth 3 relative
to A, so if no other delta chain that is longer than 3 based on
A exists, mark A with 3). Then when attempting to deltify A, we
would take that number into account to see if the final delta
chain that leads to D becomes too deep.
However, this is a bit cumbersome to compute, so we would cheat
and reduce the maximum depth for A arbitrarily to depth/4 in
this implementation.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Documentation/git-pack-objects.txt | 21 +++++++
pack-objects.c | 102 +++++++++++++++++++++++++-----------
2 files changed, 91 insertions(+), 32 deletions(-)
98885061623676a37575e59d7f7aff64072e3300
diff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt
index 2d67d39..4cb2e83 100644
--- a/Documentation/git-pack-objects.txt
+++ b/Documentation/git-pack-objects.txt
@@ -8,7 +8,10 @@ git-pack-objects - Create a packed archi
SYNOPSIS
--------
-'git-pack-objects' [--non-empty] [--local] [--incremental] [--window=N] [--depth=N] {--stdout | base-name} < object-list
+[verse]
+'git-pack-objects' [-q] [--no-reuse-delta] [--non-empty]
+ [--local] [--incremental] [--window=N] [--depth=N]
+ {--stdout | base-name} < object-list
DESCRIPTION
@@ -32,6 +35,10 @@ Placing both in the pack/ subdirectory o
any of the directories on $GIT_ALTERNATE_OBJECT_DIRECTORIES)
enables git to read from such an archive.
+In a packed archive, an object is either stored as a compressed
+whole, or as a difference from some other object. The latter is
+often called a delta.
+
OPTIONS
-------
@@ -74,6 +81,18 @@ base-name::
Only create a packed archive if it would contain at
least one object.
+-q::
+ This flag makes the command not to report its progress
+ on the standard error stream.
+
+--no-reuse-delta::
+ When creating a packed archive in a repository that
+ has existing packs, the command reuses existing deltas.
+ This sometimes results in a slightly suboptimal pack.
+ This flag tells the command not to reuse existing deltas
+ but compute them from scratch.
+
+
Author
------
Written by Linus Torvalds <torvalds@osdl.org>
diff --git a/pack-objects.c b/pack-objects.c
index 70fb2af..38e1c99 100644
--- a/pack-objects.c
+++ b/pack-objects.c
@@ -5,7 +5,7 @@
#include "csum-file.h"
#include <sys/time.h>
-static const char pack_usage[] = "git-pack-objects [-q] [--non-empty] [--local] [--incremental] [--window=N] [--depth=N] {--stdout | base-name} < object-list";
+static const char pack_usage[] = "git-pack-objects [-q] [--no-reuse-delta] [--non-empty] [--local] [--incremental] [--window=N] [--depth=N] {--stdout | base-name} < object-list";
struct object_entry {
unsigned char sha1[20];
@@ -14,10 +14,11 @@ struct object_entry {
unsigned int depth; /* delta depth */
unsigned int hash; /* name hint hash */
enum object_type type;
+ unsigned char edge; /* reused delta chain points at this entry. */
+ enum object_type in_pack_type; /* could be delta */
unsigned long delta_size; /* delta data size (uncompressed) */
struct object_entry *delta; /* delta base object */
struct packed_git *in_pack; /* already in pack */
- enum object_type in_pack_type; /* could be delta */
unsigned int in_pack_offset;
};
@@ -36,6 +37,7 @@ struct object_entry {
static unsigned char object_list_sha1[20];
static int non_empty = 0;
+static int no_reuse_delta = 0;
static int local = 0;
static int incremental = 0;
static struct object_entry **sorted_by_sha, **sorted_by_type;
@@ -75,7 +77,9 @@ static int pack_revindex_hashsz = 0;
* stats
*/
static int written = 0;
+static int written_delta = 0;
static int reused = 0;
+static int reused_delta = 0;
static int pack_revindex_ix(struct packed_git *p)
{
@@ -227,10 +231,23 @@ static unsigned long write_object(struct
unsigned char header[10];
unsigned hdrlen, datalen;
enum object_type obj_type;
+ int to_reuse = 0;
obj_type = entry->type;
- if (!entry->in_pack ||
- (obj_type != entry->in_pack_type)) {
+ if (! entry->in_pack)
+ to_reuse = 0; /* can't reuse what we don't have */
+ else if (obj_type == OBJ_DELTA)
+ to_reuse = 1; /* check_object() decided it for us */
+ else if (obj_type != entry->in_pack_type)
+ to_reuse = 0; /* pack has delta which is unusable */
+ else if (entry->delta)
+ to_reuse = 0; /* we want to pack afresh */
+ else
+ to_reuse = 1; /* we have it in-pack undeltified,
+ * and we do not need to deltify it.
+ */
+
+ if (! to_reuse) {
buf = read_sha1_file(entry->sha1, type, &size);
if (!buf)
die("unable to read %s", sha1_to_hex(entry->sha1));
@@ -266,8 +283,12 @@ static unsigned long write_object(struct
sha1write(f, buf, datalen);
unuse_packed_git(p);
hdrlen = 0; /* not really */
+ if (obj_type == OBJ_DELTA)
+ reused_delta++;
reused++;
}
+ if (obj_type == OBJ_DELTA)
+ written_delta++;
written++;
return hdrlen + datalen;
}
@@ -294,7 +315,6 @@ static void write_pack_file(void)
int i;
struct sha1file *f;
unsigned long offset;
- unsigned long mb;
struct pack_header hdr;
if (!base_name)
@@ -357,10 +377,9 @@ static int add_object_entry(unsigned cha
unsigned int idx = nr_objects;
struct object_entry *entry;
struct packed_git *p;
- unsigned int found_offset;
- struct packed_git *found_pack;
+ unsigned int found_offset = 0;
+ struct packed_git *found_pack = NULL;
- found_pack = NULL;
for (p = packed_git; p; p = p->next) {
struct pack_entry e;
if (find_pack_entry_one(sha1, &e, p)) {
@@ -420,32 +439,39 @@ static void check_object(struct object_e
char type[20];
if (entry->in_pack) {
+ unsigned char base[20];
+ unsigned long size;
+ struct object_entry *base_entry;
+
+ /* We want in_pack_type even if we do not reuse delta.
+ * There is no point not reusing non-delta representations.
+ */
+ check_reuse_pack_delta(entry->in_pack,
+ entry->in_pack_offset,
+ base, &size,
+ &entry->in_pack_type);
+
/* Check if it is delta, and the base is also an object
* we are going to pack. If so we will reuse the existing
* delta.
*/
- unsigned char base[20];
- unsigned long size;
- struct object_entry *base_entry;
- if (!check_reuse_pack_delta(entry->in_pack,
- entry->in_pack_offset,
- base, &size,
- &entry->in_pack_type) &&
+ if (!no_reuse_delta &&
+ entry->in_pack_type == OBJ_DELTA &&
(base_entry = locate_object_entry(base))) {
- /* We do not know depth at this point, but it
- * does not matter. Getting delta_chain_length
- * with packed_object_info_detail() is not so
- * expensive, so we could do that later if we
- * wanted to. Calling sha1_object_info to get
- * the true size (and later an uncompressed
- * representation) of deeply deltified object
- * is quite expensive.
+
+ /* Depth value does not matter - find_deltas()
+ * will never consider reused delta as the
+ * base object to deltify other objects
+ * against, in order to avoid circular deltas.
*/
- entry->depth = 1;
- /* uncompressed size */
+
+ /* uncompressed size of the delta data */
entry->size = entry->delta_size = size;
entry->delta = base_entry;
entry->type = OBJ_DELTA;
+
+ base_entry->edge = 1;
+
return;
}
/* Otherwise we would do the usual */
@@ -568,6 +594,13 @@ static int try_delta(struct unpacked *cu
if (cur_entry->type != old_entry->type)
return -1;
+ /* If the current object is at edge, take the depth the objects
+ * that depend on the current object into account -- otherwise
+ * they would become too deep.
+ */
+ if (cur_entry->edge)
+ max_depth /= 4;
+
size = cur_entry->size;
if (size < 50)
return -1;
@@ -627,7 +660,7 @@ static void find_deltas(struct object_en
if (entry->delta)
/* This happens if we decided to reuse existing
- * delta from a pack.
+ * delta from a pack. "!no_reuse_delta &&" is implied.
*/
continue;
@@ -636,6 +669,7 @@ static void find_deltas(struct object_en
n->data = read_sha1_file(entry->sha1, type, &size);
if (size != entry->size)
die("object %s inconsistent object length (%lu vs %lu)", sha1_to_hex(entry->sha1), size, entry->size);
+
j = window;
while (--j > 0) {
unsigned int other_idx = idx + j;
@@ -664,7 +698,7 @@ static void prepare_pack(int window, int
fprintf(stderr, "Packing %d objects", nr_objects);
get_object_details();
if (progress)
- fprintf(stderr, ".");
+ fputc('.', stderr);
sorted_by_type = create_sorted_list(type_size_sort);
if (window && depth)
@@ -694,8 +728,9 @@ static int reuse_cached_pack(unsigned ch
}
}
- fprintf(stderr, "Reusing %d objects pack %s\n", nr_objects,
- sha1_to_hex(sha1));
+ if (progress)
+ fprintf(stderr, "Reusing %d objects pack %s\n", nr_objects,
+ sha1_to_hex(sha1));
if (pack_to_stdout) {
if (copy_fd(ifd, 1))
@@ -775,6 +810,10 @@ int main(int argc, char **argv)
progress = 0;
continue;
}
+ if (!strcmp("--no-reuse-delta", arg)) {
+ no_reuse_delta = 1;
+ continue;
+ }
if (!strcmp("--stdout", arg)) {
pack_to_stdout = 1;
continue;
@@ -850,7 +889,8 @@ int main(int argc, char **argv)
puts(sha1_to_hex(object_list_sha1));
}
}
- fprintf(stderr, "Total %d, written %d, reused %d\n",
- nr_objects, written, reused);
+ if (progress)
+ fprintf(stderr, "Total %d, written %d (delta %d), reused %d (delta %d)\n",
+ nr_objects, written, written_delta, reused, reused_delta);
return 0;
}
--
1.2.1.g91016
^ 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