* Re: [PATCH 07/16] git-read-tree: take --submodules option
From: Jan Hudec @ 2007-05-20 15:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: skimo, Alex Riesen, git
In-Reply-To: <7v4pm8y8tf.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 3583 bytes --]
On Sat, May 19, 2007 at 11:20:12 -0700, Junio C Hamano wrote:
> Sven Verdoolaege <skimo@kotnet.org> writes:
>
> > Does everyone agree that we should fetch (possibly after asking
> > for confirmation from the use) _during_ the checkout ?
> > I now only fetch submodules during a fetch of the supermodule
> > (actually, in my current patch set, I only fetch a submodule
> > the first time I see it, but that's a bug), but if there is
> > a consensus on this, I can switch to fetching during checkout.
>
> I think fetching of subproject during fetch or clone of
> superproject would not make much sense. Making it part of
> superproject checkout would probably be the way we will end up
> going. The detail of "which part of the checkout" would need to
> be defined, and I tend to agree with Alex that checkout itself
> would need to be multi-phased, but I think that is a minor
> implementation detail we can discuss after how the overall flows
> should look like.
IMHO it makes more sense to fetch during fetch of superproject:
- If you don't fetch the superproject, it won't start refering to
unavailable commit of subproject. So should only need to fetch subproject
after fetching superproject.
- If you fetch from more than one location, you want to fetch subproject
from location corresponding to where you fetch superproject from.
Let's have a repository of project P with remotes PA and PB. Let it have
a subproject S with remotes SA and SB.
Whenever I pull P from PA, it might refer to commit of S, that is only
available from SA (because that's what PA owner uses). Whenever I pull
P from PB, it might refer to commit of S, that is only available from SB
(again because that's what PB owner uses).
Now checkout does not know, whether I pulled the target revision from PA
or PB, so:
- Either it has to fetch both. But say the commit I want is in SB and SA
contains a lot of new stuff, which will slow the thing down, though
I don't need it.
- Or it has to guess by looking whether any heads in remotes/PA or
remotes/PB are descendants of the commit being checked out. But that
feels rather hacky.
I see several options:
- Fetch will recurse. This should work ok and is IMHO least magic. We can
also add some way to specify refspecs for the subproject, giving user
control over what is fetched.
- Fetch will store a "pending fetch from" note in the subproject and
checkout, if it does not find the revision, will try fetching from all
sources pointed to by those notes. There is still a problem with what
exactly to fetch (user can specify in config).
- Checkout will ask all subproject repositories whether they have given
commit and pull the first one that does. This would get the needed
commit most certainly. It would be slower though, because it would need
to ask all the repositories whether they have the particular object.
It also leaves the tracking branches in subproject in somewhat random
state (maybe both repositories had the commit, so it pulled from the
other one that user would etc.).
> > As to the key to use to lookup the URL in the config, right
> > now I simply use the directory name where it is attached
> > (which seems like a useful default to me).
The extra level of indirection has the advantage, that you can describe
moving the same subproject to a different directory.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] gitweb.perl - Optionally send archives as .zip files
From: Mark Levedahl @ 2007-05-20 15:46 UTC (permalink / raw)
To: git; +Cc: Mark Levedahl
git-archive already knows how to generate an archive as a tar or a zip
file, but gitweb did not. zip archvies are much more usable in a Windows
environment due to native support and this patch allows a site admin the
option to deliver zip rather than tar files. The selection is done by
inserting
$feature{'snapshot'}{'default'} = ['x-zip', 'zip', ''];
in gitweb_config.perl.
Tar files remain the default option.
Signed-off-by: Mark Levedahl <mdl123@verizon.net>
---
gitweb/gitweb.perl | 25 +++++++++++++++++--------
1 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 21864c6..273cad2 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -129,7 +129,7 @@ our %feature = (
# $feature{'snapshot'}{'default'} = [undef];
# To have project specific config enable override in $GITWEB_CONFIG
# $feature{'snapshot'}{'override'} = 1;
- # and in project config gitweb.snapshot = none|gzip|bzip2;
+ # and in project config gitweb.snapshot = none|gzip|bzip2|zip;
'snapshot' => {
'sub' => \&feature_snapshot,
'override' => 0,
@@ -227,6 +227,8 @@ sub feature_snapshot {
return ('x-gzip', 'gz', 'gzip');
} elsif ($val eq 'bzip2') {
return ('x-bzip2', 'bz2', 'bzip2');
+ } elsif ($val eq 'zip') {
+ return ('x-zip', 'zip', '');
} elsif ($val eq 'none') {
return ();
}
@@ -3912,19 +3914,26 @@ sub git_snapshot {
$hash = git_get_head_hash($project);
}
- my $filename = decode_utf8(basename($project)) . "-$hash.tar.$suffix";
+ my $git = git_cmd_str();
+ my $name = $project;
+ $name =~ s/\047/\047\\\047\047/g;
+ my $filename = decode_utf8(basename($project));
+ my $cmd;
+ if ($suffix eq 'zip') {
+ $filename .= "-$hash.$suffix";
+ $cmd = "$git archive --format=zip --prefix=\'$name\'/ $hash";
+ } else {
+ $filename .= "-$hash.tar.$suffix";
+ $cmd = "$git archive --format=tar --prefix=\'$name\'/ $hash | $command";
+ }
print $cgi->header(
-type => "application/$ctype",
-content_disposition => 'inline; filename="' . "$filename" . '"',
-status => '200 OK');
- my $git = git_cmd_str();
- my $name = $project;
- $name =~ s/\047/\047\\\047\047/g;
- open my $fd, "-|",
- "$git archive --format=tar --prefix=\'$name\'/ $hash | $command"
- or die_error(undef, "Execute git-tar-tree failed");
+ open my $fd, "-|", $cmd
+ or die_error(undef, "Execute git-archive failed");
binmode STDOUT, ':raw';
print <$fd>;
binmode STDOUT, ':utf8'; # as set at the beginning of gitweb.cgi
--
1.5.2.rc3.95.gb3c7e
^ permalink raw reply related
* [PATCH] gitk - Update fontsize in patch / tree list
From: Mark Levedahl @ 2007-05-20 15:45 UTC (permalink / raw)
To: paulus, git; +Cc: Mark Levedahl
When adjusting fontsize (using ctrl+/-), all panes except the lower right
were updated. This fixes that.
Signed-off-by: Mark Levedahl <mdl123@verizon.net>
---
gitk | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/gitk b/gitk
index 530f8e1..4a15d7b 100755
--- a/gitk
+++ b/gitk
@@ -4695,13 +4695,14 @@ proc redisplay {} {
}
proc incrfont {inc} {
- global mainfont textfont ctext canv phase
+ global mainfont textfont ctext canv phase cflist
global stopped entries
unmarkmatches
set mainfont [lreplace $mainfont 1 1 [expr {[lindex $mainfont 1] + $inc}]]
set textfont [lreplace $textfont 1 1 [expr {[lindex $textfont 1] + $inc}]]
setcoords
$ctext conf -font $textfont
+ $cflist conf -font $textfont
$ctext tag conf filesep -font [concat $textfont bold]
foreach e $entries {
$e conf -font $mainfont
--
1.5.2.rc3.95.gb3c7e
^ permalink raw reply related
* [PATCH] gitk - Allow specifying tabstop as other than default 8 characters.
From: Mark Levedahl @ 2007-05-20 15:45 UTC (permalink / raw)
To: paulus, git; +Cc: Mark Levedahl
In-Reply-To: <11796759503065-git-send-email-mdl123@verizon.net>
Not all projects use the convention that one tabstop = 8 characters, and
a common convention is to use one tabstop = one level of indent. For such
projects, using 8 characters per tabstop often shows too much whitespace
per indent. This allows the user to configure the number of characters
to use per tabstop.
Signed-off-by: Mark Levedahl <mdl123@verizon.net>
---
gitk | 17 +++++++++++++----
1 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/gitk b/gitk
index 4a15d7b..801c39d 100755
--- a/gitk
+++ b/gitk
@@ -395,7 +395,7 @@ proc confirm_popup msg {
proc makewindow {} {
global canv canv2 canv3 linespc charspc ctext cflist
- global textfont mainfont uifont
+ global textfont mainfont uifont tabstop
global findtype findtypemenu findloc findstring fstring geometry
global entries sha1entry sha1string sha1but
global maincursor textcursor curtextcursor
@@ -615,6 +615,7 @@ proc makewindow {} {
pack .bleft.mid.diff .bleft.mid.old .bleft.mid.new -side left
set ctext .bleft.ctext
text $ctext -background $bgcolor -foreground $fgcolor \
+ -tabs "[expr {$tabstop * $charspc}]" \
-state disabled -font $textfont \
-yscrollcommand scrolltext -wrap none
scrollbar .bleft.sb -command "$ctext yview"
@@ -824,7 +825,7 @@ proc click {w} {
}
proc savestuff {w} {
- global canv canv2 canv3 ctext cflist mainfont textfont uifont
+ global canv canv2 canv3 ctext cflist mainfont textfont uifont tabstop
global stuffsaved findmergefiles maxgraphpct
global maxwidth showneartags
global viewname viewfiles viewargs viewperm nextviewnum
@@ -838,6 +839,7 @@ proc savestuff {w} {
puts $f [list set mainfont $mainfont]
puts $f [list set textfont $textfont]
puts $f [list set uifont $uifont]
+ puts $f [list set tabstop $tabstop]
puts $f [list set findmergefiles $findmergefiles]
puts $f [list set maxgraphpct $maxgraphpct]
puts $f [list set maxwidth $maxwidth]
@@ -4696,12 +4698,13 @@ proc redisplay {} {
proc incrfont {inc} {
global mainfont textfont ctext canv phase cflist
+ global charspc tabstop
global stopped entries
unmarkmatches
set mainfont [lreplace $mainfont 1 1 [expr {[lindex $mainfont 1] + $inc}]]
set textfont [lreplace $textfont 1 1 [expr {[lindex $textfont 1] + $inc}]]
setcoords
- $ctext conf -font $textfont
+ $ctext conf -font $textfont -tabs "[expr {$tabstop * $charspc}]"
$cflist conf -font $textfont
$ctext tag conf filesep -font [concat $textfont bold]
foreach e $entries {
@@ -5852,7 +5855,7 @@ proc doprefs {} {
global maxwidth maxgraphpct diffopts
global oldprefs prefstop showneartags
global bgcolor fgcolor ctext diffcolors selectbgcolor
- global uifont
+ global uifont tabstop
set top .gitkprefs
set prefstop $top
@@ -5890,6 +5893,9 @@ proc doprefs {} {
checkbutton $top.ntag.b -variable showneartags
pack $top.ntag.b $top.ntag.l -side left
grid x $top.ntag -sticky w
+ label $top.tabstopl -text "tabstop" -font optionfont
+ entry $top.tabstop -width 10 -textvariable tabstop
+ grid x $top.tabstopl $top.tabstop -sticky w
label $top.cdisp -text "Colors: press to choose"
$top.cdisp configure -font $uifont
@@ -5988,9 +5994,11 @@ proc prefscan {} {
proc prefsok {} {
global maxwidth maxgraphpct
global oldprefs prefstop showneartags
+ global charspc ctext tabstop
catch {destroy $prefstop}
unset prefstop
+ $ctext configure -tabs "[expr {$tabstop * $charspc}]"
if {$maxwidth != $oldprefs(maxwidth)
|| $maxgraphpct != $oldprefs(maxgraphpct)} {
redisplay
@@ -6296,6 +6304,7 @@ if {$tclencoding == {}} {
set mainfont {Helvetica 9}
set textfont {Courier 9}
set uifont {Helvetica 9 bold}
+set tabstop 8
set findmergefiles 0
set maxgraphpct 50
set maxwidth 16
--
1.5.2.rc3.95.gb3c7e
^ permalink raw reply related
* [PATCH v2] Submodule merge support
From: Martin Waitz @ 2007-05-20 15:42 UTC (permalink / raw)
To: git
When merge-recursive gets to a dirlink, it starts an automatic submodule
merge and then uses the resulting merge commit for the top-level tree.
The submodule merge is done in another process to decouple object databases.
Submodule merges are done solely in the submodules' history, without taking
the supermodule (and it's merge base) into account. If the submodule merge
is successful then the new submodule version will be used in the merged
supermodule.
If one side of the merge removed any submodule commits (e.g. by switching to
a different branch) then the automatic merge is stopped so that the user can
take a closer look on what happened.
Signed-off-by: Martin Waitz <tali@admingilde.org>
---
This patch is based on my previous submodule checkout patch and the
start-commands-in-submodule patch.
This version takes index_only into account and does not need a new
helper script as all code is done in C now.
The entire ll_merge code in merge-recursive still should be moved to
some generic place, but that is for another patch.
merge-recursive.c | 122 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 122 insertions(+), 0 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index 8f72b2c..72562a8 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -11,6 +11,7 @@
#include "diff.h"
#include "diffcore.h"
#include "run-command.h"
+#include "refs.h"
#include "tag.h"
#include "unpack-trees.h"
#include "path-list.h"
@@ -574,6 +575,21 @@ static void update_file_flags(const unsigned char *sha,
void *buf;
unsigned long size;
+ if (S_ISDIRLNK(mode)) {
+ /* defer dirlinks to another process, don't try to */
+ /* read the object "sha" here */
+ const char *dirlink_checkout[] = {
+ "dirlink-checkout", path, sha1_to_hex(sha), NULL
+ };
+ struct child_process cmd = {
+ .argv = dirlink_checkout,
+ .git_cmd = 1,
+ };
+
+ run_command(&cmd);
+ goto update_index;
+ }
+
buf = read_sha1_file(sha, &type, &size);
if (!buf)
die("cannot read object %s '%s'", sha1_to_hex(sha), path);
@@ -1025,6 +1041,105 @@ static int ll_merge(mmbuffer_t *result_buf,
return merge_status;
}
+
+static int ll_dirlink_merge_base(const char *path,
+ const unsigned char *a,
+ const unsigned char *b,
+ unsigned char *result)
+{
+ const char *merge_base[] = {
+ "merge-base",
+ sha1_to_hex(a),
+ sha1_to_hex(b),
+ NULL
+ };
+ struct child_process cmd = {
+ .argv = merge_base,
+ .submodule = path,
+ .git_cmd = 1,
+ .out = -1,
+ };
+ char hex[40];
+ int status;
+
+ status = start_command(&cmd);
+ if (status) return status;
+
+ status = read(cmd.out, hex, sizeof(hex));
+ if (status != 40) return status;
+
+ status = finish_command(&cmd);
+ if (status) return status;
+
+ status = get_sha1_hex(hex, result);
+
+ return status;
+}
+
+static int ll_dirlink_merge(const char *path,
+ const unsigned char *o,
+ const unsigned char *a,
+ const unsigned char *b,
+ unsigned char *result)
+{
+ char b_hex[40+1];
+ const char *merge[] = {
+ "merge", b_hex, NULL
+ };
+ struct child_process cmd = {
+ .argv = merge,
+ .submodule = path,
+ .git_cmd = 1,
+ };
+ int status;
+ unsigned char base[20];
+ unsigned char test[20];
+
+ if (index_only) {
+ /* as submodules have their own history we don't have to */
+ /* try to do the index_only intermediate merges. */
+ /* however we still want to get a submodule version */
+ /* which is suitable as merge-base, just to make sure that */
+ /* all merge parents contain this base. */
+ /* The real merge (below) aborts if this check fails */
+ return ll_dirlink_merge_base(path, a, b, result);
+ }
+
+ strcpy(b_hex, sha1_to_hex(b));
+ output(3, "merging submodule %s:", path);
+ output(3, " o=%s", sha1_to_hex(o));
+ output(3, " a=%s", sha1_to_hex(a));
+ output(3, " b=%s", sha1_to_hex(b));
+
+ /* first check that the submodule is in the current state */
+ /* so that it can be merged. */
+ status = resolve_gitlink_ref(path, "HEAD", test);
+ if (hashcmp(test, a)) {
+ return error("can't merge submodule %s: not up to date.", path);
+ }
+
+ /* check that both sides of the superproject only did a */
+ /* fast forward of the subproject so that it can be merged */
+ /* automatically. */
+ status = ll_dirlink_merge_base(path, a, b, base);
+ if (status) return status;
+ status = ll_dirlink_merge_base(path, o, base, test);
+ if (status) return status;
+ if (hashcmp(test, o)) {
+ return error("can't merge submodule %s: conflicting history",
+ path);
+ }
+
+ /* now start another merge process for the submodule */
+ status = run_command(&cmd);
+ if (status) return status;
+
+ /* get the new merged version */
+ status = resolve_gitlink_ref(path, "HEAD", result);
+
+ return status;
+}
+
static struct merge_file_info merge_file(struct diff_filespec *o,
struct diff_filespec *a, struct diff_filespec *b,
const char *branch1, const char *branch2)
@@ -1069,6 +1184,13 @@ static struct merge_file_info merge_file(struct diff_filespec *o,
free(result_buf.ptr);
result.clean = (merge_status == 0);
+ } else if (S_ISDIRLNK(a->mode)) {
+ int merge_status;
+
+ merge_status = ll_dirlink_merge(a->path,
+ o->sha1, a->sha1, b->sha1, result.sha);
+
+ result.clean = (merge_status == 0);
} else {
if (!(S_ISLNK(a->mode) || S_ISLNK(b->mode)))
die("cannot merge modes?");
--
1.5.2.2.g081e
--
Martin Waitz
^ permalink raw reply related
* [PATCH] allow commands to be executed in submodules
From: Martin Waitz @ 2007-05-20 15:39 UTC (permalink / raw)
To: git
Add an extra "submodule" field to struct child_process to be able to
easily start commands which are to be executed in a submodule
repository.
Signed-off-by: Martin Waitz <tali@admingilde.org>
---
run-command.c | 13 ++++++
run-command.h | 1 +
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/run-command.c b/run-command.c
index eff523e..c2475e4 100644
--- a/run-command.c
+++ b/run-command.c
@@ -73,6 +73,19 @@ int start_command(struct child_process *cmd)
close(cmd->out);
}
+ if (cmd->submodule) {
+ int err = chdir(cmd->submodule);
+ if (err) {
+ die("cannot exec %s in %s.",
+ cmd->argv[0], cmd->submodule);
+ }
+ /* don't inherit supermodule environment */
+ unsetenv(GIT_DIR_ENVIRONMENT);
+ unsetenv(DB_ENVIRONMENT);
+ unsetenv(INDEX_ENVIRONMENT);
+ unsetenv(GRAFT_ENVIRONMENT);
+ }
+
if (cmd->git_cmd) {
execv_git_cmd(cmd->argv);
} else {
diff --git a/run-command.h b/run-command.h
index 3680ef9..2940186 100644
--- a/run-command.h
+++ b/run-command.h
@@ -16,6 +16,7 @@ struct child_process {
pid_t pid;
int in;
int out;
+ const char *submodule;
unsigned close_in:1;
unsigned close_out:1;
unsigned no_stdin:1;
--
1.5.2.2.g081e
--
Martin Waitz
^ permalink raw reply related
* Re: [QGit PATCH] Remove most ASSERT warnings in Git::setStatus
From: Michael @ 2007-05-20 14:41 UTC (permalink / raw)
To: git; +Cc: Marco Costalba
In-Reply-To: <e5bfff550705200723i7b4e21ebi6a2c51d66659b388@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com>:
> So I rather would prefer something like
>
> line.section('\t', 0, 0).section(' ', -1, -1).left(1)
>
> because we could have more then one file separated by a tab, so
>
> line.section('\t', -2, -2).right(1)
>
> it seems to me a little bit fragile. What do you think?
You're right.
> Also I don't understand why you consider the right most (right(1)),
> instead of the left most character as the status.
Only because it was simpler AND because I didn't know it was wrong.
^ permalink raw reply
* Re: [QGit PATCH] Remove most ASSERT warnings in Git::setStatus
From: Marco Costalba @ 2007-05-20 14:23 UTC (permalink / raw)
To: Michael; +Cc: Git Mailing List
In-Reply-To: <200705201558.53546.barra_cuda@katamail.com>
On 5/20/07, Michael <barra_cuda@katamail.com> wrote:
> "Marco Costalba" <mcostalba@gmail.com>:
> > On 5/20/07, Michael <barra_cuda@katamail.com> wrote:
> > > Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
> > > ---
> > >
> > > ...is this correct?
> > >
> > > src/git_startup.cpp | 2 +-
> > > 1 files changed, 1 insertions(+), 1 deletions(-)
> > >
> > > diff --git a/src/git_startup.cpp b/src/git_startup.cpp
> > > index a99edba..17312f9 100644
> > > --- a/src/git_startup.cpp
> > > +++ b/src/git_startup.cpp
> > > @@ -329,7 +329,7 @@ void Git::parseDiffFormatLine(RevFile& rf, SCRef line, int parNum) {
> > >
> > > // TODO rename/copy is not supported for combined merges
> > > appendFileName(rf, line.section('\t', -1));
> > > - setStatus(rf, line.section(' ', 6, 6).left(1));
> > > + setStatus(rf, line.section('\t', -2, -2).right(1));
> > > rf.mergeParent.append(parNum);
> > > } else { // faster parsing in normal case
> > >
>From diff-format.txt we have that an output line is formatted this way:
------------------------------------------------
in-place edit :100644 100644 bcd1234... 0123456... M file0
copy-edit :100644 100644 abcd123... 1234567... C68 file1 file2
rename-edit :100644 100644 abcd123... 1234567... R86 file1 file3
create :000000 100644 0000000... 1234567... A file4
delete :100644 000000 1234567... 0000000... D file5
unmerged :000000 000000 0000000... 0000000... U file6
------------------------------------------------
That is, from the left to the right:
. a colon.
. mode for "src"; 000000 if creation or unmerged.
. a space.
. mode for "dst"; 000000 if deletion or unmerged.
. a space.
. sha1 for "src"; 0\{40\} if creation or unmerged.
. a space.
. sha1 for "dst"; 0\{40\} if creation, unmerged or "look at work tree".
. a space.
. status, followed by optional "score" number.
. a tab or a NUL when '-z' option is used.
. path for "src"
. a tab or a NUL when '-z' option is used; only exists for C or R.
. path for "dst"; only exists for C or R.
. an LF or a NUL when '-z' option is used, to terminate the record.
So I rather would prefer something like
line.section('\t', 0, 0).section(' ', -1, -1).left(1)
because we could have more then one file separated by a tab, so
line.section('\t', -2, -2).right(1)
it seems to me a little bit fragile. What do you think?
Also I don't understand why you consider the right most (right(1)),
instead of the left most character as the status.
Thanks
Marco
^ permalink raw reply
* Re: [QGit PATCH] Remove most ASSERT warnings in Git::setStatus
From: Michael @ 2007-05-20 14:08 UTC (permalink / raw)
To: git
In-Reply-To: <e5bfff550705200553q757c334el7aa5aed393052616@mail.gmail.com>
(sorry, dropped git ml)
"Marco Costalba" <mcostalba@gmail.com>:
> On 5/20/07, Michael <barra_cuda@katamail.com> wrote:
> > Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
> > ---
> >
> > ...is this correct?
> >
> > src/git_startup.cpp | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/src/git_startup.cpp b/src/git_startup.cpp
> > index a99edba..17312f9 100644
> > --- a/src/git_startup.cpp
> > +++ b/src/git_startup.cpp
> > @@ -329,7 +329,7 @@ void Git::parseDiffFormatLine(RevFile& rf, SCRef line, int parNum) {
> >
> > // TODO rename/copy is not supported for combined merges
> > appendFileName(rf, line.section('\t', -1));
> > - setStatus(rf, line.section(' ', 6, 6).left(1));
> > + setStatus(rf, line.section('\t', -2, -2).right(1));
> > rf.mergeParent.append(parNum);
> > } else { // faster parsing in normal case
> >
> > --
> > 1.5.1.2
> >
>
> Where do you see the ASSERT? could you link me to the test repository
> when you see that warnings?
>
> I would like to understand better what causes the warnings.
On the git repo:
rm .git/qgit_cache.dat
qgit origin/pu
then use arrows to go down to the first octopus merge, ie:
Merge branches 'jc/blame' and 'jc/diff' into pu
qgit prints:
ASSERT in Git::setStatus, unknown status <1>. 'MODIFIED' will be used instead.
ASSERT in Git::setStatus, unknown status <c>. 'MODIFIED' will be used instead.
on stderr.
That's because the lines considered in Git::setStatus are:
:::100644 100644 100644 100644 35864ed3c4afe01680bd5123fc28c35f5cf328e6 29243c6e8b49958ddcb08df0eb4223b14fd3e19f 16a5b9ac49c756492a7fd91fa49b84a3aee1f6b2 77ca8dcdfbcd6667b7f511306347c0d245ee4e2b MMM Makefile
:::100644 100644 100644 100644 0e6439b0ddaf317a6288ab4dd40ae8b9a41e9884 4204bc168c11fc7f8764e7d92e5935d2dc30c3bd cbab8ebecb4f3f13856b3be21409074dbcd3edda d1ff7f50a31d9647c26c1e2293957a1d719c9373 MMM cache.h
...which obviously do not have the right information ("M") in
line.section(' ', 6, 6).left(1)
but in
line.section('\t', -2, -2).right(1)
I thought this would trigger even with .git/qgit_cache.dat,
but I was wrong. (Anyway, I have a patch that adds an option
to make .git/qgit_cache.dat optional, but I don't think it
could be that useful. What do you think?)
If it still doesn't trigger for you, maybe I should post you
my qgitrc...
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.2
From: Thomas Glanzmann @ 2007-05-20 13:52 UTC (permalink / raw)
To: Dave Hanson; +Cc: Junio C Hamano, git
In-Reply-To: <9fb1551c0705200646m62b61efegbae76e6f17b06799@mail.gmail.com>
Hello,
> /usr/bin/ld: can't locate file for: -lexpat
make NO_EXPAT=1
or if you have libexpat.so installed on your system you should provide
it in the Linkerpath and Runtimepath.
Thomas
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.2
From: Dave Hanson @ 2007-05-20 13:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <9fb1551c0705200646m62b61efegbae76e6f17b06799@mail.gmail.com>
ps: This error occurred only on the PowerPC; the build on the Intel
Mac worked fine.
On 5/20/07, Dave Hanson <drh@drhanson.net> wrote:
> When I try building git 1.5.2 on Mac OS X 10.4.9, using "make
> prefix=/usr/local", it fails with:
>
> $ git checkout v1.5.2
> $ make prefix=/usr/local
> ...
> LINK git-http-fetch
> /usr/bin/ld: can't locate file for: -lexpat
> collect2: ld returned 1 exit status
> make: *** [git-http-fetch] Error 1
>
> But the build succeeds when I use:
>
> $ make configure; ./configure --prefix=/usr/local; make
>
> thanks,
> dave h
>
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.2
From: Dave Hanson @ 2007-05-20 13:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsl9rq2u2.fsf@assigned-by-dhcp.cox.net>
When I try building git 1.5.2 on Mac OS X 10.4.9, using "make
prefix=/usr/local", it fails with:
$ git checkout v1.5.2
$ make prefix=/usr/local
...
LINK git-http-fetch
/usr/bin/ld: can't locate file for: -lexpat
collect2: ld returned 1 exit status
make: *** [git-http-fetch] Error 1
But the build succeeds when I use:
$ make configure; ./configure --prefix=/usr/local; make
thanks,
dave h
^ permalink raw reply
* [PATCH] Use PATH_MAX instead of TEMPFILE_PATH_LEN
From: Fernando J. Pereda @ 2007-05-20 13:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
Signed-off-by: Fernando J. Pereda <ferdy@gentoo.org>
---
In Gentoo, packages compile with:
TMPDIR=/var/tmp/portage/dev-util/git-1.5.2/temp
so git_mkstemp couldn't fit the .diff_XXXXXX part and mkstemp was
returning EINVAL.
diff.c | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/diff.c b/diff.c
index 33297aa..b23e190 100644
--- a/diff.c
+++ b/diff.c
@@ -186,13 +186,11 @@ static const char *external_diff(void)
return external_diff_cmd;
}
-#define TEMPFILE_PATH_LEN 50
-
static struct diff_tempfile {
const char *name; /* filename external diff should read from */
char hex[41];
char mode[10];
- char tmp_path[TEMPFILE_PATH_LEN];
+ char tmp_path[PATH_MAX];
} diff_temp[2];
static int count_lines(const char *data, int size)
@@ -1561,7 +1559,7 @@ static void prep_temp_blob(struct diff_tempfile *temp,
{
int fd;
- fd = git_mkstemp(temp->tmp_path, TEMPFILE_PATH_LEN, ".diff_XXXXXX");
+ fd = git_mkstemp(temp->tmp_path, PATH_MAX, ".diff_XXXXXX");
if (fd < 0)
die("unable to create temp-file");
if (write_in_full(fd, blob, size) != size)
--
1.5.2
--
Fernando J. Pereda Garcimartín
20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4
^ permalink raw reply related
* Re: [QGit PATCH] Remove most ASSERT warnings in Git::setStatus
From: Marco Costalba @ 2007-05-20 12:53 UTC (permalink / raw)
To: Michael; +Cc: Git Mailing List
In-Reply-To: <200705201401.35991.barra_cuda@katamail.com>
On 5/20/07, Michael <barra_cuda@katamail.com> wrote:
> Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
> ---
>
> ...is this correct?
>
> src/git_startup.cpp | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/src/git_startup.cpp b/src/git_startup.cpp
> index a99edba..17312f9 100644
> --- a/src/git_startup.cpp
> +++ b/src/git_startup.cpp
> @@ -329,7 +329,7 @@ void Git::parseDiffFormatLine(RevFile& rf, SCRef line, int parNum) {
>
> // TODO rename/copy is not supported for combined merges
> appendFileName(rf, line.section('\t', -1));
> - setStatus(rf, line.section(' ', 6, 6).left(1));
> + setStatus(rf, line.section('\t', -2, -2).right(1));
> rf.mergeParent.append(parNum);
> } else { // faster parsing in normal case
>
> --
> 1.5.1.2
>
Where do you see the ASSERT? could you link me to the test repository
when you see that warnings?
I would like to understand better what causes the warnings.
Thanks
Marco
^ permalink raw reply
* Re: [PATCH] Teach 'git-apply --whitespace=strip' to remove empty lines at the end of file
From: Marco Costalba @ 2007-05-20 12:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vabvzoij8.fsf@assigned-by-dhcp.cox.net>
On 5/20/07, Junio C Hamano <junkio@cox.net> wrote:
>
> I was starting to suspect that I misunderstood what you were
> trying to do. I thought you were trying to avoid a patch that
> adds (one or more) blank line(s) at the end of the file, but is
> it that you do not want to have a hunk that adds more than one
> blank line anywhere? However, the comment "Only fragments that
> add lines at the bottom ends with '+' lines" suggests otherwise.
>
No, you understand right.
>
> Because we had the same mistake in our earlier code as you made
> in this patch, which assumed that a hunk that ends with '+' only
> apply at the end (and we still assume that by default), if you
> apply this with patch git-apply without --unidiff-zero option,
> you get an error. If you use the option this patch can be
> applied correctly.
>
Ok. This is take 3. It works correctly on standard patches and also on
u0 example that you gave above.
This patch is on top of git 1.5.2
Please check it.
builtin-apply.c | 34 ++++++++++++++++++++++++++++++++++
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/builtin-apply.c b/builtin-apply.c
index 0399743..6032f78 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -1671,6 +1671,7 @@ static int apply_one_fragment(struct buffer_desc *desc,
char *new = xmalloc(size);
const char *oldlines, *newlines;
int oldsize = 0, newsize = 0;
+ int trailing_added_lines = 0;
unsigned long leading, trailing;
int pos, lines;
@@ -1699,6 +1700,17 @@ static int apply_one_fragment(struct buffer_desc *desc,
else if (first == '+')
first = '-';
}
+ /*
+ * Count lines added at the end of the file.
+ * This is not enough to get things right in case of
+ * patches generated with --unified=0, but it's a
+ * useful upper bound.
+ */
+ if (first == '+')
+ trailing_added_lines++;
+ else
+ trailing_added_lines = 0;
+
switch (first) {
case '\n':
/* Newer GNU diff, empty context line */
@@ -1738,6 +1750,24 @@ static int apply_one_fragment(struct buffer_desc *desc,
newsize--;
}
+ if (new_whitespace == strip_whitespace) {
+ /* Any added empty lines is already cleaned-up here
+ * becuase of 'strip_whitespace' flag, so just count '\n'
+ */
+ int empty = 0;
+ while ( empty < trailing_added_lines
+ && newsize - empty > 0
+ && new[newsize - empty - 1] == '\n')
+ empty++;
+
+ if (empty < trailing_added_lines)
+ empty--;
+
+ /* these are the empty lines added at
+ * the end of the file, modulo u0 patches.
+ */
+ trailing_added_lines = empty;
+ }
oldlines = old;
newlines = new;
leading = frag->leading;
@@ -1770,6 +1800,10 @@ static int apply_one_fragment(struct buffer_desc *desc,
if (match_beginning && offset)
offset = -1;
if (offset >= 0) {
+
+ if (desc->size - oldsize - offset == 0) /* end of file? */
+ newsize -= trailing_added_lines;
+
int diff = newsize - oldsize;
unsigned long size = desc->size + diff;
unsigned long alloc = desc->alloc;
^ permalink raw reply related
* Re: [PATCH] branch: fix segfault when resolving an invalid HEAD
From: Jonas Fonseca @ 2007-05-20 12:44 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <20070520121917.GA18850@diku.dk>
On 5/20/07, Jonas Fonseca <fonseca@diku.dk> wrote:
> Caused by return value of resolve_ref being passed directly
> to xstrdup whereby the sanity checking was never reached.
While checking other usage of resolve_ref, this problem also occurs in
builtin-show-branch.c around line 695, however, the logic later in the
file seems to be more forgiving so I have no idea of how to patch it.
--
Jonas Fonseca
^ permalink raw reply
* Re: git-rebase (1.5.0.6) errors
From: Jan Hudec @ 2007-05-20 12:43 UTC (permalink / raw)
To: Ilpo Järvinen; +Cc: David Kastrup, Paolo Teti, git
In-Reply-To: <Pine.LNX.4.64.0705181640270.14736@kivilampi-30.cs.helsinki.fi>
[-- Attachment #1: Type: text/plain, Size: 1789 bytes --]
On Fri, May 18, 2007 at 17:02:56 +0300, Ilpo Järvinen wrote:
> David Kastrup <dak@gnu.org> wrote:
>
> > Only if size_t is a larger type than int (could be on x86-64 and alpha
> > architectures). Other than that, this comparison would work. Which
> > does not mean that this does not warrant fixing, but it is not
> > necessarily the cause of this problem.
>
> ...sizeof(size_t) == sizeof(int) should hold...
Really?
$ cat test.c
#include <stdio.h>
int main(void)
{
printf("sizeof(int) = %i\n", sizeof(int));
printf("sizeof(long) = %i\n", sizeof(long));
printf("sizeof(size_t) = %i\n", sizeof(size_t));
return 0;
}
$ gcc -otest test.c
$ ./test
sizeof(int) = 4
sizeof(long) = 8
sizeof(size_t) = 8
Hm, it does not seem that sizeof(size_t) == sizeof(int).
$ uname -m
x86_64
Yes, this is a 64-bit system.
Anyway, comparing it with -1 is ALWAYS OK in spite of this!
$ cat test2.c
#include <stdio.h>
int main(void)
{
size_t x = 0;
--x;
printf("x = 0x%lx\n", x);
printf("(x == -1) = %i\n", (x == -1));
return 0;
}
$ gcc -otest2 test2.c
$ ./test2
x = 0xffffffffffffffff
(x == -1) = 1
So at least with gcc that comparison is OK anyway. There has to be something
else that causes that problem.
> Anyway, if this has any relevance: I'm using non-utf system, and (as you
> see) my surname has ä... The system was recently upgraded to git 1.5+
> which started to complain also about a missing i18n.commitencoding,
> figured out that when I set it to utf8 (empty => defaults to it) and have
> signed-off line (with native non-utf ä), I get that error...
>
> ...and please, do not drop me from cc since I'm not subscribed...
>
> --
> i.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] Cross-reference the manpages for git-name-rev and git-describe (was Re: Commits gone AWOL, but not reported by git-fsck --unreachable)
From: Matthieu Moy @ 2007-05-20 12:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brian Gernhardt, Anand Kumria, git
In-Reply-To: <7vfy5sy91f.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Brian Gernhardt <benji@silverinsanity.com> writes:
>
>> On May 19, 2007, at 12:55 PM, Matthieu Moy wrote:
>>
>>> Brian Gernhardt <benji@silverinsanity.com> writes:
>>>
>>>> On May 19, 2007, at 12:08 PM, Matthieu Moy wrote:
>>>>
>>>>> The commit introducing it is
>>>>> 566842f62bdf1f16c2e94fb431445d2e6c0f3f0b,
>>>>> and I'd say it's in git 1.5.1:
>>>>>
>>>>> $ git-describe --tags 566842f62bdf1f16c2e94fb431445d2e6c0f3f0b
>>>>> v1.5.1-34-g566842f
>>>>
>>>> Actually, I think that means it's 34 commits *after* v1.5.1, not
>>>> before. It's in 1.5.2-rc0, but none of the 1.5.1.* series.
>>>
>>> You're right. Then, is there any easy way to ask git the oldest tag(s)
>>> that a commit is an ancestor of? In other words, which command should
>>> I have typed above?
>>
>> I did it the hard way with "git log v1.5.1..v.1.5.1.1", "..1.5.1.2",
>> and using grep to look for 566842. Anybody better at constructing
>> these incantations want to chime in?
>
> Perhaps "git-name-rev --refs='refs/tags/v*' $it"?
Yes, that's the one I was looking for (I knew it, but mixed name-rev
and describe).
How about this documentation patch then?
>From c280d7db974faacf388314e0396c9d50b40d55aa Mon Sep 17 00:00:00 2001
From: Matthieu Moy <Matthieu.Moy@imag.fr>
Date: Sun, 20 May 2007 14:33:44 +0200
Subject: [PATCH] Cross-reference the manpages for git-name-rev and git-describe
Both commands achieve a very similar goal.
---
Documentation/git-describe.txt | 4 ++++
Documentation/git-name-rev.txt | 4 ++++
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
index 47a583d..ff8383d 100644
--- a/Documentation/git-describe.txt
+++ b/Documentation/git-describe.txt
@@ -105,6 +105,10 @@ selected and output. Here fewest commits different is defined as
the number of commits which would be shown by "git log tag..input"
will be the smallest number of commits possible.
+See Also
+--------
+gitlink:git-name-rev[1] (very similar to git-describe, but searches
+the succesors of the commit)
Author
------
diff --git a/Documentation/git-name-rev.txt b/Documentation/git-name-rev.txt
index d6c8bf8..bdb0b27 100644
--- a/Documentation/git-name-rev.txt
+++ b/Documentation/git-name-rev.txt
@@ -57,6 +57,10 @@ Another nice thing you can do is:
% git log | git name-rev --stdin
------------
+See Also
+--------
+gitlink:git-describe[1] (very similar to git-name-rev, but searches
+the ancestors of the commit)
Author
------
--
1.5.2.rc3.32.ga3b1
--
Matthieu
^ permalink raw reply related
* [PATCH] branch: fix segfault when resolving an invalid HEAD
From: Jonas Fonseca @ 2007-05-20 12:19 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Caused by return value of resolve_ref being passed directly
to xstrdup whereby the sanity checking was never reached.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
builtin-branch.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
Discovered while renaming a ref from "a/b" to "a" while redoing some
changes. After a `git push --all`, `git branch` in the remote repo
segfaulted, since its HEAD was still pointing to "a/b".
diff --git a/builtin-branch.c b/builtin-branch.c
index 6bd5843..a5b6bbe 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -623,9 +623,10 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
(rename && force_create))
usage(builtin_branch_usage);
- head = xstrdup(resolve_ref("HEAD", head_sha1, 0, NULL));
+ head = resolve_ref("HEAD", head_sha1, 0, NULL);
if (!head)
die("Failed to resolve HEAD as a valid ref.");
+ head = xstrdup(head);
if (!strcmp(head, "HEAD")) {
detached = 1;
}
--
1.5.2.rc3.800.ga489e-dirty
--
Jonas Fonseca
^ permalink raw reply related
* Re: Commit ID in exported Tar Ball
From: René Scharfe @ 2007-05-20 11:20 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Frank Lichtenheld, Johan Herland, git,
Thomas Glanzmann, Michael Gernoth
In-Reply-To: <20070520035752.GG3141@spearce.org>
Shawn O. Pearce schrieb:
> Junio C Hamano <junkio@cox.net> wrote:
>> René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
>>
>>> Something like the following patch? Since we're already embedding the
>>> commit ID in a comment, we might as well offer creating a synthetic file
>>> for it, too, if that solves a user's problem that might be difficult to
>>> work around otherwise.
>
> What about being able to get the output of git-describe embedded
> into an archive file? Doesn't git.git do that in its Makefile? ;-)
>
> git-describe is more human-friendly than a SHA-1...
Yes, and the Makefile does even more than that: it adds a version file,
a spec file and another version file for git-gui.
The first two are probably useful for most projects that actually do
versioned releases. We could have a simple parser that reads a
template, replaces @@VERSION@@ with a git-describe output string and
adds the result as a synthetic file to the archive. It's not exactly
trivial -- e.g., how to specify git-describe options, template file and
synthetic name, all in one command line parameter? -- but it's doable.
I'm not sure how the git-gui version file fits in. I guess it's just a
special case and doesn't need git-archive support?
René
^ permalink raw reply
* Re: Commit ID in exported Tar Ball
From: René Scharfe @ 2007-05-20 11:20 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Junio C Hamano, Frank Lichtenheld, Johan Herland, git,
Thomas Glanzmann, Michael Gernoth
In-Reply-To: <20070520035752.GG3141@spearce.org>
Shawn O. Pearce schrieb:
> Junio C Hamano <junkio@cox.net> wrote:
>> René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
>>
>>> Something like the following patch? Since we're already embedding the
>>> commit ID in a comment, we might as well offer creating a synthetic file
>>> for it, too, if that solves a user's problem that might be difficult to
>>> work around otherwise.
>
> What about being able to get the output of git-describe embedded
> into an archive file? Doesn't git.git do that in its Makefile? ;-)
>
> git-describe is more human-friendly than a SHA-1...
Yes, and the Makefile does even more than that: it adds a version file,
a spec file and another version file for git-gui.
The first two are probably useful for most projects that actually do
versioned releases. We could have a simple parser that reads a
template, replaces @@VERSION@@ with a git-describe output string and
adds the result as a synthetic file to the archive. It's not exactly
trivial -- e.g., how to specify git-describe options, template file and
synthetic name, all in one command line parameter? -- but it's doable.
I'm not sure how the git-gui version file fits in. I guess it's just a
special case and doesn't need git-archive support?
René
^ permalink raw reply
* Re: Commit ID in exported Tar Ball
From: René Scharfe @ 2007-05-20 11:20 UTC (permalink / raw)
To: Junio C Hamano
Cc: Frank Lichtenheld, Johan Herland, git, Thomas Glanzmann,
Michael Gernoth
In-Reply-To: <464F932D.6040509@lsrfire.ath.cx>
Turns out a matcher for the kind of pathspecs used in git-archive
is much easier to write than I thought. :-)
This is just a progress note and not for inclusion, yet -- Shawn has
a good point suggesting git-describe output to be used instead of
bare commit IDs.
Documentation/git-archive.txt | 4 +++
archive-tar.c | 7 ++++++
archive-zip.c | 7 ++++++
archive.h | 1 +
builtin-archive.c | 44 +++++++++++++++++++++++++++++++++++++++++
5 files changed, 63 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-archive.txt b/Documentation/git-archive.txt
index 721e035..7016d1e 100644
--- a/Documentation/git-archive.txt
+++ b/Documentation/git-archive.txt
@@ -43,6 +43,10 @@ OPTIONS
--prefix=<prefix>/::
Prepend <prefix>/ to each filename in the archive.
+--commit-id-file=<filename>::
+ Adds a file to the archive containing the commit ID. This option
+ is can only be used if <tree-ish> references a commit or tag.
+
<extra>::
This can be any options that the archiver backend understand.
See next section.
diff --git a/archive-tar.c b/archive-tar.c
index 33e7657..555850a 100644
--- a/archive-tar.c
+++ b/archive-tar.c
@@ -319,6 +319,13 @@ int write_tar_archive(struct archiver_args *args)
}
read_tree_recursive(args->tree, args->base, plen, 0,
args->pathspec, write_tar_entry);
+ if (args->commit_sha1 && args->commit_sha1_file) {
+ unsigned char fake_sha1[20];
+ pretend_sha1_file(sha1_to_hex(args->commit_sha1), 40,
+ OBJ_BLOB, fake_sha1);
+ write_tar_entry(fake_sha1, args->base, plen,
+ args->commit_sha1_file, 0100666, 0);
+ }
write_trailer();
return 0;
diff --git a/archive-zip.c b/archive-zip.c
index 3cbf6bb..88c5dfa 100644
--- a/archive-zip.c
+++ b/archive-zip.c
@@ -328,6 +328,13 @@ int write_zip_archive(struct archiver_args *args)
}
read_tree_recursive(args->tree, args->base, plen, 0,
args->pathspec, write_zip_entry);
+ if (args->commit_sha1 && args->commit_sha1_file) {
+ unsigned char fake_sha1[20];
+ pretend_sha1_file(sha1_to_hex(args->commit_sha1), 40,
+ OBJ_BLOB, fake_sha1);
+ write_zip_entry(fake_sha1, args->base, plen,
+ args->commit_sha1_file, 0100666, 0);
+ }
write_zip_trailer(args->commit_sha1);
free(zip_dir);
diff --git a/archive.h b/archive.h
index 6838dc7..020f82f 100644
--- a/archive.h
+++ b/archive.h
@@ -8,6 +8,7 @@ struct archiver_args {
const char *base;
struct tree *tree;
const unsigned char *commit_sha1;
+ const char *commit_sha1_file;
time_t time;
const char **pathspec;
unsigned int verbose : 1;
diff --git a/builtin-archive.c b/builtin-archive.c
index 7f4e409..1fe4d47 100644
--- a/builtin-archive.c
+++ b/builtin-archive.c
@@ -151,6 +151,7 @@ int parse_archive_args(int argc, const char **argv, struct archiver *ar)
int extra_argc = 0;
const char *format = "tar";
const char *base = "";
+ const char *commit_sha1_file = NULL;
int verbose = 0;
int i;
@@ -174,6 +175,10 @@ int parse_archive_args(int argc, const char **argv, struct archiver *ar)
base = arg + 9;
continue;
}
+ if (!prefixcmp(arg, "--commit-id-file=")) {
+ commit_sha1_file = arg + 17;
+ continue;
+ }
if (!strcmp(arg, "--")) {
i++;
break;
@@ -192,6 +197,11 @@ int parse_archive_args(int argc, const char **argv, struct archiver *ar)
usage(archive_usage);
if (init_archiver(format, ar) < 0)
die("Unknown archive format '%s'", format);
+ if (commit_sha1_file) {
+ size_t namelen = strlen(commit_sha1_file);
+ if (namelen == 0 || commit_sha1_file[namelen - 1] == '/')
+ die("Invalid commit ID file name: %s", commit_sha1_file);
+ }
if (extra_argc) {
if (!ar->parse_extra)
@@ -201,6 +211,7 @@ int parse_archive_args(int argc, const char **argv, struct archiver *ar)
}
ar->args.verbose = verbose;
ar->args.base = base;
+ ar->args.commit_sha1_file = commit_sha1_file;
return i;
}
@@ -236,6 +247,32 @@ static const char *extract_remote_arg(int *ac, const char **av)
return remote;
}
+static int is_path_in_spec(const struct archiver_args *args, const char *path)
+{
+ unsigned char sha1[20];
+ unsigned int mode;
+ const char *match;
+ const char **pathspec = args->pathspec;
+
+ if (get_tree_entry(args->tree->object.sha1, path, sha1, &mode))
+ return 0;
+ if (!pathspec)
+ return 1;
+ while ((match = *pathspec++) != NULL) {
+ size_t matchlen = strlen(match);
+ if (matchlen == 0)
+ return 1;
+ if (match[matchlen - 1] == '/') {
+ if (!prefixcmp(path, match))
+ return 1;
+ } else {
+ if (!strcmp(path, match))
+ return 1;
+ }
+ }
+ return 0;
+}
+
int cmd_archive(int argc, const char **argv, const char *prefix)
{
struct archiver ar;
@@ -257,5 +294,12 @@ int cmd_archive(int argc, const char **argv, const char *prefix)
parse_treeish_arg(argv, &ar.args, prefix);
parse_pathspec_arg(argv + 1, &ar.args);
+ if (ar.args.commit_sha1_file) {
+ if (is_path_in_spec(&ar.args, ar.args.commit_sha1_file))
+ die("Commit ID file name already exists in archive.");
+ if (!ar.args.commit_sha1)
+ die("Need a commit to use --commit-id-file, and not a tree.");
+ }
+
return ar.write_archive(&ar.args);
}
^ permalink raw reply related
* Re: [PATCH 3/3] Use stringbuf to clean up some string handling code.
From: Timo Sirainen @ 2007-05-20 11:19 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20070520095623.GA3106@steel.home>
[-- Attachment #1: Type: text/plain, Size: 1477 bytes --]
On Sun, 2007-05-20 at 11:56 +0200, Alex Riesen wrote:
> Timo Sirainen, Sun, May 20, 2007 04:25:42 +0200:
> > ---
> > commit.c | 30 +++++++++++++-----------------
> > local-fetch.c | 34 ++++++++++++++++------------------
> > 2 files changed, 29 insertions(+), 35 deletions(-)
>
> I find it hard to believe that it actually was a cleanup.
>
> It is a nicer code, but... it is bigger, heavier on stack, and it does
> not actually fix anything.
>
> In my experience, such changes are seldom worth the effort. It may be
> a nice code (and I actually like str.[hc]), but its use _must_ be
> justified. I.e. it must simplify a complex formatting routine, or fix
> a bug, which otherwise would be too hard or ugly to fix. It is
> definitely not the case in this patch.
In my own projects security is the highest priority and it justifies
pretty much all changes. I've done several large changes that change
thousands of lines of code just because it makes it a bit easier to
verify the code's safety/correctness.
I realize that other projects may not want to use all of the tricks that
I'm using in my C code (type safe dynamic arrays, type safe context
pointer in callback functions, etc.), but I was hoping that at least the
libc string handling functions would never be used in a large project
anymore. Using them makes it extremely time consuming to verify the
code's safety, and at least I try to avoid software if I can't do that.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Teach 'git-apply --whitespace=strip' to remove empty lines at the end of file
From: Junio C Hamano @ 2007-05-20 11:12 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List
In-Reply-To: <e5bfff550705200334pef694cn1a7842c23e2672f5@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com> writes:
> On 5/20/07, Junio C Hamano <junkio@cox.net> wrote:
>> "Marco Costalba" <mcostalba@gmail.com> writes:
>>
>> > Signed-off-by: Marco Costalba <mcostalba@gmail.com>
>> > ---
>> >
>> > This one seems to pass all the tests.
>>
>> I think this happens to work because you are not feeding -u0
>> patch; if you have more than one context, then a hunk that ends
>> with + line is guaranteed to apply only at the end, With a
>> diff prepared with -u0, that is not true anymore, is it?
>
> I don't know much about this -u0 thing, could you please point me to
> an example so I can try to fix also this case?
I was starting to suspect that I misunderstood what you were
trying to do. I thought you were trying to avoid a patch that
adds (one or more) blank line(s) at the end of the file, but is
it that you do not want to have a hunk that adds more than one
blank line anywhere? However, the comment "Only fragments that
add lines at the bottom ends with '+' lines" suggests otherwise.
But.
If you start with this file:
$ git init
$ cat >AAA <<\EOF
a
b
c
d
EOF
$ git add AAA
and modify it by adding three blank lines between b and c, like
this:
$ cat >AAA <<\EOF
a
b
c
d
EOF
If you say "give me zero lines of context" (again, I think use
of -u0 is insane, but we got complaints in the past that we did
not get this right), you would get this:
$ git diff --unified=0 >P.diff
$ cat P.diff
diff --git a/AAA b/AAA
index d68dd40..8410b89 100644
--- a/AAA
+++ b/AAA
@@ -2,0 +3,3 @@ b
+
+
+
Because we had the same mistake in our earlier code as you made
in this patch, which assumed that a hunk that ends with '+' only
apply at the end (and we still assume that by default), if you
apply this with patch git-apply without --unidiff-zero option,
you get an error. If you use the option this patch can be
applied correctly.
$ git checkout -- AAA ;# to go back to the original a/b/c/d
$ git apply --unidiff-zero P.diff
Now, with --unidiff-zero option, I think your patch will mistake
that this hunk adds _trailing_ blank lines, because it does not
see anything that comes after the '+'.
I think it should notice that it adds three trailing
blank lines and should reduce "new" to zero lines, but
somehow it does not seem to do so. You start with
newsize == 3 and do not allow (newsize-empty) to go
below 2, so you would get only 1 in empty, not 3, and
end up reducing this hunk by only one line.
Which may or may not be a bug, but that is besides the
point.
The point is that this hunk does not apply to the end of the
file, and I do not think you should even be attempting to reduce
"new" at all.
But the code to determine where in the dest buffer the hunk
applies to exists way after the point you patched (inside of the
for(;;) loop, where we have memmove and memcpy). The memmove is
to move away the later part of the file to make room if "new" is
larger than "old" (if the hunk deletes more than it adds, the
memmove would move the remainder up, otherwise down), and I
think that should be the place you would first decide if you are
applying at the end, and reduce "new" only if that is the case.
Am I misreading your patch?
^ permalink raw reply related
* Re: [PATCH] git-archive: recursive prefix directory creation
From: René Scharfe @ 2007-05-20 10:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vtzu8va12.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano schrieb:
> René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
>
>> Junio C Hamano schrieb:
>>> René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
>>>
>>>> Currently git-archive only adds a single directory entry for
>>>> prefixes, e.g. for --prefix=a/b/c/ only the directory a/b/c/
>>>> would be added to the archive, not a/ nor a/b/. While tar and
>>>> unzip don't seem to have a problem handling these missing
>>>> entries, their omission was not intended.
>>> Until we start tracking directories (we briefly discussed, and I
>>> think I agree with Linus that it should not be too painful), I'd
>>> rather keep the current behaviour which I feel is more consistent
>>> with what we really are doing.
>> Hmm, fair enough. I started out with a simple cleanup and then I
>> guess went a bit overboard with that overblown path walker. :-]
>
> Well, I take that back -- I did not realize you were primarily
> talking about the LEADING part of the path.
In any case, please don't apply this patch. I checked again, and it
turns out both tar and zip don't always add leading directories to
archives. So my "cleanup" only adds bloat. I'll try to find another
way to beautify the code.
René
^ 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