* Re: [PATCH 2/2] remote-curl.c: fix rpc_out()
From: Johannes Schindelin @ 2009-11-23 10:39 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: Sverre Rabbelier, git, Shawn O. Pearce, Junio C Hamano
In-Reply-To: <be6fef0d0911230038y13c23e3ek5591ee0dc3eaa47a@mail.gmail.com>
Hi,
On Mon, 23 Nov 2009, Tay Ray Chuan wrote:
> On Mon, Nov 23, 2009 at 1:53 PM, Sverre Rabbelier <srabbelier@gmail.com>
> wrote:
> > Seems like this type of patch would do very well with a test case or
> > two?
>
> ah, but to trigger the code involved, a sufficiently large test
> repository is needed. The git repository would be enough. :)
I guess you meant "not be enough", as an int can hold a pretty large
number until it turns negative.
So I think in this case it is more harm- than helpful to have a test case.
For future reference: if you need a repository with special featurs
for testing, it is best to generate it in a test script (see the many test
cases labeled 'setup' in our test suite for examples).
Ciao,
Dscho
^ permalink raw reply
* Re: 'error: unable to set permission to './objects/...'
From: Martin Langhoff @ 2009-11-23 9:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Rafal Rusin, git
In-Reply-To: <7vd43acf7y.fsf@alter.siamese.dyndns.org>
On Mon, Nov 23, 2009 at 12:27 AM, Junio C Hamano <gitster@pobox.com> wrote:
> And the chmod() fails
> in this codepath. Then what? Wouldn't it make the resulting repository
> unusable?
Slightly off-topic: I keep encountering hosts where
core.sharedrepository doesn't always work with git+ssh. It may be
related to old git versions (I see 1.5.8 in a host where I've seen it
happen recently), but I never fails to baffle me.
Been sysadmin'ing and developing on linux since '98 and there is
nothing to prevent git from chmod'ing things right. And I know a few
things about git's plumbing :-) -- don't think it should be
mysteriously failing.
(And in several git repo servers I've spotted a cronjob doing chmod -R
g+rwx, applied by sysadmins to make the devs STFU about it ;-) ).
Is there a shortlist somewhere of reasons for it to be ignored?
Perhaps it is a known bug in old versions? -- the repo servers are
often behind...
Puzzled minds want to know.
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2009, #05; Sun, 22)
From: Johan Herland @ 2009-11-23 9:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Shawn O. Pearce
In-Reply-To: <7vhbsl935q.fsf@alter.siamese.dyndns.org>
On Monday 23 November 2009, Junio C Hamano wrote:
> * jh/notes (2009-11-20) 10 commits
> - Add more testcases to test fast-import of notes
> - Rename t9301 to t9350, to make room for more fast-import tests
> - fast-import: Proper notes tree manipulation using the notes API
> - Refactor notes concatenation into a flexible interface for combining notes
> - Notes API: Allow multiple concurrent notes trees with new struct notes_tree
> - Notes API: for_each_note(): Traverse the entire notes tree with a callback
> - Notes API: get_note(): Return the note annotating the given object
> - Notes API: add_note(): Add note objects to the internal notes tree structure
> - Notes API: init_notes(): Initialize the notes tree from the given notes ref
> - Notes API: get_commit_notes() -> format_note() + remove the commit restriction
>
> Early part has been lived in 'next' for a while and has graduated. This
> is a reroll of the remainder. Is everybody happy with merging this to
> 'next'?
I really want an Ack from Shawn on the fast-import patch (patch 8/10)
before putting this in 'next'. The rest of the series is good AFAICS,
although there might be some changes needed if I need to rework the
fast-import patch.
> I saw some checkpatch style violations, but didn't find anything
> objectionable in the logic.
Ok. I fixed most of them locally, but there are still some remaining in
fast-import.c, where I'd rather follow fast-import.c's existing style,
which seems to disagree somewhat with checkpatch.
The style fixes will be part of the next iteration (which will also
include the rebase back onto the early part of the jh/notes series).
I'll wait for Shawn's comments before resending, though.
> [...]
>
> * sr/vcs-helper (2009-11-18) 12 commits
> - Add Python support library for remote helpers
> - Basic build infrastructure for Python scripts
> - Allow helpers to report in "list" command that the ref is unchanged
> - Fix various memory leaks in transport-helper.c
> - Allow helper to map private ref names into normal names
> - Add support for "import" helper command
> - Allow specifying the remote helper in the url
> - Add a config option for remotes to specify a foreign vcs
> - Allow fetch to modify refs
> - Use a function to determine whether a remote is valid
> - Allow programs to not depend on remotes having urls
> - Fix memory leak in helper method for disconnect
>
> Replaced again. Is everybody happy with merging this to 'next'?
Yep, assuming Daniel is happy with the transport layer parts.
For the record, you can add this to the last patch of the series:
Signed-off-by: Johan Herland <johan@herland.net>
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: Git graph with branch labels for all paths in text environment
From: rhlee @ 2009-11-23 9:56 UTC (permalink / raw)
To: git
In-Reply-To: <2c6b72b30911210950m7f90f210saf3c32c1a3cbdebe@mail.gmail.com>
Jonas Fonseca wrote:
>
> You can browse all branches by using: tig --all
>
Thanks this great as this saves me from quitting tig to view all branch
histories.
Jonas Fonseca wrote:
>
> However, the graph drawing is rather poor for complex git histories.
>
I'm working on 3-4 current branches and it's fine for me.
Thanks,
Richard
--
View this message in context: http://n2.nabble.com/Git-graph-with-branch-labels-for-all-paths-in-text-environment-tp4011651p4050140.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* [PATCH] t4014-format-patch: do not assume 'test' is available as non-builtin
From: Johannes Sixt @ 2009-11-23 9:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
From: Johannes Sixt <j6t@kdbg.org>
One test case used 'xargs test', which assumes that 'test' is available
as external program. At least on MinGW it is not.
Moreover, 'git format-patch' was invoked in a pipeline, but not as the
last command. Rewrite the test case to catch breakage in 'git format-patch'
as well.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
t/t4014-format-patch.sh | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index 5689d59..7f267f9 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -549,9 +549,7 @@ test_expect_success 'options no longer allowed for format-patch' '
test_cmp expect.check output'
test_expect_success 'format-patch --numstat should produce a patch' '
- git format-patch --numstat --stdout master..side |
- grep "^diff --git a/" |
- wc -l |
- xargs test 6 = '
+ git format-patch --numstat --stdout master..side > output &&
+ test 6 = $(grep "^diff --git a/" output | wc -l)'
test_done
--
1.6.6.rc0.1059.gdce25
^ permalink raw reply related
* Re: 'error: unable to set permission to './objects/...'
From: Rafal Rusin @ 2009-11-23 9:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd43acf7y.fsf@alter.siamese.dyndns.org>
2009/11/23 Junio C Hamano <gitster@pobox.com>:
> Rafal Rusin <rafal.rusin@gmail.com> writes:
>
>> I'm hosting git repository on filesystem with 'chmod <some-file>'
>> causing permission denied error (it's smbfs mounted directory),
>> When I was doing push to such repo using file:// protocol, I got
>> following error:
>> error: unable to set permission to './objects/...'
>>
>> I did a small fix to sha1_file.c (patch in attachment) and git now
>> warns when unable to chmod, and continues push. This resolved problem.
>> What do you think about applying it?
>
> Suppose the user wanted to use this as a shared public repository and
> configured core.sharedrepository. If we try to set shared-perm and notice
> a failure but keep going, what happens to the resulting repository?
>
> For example, the umask of the user who is pushing objects, causing this
> codepath to run, might be too tight to be usable for the purpose of making
> the file readable for other members of the group. And the chmod() fails
> in this codepath. Then what? Wouldn't it make the resulting repository
> unusable?
>
> I think a _fix_ needs to first know why chmod is failing for you and
> either
>
> (1) make it not to fail; or
>
> (2) Perhaps your filesystem is lying and the result of chmod happens to
> be Ok (iow, the resulting file may be readable/writable by people who
> are supposed to be able to, accoring to the core.sharedrepository
> settings), in which case make the code notice the situation and keep
> going _only when_ it is safe to do so.
>
> I do not think your change to _unconditionally_ keep going is a fix.
Thanks for reply. You are right about sharedrepository argument.
As for detecting this particular case, I think it's not possible.
I think the best solution is to add repository config switch like
'usefilepermissions' true by default. If set to false, git would skip
chmod during push.
Does that make sense to you?
Regards,
--
Rafał Rusin
http://rrusin.blogspot.com
http://www.touk.pl
http://top.touk.pl
^ permalink raw reply
* Re: [ANNOUNCE] codeBeamer MR - Easy ACL for Git
From: Intland Software @ 2009-11-23 9:34 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: Petr Baudis, git
In-Reply-To: <2e24e5b90911210512g5ec26307te63d10912a7906fb@mail.gmail.com>
Sitaram Chamarty wrote:
> Intland: do you have a page that describes your role based ACL stuff a
> little more?
This is a good starting point in our Knowledge Base, to read more about
the permission model used in MR:
https://codebeamer.com/cb/wiki/11121
--
Intland Team
Follow @intland on Twitter: http://twitter.com/intland
Find codeBeamer on Facebook: http://bit.ly/rcTuX
^ permalink raw reply
* Re: [PATCH 2/2] remote-curl.c: fix rpc_out()
From: Tay Ray Chuan @ 2009-11-23 8:38 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: git, Shawn O. Pearce, Junio C Hamano
In-Reply-To: <fabb9a1e0911222153n633ade94w179513d4aa42a3d4@mail.gmail.com>
Hi,
On Mon, Nov 23, 2009 at 1:53 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> Seems like this type of patch would do very well with a test case or two?
ah, but to trigger the code involved, a sufficiently large test
repository is needed. The git repository would be enough. :)
Any idea on how I could go about accessing this repository?
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [PATCH 2/2] user-manual: Document that "git merge" doesn't like uncommited changes.
From: Matthieu Moy @ 2009-11-23 7:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy6lyaz9b.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> The work tree is overwritten by the result of the
> merge when this combining is done cleanly, and the result is
> committed. Otherwise it is
> overwritten by a half-merged results when this combining results
I thought of something like this, but this is slightly incorrect in
case of fast-forward (Git doesn't "commit", but "reuses" a commit), so
I prefered making a separate paragraph.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* [PATCH] Fix over-simplified documentation for 'git log -z'
From: Björn Gustavsson @ 2009-11-23 7:40 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In commit 64485b4a, the documentation for 'git log -z' was
simplified too much. The -z option actually changes the behavior
of 'git log' in two ways: commits will be ended with a NUL
instead of a LF (correctly documented) and the --raw and
--numstat will have NUL as field terminators (omitted in
the documentation for 'git log').
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
---
I wrongly assumed that 'git log' ignores the --raw
and --numstat options, because I tested it in a repository
with only merge commits. They do have an effect for
plain commits, and consequently -z will modify their
behavior for 'git log' too.
This patch applies on 'next'.
Documentation/diff-options.txt | 12 +++++++-----
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 18366b1..8707d0e 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -87,19 +87,21 @@ endif::git-format-patch[]
ifndef::git-format-patch[]
-z::
+ifdef::git-log[]
+ Separate the commits with NULs instead of with new newlines.
++
+Also, when `--raw` or `--numstat` has been given, do not munge
+pathnames and use NULs as output field terminators.
+endif::git-log[]
ifndef::git-log[]
When `--raw` or `--numstat` has been given, do not munge
pathnames and use NULs as output field terminators.
+endif::git-log[]
+
Without this option, each pathname output will have TAB, LF, double quotes,
and backslash characters replaced with `\t`, `\n`, `\"`, and `\\`,
respectively, and the pathname will be enclosed in double quotes if
any of those replacements occurred.
-endif::git-log[]
-
-ifdef::git-log[]
- Separate the commits with NULs instead of with new newlines.
-endif::git-log[]
--name-only::
Show only names of changed files.
--
1.6.5.3.298.g39add
^ permalink raw reply related
* [PATCH] instaweb: restart server if already running
From: Stephen Boyd @ 2009-11-23 7:09 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Running 'git instaweb' when an instaweb server is already running will
fail (at least when the port is the same) and overwrite the pid file
used to track the currently running server. This turns out to be
especially annoying when the user tries to stop the previously running
server with 'git instaweb --stop' and is instead greeted with an error
message because the pid file has been destroyed.
Instead of allowing a user to start two instaweb servers, stop the
currently running server first and then start the new one. This should
be fine because it was never really possible to start two instaweb
servers in the first place due to the pid file issue outlined above.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---
git-instaweb.sh | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/git-instaweb.sh b/git-instaweb.sh
index 622a5f0..ffc2ab6 100755
--- a/git-instaweb.sh
+++ b/git-instaweb.sh
@@ -73,6 +73,11 @@ resolve_full_httpd () {
}
start_httpd () {
+ if test -f "$fqgitdir/pid"; then
+ say "Instance already running. Restarting..."
+ stop_httpd
+ fi
+
# here $httpd should have a meaningful value
resolve_full_httpd
--
1.6.5.3.299.gb65c9
^ permalink raw reply related
* Re: What's cooking in git.git (Nov 2009, #05; Sun, 22)
From: Sverre Rabbelier @ 2009-11-23 6:24 UTC (permalink / raw)
To: Git List
In-Reply-To: <7vhbsl935q.fsf@alter.siamese.dyndns.org>
Heya,
On Mon, Nov 23, 2009 at 07:16, Junio C Hamano <gitster@pobox.com> wrote:
> * sr/gfi-options (2009-09-06) 6 commits.
> - fast-import: test the new option command
> - fast-import: add option command
> - fast-import: test the new feature command
> - fast-import: add feature command
> - fast-import: put marks reading in it's own function
> - fast-import: put option parsing code in separate functions
>
> It seemed to be moving again soon, but nothing has happened yet...
To those following this series, I've done a reroll addressing Shawn's
comments, but am holding back on sending it out since I want to add
the import-marks and export-marks features as well (which were the
sole reason for this series in the first place, to me at least). It
should not be much work, but I have to redo the test cases as well, so
it will take a little while longer to finish.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* What's cooking in git.git (Nov 2009, #05; Sun, 22)
From: Junio C Hamano @ 2009-11-23 6:16 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'. The ones
marked with '.' do not appear in any of the integration branches, but I am
still holding onto them.
In 1.7.0, we plan to correct handful of warts in the interfaces everybody
agrees that they were mistakes. The resulting system may not be strictly
backward compatible. Currently planned changes are:
* refuse push to update the checked out branch in a non-bare repo by
default
Make "git push" into a repository to update the branch that is checked
out fail by default. You can countermand this default by setting a
configuration variable in the receiving repository.
http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007
* refuse push to delete the current branch by default
Make "git push $there :$killed" to delete the branch that is pointed at
by its HEAD fail by default. You can countermand this default by
setting a configuration variable in the receiving repository.
http://thread.gmane.org/gmane.comp.version-control.git/108862/focus=108936
* "git send-email" won't make deep threads by default
Many people said that by default when sending more than 2 patches the
threading git-send-email makes by default is hard to read, and they
prefer the default be one cover letter and each patch as a direct
follow-up to the cover letter. You can countermand this by setting a
configuration variable.
http://article.gmane.org/gmane.comp.version-control.git/109790
* git-status won't be "git-commit --dry-run" anymore
http://thread.gmane.org/gmane.comp.version-control.git/125989/focus=125993
* "git diff -w --exit-code" will exit success if only differences it
found are whitespace changes that are stripped away from the output.
http://thread.gmane.org/gmane.comp.version-control.git/119731/focus=119751
* "git diff -w/-b" won't even produce "diff --git" header when all changes
are about whitespaces.
http://thread.gmane.org/gmane.comp.version-control.git/133256
Tonight's tip of 'master' is at v1.6.6-rc0. I am aware of a handful of
patches sent today but they didn't arraive before I started today's
integration cycle and are left out from today's tree.
--------------------------------------------------
[Graduated to "master"]
* ls/maint-mailinfo-no-inbody (2009-11-20) 1 commit.
(merged to 'next' on 2009-11-21 at dba8141)
+ git am/mailinfo: Don't look at in-body headers when rebasing
* rj/maint-t9700 (2009-11-19) 1 commit.
(merged to 'next' on 2009-11-21 at 29e149b)
+ t9700-perl-git.sh: Fix a test failure on Cygwin
* jn/faster-completion-startup (2009-11-17) 1 commit.
+ Speed up bash completion loading
* th/maint-remote-update-help-string (2009-11-15) 1 commit.
+ Update 'git remote update' usage string to match man page.
* tc/format-attribute (2009-11-14) 1 commit
+ Check the format of more printf-type functions
* jk/maint-break-rename-reduce-memory (2009-11-16) 2 commits.
(merged to 'next' on 2009-11-16 at 5b5a93f)
+ diffcore-break: save cnt_data for other phases
+ diffcore-break: free filespec data as we go
* bc/grep-i-F (2009-11-06) 1 commit.
(merged to 'next' on 2009-11-17 at a9b138c)
+ grep: Allow case insensitive search of fixed-strings
* mm/config-pathname-tilde-expand (2009-11-17) 1 commit.
(merged to 'next' on 2009-11-17 at 7ba213d)
+ Expand ~ and ~user in core.excludesfile, commit.template
* pb/maint-use-custom-perl (2009-11-17) 1 commit.
(merged to 'next' on 2009-11-17 at 1ee8d46)
+ Make sure $PERL_PATH is defined when the test suite is run.
* th/remote-usage (2009-11-16) 1 commit.
+ git remote: Separate usage strings for subcommands
* mo/maint-crlf-doc (2009-11-14) 1 commit.
(merged to 'next' on 2009-11-17 at abd9133)
+ core.autocrlf documentation: mention the crlf attribute
* rj/cygwin-msvc (2009-11-09) 2 commits.
+ MSVC: Add support for building with NO_MMAP
+ Makefile: keep MSVC and Cygwin configuration separate
(this branch uses rj/maint-simplify-cygwin-makefile.)
* jp/fetch-cull-many-refs (2009-11-13) 3 commits
(merged to 'next' on 2009-11-15 at db0f967)
+ remote: fix use-after-free error detected by glibc in ref_remove_duplicates
(merged to 'next' on 2009-11-01 at 1f09ce9)
+ fetch: Speed up fetch of large numbers of refs
+ remote: Make ref_remove_duplicates faster for large numbers of refs
* jn/help-everywhere (2009-11-09) 21 commits
(merged to 'next' on 2009-11-17 at 3a2dffe)
+ diff --no-index: make the usage string less scary
+ merge-{recursive,subtree}: use usagef() to print usage
+ Introduce usagef() that takes a printf-style format
+ Let 'git <command> -h' show usage without a git dir
+ Show usage string for 'git http-push -h'
+ Let 'git http-fetch -h' show usage outside any git repository
+ Show usage string for 'git stripspace -h'
+ Show usage string for 'git unpack-file -h'
+ Show usage string for 'git show-index -h'
+ Show usage string for 'git rev-parse -h'
+ Show usage string for 'git merge-one-file -h'
+ Show usage string for 'git mailsplit -h'
+ Show usage string for 'git imap-send -h'
+ Show usage string for 'git get-tar-commit-id -h'
+ Show usage string for 'git fast-import -h'
+ Show usage string for 'git check-ref-format -h'
+ Show usage string for 'git show-ref -h'
+ Show usage string for 'git merge-ours -h'
+ Show usage string for 'git commit-tree -h'
+ Show usage string for 'git cherry -h'
+ Show usage string for 'git grep -h'
(this branch uses jn/maint-http-fetch-mingw and jn/remove-fetch--tool.)
* jn/maint-http-fetch-mingw (2009-11-09) 1 commit.
(merged to 'next' on 2009-11-17 at cd35125)
+ http-fetch: add missing initialization of argv0_path
(this branch is used by jn/help-everywhere.)
* jn/remove-fetch--tool (2009-11-09) 1 commit
(merged to 'next' on 2009-11-17 at 72f6c3b)
+ Retire fetch--tool helper to contrib/examples
(this branch is used by jn/help-everywhere.)
* jn/gitweb-log-history (2009-11-13) 3 commits
(merged to 'next' on 2009-11-17 at d225f7d)
+ gitweb: Make 'history' view (re)use git_log_generic()
+ gitweb: Refactor common parts of 'log' and 'shortlog' views
+ gitweb: Refactor 'log' action generation, adding git_log_body()
* rg/doc-workflow (2009-11-17) 1 commit.
+ Add branch management for releases to gitworkflows
* sb/ls-tree-parseopt (2009-11-13) 2 commits.
(merged to 'next' on 2009-11-17 at c383204)
+ ls-tree: migrate to parse-options
+ t3101: test more ls-tree options
* jl/submodule-add-noname (2009-09-22) 1 commit.
(merged to 'next' on 2009-11-15 at 3a77d01)
+ git submodule add: make the <path> parameter optional
Dscho started an interesting discussion regarding the larger workflow in
which the "submodule add" is used. I think the patch itself makes sense
but at the same time it probably makes sense to also take the <path> and
infer the <repository> as Dscho suggested, probably in "git submodule
add", not in "git add" proper, at least initially.
* sc/protocol-doc (2009-11-03) 1 commit.
(merged to 'next' on 2009-11-15 at 32d6de8)
+ Update packfile transfer protocol documentation
* tr/filter-branch (2009-11-10) 2 commits.
(merged to 'next' on 2009-11-15 at 79c6a1d)
+ filter-branch: nearest-ancestor rewriting outside subdir filter
+ filter-branch: stop special-casing $filter_subdir argument
* bg/format-patch-doc-update (2009-11-07) 4 commits.
(merged to 'next' on 2009-11-17 at 68b9056)
+ format-patch: Add "--no-stat" as a synonym for "-p"
+ format-patch documentation: Fix formatting
+ format-patch documentation: Remove diff options that are not useful
+ format-patch: Always generate a patch
* rj/maint-simplify-cygwin-makefile (2009-10-27) 1 commit.
+ Makefile: merge two Cygwin configuration sections into one
(this branch is used by rj/cygwin-msvc.)
* jn/editor-pager (2009-10-30) 9 commits
(merged to 'next' on 2009-11-15 at 7f3e3ae)
+ Provide a build time default-pager setting
+ Provide a build time default-editor setting
+ am -i, git-svn: use "git var GIT_PAGER"
+ add -i, send-email, svn, p4, etc: use "git var GIT_EDITOR"
+ Teach git var about GIT_PAGER
+ Teach git var about GIT_EDITOR
+ Suppress warnings from "git var -l"
+ Do not use VISUAL editor on dumb terminals
+ Handle more shell metacharacters in editor names
* bw/autoconf-more (2009-11-04) 2 commits
(merged to 'next' on 2009-11-15 at e86a8c9)
+ configure: add settings for gitconfig, editor and pager
+ configure: add macro to set arbitrary make variables
* sp/smart-http (2009-11-14) 37 commits
(merged to 'next' on 2009-11-17 at 11067eb)
+ http-backend: Let gcc check the format of more printf-type functions.
+ http-backend: Fix access beyond end of string.
(merged to 'next' on 2009-11-15 at 2a326b2)
+ http-backend: Fix bad treatment of uintmax_t in Content-Length
+ t5551-http-fetch: Work around broken Accept header in libcurl
+ t5551-http-fetch: Work around some libcurl versions
+ http-backend: Protect GIT_PROJECT_ROOT from /../ requests
+ Git-aware CGI to provide dumb HTTP transport
(merged to 'next' on 2009-11-06 at 666837c)
+ http-backend: Test configuration options
+ http-backend: Use http.getanyfile to disable dumb HTTP serving
+ test smart http fetch and push
+ http tests: use /dumb/ URL prefix
+ set httpd port before sourcing lib-httpd
+ t5540-http-push: remove redundant fetches
+ Smart HTTP fetch: gzip requests
+ Smart fetch over HTTP: client side
+ Smart push over HTTP: client side
+ Discover refs via smart HTTP server when available
+ http-backend: more explict LocationMatch
+ http-backend: add example for gitweb on same URL
+ http-backend: use mod_alias instead of mod_rewrite
+ http-backend: reword some documentation
+ http-backend: add GIT_PROJECT_ROOT environment var
+ Smart fetch and push over HTTP: server side
+ Add stateless RPC options to upload-pack, receive-pack
+ Git-aware CGI to provide dumb HTTP transport
+ remote-helpers: return successfully if everything up-to-date
+ Move WebDAV HTTP push under remote-curl
+ remote-helpers: Support custom transport options
+ remote-helpers: Fetch more than one ref in a batch
+ fetch: Allow transport -v -v -v to set verbosity to 3
+ remote-curl: Refactor walker initialization
+ Add multi_ack_detailed capability to fetch-pack/upload-pack
+ Move "get_ack()" back to fetch-pack
+ fetch-pack: Use a strbuf to compose the want list
+ pkt-line: Make packet_read_line easier to debug
+ pkt-line: Add strbuf based functions
+ http-push: fix check condition on http.c::finish_http_pack_request()
--------------------------------------------------
[New Topics]
* bg/apply-doc (2009-11-22) 4 commits
(merged to 'next' on 2009-11-22 at b42fece)
+ apply: Use the term "working tree" consistently
+ apply: Format all options using back-quotes
+ apply: apply works outside a repository
+ Clarify and correct -z
* cc/replace (2009-11-19) 3 commits
(merged to 'next' on 2009-11-21 at 2aaf84b)
+ Documentation: talk a little bit about GIT_NO_REPLACE_OBJECTS
+ Documentation: fix typos and spelling in replace documentation
+ replace: use a GIT_NO_REPLACE_OBJECTS env variable
* fc/send-email-envelope (2009-11-22) 1 commit.
- t9001: test --envelope-sender option of send-email
The new feature itself looked promising; this is just an unrelated test
patch.
* gb/1.7.0-diff-whitespace-only-outout (2009-11-19) 1 commit
(merged to 'next' on 2009-11-21 at 3375bf4)
+ No diff -b/-w output for all-whitespace changes
* jc/checkout-merge-base (2009-11-20) 2 commits
- "rebase --onto A...B" replays history on the merge base between A and B
- "checkout A...B" switches to the merge base between A and B
* mm/maint-hint-failed-merge (2009-11-22) 2 commits.
(merged to 'next' on 2009-11-22 at c0f64c2)
+ user-manual: Document that "git merge" doesn't like uncommited changes.
+ merge-recursive: point the user to commit when file would be overwritten.
* rj/maint-cygwin-count-objects (2009-11-19) 2 commits.
(merged to 'next' on 2009-11-22 at 4ba5880)
+ ST_BLOCKS_COUNTS_IN_BLKSIZE to say on-disk size is (st_blksize * st_blocks)
+ git-count-objects: Fix a disk-space under-estimate on Cygwin
* rs/color-escape-has-zero-width (2009-11-23) 1 commit
- Teach %w() that color escape codes have zero width
* tr/reset-checkout-patch (2009-11-19) 1 commit.
(merged to 'next' on 2009-11-22 at b224950)
+ {checkout,reset} -p: make patch direction configurable
--------------------------------------------------
[Stalled]
* jc/fix-tree-walk (2009-10-22) 8 commits
(merged to 'next' on 2009-10-22 at 10c0c8f)
+ Revert failed attempt since 353c5ee
+ read-tree --debug-unpack
(merged to 'next' on 2009-10-11 at 0b058e2)
+ unpack-trees.c: look ahead in the index
+ unpack-trees.c: prepare for looking ahead in the index
+ Aggressive three-way merge: fix D/F case
+ traverse_trees(): handle D/F conflict case sanely
+ more D/F conflict tests
+ tests: move convenience regexp to match object names to test-lib.sh
This has some stupid bugs and reverted from 'next' until I can fix it, but
the "temporarily" turned out to be very loooong. Sigh...
* sr/gfi-options (2009-09-06) 6 commits.
- fast-import: test the new option command
- fast-import: add option command
- fast-import: test the new feature command
- fast-import: add feature command
- fast-import: put marks reading in it's own function
- fast-import: put option parsing code in separate functions
It seemed to be moving again soon, but nothing has happened yet...
* je/send-email-no-subject (2009-08-05) 1 commit.
(merged to 'next' on 2009-10-11 at 1b99c56)
+ send-email: confirm on empty mail subjects
The existing tests cover the positive case (i.e. as long as the user says
"yes" to the "do you really want to send this message that lacks subject",
the message is sent) of this feature, but the feature itself needs its own
test to verify the negative case (i.e. does it correctly stop if the user
says "no"?)
--------------------------------------------------
[Cooking]
* jh/notes (2009-11-20) 10 commits
- Add more testcases to test fast-import of notes
- Rename t9301 to t9350, to make room for more fast-import tests
- fast-import: Proper notes tree manipulation using the notes API
- Refactor notes concatenation into a flexible interface for combining notes
- Notes API: Allow multiple concurrent notes trees with new struct notes_tree
- Notes API: for_each_note(): Traverse the entire notes tree with a callback
- Notes API: get_note(): Return the note annotating the given object
- Notes API: add_note(): Add note objects to the internal notes tree structure
- Notes API: init_notes(): Initialize the notes tree from the given notes ref
- Notes API: get_commit_notes() -> format_note() + remove the commit restriction
Early part has been lived in 'next' for a while and has graduated. This
is a reroll of the remainder. Is everybody happy with merging this to
'next'? I saw some checkpatch style violations, but didn't find anything
objectionable in the logic.
* jn/gitweb-blame (2009-11-19) 6 commits.
- gitweb.js: fix null object exception in initials calculation
- gitweb: Minify gitweb.js if JSMIN is defined
- gitweb: Create links leading to 'blame_incremental' using JavaScript
(merged to 'next' on 2009-10-11 at 73c4a83)
+ gitweb: Colorize 'blame_incremental' view during processing
+ gitweb: Incremental blame (using JavaScript)
+ gitweb: Add optional "time to generate page" info in footer
Ajax-y blame, with a few recent fixes.
* tr/maint-merge-ours-clarification (2009-11-15) 1 commit
(merged to 'next' on 2009-11-21 at fadaf7b)
+ rebase: refuse to rebase with -s ours
* jc/log-stdin (2009-11-20) 4 commits
(merged to 'next' on 2009-11-21 at c3e2e52)
+ Make --stdin option to "log" family read also pathspecs
+ setup_revisions(): do not call get_pathspec() too early
+ Teach --stdin option to "log" family
+ read_revision_from_stdin(): use strbuf
Still no tests yet but with docs from Peff.
* jn/rfc-pull-rebase-error-message (2009-11-12) 1 commit
- git-pull.sh --rebase: overhaul error handling when no candidates are found
I heard this needs at least retitling among other changes?
* em/commit-claim (2009-11-04) 1 commit
- commit -c/-C/--amend: reset timestamp and authorship to committer with --reset-author
I just picked better bits from both versions, but this needs to be
rethought.
* bg/fetch-multi (2009-11-10) 9 commits.
(merged to 'next' on 2009-11-21 at 282f464)
+ Re-implement 'git remote update' using 'git fetch'
+ builtin-fetch: add --dry-run option
+ builtin-fetch: add --prune option
+ teach warn_dangling_symref to take a FILE argument
+ remote: refactor some logic into get_stale_heads()
+ Add missing test for 'git remote update --prune'
+ Add the configuration option skipFetchAll
+ Teach the --multiple option to 'git fetch'
+ Teach the --all option to 'git fetch'
* cc/bisect-doc (2009-11-08) 1 commit
- Documentation: add "Fighting regressions with git bisect" article
Any comments? Should it go to Documentation/technical instead?
* sr/vcs-helper (2009-11-18) 12 commits
- Add Python support library for remote helpers
- Basic build infrastructure for Python scripts
- Allow helpers to report in "list" command that the ref is unchanged
- Fix various memory leaks in transport-helper.c
- Allow helper to map private ref names into normal names
- Add support for "import" helper command
- Allow specifying the remote helper in the url
- Add a config option for remotes to specify a foreign vcs
- Allow fetch to modify refs
- Use a function to determine whether a remote is valid
- Allow programs to not depend on remotes having urls
- Fix memory leak in helper method for disconnect
Replaced again. Is everybody happy with merging this to 'next'?
* mr/gitweb-snapshot (2009-11-07) 4 commits.
(merged to 'next' on 2009-11-21 at e825ad9)
+ gitweb: Smarter snapshot names
+ gitweb: Document current snapshot rules via new tests
+ t/gitweb-lib.sh: Split gitweb output into headers and body
(merged to 'next' on 2009-10-11 at 22ba047)
+ gitweb: check given hash before trying to create snapshot
Soon in 'master'.
* jc/pretty-lf (2009-10-04) 1 commit.
- Pretty-format: %[+-]x to tweak inter-item newlines
* ks/precompute-completion (2009-11-15) 4 commits.
(merged to 'next' on 2009-11-15 at 23cdb96)
+ Revert ks/precompute-completion series
(merged to 'next' on 2009-10-28 at cd5177f)
+ completion: ignore custom merge strategies when pre-generating
(merged to 'next' on 2009-10-22 at f46a28a)
+ bug: precomputed completion includes scripts sources
(merged to 'next' on 2009-10-14 at adf722a)
+ Speedup bash completion loading
Reverted out of 'next', to be replaced with jn/faster-completion-startup
topic.
* nd/sparse (2009-08-20) 19 commits.
- sparse checkout: inhibit empty worktree
- Add tests for sparse checkout
- read-tree: add --no-sparse-checkout to disable sparse checkout support
- unpack-trees(): ignore worktree check outside checkout area
- unpack_trees(): apply $GIT_DIR/info/sparse-checkout to the final index
- unpack-trees(): "enable" sparse checkout and load $GIT_DIR/info/sparse-checkout
- unpack-trees.c: generalize verify_* functions
- unpack-trees(): add CE_WT_REMOVE to remove on worktree alone
- Introduce "sparse checkout"
- dir.c: export excluded_1() and add_excludes_from_file_1()
- excluded_1(): support exclude files in index
- unpack-trees(): carry skip-worktree bit over in merged_entry()
- Read .gitignore from index if it is skip-worktree
- Avoid writing to buffer in add_excludes_from_file_1()
- Teach Git to respect skip-worktree bit (writing part)
- Teach Git to respect skip-worktree bit (reading part)
- Introduce "skip-worktree" bit in index, teach Git to get/set this bit
- Add test-index-version
- update-index: refactor mark_valid() in preparation for new options
The latest update I didn't look at very closely but I had an impression
that it was touching very generic codepath that would affect non sparse
cases, iow the patch looked very scary (the entire series already is).
--------------------------------------------------
[For 1.7.0]
* jc/1.7.0-no-commit-no-ff-2 (2009-10-22) 1 commit.
- git-merge: forbid fast-forward and up-to-date when --no-commit is given
This makes "git merge --no-commit" fail when it results in fast-forward or
up-to-date. I haven't described this at the beginning of this message
yet, as it is not clear if this change is even necessary. Opinions?
* jk/1.7.0-status (2009-09-05) 5 commits.
(merged to 'next' on 2009-11-21 at 884bb56)
+ docs: note that status configuration affects only long format
(merged to 'next' on 2009-10-11 at 65c8513)
+ commit: support alternate status formats
+ status: add --porcelain output format
+ status: refactor format option parsing
+ status: refactor short-mode printing to its own function
(this branch uses jc/1.7.0-status.)
Gives the --short output format to post 1.7.0 "git commit --dry-run" that
is similar to that of post 1.7.0 "git status".
* jc/1.7.0-status (2009-09-05) 4 commits.
(merged to 'next' on 2009-10-11 at 9558627)
+ status: typo fix in usage
+ git status: not "commit --dry-run" anymore
+ git stat -s: short status output
+ git stat: the beginning of "status that is not a dry-run of commit"
(this branch is used by jk/1.7.0-status.)
With this, "git status" is no longer "git commit --dry-run".
* jc/1.7.0-send-email-no-thread-default (2009-08-22) 1 commit.
(merged to 'next' on 2009-10-11 at 043acdf)
+ send-email: make --no-chain-reply-to the default
* jc/1.7.0-diff-whitespace-only-status (2009-08-30) 4 commits.
(merged to 'next' on 2009-10-11 at 546c74d)
+ diff.c: fix typoes in comments
+ Make test case number unique
+ diff: Rename QUIET internal option to QUICK
+ diff: change semantics of "ignore whitespace" options
This changes exit code from "git diff --ignore-whitespace" and friends
when there is no actual output. It is a backward incompatible change, but
we could argue that it is a bugfix.
* jc/1.7.0-push-safety (2009-02-09) 2 commits.
(merged to 'next' on 2009-10-11 at 81b8128)
+ Refuse deleting the current branch via push
+ Refuse updating the current branch in a non-bare repository via push
--------------------------------------------------
[I have been too busy to purge these]
* ne/rev-cache (2009-10-19) 7 commits.
. support for commit grafts, slight change to general mechanism
. support for path name caching in rev-cache
. full integration of rev-cache into git, completed test suite
. administrative functions for rev-cache, start of integration into git
. support for non-commit object caching in rev-cache
. basic revision cache system, no integration or features
. man page and technical discussion for rev-cache
The author indicated that there is another round coming. Does not seem to
pass the tests when merged to 'pu', so it has been ejected for now.
* jc/log-tz (2009-03-03) 1 commit.
- Allow --date=local --date=other-format to work as expected
Maybe some people care about this. I dunno.
* jc/mailinfo-remove-brackets (2009-07-15) 1 commit.
- mailinfo: -b option keeps [bracketed] strings that is not a [PATCH] marker
Maybe some people care about this. I dunno.
* pb/gitweb-no-project-list (2009-11-06) 3 commits.
. gitweb: Polish the content tags support
. gitweb: Support for no project list on gitweb front page
. gitweb: Refactor project list routines
I picked these up but didn't queue as Warthog9's comments made certain
amount of sense to me.
^ permalink raw reply
* Re: [PATCH 1/2] Do curl option disabling before enabling new options
From: Tay Ray Chuan @ 2009-11-23 3:05 UTC (permalink / raw)
To: git; +Cc: Martin Storsjö
In-Reply-To: <20091123110328.748fcf09.rctay89@gmail.com>
Hi,
On Mon, Nov 23, 2009 at 11:03 AM, Tay Ray Chuan <rctay89@gmail.com> wrote:
> Squashed in another potential trigger for this bug in remote-curl.c,
> introduced in 'next'.
sorry, this should now read 'master'.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [PATCH 2/2] remote-curl.c: fix rpc_out()
From: Sverre Rabbelier @ 2009-11-23 5:53 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: git, Shawn O. Pearce, Junio C Hamano
In-Reply-To: <20091123110338.2b230359.rctay89@gmail.com>
Heya,
On Mon, Nov 23, 2009 at 04:03, Tay Ray Chuan <rctay89@gmail.com> wrote:
> remote-curl.c | 17 +++++++++++------
> 1 files changed, 11 insertions(+), 6 deletions(-)
Seems like this type of patch would do very well with a test case or two?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 0/2] jn/gitweb-blame fixes
From: Stephen Boyd @ 2009-11-23 4:52 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200911210132.44649.jnareb@gmail.com>
Jakub Narebski wrote:
> I have tested gitweb with both of your patches applied, serving gitweb
> as CGI script using Apache 2.0.54 on Linux, and viewing from separate
> computer on MS Windows XP, with the following results:
>
> * For the following browsers blame_incremental view on gitweb/gitweb.perl
> file produces correct output, but for progress info which instead of
> ( 1%) -> ( 29%) -> (100%) looks more like ( 1%) -> (29%) -> (100%)
This is due to an off-by-one error in the while loop. This should fix
it. I'll probably squash this into patch 2 and resend.
--->8----
diff --git a/gitweb/gitweb.js b/gitweb/gitweb.js
index 30597dd..9214497 100644
--- a/gitweb/gitweb.js
+++ b/gitweb/gitweb.js
@@ -43,7 +43,7 @@ function padLeftStr(input, width, str) {
var prefix = '';
width -= input.toString().length;
- while (width > 1) {
+ while (width > 0) {
prefix += str;
width--;
}
^ permalink raw reply related
* [PATCH] bisect: simplify calling visualizer using '--bisect' option
From: Christian Couder @ 2009-11-23 4:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds
In commit ad3f9a7 (Add '--bisect' revision machinery argument) the
'--bisect' option was added to easily pass bisection refs to
commands using the revision machinery.
So it is now shorter and safer to use the new '--bisect' revision
machinery option, than to compute the refs that we must pass.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
git-bisect.sh | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
This patch was previously sent in an RFC series aimed at
using '--bisect-refs' instead of '--bisect' as the revision
machinery bisect option.
diff --git a/git-bisect.sh b/git-bisect.sh
index 8b3c585..a5ea843 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -300,8 +300,7 @@ bisect_visualize() {
esac
fi
- not=$(git for-each-ref --format='%(refname)' "refs/bisect/good-*")
- eval '"$@"' refs/bisect/bad --not $not -- $(cat "$GIT_DIR/BISECT_NAMES")
+ eval '"$@"' --bisect -- $(cat "$GIT_DIR/BISECT_NAMES")
}
bisect_reset() {
--
1.6.5.1.gaf97d
^ permalink raw reply related
* Re: Android needs repo, Chrome needs gclient. Neither work. What does that say about git?
From: Adrian May @ 2009-11-23 4:11 UTC (permalink / raw)
To: git, chromium-discuss
In-Reply-To: <alpine.DEB.1.00.0911201229080.4985@pacific.mpi-cbg.de>
>> Git is just plain wrong, because you can't split or merge repositories
>> or pull subtrees of them.
>
> You are plain wrong, because that is possible. Did you maybe forget to do
> your homework before coming here and shouting around as if you were right?
So it is. Fair enough, I stand corrected. That was my single biggest
gripe about git so it's nice to know it's there.
> To the contrary, these "bolt-on scripts" are superior to other solutions,
> because they give the savvy user freedom to do _anything_ a program can
> do.
> Your complaing have the same sense as complaining that gcc does not
> include functionality of Makefile, because you just can't manage
> larger projects without it (or equivalent).
Well, these scripts, whatever git is written in and pretty much
everything else in sight is a Turing machine, so anything could, in
theory, do anything. But nevertheless, I think everybody agrees that
certain functions belong in certain places, even if they disagree
about where. I'd wager that 'make' belongs outside of gcc because it
also drives other compilers, things like yacc, post-build steps, etc.
OTOH I think producing browse info is a long-standing ommission from
gcc that should never have been done externally in things like ctags
and cscope, because the compiler has to do 90% of the work required
anyway and because it's the compiler's opinion that counts.
As for gclient and repo, without pretending to be an expert on what
they actually do, I'm getting a strong gut feeling that if what I'm
trying to do is pull or push code, then that's about as close as you
can get to a definition of source control's central purpose. In the
days of cvs or svn, I'd expect to use the source control for that. How
come git needs help? Basically, my point is that these scripts should
be the roadmap for git itself, because those are the functions people
had to add to their git-based set-up in the real world. Also because
the implementations would probably be simpler, more robust and more
general if they were in git.
> these "bolt-on scripts" give the savvy user freedom
Actually, I think their purpose is precisely the opposite: to regiment
the ordinary developer into following their process. So having that
code under the developer's control is a weakness.
As for pulling subtrees, I guess it's sensible for the code managers
to declare which subtrees are likely to work on their own by making
them repositories. I believe you can also link lots of repositories
together to make a huge combo-repository, so I don't understand why
android doesn't use that instead of having this script to iterate over
them all. Maybe they started before the split/merge thing got written
(it would have been risky to try and get it right first time if they
couldn't rearrange them later.)
>> It doesn't have the kind of triggers you
>> need to assert change control either, and these bolt-on scripts are
>> just making life messy.
>Can you elaborate?
Well, I believe that repo is largely about asserting their code
integration process. It knows who to send your changes to for review.
But now that I think about it, I guess git does that as a first
principle. If I push to your repo, you get to review it before it goes
in and in the meantime I shouldn't be surprised that our repos look
different. So what the hell do they write those scripts for? Does
anybody around here know if they actually need them or not?
Unfortunately their list doesn't seem to be taking my post.
> If you had problems pulling the code, there are two possible sources of
> problems: the program or a PEBCAK.
Well, the repo thing eventually got fixed: it was committing suicide
at the first sign of server load. I don't know what gclient's problem
is, but my personal opinion is that the *root* problem is the
existence of the scripts at all. In both cases, there's not much room
for pebcak in the instructions.
> You obviously do not understand Open Source. If you have an itch, scratch
> it, or pay somebody to scratch it for you.
I know, but I'm actually supposed to be getting on with my real job
instead of sticking my nose into other peoples' problems like this. I
might also argue that making suggestions is some kind of contribution,
at least if the value of the suggestion outweighs the distraction of
everybody having to read it to find out whether it's any use or not,
which may or may not be the case here. Either way, I also have a
budget for distractions and it doesn't allow for getting my brain
around the git source code.
Adrian.
^ permalink raw reply
* [PATCH 0/2] http fixes
From: Tay Ray Chuan @ 2009-11-23 3:03 UTC (permalink / raw)
To: git; +Cc: Martin Storsjö, Shawn O. Pearce, Junio C Hamano
Patch 1 ("Do curl option disabling before enabling new options"):
This is a workaround for a fairly recent curl issue that affected
versions up to 7.19.4.
Patch 2 ("remote-curl.c: fix rpc_out()"):
Fixes issues that affect chunked encoding.
http-push.c | 2 +-
remote-curl.c | 19 ++++++++++++-------
2 files changed, 13 insertions(+), 8 deletions(-)
--
Cheers,
Ray Chuan
^ permalink raw reply
* [PATCH 2/2] remote-curl.c: fix rpc_out()
From: Tay Ray Chuan @ 2009-11-23 3:03 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce, Junio C Hamano
Use comparisons between rpc->len and rpc->pos, rather than computing
their difference. This avoids potential errors when this value is
negative and we access it.
Use an int to store the return value from packet_read_line(), instead
of a size_t.
Handle the errorneous condition where rpc->pos exceeds rpc->len by
printing a message and aborting the transfer (return 0).
Remove extraneous semicolon (';') at the end of the if statement, that
prevented code in its block from executing.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
Users might experience issues when pushing with chunked encoding when
size_t avail is negative.
remote-curl.c | 17 +++++++++++------
1 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/remote-curl.c b/remote-curl.c
index 69eaf58..a2b8bbf 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -297,17 +297,22 @@ static size_t rpc_out(void *ptr, size_t eltsize,
{
size_t max = eltsize * nmemb;
struct rpc_state *rpc = buffer_;
- size_t avail = rpc->len - rpc->pos;
+ size_t avail = (size_t) 0;
- if (!avail) {
- avail = packet_read_line(rpc->out, rpc->buf, rpc->alloc);
- if (!avail)
+ if (rpc->pos == rpc->len) {
+ int n = packet_read_line(rpc->out, rpc->buf, rpc->alloc);
+ if (!n)
return 0;
rpc->pos = 0;
- rpc->len = avail;
+ avail = rpc->len = (size_t) n;
+ } else if (rpc->pos > rpc->len) {
+ error("bad condition!");
+ return 0;
+ } else {
+ avail = rpc->len - rpc->pos;
}
- if (max < avail);
+ if (max < avail)
avail = max;
memcpy(ptr, rpc->buf + rpc->pos, avail);
rpc->pos += avail;
--
1.6.5.3.301.gb2eb
^ permalink raw reply related
* [PATCH 1/2] Do curl option disabling before enabling new options
From: Tay Ray Chuan @ 2009-11-23 3:03 UTC (permalink / raw)
To: git; +Cc: Martin Storsjö
In-Reply-To: <Pine.LNX.4.64.0904142200130.7479@localhost.localdomain>
From: =?ISO-8859-15?Q?Martin_Storsj=F6?= <martin@martin.st>
This works around a bug in curl versions up to 7.19.4, where
disabling the CURLOPT_NOBODY option sets the internal state
incorrectly considering that CURLOPT_PUT was enabled earlier.
The bug is discussed at http://curl.haxx.se/bug/view.cgi?id=2727981
and is corrected in the latest version of curl in CVS.
This bug usually has no impact on git, but may surface if using
multi-pass authentication methods.
Signed-off-by: Martin Storsjo <martin@martin.st>
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
Squashed in another potential trigger for this bug in remote-curl.c,
introduced in 'next'.
http-push.c | 2 +-
remote-curl.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/http-push.c b/http-push.c
index f10803a..295f1fb 100644
--- a/http-push.c
+++ b/http-push.c
@@ -408,10 +408,10 @@ static void start_put(struct transfer_request *request)
curl_easy_setopt(slot->curl, CURLOPT_IOCTLDATA, &request->buffer);
#endif
curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, fwrite_null);
+ curl_easy_setopt(slot->curl, CURLOPT_NOBODY, 0);
curl_easy_setopt(slot->curl, CURLOPT_CUSTOMREQUEST, DAV_PUT);
curl_easy_setopt(slot->curl, CURLOPT_UPLOAD, 1);
curl_easy_setopt(slot->curl, CURLOPT_PUT, 1);
- curl_easy_setopt(slot->curl, CURLOPT_NOBODY, 0);
curl_easy_setopt(slot->curl, CURLOPT_URL, request->url);
if (start_active_slot(slot)) {
diff --git a/remote-curl.c b/remote-curl.c
index 4f28c22..69eaf58 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -356,8 +356,8 @@ static int post_rpc(struct rpc_state *rpc)
slot = get_active_slot();
slot->results = &results;
- curl_easy_setopt(slot->curl, CURLOPT_POST, 1);
curl_easy_setopt(slot->curl, CURLOPT_NOBODY, 0);
+ curl_easy_setopt(slot->curl, CURLOPT_POST, 1);
curl_easy_setopt(slot->curl, CURLOPT_URL, rpc->service_url);
curl_easy_setopt(slot->curl, CURLOPT_ENCODING, "");
--
1.6.4.4
^ permalink raw reply related
* [PATCH] git svn: strip leading path when making empty dirs
From: Eric Wong @ 2009-11-23 2:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Björn Steinbrink
In-Reply-To: <20091122235248.GA17418@atjola.homenet>
Björn Steinbrink <B.Steinbrink@gmx.de> wrote:
> Argh, yeah, I messed that patch up, the test only failed because I also
> messed up this line, adding the trunk prefix there, too. Fixed patch
> below.
>
> SVN Repo layout:
>
> /
> |
> |---trunk
> | |
> ... |---foo/ # Empty
> |
> |---bar/
> |
> somefile
>
> with "git svn clone -s svn://host/path/to/repo you get:
>
> .git
> bar/
> bar/somefile
> trunk/foo # This should be just foo/
>
> i.e. the empty directories have their path relative to the repo root,
> instead of relative to the directory the git branch is associated with.
>
> Sorry for the messed up first patch.
No worries, thanks for the bug report and test case. My brain's been
completely fried lately so I was completely confused :x
Anyways this should fix it:
Also pushed out to git://git.bogomips.org/git-svn:
Eric Wong (2):
git svn: always reuse existing remotes on fetch
git svn: strip leading path when making empty dirs
From 9be30eed61993a6f2d04a1609723e64e7632a64e Mon Sep 17 00:00:00 2001
From: Eric Wong <normalperson@yhbt.net>
Date: Sun, 22 Nov 2009 18:11:32 -0800
Subject: [PATCH] git svn: strip leading path when making empty dirs
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Since unhandled.log stores paths relative to the repository
root, we need to strip out leading path components if the
directories we're tracking are not the repository root.
Reported-by: Björn Steinbrink
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 3 +++
t/t9146-git-svn-empty-dirs.sh | 23 +++++++++++++++++++++++
2 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 7f7a56f..957d44e 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2752,8 +2752,11 @@ sub mkemptydirs {
}
}
close $fh;
+
+ my $strip = qr/\A\Q$self->{path}\E(?:\/|$)/;
foreach my $d (sort keys %empty_dirs) {
$d = uri_decode($d);
+ $d =~ s/$strip//;
next if -d $d;
if (-e _) {
warn "$d exists but is not a directory\n";
diff --git a/t/t9146-git-svn-empty-dirs.sh b/t/t9146-git-svn-empty-dirs.sh
index 5948544..70c52c1 100755
--- a/t/t9146-git-svn-empty-dirs.sh
+++ b/t/t9146-git-svn-empty-dirs.sh
@@ -82,4 +82,27 @@ test_expect_success 'git svn mkdirs -r works' '
)
'
+test_expect_success 'initialize trunk' '
+ for i in trunk trunk/a trunk/"weird file name"
+ do
+ svn_cmd mkdir -m "mkdir $i" "$svnrepo"/"$i"
+ done
+'
+
+test_expect_success 'clone trunk' 'git svn clone -s "$svnrepo" trunk'
+
+test_expect_success 'empty directories in trunk exist' '
+ (
+ cd trunk &&
+ for i in a "weird file name"
+ do
+ if ! test -d "$i"
+ then
+ echo >&2 "$i does not exist"
+ exit 1
+ fi
+ done
+ )
+'
+
test_done
--
Eric Wong
^ permalink raw reply related
* [PATCH 0/2] Miscellaneous documentation updates
From: Matthew Ogilvie @ 2009-11-23 2:07 UTC (permalink / raw)
To: git, gitster; +Cc: Matthew Ogilvie
This is a series of documentation updates. They are independent of
each other.
These are separate from and do not duplicate the core.autocrlf patch
from a week ago.
Matthew Ogilvie (2):
cvsserver doc: database generally can not be reproduced consistently
config documentation: some configs are auto-set by git-init
Documentation/config.txt | 24 ++++++++++++++++++++++--
Documentation/git-cvsserver.txt | 19 +++++++++++++++----
2 files changed, 37 insertions(+), 6 deletions(-)
^ permalink raw reply
* [PATCH 2/2] config documentation: some configs are auto-set by git-init
From: Matthew Ogilvie @ 2009-11-23 2:07 UTC (permalink / raw)
To: git, gitster; +Cc: Matthew Ogilvie
In-Reply-To: <1258942050-11423-2-git-send-email-mmogilvi_git@miniinfo.net>
Add documentation for core.ignorecase, and mention git-init
in core.filemode and core.symlinks.
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
---
Documentation/config.txt | 24 ++++++++++++++++++++++--
1 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 78ee906..b2ee139 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -131,7 +131,11 @@ advice.*::
core.fileMode::
If false, the executable bit differences between the index and
the working copy are ignored; useful on broken filesystems like FAT.
- See linkgit:git-update-index[1]. True by default.
+ See linkgit:git-update-index[1].
++
+The default is true, except linkgit:git-clone[1] or linkgit:git-init[1]
+will probe and set core.fileMode false if appropriate when the
+repository is created.
core.ignoreCygwinFSTricks::
This option is only used by Cygwin implementation of Git. If false,
@@ -144,6 +148,18 @@ core.ignoreCygwinFSTricks::
is true, in which case ignoreCygwinFSTricks is ignored as Cygwin's
POSIX emulation is required to support core.filemode.
+core.ignorecase::
+ If true, this option enables various workarounds to enable
+ git to work better on filesystems that are not case sensitive,
+ like FAT. For example, if a directory listing finds
+ "makefile" when git expects "Makefile", git will assume
+ it is really the same file, and continue to remember it as
+ "Makefile".
++
+The default is false, except linkgit:git-clone[1] or linkgit:git-init[1]
+will probe and set core.ignorecase true if appropriate when the repository
+is created.
+
core.trustctime::
If false, the ctime differences between the index and the
working copy are ignored; useful when the inode change time
@@ -223,7 +239,11 @@ core.symlinks::
contain the link text. linkgit:git-update-index[1] and
linkgit:git-add[1] will not change the recorded type to regular
file. Useful on filesystems like FAT that do not support
- symbolic links. True by default.
+ symbolic links.
++
+The default is true, except linkgit:git-clone[1] or linkgit:git-init[1]
+will probe and set core.symlinks false if appropriate when the repository
+is created.
core.gitProxy::
A "proxy command" to execute (as 'command host port') instead
--
1.6.4.GIT
^ permalink raw reply related
* [PATCH 1/2] cvsserver doc: database generally can not be reproduced consistently
From: Matthew Ogilvie @ 2009-11-23 2:07 UTC (permalink / raw)
To: git, gitster; +Cc: Matthew Ogilvie
In-Reply-To: <1258942050-11423-1-git-send-email-mmogilvi_git@miniinfo.net>
A regenerated git-cvsserver database is at risk of having different
CVS revision numbers from an incrementally updated database. Mention
this in the the documentation, and remove an erroneous statement
to the contrary.
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
---
Documentation/git-cvsserver.txt | 19 +++++++++++++++----
1 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-cvsserver.txt b/Documentation/git-cvsserver.txt
index 785779e..99a7c14 100644
--- a/Documentation/git-cvsserver.txt
+++ b/Documentation/git-cvsserver.txt
@@ -182,10 +182,9 @@ Database Backend
----------------
'git-cvsserver' uses one database per git head (i.e. CVS module) to
-store information about the repository for faster access. The
-database doesn't contain any persistent data and can be completely
-regenerated from the git repository at any time. The database
-needs to be updated (i.e. written to) after every commit.
+store information about the repository to maintain consistent
+CVS revision numbers. The database needs to be
+updated (i.e. written to) after every commit.
If the commit is done directly by using `git` (as opposed to
using 'git-cvsserver') the update will need to happen on the
@@ -204,6 +203,18 @@ write so it might not be enough to grant the users using
'git-cvsserver' write access to the database file without granting
them write access to the directory, too.
+The database can not be reliably regenerated in a
+consistent form after the branch it is tracking has changed.
+Example: For merged branches, 'git-cvsserver' only tracks
+one branch of development, and after a 'git-merge' an
+incrementally updated database may track a different branch
+than a database regenerated from scratch, causing inconsistent
+CVS revision numbers. `git-cvsserver` has no way of knowing which
+branch it would have picked if it had been run incrementally
+pre-merge. So if you have to fully or partially (from old
+backup) regenerate the database, you should be suspicious
+of pre-existing CVS sandboxes.
+
You can configure the database backend with the following
configuration variables:
--
1.6.4.GIT
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox