* [PATCH] add freebsd support in Makefile
From: Alecs King @ 2006-01-26 18:04 UTC (permalink / raw)
To: git
fbsd needs iconv and third party lib/headers are inside /usr/local
Signed-off-by: Alecs King <alecsk@gmail.com>
e3b0db75ae3521b979a0b7ab115abdfab24b3111
diff --git a/Makefile b/Makefile
index 2e95353..6910448 100644
--- a/Makefile
+++ b/Makefile
@@ -251,6 +251,11 @@ ifeq ($(uname_O),Cygwin)
NO_IPV6 = YesPlease
X = .exe
endif
+ifeq ($(uname_S),FreeBSD)
+ NEEDS_LIBICONV = YesPlease
+ ALL_CFLAGS += -I/usr/local/include
+ ALL_LDFLAGS += -L/usr/local/lib
+endif
ifeq ($(uname_S),OpenBSD)
NO_STRCASESTR = YesPlease
NEEDS_LIBICONV = YesPlease
--
Alecs King
^ permalink raw reply related
* [PATCH] Make GIT-VERSION-GEN tolerate missing git describe command again
From: Uwe Zeisberger @ 2006-01-26 16:39 UTC (permalink / raw)
To: git; +Cc: Uwe Zeisberger
In-Reply-To: <20060126134521.GA11570@informatik.uni-freiburg.de>
Commit 5c7d3c95 broke that by making the git-describe command part of
a pipe.
Signed-off-by: Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de>
---
GIT-VERSION-GEN | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
b5763601050151e944cb58b3b0fe6f4aee88b47f
diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
index e3cd9fa..72201be 100755
--- a/GIT-VERSION-GEN
+++ b/GIT-VERSION-GEN
@@ -5,9 +5,11 @@ DEF_VER=v1.1.GIT
# First try git-describe, then see if there is a version file
# (included in release tarballs), then default
-VN=$(git-describe --abbrev=4 HEAD 2>/dev/null | sed -e 's/-/./g') ||
-VN=$(cat version) ||
-VN="$DEF_VER"
+if VN=$(git-describe --abbrev=4 HEAD 2>/dev/null); then
+ VN=$(echo "$VN" | sed -e 's/-/./g');
+else
+ VN=$(cat version) || VN="$DEF_VER"
+fi
VN=$(expr "$VN" : v*'\(.*\)')
--
1.1.4-g9acfd
^ permalink raw reply related
* Re: What's in git.git
From: Santi Bejar @ 2006-01-26 16:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhd7rfare.fsf@assigned-by-dhcp.cox.net>
> I think this patch would address your two issues (applies on top
> of "pu"), but I have not had time to test it seriously enough.
It works here, thanks.
Just a little issue. With grafted commits the combined diff works but
the "Merge:" line is not shown.
Santi
^ permalink raw reply
* Re: How to create and keep up to date a naked/bare repository?
From: Mathieu Chouquet-Stringer @ 2006-01-26 15:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64o7fac1.fsf@assigned-by-dhcp.cox.net>
junkio@cox.net (Junio C Hamano) writes:
> Mathieu Chouquet-Stringer <ml2news@free.fr> writes:
> > I can do a: GIT_DIR=. git fetch and it works.
>
> That is the right way of doing it.
Ok.
> > The second question is I'd think I would have to use git fetch instead of
> > git pull as a pull is fetch + merge and merging wouldn't make much sense as
> > I didn't check out any files. Does it make any sense?
>
> Absolutely. Bare repositories are either to be pushed into or
> fetched into.
Great I ain't totally lost then!
> > The third thing (can't reproduce ATM as I just got a fresh new clone) is
> > that git fetch was just fetching over and over the same objects...
>
> It sounds like you are not telling fetch to update the refs you
> track from outside. Perhaps, this may help (untested):
>
> $ GIT_DIR=/pub/scm/git/git.git git fetch \
> --update-head-ok $remote master:master
I'll try that and will let you know...
Thanks Junio for getting back to me.
--
Mathieu Chouquet-Stringer
"Le disparu, si l'on vénère sa mémoire, est plus présent et
plus puissant que le vivant".
-- Antoine de Saint-Exupéry, Citadelle --
^ permalink raw reply
* Re: [PATCH] [GITK] use "git <command>" instead of "git-<command>"
From: Uwe Zeisberger @ 2006-01-26 14:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3bjcws5o.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> 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.
(I remember darkly that was already discussed, but I cannot find the
thread ATM.)
Just to get the patch right:
If
- PATH=$(HOME)/bin:/usr/bin
- GIT_EXEC_PATH=/usr/bin
then gitk should use
PATH=/usr/bin:$(HOME)/bin:/usr/bin
to call git-<command> and
PATH=$(HOME)/bin:/usr/bin
to call the rest, right?
Best regards
Uwe
--
Uwe Zeisberger
fib where fib = 0 : 1 : zipWith (+) fib (tail fib)
^ permalink raw reply
* 5c7d3c95 broke 026351a
From: Uwe Zeisberger @ 2006-01-26 13:45 UTC (permalink / raw)
To: git
Hello,
zeisberger@io:~$ VN=$(nonexistentcmd) || echo lala
bash: nonexistentcmd: command not found
lala
uzeisberger@io:~$ VN=$(nonexistentcmd | sed 's/-/./g') || echo lala
bash: nonexistentcmd: command not found
The reason is (from bash(1)):
The return status of a pipeline is the exit status of the last
command, unless the pipefail option is enabled.
and the sed command is fine.
pipefail is not portable, i.e. Solaris' sh doesn't support it.
I'd suggest:
if VN=$(git-describe --abbrev=4 HEAD 2>/dev/null); then
VN=$(echo "$VN" | sed 's/-/./g');
else
VN=$(cat version) || VN="$DEF_VER";
fi
This works with Solaris' sh and bash.
Best regards
Uwe
--
Uwe Zeisberger
exit vi, lesson V:
o : q ! CTRL-V <CR> <Esc> " d d d @ d
^ permalink raw reply
* Re: Safe way to remove .temp objects?
From: Junio C Hamano @ 2006-01-26 12:24 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git, Erik Mouw
In-Reply-To: <43D8AFF1.2080106@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Erik Mouw wrote:
>> Hi,
>> After a git repack, git count-objects reports there are still 20
>> objects in the repository. It looks like those are temp objects:
>> erik@arthur:~/git/linux-2.6 > ls .git/objects/??/
>> .git/objects/14/:
>> d6545767f5103b5ef4702bc8fffa18dbe32ce1.temp
>> .git/objects/1a/:
>> d37b580be4215f1b0927b7560f5e8b8d1bc0fa.temp
>> [...]
>> Is there a git command to remove those objects in a safe way, or can
>> I
>> just rm them without "harming" git??
>>
>
> $ git prune-packed
>
> When you repack, you can run
>
> $ git repack -d
>
> to remove loose objects when you're done packing.
What is being asked is not about loose objects but droppings
commit walkers make when interrupted.
I think *.temp files are garbage and you can safely remove
them. They are not even correct objects.
^ permalink raw reply
* Re: How to create and keep up to date a naked/bare repository?
From: Junio C Hamano @ 2006-01-26 12:22 UTC (permalink / raw)
To: Mathieu Chouquet-Stringer; +Cc: git
In-Reply-To: <m37j8n9rat.fsf_-_@localhost.localdomain>
Mathieu Chouquet-Stringer <ml2news@free.fr> writes:
> I can do a: GIT_DIR=. git fetch and it works.
That is the right way of doing it.
> The second question is I'd think I would have to use git fetch instead of
> git pull as a pull is fetch + merge and merging wouldn't make much sense as
> I didn't check out any files. Does it make any sense?
Absolutely. Bare repositories are either to be pushed into or
fetched into.
> The third thing (can't reproduce ATM as I just got a fresh new clone) is
> that git fetch was just fetching over and over the same objects...
It sounds like you are not telling fetch to update the refs you
track from outside. Perhaps, this may help (untested):
$ GIT_DIR=/pub/scm/git/git.git git fetch \
--update-head-ok $remote master:master
^ permalink raw reply
* Re: What's in git.git
From: Junio C Hamano @ 2006-01-26 12:12 UTC (permalink / raw)
To: Santi Bejar; +Cc: git
In-Reply-To: <8aa486160601260156h6157ca34s@mail.gmail.com>
Santi Bejar <sbejar@gmail.com> writes:
> 2006/1/26, Junio C Hamano <junkio@cox.net>:
>> No comment on your message yet, but please fix your MUA so that
>> your messages do not get rejected by the mailing list software.
>>
>> I suspect it is base64 CTE that causes it.
>>
>> Content-Type: text/plain; charset=UTF-8
>> Content-Transfer-Encoding: base64
>
> Sorry, about that. But I didn't get any notification.
You do not need to feel sorry. It's just your voice is not
heard as widely as it should have been, and you did not know
about it.
The spam filter just drops things on the floor without bothering
to notify potential spammers.
I think this patch would address your two issues (applies on top
of "pu"), but I have not had time to test it seriously enough.
-- >8 --
[PATCH] combine-diff: better hunk splitting.
It considered an otherwise unchanged line that had line removals
in front of it an interesting line, which caused hunks to have
one extra the trailing context line.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
combine-diff.c | 142 ++++++++++++++++++++++++++++++++++++++++++++++----------
1 files changed, 116 insertions(+), 26 deletions(-)
0aa20bc0c276c3fcb7215ba9f591960178792261
diff --git a/combine-diff.c b/combine-diff.c
index 3b219a0..d94a93d 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -323,52 +323,142 @@ static unsigned long line_all_diff(struc
return different;
}
-static int make_hunks(struct sline *sline, unsigned long cnt,
- int num_parent, int dense)
+static unsigned long adjust_hunk_tail(struct sline *sline,
+ unsigned long all_mask,
+ unsigned long hunk_begin,
+ unsigned long i)
+{
+ /* i points at the first uninteresting line.
+ * If the last line of the hunk was interesting
+ * only because it has some deletion, then
+ * it is not all that interesting for the
+ * purpose of giving trailing context lines.
+ */
+ if ((hunk_begin + 1 <= i) &&
+ ((sline[i-1].flag & all_mask) == all_mask))
+ i--;
+ return i;
+}
+
+static unsigned long next_interesting(struct sline *sline,
+ unsigned long mark,
+ unsigned long i,
+ unsigned long cnt,
+ int uninteresting)
+{
+ while (i < cnt)
+ if (uninteresting ?
+ !(sline[i].flag & mark) :
+ (sline[i].flag & mark))
+ return i;
+ else
+ i++;
+ return cnt;
+}
+
+static int give_context(struct sline *sline, unsigned long cnt, int num_parent)
{
unsigned long all_mask = (1UL<<num_parent) - 1;
unsigned long mark = (1UL<<num_parent);
unsigned long i;
int has_interesting = 0;
- i = 0;
+ i = next_interesting(sline, mark, 0, cnt, 0);
+ if (cnt <= i)
+ return 0;
+
while (i < cnt) {
- if (interesting(&sline[i], all_mask)) {
- unsigned long j = (context < i) ? i - context : 0;
- while (j <= i)
+ unsigned long j = (context < i) ? (i - context) : 0;
+ unsigned long k;
+ while (j < i)
+ sline[j++].flag |= mark;
+
+ again:
+ j = next_interesting(sline, mark, i, cnt, 1);
+ if (cnt <= j)
+ break; /* the rest are all interesting */
+
+ /* lookahead context lines */
+ k = next_interesting(sline, mark, j, cnt, 0);
+ j = adjust_hunk_tail(sline, all_mask, i, j);
+
+ if (k < j + context) {
+ /* k is interesting and [j,k) are not, but
+ * paint them interesting because the gap is small.
+ */
+ while (j < k)
sline[j++].flag |= mark;
- while (++i < cnt) {
- if (!interesting(&sline[i], all_mask))
- break;
- sline[i].flag |= mark;
- }
- j = (i + context < cnt) ? i + context : cnt;
- while (i < j)
- sline[i++].flag |= mark;
- has_interesting = 1;
- continue;
+ i = k;
+ goto again;
}
- i++;
+
+ /* j is the first uninteresting line and there is
+ * no overlap beyond it within context lines.
+ */
+ i = k;
+ k = (j + context < cnt) ? j + context : cnt;
+ while (j < k)
+ sline[j++].flag |= mark;
+ }
+ return 1;
+}
+
+static int make_hunks(struct sline *sline, unsigned long cnt,
+ int num_parent, int dense)
+{
+ unsigned long all_mask = (1UL<<num_parent) - 1;
+ unsigned long mark = (1UL<<num_parent);
+ unsigned long i;
+ int has_interesting = 0;
+
+ for (i = 0; i < cnt; i++) {
+ if (interesting(&sline[i], all_mask))
+ sline[i].flag |= mark;
+ else
+ sline[i].flag &= ~mark;
}
if (!dense)
- return has_interesting;
+ return give_context(sline, cnt, num_parent);
/* Look at each hunk, and if we have changes from only one
* parent, or the changes are the same from all but one
* parent, mark that uninteresting.
*/
- has_interesting = 0;
i = 0;
while (i < cnt) {
- int j, hunk_end, same, diff;
+ unsigned long j, hunk_begin, hunk_end;
+ int same, diff;
unsigned long same_diff, all_diff;
while (i < cnt && !(sline[i].flag & mark))
i++;
if (cnt <= i)
break; /* No more interesting hunks */
- for (hunk_end = i + 1; hunk_end < cnt; hunk_end++)
- if (!(sline[hunk_end].flag & mark))
- break;
+ hunk_begin = i;
+ for (j = i + 1; j < cnt; j++) {
+ if (!(sline[j].flag & mark)) {
+ /* Look beyond the end to see if there
+ * is an interesting line after this
+ * hunk within context span.
+ */
+ unsigned long la; /* lookahead */
+ int contin = 0;
+ la = adjust_hunk_tail(sline, all_mask,
+ hunk_begin, j);
+ la = (la + context < cnt) ?
+ (la + context) : cnt;
+ while (j <= --la) {
+ if (sline[la].flag & mark) {
+ contin = 1;
+ break;
+ }
+ }
+ if (!contin)
+ break;
+ j = la;
+ }
+ }
+ hunk_end = j;
+
/* [i..hunk_end) are interesting. Now does it have
* the same change with all but one parent?
*/
@@ -387,13 +477,13 @@ static int make_hunks(struct sline *slin
}
if ((num_parent - 1 <= same) || (diff == 1)) {
/* This hunk is not that interesting after all */
- for (j = i; j < hunk_end; j++)
+ for (j = hunk_begin; j < hunk_end; j++)
sline[j].flag &= ~mark;
}
- else
- has_interesting = 1;
i = hunk_end;
}
+
+ has_interesting = give_context(sline, cnt, num_parent);
return has_interesting;
}
--
1.1.4.g2cff
^ permalink raw reply related
* Re: What is "-u" supposed to mean in git-fetch?
From: Junio C Hamano @ 2006-01-26 11:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0601261148510.32499@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 96b086d6 introduced "-u" to mean "--upload-pack" taking one argument. But
> long ago, b10ac50f1 from Aug 10 already introduced "-u" to mean
> "--update-head-ok" (without argument). This broke my scripts badly.
>
> So, what is it?
Ah, I was not careful enough when reviewing.
You are right. The newcomer --upload-pack should drop its
abbreviation shorter than "--upl".
> Also, in the course of researching this, I tried
>
> git-whatchanged git-fetch-script
As in Linus' message, "git whatchanged -- git-fetch-script" is
supposed to be the kosher way now, but it does *not* work.
I started to suspect that flag/option parsing with rev-parse has
outlived its usefulness, at least in whatchanged.
It is getting late, so won't have updates from me tonight.
Sorry.
^ permalink raw reply
* [PATCH 2/2] [CLEANUP] use symbolic name as return value
From: Uwe Zeisberger @ 2006-01-26 11:26 UTC (permalink / raw)
To: git
Signed-off-by: Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de>
---
sha1_name.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
9acfd0a5f5390460d3de7d3f04610b795f8e69dc
diff --git a/sha1_name.c b/sha1_name.c
index b95ef05..ba0747c 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -143,7 +143,7 @@ static int find_unique_short_object(int
}
/* Both have unique ones -- do they match? */
if (memcmp(packed_sha1, unpacked_sha1, 20))
- return -2;
+ return SHORT_NAME_AMBIGUOUS;
memcpy(sha1, packed_sha1, 20);
return 0;
}
--
1.1.4.g3e6c
--
Uwe Zeisberger
Set the I_WANT_A_BROKEN_PS environment variable to force BSD syntax ...
-- manpage of procps
^ permalink raw reply related
* [PATCH 1/2] [CLEANUP] remove unneeded header
From: Uwe Zeisberger @ 2006-01-26 11:25 UTC (permalink / raw)
To: git
Signed-off-by: Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de>
---
mailsplit.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
435f396a46d9bd29a9465573f028cdfbddc3c7d6
diff --git a/mailsplit.c b/mailsplit.c
index 14c1358..c529e2d 100644
--- a/mailsplit.c
+++ b/mailsplit.c
@@ -11,7 +11,6 @@
#include <sys/stat.h>
#include <string.h>
#include <stdio.h>
-#include <assert.h>
#include "cache.h"
static const char git_mailsplit_usage[] =
--
1.1.4.g3e6c
--
Uwe Zeisberger
http://www.google.com/search?q=gravity+on+earth%3D
^ permalink raw reply related
* Re: Safe way to remove .temp objects?
From: Andreas Ericsson @ 2006-01-26 11:18 UTC (permalink / raw)
To: Erik Mouw; +Cc: git
In-Reply-To: <20060126093507.GA5118@harddisk-recovery.nl>
Erik Mouw wrote:
> Hi,
>
> After a git repack, git count-objects reports there are still 20
> objects in the repository. It looks like those are temp objects:
>
> erik@arthur:~/git/linux-2.6 > ls .git/objects/??/
> .git/objects/14/:
> d6545767f5103b5ef4702bc8fffa18dbe32ce1.temp
>
> .git/objects/1a/:
> d37b580be4215f1b0927b7560f5e8b8d1bc0fa.temp
>
> [...]
>
> Is there a git command to remove those objects in a safe way, or can I
> just rm them without "harming" git??
>
>
$ git prune-packed
When you repack, you can run
$ git repack -d
to remove loose objects when you're done packing.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* How to create and keep up to date a naked/bare repository?
From: Mathieu Chouquet-Stringer @ 2006-01-26 11:12 UTC (permalink / raw)
To: git
In-Reply-To: <7v1wyvn9pc.fsf@assigned-by-dhcp.cox.net>
Hello,
I've got a couple of questions and reading (some of the files in) the
Documentation directory didn't really enlighten me...
Let's say I want to maintain a private (read-only) copy of a git repository
(eg git.git or linus-2.6.git). Because this repository is shared
internally (used by a bunch of boxes), I'd like to clone it as a bare
repo, no need to have the files checked out on my local master.
Cloning is done by running the following:
git clone --naked git://www.kernel.org/pub/scm/git/git.git git.git
Now I've got my repository. Because I'll share it with git-daemon, I touch
the git-daemon-export-ok file to export it.
The first problem arises when I try to keep this repo up to date.
If I try a git fetch or pull (more on that later), git complains because it
can't find a .git directory (which is correct as in a bare repository the
repository directory is the .git directory).
I can do a: GIT_DIR=. git fetch and it works but that's kind of ugly. I
can also link . to .git but it's as disgusting as the previous hack.
Maybe I'm missing something obvious here, is there an option to tell
fetch/pull that it's working with a bare repository?
The second question is I'd think I would have to use git fetch instead of
git pull as a pull is fetch + merge and merging wouldn't make much sense as
I didn't check out any files. Does it make any sense?
The third thing (can't reproduce ATM as I just got a fresh new clone) is
that git fetch was just fetching over and over the same objects...
Can anyone tell me what I'm doing wrong?
--
Mathieu Chouquet-Stringer
"Le disparu, si l'on vénère sa mémoire, est plus présent et
plus puissant que le vivant".
-- Antoine de Saint-Exupéry, Citadelle --
^ permalink raw reply
* What is "-u" supposed to mean in git-fetch?
From: Johannes Schindelin @ 2006-01-26 10:57 UTC (permalink / raw)
To: git, junkio
Hi,
96b086d6 introduced "-u" to mean "--upload-pack" taking one argument. But
long ago, b10ac50f1 from Aug 10 already introduced "-u" to mean
"--update-head-ok" (without argument). This broke my scripts badly.
So, what is it?
Also, in the course of researching this, I tried
git-whatchanged git-fetch-script
because git-whatchanged does not follow renames. But that did not work,
because there is no current file of that name! When I created a dummy file
of that name, git-whatchanged worked real fine! I consider that behaviour
a bug.
Ciao,
Dscho
^ permalink raw reply
* Safe way to remove .temp objects?
From: Erik Mouw @ 2006-01-26 9:35 UTC (permalink / raw)
To: git
Hi,
After a git repack, git count-objects reports there are still 20
objects in the repository. It looks like those are temp objects:
erik@arthur:~/git/linux-2.6 > ls .git/objects/??/
.git/objects/14/:
d6545767f5103b5ef4702bc8fffa18dbe32ce1.temp
.git/objects/1a/:
d37b580be4215f1b0927b7560f5e8b8d1bc0fa.temp
[...]
Is there a git command to remove those objects in a safe way, or can I
just rm them without "harming" git??
Erik
--
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
| Data lost? Stay calm and contact Harddisk-recovery.com
^ permalink raw reply
* Re: git describe fails without tags
From: Junio C Hamano @ 2006-01-26 9:02 UTC (permalink / raw)
To: Uwe Zeisberger; +Cc: git
In-Reply-To: <20060126084151.GB2941@informatik.uni-freiburg.de>
Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de> writes:
> I see two things to fix in that patch:
>
> 1) define DEFAULT_ABBREV (e.g. by moving it to cache.h, where
> find_unique_abbrev is defined.)
Sorry, the patch alone was not compilable since cleaning up the
definition of symbolic constants *_ABBREV comes before the patch
you quoted in the "pu" branch.
> 2) describe.c allows only abbrev >= 4. (Allowing values less than 2
> failes, because find_short_object_filename (and maybe others) assume
> len to be at least 2.) I think 4 is sensible.
Thanks. "rev-parse --abbrev=2" would have segfaulted without
your fix. I suspect substituting with MINIMUM instead of
DEFAULT in such a case would be more sensible, so...
-- >8 --
[PATCH] rev-parse --abbrev: do not try abbrev shorter than minimum.
We do not allow abbreviation shorter than 4 letters in other
parts of the system so do not attempt to generate such.
Noticed by Uwe Zeisberger.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
rev-parse.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
030d25d271adb2671f560b410d77585d8744acbf
diff --git a/rev-parse.c b/rev-parse.c
index 42969a6..8bf316e 100644
--- a/rev-parse.c
+++ b/rev-parse.c
@@ -206,8 +206,10 @@ int main(int argc, char **argv)
abbrev = DEFAULT_ABBREV;
if (arg[8] == '=')
abbrev = strtoul(arg + 9, NULL, 10);
- if (abbrev < 0 || 40 <= abbrev)
- abbrev = DEFAULT_ABBREV;
+ if (abbrev < MINIMUM_ABBREV)
+ abbrev = MINIMUM_ABBREV;
+ else if (40 <= abbrev)
+ abbrev = 40;
continue;
}
if (!strcmp(arg, "--sq")) {
--
1.1.4.g00a4
^ permalink raw reply related
* Re: git describe fails without tags
From: Uwe Zeisberger @ 2006-01-26 8:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmzhjif8i.fsf@assigned-by-dhcp.cox.net>
Hello Junio,
Junio C Hamano wrote:
> Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de> writes:
>
> > Yes, I wrote a script that automatically build git and install it to
> > ${HOME}/usr/stow/git-`git describe HEAD` and then stow(8)s it. Writing
> > a similar script for sparse cannot use git describe because there are no
> > tags ...
> > ...
> > It's a pity your not particularly interested, I like that patch's idea.
> > git describe dies with an error here in a situation where there is the
> > possibility to do something sensible.
>
> I think I understand the problem pretty well, and actually I am
> sympathetic to the cause.
>
> Having said that, I do not agree with the approach of your
> patch. It makes it inconvenient for scripts to tell describable
> and indescribable revs apart by checking the exit status from
> the command.
OK, that's fine for me. Then it would be sensible to add a note to the
docs describing the exit codes.
Thanks for your suggestion for my script.
Best regards
Uwe
--
Uwe Zeisberger
http://www.google.com/search?q=sin%28pi%2F2%29
^ permalink raw reply
* Re: git describe fails without tags
From: Uwe Zeisberger @ 2006-01-26 8:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vek2wws61.fsf@assigned-by-dhcp.cox.net>
Hello Junio,
Junio C Hamano wrote:
> 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;
I see two things to fix in that patch:
1) define DEFAULT_ABBREV (e.g. by moving it to cache.h, where
find_unique_abbrev is defined.)
2) describe.c allows only abbrev >= 4. (Allowing values less than 2
failes, because find_short_object_filename (and maybe others) assume
len to be at least 2.) I think 4 is sensible.
This results in the following patch:
--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.
This patch is a modification of a suggestion by Junio C Hamano.
Signed-off-by: Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de>
---
cache.h | 2 ++
describe.c | 1 -
rev-parse.c | 14 ++++++++++++++
3 files changed, 16 insertions(+), 1 deletions(-)
0d43ec7461b38d6a1d1563fd7dc2ebf399eabe9e
diff --git a/cache.h b/cache.h
index b493b65..139c670 100644
--- a/cache.h
+++ b/cache.h
@@ -177,6 +177,8 @@ extern int check_repository_format(void)
#define DATA_CHANGED 0x0020
#define TYPE_CHANGED 0x0040
+#define DEFAULT_ABBREV 8 /* maybe too many */
+
/* Return a statically allocated filename matching the sha1 signature */
extern char *mkpath(const char *fmt, ...) __attribute__((format (printf, 1, 2)));
extern char *git_path(const char *fmt, ...) __attribute__((format (printf, 1, 2)));
diff --git a/describe.c b/describe.c
index 4866510..6518f06 100644
--- a/describe.c
+++ b/describe.c
@@ -11,7 +11,6 @@ static const char describe_usage[] =
static int all = 0; /* Default to annotated tags only */
static int tags = 0; /* But allow any tags if --tags is specified */
-#define DEFAULT_ABBREV 8 /* maybe too many */
static int abbrev = DEFAULT_ABBREV;
static int names = 0, allocs = 0;
diff --git a/rev-parse.c b/rev-parse.c
index 0c951af..58cff6f 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 < 4 || 40 <= abbrev)
+ abbrev = DEFAULT_ABBREV;
+ continue;
+ }
if (!strcmp(arg, "--sq")) {
output_sq = 1;
continue;
--
1.1.4.g3e6c
Best regards
Uwe
--
Uwe Zeisberger
http://www.google.com/search?q=72+PS+point+in+inch
^ permalink raw reply related
* Re: git describe fails without tags
From: Junio C Hamano @ 2006-01-26 8:07 UTC (permalink / raw)
To: Uwe Zeisberger; +Cc: git
In-Reply-To: <20060126074421.GA2941@informatik.uni-freiburg.de>
Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de> writes:
> Yes, I wrote a script that automatically build git and install it to
> ${HOME}/usr/stow/git-`git describe HEAD` and then stow(8)s it. Writing
> a similar script for sparse cannot use git describe because there are no
> tags ...
> ...
> It's a pity your not particularly interested, I like that patch's idea.
> git describe dies with an error here in a situation where there is the
> possibility to do something sensible.
I think I understand the problem pretty well, and actually I am
sympathetic to the cause.
Having said that, I do not agree with the approach of your
patch. It makes it inconvenient for scripts to tell describable
and indescribable revs apart by checking the exit status from
the command.
In other words, I think a sensible thing can be done more sanely
in your script. Something like this?
#!/bin/sh
project=git ;# or 'sparse'
version=`git describe HEAD` ||
version=untagged-g`git rev-parse --abbrev HEAD`
$(MAKE) prefix=$HOME/usr/stow/$project-$version
If you want to squelch the error message from indescribable rev,
you could do:
version=`git describe HEAD 2>/dev/null` ||
of course.
^ permalink raw reply
* Re: git describe fails without tags
From: Uwe Zeisberger @ 2006-01-26 7:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vek2wws61.fsf@assigned-by-dhcp.cox.net>
Hello Junio,
Junio C Hamano wrote:
> 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?
>
> [...] 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*].
Yes, I wrote a script that automatically build git and install it to
${HOME}/usr/stow/git-`git describe HEAD` and then stow(8)s it. Writing
a similar script for sparse cannot use git describe because there are no
tags ...
> 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)
It's a pity your not particularly interested, I like that patch's idea.
git describe dies with an error here in a situation where there is the
possibility to do something sensible.
BTW, for the sake of consistency, I'd suggest
- die("cannot describe '%s'", sha1_to_hex(cmit->object.sha1));
+ printf("g%s\n", find_unique_abbrev(cmit->object.sha1, abbrev));
Best regards
Uwe
--
Uwe Zeisberger
http://www.google.com/search?q=1+year+divided+by+3+in+seconds
^ 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
* 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
* 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
* 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
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