* Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.
From: Johannes Schindelin @ 2007-09-02 23:02 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Marius Storm-Olsen, Johannes Sixt, git
In-Reply-To: <200709022342.42733.robin.rosenberg.lists@dewire.com>
Hi,
On Sun, 2 Sep 2007, Robin Rosenberg wrote:
> You actually need admin privileges too, but I don't know any windows
> developer who hasn't got that.
Like almost every developer in the corporate world?
Fact is: this support of symlinks is ridiculous. Why not just admit it?
Ciao,
Dscho
^ permalink raw reply
* Re: gitk fails to parse git log output in 1.5.3
From: Junio C Hamano @ 2007-09-02 23:16 UTC (permalink / raw)
To: Jing Xue; +Cc: git
In-Reply-To: <20070902223128.GA19198@falcon.digizenstudio.com>
Jing Xue <jingxue@digizenstudio.com> writes:
> gitk shows an error "Can't parse git log output: {\x1b[33commit..." at
> startup and quits.
>
> Obviously it's because my git-log outputs in color mode. But the same
> happens (and git-log still outputs in colors) after I set color.pager=false.
>
> What am I missing?
This will quickly turn into an FAQ.
Please see:
http://thread.gmane.org/gmane.comp.version-control.git/57204
for details and a possible future plans. Making "diff.color =
true" to always color was a mistake, and if you have such a
configuration, it would break any script that reads from "git
log". In the meantime, do not do "diff.color = true" (or
"color.diff = true") in your configuration; say "auto" instead
of "true", and/or apply this patch.
---
gitk | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/gitk b/gitk
index 300fdce..9c21eff 100755
--- a/gitk
+++ b/gitk
@@ -93,6 +93,7 @@ proc start_rev_list {view} {
}
if {[catch {
set fd [open [concat | git log -z --pretty=raw $order --parents \
+ --no-color \
--boundary $viewargs($view) "--" $viewfiles($view)] r]
} err]} {
error_popup "Error executing git rev-list: $err"
^ permalink raw reply related
* Re: [ANNOUNCE] GIT 1.5.3
From: Sean @ 2007-09-02 23:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: H. Peter Anvin, David Kastrup, git, linux-kernel
In-Reply-To: <7v4picpvgq.fsf@gitster.siamese.dyndns.org>
On Sun, 02 Sep 2007 15:13:09 -0700
Junio C Hamano <gitster@pobox.com> wrote:
Hi Junio,
> For majority of general public, I thought the spec file _I_
> ship, along with RPM files _I_ build, are contrib status
> already. Don't distro people do their own RPM packages, instead
> of using what I placed on k.org?
Didn't know you used RPM yourself, so I guess this is just
a case of something slipping through rather than the spec file
needing a maintainer. Having said that, it seems odd that you
would say the spec file included with git is "contrib status
already". How can something be contrib status unless it
is in the contrib directory of Git?
> Assuming that we do not give the old git-p4import script
> packaged in "git-p4 package", would the following patch be all
> that is needed, or do we need other things in the spec file?
Given the comment from David, I suspect your patch is all
that's needed; hopefully Peter can give it a quick test.
Sean
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3
From: Junio C Hamano @ 2007-09-02 23:28 UTC (permalink / raw)
To: David Kågedal; +Cc: git
In-Reply-To: <87d4x0fzky.fsf@morpheus.local>
David Kågedal <davidk@lysator.liu.se> writes:
> David Kågedal <davidk@lysator.liu.se> writes:
>
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> GIT v1.5.3 Release Notes
>>> ========================
>>>
>>> Updates since v1.5.2
>>> --------------------
>>>
>>> * The commit walkers other than http are officially deprecated,
>>> but still supported for now.
>>
>> As I think I said before, this first bullet point makes no sense to
>> git users. Only hardcore git developers know what a "commit walker
>> is", and what commit walkers exist (other than html, obviously). How
>
> I'm not trying to make you even more confused. Make that "http",
> please. :-)
Unless you work extremely hard at it, you won't be using the
local and/or ssh walkers. The entry is really meant for
Porcelain writers (aka plumbing users).
It's a tricky balancing act. Not everybody is the end user who
is only interested in using Porcelain. The release note for a
new release somehow needs to mention changes that would affect
only plumbing users as well.
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3
From: Steven Grimm @ 2007-09-02 23:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Kågedal, git
In-Reply-To: <7vveasode8.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> It's a tricky balancing act. Not everybody is the end user who
> is only interested in using Porcelain. The release note for a
> new release somehow needs to mention changes that would affect
> only plumbing users as well.
>
No argument there, of course; it needs to be documented. But maybe not
as the very first item at the top of the release notes, which people
might expect to be organized in a "most user-visible first" order. I
usually expect to see general descriptions of new features and critical
bugfixes at the top of a program's release notes, with the option to
keep reading if I want the low-level details.
Barring that, or even in addition to that, would it make sense to have
separate "porcelain" and "plumbing" sections of the release notes?
Obviously some changes straddle the two, but there are a lot that are
pretty clear-cut one way or the other. Then end users can ignore the
plumbing section and porcelain writers can jump straight to it.
-Steve
^ permalink raw reply
* [PATCH] gitweb: Fix file name quoting in simplified out patch detection for --cc output
From: Jakub Narebski @ 2007-09-02 20:22 UTC (permalink / raw)
To: git
For the --cc (compressed combined) diff output there can be patches
which are simple and got simplified out, so there is no patch
corresponding to raw output line.
Fix detection of of such simplified out patches: file name in git diff
header for --cc diff can be quoted; unquote it.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This patch depends _textually_ on the just send
"gitweb: Fix and simplify "split patch" detection"
patch, although it is _conceptually_ independent.
The commit message could be better...
gitweb/gitweb.perl | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 8c1e02c..5d424e5 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3140,8 +3140,8 @@ sub git_patchset_body {
# compact combined diff output can have some patches skipped
# find which patch (using pathname of result) we are at now
my $to_name;
- if ($patch_line =~ m!^diff --cc "?(.*)"?$!) {
- $to_name = $1;
+ if ($patch_line =~ m!^diff --cc ("?.*"?)$!) {
+ $to_name = unquote($1);
}
do {
--
1.5.2.5
^ permalink raw reply related
* [PATCH] gitweb: Fix and simplify "split patch" detection
From: Jakub Narebski @ 2007-09-02 20:18 UTC (permalink / raw)
To: git; +Cc: Yann Dirson, Petr Baudis, Junio C Hamano
There are some cases when one line from "raw" git-diff output (raw format)
corresponds to more than one patch in the patchset git-diff output; we
call this situation "split patch". Current code misdetected subsequent
patches (for different files) with the same pre-image and post-image
as fragments of "split patch", leading to mislabeled from-file/to-file
diff header etc.
We could parse from_file and to_file (if to_file exists) from the "git
diff header" in the patch, i.e. from the "^diff" line in patchset, and
consider patch "split" or "continued" if not only pre-image and
post-image (from_id and to_id) matches, but only when also from_file
and to_file (if it exists) matches. This has the advantage of being
generic, not depending on details of git diff output formatting, and
how patch output relates to raw diff output, but it adds yet another
complication.
Note: both from_name and to_name can be quoted and contain spaces;
their separation is nontrivial.
Alternate solution, which we did chose, is to check when git splits
patches, and do not check if parsed info from current patch corresponds
to current or next raw diff format output line. Git splits patches
only for 'T' (typechange) status filepair, and there always two patches
corresponding to one raw diff line.
And we can get rid of buffering extended diff header and parsing it,
This simplifies git_patchset_body, making it easier to understand and
maintain. At the other hand it fixes gitweb to git diff output details.
While at it we added 'status_str' to diffinfo output, which stores
status (also for merge commit) as a string. This allows for easy
checking if there is given status among all for merge commit, e.g.
$diffinfo->{'status_str'} =~ /T/
There are no users of from_ids_eq subroutine.
Noticed-by: Yann Dirson <ydirson@altern.org>
Diagnosed-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This is post 1.5.3 resend of the patch
Message-Id: <200708290208.08191.jnareb@gmail.com>
posted in the "[BUG] gitweb on repo.or.cz shows buggy commitdiff"
thread.
I'm a tiny little bit ambivalent about this patch: on one hand it
fixes the bug and simplifies git_patchset_body code making it easier
to maintain, on the other hand it ties patch handling code in gitweb
with the details of git-diff patch vs. raw output format.
gitweb/gitweb.perl | 63 +++++++++++++++++++--------------------------------
1 files changed, 24 insertions(+), 39 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index b2bae1b..8c1e02c 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1963,7 +1963,7 @@ sub parse_difftree_raw_line {
$res{'to_mode'} = $2;
$res{'from_id'} = $3;
$res{'to_id'} = $4;
- $res{'status'} = $5;
+ $res{'status'} = $res{'status_str'} = $5;
$res{'similarity'} = $6;
if ($res{'status'} eq 'R' || $res{'status'} eq 'C') { # renamed or copied
($res{'from_file'}, $res{'to_file'}) = map { unquote($_) } split("\t", $7);
@@ -1979,6 +1979,7 @@ sub parse_difftree_raw_line {
$res{'to_mode'} = pop @{$res{'from_mode'}};
$res{'from_id'} = [ split(' ', $3) ];
$res{'to_id'} = pop @{$res{'from_id'}};
+ $res{'status_str'} = $4;
$res{'status'} = [ split('', $4) ];
$res{'to_file'} = unquote($5);
}
@@ -3112,6 +3113,7 @@ sub git_patchset_body {
my $patch_line;
my $diffinfo;
my (%from, %to);
+ my $patches_per_difftree_line = 1;
print "<div class=\"patchset\">\n";
@@ -3124,42 +3126,13 @@ sub git_patchset_body {
PATCH:
while ($patch_line) {
- my @diff_header;
- my ($from_id, $to_id);
-
- # git diff header
- #assert($patch_line =~ m/^diff /) if DEBUG;
- #assert($patch_line !~ m!$/$!) if DEBUG; # is chomp-ed
- $patch_number++;
- push @diff_header, $patch_line;
-
- # extended diff header
- EXTENDED_HEADER:
- while ($patch_line = <$fd>) {
- chomp $patch_line;
-
- last EXTENDED_HEADER if ($patch_line =~ m/^--- |^diff /);
-
- if ($patch_line =~ m/^index ([0-9a-fA-F]{40})..([0-9a-fA-F]{40})/) {
- $from_id = $1;
- $to_id = $2;
- } elsif ($patch_line =~ m/^index ((?:[0-9a-fA-F]{40},)+[0-9a-fA-F]{40})..([0-9a-fA-F]{40})/) {
- $from_id = [ split(',', $1) ];
- $to_id = $2;
- }
-
- push @diff_header, $patch_line;
- }
- my $last_patch_line = $patch_line;
# check if current patch belong to current raw line
# and parse raw git-diff line if needed
- if (defined $diffinfo &&
- defined $from_id && defined $to_id &&
- from_ids_eq($diffinfo->{'from_id'}, $from_id) &&
- $diffinfo->{'to_id'} eq $to_id) {
+ if ($patches_per_difftree_line > 1) {
# this is continuation of a split patch
print "<div class=\"patch cont\">\n";
+ $patches_per_difftree_line--;
} else {
# advance raw git-diff output if needed
$patch_idx++ if defined $diffinfo;
@@ -3167,7 +3140,7 @@ sub git_patchset_body {
# compact combined diff output can have some patches skipped
# find which patch (using pathname of result) we are at now
my $to_name;
- if ($diff_header[0] =~ m!^diff --cc "?(.*)"?$!) {
+ if ($patch_line =~ m!^diff --cc "?(.*)"?$!) {
$to_name = $1;
}
@@ -3191,6 +3164,7 @@ sub git_patchset_body {
}
} until (!defined $to_name || $to_name eq $diffinfo->{'to_file'} ||
$patch_idx > $#$difftree);
+
# modifies %from, %to hashes
parse_from_to_diffinfo($diffinfo, \%from, \%to, @hash_parents);
if ($diffinfo->{'nparents'}) {
@@ -3232,32 +3206,43 @@ sub git_patchset_body {
# this is first patch for raw difftree line with $patch_idx index
# we index @$difftree array from 0, but number patches from 1
print "<div class=\"patch\" id=\"patch". ($patch_idx+1) ."\">\n";
+
+ # typechange diff with 'T' status has two patches per one raw line
+ if ($diffinfo->{'status_str'} =~ /T/) {
+ $patches_per_difftree_line = 2;
+ }
}
+ # git diff header
+ #assert($patch_line =~ m/^diff /) if DEBUG;
+ #assert($patch_line !~ m!$/$!) if DEBUG; # is chomp-ed
+ $patch_number++;
# print "git diff" header
- $patch_line = shift @diff_header;
print format_git_diff_header_line($patch_line, $diffinfo,
\%from, \%to);
# print extended diff header
- print "<div class=\"diff extended_header\">\n" if (@diff_header > 0);
+ print "<div class=\"diff extended_header\">\n";
EXTENDED_HEADER:
- foreach $patch_line (@diff_header) {
+ while ($patch_line = <$fd>) {
+ chomp $patch_line;
+
+ last EXTENDED_HEADER if ($patch_line =~ m/^--- |^diff /);
+
print format_extended_diff_header_line($patch_line, $diffinfo,
\%from, \%to);
}
- print "</div>\n" if (@diff_header > 0); # class="diff extended_header"
+ print "</div>\n"; # class="diff extended_header"
# from-file/to-file diff header
- $patch_line = $last_patch_line;
if (! $patch_line) {
print "</div>\n"; # class="patch"
last PATCH;
}
next PATCH if ($patch_line =~ m/^diff /);
#assert($patch_line =~ m/^---/) if DEBUG;
- #assert($patch_line eq $last_patch_line) if DEBUG;
+ my $last_patch_line = $patch_line;
$patch_line = <$fd>;
chomp $patch_line;
#assert($patch_line =~ m/^\+\+\+/) if DEBUG;
--
1.5.2.5
^ permalink raw reply related
* [StGit PATCH] Allow "stg add" when we have no stack
From: Karl Hasselström @ 2007-09-02 23:59 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
There's simply no reason not to allow this. It behaves just like
git-add, so it's well-defined enough.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
stgit/commands/add.py | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/stgit/commands/add.py b/stgit/commands/add.py
index 7f5a0b3..fc9c5a7 100644
--- a/stgit/commands/add.py
+++ b/stgit/commands/add.py
@@ -40,7 +40,4 @@ def func(parser, options, args):
if len(args) < 1:
parser.error('incorrect number of arguments')
- if not crt_series.get_current():
- raise CmdException, 'No patches applied'
-
git.add(args)
^ permalink raw reply related
* [StGit PATCH] Test "stg status" more thoroughly
From: Karl Hasselström @ 2007-09-03 0:00 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
t/t0002-status.sh | 114 ++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 112 insertions(+), 2 deletions(-)
diff --git a/t/t0002-status.sh b/t/t0002-status.sh
index c088d56..ce3b688 100755
--- a/t/t0002-status.sh
+++ b/t/t0002-status.sh
@@ -8,8 +8,118 @@ test_description='Basic stg status
Test that "stg status" works.'
. ./test-lib.sh
+stg init
-test_expect_success 'Run status on empty' \
- 'stg status'
+# Ignore our own output files.
+cat > .git/info/exclude <<EOF
+/expected.txt
+/output.txt
+EOF
+
+cat > expected.txt <<EOF
+EOF
+test_expect_success 'Run status on empty' '
+ stg status > output.txt &&
+ diff -u expected.txt output.txt
+'
+
+cat > expected.txt <<EOF
+? foo
+EOF
+test_expect_success 'Status with an untracked file' '
+ touch foo &&
+ stg status > output.txt &&
+ diff -u expected.txt output.txt
+'
+rm -f foo
+
+cat > expected.txt <<EOF
+EOF
+test_expect_success 'Status with an empty directory' '
+ mkdir foo &&
+ stg status > output.txt &&
+ diff -u expected.txt output.txt
+'
+
+cat > expected.txt <<EOF
+? foo/
+EOF
+test_expect_success 'Status with an untracked file in a subdir' '
+ touch foo/bar &&
+ stg status > output.txt &&
+ diff -u expected.txt output.txt
+'
+
+cat > expected.txt <<EOF
+A foo/bar
+EOF
+test_expect_success 'Status with an added file' '
+ stg add foo &&
+ stg status > output.txt &&
+ diff -u expected.txt output.txt
+'
+
+cat > expected.txt <<EOF
+EOF
+test_expect_success 'Status after refresh' '
+ stg new -m "first patch" &&
+ stg refresh &&
+ stg status > output.txt &&
+ diff -u expected.txt output.txt
+'
+
+cat > expected.txt <<EOF
+M foo/bar
+EOF
+test_expect_success 'Status after modification' '
+ echo "wee" >> foo/bar &&
+ stg status > output.txt &&
+ diff -u expected.txt output.txt
+'
+
+cat > expected.txt <<EOF
+EOF
+test_expect_success 'Status after refresh' '
+ stg new -m "second patch" && stg refresh &&
+ stg status > output.txt &&
+ diff -u expected.txt output.txt
+'
+
+test_expect_success 'Make a conflicting patch' '
+ stg pop &&
+ stg new -m "third patch" &&
+ echo "woo" >> foo/bar &&
+ stg refresh
+'
+
+cat > expected.txt <<EOF
+? foo/bar.ancestor
+? foo/bar.current
+? foo/bar.patched
+C foo/bar
+EOF
+test_expect_success 'Status after conflicting push' '
+ ! stg push &&
+ stg status > output.txt &&
+ diff -u expected.txt output.txt
+'
+
+cat > expected.txt <<EOF
+M foo/bar
+EOF
+test_expect_success 'Status after resolving the push' '
+ stg resolved -a &&
+ stg status > output.txt &&
+ diff -u expected.txt output.txt
+'
+
+cat > expected.txt <<EOF
+D foo/bar
+EOF
+test_expect_success 'Status after deleting a file' '
+ rm foo/bar &&
+ stg status > output.txt &&
+ diff -u expected.txt output.txt
+'
test_done
^ permalink raw reply related
* Re: [ANNOUNCE] GIT 1.5.3
From: Junio C Hamano @ 2007-09-03 0:03 UTC (permalink / raw)
To: Steven Grimm; +Cc: David Kågedal, git
In-Reply-To: <46DB4903.6060100@midwinter.com>
Steven Grimm <koreth@midwinter.com> writes:
> No argument there, of course; it needs to be documented. But maybe not
> as the very first item at the top of the release notes, which people
> might expect to be organized in a "most user-visible first" order. I
> usually expect to see general descriptions of new features and
> critical bugfixes at the top of a program's release notes, with the
> option to keep reading if I want the low-level details.
>
> Barring that, or even in addition to that, would it make sense to have
> separate "porcelain" and "plumbing" sections of the release notes?
I think that makes sense, as "most user-visible first" order
will be different what kind of "user" you are.
^ permalink raw reply
* [StGit PATCH] Fix "stg resolved" to work with new conflict representation
From: Karl Hasselström @ 2007-09-03 0:04 UTC (permalink / raw)
To: Catalin Marinas, David Kågedal; +Cc: git
The actual resolving is done by calling the same subroutine as "git
add".
Instead of using existing *.{ancestor,current,patches} files, the
interactive merge has to create them from the index contents, and
delete them afterwards.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
This goes on top of David's conflict series.
stgit/commands/common.py | 16 ++-----
stgit/commands/resolved.py | 19 ++------
stgit/gitmergeonefile.py | 99 ++++++++++++++++++++++++--------------------
3 files changed, 62 insertions(+), 72 deletions(-)
diff --git a/stgit/commands/common.py b/stgit/commands/common.py
index ad94caf..f31c09b 100644
--- a/stgit/commands/common.py
+++ b/stgit/commands/common.py
@@ -137,18 +137,10 @@ def print_crt_patch(branch = None):
def resolved(filename, reset = None):
if reset:
- reset_file = filename + file_extensions()[reset]
- if os.path.isfile(reset_file):
- if os.path.isfile(filename):
- os.remove(filename)
- os.rename(reset_file, filename)
-
- git.update_cache([filename], force = True)
-
- for ext in file_extensions().values():
- fn = filename + ext
- if os.path.isfile(fn):
- os.remove(fn)
+ stage = {'ancestor': 1, 'current': 2, 'patched': 3}[reset]
+ Run('git-checkout-index', '--no-create', '--stage=%d' % stage, '--',
+ filename).no_output()
+ git.add([filename])
def resolved_all(reset = None):
conflicts = git.get_conflicts()
diff --git a/stgit/commands/resolved.py b/stgit/commands/resolved.py
index 1130641..de38737 100644
--- a/stgit/commands/resolved.py
+++ b/stgit/commands/resolved.py
@@ -73,18 +73,7 @@ def func(parser, options, args):
raise CmdException, 'No conflicts for "%s"' % filename
# resolved
- try:
- for filename in files:
- if options.interactive:
- interactive_merge(filename)
- resolved(filename, options.reset)
- del conflicts[conflicts.index(filename)]
- finally:
- # save or remove the conflicts file. Needs a finally clause to
- # ensure that already solved conflicts are marked
- if conflicts == []:
- os.remove(os.path.join(basedir.get(), 'conflicts'))
- else:
- f = file(os.path.join(basedir.get(), 'conflicts'), 'w+')
- f.writelines([line + '\n' for line in conflicts])
- f.close()
+ for filename in files:
+ if options.interactive:
+ interactive_merge(filename)
+ resolved(filename, options.reset)
diff --git a/stgit/gitmergeonefile.py b/stgit/gitmergeonefile.py
index 2aa5ef8..e9bdebb 100644
--- a/stgit/gitmergeonefile.py
+++ b/stgit/gitmergeonefile.py
@@ -96,51 +96,60 @@ def __conflict(path):
def interactive_merge(filename):
- """Run the interactive merger on the given file. Note that the
- index should not have any conflicts.
- """
- extensions = file_extensions()
-
- ancestor = filename + extensions['ancestor']
- current = filename + extensions['current']
- patched = filename + extensions['patched']
-
- if os.path.isfile(ancestor):
- three_way = True
- files_dict = {'branch1': current,
- 'ancestor': ancestor,
- 'branch2': patched,
- 'output': filename}
- imerger = config.get('stgit.i3merge')
- else:
- three_way = False
- files_dict = {'branch1': current,
- 'branch2': patched,
- 'output': filename}
- imerger = config.get('stgit.i2merge')
-
- if not imerger:
- raise GitMergeException, 'No interactive merge command configured'
-
- # check whether we have all the files for the merge
- for fn in [filename, current, patched]:
- if not os.path.isfile(fn):
- raise GitMergeException, \
- 'Cannot run the interactive merge: "%s" missing' % fn
-
- mtime = os.path.getmtime(filename)
-
- out.info('Trying the interactive %s merge'
- % (three_way and 'three-way' or 'two-way'))
-
- err = os.system(imerger % files_dict)
- if err != 0:
- raise GitMergeException, 'The interactive merge failed: %d' % err
- if not os.path.isfile(filename):
- raise GitMergeException, 'The "%s" file is missing' % filename
- if mtime == os.path.getmtime(filename):
- raise GitMergeException, 'The "%s" file was not modified' % filename
-
+ """Run the interactive merger on the given file."""
+ try:
+ extensions = file_extensions()
+ line = MRun('git-checkout-index', '--stage=all', '--', filename
+ ).output_one_line()
+ stages, path = line.split('\t')
+ stages = dict(zip(['ancestor', 'current', 'patched'],
+ stages.split(' ')))
+ for stage, fn in stages.iteritems():
+ if stages[stage] == '.':
+ stages[stage] = None
+ else:
+ newname = filename + extensions[stage]
+ if not os.path.exists(newname):
+ os.rename(stages[stage], newname)
+ stages[stage] = newname
+
+ # Check whether we have all the files for the merge.
+ if not (stages['current'] and stages['patched']):
+ raise GitMergeException('Cannot run the interactive merge')
+
+ if stages['ancestor']:
+ three_way = True
+ files_dict = {'branch1': stages['current'],
+ 'ancestor': stages['ancestor'],
+ 'branch2': stages['patched'],
+ 'output': filename}
+ imerger = config.get('stgit.i3merge')
+ else:
+ three_way = False
+ files_dict = {'branch1': stages['current'],
+ 'branch2': stages['patched'],
+ 'output': filename}
+ imerger = config.get('stgit.i2merge')
+
+ if not imerger:
+ raise GitMergeException, 'No interactive merge command configured'
+
+ mtime = os.path.getmtime(filename)
+
+ out.start('Trying the interactive %s merge'
+ % (three_way and 'three-way' or 'two-way'))
+ err = os.system(imerger % files_dict)
+ out.done()
+ if err != 0:
+ raise GitMergeException, 'The interactive merge failed'
+ if not os.path.isfile(filename):
+ raise GitMergeException, 'The "%s" file is missing' % filename
+ if mtime == os.path.getmtime(filename):
+ raise GitMergeException, 'The "%s" file was not modified' % filename
+ finally:
+ for fn in stages.itervalues():
+ if os.path.isfile(fn):
+ os.remove(fn)
#
# Main algorithm
^ permalink raw reply related
* Re: [PATCH] gitweb: Fix and simplify "split patch" detection
From: Junio C Hamano @ 2007-09-03 0:15 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Yann Dirson, Petr Baudis
In-Reply-To: <200709022218.43042.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Alternate solution, which we did chose, is to check when git splits
> patches, and do not check if parsed info from current patch corresponds
> to current or next raw diff format output line. Git splits patches
> only for 'T' (typechange) status filepair, and there always two patches
> corresponding to one raw diff line.
Not that I can think of a better way offhand than what you
already mentioned, but I have to say that I am not entirely
happy with this implementation. A really old git showed two
patches (one creation and one deletion) for "complete rewrite",
which was corrected long time ago. I do not think we will
change the typechange output in a similar way in the future, but
relying on that level of detail feels somewhat ugly.
As you are reading from --patch-with-raw, you already know the
order of patches that will be given to you when you finished
reading the "raw" part. The patches will come in the same
order. So it might be possible to keep track of patches to what
path you are expecting and decide if it is part of what you are
processing at the point you process "diff --git" line.
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3
From: Junio C Hamano @ 2007-09-03 0:19 UTC (permalink / raw)
To: Sean; +Cc: H. Peter Anvin, David Kastrup, git, linux-kernel
In-Reply-To: <20070902191644.29d46cd2.seanlkml@sympatico.ca>
Sean <seanlkml@sympatico.ca> writes:
> On Sun, 02 Sep 2007 15:13:09 -0700
> Junio C Hamano <gitster@pobox.com> wrote:
> ...
>> For majority of general public, I thought the spec file _I_
>> ship, along with RPM files _I_ build, are contrib status
>> already. Don't distro people do their own RPM packages, instead
>> of using what I placed on k.org?
>
> Didn't know you used RPM yourself, so I guess this is just
> a case of something slipping through rather than the spec file
> needing a maintainer.
Well, I do not _use_ it, but the RPM I have on k.org and mention
as part of the announcement are built by me by typing "make
rpm". What I meant to say was that these RPM files may not be
"official" at all from the point of view of distro users, and I
suspect that distro "package maintainers" for git would not be
doing just a plain vanilla "make rpm" using the spec file that
comes as part of git.git repository.
^ permalink raw reply
* Re: [PATCH 0/5] gitweb: Support for arbitrary diffs
From: Jakub Narebski @ 2007-09-03 0:19 UTC (permalink / raw)
To: git
In-Reply-To: <11887443682216-git-send-email-mkoegler@auto.tuwien.ac.at>
[Cc: Martin Koegler <mkoegler@auto.tuwien.ac.at>,
Petr Baudis <pasky@suse.cz>, git@vger.kernel.org]
Martin Koegler wrote:
> Patch 4 now only generates the links, if they are enabled.
> The header contains a new link to show/hide the links.
> The state is remembered via a cookie across pages.
I'd rather have patch adding cookie management (are they only JavaScript,
or also server side?) as a separate patch.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Buffer overflows
From: Jakub Narebski @ 2007-09-03 0:19 UTC (permalink / raw)
To: git
In-Reply-To: <85veatqelm.fsf@lola.goethe.zz>
David Kastrup wrote:
> "Reece Dunn" <msclrhd@googlemail.com> writes:
>
>> Which is good, as this means that along with the tests in the
>> library, it will be more stable and less likely to be buggy than
>> something that is written from scratch.
>
> Remember git's history.
On the other hand instead of doing binary diffs from a scratch, git uses
[customized] LibXDiff library. The same might be done with bstring library,
I think.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* StGIT experimental branches updated
From: Karl Hasselström @ 2007-09-03 0:20 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
I've added the three patches I just sent out. That's all, since no one
else seems to be working. :-)
Plus, I've renamed the branches to "safe" and "experimental", since
that's what they're all about.
-+-
The following changes since commit 18669b744dbc40df9ce025f3db44a28f7aba29ff:
Catalin Marinas (1):
Add the '--exclusive' option to 'uncommit'
are available in the git repository at:
git://repo.or.cz/stgit/kha.git safe
David Kågedal (2):
Add basic test for stg status
Cleanup tree_status and use -z
Karl Hasselström (5):
Write warnings and errors to stderr if not on a terminal
Don't fail just because a subprocess wrote stuff to stderr
Let "stg status" ignore empty directories
Allow "stg add" when we have no stack
Test "stg status" more thoroughly
Pavel Roskin (2):
Use --force to overwrite python files
Fix refresh -es
Makefile | 2 +-
stgit/commands/add.py | 3 -
stgit/commands/patches.py | 2 +-
stgit/commands/refresh.py | 2 +-
stgit/git.py | 25 +++++----
stgit/out.py | 11 +++-
stgit/run.py | 5 ++-
stgit/stack.py | 3 +-
t/t0002-status.sh | 125 +++++++++++++++++++++++++++++++++++++++++++++
9 files changed, 156 insertions(+), 22 deletions(-)
create mode 100755 t/t0002-status.sh
-+-
The following changes since commit eda4068ff351143504a416393514b9fc57fb7fae:
Karl Hasselström (1):
Test "stg status" more thoroughly
are available in the git repository at:
git://repo.or.cz/stgit/kha.git experimental
David Kågedal (6):
Split git.merge into two functions
Leave working dir and index alone after failed (conflicting) push
Added a test case to check what happens when push finds a conflict
Simplify merge_recursive
Use the output from merge-recursive to list conflicts
Ask git about unmerged files
Karl Hasselström (12):
Compute patch appliedness from commit DAG
Test the new DAG appliedness machinery
Fix bash completion after the DAG appliedness patch
Speed up the appliedness test
Speed up the discovery of uninteresting commits
Speed up appliedness check during patch creation
Don't traverse the whole DAG when looking for uninteresting commits
Find uninteresting commits faster for special cases
Optimize uninterestingness checks for rebase
Better error message if merge fails
Fix "stg resolved" to work with new conflict representation
Merge branch 'conflict'
contrib/stgit-completion.bash | 15 +-
stgit/commands/commit.py | 8 +-
stgit/commands/common.py | 24 +--
stgit/commands/float.py | 2 +-
stgit/commands/imprt.py | 2 +-
stgit/commands/pick.py | 2 +-
stgit/commands/refresh.py | 2 +-
stgit/commands/resolved.py | 19 +-
stgit/commands/sync.py | 2 +-
stgit/git.py | 74 ++++--
stgit/gitmergeonefile.py | 99 ++++----
stgit/stack.py | 574 +++++++++++++++++++++++++++++++++--------
t/t0002-status.sh | 3 -
t/t1203-push-conflict.sh | 70 +++++
t/t3000-git-interop.sh | 60 +++++
t/t4000-upgrade.sh | 6 +
16 files changed, 730 insertions(+), 232 deletions(-)
create mode 100755 t/t1203-push-conflict.sh
create mode 100755 t/t3000-git-interop.sh
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] gitweb: Fix file name quoting in simplified out patch detection for --cc output
From: Junio C Hamano @ 2007-09-03 0:22 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200709022222.13865.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 8c1e02c..5d424e5 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -3140,8 +3140,8 @@ sub git_patchset_body {
> # compact combined diff output can have some patches skipped
> # find which patch (using pathname of result) we are at now
> my $to_name;
> - if ($patch_line =~ m!^diff --cc "?(.*)"?$!) {
> - $to_name = $1;
> + if ($patch_line =~ m!^diff --cc ("?.*"?)$!) {
> + $to_name = unquote($1);
> }
This patch obviously makes sense, but I wonder why you use the
form m!foobar! here, instead of far simpler to read /foobar/
form?
^ permalink raw reply
* Re: Buffer overflows
From: Junio C Hamano @ 2007-09-03 0:31 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <fbfju8$7gh$2@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> David Kastrup wrote:
> ...
>> Remember git's history.
>
> On the other hand instead of doing binary diffs from a scratch, git uses
> [customized] LibXDiff library. The same might be done with bstring library,
> I think.
I am very much in favor of reusing code that aleady proved
itself in the field outside git's context.
^ permalink raw reply
* Re: Large-scale configuration backup with GIT?
From: Martin Langhoff @ 2007-09-03 0:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jan-Benedict Glaw, git
In-Reply-To: <7vd4x0pwjm.fsf@gitster.siamese.dyndns.org>
On 9/3/07, Junio C Hamano <gitster@pobox.com> wrote:
> This is something similar to what I and others in my group did
> long time before git was even invented. I'd suggest you go in
> the opposite direction.
Agreed. The infrustructures.org crowd has been exploring this space
quite a bit, and developing tools like isconf that allow you to manage
a huge number of machines across various unixen.
And recently someone's integrated Debian APT with git tracking config
files (called IsiSetup http://www.isisetup.ch/ ). I haven't reviewed
it in detail, but it'd be first on my list.
> If you have 5 configurations, each of which have 20 machines
> that _should_ share that configuration (modulo obvious
> differences that come from hostname, IP address assignment,
> etc), then
Indeed. I ended up liking the makefile-stanzas approach it is
incredibly simple and flexible. Add debian/rpm packages, some of the
tools in the cfengine toolchain, git to track your
scripts/configuration and you are golden.
For the Windows side of things, see "Real Men Don't Click"
<http://isg.ee.ethz.ch/tools/realmen/> -- a bunch of unixy sysadmins
with the "infrastructures.org" background took on Windows
servers/desktops management -- and succeeded. PG-rated, fun for the
whole family. ;-)
HTH,
martin-who-survived-the-sysadmin-wars
^ permalink raw reply
* Re: problem with git cvsimport
From: Jean-François Veillette @ 2007-09-03 0:51 UTC (permalink / raw)
To: git
In-Reply-To: <A74F186F-7C25-48D5-9354-C74576439AF1@gmail.com>
Answering to myself ...
cvsps was the culprit.
I reverted to the unmodified 2.1 version (tag 2.1 without any patches
from the git repository) and suddently I was able to convert some cvs
projects.
But other projects are still causing problem.
- on one project it fail after 2 successful commits with :
fatal: Not a valid object name refs/heads/DEV_2_1_1
read-tree failed: 32768
- another is failing on a specific subdirectory (idealy the project
would be one directory up, in .../Wonder/Ajax/Ajax, but the
Components subdirectory importation systematicaly fail) :
09:50:26: git cvsimport -v
jfveillette@wonder.cvs.sourceforge.net's password:
Initialized empty Git repository in /Users/jfv/Developement/
WebObjects/Wonder/Ajax/Ajax/Components/.git/
Running cvsps...
jfveillette@wonder.cvs.sourceforge.net's password:
cvs_direct initialized to CVSROOT /cvsroot/wonder
cvs rlog: Logging Wonder/Ajax/Ajax/Components
DONE; creating master branch
fatal: refs/heads/origin: not a valid SHA1
fatal: master: not a valid SHA1
warning: You appear to be on a branch yet to be born.
warning: Forcing checkout of HEAD.
fatal: just how do you expect me to merge 0 trees?
checkout failed: 256
BTW, the output from « cvsps -g » (generating patches) seem to
succeed even when cvsimport fail. Is there a tool that will take the
patches from cvsps and directly import them in git ?
I tried git-am but it failed.
Again, any pointer is welcome to help resolve issues with importing
cvs projects.
Thanks to Michael for pointing out cvs2svn,I haven't tried it yet.
- jfv
Le 07-08-31 à 10:31, Jean-François Veillette a écrit :
> I can't get git-cvsimport to convert a cvs project to git (full log
> bellow).
> I always get :
> fatal: Not a valid object name refs/heads/HEAD
> read-tree failed: 32768
>
> I'm a relatively new to git. I would like to convert my project and
> track external projects with git.
> But cvsimport seem to fail. Any pointer to help me resolve the
> issue is welcome !
>
> thanks,
>
> - jfv
>
> Detail informations ...
>
> host info (uname -a) :
> Darwin localhost 8.10.0 Darwin Kernel Version 8.10.0: Wed May 23
> 16:50:59 PDT 2007; root:xnu-792.21.3~1/RELEASE_PPC Power Macintosh
> powerpc
>
> git --version
> git version 1.5.3.rc7.16.ge340d-dirty
>
> cvsps version 2.1 (got the git repository, merged 'master' with
> 'multitag')
^ permalink raw reply
* [PATCH] send-email: Add support for SSL and SMTP-AUTH
From: Douglas Stockwell @ 2007-09-02 18:06 UTC (permalink / raw)
To: gitster; +Cc: git
Allows username and password to be given using --smtp-user
and --smtp-pass. SSL use is flagged by --smtp-ssl. These are
backed by corresponding defaults in the git configuration file.
This implements Junio's 'mail identity' suggestion in a slightly
more generalised manner. --identity=$identity, backed by
sendemail.identity indicates that the configuration subsection
[sendemail "$identity"] should take priority over the [sendemail]
section for all configuration values.
Signed-off-by: Douglas Stockwell <doug@11011.net>
---
Documentation/git-send-email.txt | 35 +++++++++++++-
git-send-email.perl | 101 ++++++++++++++++++++++++++++----------
2 files changed, 109 insertions(+), 27 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 16bfd7b..1ec61af 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -75,6 +75,12 @@ The --cc option must be repeated for each user you want on the cc list.
Make git-send-email less verbose. One line per email should be
all that is output.
+--identity::
+ A configuration identity. When given, causes values in the
+ 'sendemail.<identity>' subsection to take precedence over
+ values in the 'sendemail' section. The default identity is
+ the value of 'sendemail.identity'.
+
--smtp-server::
If set, specifies the outgoing SMTP server to use (e.g.
`smtp.example.com` or a raw IP address). Alternatively it can
@@ -85,6 +91,17 @@ The --cc option must be repeated for each user you want on the cc list.
`/usr/lib/sendmail` if such program is available, or
`localhost` otherwise.
+--smtp-user, --smtp-pass::
+ Username and password for SMTP-AUTH. Defaults are the values of
+ the configuration values 'sendemail.smtpuser' and
+ 'sendemail.smtppass', but see also 'sendemail.identity'.
+ If not set, authentication is not attempted.
+
+--smtp-ssl::
+ If set, connects to the SMTP server using SSL.
+ Default is the value of the 'sendemail.smtpssl' configuration value;
+ if that is unspecified, does not use SSL.
+
--subject::
Specify the initial subject of the email thread.
Only necessary if --compose is also set. If --compose
@@ -122,6 +139,13 @@ The --to option must be repeated for each user you want on the to list.
CONFIGURATION
-------------
+sendemail.identity::
+ The default configuration identity. When specified,
+ 'sendemail.<identity>.<item>' will have higher precedence than
+ 'sendemail.<item>'. This is useful to declare multiple SMTP
+ identities and to hoist sensitive authentication information
+ out of the repository and into the global configuation file.
+
sendemail.aliasesfile::
To avoid typing long email addresses, point this to one or more
email aliases files. You must also supply 'sendemail.aliasfiletype'.
@@ -141,7 +165,16 @@ sendemail.chainreplyto::
parameter.
sendemail.smtpserver::
- Default smtp server to use.
+ Default SMTP server to use.
+
+sendemail.smtpuser::
+ Default SMTP-AUTH username.
+
+sendemail.smtppass::
+ Default SMTP-AUTH password.
+
+sendemail.smtpssl::
+ Boolean value specifying the default to the '--smtp-ssl' parameter.
Author
------
diff --git a/git-send-email.perl b/git-send-email.perl
index e0b7d12..dd7560b 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -73,9 +73,18 @@ Options:
--signed-off-cc Automatically add email addresses that appear in
Signed-off-by: or Cc: lines to the cc: list. Defaults to on.
+ --identity The configuration identity, a subsection to prioritise over
+ the default section.
+
--smtp-server If set, specifies the outgoing SMTP server to use.
Defaults to localhost.
+ --smtp-user The username for SMTP-AUTH.
+
+ --smtp-pass The password for SMTP-AUTH.
+
+ --smtp-ssl If set, connects to the SMTP server using SSL.
+
--suppress-from Suppress sending emails to yourself if your address
appears in a From: line. Defaults to off.
@@ -145,7 +154,6 @@ my $compose_filename = ".msg.$$";
my (@to,@cc,@initial_cc,@bcclist,@xh,
$initial_reply_to,$initial_subject,@files,$author,$sender,$compose,$time);
-my $smtp_server;
my $envelope_sender;
# Example reply to:
@@ -164,24 +172,26 @@ my ($quiet, $dry_run) = (0, 0);
# Variables with corresponding config settings
my ($thread, $chain_reply_to, $suppress_from, $signed_off_cc, $cc_cmd);
+my ($smtp_server, $smtp_authuser, $smtp_authpass, $smtp_ssl);
+my ($identity, $aliasfiletype, @alias_files);
-my %config_settings = (
+my %config_bool_settings = (
"thread" => [\$thread, 1],
"chainreplyto" => [\$chain_reply_to, 1],
"suppressfrom" => [\$suppress_from, 0],
"signedoffcc" => [\$signed_off_cc, 1],
- "cccmd" => [\$cc_cmd, ""],
+ "smtpssl" => [\$smtp_ssl, 0],
);
-foreach my $setting (keys %config_settings) {
- my $config = $repo->config_bool("sendemail.$setting");
- ${$config_settings{$setting}->[0]} = (defined $config) ? $config : $config_settings{$setting}->[1];
-}
-
-@bcclist = $repo->config('sendemail.bcc');
-if (!@bcclist or !$bcclist[0]) {
- @bcclist = ();
-}
+my %config_settings = (
+ "smtpserver" => \$smtp_server,
+ "smtpuser" => \$smtp_authuser,
+ "smtppass" => \$smtp_authpass,
+ "cccmd" => \$cc_cmd,
+ "aliasfiletype" => \$aliasfiletype,
+ "bcc" => \@bcclist,
+ "aliasesfile" => \@alias_files,
+);
# Begin by accumulating all the variables (defined above), that we will end up
# needing, first, from the command line:
@@ -194,6 +204,10 @@ my $rc = GetOptions("sender|from=s" => \$sender,
"bcc=s" => \@bcclist,
"chain-reply-to!" => \$chain_reply_to,
"smtp-server=s" => \$smtp_server,
+ "smtp-user=s" => \$smtp_authuser,
+ "smtp-pass=s" => \$smtp_authpass,
+ "smtp-ssl!" => \$smtp_ssl,
+ "identity=s" => \$identity,
"compose" => \$compose,
"quiet" => \$quiet,
"cc-cmd=s" => \$cc_cmd,
@@ -208,6 +222,43 @@ unless ($rc) {
usage();
}
+# Now, let's fill any that aren't set in with defaults:
+
+sub read_config {
+ my ($prefix) = @_;
+
+ foreach my $setting (keys %config_bool_settings) {
+ my $target = $config_bool_settings{$setting}->[0];
+ $$target = $repo->config_bool("$prefix.$setting") unless (defined $$target);
+ }
+
+ foreach my $setting (keys %config_settings) {
+ my $target = $config_settings{$setting};
+ if (ref($target) eq "ARRAY") {
+ unless (@$target) {
+ my @values = $repo->config("$prefix.$setting");
+ @$target = @values if (@values && defined $values[0]);
+ }
+ }
+ else {
+ $$target = $repo->config("$prefix.$setting") unless (defined $$target);
+ }
+ }
+}
+
+# read configuration from [sendemail "$identity"], fall back on [sendemail]
+$identity = $repo->config("sendemail.identity") unless (defined $identity);
+read_config("sendemail.$identity") if (defined $identity);
+read_config("sendemail");
+
+# fall back on builtin bool defaults
+foreach my $setting (values %config_bool_settings) {
+ ${$setting->[0]} = $setting->[1] unless (defined (${$setting->[0]}));
+}
+
+my ($repoauthor) = $repo->ident_person('author');
+my ($repocommitter) = $repo->ident_person('committer');
+
# Verify the user input
foreach my $entry (@to) {
@@ -222,14 +273,7 @@ foreach my $entry (@bcclist) {
die "Comma in --bcclist entry: $entry'\n" unless $entry !~ m/,/;
}
-# Now, let's fill any that aren't set in with defaults:
-
-my ($repoauthor) = $repo->ident_person('author');
-my ($repocommitter) = $repo->ident_person('committer');
-
my %aliases;
-my @alias_files = $repo->config('sendemail.aliasesfile');
-my $aliasfiletype = $repo->config('sendemail.aliasfiletype');
my %parse_alias = (
# multiline formats can be supported in the future
mutt => sub { my $fh = shift; while (<$fh>) {
@@ -320,10 +364,7 @@ if ($thread && !defined $initial_reply_to && $prompting) {
$initial_reply_to =~ s/(^\s+|\s+$)//g;
}
-if (!$smtp_server) {
- $smtp_server = $repo->config('sendemail.smtpserver');
-}
-if (!$smtp_server) {
+if (!defined $smtp_server) {
foreach (qw( /usr/sbin/sendmail /usr/lib/sendmail )) {
if (-x $_) {
$smtp_server = $_;
@@ -553,8 +594,16 @@ X-Mailer: git-send-email $gitversion
print $sm "$header\n$message";
close $sm or die $?;
} else {
- require Net::SMTP;
- $smtp ||= Net::SMTP->new( $smtp_server );
+ if ($smtp_ssl) {
+ require Net::SMTP::SSL;
+ $smtp ||= Net::SMTP::SSL->new( $smtp_server, Port => 465 );
+ }
+ else {
+ require Net::SMTP;
+ $smtp ||= Net::SMTP->new( $smtp_server );
+ }
+ $smtp->auth( $smtp_authuser, $smtp_authpass )
+ or die $smtp->message if (defined $smtp_authuser);
$smtp->mail( $raw_from ) or die $smtp->message;
$smtp->to( @recipients ) or die $smtp->message;
$smtp->data or die $smtp->message;
@@ -661,7 +710,7 @@ foreach my $t (@files) {
}
close F;
- if ($cc_cmd ne "") {
+ if (defined $cc_cmd) {
open(F, "$cc_cmd $t |")
or die "(cc-cmd) Could not execute '$cc_cmd'";
while(<F>) {
--
1.5.3.1.gc752
^ permalink raw reply related
* Google Summer of Code 2007 progress report / summary
From: Jakub Narebski @ 2007-09-03 1:09 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce, Johannes Schindelin
How it goes with Google Summer of Code git projects:
builtinification and libification? Which parts are
done, which parts are worked on?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: gitk fails to parse git log output in 1.5.3
From: Jing Xue @ 2007-09-03 1:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzm04odze.fsf@gitster.siamese.dyndns.org>
On Sun, Sep 02, 2007 at 04:16:05PM -0700, Junio C Hamano wrote:
>
> This will quickly turn into an FAQ.
Indeed. I went and added it to the Wiki/FAQ.
Also I noticed that git-log was missing the descriptions for '--color'
and '--no-color'.
Signed-off-by: Jing Xue <jingxue@digizenstudio.com>
---
Documentation/git-log.txt | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index 5ec547c..c42ca89 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -72,6 +72,14 @@ include::pretty-options.txt[]
Note that only message is considered, if also a diff is shown
its size is not included.
+--color::
+ Show colored log entries. Same as if `color.diff` were set to
+ "true".
+
+--no-color::
+ Turn off colored log entries, even when `color.diff` sets the
+ default to color output.
+
<paths>...::
Show only commits that affect the specified paths.
--
1.5.3
^ permalink raw reply related
* Re: [PATCH 0/5] gitweb: Support for arbitrary diffs
From: Petr Baudis @ 2007-09-03 1:33 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <fbfjtl$7gh$1@sea.gmane.org>
On Mon, Sep 03, 2007 at 02:19:05AM CEST, Jakub Narebski wrote:
> [Cc: Martin Koegler <mkoegler@auto.tuwien.ac.at>,
> Petr Baudis <pasky@suse.cz>, git@vger.kernel.org]
>
> Martin Koegler wrote:
>
> > Patch 4 now only generates the links, if they are enabled.
> > The header contains a new link to show/hide the links.
> > The state is remembered via a cookie across pages.
>
> I'd rather have patch adding cookie management (are they only JavaScript,
> or also server side?) as a separate patch.
This is purely in-Javascript thing, so I don't think a separate patch
makes much sense.
To hijack this post a bit, another patch in the queue (the incremental
blame thingie) introduces blame.js. Do you think that we should keep the
.js files separate, or instead have one big gitweb.js with everything?
I'm inclined to the second possibility in order to reduce the number of
requests, but it comes at a price of slightly worse maintainability.
--
Petr "Pasky" Baudis
Early to rise and early to bed makes a male healthy and wealthy and dead.
-- James Thurber
^ permalink raw reply
* Re: [PATCH] git-reset.txt: Use uniform HEAD~N notation in all examples
From: Miles Bader @ 2007-09-03 2:03 UTC (permalink / raw)
To: Jari Aalto; +Cc: git
In-Reply-To: <veauqfu0.fsf@cante.net>
Jari Aalto <jari.aalto@cante.net> writes:
> After all, the ^ very differento to what other SCM/VCSs use.
It's something I _constantly_ wished other SCM/VCSs had, as it's far,
far, more usable than the typical absolute rev numbers. It really
should be introduced as early as possible.
-Miles
--
Fast, small, soon; pick any 2.
^ 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