* [PATCH v2] Edit recipient addresses with the --compose flag
From: Ian Hilt @ 2008-11-13 2:50 UTC (permalink / raw)
To: Git Mailing List
Sometimes specifying the recipient addresses can be tedious on the
command-line. This commit allows the user to edit the recipient
addresses in their editor of choice.
Signed-off-by: Ian Hilt <ian.hilt@gmx.com>
---
Here's an updated commit with improved regex's from Junio and Francis.
git-send-email.perl | 47 ++++++++++++++++++++++++++++++++++++++++++++---
1 files changed, 44 insertions(+), 3 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 9039cfd..4d8aaa7 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -480,6 +480,9 @@ if ($compose) {
my $tpl_sender = $sender || $repoauthor || $repocommitter || '';
my $tpl_subject = $initial_subject || '';
my $tpl_reply_to = $initial_reply_to || '';
+ my $tpl_to = join(', ', @to);
+ my $tpl_cc = join(', ', @initial_cc);
+ my $tpl_bcc = join(', ', @bcclist);
print C <<EOT;
From $tpl_sender # This line is ignored.
@@ -489,6 +492,9 @@ GIT: for the patch you are writing.
GIT:
GIT: Clear the body content if you don't wish to send a summary.
From: $tpl_sender
+To: $tpl_to
+Cc: $tpl_cc
+Bcc: $tpl_bcc
Subject: $tpl_subject
In-Reply-To: $tpl_reply_to
@@ -512,9 +518,31 @@ EOT
open(C,"<",$compose_filename)
or die "Failed to open $compose_filename : " . $!;
+ local $/;
+ my $c_file = <C>;
+ $/ = "\n";
+ close(C);
+
+ my (@tmp_to, @tmp_cc, @tmp_bcc);
+
+ if ($c_file =~ /^To:\s*(\S.+?)\s*\nCc:/ism) {
+ @tmp_to = get_recipients($1);
+ }
+ if ($c_file =~ /^Cc:\s*(\S.+?)\s*\nBcc:/ism) {
+ @tmp_cc = get_recipients($1);
+ }
+ if ($c_file =~ /^Bcc:\s*(\S.+?)\s*\nSubject:/ism) {
+ @tmp_bcc = get_recipients($1);
+ }
+
+
my $need_8bit_cte = file_has_nonascii($compose_filename);
my $in_body = 0;
my $summary_empty = 1;
+
+ open(C,"<",$compose_filename)
+ or die "Failed to open $compose_filename : " . $!;
+
while(<C>) {
next if m/^GIT: /;
if ($in_body) {
@@ -543,15 +571,21 @@ EOT
} elsif (/^From:\s*(.+)\s*$/i) {
$sender = $1;
next;
- } elsif (/^(?:To|Cc|Bcc):/i) {
- print "To/Cc/Bcc fields are not interpreted yet, they have been ignored\n";
- next;
}
print C2 $_;
}
close(C);
close(C2);
+ if (@tmp_to) {
+ @to = @tmp_to;
+ }
+ if (@tmp_cc) {
+ @initial_cc = @tmp_cc;
+ }
+ if (@tmp_bcc) {
+ @bcclist = @tmp_bcc;
+ }
if ($summary_empty) {
print "Summary email is empty, skipping it\n";
$compose = -1;
@@ -1095,3 +1129,10 @@ sub file_has_nonascii {
}
return 0;
}
+
+sub get_recipients {
+ my $match = shift(@_);
+ my @recipients = split(/\s*,\s*(?![^"]+(?:\"[^*]*)*")/, $match);
+
+ return @recipients;
+}
--
1.6.0.3.523.g304d0
^ permalink raw reply related
* What's in git.git (Nov 2008, #02; Wed, 12)
From: Junio C Hamano @ 2008-11-13 2:16 UTC (permalink / raw)
To: git
The last maintenance release 1.6.0.4 was released a few days ago. There
are a few fixes already on 'maint', and also a handful more fixes cooking
in 'next', for 1.6.0.5.
I'd like to start closing the cycle for 1.6.1 by declaring -rc0 by the end
of this week. In early next month, hopefully -rc1 can contain everything
we have in 'next' tonight, plus a handful more topics that are currently
parked in 'pu'.
* The 'maint' branch has these fixes since the last announcement.
Alex Riesen (7):
Add mksnpath which allows you to specify the output buffer
Fix mkpath abuse in dwim_ref and dwim_log of sha1_name.c
Fix potentially dangerous uses of mkpath and git_path
Add git_snpath: a .git path formatting routine with output buffer
Fix potentially dangerous use of git_path in ref.c
git_pathdup: returns xstrdup-ed copy of the formatted path
Use git_pathdup instead of xstrdup(git_path(...))
Alexandre Julliard (2):
checkout: Don't crash when switching away from an invalid branch.
git-submodule: Avoid printing a spurious message.
Christian Couder (2):
Documentation: rev-list: change a few instances of "git-cmd" to "git cmd"
Documentation: bisect: change a few instances of "git-cmd" to "git cmd"
Christian Jaeger (1):
Git.pm: do not break inheritance
Clemens Buchacher (2):
do not force write of packed refs
push: fix local refs update if already up-to-date
Daniel Lowe (1):
Fix non-literal format in printf-style calls
Jeff King (1):
refactor handling of "other" files in ls-files and status
Johannes Schindelin (1):
Fix fetch/pull when run without --update-head-ok
Junio C Hamano (11):
pull: allow "git pull origin $something:$current_branch" into an unborn
branch
Fix "checkout --track -b newbranch" on detached HEAD
reset --hard/read-tree --reset -u: remove unmerged new paths
demonstrate breakage of detached checkout with symbolic link HEAD
Enhance hold_lock_file_for_{update,append}() API
Update draft 1.6.0.4 release notes
format-patch documentation: mention the special case of showing a single
commit
GIT 1.6.0.4
Makefile: help people who run 'make check' by mistake
checkout: Fix "initial checkout" detection
Start 1.6.0.5 cycle
Matt Kraai (1):
Remove the period after the git-check-attr summary
Mikael Magnusson (1):
Document that git-log takes --all-match.
Miklos Vajna (5):
Fix git branch -m for symrefs.
rename_ref(): handle the case when the reflog of a ref does not exist
Fix git update-ref --no-deref -d.
git branch -m: forbid renaming of a symref
update-ref --no-deref -d: handle the case when the pointed ref is packed
Nicolas Pitre (1):
Fix pack.packSizeLimit and --max-pack-size handling
Quy Tonthat (1):
Update RPM spec for the new location of git-cvsserver.
Stefan Naewe (1):
git ls-remote: make usage string match manpage
Yann Dirson (1):
Add reference for status letters in documentation.
* The 'master' branch has these since the last announcement
in addition to the above.
Alex Riesen (1):
Fix potentially dangerous uses of mkpath and git_path
Alexander Gavrilov (5):
builtin-blame: Reencode commit messages according to git-log rules.
Windows: Make OpenSSH properly detect tty detachment.
gitweb: Use single implementation of export_ok check.
gitweb: Add a per-repository authorization hook.
gitweb: Fix mod_perl support.
Brian Downing (2):
Always initialize xpparam_t to 0
Allow alternate "low-level" emit function from xdl_diff
Christian Couder (1):
bisect: fix missing "exit"
Daniel Lowe (1):
Fix non-literal format in printf-style calls
David M. Syzdek (1):
autoconf: Add link tests to each AC_CHECK_FUNC() test
David Symonds (1):
git-diff: Add --staged as a synonym for --cached.
Giuseppe Bilotta (5):
gitweb: parse project/action/hash_base:filename PATH_INFO
gitweb: generate project/action/hash URLs
gitweb: use_pathinfo filenames start with /
gitweb: parse parent..current syntax from PATH_INFO
gitweb: generate parent..current URLs
Jeff King (1):
t5400: expect success for denying deletion
John Chapman (2):
git-p4: Support purged files and optimize memory usage
git-p4: Cache git config for performance
Junio C Hamano (6):
Fix reading of cloud tags
rebase-i-p: minimum fix to obvious issues
git-rebase--interactive.sh: comparision with == is bashism
Update draft release notes to 1.6.1
Update draft release notes to 1.6.1
git.html: Update the links to stale versions
Markus Heidelberg (1):
Makefile: add install-man rules (quick and normal)
Miklos Vajna (1):
parse-opt: migrate builtin-checkout-index.
Nicolas Pitre (5):
index-pack: rationalize delta resolution code
index-pack: smarter memory usage during delta resolution
fix multiple issues in index-pack
improve index-pack tests
index-pack: don't leak leaf delta result
Pete Harlan (2):
contrib/hooks/post-receive-email: Put rev display in separate function
contrib/hooks/post-receive-email: Make revision display configurable
René Scharfe (3):
blame: inline get_patch()
add xdi_diff_hunks() for callers that only need hunk lengths
blame: use xdi_diff_hunks(), get rid of struct patch
Stephen Haberman (7):
rebase-i-p: test to exclude commits from todo based on its parents
rebase-i-p: use HEAD for updating the ref instead of mapping OLDHEAD
rebase-i-p: delay saving current-commit to REWRITTEN if squashing
rebase-i-p: fix 'no squashing merges' tripping up non-merges
rebase-i-p: only list commits that require rewriting in todo
rebase-i-p: do not include non-first-parent commits touching UPSTREAM
rebase-i-p: if todo was reordered use HEAD as the rewritten parent
^ permalink raw reply
* What's cooking in git.git (Nov 2008, #04; Wed, 12)
From: Junio C Hamano @ 2008-11-13 2:16 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'.
The topics list the commits in reverse chronological order. The topics
meant to be merged to the maintenance series have "maint-" in their names.
I think we should declare -rc0 by the end of this week, with the goal of
including everything that are in 'next' as of tonight, plus the "narrow
checkout" and possibly Pierre's send-email that acts as format-patch
frontend, by the time we hit -rc1, perhaps soon after the end of month.
----------------------------------------------------------------
[New Topics]
* mk/maint-cg-push (Mon Nov 10 22:47:11 2008 +0100) 1 commit
+ git push: Interpret $GIT_DIR/branches in a Cogito compatible way
* jk/commit-v-strip (Wed Nov 12 03:23:37 2008 -0500) 5 commits
+ status: show "-v" diff even for initial commit
+ Merge branch 'jk/maint-commit-v-strip' into jk/commit-v-strip
+ commit: Fix stripping of patch in verbose mode.
+ wt-status: refactor initial commit printing
+ define empty tree sha1 as a macro
* jk/maint-commit-v-strip (Wed Nov 12 03:25:52 2008 -0500) 1 commit
+ commit: Fix stripping of patch in verbose mode.
* ph/send-email (Tue Nov 11 00:54:02 2008 +0100) 4 commits
- git send-email: ask less questions when --compose is used.
- git send-email: add --annotate option
- git send-email: interpret unknown files as revision lists
- git send-email: make the message file name more specific.
* nd/rename-cache (Sat Nov 8 18:27:33 2008 +0700) 2 commits
- diffcore-rename: add config option to allow to cache renames
- diffcore-rename: support rename cache
----------------------------------------------------------------
[Will merge to "master" soon]
* jk/deny-push-to-current (Sat Nov 8 20:49:27 2008 -0500) 2 commits
+ receive-pack: detect push to current branch of non-bare repo
+ t5516: refactor oddball tests
* dl/xdiff (Fri Nov 7 21:24:33 2008 -0800) 1 commit
+ xdiff: give up scanning similar lines early
This performance fix may eventually need to be cherry-picked to 'maint'.
* lt/decorate (Wed Nov 12 11:51:28 2008 +0100) 7 commits
+ rev-list documentation: clarify the two parts of history
simplification
+ Document "git log --simplify-by-decoration"
+ Document "git log --source"
+ revision traversal: '--simplify-by-decoration'
+ Make '--decorate' set an explicit 'show_decorations' flag
+ revision: make tree comparison functions take commits rather than
trees
+ Add a 'source' decorator for commits
* gb/gitweb-snapshot-pathinfo (Sun Nov 2 10:21:39 2008 +0100) 3 commits
+ gitweb: embed snapshot format parameter in PATH_INFO
+ gitweb: retrieve snapshot format from PATH_INFO
+ gitweb: make the supported snapshot formats array global
Got sick of waiting for re-Ack.
* jn/gitweb-customlinks (Sun Oct 12 00:02:32 2008 +0200) 1 commit
+ gitweb: Better processing format string in custom links in navbar
Got sick of waiting for some sort of response from Pasky.
* st/tag (Wed Nov 5 00:20:36 2008 +0100) 2 commits
+ tag: Add more tests about mixing incompatible modes and options
+ tag: Check that options are only allowed in the appropriate mode
* ds/uintmax-config (Mon Nov 3 09:14:28 2008 -0900) 5 commits
- autoconf: Enable threaded delta search when pthreads are supported
+ Add autoconf tests for pthreads
+ Make Pthread link flags configurable
+ Add Makefile check for FreeBSD 4.9-SECURITY
+ Build: add NO_UINTMAX_T to support ancient systems
I split the part that unconditionally enable threaded delta search on any
platform on which Pthread library is detected to be available from the
topmost one. Will merge the rest to 'master' soon.
* jk/diff-convfilter (Sun Oct 26 00:50:02 2008 -0400) 8 commits
+ enable textconv for diff in verbose status/commit
+ wt-status: load diff ui config
+ only textconv regular files
+ userdiff: require explicitly allowing textconv
+ refactor userdiff textconv code
+ add userdiff textconv tests
+ document the diff driver textconv feature
+ diff: add missing static declaration
* jk/diff-convfilter-test-fix (Fri Oct 31 01:09:13 2008 -0400) 4 commits
+ Avoid using non-portable `echo -n` in tests.
+ add userdiff textconv tests
+ document the diff driver textconv feature
+ diff: add missing static declaration
An update to the one above.
----------------------------------------------------------------
[Actively Cooking]
* bc/maint-keep-pack (Sun Nov 9 23:59:58 2008 -0600) 9 commits
+ pack-objects: extend --local to mean ignore non-local loose
objects too
+ sha1_file.c: split has_loose_object() into local and non-local
counterparts
+ t7700: demonstrate mishandling of loose objects in an alternate
ODB
+ builtin-gc.c: use new pack_keep bitfield to detect .keep file
existence
+ repack: do not fall back to incremental repacking with [-a|-A]
+ repack: don't repack local objects in packs with .keep file
+ pack-objects: new option --honor-pack-keep
+ packed_git: convert pack_local flag into a bitfield and add
pack_keep
+ t7700: demonstrate mishandling of objects in packs with a .keep
file
A few commits were rewound from 'next' and replaced with new ones.
* np/pack-safer (Sun Nov 9 13:11:06 2008 -0800) 11 commits
+ t5303: fix printf format string for portability
+ t5303: work around printf breakage in dash
+ pack-objects: don't leak pack window reference when splitting
packs
+ extend test coverage for latest pack corruption resilience
improvements
+ pack-objects: allow "fixing" a corrupted pack without a full
repack
+ make find_pack_revindex() aware of the nasty world
+ make check_object() resilient to pack corruptions
+ make packed_object_info() resilient to pack corruptions
+ make unpack_object_header() non fatal
+ better validation on delta base object offsets
+ close another possibility for propagating pack corruption
* mv/remote-rename (Mon Nov 10 21:43:03 2008 +0100) 4 commits
+ git-remote: document the migration feature of the rename
subcommand
+ git-remote rename: migrate from remotes/ and branches/
+ remote: add a new 'origin' variable to the struct
+ Implement git remote rename
* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits
+ blame: show "previous" information in --porcelain/--incremental
format
+ git-blame: refactor code to emit "porcelain format" output
* nd/narrow (Wed Oct 1 11:04:09 2008 +0700) 9 commits
- grep: skip files outside sparse checkout area
- checkout_entry(): CE_NO_CHECKOUT on checked out entries.
- Prevent diff machinery from examining worktree outside sparse
checkout
- ls-files: Add tests for --sparse and friends
- update-index: add --checkout/--no-checkout to update
CE_NO_CHECKOUT bit
- update-index: refactor mark_valid() in preparation for new options
- ls-files: add options to support sparse checkout
- Introduce CE_NO_CHECKOUT bit
- Extend index to save more flags
Early parts looked Ok; I am trying to find time to review the whole thing
but fixing bugs in topics from other people here and there took almost all
my time this weekend. Not good.
----------------------------------------------------------------
[On Hold]
* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit
- "git push": tellme-more protocol extension
This seems to have a deadlock during communication between the peers.
Someone needs to pick up this topic and resolve the deadlock before it can
continue.
* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
- diff: enable "too large a rename" warning when -M/-C is explicitly
asked for
This would be the right thing to do for command line use,
but gitk will be hit due to tcl/tk's limitation, so I am holding
this back for now.
^ permalink raw reply
* Re: [PATCH] Doc: Add a simplified help on top of the "History Simplification"
From: Junio C Hamano @ 2008-11-13 2:16 UTC (permalink / raw)
To: Santi Béjar; +Cc: git, Nanako Shiraishi
In-Reply-To: <1226487088-5308-1-git-send-email-santi@agolina.net>
Thanks, will queue.
^ permalink raw reply
* Re: git commit -v does not removes the patch
From: Junio C Hamano @ 2008-11-13 2:15 UTC (permalink / raw)
To: Jeff King; +Cc: Santi Béjar, Git Mailing List
In-Reply-To: <20081112081609.GA3720@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Here's a patch series that at least improves the situation by turning
> off the diff-stripping if we never put in a diff in the first place.
> That way only people who actually _use_ "-v" will have to pay for it.
> It has the fix I sent to Santi earlier, as well as some related
> cleanups.
>
> 1/5: define empty tree sha1 as a macro
> 2/5: wt-status: refactor initial commit printing
> 3/5: status: show "-v" diff even for initial commit
> 4/5: commit: loosen pattern for matching "-v" diff
> 5/5: commit: only strip diff from message in verbose mode
Makes sense. Thanks, will queue for 'master' with minor futzing to lift
minimum fix to 'maint'.
^ permalink raw reply
* Re: [PATCH] Remove the period after the git-check-attr summary
From: Junio C Hamano @ 2008-11-13 2:15 UTC (permalink / raw)
To: Matt Kraai; +Cc: git
In-Reply-To: <1226060815-7548-1-git-send-email-kraai@ftbfs.org>
Matt Kraai <kraai@ftbfs.org> writes:
> The period at the end of the git-check-attr summary causes there to be
> two periods after the summary in the git(1) manual page.
>
> Signed-off-by: Matt Kraai <kraai@ftbfs.org>
Thanks. I think what you wrote after the --- marker is a perfect
justification of this change, so I lifted them up.
^ permalink raw reply
* Re: git integration with monodevelop
From: Miguel de Icaza @ 2008-11-13 1:42 UTC (permalink / raw)
To: Jakub Narebski
Cc: monodevelop-list, Andreas Ericsson, Git Mailing List,
Shawn Pearce
In-Reply-To: <m33ahwio3v.fsf@localhost.localdomain>
> I assume that results of Mono's Google Summer of Code 2008 projects
> to create managed git implementation in C# (git#)[1][2] were not
> very successfull? Taking into account that JGit isn't yet full git
> implementation, after much longer development...
They were a complete disaster, one student was going to focus on the
front-end, the other on the back-end.
Nothing came out of it.
>
> [1] http://code.google.com/soc/2008/mono/appinfo.html?csaid=E6D8A717A88A7632
> [2] http://code.google.com/soc/2008/mono/appinfo.html?csaid=F2E71A4D93E7EF37
>
^ permalink raw reply
* Re: Possible bug: "git log" ignores "--encoding=UTF-8" option if --pretty=format:%e%n%s%n is used
From: Junio C Hamano @ 2008-11-13 1:38 UTC (permalink / raw)
To: Constantine Plotnikov; +Cc: Jeff King, git
In-Reply-To: <85647ef50811120508j5074f892p1e2a95acfae8c0a8@mail.gmail.com>
"Constantine Plotnikov" <constantine.plotnikov@gmail.com> writes:
> BTW for some reason --pretty=raw is affected by encoding option on the
> command line.
Unfortunately, that is what you get for reading from a Porcelain output,
which is meant for, and are subject to improvement for, human consumption.
If you want bit-for-bit information, you can always ask "git cat-file".
^ permalink raw reply
* [PATCH] t7700: test that 'repack -a' packs alternate packed objects
From: Brandon Casey @ 2008-11-13 0:50 UTC (permalink / raw)
To: gitster; +Cc: peff, git, spearce, nico, Brandon Casey
In-Reply-To: <WFmMnhNsYRw3IUD8hZk59At-5jc1rZU5GaB35sb1epRZ6zwd7IMw9V94SQyEliIEyriM4J5j3AM@cipher.nrlssc.navy.mil>
Previously, when 'repack -a' was called and there were no packs in the local
repository without a .keep file, the repack would fall back to calling
pack-objects with '--unpacked --incremental'. This resulted in the created
pack file, if any, to be missing the packed objects in the alternate object
store. Test that this specific case has been fixed.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
Here is a test to demonstrate what
[PATCH 5/6] repack: do not fall back to incremental repacking with [-a|-A]
fixes.
This should apply cleanly to next since it includes
a836cfa3 t7700: demonstrate mishandling of loose objects in an alternate ODB
which has a few context lines showing through in the diff below.
-brandon
t/t7700-repack.sh | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/t/t7700-repack.sh b/t/t7700-repack.sh
index 960bff4..3f602ea 100755
--- a/t/t7700-repack.sh
+++ b/t/t7700-repack.sh
@@ -53,5 +53,21 @@ test_expect_success 'loose objects in alternate ODB are not repacked' '
test -z "$found_duplicate_object"
'
+test_expect_success 'packed obs in alt ODB are repacked even when local repo is packless' '
+ mkdir alt_objects/pack
+ mv .git/objects/pack/* alt_objects/pack &&
+ git repack -a &&
+ myidx=$(ls -1 .git/objects/pack/*.idx) &&
+ test -f "$myidx" &&
+ for p in alt_objects/pack/*.idx; do
+ git verify-pack -v $p | sed -n -e "/^[0-9a-f]\{40\}/p"
+ done | while read sha1 rest; do
+ if ! ( git verify-pack -v $myidx | grep "^$sha1" ); then
+ echo "Missing object in local pack: $sha1"
+ return 1
+ fi
+ done
+'
+
test_done
--
1.6.0.3.552.g12334
^ permalink raw reply related
* Re* [take 2] git send-email updates
From: Junio C Hamano @ 2008-11-13 0:01 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <7vk5b9x0kj.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Actually, "send-email --format-patch master..fixes Documentation/" may be
> a useful command to send out only documentation fixes. For such a usage,
> Documentation/ should not be taken as a maildir. If we would want to
> support such usage (and I'd say why not), a token can fall into one (or
> two) of three categories:
>
> - can it be a rev?
>
> - is it a tracked path (either blob or a leading dir)?
>
> - is it a file/dir that is not tracked?
>
> The first two would be format-patch candidate. The last one is the
> traditional mail source. Because the latter two are disjoint set, and
> because it does not matter if you have a tracked file 'master' and a
> branch 'master' in your repo (either will be passed to format-patch
> anyway), the actual disambiguity is reduced, but it still is different
> from what you have in your patch, I suspect.
>
> As to options, how about doing this:
>
> --no-format-patch means never ever run format-patch, behave exactly as
> before;
>
> --format-patch means what you have in your patch. guess and favor
> format-patch parameter when ambiguous;
>
> without either option, guess and favor mbox/maildir but still run
> format-patch if remaining parameters and options need to
> (e.g. "send-email my-cover-letter origin/master..master" will find
> my-cover-letter which is not tracked and take it as mbox, and grab
> patches from commits between origin/master..master, and send all of
> them).
This patch on top of your [2/4] illustrates what I had in mind (it also
removes the "print foo" while at it).
git-send-email.perl | 35 +++++++++++++++++++++++++++++++----
1 files changed, 31 insertions(+), 4 deletions(-)
diff --git c/git-send-email.perl w/git-send-email.perl
index 6f5a613..9aa3500 100755
--- c/git-send-email.perl
+++ w/git-send-email.perl
@@ -152,7 +152,7 @@ if ($@) {
# Behavior modification variables
my ($quiet, $dry_run) = (0, 0);
-my $format_patch;
+my $format_patch = 'unspecified';
my $compose_filename = $repo->repo_path() . "/.gitsendemail.msg.$$";
# Variables with corresponding config settings
@@ -243,6 +243,15 @@ unless ($rc) {
usage();
}
+if ($format_patch && $format_patch eq 'unspecified') {
+ # No --format-patch nor --no-format-patch on the command line
+ $format_patch = 0;
+} elsif (!$format_patch) {
+ $format_patch = undef;
+} else {
+ $format_patch = 1;
+}
+
# Now, let's fill any that aren't set in with defaults:
sub read_config {
@@ -374,11 +383,27 @@ if (@alias_files and $aliasfiletype and defined $parse_alias{$aliasfiletype}) {
# returns 1 if the conflict must be solved using it as a format-patch argument
sub check_file_rev_conflict($) {
my $f = shift;
+
+ if (!defined $format_patch) {
+ # The command line explicitly forbids acting as a wrapper
+ return 0;
+ }
+
+ # If it is a tracked path it can't be tracking the e-mails you
+ # are going to send out to describe the change to this repository.
+ eval {
+ $repo->command(['ls-files', '--error-unmatch', $f],
+ { STDERR => 0 });
+ };
+ if (!$@) {
+ return 1;
+ }
+
+ # Can it be interpreted as a rev?
try {
$repo->command('rev-parse', '--verify', '--quiet', $f);
- if (defined($format_patch)) {
- print "foo\n";
- return $format_patch;
+ if ($format_patch) {
+ return 1;
}
die(<<EOF);
File '$f' exists but it could also be the range of commits
@@ -408,6 +433,8 @@ while (my $f = pop @ARGV) {
closedir(DH);
} elsif ((-f $f or -p $f) and !check_file_rev_conflict($f)) {
push @files, $f;
+ } elsif (!defined $format_patch) {
+ die("--no-format-patch was given but $f is not a valid send-email argument");
} else {
push @rev_list_opts, $f;
}
^ permalink raw reply related
* git svn branch
From: yb_Art @ 2008-11-12 23:47 UTC (permalink / raw)
To: git
I'm using the binary from google code on my mac os-x leopard machine,
and it doesn't have git svn branch. How can I work around this
issue? Is there anyway to create a branch on the svn repository using
git?
^ permalink raw reply
* Re: git integration with monodevelop
From: Govind Salinas @ 2008-11-13 0:00 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Git Mailing List, Shawn Pearce, Michael Hutchinson
In-Reply-To: <491AB078.6020208@op5.se>
On Wed, Nov 12, 2008 at 4:31 AM, Andreas Ericsson <ae@op5.se> wrote:
> Andreas Ericsson wrote:
>>
>> Recently, I've started learning C#. More for fun than anything else,
>> but one of the mono core devs sniffed me out and said they've been
>> thinking of porting jgit to C# to get a working IDE integration in
>> monodevelop. Currently, the only option available (with IDE
>> integration anyways) to the poor C# devs is either Microsoft's
>> crappy VSS, or the less crappy but still far from fantastic
>> Subversion.
>>
>> So in an effort to learn C#, I've decided to play along with this
>> (hopefully with some help from the MonoDevelop team), but it seems
>> to me that the best place to start is the fledgling libgit2 and link
>> that with git-sharp. The primary reason for this is ofcourse that I
>> think it'd be a terrible waste to have yet another from-scratch
>> implementation of git in a new language (ruby, java, C#, C...). The
>> secondary reason is that it would be neat to have more OSS projects
>> use my favourite scm.
>>
>> Besides, getting something to rely on libgit2 early on is probably
>> the best way to get more people interested in making development of
>> it proceed rapidly.
>>
>> Thoughts anyone?
>>
>> Please reply-to-all as this goes cross-list
>> (currently, Cc ae@op5.se, spearce@spearce.org, git@vger.kernel.org,
>> m.j.hutchinson@gmail.com, in case monodevelop-list uses reply-to
>> header).
>>
>
> Ouch. Scratch monodevelop-list from that Cc list. It appears to be
> members-only (although not listed as such on their list-server).
>
Hi,
I started working on a C# UI a long time ago but I abandoned it due
to lack of interest from others and time constraints. You are welcome
to take it and build on it if you like. It wraps the C git binaries and the UI
is separate from the "plumbing".
http://repo.or.cz/w/Widgit.git
-Govind
^ permalink raw reply
* Re: git integration with monodevelop
From: Michael Hutchinson @ 2008-11-12 23:56 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: monodevelop-list, Git Mailing List, Shawn Pearce
In-Reply-To: <491AAE6D.8030304@op5.se>
On Wed, Nov 12, 2008 at 5:22 AM, Andreas Ericsson <ae@op5.se> wrote:
> Recently, I've started learning C#. More for fun than anything else,
> but one of the mono core devs sniffed me out and said they've been
> thinking of porting jgit to C# to get a working IDE integration in
> monodevelop. Currently, the only option available (with IDE
> integration anyways) to the poor C# devs is either Microsoft's
> crappy VSS, or the less crappy but still far from fantastic
> Subversion.
I'm glad you're interested :-)
We do have an interface in MD for integrating VCS providers, and
although the only existing one is SVN, I believe some users are
working on bzr and perforce addins. I'd prefer to see git get
established as the default (D)VCS ...
Currently, to implement a VCS provider one needs to subclass
VersionControlSystem, as demonstrated by the SVN provider:
http://anonsvn.mono-project.com/viewvc/trunk/monodevelop/main/src/addins/VersionControl/MonoDevelop.VersionControl.Subversion/MonoDevelop.VersionControl.Subversion.addin.xml?view=markup.
We may need to extend the interfaces in order to expose more
DVCS-specific features, but I think it's best to find and fix these as
needed rather than speculatively implementing things.
> So in an effort to learn C#, I've decided to play along with this
> (hopefully with some help from the MonoDevelop team), but it seems
> to me that the best place to start is the fledgling libgit2 and link
> that with git-sharp. The primary reason for this is ofcourse that I
> think it'd be a terrible waste to have yet another from-scratch
> implementation of git in a new language (ruby, java, C#, C...). The
> secondary reason is that it would be neat to have more OSS projects
> use my favourite scm.
That's actually one of the reasons we'd like a full managed
implementation --it'd be trivial to include to with cross-platform
Mono-based apps without worrying about architecture, C dependencies,
etc. For example, Tomboy could use git to store its notes, so users
would have a versioned history and better synch/merge. Then, for
example, you could build a Silverlight version that would have full
history in local storage.
> Besides, getting something to rely on libgit2 early on is probably
> the best way to get more people interested in making development of
> it proceed rapidly.
>
> Thoughts anyone?
I hadn't heard of libgit2 (it looks pretty recent) but it looks
interesting -- at least stable APIs would no longer be a worry.
However, I think fully managed is the way to go, from the point of
view of much easier dependencies (on windows, mac, silverlight and
older linux distros) and licensing.
--
Michael Hutchinson
http://mjhutchinson.com
^ permalink raw reply
* Re: [PATCH] git-diff: Add --staged as a synonym for --cached.
From: Junio C Hamano @ 2008-11-12 23:42 UTC (permalink / raw)
To: Avery Pennarun
Cc: Junio C Hamano, Jeff King, Johannes Schindelin,
Björn Steinbrink, David Symonds, git, Stephan Beyer
In-Reply-To: <32541b130811121439tbfc54aeq2999dbebf149d5bc@mail.gmail.com>
"Avery Pennarun" <apenwarr@gmail.com> writes:
> I assume the reason is that "git diff tree1..tree2" works with the
> differences between tree1 and tree2, much like "git log tree1..tree2"
> does.
Actually, that perception is already confused. The analogue to "log A..B"
is expressed as "diff A...B", and not "diff A..B".
That is one of the reasons why I tend to teach against using "diff A..B"
unless you know what it is doing. I'd suggest to get out of that habit
before you confuse yourself even more ;-).
The _only_ reason diff takes A..B and A...B syntax is because the command
line parameter parser was easy to write that way. IOW, it was an artifact
of the implementation convenience.
^ permalink raw reply
* Re: [PATCH] Git.pm: Make _temp_cache use the repository directory
From: Marten Svanfeldt (dev) @ 2008-11-12 23:27 UTC (permalink / raw)
To: piyo; +Cc: msysgit, git, Eric Wong
In-Reply-To: <1f748ec60811121406j7ac72c7eqcfbe68132b2ebfc0@mail.gmail.com>
Hi,
Clifford Caoile wrote:
> Hi Marten Svanfeldt:
>
> On Wed, Nov 12, 2008 at 11:28 PM, Marten Svanfeldt (dev)
> <developer@svanfeldt.com> wrote:
..
> I suppose if I wanted to used ${workingdir}/.git instead of
> ${workingdir}, I should replace the $tmpdir line above with $tmpdir =
> $self->repo_path() . "/.git" ?
No. repo_path() is the path to the repository, so the .git directory. If
you instead want within the working directory it is wc_path().
>
> Best regards,
> Clifford Caoile
-Marten Svanfeldt
^ permalink raw reply
* Re: fixing duplicated history
From: Felipe Balbi @ 2008-11-12 22:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: me, git
In-Reply-To: <7vod0klfng.fsf@gitster.siamese.dyndns.org>
On Wed, Nov 12, 2008 at 02:53:55PM -0800, Junio C Hamano wrote:
> Felipe Balbi <me@felipebalbi.com> writes:
>
> > I have a git tree which history is completely messed up with duplicated
> > entries. By reading git man pages I saw that it might be possible to
> > delete those duplicated entries with git reflog delete, am I reading it
> > right ?
> >
> > If so, would it cause any problems to the users who already cloned the
> > original tree ? I mean, will git see it as a different history line and
> > try a merge or will it figure it's the same tree with the duplicated
> > entries removed ?
>
> I assume that you meant "commit" by "entry", and also I assume that you
> read "git filter-branch" not "git reflog delete". Then you are right.
>
> And rewriting history with filter-branch will cause problems to the
> downstream users.
Yes, you got me right. Hmm, so if it'll cause problems to the downstream
users I can't do anything, unfortunately :-(
Unless they wanna clone the tree again :-p
Thanks for the info Junio.
--
balbi
^ permalink raw reply
* Re: fixing duplicated history
From: Junio C Hamano @ 2008-11-12 22:53 UTC (permalink / raw)
To: me; +Cc: git
In-Reply-To: <20081112222346.GA24013@frodo>
Felipe Balbi <me@felipebalbi.com> writes:
> I have a git tree which history is completely messed up with duplicated
> entries. By reading git man pages I saw that it might be possible to
> delete those duplicated entries with git reflog delete, am I reading it
> right ?
>
> If so, would it cause any problems to the users who already cloned the
> original tree ? I mean, will git see it as a different history line and
> try a merge or will it figure it's the same tree with the duplicated
> entries removed ?
I assume that you meant "commit" by "entry", and also I assume that you
read "git filter-branch" not "git reflog delete". Then you are right.
And rewriting history with filter-branch will cause problems to the
downstream users.
^ permalink raw reply
* Re: fixing duplicated history
From: Robin Rosenberg @ 2008-11-12 22:52 UTC (permalink / raw)
To: me; +Cc: git
In-Reply-To: <20081112222346.GA24013@frodo>
onsdag 12 november 2008 23:23:51 skrev Felipe Balbi:
> Hi,
>
> I have a git tree which history is completely messed up with duplicated
> entries. By reading git man pages I saw that it might be possible to
> delete those duplicated entries with git reflog delete, am I reading it
> right ?
No. The reflog is not the history, except your very local log of what
the heads pointed to. You do not see the reflog unless you ask for it,
and nobody else can see it (i.e. *your* reflog).
What looks like duplicate entries may commit that have been cherry
picked into one or more branches that have been merged thereafter. If
you look carefully they have different id's.
-- robin
^ permalink raw reply
* Re: Why is TreeWalk.forPath(...) returning null
From: Farrukh Najmi @ 2008-11-12 22:52 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20081112224236.GX2932@spearce.org>
Shawn O. Pearce wrote:
> Farrukh Najmi <farrukh@wellfleetsoftware.com> wrote:
>
>> My "git status" command shows:
>>
>> # On branch master
>> # Changed but not updated:
>> # (use "git add <file>..." to update what will be committed)
>> #
>> # modified: xml/minDB/SubmitObjectsRequest_CMSScheme.xml
>>
>> The file above was committed and then modified. I want to use jgit to
>> find the comitted version of that file.
>>
>> When I do the following code I get a null treeWalk? Why is that? What
>> should I specify for path instead?
>>
>> String path = "xml/minDB/SubmitObjectsRequest_CMSScheme.xml";
>> String versionName = Constants.HEAD;
>>
>> Commit commit = repository.mapCommit(versionName);
>>
>> if (commit == null) {
>> log.trace("Did not find Commit. versionName:" +
>> versionName);
>> } else {
>> ObjectId[] ids = {commit.getTree().getId()};
>> TreeWalk treeWalk = TreeWalk.forPath(repository, path, ids);
>> }
>>
>
> Huh. That should have worked.
>
> TreeWalk.forPath returns null if the path doesn't get found. So
> it sounds like jgit isn't matching the path. Its a pretty simple
> operation, I'm not sure why its failing here. I'd run it through
> a debugger to try and see why the TreeWalk didn't match your path.
>
> Your code is logically the same as:
>
> git rev-parse HEAD:$path
>
> so it should find the blob if Git would have found it.
>
>
My bad. I had a type in the path in my junit test :-[
Its working as expected. Thanks.
--
Regards,
Farrukh Najmi
Web: http://www.wellfleetsoftware.com
^ permalink raw reply
* Re: [PATCH] git-diff: Add --staged as a synonym for --cached.
From: Avery Pennarun @ 2008-11-12 22:39 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, Johannes Schindelin, Björn Steinbrink,
David Symonds, git, Stephan Beyer
In-Reply-To: <7vbpwkogxq.fsf@gitster.siamese.dyndns.org>
On Wed, Nov 12, 2008 at 2:57 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jeff King <peff@peff.net> writes:
>
>> I'm not sure I agree. They _are_ different things, but in the case of
>> diff, you are really treating each of them like a tree (which makes
>> range operators a little silly, but then that is a silliness already
>> present in "git diff tree1..tree2").
>
> It is not _little_ silly, but quite silly. It is a historical accident
> and I personally suggest against using it when I teach git to others.
I assume the reason is that "git diff tree1..tree2" works with the
differences between tree1 and tree2, much like "git log tree1..tree2"
does. On the other hand, "git log tree1 tree2" is something
completely different.
So at least in my mental model, it's "git diff tree1 tree2" that's out
of place, not really the one with the range specifier.
Apparently what's intuitive to one person isn't always intuitive to the next.
Avery
^ permalink raw reply
* Re: EGIT branch checkout errors
From: Robin Rosenberg @ 2008-11-12 22:48 UTC (permalink / raw)
To: Chris Dumoulin; +Cc: git
In-Reply-To: <491AFB40.4000800@oanda.com>
onsdag 12 november 2008 16:50:24 skrev Chris Dumoulin:
> Using EGIT in Eclipse, I'm able to create a new branch, but not able to
> checkout a branch. When I try Team->Branch...->Checkout, nothing
> happens, so I launched Eclipse from a terminal to see any output it
> might be giving. Here's what I got:
Something is wrong in the WorkDirCheckout class. Could you send these
things
git ls-tree -r HEAD
git-ls-tree -r branch-you-try-to-switch-to
git diff --name-only
Then post it to http://code.google.com/p/egit/issues/list
-- robin
^ permalink raw reply
* Re: Why is TreeWalk.forPath(...) returning null
From: Shawn O. Pearce @ 2008-11-12 22:42 UTC (permalink / raw)
To: Farrukh Najmi; +Cc: git
In-Reply-To: <491B579E.6050408@wellfleetsoftware.com>
Farrukh Najmi <farrukh@wellfleetsoftware.com> wrote:
>
> My "git status" command shows:
>
> # On branch master
> # Changed but not updated:
> # (use "git add <file>..." to update what will be committed)
> #
> # modified: xml/minDB/SubmitObjectsRequest_CMSScheme.xml
>
> The file above was committed and then modified. I want to use jgit to
> find the comitted version of that file.
>
> When I do the following code I get a null treeWalk? Why is that? What
> should I specify for path instead?
>
> String path = "xml/minDB/SubmitObjectsRequest_CMSScheme.xml";
> String versionName = Constants.HEAD;
>
> Commit commit = repository.mapCommit(versionName);
>
> if (commit == null) {
> log.trace("Did not find Commit. versionName:" +
> versionName);
> } else {
> ObjectId[] ids = {commit.getTree().getId()};
> TreeWalk treeWalk = TreeWalk.forPath(repository, path, ids);
> }
Huh. That should have worked.
TreeWalk.forPath returns null if the path doesn't get found. So
it sounds like jgit isn't matching the path. Its a pretty simple
operation, I'm not sure why its failing here. I'd run it through
a debugger to try and see why the TreeWalk didn't match your path.
Your code is logically the same as:
git rev-parse HEAD:$path
so it should find the blob if Git would have found it.
--
Shawn.
^ permalink raw reply
* Re: Newbie questions regarding jgit
From: Robin Rosenberg @ 2008-11-12 22:37 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Farrukh Najmi, git
(resend without HTML)
tisdag 11 november 2008 22:37:40 skrev Jonas Fonseca:
> On Tue, Nov 11, 2008 at 21:44, Farrukh Najmi
> <farrukh@wellfleetsoftware.com> wrote:
> > Hi all,
>
> Hello,
>
> > I am git newbie and looking to use jgit in a servlet endpoint.
>
> Sounds interesting. I have been thinking about how hard it would be to
> write a very simpe jgitweb kind of thing and am very interested to
> hear more about your experiences.
Consider this:
http://www.jgit.org/cgi-bin/gitweb/gitweb.cgi?p=EGIT-jee.git;a=shortlog;h=rr/jeegitweb
It's an toy experiment with taglibs. Unfortunately the JSP doesn't even compile (!) anymore,
maybe someone can spot the error. Something very close to this did work a while ago.
The example jsp is here:
http://www.jgit.org/cgi-bin/gitweb/gitweb.cgi?p=EGIT-jee.git;a=blob;f=org.spearce.jeegit web/WebContent/index.jsp;h=d065d9f5a725a161a640e58e3be4d5b3a0666b5e;hb=fabffb50f0a020ff9b1653c090675bbd56dcc80a
-- robin
^ permalink raw reply
* Re: Newbie questions regarding jgit
From: Robin Rosenberg @ 2008-11-12 22:36 UTC (permalink / raw)
To: Farrukh Najmi; +Cc: git
(resend without HTML)
tisdag 11 november 2008 22:12:58 skrev Farrukh Najmi:
>
> I should clarify that I am not using eclipse nor am I using any GUI. My
> objective is to have Java API access to git from within a servlet using
> jgit. At present, all I have to go on is javadoc and its not clear where
> to begin if I simply wish to create, read and update files in a git repo
> from within the servlet java code.
>
We do not have a tutorial. The JUnit tests are the best examples on
how to use the API today. I did some experiement wit J2EE and created
some jsp tags, but that's for JSP only and mostly experimental. To
comply with the JEE spec one should create a resource manager for
Git to deal with scalability when many users try to access repos.
> > I am git newbie and looking to use jgit in a servlet endpoint.
> >
> > Where can I find a public maven repo for gjit? It seems there is one
> > somewhere because of the following file in src tree:
> >
> > jgit-maven/jgit/pom.xml
We do not use maven ourselves right now, though that might change, so
there is not public maven repository for jgit just yet. What do I need to
do to set it up?
> >
> > For now I have built the jar using /make_jgit.sh and installed the pom
> > manually using m
> >
> > mvn install:install-file -DpomFile=jgit-maven/jgit/pom.xml
> > -Dfile=jgit.jar
The pom.xml works for building jgit. cd to the mave dir and type mvn
and watch it build (and run unit tests if you ask it to).
-- robin
^ permalink raw reply
* fixing duplicated history
From: Felipe Balbi @ 2008-11-12 22:23 UTC (permalink / raw)
To: git
Hi,
I have a git tree which history is completely messed up with duplicated
entries. By reading git man pages I saw that it might be possible to
delete those duplicated entries with git reflog delete, am I reading it
right ?
If so, would it cause any problems to the users who already cloned the
original tree ? I mean, will git see it as a different history line and
try a merge or will it figure it's the same tree with the duplicated
entries removed ?
Thanks in advance for the help
--
balbi
^ 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