* Re: [PATCH] [GITK] use "git <command>" instead of "git-<command>"
From: Junio C Hamano @ 2006-01-25 9:52 UTC (permalink / raw)
To: Uwe Zeisberger; +Cc: git
In-Reply-To: <20060125075635.GB2768@informatik.uni-freiburg.de>
Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de> writes:
> Otherwise gitk is not able to work with installations using a gitexecdir
> different from bindir.
For something like gitk that lives for some time and spawns git
number of times, it is considered a good practice to:
(1) Run "git --exec-path" at the beginning, to learn
GIT_EXEC_PATH;
(2) Prepend that to PATH;
(3) And invoke "git-foo" commands in the rest of the script.
This saves an extra fork/exec (gitk -> git -> git-foo). I was
told qgit already does this.
Note that we may end up leaving some git-* commands in /usr/bin
while moving the rest to elsewhere (e.g. /usr/lib/git-core/exec/),
so (2) and (3) cannot be safely substituted with
(BAD) invoke "$GIT_EXEC_PATH/git-foo" instead.
I usually prefer patches to gitk to come through paulus, so
please CC: when sending patches to gitk ("git whatchanged gitk"
would give you the e-mail address).
^ permalink raw reply
* Re: git describe fails without tags
From: Junio C Hamano @ 2006-01-25 9:52 UTC (permalink / raw)
To: Uwe Zeisberger; +Cc: git
In-Reply-To: <20060125074725.GA2768@informatik.uni-freiburg.de>
Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de> writes:
> I wonder if it would be sane to assume an implicit tag for the empty
> repository, s.t. git describe results in
>
> <empty>-62ac6c16
>
> (whatever name is choosen for <empty>).
>
> Any opinions?
The value of 'describe' is not in the 62ac6c part, but in the
tag part, which lets us find out that the rev in question is at
least newer than that tag. If the reason you are doing
"describe" is to find out an usable abbreviated name, you could
feed the first few hexdigits to "git rev-parse --verify",
lengthening the prefix longer by one until it says you have a
unique prefix [*1*].
In other words, not particularly interested, although it is
trivial to implement, like this:
diff --git a/describe.c b/describe.c
index 4866510..aeaf0fb 100644
--- a/describe.c
+++ b/describe.c
@@ -137,7 +137,7 @@ static void describe(char *arg, int last
return;
}
}
- die("cannot describe '%s'", sha1_to_hex(cmit->object.sha1));
+ printf("%s\n", find_unique_abbrev(cmit->object.sha1, abbrev));
}
int main(int argc, char **argv)
[Footnote]
*1* If you do this often, we could introduce
$ git rev-parse --abbrev=<n> HEAD
that quacks like --verify (i.e. makes sure there is a single
"extended SHA1 expression" that evaluates to a valid object
name) but outputs the result abbreviated to at least <n>
hexdigits.
This has an added advantage that it would work on a
non-commit object name.
-- >8 --
[PATCH] rev-parse: --abbrev option.
The new option behaves just like --verify, but outputs an
abbreviated object name that is unique within the repository.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
rev-parse.c | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
3c7c31a913c3c4060e85f2919e2136412928dcec
diff --git a/rev-parse.c b/rev-parse.c
index 0c951af..c1646e4 100644
--- a/rev-parse.c
+++ b/rev-parse.c
@@ -20,6 +20,7 @@ static char *def = NULL;
#define REVERSED 1
static int show_type = NORMAL;
static int symbolic = 0;
+static int abbrev = 0;
static int output_sq = 0;
static int revs_count = 0;
@@ -95,6 +96,8 @@ static void show_rev(int type, const uns
putchar('^');
if (symbolic && name)
show(name);
+ else if (abbrev)
+ show(find_unique_abbrev(sha1, abbrev));
else
show(sha1_to_hex(sha1));
}
@@ -195,6 +198,17 @@ int main(int argc, char **argv)
verify = 1;
continue;
}
+ if (!strcmp(arg, "--abbrev") ||
+ !strncmp(arg, "--abbrev=", 9)) {
+ filter &= ~(DO_FLAGS|DO_NOREV);
+ verify = 1;
+ abbrev = DEFAULT_ABBREV;
+ if (arg[8] == '=')
+ abbrev = strtoul(arg + 9, NULL, 10);
+ if (abbrev < 0 || 40 <= abbrev)
+ abbrev = DEFAULT_ABBREV;
+ continue;
+ }
if (!strcmp(arg, "--sq")) {
output_sq = 1;
continue;
--
1.1.4.g869a
^ permalink raw reply related
* Re: [PATCH] rev-{list,parse}: allow -<n> as shorthand for --max-count=<n>
From: Junio C Hamano @ 2006-01-25 9:52 UTC (permalink / raw)
To: Eric Wong; +Cc: git list
In-Reply-To: <20060125063325.GA7953@mail.yhbt.net>
Eric Wong <normalperson@yhbt.net> writes:
> I don't agree with POSIX on this point, and I don't see why git should
> be bound to POSIX, especially at the UI level just because it's POSIX.
Unfortunately, it does not matter in the real world that you and
I both do not particularly like "head -n 4". We will see more
people who feel "-n 4" more familiar than "-4", unlike old
fashioned people like myself.
> ... Heck, I've
> been wanting GNU getopt_long() option parsing in git for a while...
We find somebody who wants to do this every now and then, it
seems. Last time somebody brought this up in late May 2005, we
were still a "too rapidly moving" target, adding and changing
options every other day, and the actual implementation went
nowhere while the discussion was reasonably healthy. If I
recall the discussion correctly, argp instead of GNU getopt was
the list favorite back then...
^ permalink raw reply
* Re: [PATCH] diff-tree -c: show a merge commit a bit more sensibly.
From: Florian Weimer @ 2006-01-25 12:35 UTC (permalink / raw)
To: git
In-Reply-To: <7vwtgqas0y.fsf@assigned-by-dhcp.cox.net>
* Junio C. Hamano:
> A new option '-c' to diff-tree changes the way a merge commit is
> displayed when generating a patch output. It shows a "combined
> diff" (hence the option letter 'c'), which looks like this:
>
> $ git-diff-tree --pretty -c -p fec9ebf1 | head -n 18
> diff-tree fec9ebf... (from parents)
> Merge: 0620db3... 8a263ae...
> Author: Junio C Hamano <junkio@cox.net>
> Date: Sun Jan 15 22:25:35 2006 -0800
>
> Merge fixes up to GIT 1.1.3
>
> diff --combined describe.c
> @@ +99,18 @@
> }
>
> - static void describe(char *arg)
> - static void describe(struct commit *cmit, int last_one)
> ++ static void describe(char *arg, int last_one)
Maybe it would make sense to include a lines like these?
# 0620db3... (Merge branch 'fix')
# 8a263ae... (GIT 1.1.3)
## fec9ebf... (Merge fixes up to GIT 1.1.3)
This would make more clear which columns corresponds to which parent.
^ permalink raw reply
* [RFD] remembering hand resolve...
From: Junio C Hamano @ 2006-01-25 13:00 UTC (permalink / raw)
To: git
As people on the list may know, I keep many mini topic-branches
and keep combining them on top of then-current master to publish
"pu". This involves resolving merge conflicts by hand, when the
areas topic-branches touch overlap.
The thing is, I find myself resolving the same conflicts over
and over. This is because the master branch tends to advance
faster than topic branches that touch an overlapping area. I'd
take more time than I usually do to decide what to do with them;
as a result, overlapping topic branches tend to stay unmerged
into "master" longer than other topic branches.
If I linearize topic-branches that conflict with each other in
some way, say base topic B on top of topic A, I would not have
problem merging them into "pu" as long as I do not change my
mind later and try to merge only topic B without topic A. But
that defeats the whole point of having independent topic
branches.
I would imagine that people who use StGIT or quilt would have
similar issues. If they are in the same series, then inside of
that queue the patches are already ordered to be in some way,
probably conflict is resolved once when the patch is refreshed
and they stay applicable as long as the base part cleanly
applies to the updated base version, but patches in the queue
then depend on the earlier ones in the same series, and
extracting and applying only the later parts of the queue would
need you to manually un-resolve the conflict you earlier
resolved. If you keep different topics in separate queues, on
the other hand, I would imagine you would have exactly the same
"oh, I know this and that patch conflict with each other and I
recall I resolved that last time I merged everything up" issue.
How do people on patch-queue based systems like StGIT and quilt
deal with this? I am wondering if somebody have a clever idea
to record and reuse an earlier conflict resolution.
A trivial solution would be to save the diff between conflicted
automerge result before hand resolving, and the result of my
hand resolve, and apply with "patch" when I see a conflicted
automerge the next time. I've tried this by hand and it worked
quite well tonight, but I felt it was somewhat kludgy. We
should be able to do better than that, with some tool support.
Another obvious way is to avoid rebuilding "pu"; instead I could
pull "master" into "pu" every time I have added something new to
"master". That would work most of the time, until I decide to
change the order the topic branches are merged into "pu" (or
drop one of them).
^ permalink raw reply
* What's in git.git
From: Junio C Hamano @ 2006-01-25 13:00 UTC (permalink / raw)
To: git
I've pushed out the following changes to "master" branch:
* git-clone
. --naked option is still accepted but is deprecated. Please
say --bare.
. a repository cloned with --bare does not get "origin"
branch, nor remotes/origin file.
. Earlier we accepted more than one -o options, without
complaining. We now complain.
* fetch and peek/ls-remote (Michal Ostrowski)
. --upload-pack option to the underlying git-peek-remote and
friends can be passed from the barebone Porcelain.
* local push/pull environment fix (Matt Draisey)
. We now clean "GIT_DIR" and friends from the environment
when spawning a program on the other end to drive git
native protocols on a local machine. This uses unsetenv(),
which is not strictly portable, but I was too lazy to fix
it myself. I am hoping that Jason Riedy will scream and
give us a patch to make it work again on his Solaris box
;-).
* sample update-hook rewrite (Andreas Ericsson)
* asciidoc --unsafe workaround (Pavel Roskin)
In the "pu" branch, there are some interesting changes. The
most immediately visible usability enhancement is the "combined
diff" option to git-diff-tree command. Interested people can
try something like this:
$ git checkout pu
$ make clean strip all install
$ git checkout master
Do not forget to come back to your "master" branch once you are
done, or your next pull would be screwed.
$ git whatchanged --cc --abbrev pu
This would show an improved version of "git whatchanged -m -p".
The difference is that it uses the "dense combined diff"
suggested by Linus yesterday. Commits near the tip of "pu" tend
to be Octopus, and you would see quite interesting combined
diffs for them. I am not proud of the implementation itself,
and I am sure there are more bugs to be discovered, but overall
I am reasonably happy with what it shows. Once it stabilizes,
it would be a good addition to gitweb UI. In addition to the
"commitdiff" next to each parent, there would be an extra link
in a merge commit to get a combined diff.
The "annotate helper" change by Linus and "bound commit"
subproject support experiments are there as before.
There are other minor fixes and enhancements. Not all of them
may make it to "master":
* "diff-tree --abbrev --pretty" was still showing full 40
characters of commit object names on "Merge:" line.
* "rev-parse --abbrev[=<n>] $rev" is similar to
"rev-parse --verify $rev", except that it shows an
abbreviated object name.
* The flag argument was handled confusingly by "rev-parse
[--flags|--no-flags]". The command now treats anything that
come after --flags/--no-flags things to be parsed, not an
option to control what the command does. This was primarily
needed to allow parsing out "--abbrev" option and giving it
to "diff-tree" inside whatchanged. All existing users have
been adjusted to this change. I do not think any of Cogito,
gitk, nor stgit is affected.
^ permalink raw reply
* Re: StGIT: defaults for authname, authemail
From: Catalin Marinas @ 2006-01-25 13:39 UTC (permalink / raw)
To: Andrey Borzenkov; +Cc: git
In-Reply-To: <200601242213.36996.arvidjaar@mail.ru>
Andrey Borzenkov <arvidjaar@mail.ru> wrote:
> Would be nice if StGIT honored GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL if they are
> set and took them as default. Would be more plug'n'play, I was rather
> surprised why stg export gave me From: <>.
Indeed, that's a bug. The GIT commit is properly created since GIT
will use the environment but the export and mail commands are not
aware of this (they only use the ~/.stgitrc or .git/stgitrc files).
Thanks for pointing out.
--
Catalin
^ permalink raw reply
* Re: [RFD] remembering hand resolve...
From: Andreas Ericsson @ 2006-01-25 13:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4q3ssbr6.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> As people on the list may know, I keep many mini topic-branches
> and keep combining them on top of then-current master to publish
> "pu". This involves resolving merge conflicts by hand, when the
> areas topic-branches touch overlap.
>
> The thing is, I find myself resolving the same conflicts over
> and over. This is because the master branch tends to advance
> faster than topic branches that touch an overlapping area.
How can that be possible? If the area of code in master is modified
beyond simple merging from the topic-branches, the resulting diff (which
has to be against master's HEAD) should apply cleanly so long as there
aren't *new* changes to master, in which case the pu commit needs
adaptation again, so it wouldn't really be the same conflict (or even
necessarily a similar one), would it?
> If I linearize topic-branches that conflict with each other in
> some way, say base topic B on top of topic A, I would not have
> problem merging them into "pu" as long as I do not change my
> mind later and try to merge only topic B without topic A. But
> that defeats the whole point of having independent topic
> branches.
>
Wouldn't cherry-pick be useful here? If it isn't, I fail to understand
how a merge can solve it for you. Admittedly, I know little of the inner
workings of git.
>
> A trivial solution would be to save the diff between conflicted
> automerge result before hand resolving, and the result of my
> hand resolve, and apply with "patch" when I see a conflicted
> automerge the next time. I've tried this by hand and it worked
> quite well tonight, but I felt it was somewhat kludgy. We
> should be able to do better than that, with some tool support.
>
> Another obvious way is to avoid rebuilding "pu"; instead I could
> pull "master" into "pu" every time I have added something new to
> "master". That would work most of the time, until I decide to
> change the order the topic branches are merged into "pu" (or
> drop one of them).
>
Couldn't you do something like this:
for t in $topic_branches; do
checkout $t
git rebase master
done
git checkout master
git branch -D pu
git checkout -b pu
git pull . $topic_branches
That's what I thought you were doing right now, but I can't imagine that
flow leading to the same conflicts over and over, so I must be mistaken
somehow.
--
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: Junio C Hamano @ 2006-01-25 19:24 UTC (permalink / raw)
To: Santi Bejar; +Cc: git
In-Reply-To: <8aa486160601250741k120f0021h@mail.gmail.com>
Santi Bejar <sbejar@gmail.com> writes:
> I think we should be consistent with respect the leading dots. Now the
> diff-tree line has the dots, but the merge line do not.
This is deliberate. Merge lines do not have to align with
anything else for readability.
^ permalink raw reply
* [PATCH] Fix git-format-patch -s to include a Signed-off-by: line...
From: Eric W. Biederman @ 2006-01-25 20:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7voe212h53.fsf@assigned-by-dhcp.cox.net>
In the last round of bug fixes the signed-off-by line was still be
generated but it was not including a signed-off-by line :(
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
git-format-patch.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
78308e7078be1beb979def50579722910f2ff54f
diff --git a/git-format-patch.sh b/git-format-patch.sh
index 7e67c4e..5fb8ce1 100755
--- a/git-format-patch.sh
+++ b/git-format-patch.sh
@@ -178,7 +178,7 @@ my ($signoff_pattern, $done_header, $don
$last_was_signoff);
if ($signoff) {
- $signoff = `git-var GIT_COMMITTER_IDENT`;
+ $signoff = "Signed-off-by: " . `git-var GIT_COMMITTER_IDENT`;
$signoff =~ s/>.*/>/;
$signoff_pattern = quotemeta($signoff);
}
--
1.1.4.g7830
^ permalink raw reply related
* Re: What's in git.git
From: Jason Riedy @ 2006-01-25 20:36 UTC (permalink / raw)
To: git
In-Reply-To: <7vy814qx6o.fsf@assigned-by-dhcp.cox.net>
And Junio C Hamano writes:
- This uses unsetenv(), which is not strictly portable, but
- I was too lazy to fix it myself.
And you manage to catch me on the one day in the last month
I've played with git code... Patch to add compat/unsetenv.c
coming shortly. Passes unit tests and make test as well as
before (I have some wierd, local-only cpio problems), but I
haven't used this extensively.
People _with_ unsetenv can still add compat functions, you
know. ;)
Jason
^ permalink raw reply
* [PATCH] Run GIT-VERSION-GEN with $(SHELL), not sh.
From: Jason Riedy @ 2006-01-25 20:37 UTC (permalink / raw)
To: git
Alas, not all shells named sh are capable enough to run
GIT-VERSION-GEN.
Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
---
Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
ba55c17e4888568cf17da569f95f11e27a26072d
diff --git a/Makefile b/Makefile
index 3046056..245f658 100644
--- a/Makefile
+++ b/Makefile
@@ -67,7 +67,7 @@ all:
# change being considered an inode change from the update-cache perspective.
GIT-VERSION-FILE: .FORCE-GIT-VERSION-FILE
- @sh ./GIT-VERSION-GEN
+ @$(SHELL) ./GIT-VERSION-GEN
-include GIT-VERSION-FILE
# CFLAGS and LDFLAGS are for the users to override from the command line.
--
1.0.GIT
^ permalink raw reply related
* [PATCH] Add compat/unsetenv.c .
From: Jason Riedy @ 2006-01-25 20:38 UTC (permalink / raw)
To: git
Implement a (slow) unsetenv() for older systems.
Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
---
Makefile | 5 +++++
compat/unsetenv.c | 26 ++++++++++++++++++++++++++
connect.c | 1 +
git-compat-util.h | 5 +++++
4 files changed, 37 insertions(+), 0 deletions(-)
create mode 100644 compat/unsetenv.c
30e532bf9194724ac7923b07236ec8d3cdfe4a8a
diff --git a/Makefile b/Makefile
index 245f658..2e95353 100644
--- a/Makefile
+++ b/Makefile
@@ -232,6 +232,7 @@ ifeq ($(uname_S),SunOS)
SHELL_PATH = /bin/bash
NO_STRCASESTR = YesPlease
ifeq ($(uname_R),5.8)
+ NO_UNSETENV = YesPlease
NO_SETENV = YesPlease
endif
INSTALL = ginstall
@@ -355,6 +356,10 @@ ifdef NO_SETENV
COMPAT_CFLAGS += -DNO_SETENV
COMPAT_OBJS += compat/setenv.o
endif
+ifdef NO_SETENV
+ COMPAT_CFLAGS += -DNO_UNSETENV
+ COMPAT_OBJS += compat/unsetenv.o
+endif
ifdef NO_MMAP
COMPAT_CFLAGS += -DNO_MMAP
COMPAT_OBJS += compat/mmap.o
diff --git a/compat/unsetenv.c b/compat/unsetenv.c
new file mode 100644
index 0000000..3a5e4ec
--- /dev/null
+++ b/compat/unsetenv.c
@@ -0,0 +1,26 @@
+#include <stdlib.h>
+#include <string.h>
+
+void gitunsetenv (const char *name)
+{
+ extern char **environ;
+ int src, dst;
+ size_t nmln;
+
+ nmln = strlen(name);
+
+ for (src = dst = 0; environ[src]; ++src) {
+ size_t enln;
+ enln = strlen(environ[src]);
+ if (enln > nmln) {
+ /* might match, and can test for '=' safely */
+ if (0 == strncmp (environ[src], name, nmln)
+ && '=' == environ[src][nmln])
+ /* matches, so skip */
+ continue;
+ }
+ environ[dst] = environ[src];
+ ++dst;
+ }
+ environ[dst] = NULL;
+}
diff --git a/connect.c b/connect.c
index e1c04e1..3f2d65c 100644
--- a/connect.c
+++ b/connect.c
@@ -1,3 +1,4 @@
+#include "git-compat-util.h"
#include "cache.h"
#include "pkt-line.h"
#include "quote.h"
diff --git a/git-compat-util.h b/git-compat-util.h
index 12ce659..f982b8e 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -63,6 +63,11 @@ extern int gitfakemunmap(void *start, si
extern int gitsetenv(const char *, const char *, int);
#endif
+#ifdef NO_UNSETENV
+#define unsetenv gitunsetenv
+extern void gitunsetenv(const char *);
+#endif
+
#ifdef NO_STRCASESTR
#define strcasestr gitstrcasestr
extern char *gitstrcasestr(const char *haystack, const char *needle);
--
1.0.GIT
^ permalink raw reply related
* Make git-rev-list and git-rev-parse argument parsing stricter
From: Linus Torvalds @ 2006-01-25 22:00 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
If you pass it a filename without the "--" marker to separate it from
revision information and flags, we now require that the file in question
actually exists. This makes mis-typed revision information not be silently
just considered a strange filename.
With the "--" marker, you can continue to pass in filenames that do not
actually exists - useful for querying what happened to a file that you
no longer have in the repository.
[ All scripts should use the "--" format regardless, to make things
unambiguous. So this change should not affect any existing tools ]
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
----
I hit this the hard way when I was showing off git at Linux.Conf.Au
yesterday, and I asked for
git log v2.6.14..v2.6.16
which silently did nothing at all. The reason? I don't actually have a
v2.6.16, the most recent version is 2.6.16-rc1. So it thought
v2.6.14..v2.6.16 was a _filename_.
Now, normally, if you use the "proper" format (with the -- delimeter to
mark where filenames start), you'd never have this ambiguity. But without
the "--", the way I decided that we should disambiguate things is to
verify that any filename given with the ambiguous shorthand version
actually exists.
Comments?
diff --git a/rev-list.c b/rev-list.c
index d060966..e00e6fc 100644
--- a/rev-list.c
+++ b/rev-list.c
@@ -844,8 +844,12 @@ int main(int argc, const char **argv)
arg++;
limited = 1;
}
- if (get_sha1(arg, sha1) < 0)
+ if (get_sha1(arg, sha1) < 0) {
+ struct stat st;
+ if (lstat(arg, &st) < 0)
+ die("'%s': %s", arg, strerror(errno));
break;
+ }
commit = get_commit_reference(arg, sha1, flags);
handle_one_commit(commit, &list);
}
diff --git a/rev-parse.c b/rev-parse.c
index 0c951af..7abad35 100644
--- a/rev-parse.c
+++ b/rev-parse.c
@@ -154,6 +154,7 @@ int main(int argc, char **argv)
const char *prefix = setup_git_directory();
for (i = 1; i < argc; i++) {
+ struct stat st;
char *arg = argv[i];
char *dotdot;
@@ -293,6 +294,8 @@ int main(int argc, char **argv)
}
if (verify)
die("Needed a single revision");
+ if (lstat(arg, &st) < 0)
+ die("'%s': %s", arg, strerror(errno));
as_is = 1;
show_file(arg);
}
^ permalink raw reply related
* git-whatchanged: exit out early on errors
From: Linus Torvalds @ 2006-01-25 22:02 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0601251655580.2644@evo.osdl.org>
If we get an error parsing the arguments, exit.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
This goes together with the previous diff - it just makes git-whatchanged
exit gracefully when git-rev-parse errors out.
diff --git a/git-whatchanged.sh b/git-whatchanged.sh
index 80e2500..d4f985b 100755
--- a/git-whatchanged.sh
+++ b/git-whatchanged.sh
@@ -4,7 +4,7 @@ USAGE='[-p] [--max-count=<n>] [<since>..
SUBDIRECTORY_OK='Yes'
. git-sh-setup
-diff_tree_flags=$(git-rev-parse --sq --no-revs --flags "$@")
+diff_tree_flags=$(git-rev-parse --sq --no-revs --flags "$@") || exit
test -z "$diff_tree_flags" &&
diff_tree_flags=$(git-repo-config --get whatchanged.difftree)
test -z "$diff_tree_flags" &&
^ permalink raw reply related
* Re: Make git-rev-list and git-rev-parse argument parsing stricter
From: Junio C Hamano @ 2006-01-25 22:40 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0601251655580.2644@evo.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> If you pass it a filename without the "--" marker to separate it from
> revision information and flags, we now require that the file in question
> actually exists. This makes mis-typed revision information not be silently
> just considered a strange filename.
>...
> Comments?
I think it is a good safety measure. People has to say "git
rev-list -- git-commit-script" if they are interested in
historical paths, but that is less common. We could even go
stronger and always require '--', but that is probably too much
for normal use. I like the balance you struck here.
^ permalink raw reply
* how to import stuff?
From: Ian Molton @ 2006-01-25 23:40 UTC (permalink / raw)
To: git
Hi.
I'd like to track the -mm tree in git.
I already have a linux git tree cloned from kernel.org, so I thought I'd try
git checkout -b v2.6.16-rc1 v2.6.16-rc1
git checkout -b v2.6.16-rc1-mm3
patch -Np1 < 2.6.16-rc1-mm3
So far so good - I have a tree with the patches applied
but then how do I add / remove new / deleted files?
git update-index --add --remove --refresh --ignore-missing
seems to generate a list of said files, but I cant seem to figure out
how to get it to actually do anything useful with them.
git add . adds all the new files, but there seems to be no equivalent to
remove files
and I really dont want to run git updat-index on *every single file*
that changed by hand.
Surely Im missing something, but I cant see what for the life of me. The
'everyday git' document seems to focus on small changes to one or two
files.
managing files not yet in or removed from the source isnt something
effectively covered in the document (or if it is, I missed it somehow).
Its probably obvious that Im new to this kind of SCM - and I've not got
on with SCMs generally... they never seem to be logical to me.
TIA!
-Ian
^ permalink raw reply
* Re: how to import stuff?
From: J. Bruce Fields @ 2006-01-25 23:42 UTC (permalink / raw)
To: Ian Molton; +Cc: git
In-Reply-To: <43D80C77.70207@f2s.com>
On Wed, Jan 25, 2006 at 11:40:39PM +0000, Ian Molton wrote:
> git add . adds all the new files, but there seems to be no equivalent to
> remove files
That happens on commit without the need for any special command.
--b.
^ permalink raw reply
* Re: [RFD] remembering hand resolve...
From: Junio C Hamano @ 2006-01-25 23:56 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <43D7810D.9010508@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Junio C Hamano wrote:
>> The thing is, I find myself resolving the same conflicts over
>> and over. This is because the master branch tends to advance
>> faster than topic branches that touch an overlapping area.
>
> How can that be possible? If the area of code in master is modified
> beyond simple merging from the topic-branches, the resulting diff
> (which has to be against master's HEAD) should apply cleanly so long
> as there aren't *new* changes to master, in which case the pu commit
> needs adaptation again, so it wouldn't really be the same conflict (or
> even necessarily a similar one), would it?
In general, you are right. When the change that advances
"master" touches the same area as those held-back topic branches
touch, the earlier resolution between topic branches may not help.
However, the change to the "master" that leap-frogs these
held-back topic branches is often independent from the changes
in these held-back topic branches.
For example, as of this morning, my "master" and "pu" were like
this:
$ git show-branch master pu
* [master] Merge branches 'jc/clone', 'md/env' and 'mo/path'
! [pu] Merge jc/revparse,jc/abbrev
--
- [pu] Merge jc/revparse,jc/abbrev
- [pu^] Merge lt/revlist,jc/diff,jc/bind
+ [pu^^3] combine-diff: fix appending at the tail of a list.
+ [pu^2] rev-parse --flags/--no-flags usability fix.
+ [pu^3] diff-tree: abbreviate merge parent object names wit...
+ [pu^^2] rev-list: stop when the file disappears
+ [pu^^3^] diff-tree --cc: denser combined diff output for a...
+ [pu^^3~2] diff-tree -c: show a merge commit a bit more sen...
+ [pu^^4] fsck-objects, convert-objects: understand bound co...
+ [pu^^4^] rev-list: understand bound commits.
+ [pu^^4~2] rev-list: simplify --object list generation.
+ [pu^^4~3] commit-tree: --bind <sha1> <path>/ option.
+ [pu^^4~4] write-tree: --prefix=<path>/ and --exclude=<pref...
+ [pu^^4~5] read-tree: --prefix=<path>/ option.
+ [pu^3^] rev-parse: --abbrev option.
+ [pu^3~2] abbrev cleanup: use symbolic constants
-- [master] Merge branches 'jc/clone', 'md/env' and 'mo/path'
The two merges at the tip of "pu" shows that I merged lt/revlist
(Linus' "stop at disappearance"), jc/diff ("combined diff") and
jc/bind ("bound commit') first because I felt they are more or
less ready, and then jc/revparse and jc/abbrev on top of it.
Two topic branches, jc/abbrev and jc/bind, touch the same area
in commit.c. The former changes the formatting of "Merge:" line
from prettyprinted commit (we did not honor --abbrev option to
diff-tree when we used that function). The latter changes the
same function to include a call to add the new "Bind: " lines.
When I made the last merge for the tip of "pu", I had to hand
resolve conflicts in the file.
Now suppose I feel topic branches lt/revlist, jc/diff and
jc/revparse are ready, and want to have them graduate to the
"master" branch. Also I may get a patch from you fixing
Documentation/Makefile, which none of my topic branches touch,
so I would advance "master" this way:
$ git checkout master
$ git pull . lt/revlist
$ git pull . jc/diff
$ git pull . jc/revparse
$ git am -3 -s ./+ae-doc-make.email
What I would do after this step to rebuild "pu" would be to
merge jc/bind and jc/abbrev branches, in some order. But in
whatever order I merge, I would get the conflict in commit.c
as before:
$ git checkout pu
$ git reset --hard master
$ git pull . jc/bind
$ git pull . jc/abbrev
If I swap the order I pull in jc/bind and jc/abbrev, the
sections marked with conflict markers <<< === >>> would be
swapped, so the conflict would not be exactly the same, but
the result of the resolution is the same. I end up making the
result logically the same by hand resolving.
Although I happen to do Octopus when building "pu" but the issue
does not change if the merges were made one branch at a time.
>> If I linearize topic-branches that conflict with each other in
>> some way, say base topic B on top of topic A, I would not have
>> problem merging them into "pu" as long as I do not change my
>> mind later and try to merge only topic B without topic A. But
>> that defeats the whole point of having independent topic
>> branches.
>
> Wouldn't cherry-pick be useful here? If it isn't, I fail to understand
> how a merge can solve it for you....
Suppose instead of having
A---B---C jc/bind
/
master ---O
\
D---E---F jc/abbrev
I made this:
A'--B'--C'--D---E---F
/ ^jc/bind ^jc/abbrev
master ---O
When converting the two topic branches into this sequence,
obviously I have to hand merge the changes A-B-C makes and the
changes D-E-F makes to commit.c file.
I can later attempt to cherry-pick D-E-F on top of updated
"master". I think that is what you mean by "cherry-picking",
but that would have the same "I've resolved this before" issue.
Because the change D-E-F brings in now depends on the change
A'-B'-C' brings in. But on the tip of the master branch, that
change is not there yet. The cherry-picked changes on top of O
would not cleanly apply. Even with the 3-way merge fallback,
this is a merge of F and O using C' as the merge base, and we
will see conflicts.
However, as long as I do not have to merge the contents of
jc/abbrev branch in without the contents of jc/bind branch, a
merge to an updated master would not have any conflict between
A'-B'-C' chain and D-E-F chain, and often even after jc/bind and
jc/abbrev advances:
G---H jc/bind
/
A'--B'--C'--D---E---F
/ ^jc/abbrev
master ---O---I---J
Pulling jc/bind to master and then jc/abbrev on top it may have
conflicts between the changes O-I-J and C'-G-H bring in, but at
least I would not have to re-resolve the conflicts between
A'-B'-C' and D-E-F chains. That is what I meant to say. The
merge is helped by making jc/abbrev topic branch dependent on
the earlier part of jc/bind topic branch.
> Couldn't you do something like this:
>
> for t in $topic_branches; do
> checkout $t
> git rebase master
> done
> git checkout master
> git branch -D pu
> git checkout -b pu
> git pull . $topic_branches
>
> That's what I thought you were doing right now, but I can't imagine
> that flow leading to the same conflicts over and over, so I must be
> mistaken somehow.
That is exactly what I am doing [*1*]
[Footnote]
*1* In my primary development working tree, I have a checked-out
tree of "todo" branch at Meta/ directory. The "pu" is built by
running Meta/PU (that is "PU" file in the "todo" branch) from
the toplevel and picking topic branches to merge on top of the
master branch, which essentially does what you just described.
To take a peek at how my primary development working tree looks
like, you could do this:
$ git clone git://git.kernel.org/pub/scm/git/git GIT
$ cd GIT
$ git clone -l -s -n .git Meta
$ cd Meta
$ git checkout todo
$ cd ..
$ rm Meta/.git/refs/heads/[a-p]* ;# leave only "todo"
$ rm -f .git/refs/heads/{html,man,todo}
This would give a rough approximation of where I work.
The above clone would not have any of the topic branches; but
their heads appear on merge commits between master and pu. For
example, in the earlier show-branch output, the tip of "pu" says
"Merge jc/revparse,jc/abbrev", which means pu^1 was the tip of
pu when this merge was made, pu^2 is the tip of jc/revparse
topic, and pu^3 is jc/abbrev. You can take them apart like so:
$ git branch jc/revparse pu^2
$ git branch jc/abbrev pu^3
^ permalink raw reply
* Re: What's in git.git
From: Junio C Hamano @ 2006-01-25 23:56 UTC (permalink / raw)
To: Santi Bejar; +Cc: git
In-Reply-To: <8aa486160601250634v294857e0j@mail.gmail.com>
Santi Bejar <sbejar@gmail.com> writes:
> Junio C Hamano <junkio@cox.net> writes:
>...
>> $ git whatchanged --cc --abbrev pu
>...
> Then some comments :)
>
> * There is an extra space between the +- and the content.
Thanks for noticing. Fixed.
> * I think the "diff command" could be just "diff --git". And
> "diff --git --cc" for the "dense combined diff".
I chose not say "--git" because I wanted to make sure people
would not run "git apply" by mistake. I replaced them
with "--combined" and "--cc" to make the differences clearer.
> * I miss the index lines
That would probably be easy to add in the later rounds if you
really want them, but I consider it lower priority for now.
This is designed to be human readable and not necessarily
machine applicable, so I do not see much point in showing them.
Mode changes, creation, deletion, rename, and copy may need to
be there, though. The code currently punts on them. Patches
welcome.
> * In the case of 3 and more parents I find uninteresting the hunk
> where the merge is equal to one (or more) of its children and
> the rest are equal. For example the first hunk in 22573dd, where
> all the children are equal expect the picked one:
>
> diff-tree 22573dd... (from parents)
> Merge: 92643a2 0359fe8 a428965 4aa079f
> Author: Junio C Hamano <junkio@cox.net>
> Date: Wed Jan 25 03:51:37 2006 -0800
>
> Merge lt/revlist,jc/diff,jc/bind
>
> diff --combined rev-list.c
> @@@@@ +37,7 @@@@@
> static int dense = 1;
> static int unpacked = 0;
> static int bisect_list = 0;
> --- static int tag_objects = 0;
> --- static int tree_objects = 0;
> --- static int blob_objects = 0;
> +++ static int list_objects = 0;
> static int verbose_header = 0;
> static int show_parents = 0;
> static int hdr_termination = 0;
I noticed it and found it somewhat less interesting than others,
but left it the way. It is "changed the same way from all of
these parents except this one", which is different from what I
culled in the version you are commenting on, i.e. "changed only
from one parent".
I've since updated the logic to drop these hunks as well.
Please take a look at the tip of "pu".
> * Like you said in another thread, the line numbers of all the
> files.
This is left as an exercise for the reader ;-)
> So, at the end, I suggest this output for the diff:
>...
> and this for the diff-raw:
>
> :100644 100644 56505b4... 538d21d... M Makefile
> :100644 100644 30479b4... 538d21d... M Makefile
I do not find this to be so interesting. diff-raw is primarily
for quick sanity check and machine processing, so I'd rather not
play games when generating diff-raw in order to keep the latter
form of users sane.
^ permalink raw reply
* Re: how to import stuff?
From: Junio C Hamano @ 2006-01-26 0:15 UTC (permalink / raw)
To: Ian Molton; +Cc: git
In-Reply-To: <43D80C77.70207@f2s.com>
Ian Molton <spyro@f2s.com> writes:
> git checkout -b v2.6.16-rc1 v2.6.16-rc1
You are creating a branch called v2.6.16-rc1 while you have a
tag with the same name. From this point on, when you say
v2.6.16-rc1 when git expects an arbitrary revision name, the
commit Linus tagged with that name is used. When git expects
you to use it a branch name, it uses the branch head commit of
the branch you created here. Once you create a new commit in
that branch, these two will refer to different commits depending
on the context. Unless you really understand what you are
doing, this would confuse you, so do not do this. Use some
other branch name. Better yet...
> git checkout -b v2.6.16-rc1-mm3
Starting from a vanilla clone from Linus, up to this point you
could probably have done:
$ git checkout -b v2.6.16-rc1-mm3 v2.6.16-rc1
You do not need v2.6.16-rc1 branch if you immediately create
another branch, which is the branch you would want to work on.
> patch -Np1 < 2.6.16-rc1-mm3
> So far so good - I have a tree with the patches applied
$ git apply --index 2.6.16-rc1-mm3
If the patch you are using cleanly applies without fuzz, this
would apply them to the working tree, and all the new and/or
removed files are registered to the index, without you having to
say "git update-index".
> git update-index --add --remove --refresh --ignore-missing
>
> seems to generate a list of said files, but I cant seem to figure out
> how to get it to actually do anything useful with them.
I have no idea what this update-index line with only the
flags means, so let's forget about that.
After applying the patch with "patch -p1 -E" on top of the
vanilla version:
$ git add .
would add all the new files. Then
$ git commit -a -m '2.6.16-rc1-mm3'
would notice removed and modified files as well when making a
commit.
HOWEVER.
I honestly do not understand what value you are expecting to get
out of git, if you are rolling the whole thing from -mm series
into a singe commit. Commit is designed to be easily handled as
an atomic change, and being able to pick and choose only parts
of it was never part of its design goal, so I do not understand
what useful things you are expecting to do, after you create
that commit.
IOW, there is a reason -mm series is available as individual
broken-out/ files.
^ permalink raw reply
* Re: how to import stuff?
From: Junio C Hamano @ 2006-01-26 0:16 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git, Ian Molton
In-Reply-To: <20060125234239.GA5426@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
> On Wed, Jan 25, 2006 at 11:40:39PM +0000, Ian Molton wrote:
>> git add . adds all the new files, but there seems to be no equivalent to
>> remove files
>
> That happens on commit without the need for any special command.
>
> --b.
... as long as you say "git commit -a", that is.
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.1.4
From: Eric Sandall @ 2006-01-26 0:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wz31e9t.fsf@assigned-by-dhcp.cox.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Fri, 20 Jan 2006, Junio C Hamano wrote:
> The latest maintenance release GIT 1.1.4 is available at the
> usual places:
>
> http://www.kernel.org/pub/software/scm/git/
>
> git-1.1.4.tar.{gz,bz2} (tarball)
> RPMS/$arch/git-*-1.1.4-1.$arch.rpm (RPM)
<snip>
I've updated the Source Mage GNU/Linux package for this, thanks!
- -sandalle
- --
Eric Sandall | Source Mage GNU/Linux Developer
eric@sandall.us | http://www.sourcemage.org/
http://eric.sandall.us/ | SysAdmin @ Inst. Shock Physics @ WSU
http://counter.li.org/ #196285 | http://www.shock.wsu.edu/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFD2BfqHXt9dKjv3WERAq/hAKCoX5loHUI9VqVLbSLl41yvPOemEgCfXOoN
FapnbqdRcvlK1MiEWbUxVqI=
=bTyp
-----END PGP SIGNATURE-----
^ permalink raw reply
* LCA06 Cogito/GIT workshop - (Re: git-whatchanged: exit out early on errors)
From: Martin Langhoff @ 2006-01-26 2:10 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
On 1/26/06, Linus Torvalds <torvalds@osdl.org> wrote:
> If we get an error parsing the arguments, exit.
This bug found thanks to the 'demo' effect. ;-)
The workshop had a 2hr slot -- after 2hs 15, I asked Linus if he
wanted to talk about the internals. He did, and the workshop went
on... for 2 hours more. It was actually hard to get people out of the
room.
Sadly, not many people actually played along on their laptop. Those
who did got an extra bit of help to migrate their preexisting CVS/SVN
repos ;-) (thanks to Sam Vilain for all the help!)
I'll upload the presentation material soon -- very similar to the
stuff I used @ Wellington Perl Mongers. Still text-based; given all
the talk about plumbing and porcelain, I steadfastly refuse to add
imagery.
During the presentation someone mentioned errors when running
git-cvsimport which I'm keen on hearing more about.
cheers,
m
^ permalink raw reply
* [PATCH] Only use a single parser for tree objects
From: Daniel Barkalow @ 2006-01-26 6:13 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
This makes read_tree_recursive and read_tree take a struct tree
instead of a buffer. It also move the declaration of read_tree into
tree.h (where struct tree is defined), and updates ls-tree and
diff-index (the only places that presently use read_tree*()) to use
the new versions.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
cache.h | 3 ---
diff-index.c | 8 ++++----
ls-tree.c | 9 ++++-----
tree.c | 50 +++++++++++++++++++-------------------------------
tree.h | 9 +++++----
5 files changed, 32 insertions(+), 47 deletions(-)
973280cda82b9ead56881d453c6101e4bf298c94
diff --git a/cache.h b/cache.h
index 6f13434..24a679b 100644
--- a/cache.h
+++ b/cache.h
@@ -210,9 +210,6 @@ extern char *write_sha1_file_prepare(voi
extern int check_sha1_signature(const unsigned char *sha1, void *buf, unsigned long size, const char *type);
-/* Read a tree into the cache */
-extern int read_tree(void *buffer, unsigned long size, int stage, const char **paths);
-
extern int write_sha1_from_fd(const unsigned char *sha1, int fd, char *buffer,
size_t bufsize, size_t *bufposn);
extern int write_sha1_to_fd(int fd, const unsigned char *sha1);
diff --git a/diff-index.c b/diff-index.c
index 87e1061..bbd873b 100644
--- a/diff-index.c
+++ b/diff-index.c
@@ -1,4 +1,5 @@
#include "cache.h"
+#include "tree.h"
#include "diff.h"
static int cached_only = 0;
@@ -174,8 +175,7 @@ int main(int argc, const char **argv)
unsigned char sha1[20];
const char *prefix = setup_git_directory();
const char **pathspec = NULL;
- void *tree;
- unsigned long size;
+ struct tree *tree;
int ret;
int allow_options = 1;
int i;
@@ -233,10 +233,10 @@ int main(int argc, const char **argv)
mark_merge_entries();
- tree = read_object_with_reference(sha1, "tree", &size, NULL);
+ tree = parse_tree_indirect(sha1);
if (!tree)
die("bad tree object %s", tree_name);
- if (read_tree(tree, size, 1, pathspec))
+ if (read_tree(tree, 1, pathspec))
die("unable to read tree object %s", tree_name);
ret = diff_cache(active_cache, active_nr, pathspec);
diff --git a/ls-tree.c b/ls-tree.c
index d585b6f..d005643 100644
--- a/ls-tree.c
+++ b/ls-tree.c
@@ -84,8 +84,7 @@ static int show_tree(unsigned char *sha1
int main(int argc, const char **argv)
{
unsigned char sha1[20];
- char *buf;
- unsigned long size;
+ struct tree *tree;
prefix = setup_git_directory();
if (prefix && *prefix)
@@ -131,10 +130,10 @@ int main(int argc, const char **argv)
usage(ls_tree_usage);
pathspec = get_pathspec(prefix, argv + 2);
- buf = read_object_with_reference(sha1, "tree", &size, NULL);
- if (!buf)
+ tree = parse_tree_indirect(sha1);
+ if (!tree)
die("not a tree object");
- read_tree_recursive(buf, size, "", 0, 0, pathspec, show_tree);
+ read_tree_recursive(tree, "", 0, 0, pathspec, show_tree);
return 0;
}
diff --git a/tree.c b/tree.c
index dc1c41e..962ee89 100644
--- a/tree.c
+++ b/tree.c
@@ -74,27 +74,24 @@ static int match_tree_entry(const char *
return 0;
}
-int read_tree_recursive(void *buffer, unsigned long size,
+int read_tree_recursive(struct tree *tree,
const char *base, int baselen,
int stage, const char **match,
read_tree_fn_t fn)
{
- while (size) {
- int len = strlen(buffer)+1;
- unsigned char *sha1 = buffer + len;
- char *path = strchr(buffer, ' ')+1;
- unsigned int mode;
-
- if (size < len + 20 || sscanf(buffer, "%o", &mode) != 1)
- return -1;
-
- buffer = sha1 + 20;
- size -= len + 20;
-
- if (!match_tree_entry(base, baselen, path, mode, match))
+ struct tree_entry_list *list;
+ if (parse_tree(tree))
+ return -1;
+ list = tree->entries;
+ while (list) {
+ struct tree_entry_list *current = list;
+ list = list->next;
+ if (!match_tree_entry(base, baselen, current->name,
+ current->mode, match))
continue;
- switch (fn(sha1, base, baselen, path, mode, stage)) {
+ switch (fn(current->item.any->sha1, base, baselen,
+ current->name, current->mode, stage)) {
case 0:
continue;
case READ_TREE_RECURSIVE:
@@ -102,28 +99,19 @@ int read_tree_recursive(void *buffer, un
default:
return -1;
}
- if (S_ISDIR(mode)) {
+ if (current->directory) {
int retval;
- int pathlen = strlen(path);
+ int pathlen = strlen(current->name);
char *newbase;
- void *eltbuf;
- char elttype[20];
- unsigned long eltsize;
-
- eltbuf = read_sha1_file(sha1, elttype, &eltsize);
- if (!eltbuf || strcmp(elttype, "tree")) {
- if (eltbuf) free(eltbuf);
- return -1;
- }
+
newbase = xmalloc(baselen + 1 + pathlen);
memcpy(newbase, base, baselen);
- memcpy(newbase + baselen, path, pathlen);
+ memcpy(newbase + baselen, current->name, pathlen);
newbase[baselen + pathlen] = '/';
- retval = read_tree_recursive(eltbuf, eltsize,
+ retval = read_tree_recursive(current->item.tree,
newbase,
baselen + pathlen + 1,
stage, match, fn);
- free(eltbuf);
free(newbase);
if (retval)
return -1;
@@ -133,9 +121,9 @@ int read_tree_recursive(void *buffer, un
return 0;
}
-int read_tree(void *buffer, unsigned long size, int stage, const char **match)
+int read_tree(struct tree *tree, int stage, const char **match)
{
- return read_tree_recursive(buffer, size, "", 0, stage, match, read_one_entry);
+ return read_tree_recursive(tree, "", 0, stage, match, read_one_entry);
}
struct tree *lookup_tree(const unsigned char *sha1)
diff --git a/tree.h b/tree.h
index 57a5bf7..330ab64 100644
--- a/tree.h
+++ b/tree.h
@@ -37,10 +37,11 @@ struct tree *parse_tree_indirect(const u
#define READ_TREE_RECURSIVE 1
typedef int (*read_tree_fn_t)(unsigned char *, const char *, int, const char *, unsigned int, int);
-extern int read_tree_recursive(void *buffer, unsigned long size,
- const char *base, int baselen,
- int stage, const char **match,
- read_tree_fn_t fn);
+extern int read_tree_recursive(struct tree *tree,
+ const char *base, int baselen,
+ int stage, const char **match,
+ read_tree_fn_t fn);
+extern int read_tree(struct tree *tree, int stage, const char **paths);
#endif /* TREE_H */
--
1.0.GIT
^ 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