* git-cvs-import and branches
From: Martin Mares @ 2006-02-17 19:55 UTC (permalink / raw)
To: git; +Cc: CVSps
Hello!
I'm git-importing a rather large CVS repository with lots of branches and
although the mainline is imported correctly, the branches aren't. They
usually contain some changes introduced to the ancestor branch after
the point the new branch has been tagged.
I haven't studied git-cvsimport and cvsps in much detail yet, but it seems
that git-cvsimport forks off the branch at the first patchset reported by
cvsps which mentions the branch and copies the current state of the ancestor
branch at that time.
This doesn't seem to be correct, since many changes might have happened
to the ancestor branch since the real branching point. However, since
cvsps doesn't report the branching points (and they aren't exact points anyway
since tagging is not atomic in CVS), I don't see how to make cvsimport
find the right starting revision.
Does anybody have an idea how to solve this?
Have a nice fortnight
--
Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
COBOL -- Completely Outdated, Badly Overused Language
^ permalink raw reply
* git-cvs-import retries
From: Martin Mares @ 2006-02-17 19:38 UTC (permalink / raw)
To: git
Hello!
I am trying git-cvsimport on a rather huge repository and the CVS server
sometimes drops the connection and the whole importing aborts, although
it contains some retrying logic. I've noticed that in the connection closes
I experience, $res ends up being empty instead of undefined. This is tested
by the `server went again' check, but not by the retry check a couple of
lines before.
This patch extends the retry check and makes the symptoms go away.
However, take it with a grain of salt as I don't understand yet why the
connection is aborted.
Have a nice fortnight
--
Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
A jury consists of 12 persons chosen to decide who has the better lawyer.
Signed-Off-By: Martin Mares <mj@ucw.cz>
--- old/git-cvsimport 2006-02-17 13:02:24.000000000 +0100
+++ new/git-cvsimport 2006-02-17 18:13:06.000000000 +0100
@@ -371,7 +371,7 @@
$self->_file($fn,$rev) and $res = $self->_line($fh);
- if (!defined $res) {
+ if (!defined $res || $res eq '') {
# retry
$self->conn();
$self->_file($fn,$rev)
^ permalink raw reply
* Re: [PATCH] pack-objects: reuse data from existing pack.
From: Junio C Hamano @ 2006-02-17 18:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0602170738390.916@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> 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?
Circular deltas are prevented by not using deltified objects
check_object() decides to keep in find_deltas(), so I do not
think it is an issue.
^ permalink raw reply
* 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
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