* What's cooking in git.git (Mar 2009, #05; Tue, 17)
From: Junio C Hamano @ 2009-03-18 5:30 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]
* dm/maint-docco (Mon Mar 16 23:16:17 2009 -0700) 4 commits
+ Documentation: minor grammatical fixes in git-branch.txt.
+ Documentation: minor grammatical fixes in git-blame.txt.
+ Documentation: reword the "Description" section of git-bisect.txt.
+ Documentation: minor grammatical fixes in git-archive.txt.
* mg/test-installed (Mon Mar 16 18:03:12 2009 +0100) 2 commits
+ test-lib.sh: Allow running the test suite against installed git
+ test-lib.sh: Test for presence of git-init in the right path.
----------------------------------------------------------------
[Graduated to "master"]
* kb/checkout-optim (Tue Mar 17 19:20:29 2009 +0100) 20 commits
+ Revert "lstat_cache(): print a warning if doing ping-pong between
cache types"
+ checkout bugfix: use stat.mtime instead of stat.ctime in two
places
+ Makefile: Set compiler switch for USE_NSEC
+ Create USE_ST_TIMESPEC and turn it on for Darwin
+ Not all systems use st_[cm]tim field for ns resolution file
timestamp
+ Record ns-timestamps if possible, but do not use it without
USE_NSEC
+ write_index(): update index_state->timestamp after flushing to
disk
+ verify_uptodate(): add ce_uptodate(ce) test
+ make USE_NSEC work as expected
+ fix compile error when USE_NSEC is defined
+ check_updates(): effective removal of cache entries marked
CE_REMOVE
+ lstat_cache(): print a warning if doing ping-pong between cache
types
+ show_patch_diff(): remove a call to fstat()
+ write_entry(): use fstat() instead of lstat() when file is open
+ write_entry(): cleanup of some duplicated code
+ create_directories(): remove some memcpy() and strchr() calls
+ unlink_entry(): introduce schedule_dir_for_removal()
+ lstat_cache(): swap func(length, string) into func(string, length)
+ lstat_cache(): generalise longest_match_lstat_cache()
+ lstat_cache(): small cleanup and optimisation
* tr/maint-1.6.0-send-email-irt (Wed Mar 11 23:40:13 2009 +0100) 2 commits
+ send-email: test --no-thread --in-reply-to combination
+ send-email: respect in-reply-to regardless of threading
* js/remote-improvements (Sun Mar 8 00:10:33 2009 -0800) 23 commits
+ builtin-remote.c: no "commented out" code, please
+ builtin-remote: new show output style for push refspecs
+ builtin-remote: new show output style
+ remote: make guess_remote_head() use exact HEAD lookup if it is
available
+ builtin-remote: add set-head subcommand
+ builtin-remote: teach show to display remote HEAD
+ builtin-remote: fix two inconsistencies in the output of "show
<remote>"
+ builtin-remote: make get_remote_ref_states() always populate
states.tracked
+ builtin-remote: rename variables and eliminate redundant function
call
+ builtin-remote: remove unused code in get_ref_states
+ builtin-remote: refactor duplicated cleanup code
+ string-list: new for_each_string_list() function
+ remote: make match_refs() not short-circuit
+ remote: make match_refs() copy src ref before assigning to
peer_ref
+ remote: let guess_remote_head() optionally return all matches
+ remote: make copy_ref() perform a deep copy
+ remote: simplify guess_remote_head()
+ move locate_head() to remote.c
+ move duplicated ref_newer() to remote.c
+ move duplicated get_local_heads() to remote.c
+ refactor find_ref_by_name() to accept const list
+ add basic http clone/fetch tests
+ test scripts: refactor start_httpd helper
* rs/color-grep (Mon Mar 16 13:20:04 2009 +1100) 7 commits
+ grep: prefer builtin over external one when coloring results
+ grep: cast printf %.*s "precision" argument explicitly to int
+ grep: add support for coloring with external greps
+ grep: color patterns in output
+ grep: add pmatch and eflags arguments to match_one_pattern()
+ grep: remove grep_opt argument from match_expr_eval()
+ grep: micro-optimize hit collection for AND nodes
* js/rsync-local (Mon Mar 9 19:44:55 2009 +0100) 1 commit
+ rsync transport: allow local paths, and fix tests
* js/sideband-stderr (Tue Mar 10 22:58:09 2009 +0100) 2 commits
+ winansi: support ESC [ K (erase in line)
+ recv_sideband: Bands #2 and #3 always go to stderr
* db/maint-missing-origin (Mon Mar 16 00:35:09 2009 -0700) 2 commits
+ Remove total confusion from git-fetch and git-push
+ Give error when no remote is configured
* jc/maint-1.6.0-read-tree-overlay (Thu Mar 12 00:02:12 2009 -0700) 1 commit
+ read-tree A B C: do not create a bogus index and do not segfault
With new test.
----------------------------------------------------------------
[Will merge to 'master' soon]
* fc/parseopt-config (Tue Mar 17 10:46:37 2009 +0100) 10 commits
+ config: test for --replace-all with one argument and fix
documentation.
+ config: set help text for --bool-or-int
+ git config: don't allow --get-color* and variable type
+ git config: don't allow extra arguments for -e or -l.
+ git config: don't allow multiple variable types
+ git config: don't allow multiple config file locations
+ git config: reorganize to use parseopt
+ git config: reorganize get_color*
+ git config: trivial rename in preparation for parseopt
+ git_config(): not having a per-repo config file is not an error
* js/rebase-i-opt (Tue Mar 3 10:55:31 2009 +0100) 1 commit
+ rebase -i: avoid 'git reset' when possible
* mh/cvsimport-tests (Mon Feb 23 06:08:14 2009 +0100) 5 commits
+ Add a test of "git cvsimport"'s handling of tags and branches
+ Add some tests of git-cvsimport's handling of vendor branches
+ Test contents of entire cvsimported "master" tree contents
+ Use CVS's -f option if available (ignore user's ~/.cvsrc file)
+ Start a library for cvsimport-related tests
* hv/cvsimport-tests (Mon Mar 2 18:59:36 2009 +0100) 1 commit
+ cvsimport: add test illustrating a bug in cvsps
* jc/clone-branch-rebase (Tue Mar 10 01:20:42 2009 -0700) 2 commits
+ Improve "git branch --tracking" output
+ Make git-clone respect branch.autosetuprebase
This is a rewrite of a patch from Pat Notz.
* xx/db-refspec-vs-js-remote (Sun Mar 8 00:12:33 2009 -0800) 1 commit
+ Adjust js/remote-improvements and db/refspec-wildcard-in-the-
middle
* db/refspec-wildcard-in-the-middle (Sat Mar 7 01:11:39 2009 -0500) 5 commits
+ Support '*' in the middle of a refspec
+ Keep '*' in pattern refspecs
+ Use the matching function to generate the match results
+ Use a single function to match names against patterns
+ Make clone parse the default refspec with the normal code
* bw/autoconf (Thu Mar 12 15:20:12 2009 -0400) 7 commits
+ configure: rework pthread handling to allow for user defined flags
+ configure: make iconv tests aware of user arguments
+ configure: asciidoc version test cleanup
+ configure: wrap some library tests with GIT_STASH_FLAGS
+ configure: add macros to stash FLAG variables
+ configure: reorganize flow of argument checks
+ configure: ensure settings from user are also usable in the script
----------------------------------------------------------------
[Stalled and may need help and prodding to go forward]
* ps/blame (Thu Mar 12 21:30:03 2009 +1100) 1 commit
- blame.c: start libifying the blame infrastructure
A few minor point remains in this initial one.
* jc/log-tz (Tue Mar 3 00:45:37 2009 -0800) 1 commit
- Allow --date=local --date=other-format to work as expected
The one I posted had a few corner-case bugs that was caught with the test
suite; this one has them fixed. People did not like the UI so it is kept
out of 'next'
* lh/submodule-tree-traversal (Sun Jan 25 01:52:06 2009 +0100) 1 commit
- archive.c: add support for --submodules[=(all|checkedout)]
Discussion stalled on the submodule selection criteria.
Probably I should discard it and wait for a reroll if needed.
* jc/merge-convert (Mon Jan 26 16:45:01 2009 -0800) 1 commit
- git-merge-file: allow converting the results for the work tree
This is a feature waiting for a user.
We did not give scripted Porcelains a way to say "this temporary file I am
using for merging is for this path, so use the core.autocrlf and attributes
rules for that final path". Instead, merge-file simply wrote out the
data in the canonical repository representation.
rerere has the same issue, but it is a lot worse. It reads the three
files (preimage, postimage and thisimage) from the work tree in the work
tree representation, merges them without converting them to the canonical
representation first but inserts the conflict markers with the canonical
representation and writes the resulting mess out. It needs to be fixed to
read with convert_to_git(), merge them while they are still in the
canonical representation and possibly add conflict markers, and then write
the results out after convert_to_working_tree(). It also needs to write
in binary mode as well.
* db/foreign-scm (Sun Jan 11 15:12:10 2009 -0500) 3 commits
- Support fetching from foreign VCSes
- Add specification of git-vcs helpers
- Add "vcs" config option in remotes
Daniel seems to have a plan for going forward with this series.
* cc/replace (Mon Feb 2 06:13:06 2009 +0100) 11 commits
- builtin-replace: use "usage_msg_opt" to give better error messages
- parse-options: add new function "usage_msg_opt"
- builtin-replace: teach "git replace" to actually replace
- Add new "git replace" command
- environment: add global variable to disable replacement
- mktag: call "check_sha1_signature" with the replacement sha1
- replace_object: add a test case
- object: call "check_sha1_signature" with the replacement sha1
- sha1_file: add a "read_sha1_file_repl" function
- replace_object: add mechanism to replace objects found in
"refs/replace/"
- refs: add a "for_each_replace_ref" function
I know, I really have to drop everything else and re-read these, but I
haven't managed to.
* js/notes (Wed Feb 18 11:17:27 2009 -0800) 14 commits
- tests: fix "export var=val"
- notes: refuse to edit notes outside refs/notes/
- t3301: use test_must_fail instead of !
- t3301: fix confusing quoting in test for valid notes ref
- notes: use GIT_EDITOR and core.editor over VISUAL/EDITOR
- notes: only clean up message file when editing
- handle empty notes gracefully
- git notes show: test empty notes
- git-notes: fix printing of multi-line notes
- notes: fix core.notesRef documentation
- Add an expensive test for git-notes
- Speed up git notes lookup
- Add a script to edit/inspect notes
- Introduce commit notes
----------------------------------------------------------------
[Actively cooking]
* jc/attributes-checkout (Fri Mar 13 21:24:08 2009 -0700) 1 commit
- Read attributes from the index that is being checked out
* fg/push-default (Mon Mar 16 16:42:52 2009 +0100) 2 commits
- Display warning for default git push with no push.default config
+ New config push.default to decide default behavior for push
Replaced the old series with the first step to allow a smooth transition.
Some might argue that this should not give any warning but just give users
this new configuration to play with first, and after we know we are going
to switch default some day, start the warning.
* mg/http-auth (Thu Mar 12 22:34:43 2009 -0700) 4 commits
+ http.c: CURLOPT_NETRC_OPTIONAL is not available in ancient
versions of cURL
+ http authentication via prompts
+ http_init(): Fix config file parsing
+ http.c: style cleanups
This does only the fetch side but without any additional configuration
variables that looked like band-aid. Support for push side seems to be in
the works somewhere.
* db/push-cleanup (Sun Mar 8 21:06:07 2009 -0400) 2 commits
+ Move push matching and reporting logic into transport.c
+ Use a common function to get the pretty name of refs
* kb/tracking-count-no-merges (Wed Mar 4 18:47:39 2009 +0100) 1 commit
+ stat_tracking_info(): only count real commits
This gives the merge commits zero weight when talking about how many
commits you have ahead (or behind) of the branch you are tracking. Even
though I agree that they should carry much less weight than the "real"
commits, because your repeated merge from the other branch does not really
add any real value to the end result, giving them absolute zero weight
somehow feels wrong. At least it shows that your have been _active_ on the
branch. But I do not feel very strongly about it.
* mv/parseopt-ls-files (Sat Mar 7 20:27:22 2009 -0500) 4 commits
+ ls-files: fix broken --no-empty-directory
+ t3000: use test_cmp instead of diff
+ parse-opt: migrate builtin-ls-files.
+ Turn the flags in struct dir_struct into a single variable
The tip one was a subject for further discussion, but nothing is queued
yet.
----------------------------------------------------------------
[On Hold]
* jc/deny-delete-current-1.7.0 (Mon Feb 9 00:19:46 2009 -0800) 1 commit
- receive-pack: default receive.denyDeleteCurrent to refuse
* jc/refuse-push-to-current-1.7.0 (Wed Feb 11 02:28:03 2009 -0800) 1 commit
- Refuse updating the current branch in a non-bare repository via
push
These are for 1.7.0, but the messages when they trigger together may need
to be rethought.
^ permalink raw reply
* Re: [PATCH 2/4] Documentation: reworded the "Description" section of git-blame.txt.
From: Junio C Hamano @ 2009-03-18 5:41 UTC (permalink / raw)
To: David J. Mellor; +Cc: git
In-Reply-To: <1237270577-17261-2-git-send-email-dmellor@whistlingcat.com>
"David J. Mellor" <dmellor@whistlingcat.com> writes:
> Reworded this section to make it less chatty. Also made minor grammatical
> fixes.
>
> Signed-off-by: David J. Mellor <dmellor@whistlingcat.com>
> ---
> Documentation/git-bisect.txt | 154 +++++++++++++++++++++---------------------
> 1 files changed, 77 insertions(+), 77 deletions(-)
>
> diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
> index e65c1ca..df0ed36 100644
> --- a/Documentation/git-bisect.txt
> +++ b/Documentation/git-bisect.txt
> @@ -48,61 +49,62 @@ $ git bisect good v2.6.13-rc2 # v2.6.13-rc2 was the last version
> ...
> ------------------------------------------------
> $ git bisect reset
> ------------------------------------------------
>
> -to get back to the original branch, instead of being on the bisection
> -commit ("git bisect start" will do that for you too, actually: it will
> -reset the bisection state).
> +This resest the tree to the original branch instead of being on the
This "resets" the tree.
Otherwise looked fine; thanks.
^ permalink raw reply
* Re: [PATCH1/2] Libify blame
From: Junio C Hamano @ 2009-03-18 5:41 UTC (permalink / raw)
To: pi song; +Cc: git, rene.scharfe
In-Reply-To: <49BE5343.60900@gmail.com>
pi song <pi.songs@gmail.com> writes:
> diff --git a/blame.h b/blame.h
> new file mode 100644
> index 0000000..72d1e2a
> --- /dev/null
> +++ b/blame.h
> @@ -0,0 +1,166 @@
> +/*
> + * for storing stats. it can be used
> + * across multiple blame operations
> + */
> +struct blame_stat {
> + int num_read_blob;
> + int num_get_patch;
> + int num_commits;
> +};
As I said in my previous message, I do not understand why this is not part
of the super-scoreboard (now blame_info).
> +#define PICKAXE_BLAME_MOVE 01
> +#define PICKAXE_BLAME_COPY 02
> +#define PICKAXE_BLAME_COPY_HARDER 04
> +#define PICKAXE_BLAME_COPY_HARDEST 010
> +
> +#define BLAME_DEFAULT_MOVE_SCORE 20
> +#define BLAME_DEFAULT_COPY_SCORE 40
> +
> +/* bits #0..7 in revision.h, #8..11 used for merge_bases() in commit.c */
> +#define METAINFO_SHOWN (1u<<12)
> +#define MORE_THAN_ONE_PATH (1u<<13)
Do we need to expose all of these constants outside blame.c? I think the
library caller needs access to the first four above, but I tend to think
the latter four are purely internal implementation detail that should be
kept in blame.c.
> +/* output formatting constants */
> +#define OUTPUT_ANNOTATE_COMPAT 001
> +#define OUTPUT_LONG_OBJECT_NAME 002
> +#define OUTPUT_RAW_TIMESTAMP 004
> +#define OUTPUT_PORCELAIN 010
> +#define OUTPUT_SHOW_NAME 020
> +#define OUTPUT_SHOW_NUMBER 040
> +#define OUTPUT_SHOW_SCORE 0100
> +#define OUTPUT_NO_AUTHOR 0200
I think these can be public.
> +/*
> + * One blob in a commit that is being suspected
> + */
> +struct origin {
> + int refcnt;
> + struct origin *previous;
> + struct commit *commit;
> + mmfile_t file;
> + unsigned char blob_sha1[20];
> + char path[FLEX_ARRAY];
> +};
I somehow doubt we would want to expose this level of implementation
detail to the callers of the library. If we need to, the structure needs
to be renamed---"origin" is way too generic a name.
> +extern void assign_blame(struct blame_scoreboard *sb, int opt) ;
Lose the extra SP before ";". I had to fix them in your previous patch
and there were many.
^ permalink raw reply
* Re: [PATCH] config.txt: Describe special 'none' handling in core.gitProxy.
From: Junio C Hamano @ 2009-03-18 5:41 UTC (permalink / raw)
To: Emil Sit; +Cc: git
In-Reply-To: <1237311102.24607.1305895377@webmail.messagingengine.com>
Thanks.
^ permalink raw reply
* Re: --exec-path not always honored
From: Junio C Hamano @ 2009-03-18 5:41 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List
In-Reply-To: <49BF692B.9020002@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> git-gc is a builtin. Should git setenv("GIT_EXEC_PATH") before it runs
> other git commands?
I think we just never have bothered about such a use case, but you are
right. It probably is a good solution, although setenv makes me feel a
bit nervous for no rational reason.
^ permalink raw reply
* What's in git.git (Mar 2009, #05; Tue, 17)
From: Junio C Hamano @ 2009-03-18 5:41 UTC (permalink / raw)
To: git
Notable topics graduated are Jay's "git remote" improvements, Kjetil's
"git checkout" optimization, and René's "git grep --color".
Post 1.6.2 cycle seems to be nicely progressing, and with another mass
graduation like this hopefully we can go into pre-release freeze for the
next release fairly soon.
* The 'master' branch has these since the last announcement
in addition to what are already in v1.6.2.1.
Alex Riesen (1):
disable post-checkout test on Cygwin
Benjamin Kramer (1):
Fix various dead stores found by the clang static analyzer
Brian Gernhardt (2):
Create USE_ST_TIMESPEC and turn it on for Darwin
Makefile: Set compiler switch for USE_NSEC
Chris Johnsen (2):
git-push.txt: describe how to default to pushing only current branch
Documentation: remove extra quoting/emphasis around literal texts
Daniel Barkalow (1):
Give error when no remote is configured
Emil Sit (1):
config.txt: Describe special 'none' handling in core.gitProxy.
Jay Soffian (18):
move duplicated get_local_heads() to remote.c
move duplicated ref_newer() to remote.c
move locate_head() to remote.c
remote: simplify guess_remote_head()
remote: make copy_ref() perform a deep copy
remote: let guess_remote_head() optionally return all matches
remote: make match_refs() copy src ref before assigning to peer_ref
remote: make match_refs() not short-circuit
string-list: new for_each_string_list() function
builtin-remote: refactor duplicated cleanup code
builtin-remote: remove unused code in get_ref_states
builtin-remote: rename variables and eliminate redundant function call
builtin-remote: make get_remote_ref_states() always populate
states.tracked
builtin-remote: fix two inconsistencies in the output of "show <remote>"
builtin-remote: teach show to display remote HEAD
builtin-remote: add set-head subcommand
builtin-remote: new show output style
builtin-remote: new show output style for push refspecs
Jeff King (5):
test scripts: refactor start_httpd helper
add basic http clone/fetch tests
refactor find_ref_by_name() to accept const list
remote: make guess_remote_head() use exact HEAD lookup if it is available
ls-files: require worktree when --deleted is given
Johannes Schindelin (2):
rsync transport: allow local paths, and fix tests
winansi: support ESC [ K (erase in line)
Johannes Sixt (1):
recv_sideband: Bands #2 and #3 always go to stderr
Junio C Hamano (6):
builtin-remote.c: no "commented out" code, please
Not all systems use st_[cm]tim field for ns resolution file timestamp
grep: cast printf %.*s "precision" argument explicitly to int
read-tree A B C: do not create a bogus index and do not segfault
Remove total confusion from git-fetch and git-push
Update draft release notes to 1.6.3
Kjetil Barvik (17):
lstat_cache(): small cleanup and optimisation
lstat_cache(): generalise longest_match_lstat_cache()
lstat_cache(): swap func(length, string) into func(string, length)
unlink_entry(): introduce schedule_dir_for_removal()
create_directories(): remove some memcpy() and strchr() calls
write_entry(): cleanup of some duplicated code
write_entry(): use fstat() instead of lstat() when file is open
show_patch_diff(): remove a call to fstat()
lstat_cache(): print a warning if doing ping-pong between cache types
check_updates(): effective removal of cache entries marked CE_REMOVE
fix compile error when USE_NSEC is defined
make USE_NSEC work as expected
verify_uptodate(): add ce_uptodate(ce) test
write_index(): update index_state->timestamp after flushing to disk
Record ns-timestamps if possible, but do not use it without USE_NSEC
checkout bugfix: use stat.mtime instead of stat.ctime in two places
Revert "lstat_cache(): print a warning if doing ping-pong between cache
types"
Michael J Gruber (1):
git-branch.txt: document -f correctly
Miklos Vajna (1):
Tests: use test_cmp instead of diff where possible
Nguyễn Thái Ngọc Duy (1):
grep: prefer builtin over external one when coloring results
Petr Kodl (2):
MinGW: a helper function that translates Win32 API error codes
MinGW: a hardlink implementation
René Scharfe (6):
grep: micro-optimize hit collection for AND nodes
grep: remove grep_opt argument from match_expr_eval()
grep: add pmatch and eflags arguments to match_one_pattern()
grep: color patterns in output
grep: add support for coloring with external greps
pickaxe: count regex matches only once
Stephen Boyd (1):
git-send-email.txt: describe --compose better
Thomas Rast (2):
send-email: respect in-reply-to regardless of threading
send-email: test --no-thread --in-reply-to combination
^ permalink raw reply
* Re: Ability to edit message from git rebase --interactive.
From: Sverre Rabbelier @ 2009-03-18 5:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Johannes Schindelin, Olivier Goffart, git
In-Reply-To: <7vsklbod0l.fsf@gitster.siamese.dyndns.org>
Heya,
On Wed, Mar 18, 2009 at 02:06, Junio C Hamano <gitster@pobox.com> wrote:
> Jeff King <peff@peff.net> writes:
> I am not quite sure what rephrase is buying us. Do we also want to
> introduce retree that allows you to muck with the tree object recorded
> without giving you a chance to clobber the commit log message?
Is that a common operation? Rephrase is, at least to me...
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* GitTogether '09
From: Christian Couder @ 2009-03-18 5:51 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20090310001613.GL11989@spearce.org>
Le mardi 10 mars 2009, Shawn O. Pearce a écrit :
> Folks, its that time of year again. We need to apply to be a
> mentoring organization for Google Summer of Code 2009.
Maybe we could also start discussing GitTogether '09 location and date.
I have added a GitTogether '09 heading to the wiki page and a few location
and date ideas:
http://git.or.cz/gitwiki/GitTogether
The location and dates are:
* San Francisco in October, just after the Google Summer of Code Mentor
* Portland Oregon in September, during or after LinuxCon
(http://events.linuxfoundation.org/events/linuxcon) and/or Linux Plumbers
Conference (http://linuxplumbersconf.org/)
Best regards,
Christian.
^ permalink raw reply
* Re: What's cooking in git.git (Mar 2009, #05; Tue, 17)
From: Jeff King @ 2009-03-18 5:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Miklos Vajna
In-Reply-To: <7vbprzo0si.fsf@gitster.siamese.dyndns.org>
On Tue, Mar 17, 2009 at 10:30:37PM -0700, Junio C Hamano wrote:
> * mv/parseopt-ls-files (Sat Mar 7 20:27:22 2009 -0500) 4 commits
> + ls-files: fix broken --no-empty-directory
> + t3000: use test_cmp instead of diff
> + parse-opt: migrate builtin-ls-files.
> + Turn the flags in struct dir_struct into a single variable
>
> The tip one was a subject for further discussion, but nothing is queued
> yet.
I am inclined to leave it as-is. The other sane option would be
converting it to use NONEG, as Miklos suggested.
Doing it right would probably mean adding a "this option is the opposite
of what we would usually do" flag to parse-options which would display
the option as "no-<option>" in the usage, and would reverse clearing and
setting the bit (i.e., --empty-directory would clear the HIDE_DIRECTORY
bit and --no-empty-directory would set it). But I don't think it is
worth the work to add a negatable version of an option that has never
existed before and which nobody has requested to use.
-Peff
^ permalink raw reply
* Re: [PATCH1/2] Libify blame
From: pi song @ 2009-03-18 5:59 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: rene.scharfe
In-Reply-To: <7vocvzmlqf.fsf@gitster.siamese.dyndns.org>
Don't you think we should rather split up into smaller files before
start reorganizing things?
Pi Song
On Wed, Mar 18, 2009 at 4:41 PM, Junio C Hamano <gitster@pobox.com> wrote:
> pi song <pi.songs@gmail.com> writes:
>
>> diff --git a/blame.h b/blame.h
>> new file mode 100644
>> index 0000000..72d1e2a
>> --- /dev/null
>> +++ b/blame.h
>> @@ -0,0 +1,166 @@
>> +/*
>> + * for storing stats. it can be used
>> + * across multiple blame operations
>> + */
>> +struct blame_stat {
>> + int num_read_blob;
>> + int num_get_patch;
>> + int num_commits;
>> +};
>
> As I said in my previous message, I do not understand why this is not part
> of the super-scoreboard (now blame_info).
>
>> +#define PICKAXE_BLAME_MOVE 01
>> +#define PICKAXE_BLAME_COPY 02
>> +#define PICKAXE_BLAME_COPY_HARDER 04
>> +#define PICKAXE_BLAME_COPY_HARDEST 010
>> +
>> +#define BLAME_DEFAULT_MOVE_SCORE 20
>> +#define BLAME_DEFAULT_COPY_SCORE 40
>> +
>> +/* bits #0..7 in revision.h, #8..11 used for merge_bases() in commit.c */
>> +#define METAINFO_SHOWN (1u<<12)
>> +#define MORE_THAN_ONE_PATH (1u<<13)
>
> Do we need to expose all of these constants outside blame.c? I think the
> library caller needs access to the first four above, but I tend to think
> the latter four are purely internal implementation detail that should be
> kept in blame.c.
>
>> +/* output formatting constants */
>> +#define OUTPUT_ANNOTATE_COMPAT 001
>> +#define OUTPUT_LONG_OBJECT_NAME 002
>> +#define OUTPUT_RAW_TIMESTAMP 004
>> +#define OUTPUT_PORCELAIN 010
>> +#define OUTPUT_SHOW_NAME 020
>> +#define OUTPUT_SHOW_NUMBER 040
>> +#define OUTPUT_SHOW_SCORE 0100
>> +#define OUTPUT_NO_AUTHOR 0200
>
> I think these can be public.
>
>> +/*
>> + * One blob in a commit that is being suspected
>> + */
>> +struct origin {
>> + int refcnt;
>> + struct origin *previous;
>> + struct commit *commit;
>> + mmfile_t file;
>> + unsigned char blob_sha1[20];
>> + char path[FLEX_ARRAY];
>> +};
>
> I somehow doubt we would want to expose this level of implementation
> detail to the callers of the library. If we need to, the structure needs
> to be renamed---"origin" is way too generic a name.
>
>> +extern void assign_blame(struct blame_scoreboard *sb, int opt) ;
>
> Lose the extra SP before ";". I had to fix them in your previous patch
> and there were many.
>
^ permalink raw reply
* Re: [PATCH1/2] Libify blame
From: Junio C Hamano @ 2009-03-18 6:20 UTC (permalink / raw)
To: pi.songs; +Cc: git, rene.scharfe
In-Reply-To: <1b29507a0903172259t348cb4d5n70f5b3003b1eeb00@mail.gmail.com>
pi song <pi.songs@gmail.com> writes:
> Don't you think we should rather split up into smaller files before
> start reorganizing things?
Yes, but splitting it wrong is, eh, wrong ;-)
^ permalink raw reply
* Re: [EGIT PATCH 01/25] Use generics for collections in commit dialog and import page
From: Robin Rosenberg @ 2009-03-18 6:32 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20090318014537.GC23521@spearce.org>
onsdag 18 mars 2009 02:45:37 skrev "Shawn O. Pearce" <spearce@spearce.org>:
> > Subject: Re: [EGIT PATCH 01/25] Use generics for collections in commit
> ..............................^^
>
> Are there 24 remaining patches in this series? I only got this one.
Ah, sorry. There's only one that I want to submit.
-- robin
^ permalink raw reply
* Re: [JGIT PATCH 00/12] Improve test coverage in revwalk
From: Robin Rosenberg @ 2009-03-18 6:34 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1237340451-31562-1-git-send-email-spearce@spearce.org>
onsdag 18 mars 2009 02:40:39 skrev "Shawn O. Pearce" <spearce@spearce.org>:
> Most of these patches are to improve the test coverage within the
> revwalk package.
>
>
> The last commit points out what I feared, which is that a RevWalk
> with a PathFilter applied doesn't produce the same results that
> git-core would produce in the same situation. We're either missing
> some functions necessary to implement it, or we flat out produce
> a wrong graph in some cases.
>
> The tests are commented out because JUnit doesn't have a notion of
> "known broken". But I did leave in TODO comments. I'd like to
> apply the test, and then work later to improve it, but I'm open
> to suggestions.
If we'd switch to JUnit4/TestNG we could abuse the expected exception
annotation.
-- robin
^ permalink raw reply
* Re: GitTogether '09
From: Sverre Rabbelier @ 2009-03-18 6:46 UTC (permalink / raw)
To: Christian Couder; +Cc: Shawn O. Pearce, git
In-Reply-To: <200903180651.33381.chriscool@tuxfamily.org>
Heya,
On Wed, Mar 18, 2009 at 06:51, Christian Couder <chriscool@tuxfamily.org> wrote:
> * San Francisco in October, just after the Google Summer of Code Mentor
Considering that (assuming git is accepted as mentoring organization)
we can ask Google for 2 airplane tickets, I'm voting for this option
;).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH1/2] Libify blame
From: pi song @ 2009-03-18 6:52 UTC (permalink / raw)
To: Junio C Hamano, git
In-Reply-To: <7v3adbmjwy.fsf@gitster.siamese.dyndns.org>
Wait. If you look at the builtin-blame.c, out of question it is very
messy. Things like print_usage() or -L parameter parsing for example
is not done upfront but hiding somewhere. Some functions are not very
clear if they are frontend or backend. I would say nobody would be
able to split it right in the first place. What you could do is to
split it to something "roughly right" and then work from that.
My latest two patches really do nothing but just splitting files. I
haven't changed any logics or renamed any thing only to make this big
beast more *manageable* rather than tackling the problem directly.
Yes, some bits are still wrong but I believe 70% of the functions
should already stay in the right place. The following patches will
make the structure more right *gradually*.
Pi Song
On Wed, Mar 18, 2009 at 5:20 PM, Junio C Hamano <gitster@pobox.com> wrote:
> pi song <pi.songs@gmail.com> writes:
>
>> Don't you think we should rather split up into smaller files before
>> start reorganizing things?
>
> Yes, but splitting it wrong is, eh, wrong ;-)
>
^ permalink raw reply
* Re: [PATCH1/2] Libify blame
From: pi song @ 2009-03-18 7:01 UTC (permalink / raw)
To: Junio C Hamano, git
In-Reply-To: <1b29507a0903172352x7864911fm1104e22eddde54f1@mail.gmail.com>
BTW, following patches are not available yet : P
On Wed, Mar 18, 2009 at 5:52 PM, pi song <pi.songs@gmail.com> wrote:
> Wait. If you look at the builtin-blame.c, out of question it is very
> messy. Things like print_usage() or -L parameter parsing for example
> is not done upfront but hiding somewhere. Some functions are not very
> clear if they are frontend or backend. I would say nobody would be
> able to split it right in the first place. What you could do is to
> split it to something "roughly right" and then work from that.
>
> My latest two patches really do nothing but just splitting files. I
> haven't changed any logics or renamed any thing only to make this big
> beast more *manageable* rather than tackling the problem directly.
> Yes, some bits are still wrong but I believe 70% of the functions
> should already stay in the right place. The following patches will
> make the structure more right *gradually*.
>
> Pi Song
>
>
> On Wed, Mar 18, 2009 at 5:20 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> pi song <pi.songs@gmail.com> writes:
>>
>>> Don't you think we should rather split up into smaller files before
>>> start reorganizing things?
>>
>> Yes, but splitting it wrong is, eh, wrong ;-)
>>
>
^ permalink raw reply
* Re: GitTogether '09
From: Christian Couder @ 2009-03-18 7:05 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Shawn O. Pearce, git, gittogether
In-Reply-To: <fabb9a1e0903172346j74b9992r1b0a8d6eb523103c@mail.gmail.com>
Le mercredi 18 mars 2009, Sverre Rabbelier a écrit :
> Heya,
>
> On Wed, Mar 18, 2009 at 06:51, Christian Couder <chriscool@tuxfamily.org>
wrote:
> > * San Francisco in October, just after the Google Summer of Code
> > Mentor
>
> Considering that (assuming git is accepted as mentoring organization)
> we can ask Google for 2 airplane tickets, I'm voting for this option
> ;).
I thought that it was only one international airplane ticket last year,
except perhaps when there are no US based mentor. And we are not sure that
Google or another company in the Bay Area will be able to host us this
year. So the cost of hosting the GitTogether might be higher than the cost
of a few airplane tickets.
Regards,
Christian.
^ permalink raw reply
* Re: [PATCH] Define a version of lstat(2) specially for copy operation
From: Alex Riesen @ 2009-03-18 7:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, Jeff King, layer, git
In-Reply-To: <20090317213820.GC13458@blimp.localdomain>
2009/3/17 Alex Riesen <raa.lkml@gmail.com>:
>> hooks copied from templates? I think we could pass mode 0 to copy_files()
>> and have the function special case it (and allow a platform specific
>> copy_files() implemented by Cygwin). lstat() in the copy_templates_1()
>> codepath is primarily done to see if we need to descend into a directory
>> or symlink() and our use of st.st_mode to pass to copy_files() is a no
>> cost side effect on platforms with x-bit support.
>
> And I don't think that the platform broken in so many ways deserves
> that kind of treatment. Maybe this patch is enough. Will test it
> tomorrow, when I get to mine so much hated Windows system.
>
Ok, I just tested it and it works. Junio, this patch can replace the previous
change which disabled the test.
^ permalink raw reply
* [PATCH] MinGW: implement mmap
From: Johannes Sixt @ 2009-03-18 7:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Janos Laube, Johannes Schindelin
From: Janos Laube <janos.dev@gmail.com>
Date: Fri, 13 Mar 2009 16:50:45 +0100
Add USE_WIN32_MMAP which triggers the use of windows' native
file memory mapping functionality in git_mmap()/git_munmap() functions.
As git functions currently use mmap with MAP_PRIVATE set only, this
implementation supports only that mode for now.
On Windows, offsets for memory mapped files need to match the allocation
granularity. Take this into account when calculating the packed git-
windowsize and file offsets. At the moment, the only function which makes
use of offsets in conjunction with mmap is use_pack() in sha1-file.c.
Git fast-import's code path tries to map a portion of the temporary
packfile that exceeds the current filesize, i.e. offset+length is
greater than the filesize. The NO_MMAP code worked with that since pread()
just reads the file content until EOF and returns gracefully, while
MapViewOfFile() aborts the mapping and returns 'Access Denied'.
Working around that by determining the filesize and adjusting the length
parameter.
Signed-off-by: Janos Laube <janos.dev@gmail.com>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
Makefile | 7 +++++-
compat/mingw.h | 5 ++++
compat/win32mmap.c | 53 ++++++++++++++++++++++++++++++++++++++++++++++++++++
git-compat-util.h | 12 ++++++++--
4 files changed, 73 insertions(+), 4 deletions(-)
create mode 100644 compat/win32mmap.c
diff --git a/Makefile b/Makefile
index 1087884..38e75e5 100644
--- a/Makefile
+++ b/Makefile
@@ -776,7 +776,6 @@ ifneq (,$(findstring CYGWIN,$(uname_S)))
COMPAT_OBJS += compat/cygwin.o
endif
ifneq (,$(findstring MINGW,$(uname_S)))
- NO_MMAP = YesPlease
NO_PREAD = YesPlease
NO_OPENSSL = YesPlease
NO_CURL = YesPlease
@@ -799,6 +798,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
RUNTIME_PREFIX = YesPlease
NO_POSIX_ONLY_PROGRAMS = YesPlease
NO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease
+ USE_WIN32_MMAP = YesPlease
COMPAT_CFLAGS += -D__USE_MINGW_ACCESS -DNOGDI -Icompat -Icompat/regex -Icompat/fnmatch
COMPAT_CFLAGS += -DSNPRINTF_SIZE_CORR=1
COMPAT_CFLAGS += -DSTRIP_EXTENSION=\".exe\"
@@ -967,6 +967,11 @@ endif
ifdef NO_MMAP
COMPAT_CFLAGS += -DNO_MMAP
COMPAT_OBJS += compat/mmap.o
+else
+ ifdef USE_WIN32_MMAP
+ COMPAT_CFLAGS += -DUSE_WIN32_MMAP
+ COMPAT_OBJS += compat/win32mmap.o
+ endif
endif
ifdef NO_PREAD
COMPAT_CFLAGS += -DNO_PREAD
diff --git a/compat/mingw.h b/compat/mingw.h
index 6e24686..f5da647 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -160,6 +160,11 @@ int mingw_connect(int sockfd, struct sockaddr *sa, size_t sz);
int mingw_rename(const char*, const char*);
#define rename mingw_rename
+#ifdef USE_WIN32_MMAP
+int mingw_getpagesize(void);
+#define getpagesize mingw_getpagesize
+#endif
+
/* Use mingw_lstat() instead of lstat()/stat() and
* mingw_fstat() instead of fstat() on Windows.
*/
diff --git a/compat/win32mmap.c b/compat/win32mmap.c
new file mode 100644
index 0000000..66314b8
--- /dev/null
+++ b/compat/win32mmap.c
@@ -0,0 +1,53 @@
+#include "../git-compat-util.h"
+
+/* Note that this doesn't return the actual pagesize, but
+ * the allocation granularity. If future Windows specific git code
+ * needs the real getpagesize function, we need to find another solution.
+ */
+int mingw_getpagesize(void)
+{
+ SYSTEM_INFO si;
+ GetSystemInfo(&si);
+ return si.dwAllocationGranularity;
+}
+
+void *git_mmap
+(void *start, size_t length, int prot, int flags, int fd, off_t offset)
+{
+ HANDLE hmap;
+ void *temp;
+ size_t len;
+ struct stat st;
+ uint64_t o = offset;
+ uint32_t l = o & 0xFFFFFFFF;
+ uint32_t h = (o >> 32) & 0xFFFFFFFF;
+
+ if (!fstat(fd, &st))
+ len = xsize_t(st.st_size);
+ else
+ die("mmap: could not determine filesize");
+
+ if ((length + offset) > len)
+ length = len - offset;
+
+ if (!(flags & MAP_PRIVATE))
+ die("Invalid usage of mmap when built with USE_WIN32_MMAP");
+
+ hmap = CreateFileMapping((HANDLE)_get_osfhandle(fd), 0, PAGE_WRITECOPY,
+ 0, 0, 0);
+
+ if (!hmap)
+ return MAP_FAILED;
+
+ temp = MapViewOfFileEx(hmap, FILE_MAP_COPY, h, l, length, start);
+
+ if (!CloseHandle(hmap))
+ warning("unable to close file mapping handle\n");
+
+ return temp ? temp : MAP_FAILED;
+}
+
+int git_munmap(void *start, size_t length)
+{
+ return !UnmapViewOfFile(start);
+}
diff --git a/git-compat-util.h b/git-compat-util.h
index 878d83d..1eef4eb 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -166,7 +166,7 @@ static inline const char *skip_prefix(const char *str, const char *prefix)
return strncmp(str, prefix, len) ? NULL : str + len;
}
-#ifdef NO_MMAP
+#if defined(NO_MMAP) || defined(USE_WIN32_MMAP)
#ifndef PROT_READ
#define PROT_READ 1
@@ -180,13 +180,19 @@ static inline const char *skip_prefix(const char *str, const char *prefix)
extern void *git_mmap(void *start, size_t length, int prot, int flags, int fd, off_t offset);
extern int git_munmap(void *start, size_t length);
+#else /* NO_MMAP || USE_WIN32_MMAP */
+
+#include <sys/mman.h>
+
+#endif /* NO_MMAP || USE_WIN32_MMAP */
+
+#ifdef NO_MMAP
+
/* This value must be multiple of (pagesize * 2) */
#define DEFAULT_PACKED_GIT_WINDOW_SIZE (1 * 1024 * 1024)
#else /* NO_MMAP */
-#include <sys/mman.h>
-
/* This value must be multiple of (pagesize * 2) */
#define DEFAULT_PACKED_GIT_WINDOW_SIZE \
(sizeof(void*) >= 8 \
--
1.6.2.rc2.971.g14d5
^ permalink raw reply related
* Re: [PATCH] Define a version of lstat(2) specially for copy operation
From: Junio C Hamano @ 2009-03-18 7:41 UTC (permalink / raw)
To: Alex Riesen; +Cc: Johannes Sixt, Jeff King, layer, git
In-Reply-To: <20090317213820.GC13458@blimp.localdomain>
Alex Riesen <raa.lkml@gmail.com> writes:
> So that Cygwin port can continue work around its supporting
> library and get access to its faked file attributes.
>
> Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
> ...
> diff --git a/builtin-init-db.c b/builtin-init-db.c
> index ee3911f..f3f781b 100644
> --- a/builtin-init-db.c
> +++ b/builtin-init-db.c
> @@ -66,7 +66,7 @@ static void copy_templates_1(char *path, int baselen,
> else
> exists = 1;
>
> - if (lstat(template, &st_template))
> + if (lstat_for_copy(template, &st_template))
> die("cannot stat template %s", template);
>
> if (S_ISDIR(st_template.st_mode)) {
Yuck; that's a bit too ugly for generic code. Will there be other places
that this needs to be used? If so, we'd probably need to encourage its
use where appropriate, which is even uglier but we cannot avoid it...
Also when the underlying system does not know the executable bit, how
would this help? I thought that earlier you said the part that checks if
it wants to execute hooks with access(X_OK) will fail, so...
^ permalink raw reply
* Re: --exec-path not always honored
From: Johannes Sixt @ 2009-03-18 7:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7v7i2nmlpt.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> Johannes Sixt <j.sixt@viscovery.net> writes:
>
>> git-gc is a builtin. Should git setenv("GIT_EXEC_PATH") before it runs
>> other git commands?
>
> I think we just never have bothered about such a use case, but you are
> right. It probably is a good solution, although setenv makes me feel a
> bit nervous for no rational reason.
This patch fixes the use case and is IMO the most logical solution.
diff --git a/exec_cmd.c b/exec_cmd.c
index 217c125..408e4e5 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -61,6 +61,10 @@ const char *git_extract_argv0_path(const char *argv0)
void git_set_argv_exec_path(const char *exec_path)
{
argv_exec_path = exec_path;
+ /*
+ * Propagate this setting to external programs.
+ */
+ setenv(EXEC_PATH_ENVIRONMENT, exec_path, 1);
}
^ permalink raw reply related
* Re: What's cooking in git.git (Mar 2009, #05; Tue, 17)
From: Miklos Vajna @ 2009-03-18 7:47 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20090318055222.GA17128@coredump.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 847 bytes --]
On Wed, Mar 18, 2009 at 01:52:22AM -0400, Jeff King <peff@peff.net> wrote:
> I am inclined to leave it as-is. The other sane option would be
> converting it to use NONEG, as Miklos suggested.
>
> Doing it right would probably mean adding a "this option is the opposite
> of what we would usually do" flag to parse-options which would display
> the option as "no-<option>" in the usage, and would reverse clearing and
> setting the bit (i.e., --empty-directory would clear the HIDE_DIRECTORY
> bit and --no-empty-directory would set it). But I don't think it is
> worth the work to add a negatable version of an option that has never
> existed before and which nobody has requested to use.
ACK, I'm fine with the current shape of the topic branch.
I did not think about the user confusion regarding usage when I
suggested NONEG.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] blame: read custom grafts given by -S before calling setup_revisions()
From: Junio C Hamano @ 2009-03-18 7:50 UTC (permalink / raw)
To: git
setup_revisions() while getting the command line arguments parses the
given commits from the command line, which means their direct parents will
not be rewritten by the custom graft file.
Call read_ancestry() early to work around this issue.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-blame.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/builtin-blame.c b/builtin-blame.c
index 4ea3431..0c241a9 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -2346,6 +2346,10 @@ int cmd_blame(int argc, const char **argv, const char *prefix)
parse_done:
argc = parse_options_end(&ctx);
+ if (revs_file && read_ancestry(revs_file))
+ die("reading graft file %s failed: %s",
+ revs_file, strerror(errno));
+
if (DIFF_OPT_TST(&revs.diffopt, FIND_COPIES_HARDER))
opt |= (PICKAXE_BLAME_COPY | PICKAXE_BLAME_MOVE |
PICKAXE_BLAME_COPY_HARDER);
@@ -2484,10 +2488,6 @@ parse_done:
sb.ent = ent;
sb.path = path;
- if (revs_file && read_ancestry(revs_file))
- die("reading graft file %s failed: %s",
- revs_file, strerror(errno));
-
read_mailmap(&mailmap, ".mailmap", NULL);
if (!incremental)
--
1.6.2.1.278.g7b6274e
^ permalink raw reply related
* Re: [PATCH] Define a version of lstat(2) specially for copy operation
From: Johannes Sixt @ 2009-03-18 7:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, Jeff King, layer, git
In-Reply-To: <7vmybjl1l6.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
>> So that Cygwin port can continue work around its supporting
>> library and get access to its faked file attributes.
>>
>> Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
>> ...
>> diff --git a/builtin-init-db.c b/builtin-init-db.c
>> index ee3911f..f3f781b 100644
>> --- a/builtin-init-db.c
>> +++ b/builtin-init-db.c
>> @@ -66,7 +66,7 @@ static void copy_templates_1(char *path, int baselen,
>> else
>> exists = 1;
>>
>> - if (lstat(template, &st_template))
>> + if (lstat_for_copy(template, &st_template))
>> die("cannot stat template %s", template);
>>
>> if (S_ISDIR(st_template.st_mode)) {
>
> Yuck; that's a bit too ugly for generic code. Will there be other places
> that this needs to be used? If so, we'd probably need to encourage its
> use where appropriate, which is even uglier but we cannot avoid it...
>
> Also when the underlying system does not know the executable bit, how
> would this help? I thought that earlier you said the part that checks if
> it wants to execute hooks with access(X_OK) will fail, so...
The "underlying system" in this case is Cygwin, and it *does* have an
executable bit.
But the FS gymnastics that implement it are slow and affect all lstat()
calls, so we have replaced lstat() with a simpler and faster
implementation. Only that the replacement doesn't know about the X bit
anymore; it always returns mode 0666.
Therefore, if a file is created whose mode is influenced by the fast
lstat(), then it will always be non-X. The access(, X_OK) call on the hook
script would do the right thing if only the script were created with the
correct mode. access(, X_OK) fails because the file was created with non-X
permissions.
-- Hannes
^ permalink raw reply
* Re: fetch and pull
From: Björn Steinbrink @ 2009-03-18 8:58 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: John Dlugosz, git, Junio C Hamano
In-Reply-To: <20090318063103.6117@nanako3.lavabit.com>
On 2009.03.18 06:31:03 +0900, Nanako Shiraishi wrote:
> Quoting John Dlugosz <JDlugosz@TradeStation.com>:
> > I think the documentation for git-pull might also be garbled from
> > text being of different eras. "Normally the branch merged is the
> > HEAD of the remote"? That will be basically random since the last
> > thing the upstream repo user did will control what his HEAD is.
>
> That's how it's supposed to work, and the documentation isn't from a
> different era, either. Majority of users clone from a central
> repository and keep pulling to update their clones, and in that kind
> of setting, HEAD will never change. A HEAD in a bare repository tells
> people which branch is the primary branch of the project.
But _if_ HEAD changes in the remote repo, that has normally no effect on
the behaviour of pull. Especially since the examples in the man page are
"git pull" and "git pull origin".
AFAICT the remote's HEAD affects the pull behaviour when:
1) You do "git pull git://host/repo.git" or similar, i.e. you don't use
a remote. Because then, no refspec is given to fetch, and it defaults to
fetching HEAD.
2) You do "git pull origin" and there's no remote.origin.fetch set, same
as above then.
3) You do "git pull" and either is branch.<name>.remote set to an url
(same as 1) then) or to a remote that has no default fetch refspec set
(same as 2) then).
1) probably isn't that common for most users, and even if, it's not
one of the commands given as examples to which the paragraph applies.
2) I don't think that's a common setup, and it's not a default setup, so
that hardly qualifies for "normally".
3) I've actually seen cases of the first form of this setup (remote set
to an url), but usually that was paired with a confused user.
So while it's true that the remote's HEAD might be what you merge, it's
not quite what happens "normally". Of course it's true that the most
common setup is probably that HEAD references master and that
branch.<name>.merge is also set to refs/heads/master, but while the
outcome is basically the same, I'd rather say that that is a coincidence
rather than what the text means to the reader.
I'm unsure about how to improve that section though. Basically, the last
paragraph ("When no refspec was given ...") above the EXAMPLES section
needs to be repeated, but that feels wrong. Anyone got a better idea?
Well, at least I finally realised that pull _might_ default to the
remote's HEAD, and for that part, I'll send a patch.
Björn
^ 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