* Re: [PATCH 3/6] Glean libexec path from argv[0] for git-upload-pack and git-receive-pack.
From: Steffen Prohaska @ 2009-01-11 10:04 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Git Mailing List, Johannes Sixt,
Steve Haslam
In-Reply-To: <7viqomx5iq.fsf@gitster.siamese.dyndns.org>
On Jan 10, 2009, at 9:36 PM, Junio C Hamano wrote:
> Steffen Prohaska <prohaska@zib.de> writes:
>
>> On Jan 10, 2009, at 3:34 PM, Johannes Schindelin wrote:
>>
>>> Logically, and to avoid committing a broken revision, 1/6 should
>>> come
>>> last, methinks.
>>
>> RUNTIME_PREFIX is not defined before 6/6. But I agree,
>> 1/6 should probably be moved after 5/6.
>>
> Hmm, I actually was thinking about applying that (and that one only)
> early
> to my tree, to make sure it is regression-free.
Does "early" mean that you want to wait and see how the discussion
about the other patches evolves before you consider applying them,
or does "and that one only" mean that you tend to not apply the
other patches at all?
Steffen
^ permalink raw reply
* What's cooking in git.git (Jan 2009, #02; Sun, 11)
From: Junio C Hamano @ 2009-01-11 9:51 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 ones marked with '.' do not appear in any of the branches,
but I am still holding onto them.
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]
* rs/fgrep (Sat Jan 10 00:18:34 2009 +0100) 2 commits
+ grep: don't call regexec() for fixed strings
+ grep -w: forward to next possible position after rejected match
* lt/zlib-wrap-xprm (Wed Jan 7 19:54:47 2009 -0800) 1 commit
- Wrap inflateInit to retry allocation after releasing pack memory
Need to clean up the log message, perhaps rebase it to maint-1.6.0 and
start cooking in 'next'.
* jc/maint-format-patch (Sat Jan 10 12:41:33 2009 -0800) 1 commit
+ format-patch: show patch text for the root commit
* tr/maint-no-index-fixes (Wed Jan 7 12:15:30 2009 +0100) 3 commits
+ diff --no-index -q: fix endless loop
+ diff --no-index: test for pager after option parsing
+ diff: accept -- when using --no-index
* gb/gitweb-opml (Fri Jan 2 13:49:30 2009 +0100) 2 commits
- gitweb: suggest name for OPML view
- gitweb: don't use pathinfo for global actions
* mh/maint-commit-color-status (Thu Jan 8 19:53:05 2009 +0100) 2 commits
- git-status -v: color diff output when color.ui is set
- git-commit: color status output when color.ui is set
* ks/maint-mailinfo-folded (Thu Jan 8 01:43:42 2009 +0300) 1 commit
- mailinfo: correctly handle multiline 'Subject:' header
* js/patience-diff (Thu Jan 1 17:39:37 2009 +0100) 3 commits
- bash completions: Add the --patience option
- Introduce the diff option '--patience'
- Implement the patience diff algorithm
All of the above 'pu' topics are ready for 'next'.
* ap/clone-into-empty (Fri Jan 9 02:24:23 2009 +0300) 2 commits
- Use is_pseudo_dir_name everywhere
- Allow cloning to an existing empty directory
There is an updated patch that only refactors the repeated code to check
if a dirent is dot or dot-dot posted, which I should have picked up to
replace these but I haven't yet (the "clone into empty" can and should
build on top of it).
----------------------------------------------------------------
[Stalled and may need help and prodding to go forward]
* ds/uintmax-config (Mon Nov 3 09:14:28 2008 -0900) 1 commit
- autoconf: Enable threaded delta search when pthreads are supported
This automatically enables threaded delta search code when autoconf
detects pthreads are usable. I haven't heard neither positive nor
negative comments from minority platforms that might be harmed, but
this feels like the right thing to do, so perhaps the best course of
action is to merge this down to 'master' and see if anybody screams.
* 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
This gives Porcelains (like gitweb) the information on the commit _before_
the one that the final blame is laid on, which should save them one
rev-parse to dig further. The line number in the "previous" information
may need refining, and sanity checking code for reference counting may
need to be resurrected before this can move forward.
----------------------------------------------------------------
[Actively cooking]
* mv/apply-parse-opt (Fri Jan 9 22:21:36 2009 -0800) 2 commits
+ Resurrect "git apply --flags -" to read from the standard input
+ parse-opt: migrate builtin-apply.
* rs/maint-shortlog-foldline (Tue Jan 6 21:41:06 2009 +0100) 1 commit
+ shortlog: handle multi-line subjects like log --pretty=oneline et.
al. do
* tr/rebase-root (Fri Jan 2 23:28:29 2009 +0100) 4 commits
- rebase: update documentation for --root
- rebase -i: learn to rebase root commit
- rebase: learn to rebase root commit
- rebase -i: execute hook only after argument checking
I should be able to find time to read this over again and merge to
'next' sometime this week.
* as/autocorrect-alias (Sun Jan 4 18:16:01 2009 +0100) 1 commit
+ git.c: make autocorrected aliases work
* js/notes (Sat Dec 20 13:06:03 2008 +0100) 4 commits
- Add an expensive test for git-notes
- Speed up git notes lookup
- Add a script to edit/inspect notes
- Introduce commit notes
* sc/gitweb-category (Fri Dec 12 00:45:12 2008 +0100) 3 commits
- gitweb: Optional grouping of projects by category
- gitweb: Split git_project_list_body in two functions
- gitweb: Modularized git_get_project_description to be more generic
* gb/gitweb-patch (Thu Dec 18 08:13:19 2008 +0100) 4 commits
- gitweb: link to patch(es) view in commit(diff) and (short)log view
- gitweb: add patches view
- gitweb: change call pattern for git_commitdiff
- gitweb: add patch view
----------------------------------------------------------------
[Graduated to "master"]
* mh/maint-sendmail-cc-doc (Mon Dec 29 00:37:25 2008 +0100) 1 commit
+ doc/git-send-email: mention sendemail.cc config variable
* rs/diff-ihc (Sun Dec 28 19:45:32 2008 +0100) 1 commit
+ diff: add option to show context between close hunks
* js/maint-merge-recursive-r-d-conflict (Mon Dec 22 23:10:20 2008 +0100) 1 commit
+ merge-recursive: mark rename/delete conflict as unmerged
* mk/gitweb-feature (Mon Dec 15 22:16:19 2008 -0800) 1 commit
+ gitweb: unify boolean feature subroutines
* cb/merge-recursive-fix (Mon Dec 15 02:41:24 2008 -0800) 3 commits
+ Merge branch 'cb/maint-merge-recursive-fix' into cb/merge-
recursive-fix
+ merge-recursive: do not clobber untracked working tree garbage
+ modify/delete conflict resolution overwrites untracked file
* cb/maint-merge-recursive-fix (Sun Dec 14 19:40:09 2008 -0800) 2 commits
+ merge-recursive: do not clobber untracked working tree garbage
+ modify/delete conflict resolution overwrites untracked file
* wp/add-p-goto (Thu Dec 4 10:22:40 2008 +0000) 2 commits
+ Add 'g' command to go to a hunk
+ Add subroutine to display one-line summary of hunks
* jn/gitweb-blame (Thu Dec 11 01:33:29 2008 +0100) 3 commits
+ gitweb: cache $parent_commit info in git_blame()
+ gitweb: A bit of code cleanup in git_blame()
+ gitweb: Move 'lineno' id from link to row element in git_blame
* mv/um-pdf (Wed Dec 10 23:44:50 2008 +0100) 1 commit
+ Add support for a pdf version of the user manual
* kk/maint-http-push (Tue Dec 23 11:31:15 2008 +0300) 1 commit
+ http-push: support full URI in handle_remote_ls_ctx()
----------------------------------------------------------------
[Will merge to "master" soon]
* nd/grep-assume-unchanged (Sat Dec 27 15:21:03 2008 +0700) 2 commits
+ grep: grep cache entries if they are "assume unchanged"
+ grep: support --no-ext-grep to test builtin grep
* as/maint-shortlog-cleanup (Tue Dec 30 22:01:44 2008 +0100) 1 commit
+ builtin-shortlog.c: use string_list_append(), and don't strdup
unnecessarily
* jc/maint-ls-tree (Wed Dec 31 19:00:50 2008 +0900) 2 commits
+ Document git-ls-tree --full-tree
+ ls-tree: add --full-tree option
* js/bundle-tags (Fri Jan 2 19:08:46 2009 +0100) 1 commit
+ bundle: allow rev-list options to exclude annotated tags
* js/add-not-submodule (Fri Jan 2 19:08:40 2009 +0100) 1 commit
+ git add: do not add files from a submodule
* pb/maint-git-pm-false-dir (Mon Dec 29 01:25:00 2008 +0100) 1 commit
+ Git.pm: correctly handle directory name that evaluates to "false"
* pj/maint-ldflags (Sun Jan 4 21:27:41 2009 -0500) 1 commit
+ configure clobbers LDFLAGS
* fe/cvsserver (Fri Jan 2 16:40:14 2009 +0100) 2 commits
+ cvsserver: change generation of CVS author names
+ cvsserver: add option to configure commit message
* js/maint-bisect-gitk (Fri Jan 2 19:08:00 2009 +0100) 1 commit
+ bisect view: call gitk if Cygwin's SESSIONNAME variable is set
* np/no-loosen-prune-expire-now (Tue Dec 30 14:45:11 2008 -0500) 1 commit
+ objects to be pruned immediately don't have to be loosened
* cb/maint-unpack-trees-absense (Thu Jan 1 21:54:33 2009 +0100) 3 commits
+ unpack-trees: remove redundant path search in verify_absent
+ unpack-trees: fix path search bug in verify_absent
+ unpack-trees: handle failure in verify_absent
* mc/cd-p-pwd (Tue Dec 30 07:10:24 2008 -0800) 1 commit
+ git-sh-setup: Fix scripts whose PWD is a symlink to a work-dir on
OS X
* mh/cherry-default (Thu Jan 1 22:56:29 2009 +0100) 2 commits
+ Documentation: clarify which parameters are optional to git-cherry
+ git-cherry: make <upstream> parameter optional
----------------------------------------------------------------
[Will drop]
* as/commit-signoff (Mon Dec 29 12:16:45 2008 +0100) 1 commit
- [WIP] Add a commit.signoff configuration option to always use --
signoff in commit
The semantics when "git commit" was used as a backend for other actions
such as rebase and cherry-pick was unclear.
----------------------------------------------------------------
[On Hold]
* 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.
* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
- git-am --forge: add Signed-off-by: line for the author
- git-am: clean-up Signed-off-by: lines
- stripspace: add --log-clean option to clean up signed-off-by:
lines
- stripspace: use parse_options()
- Add "git am -s" test
- git-am: refactor code to add signed-off-by line for the committer
^ permalink raw reply
* Re: [PATCH/RFC v5 1/1] more cache effective symlink/directory detection
From: Kjetil Barvik @ 2009-01-11 8:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: René Scharfe, git
In-Reply-To: <7vljtivfao.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
>
>> Kjetil Barvik schrieb:
>>> - Also introduce a 'void clear_lstat_cache(void)' function, which
>>> should be used to clean the cache before usage. If for instance,
>>> you have changed the types of directories which should be cached,
>>> the cache could contain a path which was not wanted.
>>
>> Is it possible to make the cache detect these situations automatically
>> by saving track_flags along with the cache contents? Not having to
>> clear the cache manually would be a major feature.
>
>> Also, it's probably worth to split this patch up again. First switching
>> to your improved implementation of has_symlink_leading_path(), then
>> introducing has_symlink_or_noent_leading_path() and finally adding
>> LSTAT_FULLPATH and the fourth parameter of lstat_cache() etc. and using
>> this feature in entry.c seems like a nice incremental progression.
>
> Both are reasonable suggestions. Thanks.
Ok! Thanks for comments! Version 6 will follow shortly!
-- kjetil
^ permalink raw reply
* Re: TortoiseGit
From: Frank Li @ 2009-01-11 3:09 UTC (permalink / raw)
To: Victor Westmann; +Cc: git
In-Reply-To: <4d5bc4bb0901101906g4f64100dyc140ebd62d51fdf1@mail.gmail.com>
Absolutely yes!
Welcome translation!
^ permalink raw reply
* Re: TortoiseGit
From: Victor Westmann @ 2009-01-11 3:06 UTC (permalink / raw)
To: Frank Li; +Cc: git
In-Reply-To: <1976ea660901101757n3f18c0e4m2fa275ab7b961a2c@mail.gmail.com>
Frank,
hi. Youre more than welcome! I have helped in the translation of
TortoiseCVS and TortoiseSVN so I thought it would be nice to help in
this project too! :)
Cheers.
--
[]s
Victor Westmann
Steve Martin - "I like a woman with a head on her shoulders. I hate necks."
^ permalink raw reply
* Re: TortoiseGit
From: Frank Li @ 2009-01-11 1:57 UTC (permalink / raw)
To: Victor Westmann; +Cc: git
In-Reply-To: <4d5bc4bb0901101446j29d147c3pb885824e8d0d484f@mail.gmail.com>
Great!
I have not to enabled multi-language support yet.
I will enable it soon.
When it is ready, I will tell you.
Thank you very much
^ permalink raw reply
* Re: [BUG PATCH RFC] mailinfo: correctly handle multiline 'Subject:' header
From: Junio C Hamano @ 2009-01-11 1:54 UTC (permalink / raw)
To: Kirill Smelkov; +Cc: Alexander Potashev, git
In-Reply-To: <20090108231135.GB4185@roro3>
Kirill Smelkov <kirr@landau.phys.spbu.ru> writes:
> [but I'm not sure whether testresult with Nathaniel Borenstein
> (םולש ןב ילטפנ) is correct -- see rfc2047-info-0004]
> ...
> diff --git a/t/t5100/rfc2047-info-0004 b/t/t5100/rfc2047-info-0004
> new file mode 100644
> index 0000000..850f831
> --- /dev/null
> +++ b/t/t5100/rfc2047-info-0004
> @@ -0,0 +1,5 @@
> +Author: Nathaniel Borenstein
> + (םולש ןב ילטפנ)
> +Email: nsb@thumper.bellcore.com
> +Subject: Test of new header generator
> +
That does look wrong. If you can fix this, please do so; otherwise please
mark the test that deals with this entry with test_expect_failure, until
somebody else does.
^ permalink raw reply
* Re: [PATCH v2] make diff --color-words customizable
From: Junio C Hamano @ 2009-01-11 1:34 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Thomas Rast, git, Teemu Likonen
In-Reply-To: <alpine.DEB.1.00.0901101239550.30769@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Well, the thing I tried to hint at: it is not good to have a monster
> patch, as nobody will review it.
>
> In your case, I imagine it would be much easier to get reviewers if you
> had
>
> patch 1/4 refactor color-words to allow for 0-character word
> boundaries
> patch 2/4 allow regular expressions to define what makes a word
> patch 3/4 add option to specify word boundary regexps via
> attributes
> patch 4/4 test word boundary regexps
>
> And I admit that I documented the code lousily, but that does not mean
> that you should repeat that mistake.
Sounds like a reasonable request. Also I am seeing:
diff.c: In function 'scan_word_boundaries':
diff.c:512: warning: enumeration value 'DIFF_WORD_UNDEF' not handled in switch
from this part of the code:
for (i = 0; i < len; i++) {
switch (buf->boundaries[i]) {
case DIFF_WORD_BODY:
*p++ = text[i];
break;
case DIFF_WORD_END:
*p++ = text[i];
*p++ = '\n'; /* insert an artificial newline */
break;
case DIFF_WORD_SPACE:
*p++ = '\n';
break;
case DIFF_WORD_SKIP:
/* nothing */
break;
}
}
^ permalink raw reply
* Re: [PATCH v4] submodule: add +<branch> syntax for track to allow automatic pulling.
From: Junio C Hamano @ 2009-01-11 1:34 UTC (permalink / raw)
To: Fabian Franz; +Cc: git, j.sixt, hjemli
In-Reply-To: <1231553410-7541-4-git-send-email-git@fabian-franz.de>
Fabian Franz <git@fabian-franz.de> writes:
> When the track parameter is set to +<branch>, on update command a
> new branch is created tracking the remote branch (if it does not
> yet exist). Then the branch is checked out and git-pull is run.
Usually a "+" in front of a refspec means "allow forcing non-ff update",
but here it means completely different thing. The syntax is confusing.
But that aside, I do not know if the semantics of this patch makes sense
to begin with.
Should this really be a persistent property of a submodule? With your
patch, this is always triggered for modules you did "--track +branch" when
you added them, but (1) not for others you did not say "+" when you added,
and (2) you cannot disable the auto-pull for the ones you did even if you
wanted to. It feels it might be better to make it a property of one
particular invocation of "update" action, and more generally, the entire
series feels like a very specific hack that is meant to cover/impose your
particular workflow (and not others').
Don't get me wrong. I do not see any problem in supporing it well, if
that particular workflow is a good workflow and a generally applicable
one.
But I do not think it is documented well enough. "--track creates one
configuration in the .git/config file" and "update always checks out the
tip of the named branch if such configuration is set" may be fine
descriptions of what each piece does. The readers will be left puzzled
without an explanation of the bigger picture to understand why it is
(sometimes) a good idea to make these pieces do what they do.
^ permalink raw reply
* Re: [PATCH v4] submodule: add --no-fetch parameter to update command
From: Nanako Shiraishi @ 2009-01-11 1:32 UTC (permalink / raw)
To: Fabian Franz; +Cc: git, j.sixt, hjemli, gitster
In-Reply-To: <1231553410-7541-2-git-send-email-git@fabian-franz.de>
Quoting Fabian Franz <git@fabian-franz.de> writes:
> When -u|--use-gitmodules is given the update command uses the .gitmodules
> config file instead of the .git/config file to obtain the track parameter.
> This makes it for example possible to change branches for all submodules
> at the same time without having to sync up .git/config first.
>
> Signed-off-by: Fabian Franz <git@fabian-franz.de>
Once you start doing that, doesn't it force you to always bypass .git/config, making the current mechanism even less useful? If you find that "having to sync up .git/config first" is inconvenient, wouldn't it be more useful for your patch if it made it easier and more convenient the procedure "to sync up .git/config first", instead of bypassing the current setup?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH v4] submodule: add --no-fetch parameter to update command
From: Nanako Shiraishi @ 2009-01-11 1:31 UTC (permalink / raw)
To: Fabian Franz; +Cc: git, j.sixt, hjemli, gitster
In-Reply-To: <1231553410-7541-2-git-send-email-git@fabian-franz.de>
Quoting Fabian Franz <git@fabian-franz.de> writes:
> git submodule update --no-fetch makes it possible to use git submodule
> update in complete offline mode by not fetching new revisions.
I may be confused, but does it make any sense to update without fetching?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH/RFC v5 1/1] more cache effective symlink/directory detection
From: Junio C Hamano @ 2009-01-11 0:48 UTC (permalink / raw)
To: René Scharfe; +Cc: Kjetil Barvik, git, Pete Harlan, Linus Torvalds
In-Reply-To: <49687440.5090506@lsrfire.ath.cx>
René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> Kjetil Barvik schrieb:
>> - Also introduce a 'void clear_lstat_cache(void)' function, which
>> should be used to clean the cache before usage. If for instance,
>> you have changed the types of directories which should be cached,
>> the cache could contain a path which was not wanted.
>
> Is it possible to make the cache detect these situations automatically
> by saving track_flags along with the cache contents? Not having to
> clear the cache manually would be a major feature.
> Also, it's probably worth to split this patch up again. First switching
> to your improved implementation of has_symlink_leading_path(), then
> introducing has_symlink_or_noent_leading_path() and finally adding
> LSTAT_FULLPATH and the fourth parameter of lstat_cache() etc. and using
> this feature in entry.c seems like a nice incremental progression.
Both are reasonable suggestions. Thanks.
^ permalink raw reply
* TortoiseGit
From: Victor Westmann @ 2009-01-10 22:46 UTC (permalink / raw)
To: git
Hi everyone.
How can I help translate this nice piece of software to my native
language? (pt_BR = Brazilian portuguese).
Cheers.
--
[]s
Victor Westmann
Joan Crawford - "I, Joan Crawford, I believe in the dollar.
Everything I earn, I spend."
^ permalink raw reply
* Re: [PATCH] format-patch: avoid generation of empty patches
From: Junio C Hamano @ 2009-01-10 20:41 UTC (permalink / raw)
To: Nathan W. Panike; +Cc: Alexander Potashev, git
In-Reply-To: <d77df1110901100801s463bb43bt701a95df14f167d8@mail.gmail.com>
"Nathan W. Panike" <nathan.panike@gmail.com> writes:
> On Sat, Jan 10, 2009 at 5:39 AM, Alexander Potashev
> <aspotashev@gmail.com> wrote:
> ...
>>
>> + if (!commit->parents && !rev.show_root_diff)
>> + break;
>
> Do you really want to stop getting commits? It seems like the break
> statement here should be a continue.
You can give a commit range that has two independent roots. The above
"break" is wrong.
The variable is called show_root_DIFF, not show_root_COMMIT; even if you
have "log.showroot = false", "git log -p" output would still give you the
initial commit, but without the patch text, no?
But that is not Alexander's fault; it is mine.
I think "log -p" and "format-patch" can and should behave differently in
this case. "log -p" is for people who already _have_ the history and
would want to inspect how it evolved, and it is reasonable if some people
want to say "the very initial huge import is not interesting to me while
reviewing the history", and turning it off makes sense for them (in fact,
the default was initially that way).
On the other hand, "format-patch" is about exporting a part of your
history so that you can mechanincally replay it elsewhere, and I do not
think of a reasonable justification not to export a root commit fully if
the range user asked for happens to contain one.
I agree with Alexander that we should not output just the message without
the patch text, but I think the right solution is to show both. not to
skip root.
-- >8 --
format-patch: show patch text for the root commit
Even without --root specified, if the range given on the command line
happens to include a root commit, we should include its patch text in the
output.
This fix deliberately ignores log.showroot configuration variable because
"format-patch" and "log -p" can and should behave differently in this
case, as the former is about exporting a part of your history in a form
that is replayable elsewhere and just giving the commit log message
without the patch text does not make any sense for that purpose.
Noticed and fix originally attempted by Nathan W. Panike; credit goes to
Alexander Potashev for injecting sanity to my initial (broken) fix that
used the value from log.showroot configuration, which was misguided.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-log.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git c/builtin-log.c w/builtin-log.c
index 4a02ee9..91e5412 100644
--- c/builtin-log.c
+++ w/builtin-log.c
@@ -935,6 +935,13 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
* get_revision() to do the usual traversal.
*/
}
+
+ /*
+ * We cannot move this anywhere earlier because we do want to
+ * know if --root was given explicitly from the comand line.
+ */
+ rev.show_root_diff = 1;
+
if (cover_letter) {
/* remember the range */
int i;
^ permalink raw reply related
* Re: [PATCH 2/2] grep: don't call regexec() for fixed strings
From: Junio C Hamano @ 2009-01-10 20:37 UTC (permalink / raw)
To: René Scharfe; +Cc: Git Mailing List
In-Reply-To: <4967DB4A.2000702@lsrfire.ath.cx>
René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> Add the new flag "fixed" to struct grep_pat and set it if the pattern
> is doesn't contain any regex control characters in addition to if the
> flag -F/--fixed-strings was specified.
>
> This gives a nice speed up on msysgit, where regexec() seems to be
> extra slow. Before (best of five runs):
Thanks, and...
> static void compile_regexp(struct grep_pat *p, struct grep_opt *opt)
> {
> - int err = regcomp(&p->regexp, p->pattern, opt->regflags);
> + int err;
> +
> + if (opt->fixed || is_fixed(p->pattern))
> + p->fixed = 1;
> + if (opt->regflags & REG_ICASE)
> + p->fixed = 0;
... thanks again for being extra careful. That's why I *love* your
patches.
^ permalink raw reply
* Re: [PATCH 3/6] Glean libexec path from argv[0] for git-upload-pack and git-receive-pack.
From: Junio C Hamano @ 2009-01-10 20:36 UTC (permalink / raw)
To: Steffen Prohaska
Cc: Johannes Schindelin, Git Mailing List, Johannes Sixt,
Steve Haslam
In-Reply-To: <9CECD102-6D3E-487D-BA1E-C0269D055965@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
> On Jan 10, 2009, at 3:34 PM, Johannes Schindelin wrote:
>
>> Logically, and to avoid committing a broken revision, 1/6 should come
>> last, methinks.
>
> RUNTIME_PREFIX is not defined before 6/6. But I agree,
> 1/6 should probably be moved after 5/6.
>
> Steffen
Hmm, I actually was thinking about applying that (and that one only) early
to my tree, to make sure it is regression-free.
^ permalink raw reply
* Re: [PATCH EGIT Allow for git config to not error when lines have '/r' in them.]
From: Robin Rosenberg @ 2009-01-10 20:34 UTC (permalink / raw)
To: Ryan Alberts; +Cc: git, spearce
In-Reply-To: <142772020901071910ha95d53fo2454f8685908338c@mail.gmail.com>
torsdag 08 januari 2009 04:10:05 skrev Ryan Alberts:
> I have attached a small fix for when a git config has /r lines in the file.
> I have to admit that I do not usually submit patches to the open source
> community and I am not very familiar with the process :-) Please, please,
> let me know if I can do something different next time!
1) Inline the patch
No, need for such a large sign-off. It's good you declare that you have
understand the SOB-line.
You can add "extra" comments that should not go into the cBommit after the
comment like this:
From:.. etc
"This" goes into the commit
Signed-off-by: Whom Ever <whom.ever@example.com>
---
The three dashes ends the comment. Anything after it and the actual patch
will be ignored by git am, but might be useful to the maintainer.
Back to the patch. I think we should only ignore \r (not /r, but could say CR in
a comment) before an LF.
-- robin
^ permalink raw reply
* Re: Google Summer of Code 2009
From: Johannes Schindelin @ 2009-01-10 19:58 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Shawn O. Pearce, git
In-Reply-To: <m3privyn20.fsf@localhost.localdomain>
Hi,
On Sat, 10 Jan 2009, Jakub Narebski wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> > The application answers really need to be reworked; we need to
> > address our 2008 results in these parts.
>
> By the way, do you know what happened with git-sequencer project?
-- snip --
commit 3bfd6761ce2f769746c6b84be97f7da0cad7cad1
Author: Stephan Beyer <s-beyer@gmx.net>
Date: Wed Jan 7 19:07:31 2009 +0100
builtin-sequencer.c/prepare_commit_msg_hook: tiny simplification
Thanks to Christian.
-- snap --
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] gitweb: suggest name for OPML view
From: Jakub Narebski @ 2009-01-10 19:45 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <cb7bb73a0901101115i541f0911o42f08fc47820fb82@mail.gmail.com>
Giuseppe Bilotta wrote:
> On Sat, Jan 10, 2009 at 9:10 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>> On Fri, 2 Jan 2009, Giuseppe Bilotta wrote:
>>
>>> Suggest opml.xml as name for OPML view by providing the appropriate
>>> header, consistently with similar usage in project_index view.
>>
>> It is not name for a view, but more of default filename when saving
>> it. While it is good idea to have consistency, I guess that while
>> 'project_index' view and other non-HTML views are meant to be
>> downloaded and saved (snapshots, patches, patchsets), OPML view
>> is meant to be used on-line, just like web feeds in RSS and Atom
>> formats which are non-HTML too but do not have Content-Disposition
>> header set.
>
> OPML is used for import/export of RSS feed lists between aggregators
> (e.g. moving your reading list from knewsreader to google reader). As
> such, it can also be comfortable to save it to disk for import by some
> tools. IMO, of course. [...]
If it is used in such way, then I am all for it (and of course for
consistency with 'projects_index' view).
Acked-by: Jakub Narebski <jnareb@gmail.com>
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Google Summer of Code 2009
From: Jakub Narebski @ 2009-01-10 19:33 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20090107183033.GB10790@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> The application answers really need to be reworked; we need to
> address our 2008 results in these parts.
By the way, do you know what happened with git-sequencer project?
If I remember correctly there was agreement on sequences mini-language
(I think), and there was git-sequencer prototype in shell, using
git-cherry-pick if I remember correctly, and even git-rebase and
git-am etc reworked to make use of git-sequencer. Stephan Beyer wrote
that he has some preliminary version of builtin git-sequencer (in C),
and that it makes git-rebase--interactive and like faster than current
implementation... but builtin sequencer never materialized on git
mailing list as a patch, if I remember correctly, and of course it was
not merged into git either.
> The ideas box is once again open for suggestions. Please start
> proposing student projects, and possible mentors.
Hmm... take a look what features competition has (Darcs, Bazaar-NG,
Subversion, Mercurial, Monotone)...
>
>
> Since the program is smaller, there is a chance we won't be accepted
> this year due to space constraints. But I think its still worthwhile
> to prepare everything and hope for the best. And before you can
> ask, no, my employee status with OSPO doesn't improve our odds
> for acceptance. :-)
Perhaps at least _one_ project. I think that resumable clone /
resumable fetch would be a good thing to have...
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] gitweb: suggest name for OPML view
From: Giuseppe Bilotta @ 2009-01-10 19:15 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <200901101510.20918.jnareb@gmail.com>
On Sat, Jan 10, 2009 at 9:10 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Fri, 2 Jan 2009, Giuseppe Bilotta wrote:
>
>> Suggest opml.xml as name for OPML view by providing the appropriate
>> header, consistently with similar usage in project_index view.
>
> It is not name for a view, but more of default filename when saving
> it. While it is good idea to have consistency, I guess that while
> 'project_index' view and other non-HTML views are meant to be
> downloaded and saved (snapshots, patches, patchsets), OPML view
> is meant to be used on-line, just like web feeds in RSS and Atom
> formats which are non-HTML too but do not have Content-Disposition
> header set.
OPML is used for import/export of RSS feed lists between aggregators
(e.g. moving your reading list from knewsreader to google reader). As
such, it can also be comfortable to save it to disk for import by some
tools. IMO, of course. And there's also the consistency thing, and not
actual reason _not_ to offer the filename, since it comes pretty
cheap.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [PATCH] Add new testcases for format-patch root commits
From: Alexander Potashev @ 2009-01-10 18:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <1231605577-26148-1-git-send-email-aspotashev@gmail.com>
On 19:39 Sat 10 Jan , Alexander Potashev wrote:
> 1. format-patch'ing root commit shouldn't create empty patches
> 2. With --root it should create a patch for the root commit
> 3. Similar testcases with two commits in the tree
>
> Signed-off-by: Alexander Potashev <aspotashev@gmail.com>
> ---
>
> git format-patch lacks a '--no-root' option, so I used
> 'git config log.showroot false' to emulate it.
Sorry, --root option has nothing in common with log.showroot, but the
testcases are still valid.
>
>
>
> t/t4033-format-patch-root-commit.sh | 52 +++++++++++++++++++++++++++++++++++
> 1 files changed, 52 insertions(+), 0 deletions(-)
> create mode 100755 t/t4033-format-patch-root-commit.sh
>
> diff --git a/t/t4033-format-patch-root-commit.sh b/t/t4033-format-patch-root-commit.sh
> new file mode 100755
> index 0000000..846c11c
> --- /dev/null
> +++ b/t/t4033-format-patch-root-commit.sh
> @@ -0,0 +1,52 @@
> +#!/bin/sh
> +
> +test_description='Format-patch root commit skipping/allowing'
> +
> +. ./test-lib.sh
> +
> +test_expect_success setup '
> + git config log.showroot false
> + git config format.numbered false
> + echo A > file &&
> + git add file &&
> + git commit -m First
> +'
> +
> +test_patch_count() {
> + cnt=$(grep "^Subject: \[PATCH\]" $1 | wc -l) &&
> + test $cnt = $2
> +}
> +
> +test_patch_is_single() {
> + cnt=$(grep "^Subject: \[PATCH\] $2" $1 | wc -l) &&
> + test $cnt = 1
> +}
> +
> +test_expect_success 'format-patch root commit with showroot = false' '
> + git format-patch -1 &&
> + test_must_fail cat 0001-First.patch
> +'
> +
> +test_expect_success 'format-patch root commit' '
> + git format-patch --root --stdout -5 >root-only.patch &&
> + test_patch_count root-only.patch 1 &&
> + test_patch_is_single root-only.patch First
> +'
> +
> +test_expect_success 'format-patch 2 commits without root' '
> + echo B > file &&
> + git commit -a -m Second &&
> +
> + git format-patch --stdout -2 >two-except-root.patch &&
> + test_patch_count two-except-root.patch 1 &&
> + test_patch_is_single two-except-root.patch Second
> +'
> +
> +test_expect_success 'format-patch 2 commits including root' '
> + git format-patch --root --stdout -2 >two-with-root.patch &&
> + test_patch_count two-with-root.patch 2 &&
> + test_patch_is_single two-with-root.patch First &&
> + test_patch_is_single two-with-root.patch Second
> +'
> +
> +test_done
> --
> 1.6.1.81.g61cf1
>
^ permalink raw reply
* Re: [PATCH] format-patch: avoid generation of empty patches
From: Nathan W. Panike @ 2009-01-10 18:07 UTC (permalink / raw)
To: Alexander Potashev; +Cc: Junio C Hamano, git
In-Reply-To: <20090110161722.GA18859@myhost>
Hi:
On Sat, Jan 10, 2009 at 10:17 AM, Alexander Potashev
<aspotashev@gmail.com> wrote:
...
> AFAIU get_revision stops revision iteration when it appears to stay at
> the root commit. So, if we will replace 'break' with 'continue', the
> 'while' loop will finish right after that 'continue'.
> However, I might be wrong... please, correct me then.
I was thinking of the case where there is more than one root. Maybe
the code does the right thing then, but I confess I have not looked at
it deeply enough to know.
Nathan Panike
^ permalink raw reply
* Re: SSH_ASKPASS
From: Alexander Gavrilov @ 2009-01-10 18:02 UTC (permalink / raw)
To: Henk; +Cc: git
In-Reply-To: <1231584934701-2137400.post@n2.nabble.com>
On Saturday 10 January 2009 13:55:34 Henk wrote:
> I'm trying to get "git push" to use git-gui--askpass to ask me for the
> password instead of promting me on the command promt. I need this because I
> start the "git push" command from code and there is no terminal where ssh
> can ask the user for a password. I tried writing the following tcl script
> that allmost is what I need:
>
> set env(SSH_ASKPASS) "C:/Program
> Files/Git/libexec/git-core/git-gui--askpass"
> exec ssh git@github.com
>
> Ssh will now ask me for the password using git-gui--askpass. But now the
> standardout is also shown in a dialog, and not on the standardout of the
> process. Looking at the git-gui scripts didn't help me, because I have
> absolutely zero experience in tcl.
>
> I also tried not using a tcl script, but setting SSH_ASKPASS as an
> environment variable in windows. This doesn't seem to work, ssh will still
> prompt me for a password.
>
> Anyone can help me write a script that asks for the password using
> SSH_ASKPASS but still prints the output on standardout?
OpenSSH won't even try to use SSH_ASKPASS if it has access to a terminal.
Tcl makes it work precisely because the Tcl interpreter is a GUI application
that is detached from the console.
You should set the SSH_ASKPASS variable, and try running the commands as
you actually plan to do it from your code.
Alexander
^ permalink raw reply
* Re: [PATCH v2] make diff --color-words customizable
From: Davide Libenzi @ 2009-01-10 17:53 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Johannes Schindelin, git, Thomas Rast
In-Reply-To: <200901101436.48149.jnareb@gmail.com>
On Sat, 10 Jan 2009, Jakub Narebski wrote:
> On Sat, 10 Jan 2009, Johannes Schindelin wrote:
> > On Sat, 10 Jan 2009, Jakub Narebski wrote:
> > > Thomas Rast wrote:
> > >
> > > > --color-words works (and always worked) by splitting words onto one
> > > > line each, and using the normal line-diff machinery to get a word
> > > > diff.
> > >
> > > Cannot we generalize diff machinery / use underlying LCS diff engine
> > > instead of going through line diff?
> >
> > What do you think we're doing? libxdiff is pretty hardcoded to newlines.
> > That's why we're substituting non-word characters with newlines.
>
> Isn't Meyers algorithm used by libxdiff based on LCS, largest common
> subsequence, and doesn't it generate from the mathematical point of
> view "diff" between two sequences (two arrays) which just happen to
> be lines? It is a bit strange that libxdiff doesn't export its low
> level algorithm...
The core doesn't know anything about lines. Only pre-processing (setting
up the hash by tokenizing the input) and post-processing (adding '\n' to
the end of each token), knows about newlines. Memory consumption would
increase significantly though, since there is a per-token cost, and a
word-based diff will create more of them WRT the same input.
- Davide
^ 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