* Re: Excluding files from git-diff
From: Jeff King @ 2008-10-18 15:59 UTC (permalink / raw)
To: Christian Jaeger; +Cc: Michael J Gruber, Erik Hahn, git
In-Reply-To: <48F8BDA7.50901@pflanze.mine.nu>
On Fri, Oct 17, 2008 at 06:30:31PM +0200, Christian Jaeger wrote:
> For me, adding entries to that file does not make "git diff" or "gitk" or
> even "git ls-files" ignore files matching the entries. Only "git ls-files
> --others --exclude-from=.git/info/exclude" will exclude them. And "git
> diff " and gitk don't seem to know the --exclude-from option.
What you are seeing is:
- ls-files is plumbing, and does not do any exclusion by default. So
you need to use the --exclude-from option, or more easily,
--exclude-standard (which pulls in .git/info/excludes, .gitignore,
and user-level excludes).
- porcelain _does_ do exclusion. However, exclusion does not mean "if
this file is tracked by git, don't include it in the diff." It
merely means "if this file is untracked, pretend like it is not
there." So a diff displayed by "git diff" isn't affected by
exclusions anyway.
> Is there a way to really invert the patterns given to "git diff" or
> alike? I.e. instead of saying "git diff -- * .somedotfile
> .someothernongitignoredotfile" one could just say something like "git
> diff --invert-matches -- .gitignore"? And even better, could one
> configure some such so that it has effect on all tools by default?
No, I don't think there is a way to do that currently. I would probably
generate the file list with a shell snippet:
git diff -- `git ls-files | grep -v .gitignore`
but obviously that is a lot more typing if this is something you are
doing frequently.
-Peff
^ permalink raw reply
* Re: git-svn crashing perl
From: Heinrich Nirschl @ 2008-10-18 16:05 UTC (permalink / raw)
To: Alex Bennee; +Cc: git
In-Reply-To: <b2cdc9f30810180642n22b800ddg244555bf788a83bc@mail.gmail.com>
On Sat, Oct 18, 2008 at 3:42 PM, Alex Bennee <kernel-hacker@bennee.com> wrote:
> Hi,
>
> Doing a git-sv fetch --fetch-all is generating a SEGV in perl while I
> try and update my repo. Although I can look at the backtrace in perl
> it doesn't really tell me much. Any tips on how I can get more info?
>
This seems to be a problem of the subversion perl bindings. See for example:
http://subversion.tigris.org/issues/show_bug.cgi?id=3007
^ permalink raw reply
* Re: Excluding files from git-diff
From: Christian Jaeger @ 2008-10-18 16:08 UTC (permalink / raw)
To: Jeff King; +Cc: Michael J Gruber, Erik Hahn, git
In-Reply-To: <20081018155912.GA20387@coredump.intra.peff.net>
Jeff King wrote:
> No, I don't think there is a way to do that currently. I would probably
> generate the file list with a shell snippet:
>
> git diff -- `git ls-files | grep -v .gitignore`
>
> but obviously that is a lot more typing if this is something you are
> doing frequently.
The problem with this is that it won't show files that aren't there
anymore but have been previously; in general, for that to work (also
with git log, for example), the list of files would need to include all
paths which have ever existed and which are not to be excluded. Even
then, I'm not sure whether there are corner case where it would not work
(when files are being renamed, for example?).
If I/we (after finishing my intergit-find-matching-commit-in experiment)
finally decide that tracking generated files in the same repository is
the right thing to do, then I guess the only way to ignore those cleanly
would be to add an inverse match feature to the Git core.
Christian.
^ permalink raw reply
* Re: Excluding files from git-diff
From: Jeff King @ 2008-10-18 16:14 UTC (permalink / raw)
To: Christian Jaeger; +Cc: Michael J Gruber, Erik Hahn, git
In-Reply-To: <48FA0A17.9050506@pflanze.mine.nu>
On Sat, Oct 18, 2008 at 06:08:55PM +0200, Christian Jaeger wrote:
> The problem with this is that it won't show files that aren't there
> anymore but have been previously; in general, for that to work (also with
Yes, you're right. You really do want to be telling git not "here is the
list of files I care about" but "I really care about anything _except_
this set".
And I don't think that is currently possible, so a patch would be
necessary (and I think is justified, since there is no other way to do
it).
The most flexible thing would be the ability to say "I want these paths
(or all paths), and exclude these paths" (sort of like we already do for
commits). But defining a good command-line syntax for that would
probably be painful, and I really think the only sane use case is "I
want all paths except for these". In which case your "--invert-match"
seems like a good route.
-Peff
^ permalink raw reply
* Re: Excluding files from git-diff
From: Jeff King @ 2008-10-18 16:58 UTC (permalink / raw)
To: Christian Jaeger; +Cc: Michael J Gruber, Erik Hahn, git
In-Reply-To: <20081018161424.GC20185@coredump.intra.peff.net>
On Sat, Oct 18, 2008 at 12:14:24PM -0400, Jeff King wrote:
> The most flexible thing would be the ability to say "I want these paths
> (or all paths), and exclude these paths" (sort of like we already do for
> commits). But defining a good command-line syntax for that would
> probably be painful, and I really think the only sane use case is "I
> want all paths except for these". In which case your "--invert-match"
> seems like a good route.
I looked at this a little, so here's as far as I got, in case it helps
you in writing a patch.
There are actually two ways the limiter is used:
1. diff will show only a subset of the paths, as contained in a
diff_options.paths variable
2. the revision walker will prune based based on changes in particular
paths (e.g., "git log --invert-path -- .gitignore" should show only
commits that touch something besides .gitignore)
The code to handle '1' might look something like the patch below, but
this doesn't deal at all with revision pruning.
---
diff --git a/diff.c b/diff.c
index 1c6be89..a72f593 100644
--- a/diff.c
+++ b/diff.c
@@ -2646,6 +2646,8 @@ int diff_opt_parse(struct diff_options *options, const char **av, int ac)
DIFF_OPT_CLR(options, ALLOW_EXTERNAL);
else if (!strcmp(arg, "--ignore-submodules"))
DIFF_OPT_SET(options, IGNORE_SUBMODULES);
+ else if (!strcmp(arg, "--invert-path"))
+ DIFF_OPT_SET(options, INVERT_PATH);
/* misc options */
else if (!strcmp(arg, "-z"))
diff --git a/diff.h b/diff.h
index a49d865..43f3bff 100644
--- a/diff.h
+++ b/diff.h
@@ -65,6 +65,7 @@ typedef void (*diff_format_fn_t)(struct diff_queue_struct *q,
#define DIFF_OPT_IGNORE_SUBMODULES (1 << 18)
#define DIFF_OPT_DIRSTAT_CUMULATIVE (1 << 19)
#define DIFF_OPT_DIRSTAT_BY_FILE (1 << 20)
+#define DIFF_OPT_INVERT_PATH (1 << 21)
#define DIFF_OPT_TST(opts, flag) ((opts)->flags & DIFF_OPT_##flag)
#define DIFF_OPT_SET(opts, flag) ((opts)->flags |= DIFF_OPT_##flag)
#define DIFF_OPT_CLR(opts, flag) ((opts)->flags &= ~DIFF_OPT_##flag)
diff --git a/tree-diff.c b/tree-diff.c
index 9f67af6..ef78d91 100644
--- a/tree-diff.c
+++ b/tree-diff.c
@@ -91,7 +91,7 @@ static int compare_tree_entry(struct tree_desc *t1, struct tree_desc *t2, const
* - zero for no
* - negative for "no, and no subsequent entries will be either"
*/
-static int tree_entry_interesting(struct tree_desc *desc, const char *base, int baselen, struct diff_options *opt)
+static int tree_entry_interesting_internal(struct tree_desc *desc, const char *base, int baselen, struct diff_options *opt)
{
const char *path;
const unsigned char *sha1;
@@ -190,6 +190,17 @@ static int tree_entry_interesting(struct tree_desc *desc, const char *base, int
return never_interesting; /* No matches */
}
+static int tree_entry_interesting(struct tree_desc *desc, const char *base, int baselen, struct diff_options *opt)
+{
+ int r = tree_entry_interesting_internal(desc, base, baselen, opt);
+ if (!DIFF_OPT_TST(opt, INVERT_PATH))
+ return r;
+ return r < 0 ? 2 :
+ r == 0 ? 1 :
+ r == 1 ? 0 :
+ /* r > 1 */ -1;
+}
+
/* A whole sub-tree went away or appeared */
static void show_tree(struct diff_options *opt, const char *prefix, struct tree_desc *desc, const char *base, int baselen)
{
^ permalink raw reply related
* Re: Weird filename encoding issue
From: Johannes Sixt @ 2008-10-18 17:51 UTC (permalink / raw)
To: agladysh; +Cc: msysGit, git
In-Reply-To: <c6c947f60810172322o12beeb80xfd39b551b0db7c99@mail.gmail.com>
On Samstag, 18. Oktober 2008, Alexander Gladysh wrote:
> 1. Git hooks do not work under msysgit.
This is new to me. Why are you saying that? (IOW, please be more precise with
your description. We can't help you if all you tell us is "Does not work" .)
-- Hannes
^ permalink raw reply
* Re: [PATCH] force_object_loose: Fix memory leak
From: Junio C Hamano @ 2008-10-18 18:08 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Nicolas Pitre, git
In-Reply-To: <alpine.LFD.2.00.0810172105030.26244@xanadu.home>
Thanks.
^ permalink raw reply
* Re: [PATCH] Documentation: diff-filter=T only tests for symlink changes
From: Junio C Hamano @ 2008-10-18 18:08 UTC (permalink / raw)
To: Anders Melchiorsen; +Cc: git
In-Reply-To: <87vdvq5lu4.fsf_-_@cup.kalibalik.dk>
Thanks.
^ permalink raw reply
* Re: [PATCH] contrib: update packinfo.pl to not use dashed commands
From: Junio C Hamano @ 2008-10-18 18:08 UTC (permalink / raw)
To: Dan McGee; +Cc: git
In-Reply-To: <1224297678-8818-1-git-send-email-dpmcgee@gmail.com>
Thanks.
^ permalink raw reply
* Re: [PATCH] Documentation: diff-filter=T only tests for symlink changes
From: Junio C Hamano @ 2008-10-18 18:37 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Anders Melchiorsen, git
In-Reply-To: <20081018224045.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting Anders Melchiorsen <mail@cup.kalibalik.dk>:
>
>> diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
>> index 7788d4f..7604a13 100644
>> --- a/Documentation/diff-options.txt
>> +++ b/Documentation/diff-options.txt
>> @@ -137,7 +137,7 @@ endif::git-format-patch[]
>> --diff-filter=[ACDMRTUXB*]::
>> Select only files that are Added (`A`), Copied (`C`),
>> Deleted (`D`), Modified (`M`), Renamed (`R`), have their
>> - type (mode) changed (`T`), are Unmerged (`U`), are
>> + type (symlink/regular file) changed (`T`), are Unmerged (`U`), are
>> Unknown (`X`), or have had their pairing Broken (`B`).
>> Any combination of the filter characters may be used.
>> When `*` (All-or-none) is added to the combination, all
>> --
>> 1.6.0.2.514.g23abd3
>
> Are symlinks and regular files the only kind of object you can see in
> diff? What happens when a file or directory changes to a submodule?
Oops. I've already applied Anders's patch, but you are right. A change
from a blob to submodule also shows up as a typechange event.
Perhaps we should just remove the parenthesised comment from there
instead. I'll rewind and rebuild, as I haven't pushed the results out
yet (lucky me).
^ permalink raw reply
* Re: [PATCH] feature request: git-mergetool --force
From: William Pursell @ 2008-10-18 18:44 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20081018154824.GA20185@coredump.intra.peff.net>
Jeff King wrote:
> On Sat, Oct 18, 2008 at 12:23:05AM +0100, William Pursell wrote:
>
>> I occasionally use commands like 'cp $REMOTE $MERGED' with
>> mergetool, and would prefer to not be prompted to start
>> the tool on each file. A --force option would be handy.
>
> I think it is reasonable to want to skip this prompt, but I am not sure
> "--force" is the right name for such an option. Usually we reserve
> --force for "the tool is trying to prevent something destructive or
> unusual, and the user wants to override it".
>
> Something like --no-prompt makes more sense to me, though probably
> something a little easier to type would be nice (or maybe alias "-n").
Actually, perhaps an "interactive=no" configuration setting,
which might imply trustExitCode = true.
--
William Pursell
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2008, #03; Tue, 14)
From: Johannes Sixt @ 2008-10-18 20:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Petr Baudis
In-Reply-To: <48F5AB87.4080409@viscovery.net>
On Mittwoch, 15. Oktober 2008, Johannes Sixt wrote:
> Junio C Hamano schrieb:
> > * pb/rename-rowin32 (Sun Oct 12 21:01:23 2008 -0700) 2 commits
> > - (squash): index-pack: do not unconditionally make packfile read-
> > only
> > - Do not rename read-only files during a push
> >
> > Supposedly fixes pack file renames on Windows. The (squash) patch is my
> > attempt to fix its breakage.
>
> I'm afraid I can't reproduce the problem that the commit message
> describes.
On a different system I was able to reproduce the problem, and this patch
fixes it.
I tried to fix the breakage in the compat layer, but the result was too
fragile (change the source to read-write before that operation, change to
read-only afterwards), and this patch (including your fixup) looks much
cleaner.
-- Hannes
^ permalink raw reply
* [PATCH] Git.pm: do not break inheritance
From: Christian Jaeger @ 2008-10-18 18:25 UTC (permalink / raw)
To: git; +Cc: Petr Baudis
Make it possible to write subclasses of Git.pm
Signed-off-by: Christian Jaeger <christian@jaeger.mine.nu>
---
I don't really know what the reason for the _maybe_self behaviour
was; I'm hoping this fix doesn't break anything, I haven't run any
tests with it except with my own code; the fix works on the
assumptions that if an object does indeed have Git.pm in it's
ancestry, _maybe_self should work just as if the object is a 'Git'
object without inheritance.
I'm currently using the following hack to make my scripts be able to
inherit from a non-patched Git.pm: I inherit instead from a wrapper
around Git.pm which inherits from and patches the latter at runtime
using this code:
if (do {
my @res= Git::_maybe_self ( (bless {}, __PACKAGE__) );
not $res[0]
}) {
#warn "patching Git.pm";#
no warnings;
*Git::_maybe_self= sub {
UNIVERSAL::isa($_[0], 'Git') ? @_ : (undef, @_);
}
}
While this currently works, a proper fix would of course be
preferable (like: when in the future will the above hack break?..).
perl/Git.pm | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/perl/Git.pm b/perl/Git.pm
index 6aab712..ba94453 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -1203,8 +1203,7 @@ either version 2, or (at your option) any later version.
# the method was called upon an instance and (undef, @args) if
# it was called directly.
sub _maybe_self {
- # This breaks inheritance. Oh well.
- ref $_[0] eq 'Git' ? @_ : (undef, @_);
+ UNIVERSAL::isa($_[0], 'Git') ? @_ : (undef, @_);
}
# Check if the command id is something reasonable.
--
1.6.0.2
^ permalink raw reply related
* What's in git.git (Oct 2008, #04; Sat, 18)
From: Junio C Hamano @ 2008-10-18 20:35 UTC (permalink / raw)
To: git
Hopefully what's in 'maint' today can become 1.6.0.3 soon, perhaps in mid
next week.
* The 'maint' branch has these fixes since the last announcement.
Björn Steinbrink (1):
force_object_loose: Fix memory leak
Brandon Casey (4):
remote.c: correct the check for a leading '/' in a remote name
t4018-diff-funcname: rework negated last expression test
t4018-diff-funcname: demonstrate end of line funcname matching flaw
xdiff-interface.c: strip newline (and cr) from line before pattern
matching
Dan McGee (1):
contrib: update packinfo.pl to not use dashed commands
Daniel Barkalow (1):
Check early that a new branch is new and valid
Jeff King (1):
tests: shell negation portability fix
Jonas Fonseca (1):
git-check-attr(1): add output and example sections
Junio C Hamano (3):
Update draft release notes to 1.6.0.3
diff(1): clarify what "T"ypechange status means
Hopefully the final draft release notes update before 1.6.0.3
Matt McCutchen (1):
t1301-shared-repo.sh: don't let a default ACL interfere with the test
Mikael Magnusson (1):
Typo "does not exists" when git remote update remote.
Miklos Vajna (1):
Add testcase to ensure merging an early part of a branch is done properly
* The 'master' branch has these since the last announcement
in addition to the above.
Andreas Ericsson (1):
git commit: Reformat output somewhat
Brandon Casey (1):
t4018-diff-funcname: add objective-c xfuncname pattern to syntax test
Jeff King (3):
reformat informational commit message
tutorial: update output of git commit
tests: shell negation portability fix
Junio C Hamano (2):
Update draft release notes to 1.6.1
Update draft release notes for 1.6.1
Miklos Vajna (1):
Add Linux PPC support to the pre-auto-gc example hook
Pieter de Bie (1):
builtin-commit.c: show on which branch a commit was added
^ permalink raw reply
* What's cooking in git.git (Oct 2008, #04; Sat, 18)
From: Junio C Hamano @ 2008-10-18 20:36 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.
----------------------------------------------------------------
[New Topics]
* jc/gitweb-fix-cloud-tag (Tue Oct 14 21:27:12 2008 -0700) 1 commit
+ Fix reading of cloud tags
* rs/alloc-ref (Sat Oct 18 10:44:18 2008 +0200) 3 commits
+ make alloc_ref_from_str() the new alloc_ref()
+ use alloc_ref_from_str() everywhere
+ add alloc_ref_with_prefix()
* jc/maint-reset-remove-unmerged-new (Wed Oct 15 16:00:06 2008 -0700) 1 commit
- reset --hard/read-tree --reset -u: remove unmerged new paths
* jk/fix-ls-files-other (Fri Oct 17 13:03:52 2008 -0700) 2 commits
+ Merge branch 'jk/maint-ls-files-other' into jk/fix-ls-files-other
+ refactor handling of "other" files in ls-files and status
* jc/maint-co-track (Fri Oct 17 15:44:39 2008 -0700) 4 commits
- Fix checkout not to clobber the branch when using symlinked HEAD
upon detaching
- Enhance hold_lock_file_for_{update,append}() API
- demonstrate breakage of detached checkout with symbolic link HEAD
- Fix "checkout --track -b newbranch" on detached HEAD
* jk/maint-ls-files-other (Thu Oct 16 11:07:26 2008 -0400) 1 commit
+ refactor handling of "other" files in ls-files and status
* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
+ merge: remove deprecated summary and diffstat options and config
variables
* np/index-pack (Fri Oct 17 15:57:58 2008 -0400) 2 commits
+ index-pack: smarter memory usage during delta resolution
+ index-pack: rationalize delta resolution code
----------------------------------------------------------------
[Graduated to "master"]
* pb/commit-where (Fri Oct 3 22:13:49 2008 -0400) 4 commits
+ tutorial: update output of git commit
+ reformat informational commit message
+ git commit: Reformat output somewhat
+ builtin-commit.c: show on which branch a commit was added
----------------------------------------------------------------
[Needs review]
* 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
----------------------------------------------------------------
[Dropped]
* pb/submodule (Fri Sep 12 23:09:19 2008 +0200) 1 commit
. t7400: Add short "git submodule add" testsuite
Was waiting for a reroll.
* kb/am-directory (Fri Aug 29 15:27:50 2008 -0700) 1 commit
. git-am: Pass the --directory option through to git-apply
I think this is still buggy and drops the option when am stops with
conflicts.
----------------------------------------------------------------
[Stalled]
* bd/blame (Thu Aug 21 18:22:01 2008 -0500) 5 commits
- Use xdiff caching to improve git blame performance
- Allow xdiff machinery to cache hash results for a file
- Always initialize xpparam_t to 0
- Bypass textual patch generation and parsing in git blame
- Allow alternate "low-level" emit function from xdl_diff
Réne had good comments on how the callback should be structured.
Waiting for a reroll.
----------------------------------------------------------------
[Will be merged to 'master' soon]
* js/maint-fetch-update-head (Tue Oct 14 15:32:20 2008 -0700) 2 commits
+ pull: allow "git pull origin $something:$current_branch" into an
unborn branch
+ Fix fetch/pull when run without --update-head-ok
* ns/rebase-noverify (Tue Oct 14 08:17:16 2008 +0900) 2 commits
+ rebase: Document --no-verify option to bypass pre-rebase hook
+ rebase --no-verify
This adds --no-verify to git rebase, to avoid the pre-rebase hook.
* mv/merge-noff (Fri Oct 3 14:04:47 2008 +0200) 1 commit
+ builtin-commit: use reduce_heads() only when appropriate
Fixes "git merge --no-ff --no-commit".
* ae/preservemerge (Mon Sep 29 22:28:57 2008 +0200) 1 commit
+ rebase: Support preserving merges in non-interactive mode
* pb/rename-rowin32 (Fri Oct 3 12:20:43 2008 +0200) 1 commit
+ Do not rename read-only files during a push
Fixes pack file renames on Windows.
* sp/describe-lwtag (Mon Oct 13 07:39:46 2008 -0700) 1 commit
+ describe: Make --tags and --all match lightweight tags more often
When the user gives --tags, the request is asking to treat lightweight and
annotated tags at equal weight, and if lightweight ones are closer, they
should be used.
* gb/formatpatch-autonbr (Thu Oct 2 16:55:39 2008 -0400) 1 commit
+ format-patch: autonumber by default
* dp/checkattr (Wed Oct 15 09:11:52 2008 +0200) 3 commits
+ git-check-attr(1): use 'verse' for multi-line synopsis sections
+ check-attr: Add --stdin option
+ check-attr: add an internal check_attr() function
Batch attr lookup via --stdin, for gitk and git-gui.
* gb/refactor-pathinfo (Fri Oct 10 20:42:26 2008 +0200) 1 commit
+ gitweb: refactor input parameters parse/validation
A major cleanup on the way gitweb parses its input arguments.
Future gitweb patches to add more arguments into the PATH_INFO
depend upon this initial cleanup work.
* ml/cygwin-filemode (Mon Oct 13 00:33:31 2008 -0400) 1 commit
+ compat/cygwin.c - Use cygwin's stat if core.filemode == true
* mv/clonev (Thu Oct 9 01:40:32 2008 +0200) 1 commit
+ Implement git clone -v
Does what it says it does. This may be ready for master soon,
its a pretty trivial change.
----------------------------------------------------------------
[Actively Cooking]
* tr/workflow-doc (Sat Sep 13 18:11:01 2008 +0200) 2 commits
+ Documentation: Refer to git-rebase(1) to warn against rewriting
+ Documentation: new upstream rebase recovery section in git-rebase
Expecting an update.
* sh/maint-rebase3 (Sun Oct 5 23:26:52 2008 -0500) 1 commit
+ rebase--interactive: fix parent rewriting for dropped commits
* sh/rebase-i-p (Wed Oct 15 02:44:40 2008 -0500) 8 commits
- rebase-i-p: if todo was reordered use HEAD as the rewritten parent
- rebase-i-p: do not include non-first-parent commits touching
UPSTREAM
- rebase-i-p: only list commits that require rewriting in todo
- rebase-i-p: fix 'no squashing merges' tripping up non-merges
- rebase-i-p: delay saving current-commit to REWRITTEN if squashing
- rebase-i-p: use HEAD for updating the ref instead of mapping
OLDHEAD
- rebase-i-p: test to exclude commits from todo based on its parents
+ rebase--interactive: fix parent rewriting for dropped commits
Changes the `rebase -i -p` behavior to behave like git sequencer's
rewrite of `rebase -i` would behave.
* jk/diff-convfilter (Sun Oct 5 17:43:45 2008 -0400) 4 commits
+ diff: add filter for converting binary to text
+ diff: introduce diff.<driver>.binary
+ diff: unify external diff and funcname parsing code
+ t4012: use test_cmp instead of cmp
A general cleanup on how diff drivers are implemented. Its still
missing documentation updates and tests but doesn't break anything
current as far as I can tell.
* jn/gitweb-customlinks (Sun Oct 12 00:02:32 2008 +0200) 1 commit
- gitweb: Better processing format string in custom links in navbar
Waiting for some sort of response from Pasky.
----------------------------------------------------------------
[On Hold]
* jc/post-simplify (Fri Aug 15 01:34:51 2008 -0700) 2 commits
- revision --simplify-merges: incremental simplification
- revision --simplify-merges: prepare for incremental simplification
I started making this incremental but the progress is not
so great.
* 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.
* 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
* 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] Git.pm: do not break inheritance
From: Junio C Hamano @ 2008-10-18 20:50 UTC (permalink / raw)
To: Christian Jaeger; +Cc: git, Petr Baudis
In-Reply-To: <2980b5cead38d5ae3510e4ed9adc847c80be1075.1224360106.git.christian@jaeger.mine.nu>
Christian Jaeger <christian@jaeger.mine.nu> writes:
> Make it possible to write subclasses of Git.pm
>
> Signed-off-by: Christian Jaeger <christian@jaeger.mine.nu>
> ---
>
> I don't really know what the reason for the _maybe_self behaviour
> was; I'm hoping this fix doesn't break anything,
That's how you would write class methods, isn't it? IOW, your callers
can say:
my $self = new Git();
$self->method(qw(a b c));
Git::method(qw(a b c))
and you can start your method like this:
sub method {
my ($self, @args) = _maybe_self(@_)
...
}
and use @args the same way for either form of the call in the
implementation. Two obvious pitfalls are:
- You cannot use $self if you set up your parameters with _maybe_self;
- The second form of the call would call directly into Git::method, never
your subclasses implementation, even if you write:
use Git;
package CJGit;
our @ISA = qw(Git);
sub method {
...
}
> sub _maybe_self {
> - # This breaks inheritance. Oh well.
> - ref $_[0] eq 'Git' ? @_ : (undef, @_);
> + UNIVERSAL::isa($_[0], 'Git') ? @_ : (undef, @_);
> }
>
> # Check if the command id is something reasonable.
The patch looks Ok, as long as you have a working UNIVERSAL::isa() in your
version of Perl. My reading of perl561delta,pod says that Perl 5.6.1 and
later should have a working implementation.
^ permalink raw reply
* Re: [PATCH] feature request: git-mergetool --force
From: Jeff King @ 2008-10-18 20:54 UTC (permalink / raw)
To: William Pursell; +Cc: git
In-Reply-To: <48FA2E9F.3090305@gmail.com>
On Sat, Oct 18, 2008 at 07:44:47PM +0100, William Pursell wrote:
>> Something like --no-prompt makes more sense to me, though probably
>> something a little easier to type would be nice (or maybe alias "-n").
>
> Actually, perhaps an "interactive=no" configuration setting,
> which might imply trustExitCode = true.
That sounds reasonable to me.
-Peff
^ permalink raw reply
* Re: Git graph on GitHub
From: Jakub Narebski @ 2008-10-18 20:56 UTC (permalink / raw)
To: Tom Werner; +Cc: git
In-Reply-To: <530345950810150047v75bfbf9clebbb8a406b172c4c@mail.gmail.com>
"Tom Werner" <pubsub@rubyisawesome.com> writes:
> We've just pushed out an update to the Network Graph on GitHub this
> evening that finally allows us to draw very large repositories
> (including Git). We're mirroring the Git repo on the site and I
> thought it might be interesting for people to see this visualization.
> Enjoy!
>
> http://github.com/git/git/network
>
> Let me know if you have any ideas for improvements on the graph. I'm
> always looking for ways to enhance it.
First, I wonder a bit why did you choose horizontal layout of revision
graph, instead of displaying it vertically alongside log (log like
view) like graphical history viewers and other web interfaces offering
graphical log, e.g.
http://lwn.net/Articles/140350/ (gitk screenshoot)
http://repo.or.cz/git-browser/by-commit.html?r=alt-git.git
http://people.proekspert.ee/peeter/git/git.php?p=git-git.git
I guess it is because you can show complicated history better, and
because of the "network" feature which is simply not visible for
git.git repository. On the other hand in vertical view you can display
commit subject alongside graph.
Second, the "go to commit" on click doesn't work for me, but perhaps
that is just I have to update my ancient web browser (Mozilla 1.17.2
for Linux, with Shockwave Flash 9.0 r124). I would expect that after
clicking on commit I would get _whole_ commit message, not only commit
subject (first line / first paragraph of commit message). Or at least
have some option (keyboard shortcut?) to toggle viewing full commit
message. BTW. what does having commit sha-1 there give you? You
can't select it for copy'n'paste, can you?
Third, it is nice to have refs markers for branches, but I wonder why
I cannot see refs markers for _tags_ (so one can easily see what is in
released version, and what isn't). I also wonder why in commit
description box visible on mouseover you don't have refs markers there
(even if they are turned off for graph, for example for better
visibility because they obscure some line).
By the way, it might be not relevant because while (if I understand
correctly) graphs are ordered by commit date they are not aligned on
time axis, but the timeline of commits for given author on Ohloh looks
quite nice. (Unfortunately this part of Ohloh is not open source,
although AFAIK it is also in Ruby). Example:
https://www.ohloh.net/projects/git/contributors/1194000913727
(but it doesn't use Flash).
Thank you for your work on GitHub
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* git-svn url-encodes ~ when it should not
From: Björn Steinbrink @ 2008-10-18 21:39 UTC (permalink / raw)
To: Eric Wong; +Cc: git
Hi,
Jose Carlos Garcia Sogo reported on #git that a git-svn clone of this
svn repo fails for him:
https://sucs.org/~welshbyte/svn/backuptool/trunk
I can reproduce that here with:
git-svn version 1.6.0.2.541.g46dc1.dirty (svn 1.5.1)
The error message I get is:
Apache got a malformed URI: Unusable URI: it does not refer to this
repository at /usr/local/libexec/git-core/git-svn line 4057
strace revealed that git-svn url-encodes ~ while svn does not do that.
For svn we have:
write(5, "<S:update-report send-all=\"true\" xmlns:S=\"svn:\">
<S:src-path>https://sucs.org/~welshbyte/svn/backuptool/trunk</S:src-path>...
While git-svn shows:
write(7, "<S:update-report send-all=\"true\" xmlns:S=\"svn:\">
<S:src-path>https://sucs.org/%7Ewelshbyte/svn/backuptool/trunk</S:src-path>...
Björn
^ permalink raw reply
* Re: What is the pre-merge hook status?
From: Paolo Bonzini @ 2008-10-18 21:57 UTC (permalink / raw)
To: Alexander Gladysh; +Cc: git
In-Reply-To: <c6c947f60810172342n6843b173tb0019d0af706800d@mail.gmail.com>
Alexander Gladysh wrote:
> Hi, Paolo!
>
> What is the status of your pre-merge hook patch?
>
> http://article.gmane.org/gmane.comp.version-control.git/93888
>
> I think it can help me greatly with my repository management process.
I decided that it was a bad design for me at least, because the control
had better be implemented on the server (using an update hook). But I
can submit it if you need it for something.
Paolo
^ permalink raw reply
* Re: git-svn crashing perl
From: Alex Bennee @ 2008-10-18 22:00 UTC (permalink / raw)
To: Heinrich Nirschl; +Cc: git
In-Reply-To: <394ab6ec0810180905t5faca9cbnc7b73267a72deddc@mail.gmail.com>
On Sat, Oct 18, 2008 at 5:05 PM, Heinrich Nirschl
<heinrich.nirschl@gmail.com> wrote:
> On Sat, Oct 18, 2008 at 3:42 PM, Alex Bennee <kernel-hacker@bennee.com> wrote:
>> Hi,
>>
>> Doing a git-sv fetch --fetch-all is generating a SEGV in perl while I
>> try and update my repo. Although I can look at the backtrace in perl
>> it doesn't really tell me much. Any tips on how I can get more info?
>>
>
> This seems to be a problem of the subversion perl bindings. See for example:
> http://subversion.tigris.org/issues/show_bug.cgi?id=3007
>
Looks similar. libapr certainly seems to be breaking something:
Core was generated by `/usr/bin/perl
/home/alex/src/git.git/install/libexec/git-core/git-svn fetch --f'.
Program terminated with signal 11, Segmentation fault.
#0 0x00007fd0d813c370 in ?? ()
(gdb) bt
#0 0x00007fd0d813c370 in ?? ()
#1 0x00007fd0d9a52a5d in ?? () from /usr/lib/libapr-1.so.0
#2 0x00007fd0d9a53d9a in ?? () from /usr/lib/libapr-1.so.0
#3 0x00007fd0d9a54003 in ?? () from /usr/lib/libapr-1.so.0
#4 0x00007fd0d9a53d88 in ?? () from /usr/lib/libapr-1.so.0
#5 0x00007fd0d9a54003 in ?? () from /usr/lib/libapr-1.so.0
#6 0x00007fd0d9a540f3 in apr_pool_terminate () from /usr/lib/libapr-1.so.0
#7 0x00007fd0db1c6e83 in _wrap_apr_terminate () from
/usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux/auto/SVN/_Core/_Core.so
#8 0x000000000047dbab in Perl_pp_entersub ()
#9 0x00000000004677fa in Perl_runops_debug ()
#10 0x0000000000425ae8 in Perl_call_sv ()
#11 0x0000000000425faa in Perl_call_list ()
#12 0x000000000042a0e8 in perl_destruct ()
#13 0x0000000000422238 in main ()
--
Alex, homepage: http://www.bennee.com/~alex/
^ permalink raw reply
* Re: [PATCH] Git.pm: do not break inheritance
From: Christian Jaeger @ 2008-10-18 22:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Petr Baudis
In-Reply-To: <7vabd1aaqx.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> That's how you would write class methods, isn't it? IOW, your callers
> can say:
>
> my $self = new Git();
> $self->method(qw(a b c));
> Git::method(qw(a b c))
>
> and you can start your method like this:
>
> sub method {
> my ($self, @args) = _maybe_self(@_)
> ...
> }
>
> and use @args the same way for either form of the call in the
> implementation.
I see, a magic way to offer both an OO and procedural api. Well, partial
procedural api, since not all of the methods can work without the $self.
> Two obvious pitfalls are:
>
> - You cannot use $self if you set up your parameters with _maybe_self;
>
> - The second form of the call would call directly into Git::method, never
> your subclasses implementation, even if you write:
>
> use Git;
> package CJGit;
> our @ISA = qw(Git);
>
> sub method {
> ...
> }
>
>
(This is no problem iff people are calling procedures in object notation
if they actually have got an object at hands. I.e. if you've got some
code which does:
my $repo= Git->repository(...);
$repo->foo;
then all is fine, and I would think it would be weird if people called
Git::foo($repo, ... ) in such a case. Well for my purposes it's not a
problem anyway, since if a user wants to use the extensions, he needs to
actually do this:
my $repo= CJGit->repository(...);
and then it should be clear that one shouldn't call Git:: directly. The
problem will only be in cases where an extended object is being fed to
existing code which calls Git:: with objects in the hope that virtual
method calls are going to the extended class; well, let's fix those bad
call sites when they are being discovered... Maybe this warrants a
warning somewhere.)
>> sub _maybe_self {
>> - # This breaks inheritance. Oh well.
>> - ref $_[0] eq 'Git' ? @_ : (undef, @_);
>> + UNIVERSAL::isa($_[0], 'Git') ? @_ : (undef, @_);
>> }
>>
>> # Check if the command id is something reasonable.
>>
>
> The patch looks Ok, as long as you have a working UNIVERSAL::isa() in your
> version of Perl. My reading of perl561delta,pod says that Perl 5.6.1 and
> later should have a working implementation.
>
From http://perldoc.perl.org/perl561delta.html:
> UNIVERSAL::isa()
>
> A bug in the caching mechanism used by UNIVERSAL::isa() that affected
> base.pm has been fixed. The bug has existed since the 5.005 releases,
> but wasn't tickled by base.pm in those releases.
This looks like only a bug in some (corner?) cases; I've verified that
I've been using the isa() method *or* function since perl 5.005_03, and
haven't had issues with it. I can't easily verify though when I switched
from
#if (Scalar::Util::blessed($value) and $value->isa("Eile::Html")) {
to
if (UNIVERSAL::isa($value,"Eile::Html")) {
(because it was simpler to write, once I discovered that I could just
call the function directly instead of relying on method dispatch) but
that might not have made a difference.
Christian.
^ permalink raw reply
* Re: git-svn url-encodes ~ when it should not
From: Björn Steinbrink @ 2008-10-18 22:47 UTC (permalink / raw)
To: Eric Wong; +Cc: git, jsogo
In-Reply-To: <20081018213919.GC3107@atjola.homenet>
[Adding Jose to Cc:, didn't have his address earlier]
On 2008.10.18 23:39:19 +0200, Björn Steinbrink wrote:
> Hi,
>
> Jose Carlos Garcia Sogo reported on #git that a git-svn clone of this
> svn repo fails for him:
> https://sucs.org/~welshbyte/svn/backuptool/trunk
>
> I can reproduce that here with:
> git-svn version 1.6.0.2.541.g46dc1.dirty (svn 1.5.1)
>
> The error message I get is:
> Apache got a malformed URI: Unusable URI: it does not refer to this
> repository at /usr/local/libexec/git-core/git-svn line 4057
>
> strace revealed that git-svn url-encodes ~ while svn does not do that.
>
> For svn we have:
> write(5, "<S:update-report send-all=\"true\" xmlns:S=\"svn:\">
> <S:src-path>https://sucs.org/~welshbyte/svn/backuptool/trunk</S:src-path>...
>
> While git-svn shows:
> write(7, "<S:update-report send-all=\"true\" xmlns:S=\"svn:\">
> <S:src-path>https://sucs.org/%7Ewelshbyte/svn/backuptool/trunk</S:src-path>...
>
> Björn
^ permalink raw reply
* Re: [PATCH] feature request: git-mergetool --force
From: Charles Bailey @ 2008-10-18 23:16 UTC (permalink / raw)
To: Jeff King; +Cc: William Pursell, git
In-Reply-To: <20081018205443.GA29534@coredump.intra.peff.net>
Jeff King wrote:
> On Sat, Oct 18, 2008 at 07:44:47PM +0100, William Pursell wrote:
>
>>> Something like --no-prompt makes more sense to me, though probably
>>> something a little easier to type would be nice (or maybe alias "-n").
>> Actually, perhaps an "interactive=no" configuration setting,
>> which might imply trustExitCode = true.
>
> That sounds reasonable to me.
>
> -Peff
I've recently been using git mergetool quite a bit and I'm currently
cooking a couple of patches. The first, by coincidence, was a "-n"
option which disabled the hit-return-to-actually-do-anything prompt. I,
also, used the variable "NOPROMPT" to describe this behaviour.
The other change that I am working was more of an issue for me. When I
have a fair number of files to merge I sometimes want to skip a merge.
Perhaps it's a tricky one and I want do the easy wins first.
The current behaviour of mergetool is a little annoying for this as the
first 'failed' merge aborts the process and if you restart it will
always pick up from where it left off. If you want to do some of the
later files, you have to specify the full paths to mergetool which can
be a lot more typing.
The change I am implementing just continues after a failed merge (no git
add or anything, so the file stays unmerged) and allows you to merge
subsequent files. I think that this will work reasonably well allowing
you to do your merges in a number of passes, picking off the easy merges
first and doing the tricky ones later. You can also do a quick pass
through all the merges, not actually resolving everything just to see if
there are any show stoppers.
The only gotcha is that this may interact less well with a --no-prompt
option. With the prompt you can always abort the mergetool process with
a SIGINT at the prompt, even if mergetool now wants to offer you the
opportunity to merge subsequent files after aborting one particular file
merge. Without the prompt mergetool is going to spawn your merge tool
for every conflict even if you've changed your mind and want to abort.
Thoughts?
Charles.
^ permalink raw reply
* Re: [PATCHv6 1/5] gitweb: parse project/action/hash_base:filename PATH_INFO
From: Jakub Narebski @ 2008-10-18 22:41 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <1224188831-17767-2-git-send-email-giuseppe.bilotta@gmail.com>
On Thu, 16 Oct 2008, Giuseppe Bilotta wrote:
> This patch enables gitweb to parse URLs with more information embedded
> in PATH_INFO, reducing the need for CGI parameters. The typical gitweb
> path is now $project/$action/$hash_base:$file_name or
> $project/$action/$hash
>
> This is mostly backwards compatible with the old-style gitweb paths,
> $project/$branch[:$filename], except when it was used to access a branch
> whose name matches a gitweb action.
...in which case old code would access branch, and new code would treat
name as action. This shouldn't matter in practice, unless there are
branches named exactly as gitweb actions.
[But I think current commit description is enough. Just in case...]
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
I like it. For what it is worth:
Acked-by: Jakub Narebski <jnareb@gmail.com>
> ---
> gitweb/gitweb.perl | 37 +++++++++++++++++++++++++++++++------
> 1 files changed, 31 insertions(+), 6 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index c5254af..6d0dc26 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -534,23 +534,48 @@ sub evaluate_path_info {
> return if $input_params{'action'};
> $path_info =~ s,^\Q$project\E/*,,;
>
> + # next, check if we have an action
> + my $action = $path_info;
> + $action =~ s,/.*$,,;
> + if (exists $actions{$action}) {
> + $path_info =~ s,^$action/*,,;
> + $input_params{'action'} = $action;
> + }
> +
> + # list of actions that want hash_base instead of hash
...and can have no file_name ('f') parameter.
> + my @wants_base = (
> + 'tree',
> + 'history',
> + );
I like this solution. It makes path_info URL unambiguous: it is
<project>/log/<hash> (where <hash> is usually refname), and
<project>/tree/<hash_base> which is just shortcut for <project>/tree/<hash_base>:/
It means that the @wants_base list contains actions which require / use
$hash_base and $file_name, but $file_name might be not set, which denotes
top directory (root tree).
> +
> my ($refname, $pathname) = split(/:/, $path_info, 2);
> if (defined $pathname) {
> - # we got "project.git/branch:filename" or "project.git/branch:dir/"
> + # we got "branch:filename" or "branch:dir/"
> # we could use git_get_type(branch:pathname), but it needs $git_dir
Well, this comment was there... but actually I think we avoid
git_get_type("branch:pathname") because currently it is additional fork.
And with convention that filename part of path_info ends in '/' for
directories (quite sensible I think) it is not needed. Moreso after
next patch in series, when we state action explicitly, and the only
difference _might_ be for 'history' view (which is for directories
and for files both).
> $pathname =~ s,^/+,,;
> if (!$pathname || substr($pathname, -1) eq "/") {
> - $input_params{'action'} = "tree";
> + $input_params{'action'} ||= "tree";
> $pathname =~ s,/$,,;
> } else {
> - $input_params{'action'} = "blob_plain";
> + $input_params{'action'} ||= "blob_plain";
> }
> $input_params{'hash_base'} ||= $refname;
> $input_params{'file_name'} ||= $pathname;
> } elsif (defined $refname) {
> - # we got "project.git/branch"
> - $input_params{'action'} = "shortlog";
> - $input_params{'hash'} ||= $refname;
> + # we got "branch". in this case we have to choose if we have to
^ ^
|-|-- ??? (typo?)
> + # set hash or hash_base.
> + #
> + # Most of the actions without a pathname only want hash to be
> + # set, except for the ones specified in @wants_base that want
> + # hash_base instead. It should also be noted that hand-crafted
> + # links having 'history' as an action and no pathname or hash
> + # set will fail, but that happens regardless of PATH_INFO.
Ah, I see that the comment about what makes action to be put into
@wants_base is here.
> + $input_params{'action'} ||= "shortlog";
> + if (grep {$input_params{'action'} eq $_} @wants_base) {
Style: I would use here (but perhaps it is just me) for better
readibility
+ if (grep { $input_params{'action'} eq $_ } @wants_base) {
> + $input_params{'hash_base'} ||= $refname;
> + } else {
> + $input_params{'hash'} ||= $refname;
> + }
> }
> }
> evaluate_path_info();
> --
> 1.5.6.5
>
>
--
Jakub Narebski
Poland
^ 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