* repo-config needs a prefix.
From: Robert Shearman @ 2006-08-10 9:36 UTC (permalink / raw)
To: Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 321 bytes --]
This fixes the message received when invoking certain commands from
outside of a git tree, so e.g. instead of receiving this:
/home/rob/bin/git-fetch: line 89: /FETCH_HEAD: Permission denied
We get this again:
fatal: Not a git repository: '.git'
---
git.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
[-- Attachment #2: c0aa527060f6ba202986564731e7277f11f31639.diff --]
[-- Type: text/x-patch, Size: 382 bytes --]
diff --git a/git.c b/git.c
index 18ba14a..f9c76a1 100644
--- a/git.c
+++ b/git.c
@@ -264,7 +264,7 @@ static void handle_internal_command(int
{ "prune", cmd_prune, NEEDS_PREFIX },
{ "mv", cmd_mv, NEEDS_PREFIX },
{ "prune-packed", cmd_prune_packed, NEEDS_PREFIX },
- { "repo-config", cmd_repo_config },
+ { "repo-config", cmd_repo_config, NEEDS_PREFIX },
};
int i;
^ permalink raw reply related
* Re: diff machinery cleanup
From: Junio C Hamano @ 2006-08-10 9:36 UTC (permalink / raw)
To: git
In-Reply-To: <20060810082455.GA30739@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> It seems clear that there's some global magic touched by the first diff
> that impacts the second. I have to give up on finding it for tonight,
> but I'm hoping somebody who knows more about the code will find it
> obvious (or can tell me that I'm doing something else horribly wrong in
> the above, or that these functions were never intended to be called
> within the same program).
In general, run_diff_X are _not_ designed to run twice.
The run_diff_index() function munges the index while doing its
work (e.g. mark_merge_entries() hoists unmerged entries to stage
3 -- and worse yet creating duplicate entries for the same path
at stage 3; read_tree() reads the entries into stage 1 so that
it can be compared in-index with stage 0 entries). The other
function, run_diff_files() have the same assumption but does not
touch index if I recall correctly.
If you are working in "next" branch where Johannes's merge-recur
work introduced discard_cache(), you could fake this somehow
stashing away a copy of the original index, and once you are
done with run_diff_index(), clean the slate by calling
discard_cache() once you are done, and swap the original index
in before running run_diff_files().
To solve this cleanly without doing the index munging hack, you
would (actually, I would) need to have a new path walker that
walks index, tree and working tree in parallel, which I was
working on in the git-status/git-commit rewrite I started and
discarded a few days ago.
^ permalink raw reply
* Re: What's in git.git, and announcing GIT 1.4.2-rc4
From: Johannes Schindelin @ 2006-08-10 8:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk65hvw92.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 10 Aug 2006, Junio C Hamano wrote:
> I tried it [--color-words] on this:
>
> diff --git a/builtin-apply.c b/builtin-apply.c
> index c159873..be2c715 100644
> --- a/builtin-apply.c
> +++ b/builtin-apply.c
> @@ -1700,10 +1700,8 @@ static int apply_data(struct patch *patc
> return -1;
>
> /* NUL terminate the result */
> - if (desc.alloc <= desc.size) {
> + if (desc.alloc <= desc.size)
> desc.buffer = xrealloc(desc.buffer, desc.size + 1);
> - desc.alloc++;
> - }
> desc.buffer[desc.size] = 0;
>
> patch->result = desc.buffer;
>
> which shows something like:
>
> diff --git a/builtin-apply.c b/builtin-apply.c
> index c159873..be2c715 100644
> --- a/builtin-apply.c
> +++ b/builtin-apply.c
> @@ -1700,10 +1700,8 @@ static int apply_data(struct patch *patc
> return -1;
>
> /* NUL terminate the result */
> if (desc.alloc <= desc.size)
> {
> desc.buffer = xrealloc(desc.buffer, desc.size + 1);
> desc.alloc++;
> }
> desc.buffer[desc.size] = 0;
>
> patch->result = desc.buffer;
>
> where "desc.alloc++;" and next lines and the opening brace after
> if() are red. Why does that red opening brace have to come at
> the beginning of line, I wonder...
It is an implementation detail: to determine the differing words, I turn
all whitespace into newlines in that particular hunk, and then run another
diff (nested diff run!). So, the space in --- and the newline in +++
compare equal. Since wI am mostly interested in the _new_ (gree) version,
the newline is printed, not the space.
Hmmm. I have to think about it.
Ciao,
Dscho
^ permalink raw reply
* diff machinery cleanup
From: Jeff King @ 2006-08-10 8:24 UTC (permalink / raw)
To: git
I'm trying to run two different 'diffs' in the same C program, and the
results of the second diff depend on whether or not the first diff has
run. A minimal case is below. When show_updated() is run, show_changed()
results in all files listed as "unmerged". If show_updated() is
commented out, the output for show_changed() is as expected.
-- >8 --
#include "cache.h"
#include "object.h"
#include "commit.h"
#include "diff.h"
#include "revision.h"
void show_updated() {
struct rev_info rev;
const char *argv[] = { NULL, "HEAD", NULL };
init_revisions(&rev, NULL);
setup_revisions(2, argv, &rev, NULL);
rev.diffopt.output_format = DIFF_FORMAT_NAME_STATUS;
run_diff_index(&rev, 1);
}
void show_changed() {
struct rev_info rev;
const char *argv[] = { NULL, NULL };
init_revisions(&rev, NULL);
setup_revisions(1, argv, &rev, NULL);
rev.diffopt.output_format = DIFF_FORMAT_NAME_STATUS;
run_diff_files(&rev, 0);
}
int main(int argc, char **argv) {
printf("updated:\n");
show_updated();
printf("changed:\n");
show_changed();
return 0;
}
-- >8 --
It seems clear that there's some global magic touched by the first diff
that impacts the second. I have to give up on finding it for tonight,
but I'm hoping somebody who knows more about the code will find it
obvious (or can tell me that I'm doing something else horribly wrong in
the above, or that these functions were never intended to be called
within the same program).
-Peff
^ permalink raw reply
* Re: [PATCH] Workaround for strange cmp bug
From: Johannes Schindelin @ 2006-08-10 8:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0608091309590.1800@wbgn013.biozentrum.uni-wuerzburg.de>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 778 bytes --]
Hi,
On Wed, 9 Aug 2006, Johannes Schindelin wrote:
> On Wed, 9 Aug 2006, Junio C Hamano wrote:
>
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> > > The cmp(1) (cmp (GNU diffutils) 2.8.7) distributed with openSUSE
> > > 10.1 has a subtle "shortcoming":
>
> Okay, I will try to fix the distribution. I only thought it was worthwhile
> spreading the workaround for other poor souls.
Got it. The problem is that diffutils-2.8.7-15 and -18 (which seem to be
the same...) have cherry-picked a "fix" from CVS (cmp-eof-dev-null.diff),
which is wrong. It was fixed in diffutils CVS, and I submitted a bug
report in openSUSEÂ's bugzilla.
So, look out for diffutils-2.8.7-15 on openSUSE (although it only breaks
the _tests_, not git itself!).
Ciao,
Dscho
^ permalink raw reply
* Re: What's in git.git, and announcing GIT 1.4.2-rc4
From: Junio C Hamano @ 2006-08-10 8:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0608100957050.13885@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Besides, I really use it often -- you should try it! Call me blind, but
> very often I cannot spot the differences (in the unified diff) when they
> are minor, especially when there was just a typo in the documentation. You
> could now say that I should not care about it, then, but if _I_ made the
> mistake, I want to learn from it.
I tried it on this:
diff --git a/builtin-apply.c b/builtin-apply.c
index c159873..be2c715 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -1700,10 +1700,8 @@ static int apply_data(struct patch *patc
return -1;
/* NUL terminate the result */
- if (desc.alloc <= desc.size) {
+ if (desc.alloc <= desc.size)
desc.buffer = xrealloc(desc.buffer, desc.size + 1);
- desc.alloc++;
- }
desc.buffer[desc.size] = 0;
patch->result = desc.buffer;
which shows something like:
diff --git a/builtin-apply.c b/builtin-apply.c
index c159873..be2c715 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -1700,10 +1700,8 @@ static int apply_data(struct patch *patc
return -1;
/* NUL terminate the result */
if (desc.alloc <= desc.size)
{
desc.buffer = xrealloc(desc.buffer, desc.size + 1);
desc.alloc++;
}
desc.buffer[desc.size] = 0;
patch->result = desc.buffer;
where "desc.alloc++;" and next lines and the opening brace after
if() are red. Why does that red opening brace have to come at
the beginning of line, I wonder...
^ permalink raw reply related
* Re: What's in git.git, and announcing GIT 1.4.2-rc4
From: Junio C Hamano @ 2006-08-10 8:10 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0608100957050.13885@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> - pack-objects can copy a non-delta representation of a object
>> with the new style header straight into packs.
>>...
>> * Hopefully not too long after 1.4.2:
>> - New style loose objects, which use the same header format as
>> in-pack objects, can be copied straight into packs when not
>> deltified. I am hoping that we can make the new-style loose
>> objects the default in 10 to 12 weeks to give everybody time
>> to update to 1.4 series.
>
> These are the same, no?
Yeah; I meant to say that we need to wait a while before making
the new style loose object the default, since people with older
git would not be able to use them.
^ permalink raw reply
* Re: What's in git.git, and announcing GIT 1.4.2-rc4
From: Johannes Schindelin @ 2006-08-10 8:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, linux-kernel
In-Reply-To: <7vy7txxts5.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 9 Aug 2006, Junio C Hamano wrote:
> * The 'next' branch, in addition, has these.
>
> = To graduate immediately after 1.4.2 happens:
>
> [...]
>
> - pack-objects can copy a non-delta representation of a object
> with the new style header straight into packs.
>
> [...]
>
> * Hopefully not too long after 1.4.2:
>
> [...]
>
> - New style loose objects, which use the same header format as
> in-pack objects, can be copied straight into packs when not
> deltified. I am hoping that we can make the new-style loose
> objects the default in 10 to 12 weeks to give everybody time
> to update to 1.4 series.
These are the same, no?
> * The 'pu' branch, in addition, has these.
>
> [...]
>
> - Johannes has a new diff option --color-words to use color to
> squash word differences into single line output.
>
> I do not feel much need for this stuff, and the change is
> rather intrusive, so I am tempted to drop it.
I beg to differ on the "intrusive": except for needed structs and
functions, which are totally orthogonal with the rest of git, it only
touches fn_out_consume(), builtin_diff() and in an obvious way,
diff_opt_parse() and struct diff_options.
So the real impact is pretty low and well contained.
Besides, I really use it often -- you should try it! Call me blind, but
very often I cannot spot the differences (in the unified diff) when they
are minor, especially when there was just a typo in the documentation. You
could now say that I should not care about it, then, but if _I_ made the
mistake, I want to learn from it.
Of course, if you really hate what it does, I will happily carry it in my
personal repository; I _need_ it.
Ciao,
Dscho
^ permalink raw reply
* Re: merge-recur status
From: Junio C Hamano @ 2006-08-10 8:03 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0608100949250.13885@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> P.S.: Pavel, thanks for the "A dedicated programmer with good C and Python
> skills could rewrite git-merge-recursive.py in C in 2 days, I believe. Add
> a few days of bug fixing, of course." underestimation. I do not know if I
> had started fiddling with it if I had known how involved it is.
It indeed _is_ involved, and not just C vs Python but the latter
being able to rely on multiple processes without worrying about
state clean-ups.
I am quite impressed by and happy with the merge-recur work.
^ permalink raw reply
* Re: What's in git.git, and announcing GIT 1.4.2-rc4
From: Junio C Hamano @ 2006-08-10 7:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0608100945430.13885@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> While in this particular case, desc.alloc cannot be smaller than desc.size
> (and therefore the condition in the if() is misleading), it might be
> better to write "desc.alloc = desc.size + 1;" for others to understand...
We overallocate desc.alloc in apply_one_fragment for growth, so
that if() is needed, but after this part of the code we discard
the desc hence the increment is not needed ;-).
diff --git a/builtin-apply.c b/builtin-apply.c
index c159873..be2c715 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -1700,10 +1700,8 @@ static int apply_data(struct patch *patc
return -1;
/* NUL terminate the result */
- if (desc.alloc <= desc.size) {
+ if (desc.alloc <= desc.size)
desc.buffer = xrealloc(desc.buffer, desc.size + 1);
- desc.alloc++;
- }
desc.buffer[desc.size] = 0;
patch->result = desc.buffer;
^ permalink raw reply related
* Re: qgit feature idea: multiple Patch tabs
From: Marco Costalba @ 2006-08-10 7:57 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eb9ub9$u5m$1@sea.gmane.org>
On 8/8/06, Jakub Narebski <jnareb@gmail.com> wrote:
> It would be nice to be able to have multiple "Patch" tabs,
> e.g. by using "Open in new tab"/Ctrl-Click, instead of default
> being only one Patch tab, and new patch replacing the old.
>
I'm coming back after my holidays, and I'm trying to catch up with the
list....it will take some time. It seems I'm the only one to go for
holiday in this period ;-)
A couple of weeks ago I pushed a patch to support multiple "File" tabs.
Could your suggestion of multi "patch" tabs follow the same
implementation line?
Or do you think we could do soemthing better with multi "Patch" tabs
(and back port to
multi "File" tabs patch)?
Thanks
Marco
^ permalink raw reply
* Re: [PATCH/RFC] gitweb: Great subroutines renaming
From: Jakub Narebski @ 2006-08-10 7:57 UTC (permalink / raw)
To: git
In-Reply-To: <7v3bc5397r.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Subroutines in gitweb: <current name> => <proposed rename>.
>
> If it is not too much trouble, having a few line summary of what
> each of the sub does would greatly help judging if the names are
> appropriate.
Subroutines name guideline, revised:
* git_ prefix for subroutines related to git commands,
or to gitweb actions
* git_get_ prefix for inner subroutines calling git command
and returning some output
* parse_ prefix for subroutines parsing some text, or reading and
parsing some text into hash or list
* format_ prefix for subroutines formatting/post-processing some
HTML/text fragment
* _get_ infix for subroutines which return result
* _print_ infix for subroutines which print fragment of output
* _body suffix for subroutines which outputs main part (body)
of related action
* _nav suffix for subroutines related to navigation bars
* _div suffix for subroutines returning or printing div element
Current gitweb subroutines, with proposed renames, and short summary.
* validate_input => is_valid_ref, is_valid_path (?)
universal (too universal) parameter validation
* esc_param
quote unsafe chars in link parameters
* esc_html
escape to HTML, replace invalid uft8 characters
* unquote
unquote filenames quoted and escaped by git
* untabify
convert tabs (8 spaces wide tabstops) to spaces
* chop_str
shorten string, removing characters entities as whole
* age_class
CSS class for given age value (in seconds)
* age_string
convert age in seconds to "nn units ago" string
* mode_str
convert file mode in octal to symbolic file mode string
* file_type
convert file mode in octal to file type string (directory, symlink,
file, unknown)
* format_log_line_html
format line of commit message or tag comment, hyperlinking commitids
(perhaps in the future comittags, e.g. BUG(nn) support)
* git_get_referencing => format_mark_referencing (???)
return HTML fragment generating marker of refs pointing to given object
* git_read_head => git_get_head_hash
get HEAD ref of given project as hash
* git_read_hash => git_get_hash_by_ref
get hash of given ref (e.g. refs/heads/next)
* git_get_hash_by_path
get hash of given path at given ref
* git_get_type
get type of given object (by hash)
* git_get_project_config
return value of given variable in gitweb section
* git_get_project_config_bool
return value of given variable in gitweb section, as boolean
* git_read_description => git_get_project_description
* git_read_projects => git_get_projects_list
return list of projects (path, owner)
* read_info_ref => git_get_references
return hashref of refs pointing to object given by hash key
* git_read_refs => git_get_refs_list
list of hashrefs of parsed ref info
(parsing to be separated into parse_ref subroutine)
* date_str => parse_date
given epoch and (optionally) timezone return parsed date as hash
* git_read_tag => parse_tag
given tag_id, return parsed tag as Perl hash
* git_read_commit => parse_commit
given commit_id (and optionally commit_text to reuse), return parsed
commit
* get_file_owner
return owner of given file, according to user id and gcos field
* mimetype_guess_file => ???
reads and parses mime.types like file, return mimetype of given filename
* mimetype_guess => (to be incorporated in blob_mimetype)
try $mimetypes_file, or /etc/mime.types
* git_blob_plain_mimetype => blob_mimetype
return mimetype of given (by file descriptor and filename) blob
* git_get_paging_nav => ???
return HTML fragment generating "HEAD * prev * next" page navigation
* git_page_nav => git_print_page_nav
print "action" navigation bar, optionally with pager or formats below
* git_header_div => git_print_header_div
prints div element of class "header" just below navigation bar
* git_print_page_path
print div element of class "page_path" with current path
* git_diff_print => (to be made obsolete)
print diff between two files, using /usr/bin/diff and temporary files
* git_header_html
prints HTML header of gitweb output
* git_footer_html
prints HTML footer of gitweb output
* die_error
prints gitweb error page
Subroutines printing table with shortlog, tags, heads respectively
* git_shortlog_body
* git_tags_body
* git_heads_body
Action subroutines
* git_project_list
* git_summary
* git_tag
* git_blame2 => git_blame (?)
* git_blame => git_annotate (?)
* git_tags
* git_heads
* git_blob_plain
* git_blob
* git_tree
* git_log
* git_commit
* git_blobdiff
* git_blobdiff_plain
* git_commitdiff
* git_commitdiff_plain
* git_history
* git_search
* git_shortlog
* git_rss
* git_opml
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: merge-recur status
From: Johannes Schindelin @ 2006-08-10 7:54 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: git, junkio
In-Reply-To: <20060810062914.GA5192@c165.ib.student.liu.se>
Hi,
On Thu, 10 Aug 2006, Fredrik Kuivinen wrote:
> I just want to say that you have made a great work with porting
> merge-recursive to C!
Thank you! I was feeling bad a little, because you were the creator of it,
and I just bastardized it. But given my plans with MinGW, I needed to get
rid of Python (it exists on Python, but has all kinds of path conversion
problems).
> I ran merge-recur through a couple of test merges that I used to test
> merge-recursive with. It is mostly merge cases people have posted to
> the mailing list, but also some home made ones. For some of them I get
> segmentation faults, see the log below. The first three come from
> Linus kernel tree. The last one,
> 44583d380d189095fa959ec8ba87f0cb6deb15f5, is from Thomas Gleixner's
> historical Linux kernel repository. I haven't seen "fatal: fatal:
> cache changed flush_cache();" before...
>
> Let me know if you can't reproduce some them.
I could reproduce already yesterday ;-) The patch "merge-recur: do not die
unnecessarily" I sent out earlier gets rid of this error.
But yes, I want to test -recur with the linux kernel on the weekend.
Ciao,
Dscho
P.S.: Pavel, thanks for the "A dedicated programmer with good C and Python
skills could rewrite git-merge-recursive.py in C in 2 days, I believe. Add
a few days of bug fixing, of course." underestimation. I do not know if I
had started fiddling with it if I had known how involved it is.
^ permalink raw reply
* Re: What's in git.git, and announcing GIT 1.4.2-rc4
From: Johannes Schindelin @ 2006-08-10 7:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Willy Tarreau, git
In-Reply-To: <7vfyg5xi02.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 9 Aug 2006, Junio C Hamano wrote:
> +
> + /* NUL terminate the result */
> + if (desc.alloc <= desc.size) {
> + desc.buffer = xrealloc(desc.buffer, desc.size + 1);
> + desc.alloc++;
While in this particular case, desc.alloc cannot be smaller than desc.size
(and therefore the condition in the if() is misleading), it might be
better to write "desc.alloc = desc.size + 1;" for others to understand...
Ciao,
Dscho
^ permalink raw reply
* [PATCH] combine-diff: use color
From: Junio C Hamano @ 2006-08-10 7:31 UTC (permalink / raw)
To: git
Using the same mechanism as the regular diffs, color combined diff
output.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* I do not use color myself, but I thought this would be good
for consistency's sake...
combine-diff.c | 50 ++++++++++++++++++++++++++++++++++----------------
1 files changed, 34 insertions(+), 16 deletions(-)
diff --git a/combine-diff.c b/combine-diff.c
index 919112b..ba8baca 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -497,11 +497,17 @@ static void show_parent_lno(struct sline
printf(" -%lu,%lu", l0, l1-l0);
}
-static void dump_sline(struct sline *sline, unsigned long cnt, int num_parent)
+static void dump_sline(struct sline *sline, unsigned long cnt, int num_parent,
+ int use_color)
{
unsigned long mark = (1UL<<num_parent);
int i;
unsigned long lno = 0;
+ const char *c_frag = diff_get_color(use_color, DIFF_FRAGINFO);
+ const char *c_new = diff_get_color(use_color, DIFF_FILE_NEW);
+ const char *c_old = diff_get_color(use_color, DIFF_FILE_OLD);
+ const char *c_plain = diff_get_color(use_color, DIFF_PLAIN);
+ const char *c_reset = diff_get_color(use_color, DIFF_RESET);
if (!cnt)
return; /* result deleted */
@@ -522,12 +528,13 @@ static void dump_sline(struct sline *sli
rlines = hunk_end - lno;
if (cnt < hunk_end)
rlines--; /* pointing at the last delete hunk */
+ fputs(c_frag, stdout);
for (i = 0; i <= num_parent; i++) putchar(combine_marker);
for (i = 0; i < num_parent; i++)
show_parent_lno(sline, lno, hunk_end, i);
printf(" +%lu,%lu ", lno+1, rlines);
for (i = 0; i <= num_parent; i++) putchar(combine_marker);
- putchar('\n');
+ printf("%s\n", c_reset);
while (lno < hunk_end) {
struct lline *ll;
int j;
@@ -535,18 +542,23 @@ static void dump_sline(struct sline *sli
sl = &sline[lno++];
ll = sl->lost_head;
while (ll) {
+ fputs(c_old, stdout);
for (j = 0; j < num_parent; j++) {
if (ll->parent_map & (1UL<<j))
putchar('-');
else
putchar(' ');
}
- puts(ll->line);
+ printf("%s%s\n", ll->line, c_reset);
ll = ll->next;
}
if (cnt < lno)
break;
p_mask = 1;
+ if (!(sl->flag & (mark-1)))
+ fputs(c_plain, stdout);
+ else
+ fputs(c_new, stdout);
for (j = 0; j < num_parent; j++) {
if (p_mask & sl->flag)
putchar('+');
@@ -554,7 +566,7 @@ static void dump_sline(struct sline *sli
putchar(' ');
p_mask <<= 1;
}
- printf("%.*s\n", sl->len, sl->bol);
+ printf("%.*s%s\n", sl->len, sl->bol, c_reset);
}
}
}
@@ -586,14 +598,15 @@ static void reuse_combine_diff(struct sl
sline->p_lno[i] = sline->p_lno[j];
}
-static void dump_quoted_path(const char *prefix, const char *path)
+static void dump_quoted_path(const char *prefix, const char *path,
+ const char *c_meta, const char *c_reset)
{
- fputs(prefix, stdout);
+ printf("%s%s", c_meta, prefix);
if (quote_c_style(path, NULL, NULL, 0))
quote_c_style(path, NULL, stdout, 0);
else
printf("%s", path);
- putchar('\n');
+ printf("%s\n", c_reset);
}
static int show_patch_diff(struct combine_diff_path *elem, int num_parent,
@@ -699,18 +712,22 @@ static int show_patch_diff(struct combin
if (show_hunks || mode_differs || working_tree_file) {
const char *abb;
+ int use_color = opt->color_diff;
+ const char *c_meta = diff_get_color(use_color, DIFF_METAINFO);
+ const char *c_reset = diff_get_color(use_color, DIFF_RESET);
if (rev->loginfo)
show_log(rev, opt->msg_sep);
- dump_quoted_path(dense ? "diff --cc " : "diff --combined ", elem->path);
- printf("index ");
+ dump_quoted_path(dense ? "diff --cc " : "diff --combined ",
+ elem->path, c_meta, c_reset);
+ printf("%sindex ", c_meta);
for (i = 0; i < num_parent; i++) {
abb = find_unique_abbrev(elem->parent[i].sha1,
abbrev);
printf("%s%s", i ? "," : "", abb);
}
abb = find_unique_abbrev(elem->sha1, abbrev);
- printf("..%s\n", abb);
+ printf("..%s%s\n", abb, c_reset);
if (mode_differs) {
int added = !!elem->mode;
@@ -719,10 +736,11 @@ static int show_patch_diff(struct combin
DIFF_STATUS_ADDED)
added = 0;
if (added)
- printf("new file mode %06o", elem->mode);
+ printf("%snew file mode %06o",
+ c_meta, elem->mode);
else {
if (!elem->mode)
- printf("deleted file ");
+ printf("%sdeleted file ", c_meta);
printf("mode ");
for (i = 0; i < num_parent; i++) {
printf("%s%06o", i ? "," : "",
@@ -731,11 +749,11 @@ static int show_patch_diff(struct combin
if (elem->mode)
printf("..%06o", elem->mode);
}
- putchar('\n');
+ printf("%s\n", c_reset);
}
- dump_quoted_path("--- a/", elem->path);
- dump_quoted_path("+++ b/", elem->path);
- dump_sline(sline, cnt, num_parent);
+ dump_quoted_path("--- a/", elem->path, c_meta, c_reset);
+ dump_quoted_path("+++ b/", elem->path, c_meta, c_reset);
+ dump_sline(sline, cnt, num_parent, opt->color_diff);
}
free(result);
--
1.4.2.rc4.gcdaa
^ permalink raw reply related
* Re: cvs2svn and git progress
From: Martin Langhoff @ 2006-08-10 7:28 UTC (permalink / raw)
To: Jon Smirl; +Cc: git, Shawn Pearce
In-Reply-To: <9e4733910608091828l1744822cjf001b2722fea6c5a@mail.gmail.com>
On 8/10/06, Jon Smirl <jonsmirl@gmail.com> wrote:
> I've finally got cvs2svn running through pass 7 now. It took me a
Jon,
great stuff. Is this published somewhere I can pull it from?
cheers,
martin
^ permalink raw reply
* Re: merge-recur status
From: Fredrik Kuivinen @ 2006-08-10 6:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0608092232000.13885@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
I just want to say that you have made a great work with porting
merge-recursive to C!
I ran merge-recur through a couple of test merges that I used to test
merge-recursive with. It is mostly merge cases people have posted to
the mailing list, but also some home made ones. For some of them I get
segmentation faults, see the log below. The first three come from
Linus kernel tree. The last one,
44583d380d189095fa959ec8ba87f0cb6deb15f5, is from Thomas Gleixner's
historical Linux kernel repository. I haven't seen "fatal: fatal:
cache changed flush_cache();" before...
Let me know if you can't reproduce some them.
- Fredrik
Testing 84ffa747520edd4556b136bdfc9df9eb1673ce12 Merge from-linus to-akpm
Starting merge...
Merging merge-test-branch with 81065e2f415af6c028eac13f481fb9e60a0b487b
Merging:
702c7e7626deeabb057b6f529167b65ec2eefbdb [ACPI] fix ia64 build issues resulting from Lindent and merge
81065e2f415af6c028eac13f481fb9e60a0b487b [PATCH] zd1201 kmalloc size fix
found 2 common ancestor(s):
30e332f3307e9f7718490a706e5ce99f0d3a7b26 [ACPI] re-enable platform-specific hotkey drivers by default
3edea4833a1efcd43e1dff082bc8001fdfe74b34 [PATCH] intelfb/fbdev: Save info->flags in a local variable
Merging:
30e332f3307e9f7718490a706e5ce99f0d3a7b26 [ACPI] re-enable platform-specific hotkey drivers by default
3edea4833a1efcd43e1dff082bc8001fdfe74b34 [PATCH] intelfb/fbdev: Save info->flags in a local variable
found 1 common ancestor(s):
d4ab025b73a2d10548e17765eb76f3b7351dc611 [ACPI] delete Warning: Encountered executable code at module level, [AE_NOT_CONFIGURED]
Removing Documentation/DocBook/scsidrivers.tmpl
Removing Documentation/dvb/README.dibusb
Auto-merging Documentation/kernel-parameters.txt
Removing Documentation/networking/wanpipe.txt
Removing arch/arm/kernel/arch.c
Removing arch/arm/lib/longlong.h
Removing arch/arm/lib/udivdi3.c
Removing arch/arm/mach-omap/Kconfig
Removing arch/arm/mach-omap/Makefile
Removing arch/arm/mach-omap/common.c
Removing arch/mips/vr41xx/common/giu.c
Removing arch/ppc/boot/utils/addSystemMap.c
Removing arch/ppc/syslib/ppc4xx_kgdb.c
Removing arch/ppc64/boot/mknote.c
Removing arch/ppc64/boot/piggyback.c
Removing arch/ppc64/kernel/XmPciLpEvent.c
Removing arch/ppc64/kernel/iSeries_pci_reset.c
Removing arch/um/kernel/skas/time.c
Removing arch/um/kernel/tt/time.c
Removing arch/um/kernel/tt/unmap.c
Auto-merging drivers/acpi/osl.c
Removing drivers/base/class_simple.c
Removing drivers/ide/cris/ide-v10.c
Removing drivers/input/gameport/cs461x.c
Removing drivers/input/gameport/vortex.c
Removing drivers/isdn/hisax/enternow.h
Removing drivers/isdn/hisax/st5481_hdlc.c
Removing drivers/isdn/hisax/st5481_hdlc.h
Removing drivers/isdn/sc/debug.c
Removing drivers/macintosh/macserial.c
Removing drivers/macintosh/macserial.h
Removing drivers/media/dvb/b2c2/skystar2.c
Removing drivers/media/dvb/dibusb/Kconfig
Removing drivers/media/dvb/dibusb/Makefile
Removing drivers/media/dvb/dibusb/dvb-dibusb-core.c
Removing drivers/media/dvb/dibusb/dvb-dibusb-dvb.c
Removing drivers/media/dvb/dibusb/dvb-dibusb-fe-i2c.c
Removing drivers/media/dvb/dibusb/dvb-dibusb-firmware.c
Removing drivers/media/dvb/dibusb/dvb-dibusb-remote.c
Removing drivers/media/dvb/dibusb/dvb-dibusb-usb.c
Removing drivers/media/dvb/dibusb/dvb-dibusb.h
Removing drivers/mtd/maps/db1550-flash.c
Removing drivers/mtd/maps/db1x00-flash.c
Removing drivers/mtd/maps/elan-104nc.c
Removing drivers/mtd/maps/pb1550-flash.c
Removing drivers/mtd/maps/pb1xxx-flash.c
Removing drivers/mtd/nand/tx4925ndfmc.c
Removing drivers/mtd/nand/tx4938ndfmc.c
Removing drivers/net/fmv18x.c
Removing drivers/net/sk_g16.c
Removing drivers/net/sk_g16.h
Removing drivers/net/skfp/lnkstat.c
Removing drivers/net/skfp/smtparse.c
Removing drivers/net/smc-mca.h
Removing drivers/pci/hotplug/acpiphp_pci.c
Removing drivers/pci/hotplug/acpiphp_res.c
Removing drivers/scsi/pci2000.c
Removing drivers/scsi/pci2220i.c
Removing drivers/scsi/pci2220i.h
Removing drivers/scsi/psi_dale.h
Removing drivers/scsi/psi_roy.h
Removing drivers/serial/bast_sio.c
Removing drivers/usb/atm/usb_atm.c
Removing drivers/usb/atm/usb_atm.h
Removing fs/freevxfs/vxfs_kcompat.h
Removing include/asm-m32r/m32102peri.h
Removing include/asm-ppc/fsl_ocp.h
Removing include/asm-ppc64/iSeries/HvCallCfg.h
Removing include/asm-ppc64/iSeries/LparData.h
Removing include/asm-ppc64/iSeries/XmPciLpEvent.h
Removing include/asm-ppc64/iSeries/iSeries_proc.h
Removing include/linux/ioc4_common.h
Removing include/linux/netfilter_ipv4/lockhelp.h
Removing include/linux/pci-dynids.h
Removing include/linux/xattr_acl.h
Removing net/ipv4/utils.c
Removing sound/pcmcia/vx/vx_entry.c
Removing sound/pcmcia/vx/vxp/home/freku/local/bin/git-merge: line 286: 32288 Segmenteringsfel git-merge-$strategy $common -- "$head_arg" "$@"
No merge strategy handled the merge.
Exit code: 2
Testing 0c168775709faa74c1b87f1e61046e0c51ade7f3 Merge upstream 2.6.13-rc1-git1 into 'ieee80211' branch of netdev-2.6.
Starting merge...
/home/freku/local/bin/git-merge: line 286: 32357 Segmenteringsfel git-merge-$strategy $common -- "$head_arg" "$@"
No merge strategy handled the merge.
Exit code: 2
Testing 467ca22d3371f132ee225a5591a1ed0cd518cb3d Merge with rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Starting merge...
/home/freku/local/bin/git-merge: line 286: 32702 Segmenteringsfel git-merge-$strategy $common -- "$head_arg" "$@"
No merge strategy handled the merge.
Exit code: 2
Testing 44583d380d189095fa959ec8ba87f0cb6deb15f5 Merge uml.karaya.com:/home/jdike/linux/2.5/skas-2.5
Starting merge...
merge: warning: conflicts during merge
fatal: fatal: cache changed flush_cache();
Merging merge-test-branch with 8bf1412a4bbfc9da0224e73203172f98f987b41a
Merging:
645dbacc0c65228151b7cbcb8a977c83328cef76 Put X86_NUMAQ and X86_SUMMIT under the "Subarchitecture Type" config.
8bf1412a4bbfc9da0224e73203172f98f987b41a Forwarded ported a number of skas-related fixes from 2.4.
found 6 common ancestor(s):
170f6c8f82c198fb54f86cbef95a631eec6034af Merge jdike.wstearns.org:/home/jdike/linux/linus-2.5
6543e917ce4a0b1702d80a3d54b3711cf936abef Merge jdike.wstearns.org:/home/jdike/linux/linus-2.5
48277fd028606d49ed7cbfa3d70006c7701e8157 Merge jdike.wstearns.org:/home/jdike/linux/linus-2.5
625207a1f419e3e217a0b343f12accf9d281d25b Merge jdike.stearns.org:linux/fixes-2.5
8631e9b3bd11d994fb99bc9f7451a1337cfc9487 Merge jdike.wstearns.org:/home/jdike/linux/linus-2.5
31f3e9c005d3378db504d26e387ba6b91aa19e49 Merge jdike.wstearns.org:/home/jdike/linux/linus-2.5
Merging:
170f6c8f82c198fb54f86cbef95a631eec6034af Merge jdike.wstearns.org:/home/jdike/linux/linus-2.5
6543e917ce4a0b1702d80a3d54b3711cf936abef Merge jdike.wstearns.org:/home/jdike/linux/linus-2.5
found 2 common ancestor(s):
5e32ae7ed6f1dd53fbdd9c3540f4b1dcbcc0c5ef Linux v2.5.53
433553bd1f42c0515fe77d9c0a93b67c2ff66030 Updated to 2.5.49, which involved fixing the calls to do_fork.
Merging:
5e32ae7ed6f1dd53fbdd9c3540f4b1dcbcc0c5ef Linux v2.5.53
433553bd1f42c0515fe77d9c0a93b67c2ff66030 Updated to 2.5.49, which involved fixing the calls to do_fork.
found 1 common ancestor(s):
cebce9d8beb7493d5c82035db854a475f6a1ae66 Linux v2.5.49
Auto-merging arch/um/kernel/sys_call_table.c
Auto-merging arch/um/sys-i386/Makefile
Auto-merging arch/um/kernel/signal_kern.c
Auto-merging arch/um/kernel/syscall_kern.c
Removing arch/um/ptproxy/Makefile
Merging:
virtual merged tree
48277fd028606d49ed7cbfa3d70006c7701e8157 Merge jdike.wstearns.org:/home/jdike/linux/linus-2.5
found 1 common ancestor(s):
5e32ae7ed6f1dd53fbdd9c3540f4b1dcbcc0c5ef Linux v2.5.53
Merging:
virtual merged tree
625207a1f419e3e217a0b343f12accf9d281d25b Merge jdike.stearns.org:linux/fixes-2.5
found 1 common ancestor(s):
5e32ae7ed6f1dd53fbdd9c3540f4b1dcbcc0c5ef Linux v2.5.53
Auto-merging arch/um/Makefile
Removing arch/um/boot/Makefile
Auto-merging arch/um/drivers/fd.c
Auto-merging arch/um/drivers/port_kern.c
CONFLICT (content): Merge conflict in arch/um/drivers/port_kern.c
Auto-merging arch/um/drivers/port_user.c
Auto-merging arch/um/drivers/ubd_kern.c
Auto-merging arch/um/drivers/xterm.c
Auto-merging arch/um/kernel/helper.c
Removing arch/um/kernel/setup.c
Merging:
virtual merged tree
8631e9b3bd11d994fb99bc9f7451a1337cfc9487 Merge jdike.wstearns.org:/home/jdike/linux/linus-2.5
found 2 common ancestor(s):
5e32ae7ed6f1dd53fbdd9c3540f4b1dcbcc0c5ef Linux v2.5.53
341d04a98d72b0693909f8e8a7ef3b064f07167d Merged the get_config changes from 2.4.
Merging:
5e32ae7ed6f1dd53fbdd9c3540f4b1dcbcc0c5ef Linux v2.5.53
341d04a98d72b0693909f8e8a7ef3b064f07167d Merged the get_config changes from 2.4.
found 1 common ancestor(s):
fc983daf8fe2318d66f416931b0f6b1e469e78e6 Linux v2.5.48
Already uptodate!
Merging:
virtual merged tree
31f3e9c005d3378db504d26e387ba6b91aa19e49 Merge jdike.wstearns.org:/home/jdike/linux/linus-2.5
found 1 common ancestor(s):
5e32ae7ed6f1dd53fbdd9c3540f4b1dcbcc0c5ef Linux v2.5.53
No merge strategy handled the merge.
Exit code: 2
^ permalink raw reply
* Re: What's in git.git, and announcing GIT 1.4.2-rc4
From: Willy Tarreau @ 2006-08-10 5:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfyg5xi02.fsf@assigned-by-dhcp.cox.net>
On Wed, Aug 09, 2006 at 10:43:57PM -0700, Junio C Hamano wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
> > Willy Tarreau <w@1wt.eu> writes:
> >
> >> I encountered a problem in 1.4.1 and 1.4-git about 2 weeks ago
> >> (I've not tried 1.4.2-rc4 yet). When applying a git patch which
> >> contains a symlink, the symlink created on the filesystem sometimes
> >> has a wrong name with some chars appended to its end.
> >
> > Thanks. I can reproduce this, and am looking into it.
>
> Found it. The patch application mechanism uses a counted string
> (char *buf with ulong size) to hold the result, and the code
> stupidly threw the buf to symlink(2), without making it NUL
> terminated.
Excellent ! That means that under some circumstances, it might even have
corrupted the very first link, and not necessarily only the second and
other ones. Thanks for having fixed it that fast.
Cheers,
Willy
^ permalink raw reply
* Re: What's in git.git, and announcing GIT 1.4.2-rc4
From: Junio C Hamano @ 2006-08-10 5:43 UTC (permalink / raw)
To: Willy Tarreau; +Cc: git
In-Reply-To: <7vu04lxjsv.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Willy Tarreau <w@1wt.eu> writes:
>
>> I encountered a problem in 1.4.1 and 1.4-git about 2 weeks ago
>> (I've not tried 1.4.2-rc4 yet). When applying a git patch which
>> contains a symlink, the symlink created on the filesystem sometimes
>> has a wrong name with some chars appended to its end.
>
> Thanks. I can reproduce this, and am looking into it.
Found it. The patch application mechanism uses a counted string
(char *buf with ulong size) to hold the result, and the code
stupidly threw the buf to symlink(2), without making it NUL
terminated.
diff --git a/builtin-apply.c b/builtin-apply.c
index f8c6763..c159873 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -1698,6 +1698,14 @@ static int apply_data(struct patch *patc
desc.buffer = buf;
if (apply_fragments(&desc, patch) < 0)
return -1;
+
+ /* NUL terminate the result */
+ if (desc.alloc <= desc.size) {
+ desc.buffer = xrealloc(desc.buffer, desc.size + 1);
+ desc.alloc++;
+ }
+ desc.buffer[desc.size] = 0;
+
patch->result = desc.buffer;
patch->resultsize = desc.size;
@@ -2040,6 +2048,9 @@ static int try_create_file(const char *p
int fd;
if (S_ISLNK(mode))
+ /* Although buf:size is counted string, it also is NUL
+ * terminated.
+ */
return symlink(buf, path);
fd = open(path, O_CREAT | O_EXCL | O_WRONLY, (mode & 0100) ? 0777 : 0666);
if (fd < 0)
^ permalink raw reply related
* Re: What's in git.git, and announcing GIT 1.4.2-rc4
From: Junio C Hamano @ 2006-08-10 5:05 UTC (permalink / raw)
To: Willy Tarreau; +Cc: git
In-Reply-To: <20060810033448.GH8776@1wt.eu>
Willy Tarreau <w@1wt.eu> writes:
> I encountered a problem in 1.4.1 and 1.4-git about 2 weeks ago
> (I've not tried 1.4.2-rc4 yet). When applying a git patch which
> contains a symlink, the symlink created on the filesystem sometimes
> has a wrong name with some chars appended to its end.
Thanks. I can reproduce this, and am looking into it.
^ permalink raw reply
* Re: What's in git.git, and announcing GIT 1.4.2-rc4
From: Willy Tarreau @ 2006-08-10 3:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy7txxts5.fsf@assigned-by-dhcp.cox.net>
Hi Junio,
On Wed, Aug 09, 2006 at 06:29:30PM -0700, Junio C Hamano wrote:
> GIT 1.4.2-rc4
>
> It's been a week since -rc3, so here it is. The changes are
> really small fixes and nothing else. Let's hope I can tag the
> real 1.4.2 this weekend.
I encountered a problem in 1.4.1 and 1.4-git about 2 weeks ago
(I've not tried 1.4.2-rc4 yet). When applying a git patch which
contains a symlink, the symlink created on the filesystem sometimes
has a wrong name with some chars appended to its end, such as if its
name was not zero-terminated. I always encountered this only when
there were several symlinks in the patch, eg: you create a symlink
first, then commit, then change its dest, then commit, then git-format-patch
and try to apply both patches (git-am -k -3) to another tree. Generally,
the second link will be broken. The index will be OK however, since git-status
will complain about it.
I've tried to find the reason for this problem in the code, but
failed to do so. I remember that the function which calls symlink()
(I don't remember its name, sorry) already gets an invalid name in
path->name or something like this.
That's all I could do because I was really too short in time, and I'm
sorry I really don't have enough time to track this further right now.
However, if you have some time to reproduce it and have questions, I'm
willing to respond you.
Thanks, and sorry again for the lack of information,
Willy
^ permalink raw reply
* What's in git.git, and announcing GIT 1.4.2-rc4
From: Junio C Hamano @ 2006-08-10 1:29 UTC (permalink / raw)
To: git; +Cc: linux-kernel
GIT 1.4.2-rc4
It's been a week since -rc3, so here it is. The changes are
really small fixes and nothing else. Let's hope I can tag the
real 1.4.2 this weekend.
* The 'master' branch has these since the last announcement;
these are all in 1.4.2-rc4:
Jeff King:
git-push: allow pushing from subdirectories
Johannes Schindelin:
Fix crash when GIT_DIR is invalid
Jonas Fonseca:
Update git-init-db(1) and documentation of core.sharedRepository
Junio C Hamano:
Cygwin needs NO_C99_FORMAT???
Makefile: Cygwin does not seem to need NO_STRLCPY
Fix "grep -w"
debugging: XMALLOC_POISON
builtin-mv: fix use of uninitialized memory.
GIT-VERSION-GEN: adjust for ancient git
Documentation: git-status takes the same options as git-commit
Fix tutorial-2.html
check return value from diff_setup_done()
find_unique_abbrev() with len=0 should not abbreviate
make --find-copies-harder imply -C
allow diff.renamelimit to be set regardless of -M/-C
Michael Krelin:
handle https:// protocol in git-clone
Ramsay Jones:
Allow config file to specify Signed-off-by identity in format-patch.
commit walkers: setup_ident() to record correct committer in ref-log.
Ryan Anderson:
log-tree: show_log() should respect the setting of diffopt->line_termination
annotate: Fix bug when parsing merges with differing real and logical parents.
* The 'next' branch, in addition, has these.
= To graduate immediately after 1.4.2 happens:
- Jakub Narebski's autoconf stuff acquired a bit more
clean-ups and new detections since the last announcement.
- A new merge strategy, merge-recur, which is a rewrite of
merge-recursive in C, by Johannes and Alex.
- More commands are made built-in by Matthias Kestenholz, and
I cleaned up the build procedure for built-ins a bit.
- Matthias Lederhofer introduced $GIT_PAGER environment
variable that can specify a different pager from $PAGER.
- Ramsay Jones has one header fix to add _GNU_SOURCE, which
helps things to compile in his environment. This was
confirmed to fix a similar problem on an ancient version of
one distribution.
- Timo Hirvonen made the parameter parsing of diff family
saner some time ago. Remaining two minor changes will
graduate to "master" after 1.4.2:
* --name-only, --name-status, --check and -s are mutually exclusive
* Remove awkward compatibility warts "-s". Now -s means "do
not output diff" everywhere, including git-diff-files.
- Johannes made http-push avoid fork() by calling
merge_bases() directly.
- MAX_NEEDS and MAX_HAS limitation in upload-pack has been
lifted.
- pack-objects can copy a non-delta representation of a object
with the new style header straight into packs.
- Paul Mackerras has a few gitk updates.
* Hopefully not too long after 1.4.2:
- A big gitweb clean-up series by Jakub Narebski, with help
from Jeff King, Matthias Lederhofer and Martin Waitz to make
run-time and build-time configuration easier.
Quite a lot of clean-ups and enhancements by Jakub and Luben
Tuikov are queued, and with the proposed function renames,
it may be stable enough to start seriously testing soon
after 1.4.2 happens.
- New style loose objects, which use the same header format as
in-pack objects, can be copied straight into packs when not
deltified. I am hoping that we can make the new-style loose
objects the default in 10 to 12 weeks to give everybody time
to update to 1.4 series.
= Graduation schedule unknown:
- Not-universally-liked Git.pm by Pasky with help from Dennis
Stosberg, Johannes, Pavel Roskin and others. One drawback
is this pretty much makes Perl scripts that use Git.pm
unusable with ActiveState right now. No changes since the
last announcement.
- Linus worries that Racy-git avoidance code leaves racily-clean
index entries forever and hurts performance, and I did some
tweaks. First we need to verify performance is actually
harmed and by how much to see if this is needed.
* The 'pu' branch, in addition, has these.
- An update to upload-pack to prevent it from going all the
way back when the downloader has more roots than it. Needs
testing and comments.
- Johannes has a new diff option --color-words to use color to
squash word differences into single line output.
I do not feel much need for this stuff, and the change is
rather intrusive, so I am tempted to drop it.
- A new merge strategy, merge-rename, which is still a
work-in-progress to handle renames in read-tree 3-way
merge. Judging from the way Johannes's merge-recur is
making progress, I may want to drop this.
^ permalink raw reply
* cvs2svn and git progress
From: Jon Smirl @ 2006-08-10 1:29 UTC (permalink / raw)
To: git, Shawn Pearce
I've finally got cvs2svn running through pass 7 now. It took me a
while to fix errors where it would run five hours and then die with
"key error 357" or something similar.
pass 1: 7663 seconds
pass 2: 1 second
pass 3: 1043 seconds
pass 4: 3 seconds
pass 5: 204 seconds
pass 6: 1165 seconds
pass 7: 37 seconds
Total is a little less than three hours. The new cvs2svn code is many
times faster than the old version which ran for several days. The
total includes the time needed to write the git pack and index file
for the revisions.
Pass 8 is where the final output is generated. Now that I have a
database I can only run pass 8 as needed to work on the back-end code.
I believe I have the sha1 from the git revisions correctly in the
final database but I need to write my first try at dumping the change
sets to be sure.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH and RFC] gitweb: Remove --full-history from git_history
From: Junio C Hamano @ 2006-08-09 21:42 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: git, Jakub Narebski
In-Reply-To: <20060809192815.GA7954@c165.ib.student.liu.se>
Fredrik Kuivinen <freku045@student.liu.se> writes:
> I don't think it was dropped in favor --full-history.
Correct.
The --full-history option is about merge simplification and has
nothing to do with renames.
The thing is, your patch, while I very much liked the direction
it was taking us, was so intrusive that it scared the h*ck out
of me ;-).
>> What is needed by gitweb is for git-rev-list to not only follow revisions
>> of file contents across renames, and return more revisions,
>
> Note that it is not enough to only return more revisions.
>
> For example, consider the commits (newest commit first)
> A: Rename "bar" to "foo"
> B: No changes to "bar"
> C: No changes to "bar", delete "foo"
> <more commits here>
>
> Then you want "git-rev-list --renames A -- foo" to return A,... not A,C,...
Yes. For this "following renames for a single file" example, we
should not extend the pathspec which originally starts out as
"foo" to _include_ "bar"; instead it should _replace_, and after
that point we should not care about "foo".
This was another reason I shied away from your patch back then.
We would need to think about interactions between this pathspec
for a single file (which should be switched) and pathspecs for
directories ("more useful form of usage than single file", as
Linus would put it).
I have this vague feeling, without revisiting the code to make
an informed argument, that it might be cleaner and with less
impact (read: smaller chance to break the "directories" usage)
if we special case "follow a single file" case. I dunno.
Also I was not sure how well your pathspec switching worked
across forks and merges.
M bar
.----------------4------5
/ \
A bar / R bar->foo M foo \ M foo
0------1-----2-----------3-----------6----7-------8
Suppose we are at 8 and start digging for the history of "foo".
Our pathspec starts out as "foo" at 8 and stays so until we hit
6. If the lower branch renamed bar->foo while the upper didn't,
and merge-recursive merged them correctly at 6, we would use
"foo" as pathspec while on the lower branch while traversing 6,
3 and 2 (at that point we switch to "bar"). On the upper
branch, we switch pathspec to "bar" while traversing 6, 5, 4.
When we hit 1, pathspec of both of its children (2 and 4) happen
to match in this example. But what would we do if for some
reason they didn't? Do we care? Is that die("an internal
error")? I did not have a good anser to that question, and I
still don't.
^ permalink raw reply
* Re: merge-recur status
From: Junio C Hamano @ 2006-08-09 21:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0608092232000.13885@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> I tried to wrap my head over it, but seem unable to do so. Also, I do not
> find the case 14ALT (which is mentioned in unpack-trees.c:603) in
> Documentation/technical/trivial-merge.txt.
That is t/t1000-read-tree-m-3way.sh case 14. The current
semantics for case 14 used to be called ALT until 3e03aaf
simplified the table to reflect the reality, because the
"alternative" semantics had been in use for quite some time
already back then.
I'd like to take a look at 41094b8e, the real trouble that is
causing you grief, sometime later, but I'm currently pondering
if the one I tag should be called 1.4.2 or 1.4.2-rc4 ;-).
^ 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