* git commit --amend -F ?
From: Jan Hudec @ 2007-06-11 5:05 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 173 bytes --]
Hello,
Why isn't git commit --amend -F allowed?
Yes, I know guis (qgit) should be using plumbing commands, but still...
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [Qgit RFC] commit --amend
From: Marco Costalba @ 2007-06-11 5:24 UTC (permalink / raw)
To: Jan Hudec; +Cc: git
In-Reply-To: <20070611044258.GJ4084@efreet.light.src>
On 6/11/07, Jan Hudec <bulb@ucw.cz> wrote:
>
> So I am now inclined more to the separate action and trying to go that way.
> But the difference between the variants would not be that big.
>
Ok for me. Please, feel free to implement what's the best for you and
I will apply the patch.
Marco
^ permalink raw reply
* Re: [Qgit RFC] commit --amend
From: Marco Costalba @ 2007-06-11 5:45 UTC (permalink / raw)
To: Jan Hudec; +Cc: git
In-Reply-To: <20070611044258.GJ4084@efreet.light.src>
On 6/11/07, Jan Hudec <bulb@ucw.cz> wrote:
>
> I think I mostly understood it now. Thank you.
>
Anyhow I think this could be useful to you:
/*
getAllRefSha() returns the list of sha of a given
type, where type is a mask of Git::RefType flags
see src/git.h.
In this case we want the sha of the current branch
*/
QStringList revs = getAllRefSha(CUR_BRANCH);
if (!revs.isEmpty()) {
// all the sha info is stored in this QGit::Rev
// class defined in src/common.h
const Rev* r = revLookup(revs.first());
// short log (title) is
r->shortLog();
// message body is
r->longLog();
// etc....
}
^ permalink raw reply
* Re: git-svn set-tree bug
From: Junio C Hamano @ 2007-06-11 5:52 UTC (permalink / raw)
To: Eric Wong; +Cc: Joakim Tjernlund, Steven Grimm, git
In-Reply-To: <20070611042509.GA19866@muzzle>
Eric Wong <normalperson@yhbt.net> writes:
> Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
>> > -----Original Message-----
>> > From: Steven Grimm [mailto:koreth@midwinter.com]
>> > Sent: den 11 juni 2007 01:37
>> > To: Joakim Tjernlund
>> > Cc: 'Eric Wong'; 'git'
>> > Subject: Re: git-svn set-tree bug
>> >
>> > Joakim Tjernlund wrote:
>> > > Is there a way to tell set-tree to commit the whole "merge" branch
>> > > as one svn commit?
>> > > If I merge the latest kernel into my tree there will
>> > > be a lot of commits that I don't want in svn.
>> > >
>> >
>> > You want a "squash" merge. Something like this:
>> >
>> > git checkout -b tempbranch origin/svn-branch-to-commit-merge-to
>> > git merge --squash branch-with-commits-you-want-to-merge
>> > git commit
>> > git svn dcommit
>> >
>> > The "merge" command will merge in the changes but will not commit
>> > anything; when you do the explicit "commit" command
>> > afterwards, you get
>> > the contents of the merge but from git's point of view it's just a
>> > regular commit so git-svn doesn't get confused.
>> >
>> > After you do git svn dcommit, you may want to edit
>> > .git/info/grafts to
>> > tell git after the fact that this commit was a merge. It won't hurt
>> > git-svn at that point and it will mean you can do another merge later
>> > without git getting confused about what has already been merged.
>> >
>> > Take a look at the script I posted a while back, which does something
>> > similar:
>> >
>> > http://www.spinics.net/lists/git/msg29119.html
>
> I must have missed this message the first time around.
>
>> Hi Steven
>>
>> That looks promising, especially Junos comment about making git-svn
>> able to deal with merges. Eric, do you feel this is doable?
>
> Doable? Yes. However, I think using grafts is quite hackish and
> unreliable[1]. I'd rather just have users using set-tree if
> they want to deal with non-linear history in the first place.
>
> I'd personally avoid any sort of non-linear history when interacting
> with SVN repositories, however.
I've been wondering if you can do a moral equilvalent of the
graft trick but without using graft inside dcommit. Perform a
merge --squash of the other branch (call the tip commit $B),
then dcommit on the git side as usual, and call it commit $C.
Steven's procedure would do a graft trick here, but instead of
doing that, rewrite $C to have the two parents. Using the tree
object of $C, create a new git commit $D that is a merge between
the parent of $C (i.e. $C^) and the squashed branch tip $B.
Replace the tip of the current branch (which is $C) with $D.
Finally, replace the mapping between svn commit and git side
recorded in the revdb (which currently says $C on the git side
corresponds to the HEAD of SVN side) with this new commit $D.
Wouldn't that let the git side know what was merged into the
branch, so that later merges on the git side would go smoothly?
Or am I grossly misunderstanding how dcommit, tracking of svn vs
git commit mappings and the graft trick work?
^ permalink raw reply
* Re: [PATCH] Add --no-reuse-delta option to git-gc
From: Steven Grimm @ 2007-06-11 6:20 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Sam Vilain, Shawn O. Pearce, Junio C Hamano, Daniel Barkalow,
Theodore Ts'o, Git Mailing List
In-Reply-To: <alpine.LFD.0.99.0706102144080.12885@xanadu.home>
Nicolas Pitre wrote:
>
> It won't happen for a simple reason: to be backward compatible with
> older GIT clients. If you have your repo compressed with bzip2 and an
> old client pulls it then the server would have to decompress and
> recompress everything with gzip. If instead your repo remains with gzip
> and a new client asks for bzip2 then you have to recompress as well
> (slow). So in practice it is best to remain with a single compression
> method.
>
Not that I really think this is all that important (my original question
was more out of curiosity than anything) but I don't think those are
really issues.
Even with a better compression scheme, nobody would want to remove gzip
support; if you are creating a repo that needs to be compatible with old
clients -- and of course not all repositories need that -- you'd just
configure it to use gzip (or more likely, *not* configure it to use the
other method.) There are already options whose documentation says,
"Don't enable this if you want your repo to be accessed by git clients
older than version X." In other words, git already has an established
approach for adding new non-backward-compatible features. Some projects,
e.g. internal corporate ones, can mandate that everyone upgrade their
clients, and more importantly, once any new git feature has been out for
a long enough time, even public projects can reasonably say, "You need
version X to access our repo." If alternate compression were introduced
today, in five years would anyone care that there'd be some ancient,
ancient clients that couldn't use it?
And since the hypothetical new client would have support for both
compression types, pulling from a gzip-based repo could be accomplished
totally transparently; you could, one assumes, even pull from a gzip
repo and pack locally using the other scheme if you felt like it.
-Steve
^ permalink raw reply
* git-gui 0.7.3
From: Shawn O. Pearce @ 2007-06-11 6:26 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: Linus Torvalds
Linus recently pointed out that the blame viewer in git-gui 0.7.2
is useless, and the one parked seemingly indefinately in my pu
branch was much better, and couldn't do any worse than 0.7.2's.
So here's git-gui 0.7.3, available in my maint branch:
git://repo.or.cz/git-gui.git maint
for merging into the next public Git release.
Features since 0.7.2:
* New selection indication and softer colors. This change is
due to the efforts of Matthijs Melchior, and makes the main
interface window slightly more pleasing to read.
* Vastly improved internal blame viewer. The new viewer was
incrementally improved, but in the end it amounted to a total
rewrite by the time we reached the 0.7.3 release.
* Blame viewer now shows two blame passes side-by-side on the
same file, giving the user fast access to original author and
relocation author, for any line of the file.
* Mouse tooltips appear in the blame viewer when you mouse over
a line of interest.
* Hyperlinks to original location are offered for both the original
commit and the relocation commit in the blame viewer.
Bug fixes since 0.7.2:
* Allow creating a branch when none exists. Previously we crashed
if the repository had no local branches, but had a valid HEAD.
* Better handle internal Tk destroy messages sent to widgets;
we used to terminate the entire git-gui process when any widget
was destroyed.
* Minor font corrections, where git-gui was not honoring the user's
configured preferences.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Add --no-reuse-delta option to git-gc
From: Shawn O. Pearce @ 2007-06-11 6:31 UTC (permalink / raw)
To: Steven Grimm
Cc: Nicolas Pitre, Sam Vilain, Junio C Hamano, Daniel Barkalow,
Theodore Ts'o, Git Mailing List
In-Reply-To: <466CE998.9000706@midwinter.com>
Steven Grimm <koreth@midwinter.com> wrote:
> Nicolas Pitre wrote:
> >
> >It won't happen for a simple reason: to be backward compatible with
> >older GIT clients. If you have your repo compressed with bzip2 and an
> >old client pulls it then the server would have to decompress and
> >recompress everything with gzip. If instead your repo remains with gzip
> >and a new client asks for bzip2 then you have to recompress as well
> >(slow). So in practice it is best to remain with a single compression
> >method.
> >
>
> Not that I really think this is all that important (my original question
> was more out of curiosity than anything) but I don't think those are
> really issues.
...
> And since the hypothetical new client would have support for both
> compression types, pulling from a gzip-based repo could be accomplished
> totally transparently; you could, one assumes, even pull from a gzip
> repo and pack locally using the other scheme if you felt like it.
Right, I agree with Steven here.
Pack v4 (which is rapidly becoming vaporware it seems) uses such
a radically different encoding for its commit and tree objects
that you cannot send them as-is to a client unless that client
also understands pack v4. Consequently you need to decompress and
recompress those objects when talking to an older peer; this isn't
very different from a switch to bzip2.
That said, I think switching to a different generic compressor isn't
that interesting. We can probably do a lot better by organizing
files into clusters, where those clusters have large number of
symbols in common, and then compress everything in the same cluster
with the same pack-wide dictionary.
Specifically I'm thinking that you may be able to cluster the *.h/*.c
into one cluster, and the Makefile into another, and the .gitignore
into a third cluster, and then leverage the large commonalities
between those blobs when building a dictionary and compressing them.
No, I haven't prototyped it out yet.
--
Shawn.
^ permalink raw reply
* Re: That improved git-gui blame viewer..
From: Shawn O. Pearce @ 2007-06-11 6:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.0.98.0706091117510.20321@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> That said, I do have one comment about the state of git-gui "pu".. I think
> it's fairly pretty, and definitely useful,
Thanks! I'm glad at least one other person on this planet finds
my work on the blame viewer at least partially useful.
> but one feature I end up really
> wishing for is a "search" button (or Ctrl-F). I might not know what
> line-number I'm looking for, I'm more likely to know which function I want
> to look at, and the most natural way to find it is with a simple ctrl-F.
No, there isn't a search. Tk internally offers one, I just haven't
bound UI to it. Ctrl-F is actually bound to page down, much as it is
in vi. Actually vi keys work everywhere in git-gui for scrolling.
I pushed out 0.7.3 tonight without search. I'll work on search and
jump-to-line this week, and try to get an 0.7.4 early next week
with those and maybe some other improvements in the blame viewer
that I want to get done.
I may actually wind up just doing 0.8.0 sooner than I had expected.
There's a lot of new features queued up in the master branch that I
slated for 0.8.0 that I'm using on a daily basis and is production
stable.
I wanted to implement some slick inotify() based features for the
main window during 0.8.0, but I haven't had time to work on them.
It would really improve performance of git-gui on Windows NT, and
I do have a lot of git-gui users there.
--
Shawn.
^ permalink raw reply
* Re: git-svn set-tree bug
From: Steven Grimm @ 2007-06-11 6:58 UTC (permalink / raw)
To: Eric Wong; +Cc: Joakim Tjernlund, git
In-Reply-To: <20070611042509.GA19866@muzzle>
Eric Wong wrote:
> Doable? Yes. However, I think using grafts is quite hackish and
> unreliable[1]. I'd rather just have users using set-tree if
> they want to deal with non-linear history in the first place.
>
Agreed about grafts being hackish and unreliable. But they were what I
had to work with, given that I know little enough about git-svn's
internals to be able to implement Junio's more robust idea.
IMO set-tree is not much of an option. In my environment it is
unacceptable for there to be any possibility of accidentally and
silently overwriting some other change that just happened to hit the svn
repo right before I committed my change, which (unless it has changed
since I last tried it) set-tree will happily do. I can get away with
doing that maybe once before my company's release manager will, quite
justifiably, require me to stop using git and switch back to the
standard svn client.
> I'd personally avoid any sort of non-linear history when interacting
> with SVN repositories, however.
>
Which is a shame since git loses a lot of its utility without nonlinear
history. For example, the script I posted uses git to do merges between
svn branches. It works wonderfully even if, as you and Junio point out,
its use of grafts to record svn merges scales poorly and is potentially
susceptible to corruption. Thanks to the ability to record the fact that
my merges between svn branches were actually merges, my git clone has a
more complete picture of what's in my svn repository than the svn
repository itself does!
-Steve
^ permalink raw reply
* Re: [PATCH] Introduce light weight commit annotations
From: Alex Riesen @ 2007-06-11 7:24 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Johannes Schindelin, git, gitster, Johan Herland
In-Reply-To: <alpine.LFD.0.99.0706102206590.12885@xanadu.home>
On 6/11/07, Nicolas Pitre <nico@cam.org> wrote:
> On Sat, 9 Jun 2007, Johannes Schindelin wrote:
>
> > The annotations are tracked in a new ref, refs/annotations/commits,
> > in the same fan-out style as .git/objects/??/*, only that they only
> > exist in the object database now.
>
> Isn't this abusing the refs namespace a bit? Why not
> .git/annotations/... instead?
>
It is still a reference, really. Besides, if it is not under refs/, we'd
have to change fetch/push to allow distribution of the notes/annotations
(there are special assumptions regarding reference names starting
with "refs/"). Right now it just works.
^ permalink raw reply
* Re: [PATCH] git-svn: use git-log rather than rev-list | xargs cat-file
From: Junio C Hamano @ 2007-06-11 7:34 UTC (permalink / raw)
To: Eric Wong; +Cc: Sam Vilain, git
In-Reply-To: <20070610212459.GA12222@muzzle>
Eric Wong <normalperson@yhbt.net> writes:
> Sam Vilain <sam@vilain.net> wrote:
>> This saves a bit of time when rebuilding the git-svn index.
>
> Does git-log still have the 16k buffer limit? If so then we can't use
> it because commit messages over 16k will be truncated and the git-svn-id
> line will not show up. Also, if that limit is removed I'd prefer to
> just add --pretty=raw to rev-list because git-log is stil porcelain and
> more likely to change.
How about this? It passes the test suite, but other than that
hasn't seen much test yet. I tried to be careful, but sanity
checking by extra sets of eyeballs would be needed.
It changes length from int unsigned long in several places, and
you would need to look out for a boolean test like this:
if (current_length < limit_length - slop)
... do something ...
as it now should be written like this:
if (current_length + slop < limit_length)
... do something ...
-- >8 --
Subject: Lift 16kB limit of log message output
Traditionally we had 16kB limit when formatting log messages for
output, because it was easier to arrange for the caller to have
a reasonably big buffer and pass it down without ever worrying
about reallocating.
This changes the calling convention of pretty_print_commit() to
lift this limit. Instead of the buffer and remaining length, it
now takes a pointer to the pointer that points at the allocated
buffer, and another pointer to the location that stores the
allocated length, and reallocates the buffer as necessary.
To support the user format, the error return of interpolate()
needed to be changed. It used to return a bool telling "Ok the
result fits", or "Sorry, I had to truncate it". Now it returns
0 on success, and returns the size of the buffer it wants in
order to fit the whole result.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-branch.c | 17 +++++++++-----
builtin-log.c | 6 +++-
builtin-rev-list.c | 8 ++++--
builtin-show-branch.c | 23 +++++++++++---------
commit.c | 55 ++++++++++++++++++++++++++++++++++++++----------
commit.h | 2 +-
interpolate.c | 46 ++++++++++++++++++----------------------
interpolate.h | 6 ++--
log-tree.c | 35 ++++++++++++++++++++----------
9 files changed, 124 insertions(+), 74 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index da48051..d7c321a 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -242,7 +242,6 @@ static void print_ref_item(struct ref_item *item, int maxwidth, int verbose,
char c;
int color;
struct commit *commit;
- char subject[256];
switch (item->kind) {
case REF_LOCAL_BRANCH:
@@ -263,17 +262,23 @@ static void print_ref_item(struct ref_item *item, int maxwidth, int verbose,
}
if (verbose) {
+ char *subject = NULL;
+ unsigned long subject_len = 0;
+ const char *sub = " **** invalid ref ****";
+
commit = lookup_commit(item->sha1);
- if (commit && !parse_commit(commit))
+ if (commit && !parse_commit(commit)) {
pretty_print_commit(CMIT_FMT_ONELINE, commit, ~0,
- subject, sizeof(subject), 0,
+ &subject, &subject_len, 0,
NULL, NULL, 0);
- else
- strcpy(subject, " **** invalid ref ****");
+ sub = subject;
+ }
printf("%c %s%-*s%s %s %s\n", c, branch_get_color(color),
maxwidth, item->name,
branch_get_color(COLOR_BRANCH_RESET),
- find_unique_abbrev(item->sha1, abbrev), subject);
+ find_unique_abbrev(item->sha1, abbrev), sub);
+ if (subject)
+ free(subject);
} else {
printf("%c %s%s%s\n", c, branch_get_color(color), item->name,
branch_get_color(COLOR_BRANCH_RESET));
diff --git a/builtin-log.c b/builtin-log.c
index 0aede76..b9035ab 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -742,11 +742,13 @@ int cmd_cherry(int argc, const char **argv, const char *prefix)
sign = '-';
if (verbose) {
- static char buf[16384];
+ char *buf = NULL;
+ unsigned long buflen = 0;
pretty_print_commit(CMIT_FMT_ONELINE, commit, ~0,
- buf, sizeof(buf), 0, NULL, NULL, 0);
+ &buf, &buflen, 0, NULL, NULL, 0);
printf("%c %s %s\n", sign,
sha1_to_hex(commit->object.sha1), buf);
+ free(buf);
}
else {
printf("%c %s\n", sign,
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index ebf53f5..813aadf 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -92,11 +92,13 @@ static void show_commit(struct commit *commit)
putchar('\n');
if (revs.verbose_header) {
- static char pretty_header[16384];
+ char *buf = NULL;
+ unsigned long buflen = 0;
pretty_print_commit(revs.commit_format, commit, ~0,
- pretty_header, sizeof(pretty_header),
+ &buf, &buflen,
revs.abbrev, NULL, NULL, revs.date_mode);
- printf("%s%c", pretty_header, hdr_termination);
+ printf("%s%c", buf, hdr_termination);
+ free(buf);
}
fflush(stdout);
if (commit->parents) {
diff --git a/builtin-show-branch.c b/builtin-show-branch.c
index c892f1f..4fa87f6 100644
--- a/builtin-show-branch.c
+++ b/builtin-show-branch.c
@@ -259,17 +259,19 @@ static void join_revs(struct commit_list **list_p,
static void show_one_commit(struct commit *commit, int no_name)
{
- char pretty[256], *cp;
+ char *pretty = NULL;
+ const char *pretty_str = "(unavailable)";
+ unsigned long pretty_len = 0;
struct commit_name *name = commit->util;
- if (commit->object.parsed)
+
+ if (commit->object.parsed) {
pretty_print_commit(CMIT_FMT_ONELINE, commit, ~0,
- pretty, sizeof(pretty), 0, NULL, NULL, 0);
- else
- strcpy(pretty, "(unavailable)");
- if (!prefixcmp(pretty, "[PATCH] "))
- cp = pretty + 8;
- else
- cp = pretty;
+ &pretty, &pretty_len,
+ 0, NULL, NULL, 0);
+ pretty_str = pretty;
+ }
+ if (!prefixcmp(pretty_str, "[PATCH] "))
+ pretty_str += 8;
if (!no_name) {
if (name && name->head_name) {
@@ -286,7 +288,8 @@ static void show_one_commit(struct commit *commit, int no_name)
printf("[%s] ",
find_unique_abbrev(commit->object.sha1, 7));
}
- puts(cp);
+ puts(pretty_str);
+ free(pretty);
}
static char *ref_name[MAX_REVS + 1];
diff --git a/commit.c b/commit.c
index 4ca4d44..d43a68e 100644
--- a/commit.c
+++ b/commit.c
@@ -776,7 +776,7 @@ static void fill_person(struct interp *table, const char *msg, int len)
}
static long format_commit_message(const struct commit *commit,
- const char *msg, char *buf, unsigned long space)
+ const char *msg, char **buf_p, unsigned long *space_p)
{
struct interp table[] = {
{ "%H" }, /* commit hash */
@@ -905,16 +905,27 @@ static long format_commit_message(const struct commit *commit,
if (!table[i].value)
interp_set_entry(table, i, "<unknown>");
- interpolate(buf, space, user_format, table, ARRAY_SIZE(table));
+ do {
+ char *buf = *buf_p;
+ unsigned long space = *space_p;
+
+ space = interpolate(buf, space, user_format,
+ table, ARRAY_SIZE(table));
+ if (!space)
+ break;
+ buf = xrealloc(buf, space);
+ *buf_p = buf;
+ *space_p = space;
+ } while (1);
interp_clear_table(table, ARRAY_SIZE(table));
- return strlen(buf);
+ return strlen(*buf_p);
}
unsigned long pretty_print_commit(enum cmit_fmt fmt,
const struct commit *commit,
unsigned long len,
- char *buf, unsigned long space,
+ char **buf_p, unsigned long *space_p,
int abbrev, const char *subject,
const char *after_subject,
enum date_mode dmode)
@@ -927,9 +938,11 @@ unsigned long pretty_print_commit(enum cmit_fmt fmt,
int plain_non_ascii = 0;
char *reencoded;
const char *encoding;
+ char *buf;
+ unsigned long space, slop;
if (fmt == CMIT_FMT_USERFORMAT)
- return format_commit_message(commit, msg, buf, space);
+ return format_commit_message(commit, msg, buf_p, space_p);
encoding = (git_log_output_encoding
? git_log_output_encoding
@@ -969,6 +982,26 @@ unsigned long pretty_print_commit(enum cmit_fmt fmt,
}
}
+ space = *space_p;
+ buf = *buf_p;
+
+ /*
+ * We do not want to repeatedly realloc below, so
+ * preallocate with enough slop to hold MIME headers,
+ * "Subject: " prefix, etc.
+ */
+ slop = 1000;
+ if (subject)
+ slop += strlen(subject);
+ if (after_subject)
+ slop += strlen(after_subject);
+ if (space < strlen(msg) + slop) {
+ space = strlen(msg) + slop;
+ buf = xrealloc(buf, space);
+ *space_p = space;
+ *buf_p = buf;
+ }
+
for (;;) {
const char *line = msg;
int linelen = get_one_line(msg, len);
@@ -976,14 +1009,12 @@ unsigned long pretty_print_commit(enum cmit_fmt fmt,
if (!linelen)
break;
- /*
- * We want some slop for indentation and a possible
- * final "...". Thus the "+ 20".
- */
+ /* 20 would cover indent and leave us some slop */
if (offset + linelen + 20 > space) {
- memcpy(buf + offset, " ...\n", 8);
- offset += 8;
- break;
+ space = offset + linelen + 20;
+ buf = xrealloc(buf, space);
+ *buf_p = buf;
+ *space_p = space;
}
msg += linelen;
diff --git a/commit.h b/commit.h
index a313b53..467872e 100644
--- a/commit.h
+++ b/commit.h
@@ -61,7 +61,7 @@ enum cmit_fmt {
};
extern enum cmit_fmt get_commit_format(const char *arg);
-extern unsigned long pretty_print_commit(enum cmit_fmt fmt, const struct commit *, unsigned long len, char *buf, unsigned long space, int abbrev, const char *subject, const char *after_subject, enum date_mode dmode);
+extern unsigned long pretty_print_commit(enum cmit_fmt fmt, const struct commit *, unsigned long len, char **buf_p, unsigned long *space_p, int abbrev, const char *subject, const char *after_subject, enum date_mode dmode);
/** Removes the first commit from a list sorted by date, and adds all
* of its parents.
diff --git a/interpolate.c b/interpolate.c
index fb30694..0082677 100644
--- a/interpolate.c
+++ b/interpolate.c
@@ -44,33 +44,33 @@ void interp_clear_table(struct interp *table, int ninterps)
* { "%%", "%"},
* }
*
- * Returns 1 on a successful substitution pass that fits in result,
- * Returns 0 on a failed or overflowing substitution pass.
+ * Returns 0 on a successful substitution pass that fits in result,
+ * Returns a number of bytes needed to hold the full substituted
+ * string otherwise.
*/
-int interpolate(char *result, int reslen,
+unsigned long interpolate(char *result, unsigned long reslen,
const char *orig,
const struct interp *interps, int ninterps)
{
const char *src = orig;
char *dest = result;
- int newlen = 0;
+ unsigned long newlen = 0;
const char *name, *value;
- int namelen, valuelen;
+ unsigned long namelen, valuelen;
int i;
char c;
memset(result, 0, reslen);
- while ((c = *src) && newlen < reslen - 1) {
+ while ((c = *src)) {
if (c == '%') {
/* Try to match an interpolation string. */
for (i = 0; i < ninterps; i++) {
name = interps[i].name;
namelen = strlen(name);
- if (strncmp(src, name, namelen) == 0) {
+ if (strncmp(src, name, namelen) == 0)
break;
- }
}
/* Check for valid interpolation. */
@@ -78,29 +78,25 @@ int interpolate(char *result, int reslen,
value = interps[i].value;
valuelen = strlen(value);
- if (newlen + valuelen < reslen - 1) {
+ if (newlen + valuelen + 1 < reslen) {
/* Substitute. */
strncpy(dest, value, valuelen);
- newlen += valuelen;
dest += valuelen;
- src += namelen;
- } else {
- /* Something's not fitting. */
- return 0;
}
-
- } else {
- /* Skip bogus interpolation. */
- *dest++ = *src++;
- newlen++;
+ newlen += valuelen;
+ src += namelen;
+ continue;
}
-
- } else {
- /* Straight copy one non-interpolation character. */
- *dest++ = *src++;
- newlen++;
}
+ /* Straight copy one non-interpolation character. */
+ if (newlen + 1 < reslen)
+ *dest++ = *src;
+ src++;
+ newlen++;
}
- return newlen < reslen - 1;
+ if (newlen + 1 < reslen)
+ return 0;
+ else
+ return newlen + 2;
}
diff --git a/interpolate.h b/interpolate.h
index 16a26b9..77407e6 100644
--- a/interpolate.h
+++ b/interpolate.h
@@ -19,8 +19,8 @@ struct interp {
extern void interp_set_entry(struct interp *table, int slot, const char *value);
extern void interp_clear_table(struct interp *table, int ninterps);
-extern int interpolate(char *result, int reslen,
- const char *orig,
- const struct interp *interps, int ninterps);
+extern unsigned long interpolate(char *result, unsigned long reslen,
+ const char *orig,
+ const struct interp *interps, int ninterps);
#endif /* INTERPOLATE_H */
diff --git a/log-tree.c b/log-tree.c
index 4bef909..0cf21bc 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -79,16 +79,25 @@ static int detect_any_signoff(char *letter, int size)
return seen_head && seen_name;
}
-static int append_signoff(char *buf, int buf_sz, int at, const char *signoff)
+static unsigned long append_signoff(char **buf_p, unsigned long *buf_sz_p,
+ unsigned long at, const char *signoff)
{
static const char signed_off_by[] = "Signed-off-by: ";
- int signoff_len = strlen(signoff);
+ size_t signoff_len = strlen(signoff);
int has_signoff = 0;
- char *cp = buf;
-
- /* Do we have enough space to add it? */
- if (buf_sz - at <= strlen(signed_off_by) + signoff_len + 3)
- return at;
+ char *cp;
+ char *buf;
+ unsigned long buf_sz;
+
+ buf = *buf_p;
+ buf_sz = *buf_sz_p;
+ if (buf_sz <= at + strlen(signed_off_by) + signoff_len + 3) {
+ buf_sz += strlen(signed_off_by) + signoff_len + 3;
+ buf = xrealloc(buf, buf_sz);
+ *buf_p = buf;
+ *buf_sz_p = buf_sz;
+ }
+ cp = buf;
/* First see if we already have the sign-off by the signer */
while ((cp = strstr(cp, signed_off_by))) {
@@ -133,7 +142,8 @@ static unsigned int digits_in_number(unsigned int number)
void show_log(struct rev_info *opt, const char *sep)
{
- static char this_header[16384];
+ char *msgbuf = NULL;
+ unsigned long msgbuf_len = 0;
struct log_info *log = opt->loginfo;
struct commit *commit = log->commit, *parent = log->parent;
int abbrev = opt->diffopt.abbrev;
@@ -278,14 +288,15 @@ void show_log(struct rev_info *opt, const char *sep)
/*
* And then the pretty-printed message itself
*/
- len = pretty_print_commit(opt->commit_format, commit, ~0u, this_header,
- sizeof(this_header), abbrev, subject,
+ len = pretty_print_commit(opt->commit_format, commit, ~0u,
+ &msgbuf, &msgbuf_len, abbrev, subject,
extra_headers, opt->date_mode);
if (opt->add_signoff)
- len = append_signoff(this_header, sizeof(this_header), len,
+ len = append_signoff(&msgbuf, &msgbuf_len, len,
opt->add_signoff);
- printf("%s%s%s", this_header, extra, sep);
+ printf("%s%s%s", msgbuf, extra, sep);
+ free(msgbuf);
}
int log_tree_diff_flush(struct rev_info *opt)
^ permalink raw reply related
* Re: [PATCH] Introduce light weight commit annotations
From: Junio C Hamano @ 2007-06-11 7:43 UTC (permalink / raw)
To: Alex Riesen
Cc: Nicolas Pitre, Johannes Schindelin, git, gitster, Johan Herland
In-Reply-To: <81b0412b0706110024mf975011t27b23555f6a23cc6@mail.gmail.com>
"Alex Riesen" <raa.lkml@gmail.com> writes:
> It is still a reference, really. Besides, if it is not under refs/, we'd
> have to change fetch/push to allow distribution of the notes/annotations
> (there are special assumptions regarding reference names starting
> with "refs/"). Right now it just works.
Two issues.
One is that it is unclear is how the reachability rules should
be. Should an ??/?{38} entry in the refs/annotations/commits
protects the commit the entry talks about (i.e. ???{38}) from
getting pruned?
Another is how different kinds of annotations on the same commit
should be managed. Should different commits and their histories
pointed at by refs/annotations/{frotz,xyzzy,...} be used for
that? Or perhaps we should make ??/?{38} a tree that has
multiple files underneath it?
^ permalink raw reply
* [PATCH] Avoid double-slash in path names that depend on $(sharedir).
From: Johannes Sixt @ 2007-06-11 8:02 UTC (permalink / raw)
To: git, Junio C Hamano, Shawn O. Pearce; +Cc: Johannes Sixt
Recent git-gui has the ability to determine the location of its library
files relative to the --exec-dir. Its Makefile enables this capability
depending on the install paths that are specified. However, without this
fix there is an extra slash in a path specification, so that the Makefile
does not recognize the equivalence of two paths that it compares.
A side-effect is that all "standard" builds (which do not set $(sharedir)
explicitly) now exploit above mentioned gut-gui feature.
Another side-effect is that an ugly compiled-in double-slash in
$(template_dir) is avoided.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index af84af9..c23031c 100644
--- a/Makefile
+++ b/Makefile
@@ -144,7 +144,7 @@ STRIP ?= strip
prefix = $(HOME)
bindir = $(prefix)/bin
gitexecdir = $(bindir)
-sharedir = $(prefix)/share/
+sharedir = $(prefix)/share
template_dir = $(sharedir)/git-core/templates/
ifeq ($(prefix),/usr)
sysconfdir = /etc
--
1.5.2.1.120.gd732
^ permalink raw reply related
* Re: [PATCH] Introduce light weight commit annotations
From: Alex Riesen @ 2007-06-11 8:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, Johannes Schindelin, git, Johan Herland
In-Reply-To: <7vbqfnrl54.fsf@assigned-by-dhcp.pobox.com>
On 6/11/07, Junio C Hamano <gitster@pobox.com> wrote:
> "Alex Riesen" <raa.lkml@gmail.com> writes:
>
> > It is still a reference, really. Besides, if it is not under refs/, we'd
> > have to change fetch/push to allow distribution of the notes/annotations
> > (there are special assumptions regarding reference names starting
> > with "refs/"). Right now it just works.
>
> Two issues.
>
> One is that it is unclear is how the reachability rules should
> be. Should an ??/?{38} entry in the refs/annotations/commits
> protects the commit the entry talks about (i.e. ???{38}) from
> getting pruned?
I think it should be the other way around: annotations get loose
and reported as such (and maybe even removed) by git-fsck.
^ permalink raw reply
* Re: [PATCH] Avoid double-slash in path names that depend on $(sharedir).
From: Junio C Hamano @ 2007-06-11 8:18 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Shawn O. Pearce
In-Reply-To: <11815489372169-git-send-email-johannes.sixt@telecom.at>
Johannes Sixt <johannes.sixt@telecom.at> writes:
> diff --git a/Makefile b/Makefile
> index af84af9..c23031c 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -144,7 +144,7 @@ STRIP ?= strip
> prefix = $(HOME)
> bindir = $(prefix)/bin
> gitexecdir = $(bindir)
> -sharedir = $(prefix)/share/
> +sharedir = $(prefix)/share
> template_dir = $(sharedir)/git-core/templates/
> ifeq ($(prefix),/usr)
> sysconfdir = /etc
This suggests that we would also want to drop the trailing slash
from template_dir, doesn't it?
I took a brief look at builtin-init-db.c but it seems that the
code is safe with or without the trailing slash there.
^ permalink raw reply
* Re: [PATCH 2/3] Add gitmodules(5)
From: Sven Verdoolaege @ 2007-06-11 8:34 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Junio C Hamano, Frank Lichtenheld, Johannes Schindelin, git
In-Reply-To: <8c5c35580706101414r72c45e84q2b81083f8f88ec40@mail.gmail.com>
On Sun, Jun 10, 2007 at 11:14:27PM +0200, Lars Hjemli wrote:
> And I'll drop the "unless otherwise
> noted, name=path" behaviour. If we later decide it would be useful we
> can always "re-add" it.
So every (sub)module subsection will have to have a path element?
Why?
skimo
^ permalink raw reply
* Re: [RFC] git integrated bugtracking
From: Pierre Habouzit @ 2007-06-11 8:45 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90706101614h48112deel70d848f4312c88d7@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 10572 bytes --]
On Mon, Jun 11, 2007 at 11:14:03AM +1200, Martin Langhoff wrote:
> On 6/10/07, Pierre Habouzit <madcoder@debian.org> wrote:
> > On Sun, Jun 10, 2007 at 06:59:13PM +1200, Martin Langhoff wrote:
> >> Adding git & gitweb support to traq, bugzilla, mantis, gforge, etc is
> >> what is going to make the difference. Most of those have already the
> >> ability to "link" to one or more commits -- after the commits are done
> >> and in GIT.
> >
> > Sure, you can do that and still inherit from the many downsides of
> >those tools: central, needs another separate tool to work with, and a
> >tool that nowadays tends to eat 500Mb of your memory if you take the
> >most hype implementation of it (Yes I'm describing a web browser), that
> >is slow like hell (because yes, there is many clients at the same time
> >on the central server, that is overloaded like hell), and so on.
>
> Most usable BTSs work on lighter webbrowsers, and can be tuned to work
> reasonably. That's not a dead-end per se.
okay, my point is also that using yet another tool that is neither
integrated in my shell nor in my editor sucks. I use the shell to use
$SCM, and to perform tests of my work, so it's in my workflow. I use the
editor (well do I need to tell why ? :P), I just don't want to use a
browser where the two previous should be enough.
> > You can like central web UIs, your choice. And I suppose if grit works
> >well, there will be one at some point.
>
> Bugtrackers are communication tools between developers and users. In
> many spaces, they are _teaching tools_, teaching the users about info
> developers need. That's why BTSs have explicit fields asking for
> important variables like OS, Arch, and version you are reporting a bug
> against. That's also why the BTS gains a lot from being web-based:
> extreme portability, reachability, zero-install for users.
Because it's git-based does not implies there won't be a web UI. And
it's not because there is a lot of options to the underlying process
that you need to show them all to the user.
My experience is also that people never fill informations about OS,
Arch, version properly, because it's tiredsome. debbugs (through
reportbug) approach is excellent: assuming that the user reports the
error from the machine where he experienced it and taking all the
information automatically. _here_ is how it should work for the user,
e.g.: “please download and run that script, and paste the results in your
bug report pretty please ?”
> > yeah, that is what bugtrackers already do. Though, that's of no use
> >for release managers. What is useful is what people call "milestones" in
> >trac e.g., meaning a set of bugs that has been flagged as needing to be
> >fixed. And what a release manager need is a tool to deal with this set
> >of bugs as a whole.
>
> Hmmm. Most BTSs have milestones, and the integration of the above with
> milestones is useful for release managers.
How many of those bts'es help the RMs to know if their
soon-to-be-stable branch fits the milestone ? milestones in any BTS I
know are global "yes the fix exists, in this revision (and this
information is not always here)". Sorry but it's worthless.
> How about the _rest_ of the BTS-using populace?
Okay, who else uses a BTS ? developpers, as I'm a developper, I'll
write a tool that pleases me. Let's say developpers are taken care of.
Users ? For a user, what should be made easy is reporting, and
interacting with whoever is dealing with the bug on the other end.
Advanced users will want to be able to track discussion about some bugs
they are interested into (meaning that it must be a way to crawl the
bugs database).
So let's take the three points:
* reporting: the tools to make reporting fast, efficient, _and_
useful to the developpers - many many many bug reports suck, hard -
are very often project dependant: a project in python e.g. won't
care about the architecture usually (hence forcing it is stupid) but
will probably mind the OS, python version, distribution, ... Another
project in C will mind the architecture, but is knowingly working
only on Linux so won't mind the OS, but would maybe mind the kernel
version. etc...
=> What can I do ? provide a way to deal with some kind of
property/values that can be customizeable at the BTS side and
show some examples of reporting scripts. ttbomk only debbugs and
reportbug knows how to do that. It does not prevents bad bug
reports at all, but it makes many that would have been bad almost
good, at least usable.
* simplicity to follow up: there isn't 12987123 solutions here. mail,
mail, mail, mail. A BTS should be able to track mail discussions one
way or another. For pure-web BTS, there is still mail alerts to say
"hey $someone has said $sth on your bug $bug". So the user already
is in his MUA when he receives that, well, "reply"-button is the
shortest way to answer, make it possible.
* crawling the database: that one should not be done by the BTS. Every
BTS on the planet doing that is wrong. There is plenty of good
search engines (xapian, clucene, ...) just adapt one. And the most
simple your storage backend is, the simplest it will be.
What I'm saying is that maybe we don't call BTS the same object. To me
a BTS is a "thing" able to deal with large amounts of bugs in an
efficient way, and is able to deal with some basic things like bug
statuses, and some kind of queries to the database (not the full text
search ones). Then you have the Upper Layer Tools: guis, tracking
scripts, every bling you need. Note that Git is exactly designed this
way: low level tools, and then tools like git-mergetool, gitk, ... that
don't use _any_ git internal, but rather only use the underlying
commands. I want to build the core functions to deal with a BTS, so that
everybody is able to turn this into the BTS workflow he needs.
> > That's the same argument that Linus has against per-file tracking.
> >Also atm when you e.g. backport a patch that fixes this or this bug,
> >you're no BTS helps you tagging the bug as fixed in that branch as well.
> >Not to mention that BTS I know do not make any use of the commits DAG.
> >And for a very good reason, there is no real DAG in many existing tools
> >(svn, cvs, ...).
>
> Making the BTS DAG-aware is overkill.
Why ?
> The BTS can ask for every update on every branch "what commits does it
> bring into branch X?" and that's all you need. If you backport a patch
> and mention the original patch SHA1 the BTS can do its job.
or the BTS can do it for you and you would not need to feed him with
the sha directly.
> And all of that can be done SCM-agnostic - except for the regex to
> spot a commitid.
Sure, there is projects doing that out there, I believe they are
wrong. Portability is important. I mean, when you write a tool, that has
a purpose, yes you must try to make it available everywhere. That's why
there are people trying hard to make git build and work on windows.
But when you write a tool to help _you_ work, there is now need to
make it work for every workflow in the planet, because that would mean
align yourself to the lowest common denominator of the workflows you can
work with. That's not an acceptable trade-off. Why would I have to
support cvs or svn ? I don't use them. I just don't care about them.
Wherever place I'll work in, I'll use git. Sorry but full genericity
(because it's what we are talking about, not portability) is an
impediment, not an enabler.
> > You're a lucky guy. All bug trackers I've used suck a way or another,
> >that impedes my workflow a lot. Let's cite a couple:
>
> Ok - but BTSs are a compromise, something that must work for users,
> and developers.
I don't think it needs to be a compromise.
> >> Bugtrackers are co-owned by developers, users and (where they exist)
> >> project managers.
> >
> > That's exactly why distributed rock. Because everyone could _really_
> >own _his_ bugtracker. This solves the same range of ACLish issues git
> >solves with respect to the code.
>
> Don't think I've seen politics over who owns the bugtracker ;-) but I
> _have_ seen politics over specific bugs (developers close unfixed
> bugs, flamefests ensue). I guess with a DBTS everyone can have their
> own status for the bug... but does that help the user? Or the
> developer?
That one is easy. Indeed, the big politics in bugtrackers are ...
severity-ping-pong, or close-wars. Good example of that is btw:
http://sourceware.org/bugzilla/show_bug.cgi?id=4509.
Okay, what would we gain in a DBTS: developer would still be (sorry)
a perfect asshole with the user. That is a thing we cannot fix. Though,
the release manager will probably disagree with him. So this bug that
_he_ considers non existant will be closed in his repository, but still
remain open in the main one. Meaning that if another developer steps up,
he'll see this issue is not fixed. Else nobody will have any chance to
step up, ever.
The reverse works equally well: if RM decides bugs have to be closed,
developer is able to reopen the bugs (or not merge) in his repository,
so that he can have a chance to fix them.
Yes there is politics in BTSes, and yes it can help.
> > > And at git's end we can get the smooth integration using/abusing
> > > that loose coupling strategy. So if git-log/gitk/qgit grow some
> > > hooks that can be used to perform a lookup... I can think of a
> > > perl script that gets events for each SHA1 that git-rev-list
> > > produces and returns one bug number, url and title (or more than
> > > one) that then git-log / gitk / qgit / annotate can use to further
> > > "decorate" the commit info in a similar style to what gitk is
> > > doing now with head names in each commit.
> > >
> > > Would that fit your vision of a nicely integrated tracker?
> >
> > Honestly ? No, because that would be horribly slow (but I'd love to be
> >proven wrong).
>
> What part would be slow?
The perl scripts. It would perceptibly slow down commits. And I don't
want that now that I finally have a fast SCM. I just don't want to turn
git into bzr.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git-svn set-tree bug
From: Joakim Tjernlund @ 2007-06-11 8:52 UTC (permalink / raw)
To: Steven Grimm; +Cc: Eric Wong, git
In-Reply-To: <466CF2A0.4080604@midwinter.com>
On Sun, 2007-06-10 at 23:58 -0700, Steven Grimm wrote:
> Eric Wong wrote:
> > Doable? Yes. However, I think using grafts is quite hackish and
> > unreliable[1]. I'd rather just have users using set-tree if
> > they want to deal with non-linear history in the first place.
> >
>
> Agreed about grafts being hackish and unreliable. But they were what I
> had to work with, given that I know little enough about git-svn's
> internals to be able to implement Junio's more robust idea.
>
> IMO set-tree is not much of an option. In my environment it is
> unacceptable for there to be any possibility of accidentally and
> silently overwriting some other change that just happened to hit the svn
> repo right before I committed my change, which (unless it has changed
> since I last tried it) set-tree will happily do. I can get away with
> doing that maybe once before my company's release manager will, quite
> justifiably, require me to stop using git and switch back to the
> standard svn client.
>
> > I'd personally avoid any sort of non-linear history when interacting
> > with SVN repositories, however.
> >
>
> Which is a shame since git loses a lot of its utility without nonlinear
> history. For example, the script I posted uses git to do merges between
> svn branches. It works wonderfully even if, as you and Junio point out,
> its use of grafts to record svn merges scales poorly and is potentially
> susceptible to corruption. Thanks to the ability to record the fact that
> my merges between svn branches were actually merges, my git clone has a
> more complete picture of what's in my svn repository than the svn
> repository itself does!
Exactly, I too think that this is a much needed feature for git-svn.
I have also noted that this modified(added a git svn dcommit) script
works:
rm -rf mygitsvn
rm -rf mysvnrepo
rm -rf mysvnwork
mkdir mysvnrepo
cd mysvnrepo
svnadmin create .
cd ..
svn checkout file:///$PWD/mysvnrepo mysvnwork
mkdir -p mysvnwork/trunk
cd mysvnwork/
cat << EOF > trunk/README
#
# (C) Copyright 2000 - 2005
# Wolfgang Denk, DENX Software Engineering, wd@denx.de.
#
# See file CREDITS for list of people who contributed to this
# project.
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License as
# published by the Free Software Foundation; either version 2 of
# the License, or (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
# MA 02111-1307 USA
#
EOF
svn add trunk
svn ci -m "first commit" trunk
cd ..
git-svn clone file:///$PWD/mysvnrepo -t tags -T trunk -b branches mygitsvn
cd mygitsvn
git checkout --track -b svn remotes/trunk
git checkout -b merge
echo new file > new_file
git add new_file
git commit -a -m "New file"
echo hello >> README
git commit -a -m "hello"
echo add some stuff >> new_file
git commit -a -m "add some stuff"
git checkout svn
mv -f README tmp
echo friend > README
cat tmp >> README
git commit -a -m "friend"
git svn dcommit
git pull . merge
git svn dcommit
but, as expected, then merge commit is still gone.
^ permalink raw reply
* [PATCH] Remove an odd "available" from git-mergetool message regarding no merge tools
From: Alex Riesen @ 2007-06-11 9:01 UTC (permalink / raw)
To: Git Mailing List; +Cc: Theodore Ts'o, Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 130 bytes --]
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
git-mergetool.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
[-- Attachment #2: 0001-Remove-an-odd-available-from-git-mergetool-message-r.txt --]
[-- Type: text/plain, Size: 763 bytes --]
From caf5b63a17003efa53729b71ae314197438acfe8 Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Mon, 11 Jun 2007 10:54:23 +0200
Subject: [PATCH] Remove an odd "available" from git-mergetool message regarding no merge tools
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
git-mergetool.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 7b66309..3e49168 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -339,7 +339,7 @@ if test -z "$merge_tool" ; then
fi
done
if test -z "$merge_tool" ; then
- echo "No available merge resolution programs available."
+ echo "No merge resolution programs available."
exit 1
fi
fi
--
1.5.2.1.878.gef42
^ permalink raw reply related
* Does anyone have any benchmarks against CVS?
From: linux @ 2007-06-11 9:04 UTC (permalink / raw)
To: git; +Cc: linux
It seems to be common knowledge that git is a heck of a lot faster than
CVS at most operations, but I'd like to do a little evangelizing and
I can't seem to find a benchmark to support that claim.
Am I just blind?
I could find a code base and measure myself, but perhaps someone who's
been hacking on CVS converters already has a reasonable code base
in both forms that could be used for testing?
^ permalink raw reply
* Re: [PATCH] Avoid double-slash in path names that depend on $(sharedir).
From: Johannes Sixt @ 2007-06-11 9:10 UTC (permalink / raw)
To: git
In-Reply-To: <7v645usy4c.fsf@assigned-by-dhcp.pobox.com>
Junio C Hamano wrote:
>
> Johannes Sixt <johannes.sixt@telecom.at> writes:
>
> > diff --git a/Makefile b/Makefile
> > index af84af9..c23031c 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -144,7 +144,7 @@ STRIP ?= strip
> > prefix = $(HOME)
> > bindir = $(prefix)/bin
> > gitexecdir = $(bindir)
> > -sharedir = $(prefix)/share/
> > +sharedir = $(prefix)/share
> > template_dir = $(sharedir)/git-core/templates/
> > ifeq ($(prefix),/usr)
> > sysconfdir = /etc
>
> This suggests that we would also want to drop the trailing slash
> from template_dir, doesn't it?
>
> I took a brief look at builtin-init-db.c but it seems that the
> code is safe with or without the trailing slash there.
It amounts to this on top of my other patch. It's not worth it,
if you ask me.
--- 8< ---
From: Johannes Sixt <johannes.sixt@telecom.at>
Subject: [PATCH] Remove trailing slash from $(template_dir).
This is just a consistency cleanup. sharedir is defined a line above
template_dir and doesn't have the trailing slash, either.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
Makefile | 2 +-
builtin-init-db.c | 2 +-
templates/Makefile | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index c23031c..7091a4b 100644
--- a/Makefile
+++ b/Makefile
@@ -145,7 +145,7 @@ prefix = $(HOME)
bindir = $(prefix)/bin
gitexecdir = $(bindir)
sharedir = $(prefix)/share
-template_dir = $(sharedir)/git-core/templates/
+template_dir = $(sharedir)/git-core/templates
ifeq ($(prefix),/usr)
sysconfdir = /etc
else
diff --git a/builtin-init-db.c b/builtin-init-db.c
index 4df9fd0..0be2d2e 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -7,7 +7,7 @@
#include "builtin.h"
#ifndef DEFAULT_GIT_TEMPLATE_DIR
-#define DEFAULT_GIT_TEMPLATE_DIR "/usr/share/git-core/templates/"
+#define DEFAULT_GIT_TEMPLATE_DIR "/usr/share/git-core/templates"
#endif
#ifdef NO_TRUSTABLE_FILEMODE
diff --git a/templates/Makefile b/templates/Makefile
index b8352e7..aaa39d3 100644
--- a/templates/Makefile
+++ b/templates/Makefile
@@ -7,7 +7,7 @@ endif
INSTALL ?= install
TAR ?= tar
prefix ?= $(HOME)
-template_dir ?= $(prefix)/share/git-core/templates/
+template_dir ?= $(prefix)/share/git-core/templates
# DESTDIR=
# Shell quote (do not use $(call) to accommodate ancient setups);
--
1.5.2.1.176.g7084-dirty
^ permalink raw reply related
* Re: Does anyone have any benchmarks against CVS?
From: David Kastrup @ 2007-06-11 9:26 UTC (permalink / raw)
To: git
In-Reply-To: <20070611090451.26209.qmail@science.horizon.com>
linux@horizon.com writes:
> It seems to be common knowledge that git is a heck of a lot faster than
> CVS at most operations, but I'd like to do a little evangelizing and
> I can't seem to find a benchmark to support that claim.
>
> Am I just blind?
>
> I could find a code base and measure myself, but perhaps someone who's
> been hacking on CVS converters already has a reasonable code base
> in both forms that could be used for testing?
CVS and git do completely different things (which is one of the main
points of git). git tends to do its own things pretty fast, CVS tends
to its things more leasurely and with higher network impact.
Benchmarking is not really useful since both systems do different
things.
--
David Kastrup
^ permalink raw reply
* Re: Does anyone have any benchmarks against CVS?
From: Johannes Schindelin @ 2007-06-11 9:47 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86odjmg7ty.fsf@lola.quinscape.zz>
Hi,
On Mon, 11 Jun 2007, David Kastrup wrote:
> linux@horizon.com writes:
>
> > It seems to be common knowledge that git is a heck of a lot faster than
> > CVS at most operations, but I'd like to do a little evangelizing and
> > I can't seem to find a benchmark to support that claim.
> >
> > Am I just blind?
> >
> > I could find a code base and measure myself, but perhaps someone who's
> > been hacking on CVS converters already has a reasonable code base
> > in both forms that could be used for testing?
>
> CVS and git do completely different things (which is one of the main
> points of git). git tends to do its own things pretty fast, CVS tends
> to its things more leasurely and with higher network impact.
> Benchmarking is not really useful since both systems do different
> things.
I disagree. For quite some time (pre 2005), I used CVS to track some
directories, where the "server" was a directory on the same machine.
This is exactly the same workflow as I do now with Git. So I will try to
come up with a sensible test this afternoon (If I can get at a copy
of QEmu's cvsroot, I'll try that) where I compare CVS and Git, both of
which have the repository already set up.
Okay, it is not completely fair, since Git _will_ blow CVS away, but
linux-at-horizon asked for it.
Sidenote: It was always a hassle to set up the initial version with CVS.
Funnily enough, the "CVS done right" SCM has the _same_ issue.
I even presented Git to an svn user last week (not his fault, really, he
was more than willing to try Git), and he was surprised that you could
_continue_ working in the _same_ working directory as before, after
git-init...
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] git integrated bugtracking
From: Martin Langhoff @ 2007-06-11 10:00 UTC (permalink / raw)
To: Martin Langhoff, git
In-Reply-To: <20070611084533.GA24327@artemis.intersec.eu>
On 6/11/07, Pierre Habouzit <madcoder@debian.org> wrote:
> That one is easy. Indeed, the big politics in bugtrackers are ...
> severity-ping-pong, or close-wars. Good example of that is btw:
> http://sourceware.org/bugzilla/show_bug.cgi?id=4509.
>
> Okay, what would we gain in a DBTS: developer would still be (sorry)
> a perfect asshole with the user. That is a thing we cannot fix. Though,
> the release manager will probably disagree with him. So this bug that
> _he_ considers non existant will be closed in his repository, but still
> remain open in the main one. Meaning that if another developer steps up,
> he'll see this issue is not fixed. Else nobody will have any chance to
> step up, ever.
I've seen all those bugtracker-wars. But they never block a developer
or fellow user from saying --hey, here's a patch. And with a DSCM,
that clears things up quite quickly.
I don't understand how "Else nobody will have any chance to step up, ever."
> > > Honestly ? No, because that would be horribly slow (but I'd love to be
> > >proven wrong).
> >
> > What part would be slow?
>
> The perl scripts. It would perceptibly slow down commits. And I don't
> want that now that I finally have a fast SCM. I just don't want to turn
> git into bzr.
The model I was thinking of was of _not_ slowing down your commits ;-) but
* Stick to a mostly centralised BTS that tracks a limited set of repos
* When you push to the public repo, the BTS updates its bug status
* on git-pull, update a (fast!) local cache of BTS data
* on gitk use a similar technique to the "follows" line shown for
each commit to display bug info "inline"
cheers,
martin
^ permalink raw reply
* Re: [PATCH] Add --no-reuse-delta option to git-gc
From: Johannes Schindelin @ 2007-06-11 10:20 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Sam Vilain, Steven Grimm, Shawn O. Pearce, Junio C Hamano,
Daniel Barkalow, Theodore Ts'o, Git Mailing List
In-Reply-To: <alpine.LFD.0.99.0706102144080.12885@xanadu.home>
Hi,
On Sun, 10 Jun 2007, Nicolas Pitre wrote:
> On Sun, 10 Jun 2007, Sam Vilain wrote:
>
> > Anyway it's a free world so be my guest to implement it, I guess if
> > this was selectable it would only be a minor annoyance waiting a bit
> > longer pulling from from some repositories, and it would be
> > interesting to see if it did make a big difference with pack file
> > sizes.
>
> It won't happen for a simple reason: to be backward compatible with
> older GIT clients. If you have your repo compressed with bzip2 and an
> old client pulls it then the server would have to decompress and
> recompress everything with gzip. If instead your repo remains with gzip
> and a new client asks for bzip2 then you have to recompress as well
> (slow). So in practice it is best to remain with a single compression
> method.
With the extension mechanism we have in place, the client can send what
kind of compression it supports, and the server can actually refuse to
send anything if it does not want to recompress.
What I am trying to say: you do not necessarily have to allow every client
to access that particular repository. I agree that mixed-compression repos
are evil, but nothing stands in the way of a flag allowing (or
disallowing) recompression in a different format when fetching.
So if you should decide someday to track data with Git (remember: Generic
Information Tracker, not just source code), that is particularly unfit for
compression with gzip, but that you _need_ to store in a different
compressed manner, you can set up a repository which will _only_ _ever_
use that compression.
Of course, you'd need to prepare Git for that, but I could imagine
something like a music library, which stores everything as ogg encoded
snippets. It might even use some perception-based hash on small chunks of
the music, and store the music as tree objects, which concatenate the
small chunks. I might even try to do this for fun, some day in the distant
future.
It's a wild world,
Dscho
^ 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