* What's cooking in git.git (Dec 2009, #05; Mon, 28)
From: Junio C Hamano @ 2009-12-28 9:57 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.
--------------------------------------------------
[Graduated to "master"]
* sr/vcs-helper (2009-12-07) 14 commits
(merged to 'next' on 2009-12-07 at 8f041bc)
+ tests: handle NO_PYTHON setting
(merged to 'next' on 2009-12-03 at e45b562)
+ builtin-push: don't access freed transport->url
(merged to 'next' on 2009-11-27 at 83268ab)
+ 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
* 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-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
* 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 branch is used by jc/1.7.0-diff-whitespace-prepare and jc/diff-whitespace-prepare.)
This changes exit code from "git diff --ignore-whitespace" and friends
when there is no actual output.
* gb/1.7.0-diff-whitespace-only-output (2009-11-19) 1 commit
(merged to 'next' on 2009-11-21 at 3375bf4)
+ No diff -b/-w output for all-whitespace changes
(this branch is used by jc/1.7.0-diff-whitespace-prepare and jc/diff-whitespace-prepare.)
Likewise but for the output of "diff --git" headers.
* jk/1.7.0-status (2009-12-11) 16 commits
(merged to 'next' on 2009-12-24 at e9929b3)
+ status/commit: do not suggest "reset HEAD <path>" while merging
+ commit/status: "git add <path>" is not necessarily how to resolve
+ commit/status: check $GIT_DIR/MERGE_HEAD only once
(merged to 'next' on 2009-12-08 at 9b57d84)
+ t7508-status: test all modes with color
+ t7508-status: status --porcelain ignores relative paths setting
(merged to 'next' on 2009-12-07 at 7723acf)
+ status: reduce duplicated setup code
+ status: disable color for porcelain format
(merged to 'next' on 2009-12-05 at 44dcefd)
+ status -s: obey color.status
+ builtin-commit: refactor short-status code into wt-status.c
(merged to 'next' on 2009-11-27 at 91691ec)
+ t7508-status.sh: Add tests for status -s
+ status -s: respect the status.relativePaths option
(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".
--------------------------------------------------
[New Topics]
* jc/cache-unmerge (2009-12-25) 9 commits
- rerere forget path: forget recorded resolution
- rerere: refactor rerere logic to make it independent from I/O
- rerere: remove silly 1024-byte line limit
- resolve-undo: teach "update-index --unresolve" to use resolve-undo info
- resolve-undo: "checkout -m path" uses resolve-undo information
- resolve-undo: allow plumbing to clear the information
- resolve-undo: basic tests
- resolve-undo: record resolved conflicts in a new index extension section
- builtin-merge.c: use standard active_cache macros
* js/filter-branch-prime (2009-12-15) 1 commit
- filter-branch: remove an unnecessary use of 'git read-tree'
* mg/tag-d-show (2009-12-10) 1 commit
- tag -d: print sha1 of deleted tag
* sb/maint-octopus (2009-12-11) 3 commits
- octopus: remove dead code
- octopus: reenable fast-forward merges
- octopus: make merge process simpler to follow
* il/exec-error-report (2009-12-24) 2 commits
- Improve transport helper exec failure reporting
- Report exec errors from run-command
--------------------------------------------------
[Cooking]
* jh/commit-status (2009-12-07) 1 commit
- [test?] Add commit.status, --status, and --no-status
* jc/checkout-merge-base (2009-11-20) 2 commits
(merged to 'next' on 2009-12-24 at ff4d1d4)
+ "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
* tr/http-push-ref-status (2009-12-24) 6 commits
- transport-helper.c::push_refs(): emit "no refs" error message
- transport-helper.c::push_refs(): ignore helper-reported status if ref is not to be pushed
- transport.c::transport_push(): make ref status affect return value
- refactor ref status logic for pushing
- t5541-http-push.sh: add test for unmatched, non-fast-forwarded refs
- t5541-http-push.sh: add tests for non-fast-forward pushes
* bg/maint-add-all-doc (2009-12-07) 4 commits
- squash! rm documentation--also mention add-u where we mention commit-a
- git-rm doc: Describe how to sync index & work tree
- git-add/rm doc: Consistently back-quote
- Documentation: 'git add -A' can remove files
I didn't like the existing documentation for "add -u" myself (especially
because I wrote the initial version) and this neatly fix it as well.
* il/vcs-helper (2009-12-09) 8 commits
- Remove special casing of http, https and ftp
- Support remote archive from all smart transports
- Support remote helpers implementing smart transports
- Support taking over transports
- Refactor git transport options parsing
- Pass unknown protocols to external protocol handlers
- Support mandatory capabilities
- Add remote helper debug mode
* mm/diag-path-in-treeish (2009-12-07) 1 commit
- Detailed diagnosis when parsing an object name fails.
* mh/rebase-fixup (2009-12-07) 2 commits
- Add a command "fixup" to rebase --interactive
- t3404: Use test_commit to set up test repository
(this branch is used by ns/rebase-auto-squash.)
Initial round of "fixup" action that is similar to "squash" action in
"rebase -i" that excludes the commit log message from follow-up commits
when composing the log message for the updated one. Expected is a further
improvement to skip opening the editor if a pick is followed only by
"fixup" and no "squash".
* ns/rebase-auto-squash (2009-12-08) 2 commits
- fixup! rebase -i --autosquash
- rebase -i --autosquash: auto-squash commits
(this branch uses mh/rebase-fixup.)
* jh/notes (2009-12-07) 11 commits
- 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
- Minor style fixes to notes.c
- 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
* fc/opt-quiet-gc-reset (2009-12-02) 1 commit
- General --quiet improvements
* mv/commit-date (2009-12-03) 2 commits
- Document date formats accepted by parse_date()
- builtin-commit: add --date option
* sr/gfi-options (2009-12-04) 7 commits
- fast-import: add (non-)relative-marks feature
- fast-import: allow for multiple --import-marks= arguments
- fast-import: test the new option command
- fast-import: add option command
- fast-import: add feature command
- fast-import: put marks reading in its own function
- fast-import: put option parsing code in separate functions
* ap/merge-backend-opts (2008-07-18) 6 commits
- Document that merge strategies can now take their own options
- Extend merge-subtree tests to test -Xsubtree=dir.
- Make "subtree" part more orthogonal to the rest of merge-recursive.
- Teach git-pull to pass -X<option> to git-merge
- git merge -X<option>
- git-merge-file --ours, --theirs
"git pull" patch needs sq-then-eval fix to protect it from $IFS
but otherwise seemed good.
* mo/bin-wrappers (2009-12-02) 3 commits
- INSTALL: document a simpler way to run uninstalled builds
- run test suite without dashed git-commands in PATH
- build dashless "bin-wrappers" directory similar to installed bindir
* tr/http-updates (2009-12-01) 3 commits
(merged to 'next' on 2009-12-07 at f08d447)
+ Allow curl to rewind the RPC read buffer
+ Add an option for using any HTTP authentication scheme, not only basic
+ http: maintain curl sessions
* nd/sparse (2009-12-14) 22 commits
(merged to 'next' on 2009-12-24 at 1fa9ff3)
+ commit: correctly respect skip-worktree bit
+ ie_match_stat(): do not ignore skip-worktree bit with CE_MATCH_IGNORE_VALID
(merged to 'next' on 2009-11-25 at 71380f5)
+ tests: rename duplicate t1009
(merged to 'next' on 2009-11-23 at f712a41)
+ 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
--------------------------------------------------
[Ejected]
* 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
* 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.
* jc/grep-full-tree (2009-11-24) 1 commit
. grep: --full-tree
The interaction with this option and pathspecs need to be worked out
better. I _think_ "grep --full-tree -e pattern -- '*.h'" should find from
all the header files in the tree, for example.
* cc/reset-more (2009-12-08) 6 commits
. Documentation: reset: add some tables to describe the different options
. Documentation: reset: describe new "--keep-local-changes" option
. reset: add test cases for "--keep-local-changes" option
. reset: add option "--keep-local-changes" to "git reset"
. reset: use "unpack_trees()" directly instead of "git read-tree"
. reset: add a few tests for "git reset --merge"
The documentation is much clearer than the previous round in describing
what it does, but I find it a bit unclear in describing what it is _good_
for (iow, scenarios and use cases).
Breaks 'pu' and does not pass test on its own yet.
^ permalink raw reply
* Re: [Squash PATCH] fprintf(stderr, "Warning...") -> warning("...")
From: Junio C Hamano @ 2009-12-28 9:24 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <1261651279-29041-1-git-send-email-ilari.liusvaara@elisanet.fi>
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> writes:
> Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
> ---
> transport-helper.c | 7 +++----
> 1 files changed, 3 insertions(+), 4 deletions(-)
>
> This fixes the small nit about fprintf(stderr, "Warning: ") by using
> warning() API.
>
> It can be appiled on top of "Support remote helpers implementing smart
> transports" or squashed to it.
Thanks; will squash but with two minor touch-ups:
- warning() adds its own terminating LF so we need to drop it from the caller;
- being able to grep for an error/warning message is more important than
keeping the source line strictly shorter than 80-columns.
> diff --git a/transport-helper.c b/transport-helper.c
> index 55427df..8c8ca8e 100644
> --- a/transport-helper.c
> +++ b/transport-helper.c
> @@ -420,11 +420,10 @@ static int process_connect_service(struct transport *transport,
> if (strcmp(name, exec)) {
> r = set_helper_option(transport, "servpath", exec);
> if (r > 0)
> - fprintf(stderr, "Warning: Setting remote service path "
> - "not supported by protocol.\n");
> + warning("Setting remote service path not supported "
> + "by protocol.\n");
> else if (r < 0)
> - fprintf(stderr, "Warning: Invalid remote service "
> - "path.\n");
> + warning("Invalid remote service path.\n");
> }
>
> if (data->connect)
> --
> 1.6.6.3.gaa2e1
^ permalink raw reply
* Re: [PATCH] Documentation: always respect core.worktree if set
From: Junio C Hamano @ 2009-12-28 9:16 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: git, Johannes Schindelin, Robin Rosenberg
In-Reply-To: <1261979704-30074-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> In the beginning, there was GIT_DIR environment variable, with a very
> simple semantics:
> ...
(Omitted an explanation of how GIT_DIR and core.worktree work together).
> According to the current documentation, if GIT_DIR is not set,
> core.worktree is not respected, and the parent directory of the "git
> directory" may be used as worktree. This case, unless core.worktree
> matches the parent directory of the "git directory" in question, seems
> a misconfiguration and nothing else. So remove this part of the
> documentation.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> Junio may find the description highly familiar :) only slightly modified
> at the end
I found it familiar, but I didn't see how that earlier part leads to the
conclusion in, or even gives a necessary background information for, the
last paragraph. Perhaps you omitted something in the middle that was more
relevant? If so, I would suggest omiting the earlier part, whose purpose
was to prepare readers for that middle part, as well.
And I don't think the claim your last paragraph makes is consistent with
what the patch does at all.
Removing the "it will be ignored" from the documentation is a good change
only in the sense that it makes the document closer to reality, but "it is
a misconfiguration" is not a good justification of the change.
A documentation-only patch that can be justitifed by "a misconfiguration"
claim would probably read like this:
The value of core.worktree in a ".git/config" is honored even when
it differs from the directory that has the ".git" directory as its
subdirectory. This is likely to be a misconfiguration, so warn
users about it. Also, drop the part of the documentation that
incorrectly claimed that we ignore such a misconfigured value.
---
core.worktree::
Set the path to the root of the work tree. Note that this
is honored even when set in a configuration file in a
".git" subdirectory of a directory, and its value differs
from the latter directory (e.g. "/path/to/.git/config" has
core.worktree set to "/different/path"), which is most
likely a misconfiguration. Running git commands in
"/path/to" directory will still use "/different/path" as
the root of the work tree and can cause great confusion to
the users.
Your earlier patch took a different approach to the misconfiguration. "It
is an error, so we silently _ignore_". It is a valid thing to say, but
the "silently" part is not friendly to the user and we would probably want
to diagnose and warn. That is what I originally meant.
^ permalink raw reply
* [PATCH] Documentation: always respect core.worktree if set
From: Nguyễn Thái Ngọc Duy @ 2009-12-28 5:55 UTC (permalink / raw)
To: git, Junio C Hamano, Johannes Schindelin, Robin Rosenberg
Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <fcaeb9bf0912272141j1def76e7v6f581636188e65f0@mail.gmail.com>
In the beginning, there was GIT_DIR environment variable. We had a very
simple semantics:
- When there is no GIT_DIR environment variable:
- if "." is a "git directory", i.e. it has the set of git things like
refs/, objects/ and HEAD, then you are working in a bare repository.
- if ./.git exists and it is a "git directory", then "." is the top of
the work tree;
- otherwise, try the parent directory of "." for the second rule
repeatedly to find the git directory and the top of the work tree.
- When there is GIT_DIR environment variable:
- $GIT_DIR is (and must be) the "git directory" and "." is the top of
the work tree.
People wanted to have a work tree that is at a location totally unrelated
to where the "git directory" and setting $GIT_DIR at runtime was the only
way to do so, but that restricted them to work only at the top of the work
tree. $GIT_WORK_TREE was invented as a way to say "this is the top of the
work tree". So that people can do something like:
$ GIT_DIR=/srv/git/proj.git GIT_WORK_TREE=/scratch/proj
$ export GIT_DIR GIT_WORK_TREE
$ cd $GIT_WORK_TREE/Documentation
$ edit; git diff; git commit -a; ...
Because the facility was meant to allow separation of "git directory" and
its associated work tree, and not meant to allow more than one work trees
sharing the same "git directory" (which does not make any sense, as there
is only one index in "git directory" that describes the state of the work
tree), it was an unnecessary nuisanse that you had to set two environment
variables. core.worktree was invented---by recording the location of the
work tree in the config file in the "git directory", the above can be made
into this:
$ GIT_DIR=/srv/git/proj.git
$ cd /scratch/proj/Documentation
$ edit; git diff; git commit -a; ...
According to the current documentation, if GIT_DIR is not set,
core.worktree is not respected, and the parent directory of the "git
directory" may be used as worktree. This case, unless core.worktree
matches the parent directory of the "git directory" in question, seems
a misconfiguration and nothing else. So remove this part of the
documentation.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Junio may find the description highly familiar :) only slightly modified
at the end
Documentation/config.txt | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 7d10a21..4b3d568 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -297,9 +297,7 @@ false), while all other repositories are assumed to be bare (bare
= true).
core.worktree::
- Set the path to the working tree. The value will not be
- used in combination with repositories found automatically in
- a .git directory (i.e. $GIT_DIR is not set).
+ Set the path to the working tree.
This can be overridden by the GIT_WORK_TREE environment
variable and the '--work-tree' command line option. It can be
a absolute path or relative path to the directory specified by
--
1.6.5.2.216.g9c1ec
^ permalink raw reply related
* Re: [PATCH] Fix core.worktree being used when GIT_DIR is not set
From: Nguyen Thai Ngoc Duy @ 2009-12-28 5:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, Robin Rosenberg
In-Reply-To: <7viqbsw2vn.fsf@alter.siamese.dyndns.org>
On 12/28/09, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>
> > According to config.txt:
> >> core.worktree::
> >> Set the path to the working tree. The value will not be
> >> used in combination with repositories found automatically in
> >> a .git directory (i.e. $GIT_DIR is not set).
> >
> > This behavior was changed after e90fdc3 (Clean up work-tree handling -
> > 2007-08-01) and 9459aa7 (Do check_repository_format() early (re-fix) -
> > 2007-12-05). If core.worktree is set, even if git_dir automatically
> > found (and git_work_tree_cfg set), git_work_tree_cfg will be reset to
> > core.worktree. This makes core.worktree effective even if GIT_DIR is
> > not set, in contrast to config.txt.
> >
> > This patch makes sure it only checks for core.worktree if GIT_DIR is set.
>
>
> The work-tree area got too complicated over time for a small Panda brain
> to grasp, so let me think aloud here.
>
> ...
>
> Given these background, I am not sure the "fix" is addressing the right
> issue. What does it mean to have "core.worktree" in a configuration file,
> but that configuration file was found in a "git directory" that was found
> thorough the repository discovery process due to lack of $GIT_DIR? There
> are only two cases I can see:
>
> - The user is in the "git directory" itself, which is bare (iow,
> /srv/git/proj.git in the above example). This is not the case the
> documentation snippet you quoted is about, and I don't think your patch
> changes (nor should change) the behaviour for;
>
> - The "git directory" is a ".git/" subdirectory of some work tree, and
> the value of core.worktree may or may not match that work tree. This
> is the case the documentation talks about, and your patch addresses.
>
> For the former case, while I don't see much point, we do seem to support
> this use case (continuing the example scenario):
>
> $ unset GIT_DIR GIT_WORK_TREE
> $ cd /srv/git/proj.git
> $ git checkout -b newbranch master
>
> We find that "." is our "git directory", and through its config file, we
> know core.worktree points at /scratch/proj/, and the checkout updates
> files over there, not in /srv/git/proj.git/. While it is not obvious why
> anybody finds this useful to me, I think the behaviour makes _some_ sense,
> and I don't think your patch breaks it by changing the behaviour for this
> case [*1*].
>
> The latter, unless core.worktree matches the parent directory of the "git
> directory" in question, seems to me a misconfiguration and nothing else.
> Shouldn't it be diagnosed as an error, instead of matching the
> documentation to the letter?
I had not read that part of the documentation until Robin pointed out
and always thought core.worktree was in effect if set. I thought the
author intention was not to let core.worktree get in the way if not
requested, but given that the worktree is moved to somewhere else
already, that does not make sense as it could use parent directory of
the "git directory" as worktree (unless core.worktree matches the
parent directory as you said). Probably best fixing documentation.
--
Duy
^ permalink raw reply
* Fwd: Set the repository as it was on an earlier commit
From: Sergio Belkin @ 2009-12-28 5:18 UTC (permalink / raw)
To: git
In-Reply-To: <8c6f7f450912272019t4b9c721dt2630a8d32607013e@mail.gmail.com>
Ooops I wanted to say Santi answer was the best
---------- Forwarded message ----------
From: Sergio Belkin <sebelk@gmail.com>
Date: 2009/12/28
Subject: Re: Set the repository as it was on an earlier commit
To: git@vger.kernel.org
2009/12/26 Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>:
> Santi Béjar <santi@agolina.net> writes:
>
>> I don't know if it is possible with porcelain commands, but with
>> plumbing you can:
>>
>> # begin with a clean working dir
>> git read-tree B
>> git commit
>> git reset --hard
>
> I guess
>
> (at the root of the repo)
>
> git checkout B -- .
> # git status if you want to check.
> git commit
>
> does this. The "-- ." part of "git checkout" asks Git to checkout the
> files, but the path limiter prevents it from updating HEAD, so the
> HEAD still points to the tip of the branch.
>
> --
> Matthieu Moy
> http://www-verimag.imag.fr/~moy/
>
Sorry but really answer given by Steven was better, because last one
omit the case when B had less files that D for example...
Thanks everyone
--
--
Open Kairos http://www.sergiobelkin.com
Watch More TV http://sebelk.blogspot.com
Sergio Belkin -
--
--
Open Kairos http://www.sergiobelkin.com
Watch More TV http://sebelk.blogspot.com
Sergio Belkin -
^ permalink raw reply
* [PATCH v2] Smart-http documentation: add example of how to execute from userdir
From: Tarmigan Casebolt @ 2009-12-28 4:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Tarmigan Casebolt, Tay Ray Chuan, Shawn O. Pearce
In-Reply-To: <905315640912272018r1282394fh62d37b5c9e91a234@mail.gmail.com>
Smart-http may be an attactive and easy way for people to setup git
hosting on shared servers whose primary web server configuration they
do not control. To facilite this, provide an example of how it may be
done.
cc: Tay Ray Chuan <rctay89@gmail.com>
cc: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Tarmigan Casebolt <tarmigan+git@gmail.com>
---
Looking at the
s/update/updates/
suggestion again, I decided not to make that change because I think
the original is grammical even if a little bit awkward. The first
'updates' is the noun, so the verb should be 'update' without an 's'.
I also tried rephrasing that sentence completely, but did not end up
with something better. Suggestions welcome.
Documentation/git-http-backend.txt | 31 +++++++++++++++++++++++++++++--
1 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-http-backend.txt b/Documentation/git-http-backend.txt
index 67aec06..fdff2d3 100644
--- a/Documentation/git-http-backend.txt
+++ b/Documentation/git-http-backend.txt
@@ -60,8 +60,8 @@ automatically by the web server.
EXAMPLES
--------
-All of the following examples map 'http://$hostname/git/foo/bar.git'
-to '/var/www/git/foo/bar.git'.
+Unless otherwise noted, the following examples map
+'http://$hostname/git/foo/bar.git' to '/var/www/git/foo/bar.git'.
Apache 2.x::
Ensure mod_cgi, mod_alias, and mod_env are enabled, set
@@ -144,6 +144,33 @@ ScriptAliasMatch \
ScriptAlias /git/ /var/www/cgi-bin/gitweb.cgi/
----------------------------------------------------------------
+In the following example, a repository at
+'/home/$username/devel/foo/bar.git' will be accessible at
+'http://$hostname/\~$username/cgi-bin/git/foo/bar.git'
+
+From UserDir on Apache 2.x::
+ One way to configure 'git-http-backend' to execute and serve
+ from a user directory (for example, on a shared hosting
+ provider), is to have a symbolic link named 'git' that points
+ from the cgi directory to the 'git-http-backend' executable in
+ libexec. The advantage of the symbolic link is that any updates
+ to the installed version of 'git-http-backend' also update the
+ version that is run in the userdir.
++
+----------------------------------------------------------------
+SetHandler cgi-script
+Options +SymLinksIfOwnerMatch
+SetEnv GIT_PROJECT_ROOT /home/$username/devel
+----------------------------------------------------------------
++
+Also add any needed authentication to the .htaccess file as discussed
+in earlier examples.
++
+If the web server does not follow any symbolic links, the
+'git-http-backend' executable may be copied into the cgi-bin directory
+and renamed to 'git' to acheive the same effect, but it will also need
+to be manually updated whenever a new version of 'git-http-backend' is
+installed.
ENVIRONMENT
-----------
--
1.6.6.1.g8eede.dirty
^ permalink raw reply related
* [PATCH] Smart-http: check if repository is OK to export before serving it
From: Tarmigan Casebolt @ 2009-12-28 4:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Tarmigan Casebolt
In-Reply-To: <905315640912272007i8b4904dv2b93879789b453fb@mail.gmail.com>
Similar to how git-daemon checks whether a repository is OK to be
exported, smart-http should also check. This check can be satisfied
in two different ways: the environmental variable GIT_HTTP_EXPORT_ALL
may be set to export all repositories, or the individual repository
may have the file git-daemon-export-ok.
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Tarmigan Casebolt <tarmigan+git@gmail.com>
---
Documentation/git-http-backend.txt | 10 +++++++++
http-backend.c | 3 ++
t/lib-httpd/apache.conf | 5 ++++
t/t5560-http-backend.sh | 39 ++++++++++++++++++++++++++++++++++-
4 files changed, 55 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-http-backend.txt b/Documentation/git-http-backend.txt
index 67aec06..c8fe08a 100644
--- a/Documentation/git-http-backend.txt
+++ b/Documentation/git-http-backend.txt
@@ -18,6 +18,11 @@ The program supports clients fetching using both the smart HTTP protcol
and the backwards-compatible dumb HTTP protocol, as well as clients
pushing using the smart HTTP protocol.
+It verifies that the directory has the magic file
+"git-daemon-export-ok", and it will refuse to export any git directory
+that hasn't explicitly been marked for export this way (unless the
+GIT_HTTP_EXPORT_ALL environmental variable is set).
+
By default, only the `upload-pack` service is enabled, which serves
'git-fetch-pack' and 'git-ls-remote' clients, which are invoked from
'git-fetch', 'git-pull', and 'git-clone'. If the client is authenticated,
@@ -70,6 +75,7 @@ Apache 2.x::
+
----------------------------------------------------------------
SetEnv GIT_PROJECT_ROOT /var/www/git
+SetEnv GIT_HTTP_EXPORT_ALL
ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/
----------------------------------------------------------------
+
@@ -157,6 +163,10 @@ by the invoking web server, including:
* QUERY_STRING
* REQUEST_METHOD
+The GIT_HTTP_EXPORT_ALL environmental variable may be passed to
+'git-http-backend' to bypass the check for the "git-daemon-export-ok"
+file in each repository before allowing export of that repository.
+
The backend process sets GIT_COMMITTER_NAME to '$REMOTE_USER' and
GIT_COMMITTER_EMAIL to '$\{REMOTE_USER}@http.$\{REMOTE_ADDR\}',
ensuring that any reflogs created by 'git-receive-pack' contain some
diff --git a/http-backend.c b/http-backend.c
index f729488..9de85cb 100644
--- a/http-backend.c
+++ b/http-backend.c
@@ -648,6 +648,9 @@ int main(int argc, char **argv)
setup_path();
if (!enter_repo(dir, 0))
not_found("Not a git repository: '%s'", dir);
+ if (!getenv("GIT_HTTP_EXPORT_ALL") &&
+ access("git-daemon-export-ok", F_OK) )
+ forbidden("Repository not exported: '%s'", dir);
git_config(http_config, NULL);
cmd->imp(cmd_arg);
diff --git a/t/lib-httpd/apache.conf b/t/lib-httpd/apache.conf
index 0fe3fd0..4961505 100644
--- a/t/lib-httpd/apache.conf
+++ b/t/lib-httpd/apache.conf
@@ -22,8 +22,13 @@ Alias /dumb/ www/
<Location /smart/>
SetEnv GIT_EXEC_PATH ${GIT_EXEC_PATH}
+ SetEnv GIT_HTTP_EXPORT_ALL
+</Location>
+<Location /smart_noexport/>
+ SetEnv GIT_EXEC_PATH ${GIT_EXEC_PATH}
</Location>
ScriptAlias /smart/ ${GIT_EXEC_PATH}/git-http-backend/
+ScriptAlias /smart_noexport/ ${GIT_EXEC_PATH}/git-http-backend/
<Directory ${GIT_EXEC_PATH}>
Options None
</Directory>
diff --git a/t/t5560-http-backend.sh b/t/t5560-http-backend.sh
index ed034bc..126f6d5 100755
--- a/t/t5560-http-backend.sh
+++ b/t/t5560-http-backend.sh
@@ -23,7 +23,7 @@ config() {
}
GET() {
- curl --include "$HTTPD_URL/smart/repo.git/$1" >out 2>/dev/null &&
+ curl --include "$HTTPD_URL/$SMART/repo.git/$1" >out 2>/dev/null &&
tr '\015' Q <out |
sed '
s/Q$//
@@ -91,6 +91,20 @@ get_static_files() {
GET $IDX_URL "$1"
}
+SMART=smart_noexport
+test_expect_success 'no export by default' '
+ log_div "no git-daemon-export-ok"
+ get_static_files "403 Forbidden"
+'
+test_expect_success 'export if git-daemon-export-ok' '
+ log_div "git-daemon-export-ok"
+ (cd "$HTTPD_DOCUMENT_ROOT_PATH/repo.git" &&
+ touch git-daemon-export-ok
+ ) &&
+ get_static_files "200 OK"
+'
+
+SMART=smart
test_expect_success 'direct refs/heads/master not found' '
log_div "refs/heads/master"
GET refs/heads/master "404 Not Found"
@@ -145,7 +159,6 @@ test_expect_success 'http.receivepack false' '
GET info/refs?service=git-receive-pack "403 Forbidden" &&
POST git-receive-pack 0000 "403 Forbidden"
'
-
run_backend() {
REQUEST_METHOD=GET \
GIT_PROJECT_ROOT="$HTTPD_DOCUMENT_ROOT_PATH" \
@@ -179,6 +192,28 @@ test_expect_success 'http-backend blocks bad PATH_INFO' '
cat >exp <<EOF
+### no git-daemon-export-ok
+###
+GET /smart_noexport/repo.git/HEAD HTTP/1.1 403 -
+GET /smart_noexport/repo.git/info/refs HTTP/1.1 403 -
+GET /smart_noexport/repo.git/objects/info/packs HTTP/1.1 403 -
+GET /smart_noexport/repo.git/objects/info/alternates HTTP/1.1 403 -
+GET /smart_noexport/repo.git/objects/info/http-alternates HTTP/1.1 403 -
+GET /smart_noexport/repo.git/$LOOSE_URL HTTP/1.1 403 -
+GET /smart_noexport/repo.git/$PACK_URL HTTP/1.1 403 -
+GET /smart_noexport/repo.git/$IDX_URL HTTP/1.1 403 -
+
+### git-daemon-export-ok
+###
+GET /smart_noexport/repo.git/HEAD HTTP/1.1 200
+GET /smart_noexport/repo.git/info/refs HTTP/1.1 200
+GET /smart_noexport/repo.git/objects/info/packs HTTP/1.1 200
+GET /smart_noexport/repo.git/objects/info/alternates HTTP/1.1 200 -
+GET /smart_noexport/repo.git/objects/info/http-alternates HTTP/1.1 200 -
+GET /smart_noexport/repo.git/$LOOSE_URL HTTP/1.1 200
+GET /smart_noexport/repo.git/$PACK_URL HTTP/1.1 200
+GET /smart_noexport/repo.git/$IDX_URL HTTP/1.1 200
+
### refs/heads/master
###
GET /smart/repo.git/refs/heads/master HTTP/1.1 404 -
--
1.6.6.1.g8eede.dirty
^ permalink raw reply related
* Re: Set the repository as it was on an earlier commit
From: Sergio Belkin @ 2009-12-28 4:19 UTC (permalink / raw)
To: git
In-Reply-To: <vpqiqbt95e7.fsf@bauges.imag.fr>
2009/12/26 Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>:
> Santi Béjar <santi@agolina.net> writes:
>
>> I don't know if it is possible with porcelain commands, but with
>> plumbing you can:
>>
>> # begin with a clean working dir
>> git read-tree B
>> git commit
>> git reset --hard
>
> I guess
>
> (at the root of the repo)
>
> git checkout B -- .
> # git status if you want to check.
> git commit
>
> does this. The "-- ." part of "git checkout" asks Git to checkout the
> files, but the path limiter prevents it from updating HEAD, so the
> HEAD still points to the tip of the branch.
>
> --
> Matthieu Moy
> http://www-verimag.imag.fr/~moy/
>
Sorry but really answer given by Steven was better, because last one
omit the case when B had less files that D for example...
Thanks everyone
--
--
Open Kairos http://www.sergiobelkin.com
Watch More TV http://sebelk.blogspot.com
Sergio Belkin -
^ permalink raw reply
* Re: [PATCH] Smart-http documentation: add example of how to execute from userdir
From: Tarmigan @ 2009-12-28 4:18 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: Junio C Hamano, git, Shawn O. Pearce
In-Reply-To: <be6fef0d0912261919m7b175c4fh532ad05a713d86c7@mail.gmail.com>
On Sat, Dec 26, 2009 at 10:19 PM, Tay Ray Chuan <rctay89@gmail.com> wrote:
>> -All of the following examples map 'http://$hostname/git/foo/bar.git'
>> -to '/var/www/git/foo/bar.git'.
>> +Unless otherwise noted, the following examples map
>> +'http://$hostname/git/foo/bar.git' to '/var/www/git/foo/bar.git'.
>
> This rephrase seems to be unrelated (to providing an example of
> serving smart http).
I think this change is related because previously all the examples
provided the same mapping. With the new example with a different
mapping, the "_All_ of the following" is no longer true.
>> @@ -144,6 +144,42 @@ ScriptAliasMatch \
>> ScriptAlias /git/ /var/www/cgi-bin/gitweb.cgi/
>> ----------------------------------------------------------------
>>
>> +In the following example, a repository at
>> +'/home/$username/devel/foo/bar.git' will be accessible at
>> +'http://$hostname/\~$username/cgi-bin/git/foo/bar.git'
>> +
>> +From UserDir on Apache 2.x::
>> + One way to configure 'git-http-backend' to execute and serve
>> + from a user directory (for example, on a shared hosting
>> + provider), is to have a symbolic link that points from the cgi
>> + directory to the 'git-http-backend' executable in libexec. The
>> + advantage of the symblic link is that any updates to the
>
> s/symblic/symbolic
> s/update/updates/.
Thanks.
> At this point, the user dealing with the "easy" case (ie. the user
> just symlinks the shared git installation and doesn't have to create
> symlinks in his own home directory) should have enough configuration
> details without having to read any further. So, you could tell the
> user about the symlinks to create and the configuration lines in
> .htaccess.
>
> It might also be a good idea to start a new paragraph for the "hard"
> case, for better readability.
OK, these suggestions sound good to me. I'll send out an updated patch shortly.
Thanks,
Tarmigan
^ permalink raw reply
* Re: [PATCH 2/2] Smart-http: check if repository is OK to export before serving it
From: Tarmigan @ 2009-12-28 4:07 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git, rctay89, drizzd, warthog9
In-Reply-To: <20091227211033.GB609@spearce.org>
On Sun, Dec 27, 2009 at 4:10 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> Tarmigan Casebolt <tarmigan+git@gmail.com> wrote:
>> Similar to how git-daemon checks whether a repository is OK to be
>> exported, smart-http should also check. This check can be satisfied
>> in two different ways: the environmental variable GIT_HTTP_EXPORT_ALL
>> may be set to export all repositories, or the individual repository
>> may have the file git-daemon-export-ok.
>>
>> Signed-off-by: Tarmigan Casebolt <tarmigan+git@gmail.com>
>
> Acked-by: Shawn O. Pearce <spearce@spearce.org>
>
> I really think this and 1/2 should be squashed together, in which
> case you can apply my ACK to the entire thing.
Great, thanks for the ACK.
Squashing sounds good to me, I just split it so someone could verify
that the tests fail first if they want.
I've been thinking that the not_found() to a forbidden() instead.
Thoughts? I'll send out a unified patch with that change in a reply.
Thanks,
Tarmigan
^ permalink raw reply
* Re: [PATCH] Smart-http documentation: add example of how to execute from userdir
From: Tarmigan @ 2009-12-28 4:06 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20091227211557.GC609@spearce.org>
On Sun, Dec 27, 2009 at 4:15 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> Tarmigan Casebolt <tarmigan+git@gmail.com> wrote:
>> Smart-http may be an attactive and easy way for people to setup git
>> hosting on shared servers whose primary web server configuration they
>> do not control. To facilite this, provide an example of how it may be
>> done.
> ...
>> + \~/public_html/cgi-bin/.htaccess:
>> ++
>> +----------------------------------------------------------------
>> +SetHandler cgi-script
>> +Options +SymLinksIfOwnerMatch
>> +SetEnv GIT_PROJECT_ROOT /home/$username/devel
>> +----------------------------------------------------------------
>
> At this point, isn't this just easier?
>
> mkdir ~/public_html/git
> vi ~/public_html/git/.htaccess
>
> SetEnv GIT_PROJECT_ROOT /home/$username/devel
> ScriptAlias / /usr/libexec/git-core/git-http-backend/
Yes, that would be perfect. But ScriptAlias is only valid in the
"server config" or "virtual host" contexts which is why the
symlink/copy executable convolutions might be needed. Can you see a
simpler way around it?
Thanks,
Tarmigan
^ permalink raw reply
* Re: Newbie to git
From: Junio C Hamano @ 2009-12-28 2:18 UTC (permalink / raw)
To: mysql.jorge; +Cc: git
In-Reply-To: <ecddd9ed719d3d854b2248970cdb9cdf@192.168.1.222>
<mysql.jorge@decimal.pt> writes:
> Hi Andreas,
If you are addressing Andreas, why does your mail have:
To: <git@vger.kernel.org>
Cc: <git@vger.kernel.org>
and no other addressee???
> not i have:
> /home/apache/gitprojects/mydir.git
>
> created with: git init --base mydir.git
>
> Now, inside here, what should i do to create my projects:
>
> mkdir myproject1
> cd myproject1
> git init
> touch a.txt
> git add .
> git commit -m "1st commit"
>
> am i correct or not really?
You created "myproject1" somewhere you started "mkdir" in (perhaps in
$HOME?) [*1*] and that project tracks a single file "a.txt"; you are
correct if that was what you wanted to do.
The new repository "myproject1" doesn't have any relation to the bare
repository at /home/apache/gitprojects/mydir.git/ you created earlier.
The next steps I recommend new people are:
(1) push into the public repository, by doing:
cd myproject1
git push /home/apache/gitprojects/mydir.git/ master
(2) make sure push went correctly by trying to clone from there:
cd ..
mv myproject1 myproject1.old
git clone /home/apache/gitprojects/mydir.git/ myproject1
(3) check if the clone is what you expect
diff myproject1.old/a.txt myproject1/a.txt
(4) once satisfied, remove the old one
rm -fr myproject1.old
And keep working in the myproject1 repository from there on.
[Footnote]
*1* If you started that "mkdir" somewhere else you may want to remove it
and redo that step, especially if you did so inside that bare repository
you created earlier, i.e. /home/apache/gitprojects/mydir.git directory.
You don't want to have it there.
^ permalink raw reply
* Re: [PATCH] Fix core.worktree being used when GIT_DIR is not set
From: Robin Rosenberg @ 2009-12-28 0:08 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nguyễn Thái Ngọc Duy, git, Johannes Schindelin,
Robin Rosenberg
In-Reply-To: <7viqbsw2vn.fsf@alter.siamese.dyndns.org>
söndagen den 27 december 2009 21.58.20 skrev Junio C Hamano:
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> > According to config.txt:
> >> core.worktree::
> >> Set the path to the working tree. The value will not be
> >> used in combination with repositories found automatically in
> >> a .git directory (i.e. $GIT_DIR is not set).
> >
> > This behavior was changed after e90fdc3 (Clean up work-tree handling -
> > 2007-08-01) and 9459aa7 (Do check_repository_format() early (re-fix) -
> > 2007-12-05). If core.worktree is set, even if git_dir automatically
> > found (and git_work_tree_cfg set), git_work_tree_cfg will be reset to
> > core.worktree. This makes core.worktree effective even if GIT_DIR is
> > not set, in contrast to config.txt.
> >
> > This patch makes sure it only checks for core.worktree if GIT_DIR is set.
...
>
> Given these background, I am not sure the "fix" is addressing the right
> issue. What does it mean to have "core.worktree" in a configuration file,
> but that configuration file was found in a "git directory" that was found
> thorough the repository discovery process due to lack of $GIT_DIR? There
> are only two cases I can see:
I'm inclined towards fixing the docs. Overriding a config setting in non-
intuitive and nobody has complained.
-- robin
^ permalink raw reply
* Re: Newbie to git
From: mysql.jorge @ 2009-12-27 23:00 UTC (permalink / raw)
To: git; +Cc: git
In-Reply-To: <m27hs8t5b7.fsf@whitebox.home>
Hi Andreas,
> You probably want to create a bare repository in this directory:
>
> $ git init --bare foo.git
>
Ok one more point, seams to be that!
Forgive my really newbie question:
not i have:
/home/apache/gitprojects/mydir.git
created with: git init --base mydir.git
Now, inside here, what should i do to create my projects:
mkdir myproject1
cd myproject1
git init
touch a.txt
git add .
git commit -m "1st commit"
am i correct or not really?
^ permalink raw reply
* Re: Newbie to git
From: Andreas Schwab @ 2009-12-27 22:34 UTC (permalink / raw)
To: mysql.jorge; +Cc: git
In-Reply-To: <0a78ff1d3ae5d236fa45c31f7bb8bd54@192.168.1.222>
<mysql.jorge@decimal.pt> writes:
> then i went to /home/apache/gitprojects and runned:
>
> git init
You probably want to create a bare repository in this directory:
$ git init --bare foo.git
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Git reproducible corruption errors on merge/checkout not detected by git fsck --full --strict
From: Denis Rosset @ 2009-12-27 21:59 UTC (permalink / raw)
To: git
Hi all !
I use git regularly since twelve months; on one specific repository, I
had repetitive "inflate: data stream error (incorrect data check)"
errors. These errors appear when checking out from one branch to
another or when merging; however doing a "git fsck --full --strict" on
either the local repository or the remote repository before the
operation does not show anything wrong.
The bare repository is located on a Mac OS X 10.5 PPC server with Git
1.5.X.Y (X, Y not known), the local client is Git 1.6.6 installed
through MacPorts. I am stuck with Git 1.6.6 due to the MacPorts
architecture. Local zlib is 1.2.3_3.
I created a new local repository, reimported the files manually (only
the files, losing all the history in the process), and errors happen
again. The errors seems to appear when Git creates a local pack to
store the object files.
I am now installing Macports git 1.6.6 on the server to do further
testing.
My questions :
1) is "git fsck --full --strict" the most comprehensive check I can do
on a repository ?
2) are there known bugs leading to data corruption in the git 1.6.6
prerelease and/or zlib 1.2.3_3 ?
3) is there a verbose flag or a log I can consult (and eventually send
to this list) ?
Kind regards,
Denis Rosset
^ permalink raw reply
* Re: Newbie to git
From: mysql.jorge @ 2009-12-27 21:55 UTC (permalink / raw)
To: git
In-Reply-To: <26ae428a0912271212j70857e29m6248f6ec653f7551@mail.gmail.com>
Hi Howard,
> Firstly, I would have a serious look at 'gitosis' for the server end
> (there are other similar projects I believe).
>
> Secondly, the push command is wrong. You don't need to supply the
> remote URL again... that's what 'origin' is telling the push command,
> which remote to use. This would have been established by the original
> clone.
>
> Also, again, be careful with 'empty' repositories. (again AFAIK) an
> empty repository is just that, it doesn't even have a master branch so
> you really need to check out a branch and commit something before
> pushing makes much sense. I'm sure this is not 100% correct but you'll
> be safe that way!
Well, gitosis even made me more confused :P
Let me reask:
I'm running git deamon under supervisor with:
/usr/lib/git-core/git-daemon --syslog --export-all --enable=receive-pack
--verbose --base-path=/home/apache/gitprojects
then i went to /home/apache/gitprojects and runned:
git init
git add .
but for example, CGIT web interface says:
--
Not a git repository: '/home/apache/gitprojects'
generated by cgit at 2009-12-27 21:54:47 (GMT)
--
what could i be missing here?
I've been reading howto's i find on the web, but all lead me to the same
point, what i did and non work.. (with me).
Jorge,
^ permalink raw reply
* Re: [PATCH] Smart-http documentation: add example of how to execute from userdir
From: Shawn O. Pearce @ 2009-12-27 21:15 UTC (permalink / raw)
To: Tarmigan Casebolt; +Cc: Junio C Hamano, git
In-Reply-To: <1261847255-13970-1-git-send-email-tarmigan+git@gmail.com>
Tarmigan Casebolt <tarmigan+git@gmail.com> wrote:
> Smart-http may be an attactive and easy way for people to setup git
> hosting on shared servers whose primary web server configuration they
> do not control. To facilite this, provide an example of how it may be
> done.
...
> + \~/public_html/cgi-bin/.htaccess:
> ++
> +----------------------------------------------------------------
> +SetHandler cgi-script
> +Options +SymLinksIfOwnerMatch
> +SetEnv GIT_PROJECT_ROOT /home/$username/devel
> +----------------------------------------------------------------
At this point, isn't this just easier?
mkdir ~/public_html/git
vi ~/public_html/git/.htaccess
SetEnv GIT_PROJECT_ROOT /home/$username/devel
ScriptAlias / /usr/libexec/git-core/git-http-backend/
No need to mess around with SymlinksIfOwnerMatch and all of that fun.
If you have .htaccess override allows, you should be able to setup
a ScriptAlias without needing to use a cgi-bin directory.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 2/2] Smart-http: check if repository is OK to export before serving it
From: Shawn O. Pearce @ 2009-12-27 21:10 UTC (permalink / raw)
To: Tarmigan Casebolt; +Cc: Junio C Hamano, git, rctay89, drizzd, warthog9
In-Reply-To: <1261870153-57572-2-git-send-email-tarmigan+git@gmail.com>
Tarmigan Casebolt <tarmigan+git@gmail.com> wrote:
> Similar to how git-daemon checks whether a repository is OK to be
> exported, smart-http should also check. This check can be satisfied
> in two different ways: the environmental variable GIT_HTTP_EXPORT_ALL
> may be set to export all repositories, or the individual repository
> may have the file git-daemon-export-ok.
>
> Signed-off-by: Tarmigan Casebolt <tarmigan+git@gmail.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
I really think this and 1/2 should be squashed together, in which
case you can apply my ACK to the entire thing.
--
Shawn.
^ permalink raw reply
* Re: Does smart-http need git-daemon-export-ok?
From: Shawn O. Pearce @ 2009-12-27 21:06 UTC (permalink / raw)
To: Junio C Hamano
Cc: Tarmigan, Git Mailing List, Tay Ray Chuan, Clemens Buchacher,
J.H.
In-Reply-To: <7vk4w963np.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Tarmigan <tarmigan+git@gmail.com> writes:
> > Should the git-http-backend check something like git-daemon-export-ok
> > before serving a repository?
>
> I'd agree that it would make sense to have a way to mark individual
> repository for (or not for) export.
Just for some background... early drafts of git-http-backend actually
did check for, and require, this file before it exported a repository.
I took the check out because I was relying on the HTTP server's
document root translation to provide the mapping into the local
filesystem. That meant the HTTP repository was already exported via
dumb-http, and the git-daemon-export-ok flag wasn't being checked.
Later in the series development we got the patch to allow a
different filesystem root via an environment variable, which means
its possible to hide repositories and make them available only
through git-http-backend. In that configuration, checking the
git-daemon-export-ok flag makes sense again.
> In "native" case, the chain of events are: client talks to the daemon, the
> daemon checks and decides to (or not to) export, and it runs upload-pack.
>
> In "smart http" case, http-backend is one half of what corresponds to the
> daemon (the other half being your http server configuration), and it is
> more flexible and git specific half, so I'd say it would make sense to
> implement the check that honors the same git-daemon-export-ok flag file in
> it.
Yea, I'd agree.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Fix core.worktree being used when GIT_DIR is not set
From: Junio C Hamano @ 2009-12-27 20:58 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: git, Johannes Schindelin, Robin Rosenberg
In-Reply-To: <1261920513-25189-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> According to config.txt:
>> core.worktree::
>> Set the path to the working tree. The value will not be
>> used in combination with repositories found automatically in
>> a .git directory (i.e. $GIT_DIR is not set).
>
> This behavior was changed after e90fdc3 (Clean up work-tree handling -
> 2007-08-01) and 9459aa7 (Do check_repository_format() early (re-fix) -
> 2007-12-05). If core.worktree is set, even if git_dir automatically
> found (and git_work_tree_cfg set), git_work_tree_cfg will be reset to
> core.worktree. This makes core.worktree effective even if GIT_DIR is
> not set, in contrast to config.txt.
>
> This patch makes sure it only checks for core.worktree if GIT_DIR is set.
The work-tree area got too complicated over time for a small Panda brain
to grasp, so let me think aloud here.
The command line option --git-dir= has the same impact on the semantics as
the $GIT_DIR environment variable has. The only difference is that the
option has higher precedence over environment. Therefore, I won't talk
about the command line options in the following description.
In the beginning, there was GIT_DIR environment variable. We had a very
simple semantics:
- When there is no GIT_DIR environment variable:
- if "." is a "git directory", i.e. it has the set of git things like
refs/, objects/ and HEAD, then you are working in a bare repository.
- if ./.git exists and it is a "git directory", then "." is the top of
the work tree;
- otherwise, try the parent directory of "." for the second rule
repeatedly to find the git directory and the top of the work tree.
- When there is GIT_DIR environment variable:
- $GIT_DIR is (and must be) the "git directory" and "." is the top of
the work tree.
People wanted to have a work tree that is at a location totally unrelated
to where the "git directory" and setting $GIT_DIR at runtime was the only
way to do so, but that restricted them to work only at the top of the work
tree. $GIT_WORK_TREE was invented as a way to say "this is the top of the
work tree". So that people can do something like:
$ GIT_DIR=/srv/git/proj.git GIT_WORK_TREE=/scratch/proj
$ export GIT_DIR GIT_WORK_TREE
$ cd $GIT_WORK_TREE/Documentation
$ edit; git diff; git commit -a; ...
Because the facility was meant to allow separation of "git directory" and
its associated work tree, and not meant to allow more than one work trees
sharing the same "git directory" (which does not make any sense, as there
is only one index in "git directory" that describes the state of the work
tree), it was an unnecessary nuisanse that you had to set two environment
variables. core.worktree was invented---by recording the location of the
work tree in the config file in the "git directory", the above can be made
into this:
$ GIT_DIR=/srv/git/proj.git
$ cd /scratch/proj/Documentation
$ edit; git diff; git commit -a; ...
Given these background, I am not sure the "fix" is addressing the right
issue. What does it mean to have "core.worktree" in a configuration file,
but that configuration file was found in a "git directory" that was found
thorough the repository discovery process due to lack of $GIT_DIR? There
are only two cases I can see:
- The user is in the "git directory" itself, which is bare (iow,
/srv/git/proj.git in the above example). This is not the case the
documentation snippet you quoted is about, and I don't think your patch
changes (nor should change) the behaviour for;
- The "git directory" is a ".git/" subdirectory of some work tree, and
the value of core.worktree may or may not match that work tree. This
is the case the documentation talks about, and your patch addresses.
For the former case, while I don't see much point, we do seem to support
this use case (continuing the example scenario):
$ unset GIT_DIR GIT_WORK_TREE
$ cd /srv/git/proj.git
$ git checkout -b newbranch master
We find that "." is our "git directory", and through its config file, we
know core.worktree points at /scratch/proj/, and the checkout updates
files over there, not in /srv/git/proj.git/. While it is not obvious why
anybody finds this useful to me, I think the behaviour makes _some_ sense,
and I don't think your patch breaks it by changing the behaviour for this
case [*1*].
The latter, unless core.worktree matches the parent directory of the "git
directory" in question, seems to me a misconfiguration and nothing else.
Shouldn't it be diagnosed as an error, instead of matching the
documentation to the letter?
[Footnote]
*1* I said "makes _some_ sense" for a reason. While operations like
switching branches that is inherently whole-tree makes sense, it is
totally unclear what operations that work relative to the work tree,
i.e. "git add", in such a set-up.
^ permalink raw reply
* Re: Newbie to git
From: Howard Miller @ 2009-12-27 20:12 UTC (permalink / raw)
To: mysql.jorge; +Cc: git
In-Reply-To: <3a9710ae6b01fabf3b462da607af2534@192.168.1.222>
2009/12/27 <mysql.jorge@decimal.pt>:
>> I'm a using of git for several time, but now I have the need to a git
>> server.
>> My question, where can get a howto for reallyyyy newbies on git server?
>
> One question:
>
> I've created a project on the server with:
>
> mkdir project.git
> cd project.git
> git init
>
> -and now locally, created a directory, and cloned this, it said that i was
> cloning an empty repo, fine about that.
> -now i added something locally, i get: (locally this is on a windows
> machine with tortoiso git)
>
> --
> git.exe push --tags "origin" master:git://192.168.1.206/projects.git
>
> error: src refspec master:git does not match any.
> error: failed to push some refs to 'git://192.168.1.206/projects.git'
Firstly, I would have a serious look at 'gitosis' for the server end
(there are other similar projects I believe).
Secondly, the push command is wrong. You don't need to supply the
remote URL again... that's what 'origin' is telling the push command,
which remote to use. This would have been established by the original
clone.
Also, again, be careful with 'empty' repositories. (again AFAIK) an
empty repository is just that, it doesn't even have a master branch so
you really need to check out a branch and commit something before
pushing makes much sense. I'm sure this is not 100% correct but you'll
be safe that way!
Howard
^ permalink raw reply
* Re: [RESEND] [PATCH] Endianness bug in index cache logic
From: Tomas Carnecky @ 2009-12-27 19:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nathaniel W Filardo, git
In-Reply-To: <7veimgxolb.fsf@alter.siamese.dyndns.org>
On 12/27/09 7:24 PM, Junio C Hamano wrote:
> Nathaniel W Filardo<nwf@cs.jhu.edu> writes:
>
>> I got some free time and tracked it down. The following one-line delta
>> fixes this issue for me; AIUI on sparc64 "unsigned long" is 8 bits and in
>> the wrong endianness for the memcpy trick to work as written? I could be
>> sligntly off in my assessment of the problem, tho'.
>>
>> index 1bbaf1c..9033dd3 100644
>> --- a/read-cache.c
>> +++ b/read-cache.c
>> @@ -1322,7 +1322,7 @@ int read_index_from(struct index_state *istate, const char *path)
>> * extension name (4-byte) and section length
>> * in 4-byte network byte order.
>> */
>> - unsigned long extsize;
>> + uint32_t extsize;
>> memcpy(&extsize, (char *)mmap + src_offset + 4, 4);
>> extsize = ntohl(extsize);
>> if (read_index_extension(istate,
>
> Good catch.
>
> The original is broken on big endian 64-bit platforms, and your sparc64
> indeed is one. The code expects to see a signature (4-byte) at src_offset
> followed by length (4-byte int in network byte order) and it is trying to
> read read the latter in extsize.
>
> Thanks for the fix. The bug dates back to late April 2006, and I am kind
> of surprised that nobody reported this since then (perhaps nobody runs git
> on big endian 64-bit boxes?).
Both the native Sun compiler as well as GCC default to 32bit binaries,
even if the system is capable of running 64bit binaries (unlike for
example Linux where x86_64-pc-linux-gnu-gcc produces 64bit binaries by
default). And the git makefile doesn't use -m64, so my guess is that
nobody bothered changing CFLAGS on sparc64 systems (I have access to a
couple such systems and I never changed CFLAGS because git always worked
out of the box). Though I don't know what the default is on other big
endian systems.
tom
^ permalink raw reply
* Re: [RESEND] [PATCH] Endianness bug in index cache logic
From: Junio C Hamano @ 2009-12-27 18:24 UTC (permalink / raw)
To: Nathaniel W Filardo; +Cc: git
In-Reply-To: <20091227061121.GP14941@gradx.cs.jhu.edu>
Nathaniel W Filardo <nwf@cs.jhu.edu> writes:
> I got some free time and tracked it down. The following one-line delta
> fixes this issue for me; AIUI on sparc64 "unsigned long" is 8 bits and in
> the wrong endianness for the memcpy trick to work as written? I could be
> sligntly off in my assessment of the problem, tho'.
>
> index 1bbaf1c..9033dd3 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -1322,7 +1322,7 @@ int read_index_from(struct index_state *istate, const char *path)
> * extension name (4-byte) and section length
> * in 4-byte network byte order.
> */
> - unsigned long extsize;
> + uint32_t extsize;
> memcpy(&extsize, (char *)mmap + src_offset + 4, 4);
> extsize = ntohl(extsize);
> if (read_index_extension(istate,
Good catch.
The original is broken on big endian 64-bit platforms, and your sparc64
indeed is one. The code expects to see a signature (4-byte) at src_offset
followed by length (4-byte int in network byte order) and it is trying to
read read the latter in extsize.
Thanks for the fix. The bug dates back to late April 2006, and I am kind
of surprised that nobody reported this since then (perhaps nobody runs git
on big endian 64-bit boxes?).
^ 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