* 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] 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
* 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
* 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
* [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
* Re: [PATCH v2] Edit recipient addresses with the --compose flag
From: Junio C Hamano @ 2008-11-13 3:18 UTC (permalink / raw)
To: Ian Hilt; +Cc: Git Mailing List, Pierre Habouzit
In-Reply-To: <1226544602-1839-1-git-send-email-ian.hilt@gmx.com>
Ian Hilt <ian.hilt@gmx.com> writes:
> 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.
This heavily depends on Pierre's patch, so I am CC'ing him for comments.
Until his series settles down, I cannot apply this anyway.
> @@ -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);
> + }
Why "\S.+?" and not "\S.*?"? A local user whose login name is 'q' is
disallowed?
Why does the user must keep "Cc:" in order for this new code to pick up
the list of recipients? In other words, you are forbidding the user from
removing the entire "Cc:" line, even when the message should not be Cc'ed
to anywhere. Instead there has to remain an empty Cc: line. Worse yet,
such an empty "Cc:" line is printed to C2 with your patch and eventually
fed to sendmail. I think it is a violation of 2822 to have Cc: that is
empty, as the format is specified as:
cc = "Cc:" address-list CRLF
bcc = "Bcc:" (address-list / [CFWS]) CRLF
address-list = (address *("," address)) / obs-addr-list
> + 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);
> + }
Exactly the same comment applies to Bcc and Subject part of the parsing.
I think the parsing code you introduced simply suck. Why isn't it done as
a part of the main loop to read the same file that already exists?
Unlike your additional code above that reads the whole file into a scalar
only to discard, the existing main loop processes one line at a file
(which should be more memory efficient), and you are not handling the
header continuation line anyway, processing one line at a time would make
your code much simpler (for one thing, you do not have to do /sm at all).
Also it won't be confused as your version would if the message happens to
have "To:" or "Cc:" in the message part, thanks to $in_body variable check
that is already in the code.
^ permalink raw reply
* Re: running out of memory when doing a clone of a large repository?
From: Nicolas Pitre @ 2008-11-13 3:22 UTC (permalink / raw)
To: Paul E. Rybski; +Cc: git
In-Reply-To: <491B2550.1050005@cs.cmu.edu>
On Wed, 12 Nov 2008, Paul E. Rybski wrote:
> Hi,
> I've recently started evaluating git for use on one of my projects. I
> used git-svn to convert a fairly large subversion repository and one of
> its branches into two separate git repositories following the
> instructions found here:
>
> http://www.simplisticcomplexity.com/2008/03/05/cleanly-migrate-your-subversion-repository-to-a-git-repository/
>
> From that, I created a 1.5G repository from the trunk of the subversion
> repo and a 1.1G repository from one of the branches. I then tried to
> clone the repositories from one machine to another via ssh and the
> smaller 1.1G repository of the subversion branch (with 1932 commits)
> came over just fine but the larger 1.5G repository of the subversion
> trunk (5865 commits) died with the following error:
>
> remote: Counting objects: 48415, done.
> remote: warning: suboptimal pack - out of memory
> error: git-upload-pack: git-pack-objects died with error.
> fatal: git-upload-pack: aborting due to possible repository corruption
> on the remote side.
> remote: aborting due to possible repository corruption on the remote side.
> fatal: early EOF
> fatal: index-pack failed
>
> Is this simply because the git repository is too large for the machine
> that's trying to send it over ssh?
Possibly.
> Is there a way to restrict the memory usage of git or do I need to get
> more RAM or somehow not import the full subversion history of my
> original trunk?
It is possible that the inport from svn didn't produce a fully packed
repository. Try a "git repack -a -f -d" on the server machine. If you
get the same out-of-memory problem then ideally you should copy the
whole directory to a bigger machine and run 'git repack -a -f -d" there.
Then you may copy it back to the small machine and subsequent clone
requests should be just fine.
You could also investigate the pack.windowMemory configuration variable
on the server side. If you have lots of big files then setting this to
64m for example may help.
> I'm using Ubuntu 8.04.1 on both machines and using the Ubuntu packages
> of git version 1.5.4.3.
There was a bug in versions prior to v1.5.6.4 affecting memory usage.
Upgrading to this version or later on the server machine might help too.
> The machine holding the repository is a 5-year
> old AthlonXP 3200 with 1G RAM and 32-bit Ubuntu. The machine I'm
> cloning the repository on is a more recent Intel Dual Core Quad Q6600
> with 4GRAM and 64-bit Ubuntu.
>
> Any advice would be greatly appreciated.
>
> Thanks!
>
> -Paul
>
> --
> Paul E. Rybski, Ph.D., Systems Scientist
> The Robotics Institute, Carnegie Mellon University
> Phone: 412-268-7417, Fax: 412-268-7350
> Web: http://www.cs.cmu.edu/~prybski
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Nicolas
^ permalink raw reply
* Re: Possible bug: "git log" ignores "--encoding=UTF-8" option if --pretty=format:%e%n%s%n is used
From: Jeff King @ 2008-11-13 4:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Constantine Plotnikov, git
In-Reply-To: <7vvdusjtg8.fsf@gitster.siamese.dyndns.org>
On Wed, Nov 12, 2008 at 05:38:47PM -0800, Junio C Hamano wrote:
> > 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".
What about "git rev-list --pretty=raw"? Is that also porcelain?
I would be curious to hear your take on our failure to respect
--encoding for --pretty=format. Is it a bug to be fixed, or a historical
behavior to be maintained?
-Peff
^ 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 5:10 UTC (permalink / raw)
To: Jeff King; +Cc: Constantine Plotnikov, git
In-Reply-To: <20081113043454.GA5048@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> What about "git rev-list --pretty=raw"? Is that also porcelain?
Does it re-encode? I didn't check, but ideally it shouldn't (but I do not
care too much either way, to be honest).
> I would be curious to hear your take on our failure to respect
> --encoding for --pretty=format. Is it a bug to be fixed, or a historical
> behavior to be maintained?
I think the fix you outlined was quite reasonable.
^ permalink raw reply
* Re: [RFC PATCH 0/4] deny push to current branch of non-bare repo
From: Kyle Moffett @ 2008-11-13 5:22 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, Sam Vilain
In-Reply-To: <20081112084412.GA3860@coredump.intra.peff.net>
On Wed, Nov 12, 2008 at 3:44 AM, Jeff King <peff@peff.net> wrote:
> On Tue, Nov 11, 2008 at 07:44:06PM -0500, Kyle Moffett wrote:
>> Hmm, I wonder if it would be possible to also add a "detach" variant;
>> which would create a detached-HEAD at the current commit when
>> automatically receiving a push to the working branch. I have a
>> post-receive script that does so right now on a couple repositories.
>> It's still a little confusing to someone actively working in the
>> repository being pushed to, but it's much easier to explain than the
>> current default behavior.
>
> A neat idea, but I'm not sure what workflow that is meant to support.
Basically, I have a remote tree on a fast multicore box used for runs
of a test suite on various peoples different branches. When I want
somebody to push something for me to test, they push directly to that
repo, and when I'm done playing with a previous run I just do:
$ git checkout new/branch/to/test
$ make clean
$ ./configure
$ make
$ make check
Occasionally I notice a bug which I want to temporarily fix to let the
build continue, even though I will need to have the author merge that
fix as a part of his original buggy patch. If nobody pushes the
branch I'm currently testing again, I can "git diff" just fine to see
what I had to fix. If somebody pushes to a different branch than the
one I'm testing, it's also fine. The inconsistency is pushing to the
branch I'm on.
So it would be handy to be able to mark that repository as
"detach-HEAD-on-push-of-current-branch", which would let me remember
where I was, even if that's not where that branch is anymore.
There are other ways I could probably do something very similar, but
since the config option was being added it seemed it would probably be
easy to extend. If nobody else is interested in that behavior, I will
just keep maintaining my own hook, but I thought I'd mention it.
Cheers,
Kyle Moffett
^ permalink raw reply
* Re: [RFC PATCH 0/4] deny push to current branch of non-bare repo
From: Jeff King @ 2008-11-13 5:37 UTC (permalink / raw)
To: Kyle Moffett; +Cc: Junio C Hamano, git, Sam Vilain
In-Reply-To: <f73f7ab80811122122i4ae3ba6dn2ceb314b86660a70@mail.gmail.com>
On Thu, Nov 13, 2008 at 12:22:20AM -0500, Kyle Moffett wrote:
> somebody to push something for me to test, they push directly to that
> repo, and when I'm done playing with a previous run I just do:
>
> $ git checkout new/branch/to/test
> $ make clean
> $ ./configure
> $ make
> $ make check
OK, I see how using a detached HEAD makes sense. But I think just going
straight to a detached HEAD might make even more sense. With your
proposed behavior, you need to be prepared to unexpectedly and
asynchronously move to a detached HEAD at any time, so why not just
start there in the first place?
And then the "push to current branch" problem is neatly solved: you have
no current branch.
So:
$ git checkout new/branch/to/test^0
$ make, configure, etc
-Peff
^ permalink raw reply
* Re: Possible bug: "git log" ignores "--encoding=UTF-8" option if --pretty=format:%e%n%s%n is used
From: Jeff King @ 2008-11-13 5:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Constantine Plotnikov, git
In-Reply-To: <7vod0ki531.fsf@gitster.siamese.dyndns.org>
On Wed, Nov 12, 2008 at 09:10:26PM -0800, Junio C Hamano wrote:
> > What about "git rev-list --pretty=raw"? Is that also porcelain?
>
> Does it re-encode? I didn't check, but ideally it shouldn't (but I do not
> care too much either way, to be honest).
Yes, it uses the same pretty_print_commit routine as the "log".
> > I would be curious to hear your take on our failure to respect
> > --encoding for --pretty=format. Is it a bug to be fixed, or a historical
> > behavior to be maintained?
>
> I think the fix you outlined was quite reasonable.
One thing I just realized that makes it even more reasonable: we
properly munge the encoding header when we _do_ re-encode. So whether we
re-encode or not, you will always get the correct encoding for what is
being output via "%e". Which means that a tool which handles the current
"broken" behavior by re-encoding themselves will trivially handle the
new version: the output will just always be in the --encoding specified
instead of whatever the original encoding was.
And if there are tools that are not looking at the output encoding (and
blindly assuming --encoding works), then they are already broken by the
current behavior, and we will be fixing them.
So I think it is safe to "fix" it as I described.
-Peff
^ permalink raw reply
* Re: [RFC PATCH 0/4] deny push to current branch of non-bare repo
From: Junio C Hamano @ 2008-11-13 6:14 UTC (permalink / raw)
To: Jeff King; +Cc: Kyle Moffett, git, Sam Vilain
In-Reply-To: <20081113053735.GA5343@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> And then the "push to current branch" problem is neatly solved: you have
> no current branch.
>
> So:
>
> $ git checkout new/branch/to/test^0
> $ make, configure, etc
Exactly.
I keep a handful pseudo worktrees around (created with git-new-workdir on
top of a single repository) for quick patch test and build purposes. I do
not push into them but pushing into a non-bare repository and checking out
the same branch twice in such a setup share exactly the same issue, and I
keep their HEADs all detached for exactly the same reason.
^ permalink raw reply
* Re: git integration with monodevelop
From: Andreas Ericsson @ 2008-11-13 7:20 UTC (permalink / raw)
To: Evgeniy Ivanov; +Cc: Shawn Pearce, Git Mailing List
In-Reply-To: <491B02FF.2060204@kde.ru>
Evgeniy Ivanov wrote:
> Andreas Ericsson wrote:
>> Evgeniy Ivanov wrote:
>>> Hi Andreas,
>>> I've developed basic git-support in KDevelop using git's cmd-line
>>> interface. I'm very interested in rewriting it with libgit2, when
>>> libgit2 becomes usable. Can you, please, drop me a line, when you have
>>> some code?
>>>
>> git clone http://www.spearce.org/projects/scm/libgit2/libgit2.git
>>
>> will probably prove beneficial. I'm adding Shawn to Cc as he's the
>> primary libgit2 author. Please follow the git.git guidelines for
>> submitting patches, and please note that there's not much there
>> right now. Adding a wishlist for what you need in terms of UI
>> integration might make it easier to focus on something when it's
>> going slow.
>>
>
> I can only suggest something like this on top of library (something like
> common used things):
> http://websvn.kde.org/trunk/KDE/kdevplatform/plugins/git/gitexecutor.h?revision=856589&view=markup
>
> I Don't think library interface should be much differ from cmd-line's one.
Well, it will be. The git CLI is inconsistent in places but it would be
weird to have libgit2 inherit those inconsistencies.
> For advanced use, QGit's includes can be used (search commit objects,
> etc). QGit has much more features, than my integration. AFAIK Shawn has
> experience in egit
Yes. He wrote it.
> (and maybe even gitk). IMHO the best thing is to
> implement libgit2 in terms of QGit, egit and maybe kdevelop's git
> support.
That would defeat the purpose rather wildly. The idea with libgit2 is
to create a library that the git cli can use, so building it based on
command-line output is a no-go. libgit2 is the attempt to make it right.
> I will help with pleasure (mentored by Shawn), when have some
> time (maybe only in January-February).
>
Excellent :)
> But this is the same things Shawn has suggested to my mentor and me at
> the beginning of SoC...
>
Oh? I didn't know libgit2 started as a SoC project.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git integration with monodevelop
From: Andreas Ericsson @ 2008-11-13 7:55 UTC (permalink / raw)
To: Michael Hutchinson; +Cc: monodevelop-list, Git Mailing List, Shawn Pearce
In-Reply-To: <aec34c770811121556y34465436i9ffb5e29dbf203a7@mail.gmail.com>
Michael Hutchinson wrote:
> 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.
>
I'll look into it. One thing I'd love to see is a "bisect" command
from within the IDE. That's one of those things that would make the
first IDE implementing it simply sell itself to hackers and suits
alike. Besides, "bisect", once learned, is such an awesome tool that
coders will start to adapt their workflow just to get full benefit
from it.
>> 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.
>
What's considered "unmanaged"? (remember I'm a C# newbie here). Is it
stuff marked as "unsafe"? If so, there's a whole platoon of stuff to
re-implement, which is quite nuts. Iiuc, a "safe" way of implementing
unmanaged code is to always write to objects passed as parameters in
libgit2, like so:
int git_commit_get(git_commit *commit, git_oid *oid);
instead of
git_commit *git_commit_get(git_oid *oid);
as one can let git_commit be a class that gets instantiated and also
gc'd the normal way. libgit just has to make sure not to leak memory
and avoid side-effects, but that's good library design anyways, so
it's not as if C# integration would hurt libgit design.
I really think this would be a better approach that could make the C#
implementation stay on top of new features (such as the up-and-coming
v4 pack) a lot better than writing it from scratch.
libgit2 is intended to be portable to all unices as well as Windows
and Mac OS X, so there's no real problem there
>> 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)
It is.
> 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.
>
But who's going to write (and separately maintain) the 50k or so LoC
that will make up the git core lib in C#? It really is a waste of
resources, imo. Especially since libgit will get a lot of exercise,
whereas the C# code will get that of C#-based integrations only. I
have a feeling this would lead to bugs (or limitations) in the C#
implementation that the git community would be expected to deal with.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git svn branch
From: Michael J Gruber @ 2008-11-13 8:34 UTC (permalink / raw)
To: yb_Art; +Cc: git
In-Reply-To: <ac92b632-f300-4cbd-8450-6a908fc2c762@t39g2000prh.googlegroups.com>
yb_Art venit, vidit, dixit 13.11.2008 00:47:
> 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?
I don't know which version google code has, but git-svn is a perl script
which you can download directly from
http://repo.or.cz/w/git.git?a=blob_plain;f=git-svn.perl;hb=HEAD
Note that in git-svn.perl as downloaded you will have to adjust the
first few lines (maybe a uselib in the second line; @@GIT_VERSION@@) to
match what you have in your current git-svn. If your git is not too
ancient then current git-svn should work with it.
Actually, I think compiling yourself is easier...
Michael
^ permalink raw reply
* [BUG] fatal error during merge
From: Anders Melchiorsen @ 2008-11-13 9:22 UTC (permalink / raw)
To: git
It took a while to make a minimal test case for this, but I think that all
the below steps are required. It ends up with this message:
after/one: unmerged (e69de29bb2d1d6434b8b29ae775ad8c2e48c5391)
fatal: git write-tree failed to write a tree
and the file that was moved has disappeared from the working tree.
I have tested the script with Git 1.6.0.2, but the real scenario that made
this appear seems to also fail with master and next from git.git.
Cheers,
Anders.
Test script:
mkdir am-merge-fail
cd am-merge-fail
git init
mkdir before
touch before/one after
git add -A
git commit -minitial
rm -f after
git mv before after
git commit -mmove
git checkout -b parallel HEAD~
touch another
git add -A
git commit -mparallel
git merge master
^ permalink raw reply
* Re: git integration with monodevelop
From: Christian Hergert @ 2008-11-13 9:28 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: monodevelop-list, Shawn Pearce, Git Mailing List
In-Reply-To: <491BDD70.1080701@op5.se>
[-- Attachment #1.1: Type: text/plain, Size: 5568 bytes --]
By unmanaged, he means the [DllImport] which you would need to do the call
to the extern in the shared library.
Everyone that has chimed in has considered doing the git code before,
believe us when we say we've thought about wrapping C. In this case, it
will be far more flexible in C#. Especially since tools like silverlight do
not allow DllImport's.
However, its your time, and I'd love to see git support happen any way
possible.
-- Christian
On Wed, Nov 12, 2008 at 11:55 PM, Andreas Ericsson <ae@op5.se> wrote:
> Michael Hutchinson wrote:
> > 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.
> >
>
> I'll look into it. One thing I'd love to see is a "bisect" command
> from within the IDE. That's one of those things that would make the
> first IDE implementing it simply sell itself to hackers and suits
> alike. Besides, "bisect", once learned, is such an awesome tool that
> coders will start to adapt their workflow just to get full benefit
> from it.
>
> >> 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.
> >
>
> What's considered "unmanaged"? (remember I'm a C# newbie here). Is it
> stuff marked as "unsafe"? If so, there's a whole platoon of stuff to
> re-implement, which is quite nuts. Iiuc, a "safe" way of implementing
> unmanaged code is to always write to objects passed as parameters in
> libgit2, like so:
>
> int git_commit_get(git_commit *commit, git_oid *oid);
>
> instead of
>
> git_commit *git_commit_get(git_oid *oid);
>
> as one can let git_commit be a class that gets instantiated and also
> gc'd the normal way. libgit just has to make sure not to leak memory
> and avoid side-effects, but that's good library design anyways, so
> it's not as if C# integration would hurt libgit design.
>
> I really think this would be a better approach that could make the C#
> implementation stay on top of new features (such as the up-and-coming
> v4 pack) a lot better than writing it from scratch.
>
> libgit2 is intended to be portable to all unices as well as Windows
> and Mac OS X, so there's no real problem there
>
> >> 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)
>
> It is.
>
> > 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.
> >
>
> But who's going to write (and separately maintain) the 50k or so LoC
> that will make up the git core lib in C#? It really is a waste of
> resources, imo. Especially since libgit will get a lot of exercise,
> whereas the C# code will get that of C#-based integrations only. I
> have a feeling this would lead to bugs (or limitations) in the C#
> implementation that the git community would be expected to deal with.
>
> --
> Andreas Ericsson andreas.ericsson@op5.se
> OP5 AB www.op5.se
> Tel: +46 8-230225 Fax: +46 8-230231
> _______________________________________________
> Monodevelop-list mailing list
> Monodevelop-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/monodevelop-list
>
[-- Attachment #1.2: Type: text/html, Size: 7295 bytes --]
[-- Attachment #2: Type: text/plain, Size: 170 bytes --]
_______________________________________________
Monodevelop-list mailing list
Monodevelop-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/monodevelop-list
^ permalink raw reply
* Re: [PATCH] git-svn: Update git-svn to use the ability to place temporary files within repository directory
From: Eric Wong @ 2008-11-13 9:41 UTC (permalink / raw)
To: Marten Svanfeldt (dev); +Cc: msysgit, git
In-Reply-To: <491AE935.4040406@svanfeldt.com>
"Marten Svanfeldt (dev)" <developer@svanfeldt.com> wrote:
> This fixes git-svn within msys where Perl will provide temporary files
> with path such as /tmp while the git suit expects native Windows paths.
Ah, I completely didn't understand the related Git.pm patch from you
until I saw this sentence above.
Can you update that other patch and clarify this statement so it
makes sense to UNIX-only folks?
| This fixes issues when the Perl in use uses a different format for paths
| than in use by native code in the git tools such as msysgit with msys-perl.
Thanks,
--
Eric Wong
^ permalink raw reply
* Re: [PATCH 1/9 v4] bisect: add "git bisect replace" subcommand
From: Junio C Hamano @ 2008-11-13 9:46 UTC (permalink / raw)
To: Christian Couder; +Cc: Johannes Schindelin, git
In-Reply-To: <200811121515.48277.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> Le mercredi 12 novembre 2008, Junio C Hamano a écrit :
> ...
>> When you want to hunt for a bug, it is certainly possible that your tests
>> fail for a bug that is unrelated to what you are hunting for for a range
>> of commits. Borrowing from your picture:
>>
>> ...--O--A--X1--X2--...--Xn--B--...
>>
>> non of the commit marked as Xi may not be testable.
>>
>> But at that point, will you really spend time to rebuild history between
>> A and B by fixing an unrelated bug that hinders your bisect, so that you
>> can have a parallel history that is bisectable? I doubt anybody would.
>
> I think kernel developers and perhaps others do that somehow. I mean, there
> is the following text in the git-bisect(1) documentation:
>
> "
> You may often find that during bisect you want to have near-constant tweaks
> (e.g., s/#define DEBUG 0/#define DEBUG 1/ in a header file, or "revision
> that does not have this commit needs this patch applied to work around
> other problem this bisection is not interested in") applied to the revision
> being tested.
>
> To cope with such a situation, after the inner git-bisect finds the next
> revision to test, with the "run" script, you can apply that tweak before
> compiling,...
> "
>
> So we suggest that people patch at bisect time in case of problems. But I
> think creating a parallel branch should be better in the long run, because
> you can easily keep the work you did to make things easier to bisect and
> you can easily share it with other people working with you.
I strongly disagree.
Maybe you hit X2 which does have a breakage, and you would need to patch
up that one before being able to test for your bug, but after you say good
or bad on that one, the next pick will be far away from that Xi segment.
You will test many more revisions before you come back to X3 or X5. Why
should we force the users to fix all the commits in the segment "just in
case" somebody's bisect falls into the range before that actually happens?
In other words, unless the breakage you are hunting for exists between
point A and B that you cannot bisect for that other breakage, you won't
need to patch-up _every single revision_ in the range for the breakage.
Doing so beforehand is wasteful.
And if you know the range of A..B and the fix, the procedure to follow the
suggestion you quoted above from the doc can even be automated relatively
easily. Your "run" script would need to do two merge-base to see if the
version to be tested falls inside the range, and if so apply the known fix
before testing (and clean it up afterwards).
Come to think of it, you do not even need to have a custom run script.
How about an approach illustrated by this patch?
I think it also needs to call unapply_fixup when "bisect reset" is given
to clean up, but this is more about a possible approach and not about a
adding a polished and finished shiny new toy, so...
-- >8 --
bisect: use canned "fixup patch"
This allows you to have $GIT_DIR/bisect-fixup directory, populated with
"fixup" patch files. When revisions between A and B (inclusive) cannot be
tested for your bisection purpose because they have other unrelated
breakage whose fix is already known, you can store a fix-up patch in the
file whose name is A-B (the commit object name of A, a dash, then the
commit object name of B). When "git bisect" suggests you to test a
revision that falls in that range, the patch will automatically be
applied to the working tree, so that you can test with the known fix
already in place.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git-bisect.sh | 36 ++++++++++++++++++++++++++
t/t6035-bisect-fixup.sh | 64 +++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 100 insertions(+), 0 deletions(-)
diff --git c/git-bisect.sh w/git-bisect.sh
index 0d0e278..600d9aa 100755
--- c/git-bisect.sh
+++ w/git-bisect.sh
@@ -338,13 +338,48 @@ exit_if_skipped_commits () {
fi
}
+apply_fixup() {
+ >"$GIT_DIR/BISECT_FIXUP"
+ (
+ cd "$GIT_DIR" 2>/dev/null &&
+ find bisect-fixup -type f -print
+ ) |
+ while read _fixup
+ do
+ _btm=$(expr "$_fixup" : 'bisect-fixup/\([0-9a-f]*\)-[0-9a-f]*$') &&
+ _btm=$(git rev-parse --quiet --verify "$_btm" 2>/dev/null) &&
+ _top=$(expr "$_fixup" : 'bisect-fixup/[0-9a-f]*-\([0-9a-f]*\)$') &&
+ _top=$(git rev-parse --quiet --verify "$_top" 2>/dev/null) ||
+ continue
+ if test "z$(git merge-base $_btm "$1")" = z$_btm &&
+ test "z$(git merge-base "$1" $_top)" = "z$1"
+ then
+ echo "Applying $_fixup..."
+ git apply "$GIT_DIR/$_fixup" || exit 1
+ echo >>"$GIT_DIR/BISECT_FIXUP" "$_fixup"
+ fi
+ done
+}
+
+unapply_fixup() {
+ test -r "$GIT_DIR/BISECT_FIXUP" || return 0
+ @@PERL@@ -e "print reverse <>" "$GIT_DIR/BISECT_FIXUP" |
+ while read _fixup
+ do
+ echo "Unapplying $_fixup..."
+ git apply -R "$GIT_DIR/$_fixup" || exit
+ done
+}
+
bisect_checkout() {
+ unapply_fixup || exit ;# should not happen but try to be careful
_rev="$1"
_msg="$2"
echo "Bisecting: $_msg"
mark_expected_rev "$_rev"
git checkout -q "$_rev" || exit
git show-branch "$_rev"
+ apply_fixup "$_rev" || exit
}
is_among() {
@@ -532,6 +567,7 @@ bisect_clean_state() {
do
git update-ref -d $ref $hash || exit
done
+ rm -f "$GIT_DIR/BISECT_FIXUP" &&
rm -f "$GIT_DIR/BISECT_EXPECTED_REV" &&
rm -f "$GIT_DIR/BISECT_ANCESTORS_OK" &&
rm -f "$GIT_DIR/BISECT_LOG" &&
diff --git c/t/t6035-bisect-fixup.sh w/t/t6035-bisect-fixup.sh
new file mode 100755
index 0000000..4745b73
--- /dev/null
+++ w/t/t6035-bisect-fixup.sh
@@ -0,0 +1,64 @@
+#!/bin/sh
+# Copyright (c) 2008, Junio C Hamano
+
+test_description='bisect fixup'
+
+. ./test-lib.sh
+
+cat >test-fixup <<\EOF
+diff a/elif b/elif
+--- a/elif
++++ b/elif
+@@ -1 +1 @@
+-0
++Z
+EOF
+
+test_expect_success setup '
+ echo 0 >elif
+ git add elif
+ for i in 1 2 3 4 5 6 7 8 9
+ do
+ test_tick &&
+ echo $i >file &&
+ git add file &&
+ git commit -m $i &&
+ git tag t$i
+ done &&
+
+ mkdir ".git/bisect-fixup" &&
+
+ btm=$(git rev-parse --short t3) &&
+ top=$(git rev-parse --short t5) &&
+ cat test-fixup >".git/bisect-fixup/$btm-$top" &&
+
+ btm=$(git rev-parse --short t7) &&
+ top=$(git rev-parse --short t8) &&
+ sed -e "s|Z|A|" test-fixup >".git/bisect-fixup/$btm-$top"
+'
+
+test_expect_success 'bisect fixup' '
+ t1=$(git rev-parse t1) &&
+ t5=$(git rev-parse t5) &&
+ t6=$(git rev-parse t6) &&
+ t7=$(git rev-parse t7) &&
+ t9=$(git rev-parse t9) &&
+
+ git bisect start &&
+ test $(git rev-parse HEAD) = $t9 &&
+ git bisect bad t9 &&
+ test $(git rev-parse HEAD) = $t9 &&
+ git bisect good t1 &&
+ test $(git rev-parse HEAD) = $t5 &&
+ grep Z elif &&
+
+ git bisect good &&
+ test $(git rev-parse HEAD) = $t7 &&
+ grep A elif &&
+
+ git bisect bad &&
+ test $(git rev-parse HEAD) = $t6 &&
+ grep 0 elif
+'
+
+test_done
^ permalink raw reply related
* Re: [MonoDevelop] git integration with monodevelop
From: Andreas Ericsson @ 2008-11-13 11:01 UTC (permalink / raw)
To: Christian Hergert
Cc: Michael Hutchinson, monodevelop-list, Git Mailing List,
Shawn Pearce
In-Reply-To: <6d4a25b10811130128r4ebf60a4s5679d06961b92450@mail.gmail.com>
Christian Hergert wrote:
> By unmanaged, he means the [DllImport] which you would need to do the call
> to the extern in the shared library.
>
> Everyone that has chimed in has considered doing the git code before,
> believe us when we say we've thought about wrapping C. In this case, it
> will be far more flexible in C#. Especially since tools like silverlight do
> not allow DllImport's.
>
Well, browser plugins may have a fun time with git support, but it's so far
from my priority list I couldn't even poke it with a really long pole. The
fastest way forward is probably to hack on libgit2 and use C# micro-apps
to verify continually that the binding layer works properly, so that's what
I'll be doing. I should also state that while C# seems fun and all, my top
priority is to make the git library usable as quickly as possible so that
it can attract more attention from developers. That's why I think it's so
vitally important to get some few usable steps working fast (such as diffing
against the index, staging stuff for commit and creating a commit).
Once we have that much, basic IDE integration should be fairly easy, and
then people will want to do more so interest (hopefully from developers)
is likely to increase.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH (GITK)] gitk: Fix transient windows on Win32 and MacOS.
From: Paul Mackerras @ 2008-11-13 11:41 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: Johannes Sixt, git
In-Reply-To: <bb6f213e0811120236j7c65bfe4xf95f88df440cbafb@mail.gmail.com>
Alexander Gavrilov writes:
> I'm sorry, it is indeed applied over another patch (attached because I
> only have access to Gmail Web UI right now). These patches eventually
> come from two ends of one long series that has been gradually applied
> over the time, so I still think of them as a unit.
I applied the attached patch.
Thanks,
Paul.
^ permalink raw reply
* Re: [PATCH (GITK)] gitk: Fix transient windows on Win32 and MacOS.
From: Paul Mackerras @ 2008-11-13 11:41 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git
In-Reply-To: <200811112355.43352.angavrilov@gmail.com>
Alexander Gavrilov writes:
> Transient windows cause problems on these platforms:
>
> - On Win32 the windows appear in the top left corner
> of the screen. In order to fix it, this patch causes
> them to be explicitly centered on their parents by
> an idle handler.
>
> - On MacOS with Tk 8.4 they appear without a title bar.
> Since it is clearly unacceptable, this patch disables
> transient on that platform.
>
> Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Thanks, applied.
Paul.
^ permalink raw reply
* Re: [PATCH (GITK)] gitk: Fix commit encoding support.
From: Paul Mackerras @ 2008-11-13 11:42 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git
In-Reply-To: <bb6f213e0811100406l2fcde5b8k8772360947b948fd@mail.gmail.com>
Alexander Gavrilov writes:
> If all commits were loaded through cat-file, that would be the way to
> go. Otherwise, when one code path uses one method of conversion, and
> another one, which is used rarely and semi-randomly, a different
> method, it may lead to confusing results if something goes slightly
> wrong.
OK, that makes sense. I applied the patch with a paragraph added to
the description that explains that.
Thanks,
Paul.
^ permalink raw reply
* [PATCH fixed] Git.pm: Make _temp_cache use the repository directory
From: Marten Svanfeldt (dev) @ 2008-11-13 12:04 UTC (permalink / raw)
To: msysgit, git, Eric Wong
Update the usage of File::Temp->tempfile to place the temporary files
within the repository directory instead of just letting Perl decide what
directory to use, given there is a repository specified when requesting
the temporary file.
This is needed to be able to fix git-svn on msys as msysperl generates
paths with UNIX-style paths (/tmp/xxx) while the git tools expect natvie
path format (c:/..). The repository dir is stored in native format so by
using it as the base directory for temporary files we always get a
usable native full path.
Signed-off-by: Marten Svanfeldt <developer@svanfeldt.com>
---
Hi,
Reworked the second part of the commit message after comments to make it
more obvious why this patch is needed.
perl/Git.pm | 15 ++++++++++-----
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/perl/Git.pm b/perl/Git.pm
index 6aab712..4b71dad 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -961,9 +961,7 @@ issue.
=cut
sub temp_acquire {
- my ($self, $name) = _maybe_self(@_);
-
- my $temp_fd = _temp_cache($name);
+ my $temp_fd = _temp_cache(@_);
$TEMP_FILES{$temp_fd}{locked} = 1;
$temp_fd;
@@ -1005,7 +1003,7 @@ sub temp_release {
}
sub _temp_cache {
- my ($name) = @_;
+ my ($self, $name) = _maybe_self(@_);
_verify_require();
@@ -1022,9 +1020,16 @@ sub _temp_cache {
"' was closed. Opening replacement.";
}
my $fname;
+
+ my $tmpdir;
+ if (defined $self) {
+ $tmpdir = $self->repo_path();
+ }
+
($$temp_fd, $fname) = File::Temp->tempfile(
- 'Git_XXXXXX', UNLINK => 1
+ 'Git_XXXXXX', UNLINK => 1, DIR => $tmpdir,
) or throw Error::Simple("couldn't open new temp file");
+
$$temp_fd->autoflush;
binmode $$temp_fd;
$TEMP_FILES{$$temp_fd}{fname} = $fname;
--
1.6.0.3.1439.gc9385a.dirty
^ permalink raw reply related
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