* Re: [PATCH 3/3] commit: show interesting ident information in summary
From: Junio C Hamano @ 2010-01-13 20:50 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Adam Megacz, git
In-Reply-To: <20100113201843.GB23018@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Wed, Jan 13, 2010 at 03:17:08PM -0500, Jeff King wrote:
>
>> Even outside of competent maintenance or individuals being served by
>> ISPs, I think it is really that it is no longer the case that the
>> machines we get our mail on and the machines we do our work on are less
>> and less the same. Even as an individual, I can afford a Linux
>
> Er, re-reading that I think I have too many negatives. But hopefully you
> get the point: "it is less and less the case that..." or "it is no
> longer the case that..."
Yes, I am in full agreement with everything you wrote in the message you
are responding to, including the comments after three-dash line about
showing the "Committer: " line even when the advice.implicitidentity is
declined.
Thanks.
^ permalink raw reply
* Re: [RFC 0/2] Git-over-TLS (gits://) client side support
From: Ilari Liusvaara @ 2010-01-13 21:04 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Andreas Krey, Nguyen Thai Ngoc Duy, git
In-Reply-To: <32541b131001131213m75b4baefsc70a4cbf3c8431c8@mail.gmail.com>
On Wed, Jan 13, 2010 at 03:13:40PM -0500, Avery Pennarun wrote:
> On Wed, Jan 13, 2010 at 3:06 PM, Ilari Liusvaara
>
> Lots of people use it. That was my point. If it weren't important,
> web browser makers wouldn't bother putting it in; God knows they leave
> out a lot of other stuff that I'd like.
There are two kinds of "important". Actually important for users and
important for managers.
The latter tends to be implemented with much less real world need. And
one can usually tell which of those it was from usability of feature.
> >> Furthermore, how many people who really want ssh-style keypairs (and
> >> thus refuse to use X.509 and PKI) can't just use ssh as their git
> >> transport? I don't actually understand what the goal is here.
> >
> > As said, I got fed up with failure modes of SSH.
>
> I think this is the answer that needs clarification. What failure
> modes are these? ssh doesn't seem to fail for me. And github.com
> seems to be working rather well with a huge number of users and ssh
> authentication.
Those failure modes tend to be show up at setup phase. But when they
show up, at worst I have seen ones that took hours to debug because
of multitude of possible causes and no good information on what's
wrong.
And don't get me started about multi-key setups.
SSH uses fixed sets of keys, which has inherent failure modes. And ssh
server tends to be worse than the client (Github can avoid the server
failure modes since they control the SSH server).
But not even github can avoid all the failure modes.
> If you're upset at the failure modes of ssh, is it possible to fix ssh
> instead of introducing Yet Another Tunneling Protocol?
No, those failure modes can't be solved in SSH.
-Ilari
^ permalink raw reply
* Problem: fatal oops during git fetch
From: Tilo Schwarz @ 2010-01-13 22:03 UTC (permalink / raw)
To: git
Dear List,
git really rocks!
Nevertheless, yesterday I stumbled into a problem, I don't understand. I
use git for a software projekt, where up to five different computers are
involved. On each computer the same git repository is used, main
development happens on one machine, but bug fixes happens also on the
other machines. Transfer medium is a USB stick, which I use with 'git
fetch', 'git merge' and 'git push'. More than one year nothing strange
happened.
Yesterday I tried to fetch bug fixes from one remote machine to the main
development machine being on branch 'test' using
git fetch remote/test
I got something like
fatal: oops 'SHA1'
Fetch failed
Any ideas what happened here?
I tried various things to fix this without success. I ended up doing 'git
cherry-pick' manually on the 5 commits I needed from remote/test, then
discarded remote/test and pushed my local 'test' to remote. I remember,
that maybe a branch was involved, which was already merged on a remote
machine, but not on the main machine. But up to now git always resolved
these things automagically.
As a side remark: I wished, the error message would have been a litte bit
more detailed. My attempts to make any google sense out of something like
'git fetch fatal oops' failed.
Regards,
Tilo
^ permalink raw reply
* Re: [RFC 0/2] Git-over-TLS (gits://) client side support
From: Avery Pennarun @ 2010-01-13 22:03 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: Andreas Krey, Nguyen Thai Ngoc Duy, git
In-Reply-To: <20100113210414.GA8535@Knoppix>
On Wed, Jan 13, 2010 at 4:04 PM, Ilari Liusvaara
<ilari.liusvaara@elisanet.fi> wrote:
> On Wed, Jan 13, 2010 at 03:13:40PM -0500, Avery Pennarun wrote:
>> On Wed, Jan 13, 2010 at 3:06 PM, Ilari Liusvaara
>> > As said, I got fed up with failure modes of SSH.
>>
>> I think this is the answer that needs clarification. What failure
>> modes are these? ssh doesn't seem to fail for me. And github.com
>> seems to be working rather well with a huge number of users and ssh
>> authentication.
>
> Those failure modes tend to be show up at setup phase. But when they
> show up, at worst I have seen ones that took hours to debug because
> of multitude of possible causes and no good information on what's
> wrong.
>
> And don't get me started about multi-key setups.
>
> SSH uses fixed sets of keys, which has inherent failure modes. And ssh
> server tends to be worse than the client (Github can avoid the server
> failure modes since they control the SSH server).
>
> But not even github can avoid all the failure modes.
>
>> If you're upset at the failure modes of ssh, is it possible to fix ssh
>> instead of introducing Yet Another Tunneling Protocol?
>
> No, those failure modes can't be solved in SSH.
This is still not very illuminating. How do you know your replacement
will not have these same failure modes? If you solve your main
annoyances with ssh, how do you know you won't introduce any new
annoying failure modes? *Why* can't ssh be fixed to solve the
problem? Will I have to generate and manage yet another new set of
keys to use the new system?
You seem to be positioning your implementation as a competitor to
*all* of ssh, https, and straight TLS (including stunnel), and
moreover, presenting it as superior to all three. This is surely
possible (they all suck differently), but it's going to be hard to
convince people. And if your new security protocol *only* works with
git, it loses points automatically against other solutions. (Even if
ssh is hard to set up, I've *already set it up*, so any new
alternative starts with an immediate negative score.)
Have fun,
Avery
^ permalink raw reply
* Re: [RFC 0/2] Git-over-TLS (gits://) client side support
From: Shawn O. Pearce @ 2010-01-13 22:06 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Ilari Liusvaara, Andreas Krey, Nguyen Thai Ngoc Duy, git
In-Reply-To: <32541b131001131403u162bc6ebpd551ed19aadde7fb@mail.gmail.com>
Avery Pennarun <apenwarr@gmail.com> wrote:
> possible (they all suck differently), but it's going to be hard to
> convince people. And if your new security protocol *only* works with
> git, it loses points automatically against other solutions. (Even if
> ssh is hard to set up, I've *already set it up*, so any new
> alternative starts with an immediate negative score.)
Yup.
This is where I have trouble with gits:// thus far.
I already have SSH setup everywhere. Even more so than I have
GnuPG configured, because I need SSH for just about everything,
and GnuPG for very little. So, I might as well just use SSH.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Show submodules as modified when they contain a dirty work tree
From: Junio C Hamano @ 2010-01-13 22:10 UTC (permalink / raw)
To: Jens Lehmann
Cc: Git Mailing List, Johannes Schindelin, Shawn O. Pearce,
Heiko Voigt, Lars Hjemli
In-Reply-To: <4B4E1817.1070202@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
> Thanks for your review, here is the updated patch. Changes to the RFC
> version are:
>
> - Removed check for a dangling HEAD (now the testsuite runs fine)
> - Reworded the commit message
> - Inlined is_submodule_working_directory_dirty() into
> is_submodule_modified()
> - The new code will only be called when refs did match (when they
> didn't the submodule will already show up as modified)
Looking good.
I had to squash in '#include "submodule.h"' in diff-lib.c just after it
includes "refs.h", though.
And a patch to add:
>> * It doesn't give detailed output when doing a "git diff* -p" with or
>> without the --submodule option. It should show something like
>>
>> diff --git a/sub b/sub
>> index 5431f52..3f35670 160000
>> --- a/sub
>> +++ b/sub
>> @@ -1 +1 @@
>> -Subproject commit 5431f529197f3831cdfbba1354a819a79f948f6f
>> +Subproject commit 3f356705649b5d566d97ff843cf193359229a453-dirty
>>
would look like the attached.
I think a reasonable next step would be
- Move the check for your condition (c) that we dropped from this round
to wt-status.c;
- Add wt_status_print_dangling_submodules() to wt-status.c, and use the
above logic to produce a section "Submodules with Dangling HEAD" or
something.
- Call it in wt_status_print(), immediately before we check s->verbose
and show the patch text under -v option. "git status" now will warn
about the condition (c).
- Add a similar wt_shortstatus_print_dangling_submodules() and call it at
the end of wt_shortstatus_print().
- Update is_submodule_modified() in your patch thats reads the output
from "status --porcelain", to *ignore* information about dangling
submodules. As we discussed, dangling submodules may be something the
user cares about, but that is not something "diff" should.
-- >8 --
Subject: Teach diff that modified submodule directory is dirty
A diff run in superproject only compares the name of the commit object
bound at the submodule paths. When we compare with a work tree and the
checked out submodule directory is dirty (e.g. has either staged or
unstaged changes, or has new files the user forgot to add to the index),
show the work tree side as "dirty".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
diff.c | 9 ++++++-
t/t4027-diff-submodule.sh | 49 ++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 55 insertions(+), 3 deletions(-)
diff --git a/diff.c b/diff.c
index 04beb26..750c066 100644
--- a/diff.c
+++ b/diff.c
@@ -2029,9 +2029,14 @@ static int populate_from_stdin(struct diff_filespec *s)
static int diff_populate_gitlink(struct diff_filespec *s, int size_only)
{
int len;
- char *data = xmalloc(100);
+ char *data = xmalloc(100), *dirty = "";
+
+ /* Are we looking at the work tree? */
+ if (!s->sha1_valid && is_submodule_modified(s->path))
+ dirty = "-dirty";
+
len = snprintf(data, 100,
- "Subproject commit %s\n", sha1_to_hex(s->sha1));
+ "Subproject commit %s%s\n", sha1_to_hex(s->sha1), dirty);
s->data = data;
s->size = len;
s->should_free = 1;
diff --git a/t/t4027-diff-submodule.sh b/t/t4027-diff-submodule.sh
index 5cf8924..bf8c980 100755
--- a/t/t4027-diff-submodule.sh
+++ b/t/t4027-diff-submodule.sh
@@ -32,7 +32,8 @@ test_expect_success setup '
cd sub &&
git rev-list HEAD
) &&
- echo ":160000 160000 $3 $_z40 M sub" >expect
+ echo ":160000 160000 $3 $_z40 M sub" >expect &&
+ subtip=$3 subprev=$2
'
test_expect_success 'git diff --raw HEAD' '
@@ -50,6 +51,52 @@ test_expect_success 'git diff-files --raw' '
test_cmp expect actual.files
'
+expect_from_to () {
+ printf "%sSubproject commit %s\n+Subproject commit %s\n" \
+ "-" "$1" "$2"
+}
+
+test_expect_success 'git diff HEAD' '
+ git diff HEAD >actual &&
+ sed -e "1,/^@@/d" actual >actual.body &&
+ expect_from_to >expect.body $subtip $subprev &&
+ test_cmp expect.body actual.body
+'
+
+test_expect_success 'git diff HEAD with dirty submodule (work tree)' '
+ echo >>sub/world &&
+ git diff HEAD >actual &&
+ sed -e "1,/^@@/d" actual >actual.body &&
+ expect_from_to >expect.body $subtip $subprev-dirty &&
+ test_cmp expect.body actual.body
+'
+
+test_expect_success 'git diff HEAD with dirty submodule (index)' '
+ (
+ cd sub &&
+ git reset --hard &&
+ echo >>world &&
+ git add world
+ ) &&
+ git diff HEAD >actual &&
+ sed -e "1,/^@@/d" actual >actual.body &&
+ expect_from_to >expect.body $subtip $subprev-dirty &&
+ test_cmp expect.body actual.body
+'
+
+test_expect_success 'git diff HEAD with dirty submodule (untracked)' '
+ (
+ cd sub &&
+ git reset --hard &&
+ git clean -qfdx &&
+ >cruft
+ ) &&
+ git diff HEAD >actual &&
+ sed -e "1,/^@@/d" actual >actual.body &&
+ expect_from_to >expect.body $subtip $subprev-dirty &&
+ test_cmp expect.body actual.body
+'
+
test_expect_success 'git diff (empty submodule dir)' '
: >empty &&
rm -rf sub/* sub/.git &&
^ permalink raw reply related
* Re: default behaviour for `gitmerge` (no arguments)
From: Johannes Schindelin @ 2010-01-13 22:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Gareth Adams, git
In-Reply-To: <7vpr5dn5vt.fsf@alter.siamese.dyndns.org>
Hi,
On Wed, 13 Jan 2010, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> What I was asking was:
>
> *PROVIDED* *IF* you wanted to keep the same semantics between
> them, then you would have patched i-b-n, but you didn't. Was there
> a reason callers of s-b-n should know about @{u} but callers of i-b-n
> shouldn't?
>
> Expected answer was either:
>
> (a) Codepath X that uses i-b-n shouldn't interpret @{upstream} as
> a symbolic name given by the user, but it should treat it as a
> mere SHA-1 expression instead for *this and that* reason.
> Otherwise we will see *this* breakage when the user does
> *that*. That is why i-b-n doesn't know about the new syntax;
> or
>
> (b) It was a thinko; all codepaths that use i-b-n should know the
> new syntax as they _are_ interested in learning the symbolic
> name when the user gives @{upstream}.
And I gave answer (c): I do not remember.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC 0/2] Git-over-TLS (gits://) client side support
From: Ilari Liusvaara @ 2010-01-13 23:00 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Andreas Krey, Nguyen Thai Ngoc Duy, git
In-Reply-To: <32541b131001131403u162bc6ebpd551ed19aadde7fb@mail.gmail.com>
On Wed, Jan 13, 2010 at 05:03:45PM -0500, Avery Pennarun wrote:
> On Wed, Jan 13, 2010 at 4:04 PM, Ilari Liusvaara
>
> This is still not very illuminating. How do you know your replacement
> will not have these same failure modes?
No client-side fallbacks, key auth works pseudonymously. That takes
care of them pretty well.
> If you solve your main
> annoyances with ssh, how do you know you won't introduce any new
> annoying failure modes?
Ensuring that at least some information make back to client (presuably
enough to figure out the problem).
And then there are few failure modes that can't be helped no matter what
I do (like mistaking protocol for P2P, git:// suffers from that as well).
> *Why* can't ssh be fixed to solve the problem?
Client side fallbacks (may be desired or not!), service not being
able to intervene on wheither to allow client or not in case of
keypair auth.
> Will I have to generate and manage yet another new set of
> keys to use the new system?
Yes.
> You seem to be positioning your implementation as a competitor to
> *all* of ssh, https, and straight TLS (including stunnel),
Only to smart http://, smart https:// and ssh://.
> and
> moreover, presenting it as superior to all three. This is surely
> possible (they all suck differently), but it's going to be hard to
> convince people. And if your new security protocol *only* works with
> git, it loses points automatically against other solutions.
The general design would be applicable to applications besides git, but
this implementation is git-specific.
And making it work like stunnel? On server-side that could work, but
not on client side (and it would take quite extensive changes to
git-daemon).
> (Even if
> ssh is hard to set up, I've *already set it up*, so any new
> alternative starts with an immediate negative score.)
Well, if you like SSH more, then use ssh://...
-Ilari
^ permalink raw reply
* tag namespace?
From: Leo Razoumov @ 2010-01-13 23:03 UTC (permalink / raw)
To: Git Mailing List
Hi List,
local and remote git branches live in different namespaces
refs/heads/* and refs/remotes/* respectively. thus, fetching from
remote repo never collides with local branches. Unfortunately, tags do
not enjoy such a separation. When I use
git read-tree -prefix=libfoo/ -u remotes/foo/master
remote tags suddenly populate my local tag space. v1.0 comes from my
project while v1.1 comes from foo.
When using subtree merges is it possible to create a "remotes"
namespace for tags?
Something like --tagprefix option for git-read-tree or any better solution?
--Leo--
^ permalink raw reply
* What's cooking in git.git (Jan 2010, #04; Wed, 13)
From: Junio C Hamano @ 2010-01-13 23:11 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"]
* nd/sparse (2010-01-04) 25 commits
(merged to 'next' on 2010-01-10 at fa73d6e)
+ t7002: test for not using external grep on skip-worktree paths
+ t7002: set test prerequisite "external-grep" if supported
(merged to 'next' on 2010-01-02 at 5499bbe)
+ grep: do not do external grep on skip-worktree entries
+ commit: correctly respect skip-worktree bit
+ ie_match_stat(): do not ignore skip-worktree bit with CE_MATCH_IGNORE_VALID
+ tests: rename duplicate t1009
+ 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
With the removal of external grep near future, some codepaths will be
slightly simplified.
* cc/reset-more (2010-01-08) 8 commits
(merged to 'next' on 2010-01-10 at 84730de)
+ t7111: check that reset options work as described in the tables
(merged to 'next' on 2010-01-06 at 96639cb)
+ Documentation: reset: add some missing tables
(merged to 'next' on 2010-01-04 at 8802c2c)
+ Fix bit assignment for CE_CONFLICTED
(merged to 'next' on 2010-01-03 at f83d4c6)
+ "reset --merge": fix unmerged case
+ reset: use "unpack_trees()" directly instead of "git read-tree"
+ reset: add a few tests for "git reset --merge"
+ Documentation: reset: add some tables to describe the different options
+ reset: improve mixed reset error message when in a bare repo
* rs/maint-archive-match-pathspec (2009-12-12) 1 commit
(merged to 'next' on 2010-01-03 at 92d7d15)
+ archive: complain about path specs that don't match anything
* il/vcs-helper (2010-01-09) 9 commits
(merged to 'next' on 2010-01-10 at 11e448e)
+ Reset possible helper before reusing remote structure
(merged to 'next' on 2010-01-06 at 7c79f42)
+ 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
* jc/checkout-merge-base (2010-01-07) 4 commits
(merged to 'next' on 2010-01-07 at 5229608)
+ rebase -i: teach --onto A...B syntax
+ rebase: fix --onto A...B parsing and add tests
(merged to 'next' on 2010-01-02 at 6a8f6fc)
+ "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
--------------------------------------------------
[New Topics]
* jc/maint-1.6.4-grep-lookahead (2010-01-10) 1 commit
(merged to 'next' on 2010-01-13 at 20f8f4b)
+ grep: optimize built-in grep by skipping lines that do not hit
(this branch is used by jc/grep-lookahead and jc/maint-grep-lookahead.)
Optimize the "line-by-line" internal grep by skiping en masse over lines
that cannot possibly match.
* jc/maint-grep-lookahead (2010-01-12) 0 commits
(this branch uses jc/maint-1.6.4-grep-lookahead; is used by jc/grep-lookahead.)
Early conflict resolution for the above for recent git.
* jc/grep-lookahead (2010-01-12) 2 commits
(merged to 'next' on 2010-01-13 at 20f8f4b)
+ grep: rip out pessimization to use fixmatch()
+ grep: rip out support for external grep
(this branch uses jc/maint-1.6.4-grep-lookahead and jc/maint-grep-lookahead.)
This is for eventual inclusion for the next release.
* jc/symbol-static (2010-01-11) 17 commits
- symlinks.c: remove unused functions
- object.c: remove unused functions
- blob.c: remove unused function
- strbuf.c: remove unused function
- sha1_file.c: remove unused function
- mailmap.c: remove unused function
- utf8.c: mark file-local function static
- submodule.c: mark file-local function static
- quote.c: mark file-local function static
- remote-curl.c: mark file-local function static
- read-cache.c: mark file-local functions static
- parse-options.c: mark file-local function static
- entry.c: mark file-local function static
- http.c: mark file-local functions static
- pretty.c: mark file-local function static
- builtin-rev-list.c: mark file-local function static
- bisect.c: mark file-local function static
Mark file-local symbols "static", and remove unused functions. Daniel
suggests to leave some comment for blob.c and I agree in principle, but
I don't think of a good description myself.
* nd/include-termios-for-osol (2010-01-11) 1 commit
- Add missing #include to support TIOCGWINSZ on Solaris
* pc/uninteresting-submodule-disappear-upon-switch-branches (2010-01-11) 1 commit
- Remove empty directories when checking out a commit with fewer submodules
Instead of using unlink(2) that will never succeed, use rmdir(2) to remove
an empty directory, knowing that this won't harm a populated directory.
* sd/cd-p-show-toplevel (2010-01-12) 2 commits
- Use $(git rev-parse --show-toplevel) in cd_to_toplevel().
- Add 'git rev-parse --show-toplevel' option.
Avoid having to use "cd -P" that may not be available on some platforms'
shells.
* jk/warn-author-committer-after-commit (2010-01-13) 4 commits
- commit: allow suppression of implicit identity advice
- commit: show interesting ident information in summary
- strbuf: add strbuf_addbuf_percentquote
- strbuf_expand: convert "%%" to "%"
* js/refer-upstream (2009-09-10) 1 commit
- Introduce <branch>@{upstream} notation
This does not teach the public interface about the new syntax; callers
that care about distinction between name vs SHA-1 might not work as well
as they should.
* mm/conflict-advice (2010-01-12) 1 commit
- Be more user-friendly when refusing to do something because of conflict.
* jc/maint-strbuf-add-fix-doubling (2010-01-12) 1 commit
- strbuf_addbuf(): allow passing the same buf to dst and src
* jl/submodule-diff (2010-01-13) 2 commits
- Teach diff that modified submodule directory is dirty
- Show submodules as modified when they contain a dirty work tree
--------------------------------------------------
[Stalled]
* 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.
* mh/rebase-fixup (2010-01-12) 5 commits
(merged to 'next' on 2010-01-12 at e84eab0)
+ rebase-i: Ignore comments and blank lines in peek_next_command
+ lib-rebase: Allow comments and blank lines to be added to the rebase script
+ lib-rebase: Provide clearer debugging info about what the editor did
(merged to 'next' on 2010-01-06 at c4779a7)
+ 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.)
Expecting further improvements to skip opening the editor if a pick is
followed only by "fixup" and no "squash".
* ns/rebase-auto-squash (2009-12-08) 1 commit
(merged to 'next' on 2010-01-06 at da4e2f5)
+ rebase -i --autosquash: auto-squash commits
(this branch uses mh/rebase-fixup.)
Blocked by the above.
* 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
(merged to 'next' on 2010-01-02 at ae42130)
+ 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
http://thread.gmane.org/gmane.comp.version-control.git/134738
What's the status of the fourth and later patches on this topic? Overall
it looked reasonable, if I recall correctly what I thought when I reviewed
it last time, and I am tempted to merge it to 'next' soonish. Please
file complaints before I do so if people have objections.
Hold: JH on 2010-01-05, http://article.gmane.org/gmane.comp.version-control.git/136183
* jh/gitweb-cached (2010-01-13) 7 commits
- (sign-off?) gitweb: File based caching layer (from git.kernel.org)
- (sign-off?) gitweb: add a get function to compliment print_local_time
- (sign-off?) gitweb: Convert output to using indirect file handle
- gitweb: Optionally add "git" links in project list page
- gitweb: Makefile improvements
- gitweb: Add option to force version match
- gitweb: Load checking
Replaced with a re-roll. Update to t9500 is probably needed.
--------------------------------------------------
[Cooking]
* jh/commit-status (2010-01-13) 2 commits
(merged to 'next' on 2010-01-13 at 0905d59)
+ t7502: test commit.status, --status and --no-status
+ commit: support commit.status, --status, and --no-status
I have already given ample time for people to react, but ended up getting
tired of waiting for tests to materialize and doing it myself, as I want
to close merge window for 1.7.0-rc0 by the end of next week to have the
final release early next month.
* bk/fix-relative-gitdir-file (2010-01-08) 2 commits
- Handle relative paths in submodule .git files
- Test update-index for a gitlink to a .git file
* jc/ident (2010-01-08) 3 commits
- ident.c: treat $EMAIL as giving user.email identity explicitly
(merged to 'next' on 2010-01-10 at f1f9ded)
+ ident.c: check explicit identity for name and email separately
+ ident.c: remove unused variables
Opinions on the topmost one?
* jc/ls-files-ignored-pathspec (2010-01-08) 4 commits
- ls-files: fix overeager pathspec optimization
- read_directory(): further split treat_path()
- read_directory_recursive(): refactor handling of a single path into a separate function
- t3001: test ls-files -o ignored/dir
* js/exec-error-report (2010-01-12) 4 commits
- Improve error message when a transport helper was not found
- start_command: detect execvp failures early
- run-command: move wait_or_whine earlier
- start_command: report child process setup errors to the parent's stderr
* jc/maint-1.6.1-checkout-m-custom-merge (2010-01-06) 1 commit
(merged to 'next' on 2010-01-10 at df14116)
+ checkout -m path: fix recreating conflicts
* jn/makefile (2010-01-06) 4 commits
(merged to 'next' on 2010-01-10 at f5a5d42)
+ Makefile: consolidate .FORCE-* targets
+ Makefile: learn to generate listings for targets requiring special flags
+ Makefile: use target-specific variable to pass flags to cc
+ Makefile: regenerate assembler listings when asked
* da/difftool (2010-01-09) 6 commits
(merged to 'next' on 2010-01-10 at 749c870)
+ git-diff.txt: Link to git-difftool
+ difftool: Allow specifying unconfigured commands with --extcmd
+ difftool--helper: Remove use of the GIT_MERGE_TOOL variable
+ difftool--helper: Update copyright and remove distracting comments
(merged to 'next' on 2010-01-06 at e957395)
+ git-difftool: Add '--gui' for selecting a GUI tool
+ t7800-difftool: Set a bogus tool for use by tests
* tc/test-locate-httpd (2010-01-02) 1 commit
(merged to 'next' on 2010-01-06 at 9d913e5)
+ t/lib-http.sh: Restructure finding of default httpd location
* jc/fix-tree-walk (2009-09-14) 7 commits
(merged to 'next' on 2010-01-13 at 1c01b87)
+ read-tree --debug-unpack
+ 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
Resurrected from "Ejected" category. This is fix for a tricky codepath
and testing and improving before it hits 'master' is greatly appreciated.
(I have been using this in my private build for some time).
* jc/branch-d (2009-12-29) 1 commit
(merged to 'next' on 2010-01-10 at 61a14b7)
+ branch -d: base the "already-merged" safety on the branch it merges with
* jc/rerere (2009-12-04) 1 commit
(merged to 'next' on 2010-01-10 at e295b7f)
+ Teach --[no-]rerere-autoupdate option to merge, revert and friends
* jk/run-command-use-shell (2010-01-01) 8 commits
(merged to 'next' on 2010-01-10 at 7479e2a)
+ t4030, t4031: work around bogus MSYS bash path conversion
+ diff: run external diff helper with shell
+ textconv: use shell to run helper
+ editor: use run_command's shell feature
+ run-command: optimize out useless shell calls
+ run-command: convert simple callsites to use_shell
+ t0021: use $SHELL_PATH for the filter script
+ run-command: add "use shell" option
Shuffled the commits in the topic, following J6t's suggestion in
http://thread.gmane.org/gmane.comp.version-control.git/136128
* tc/clone-v-progress (2009-12-26) 4 commits
(merged to 'next' on 2010-01-10 at ec2bfd7)
+ clone: use --progress to force progress reporting
+ clone: set transport->verbose when -v/--verbose is used
+ git-clone.txt: reword description of progress behaviour
+ check stderr with isatty() instead of stdout when deciding to show progress
Perhaps needs an entry in the Release Notes, but otherwise looked Ok.
* tc/smart-http-restrict (2010-01-02) 4 commits
(merged to 'next' on 2010-01-06 at 82736cb)
+ Smart-http tests: Test http-backend without curl or a webserver
+ Smart-http tests: Break test t5560-http-backend into pieces
+ Smart-http tests: Improve coverage in test t5560
+ Smart-http: check if repository is OK to export before serving it
* jc/cache-unmerge (2009-12-25) 9 commits
(merged to 'next' on 2010-01-13 at 2290c44)
+ 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
* tr/http-push-ref-status (2010-01-08) 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
Rerolled.
* sr/gfi-options (2009-12-04) 7 commits
(merged to 'next' on 2010-01-10 at 8b305fb)
+ 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
^ permalink raw reply
* Re: default behaviour for `gitmerge` (no arguments)
From: Junio C Hamano @ 2010-01-13 23:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, Gareth Adams, git
In-Reply-To: <alpine.DEB.1.00.1001132348570.4985@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> What I was asking was:
>>
>> *PROVIDED* *IF* you wanted to keep the same semantics between
>> them, then you would have patched i-b-n, but you didn't. Was there
>> a reason callers of s-b-n should know about @{u} but callers of i-b-n
>> shouldn't?
>>
>> Expected answer was either:
>>
>> (a) Codepath X that uses i-b-n shouldn't interpret @{upstream} as
>> a symbolic name given by the user, but it should treat it as a
>> mere SHA-1 expression instead for *this and that* reason.
>> Otherwise we will see *this* breakage when the user does
>> *that*. That is why i-b-n doesn't know about the new syntax;
>> or
>>
>> (b) It was a thinko; all codepaths that use i-b-n should know the
>> new syntax as they _are_ interested in learning the symbolic
>> name when the user gives @{upstream}.
>
> And I gave answer (c): I do not remember.
That's fine. As long as we know it is (c) (your earlier response sounded
as if you were saying (b)), we know that there might be issues we need to
find and carefully look at before using this topic.
^ permalink raw reply
* [ANNOUNCE] Git wiki & repo.or.cz migration, donations and volunteers pledge
From: Petr Baudis @ 2010-01-13 23:29 UTC (permalink / raw)
To: git
Hello!
I would like to notify you that unfortunately, Czech UPC terminated the
sponsorship of the hardware and connectivity hosting the Git Wiki and
repo.or.cz (after generously donating it for several years).
We have just secured at least provisional hosting at the Charles University,
Prague and CESNET - the connectivity should be equally good as at UPC,
even better on university backbones over the world. However, I will have
to buy new rack server for the hosting service from my own pocket and this is
where I have to ask for your help - I can't afford to sponsor the full price
of the server, and reasonably powerful rack hardware ain't cheap (repo.or.cz
_is_ quite a workload!).
Thus, I would like to ask you for donations for the new hardware - the full
cost is $1400 (CZK 24000); we would like to gather more in order to be able to
buy a RAID0 pair disk and more RAM. Any extra money would all go to
the server-related costs, most likely hardware upgrades in the future.
I apologize for abusing the vger public forum for this, I hope the readers
not using repo.or.cz and the wiki will not mind.
On a related note, unfortunately I can't spend nearly as much time on
the wiki and repo.or.cz maintenance and enhancements as it would deserve.
Thus, I'm seeking for volunteers to help with both day-to-day maintenance
and development. You will be richly credited and ethernal glory in the Git
community awaits you, plus it will surely make a great CV bullet-point! :)
I'm sure really cool things could be done by developers with fresh ideas,
especially after the hardware upgrade.
*** You can donate and view the current pledge status at: ***
http://repo.or.cz/h/pledge.html
Thanks,
Petr "Pasky" Baudis
^ permalink raw reply
* git top links: 2010-1
From: Felipe Contreras @ 2010-01-13 23:47 UTC (permalink / raw)
To: git
Hi,
git top links is my attempt to gather all the links people have been
tagging as "git" in delicious.com[1] (these are not chosen by me).
The fancier blog version is here:
http://gitlog.wordpress.com/2010/01/13/git-top-links-2010-1/
I've revamped my scripts so now all the previous items are automatically
tracked and it's much easier to generate a list of completely new links. Here
are the latest ones:
1. 25 Tips for Intermediate Git Users (230)
Comprehensive git tips
http://andyjeffries.co.uk/articles/25-tips-for-intermediate-git-users
2. Using Git to Maintain Your Website (42)
http://danielmiessler.com/blog/using-git-to-maintain-your-website
3. Setting up your Git repositories for open source projects at GitHub (41)
Mostly so pulling and pushing works correctly; and pull requests are ok
http://blog.mhartl.com/2008/10/14/setting-up-your-git-repositories-for-open-source-projects-at-github/
4. SmartGit — The Easy-to-Use Git-Client (39)
http://www.syntevo.com/smartgit/index.html
5. Persistent Trees in git, Clojure and CouchDB (36)
http://eclipsesource.com/blogs/2009/12/13/persistent-trees-in-git-clojure-and-couchdb-data-structure-convergence/
6. Amp — Version Control Revolution (24)
Meta SCM; aims to support git, bzr, hg, etc. through the same ui
http://amp.carboni.ca/
7. Gerrit — Gerrit Code Review (24)
Code review and project management for git based projects
http://code.google.com/p/gerrit/
8. how's my code (20)
Agile review tool for git based projects
http://howsmycode.com/
9. Why Git is so fast (20)
Interesting thread in git mailing list about why git is so fast: C
http://marc.info/?l=git&m=124111702609723&w=2
10. On commit messages (16)
Peter Hutterer reminds us what are good commit messages
http://who-t.blogspot.com/2009/12/on-commit-messages.html
Happy New Year!
[1] http://delicious.com/tag/git
--
Felipe Contreras
^ permalink raw reply
* Re: [RFC 0/2] Git-over-TLS (gits://) client side support
From: Avery Pennarun @ 2010-01-13 23:51 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: Andreas Krey, Nguyen Thai Ngoc Duy, git
In-Reply-To: <20100113230023.GA9171@Knoppix>
On Wed, Jan 13, 2010 at 6:00 PM, Ilari Liusvaara
<ilari.liusvaara@elisanet.fi> wrote:
> On Wed, Jan 13, 2010 at 05:03:45PM -0500, Avery Pennarun wrote:
>> This is still not very illuminating. How do you know your replacement
>> will not have these same failure modes?
>
> No client-side fallbacks, key auth works pseudonymously. That takes
> care of them pretty well.
Perhaps I'm being dense, but I don't understand what you mean by
either of those.
>> If you solve your main
>> annoyances with ssh, how do you know you won't introduce any new
>> annoying failure modes?
>
> Ensuring that at least some information make back to client (presuably
> enough to figure out the problem).
Unfortunately revealing information like that is a compromise; it
helps attackers as well as legitimate users. It's the same reason
login prints "invalid username or password" instead of choosing
between "invalid username" and "invalid password."
If you reveal more information than ssh, you'll be accused of being
less secure. And since the purpose of your protocol is security, this
is a problem.
>> *Why* can't ssh be fixed to solve the problem?
>
> Client side fallbacks (may be desired or not!), service not being
> able to intervene on wheither to allow client or not in case of
> keypair auth.
I don't understand that answer. Couldn't ssh be patched to do
whatever you want? Particularly if it's just better (optional)
diagnostics, you'd think someone would accept the patch for that.
>> Will I have to generate and manage yet another new set of
>> keys to use the new system?
>
> Yes.
Ouch.
>> (Even if
>> ssh is hard to set up, I've *already set it up*, so any new
>> alternative starts with an immediate negative score.)
>
> Well, if you like SSH more, then use ssh://...
I'm just looking for a justification for why I *shouldn't* like ssh
more. Is the only reason the fact that it might be easier to
initially configure the key exchange?
Avery
^ permalink raw reply
* Syncing a git working tree with Dropbox?
From: chombee @ 2010-01-13 23:57 UTC (permalink / raw)
To: git
I've heard of people keeping a bare repo in their Dropbox folder
(https://www.dropbox.com/) and pushing to and pulling from it, letting
Dropbox sync the bare repo between their machines. In other words using
Dropbox as a form of hosting for a private git repo. What I want to do
is sort of the other way around.
I keep on getting into the following mess: I have some changes in my
working tree on machine A, I stop working on machine A and don't commit
and push the changes (to my remote, 'central' bare repo) either because
they're not ready yet, or I forget to commit or push. Later on I arrive
at machine B which has its own clone of the same repo, but because I
didn't commit and push the changes on machine A I don't have access to
them on machine B and I can't continue working on them. The two machines
are physically located far away from each other and they're not
accessible over the internet. Argh!
Dropbox is a proprietary sync service that gets around this problem
because it automatically syncs your files whenever you save them. But I
still want to keep my project in a git repo. I'm assuming that keeping
the actual .git folder in a Dropbox folder, so that when git makes
changes inside the .git folder Drobox syncs them, would be a bad idea.
It seems like taking two different synchronisation systems and mashing
them into each other. But what about just the working tree?
My idea is that I keep my .git folder safely outside of my Dropbox
folder, but my git repository has a detached working tree that is
located in the Dropbox folder. On machine B it would be the same setup.
So the two machines each have their own clone of the git repo and these
are synchronised by git push and git pull with a 'central' remote repo.
But the two clones share the same working tree, or more accurately their
working trees are synced by Dropbox.
The working tree is just files, I don't see how it's different from
Dropbox syncing any other files. Dropbox and git ought not to collide in
any way. So this should work fine shouldn't it?
This way I don't need to commit and push my changes until they're
ready/I remember to, but whenever I move from machine A to machine B my
uncommitted changes will still be available to me because Dropbox has
synced my working tree automatically.
^ permalink raw reply
* touching a file causes it to be listed using git diff-files
From: Stephen Bannasch @ 2010-01-13 23:57 UTC (permalink / raw)
To: git
If I touch a file in the working directory (only changing it's last-modified) attribute it shows up when running git diff-files.
If I then run git status followed by git diff-files again it doesn't show up either time.
Is this an error?
Simple example:
[dev]$ git --version
git version 1.6.5.3
[dev]$ git init t
Initialized empty shared Git repository in /Users/stephen/dev/t/.git/
[dev]$ cd t
[t (master)]$ echo 'hi' > hello; git add hello; git commit -am 'initial commit'
[master (root-commit) f39d21a] initial commit
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 hello
[t (master)]$ git diff-files
[t (master)]$ git status
# On branch master
nothing to commit (working directory clean)
[t (master)]$ touch hello
[t (master)]$ git diff-files
:100644 100644 45b983be36b73c0788dc9cbcb76cbb80fc7bb057 0000000000000000000000000000000000000000 M hello
[t (master)]$ git status
# On branch master
nothing to commit (working directory clean)
[t (master)]$ git diff-files
^ permalink raw reply
* Re: Filenames and prefixes in extended diffs
From: Junio C Hamano @ 2010-01-14 0:16 UTC (permalink / raw)
To: Andreas Gruenbacher; +Cc: git
In-Reply-To: <201001131713.05505.agruen@suse.de>
Andreas Gruenbacher <agruen@suse.de> writes:
> Can git be changed to ...
Just to save your time coming up with more ways to *change* git diff...
Even though I wouldn't say _any_ change is too late to bring in, change in
the output format from "git diff" family _must_ be usable by "git apply"
people have been using for the last 4 years or so.
Suppose your updated version of "git diff" with a certain set of options
produces output A, which is different from the output B you would get out
of today's "git diff" that is run with the same set of options.
If "git apply" people have been using understands B (i.e. current output)
and does something, the format change between A and B must be designed in
such a way that the same "git apply" accepts A (i.e. your output) and do
the same thing.
Two examples:
- "git diff -M" (or "git show -M") is _defined_ to show the filenames
without prefix on "rename from" line, and deployed "git apply" relies
on this definition to apply the patch to the file the patch was meant
to apply. If your modified "git diff -M" changes it to add the prefix,
and existing "git apply" changes behaviour (either by rejecting your
output, or applying the patch to a wrong file), then such a change has
*no chance* of getting in. It is merely a breakage.
- If you say "git diff --src-prefix=a/b/c --dst-prefix=x/y", it _might_
produce something "git apply" won't grok (I haven't checked this,
though). You can suggest to change the output from such a case to work
better. We didn't work as expected so a change _could_ be a fix.
The output from "git diff --no-index" is an exception to the above rule.
It is primarily for people who have unmanaged contents and want to use
features of the git diff engine that are not found in other people's diff
implementations (e.g. wordwise colored diff), and the header part of its
output does not currently follow "git diff" convention to be grokkable by
"git apply".
Fixing _that_ is a welcome change, but I suspect that there are corner
cases, e.g. "git diff --no-index frotz-1.2.36/ /tmp/frotz/" (i.e. you have
a pristine version in frotz-1.2.36 directory, but your modified version is
in /tmp/frtoz/) that might make fixing it fundamentally impossible (I
haven't looked into it for a long time, so it could be easy, but my gut
feeling is it isn't).
^ permalink raw reply
* Re: [PATCH] git push --track
From: Miles Bader @ 2010-01-14 0:25 UTC (permalink / raw)
To: Rudolf Polzer; +Cc: git
In-Reply-To: <op.u6g8jnixg402ra@nb-04>
"Rudolf Polzer" <divVerent@alientrap.org> writes:
> I'd like a feature to automatically "transform" a non-tracking local
> branch into a tracking branch on push. A patch to do that is attached.
Yay!!
I've wanted this for a long time, but discussions about it always seem
to end up petering out...
> git branch mybranch
> git checkout mybranch
> ...
> git push --track origin mybranch:mybranch
Does it default to the current branch so you can just say "git push --track origin"?
I hope this can be added to the distro...
Thanks,
-Miles
--
Opposition, n. In politics the party that prevents the Goverment from running
amok by hamstringing it.
^ permalink raw reply
* Re: [PATCH] git push --track
From: Johannes Schindelin @ 2010-01-14 0:33 UTC (permalink / raw)
To: Miles Bader; +Cc: Rudolf Polzer, git
In-Reply-To: <871vht7cs2.fsf@catnip.gol.com>
Hi,
On Thu, 14 Jan 2010, Miles Bader wrote:
> "Rudolf Polzer" <divVerent@alientrap.org> writes:
> > I'd like a feature to automatically "transform" a non-tracking local
> > branch into a tracking branch on push. A patch to do that is attached.
>
> Yay!!
>
> I've wanted this for a long time, but discussions about it always seem
> to end up petering out...
That is not fair. I came up with a patch already years ago. You could
always have applied it to your own source, maybe after tweaking. And then
maybe lobbying for it.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git push --track
From: Miles Bader @ 2010-01-14 0:28 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: Rudolf Polzer, git
In-Reply-To: <20100113154310.GA7348@Knoppix>
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> writes:
> - Is --track the best name for this?
I think "--track" is absolutely the right name for this option -- it's
the option name used for "set up tracking" option in other commands, and
it's just very natural (when I've thought about implementing a similar
functionality myself, I also chose the name "--track").
-Miles
--
Youth, n. The Period of Possibility, when Archimedes finds a fulcrum,
Cassandra has a following and seven cities compete for the honor of endowing a
living Homer.
^ permalink raw reply
* Re: [PATCH] git push --track
From: Miles Bader @ 2010-01-14 0:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Rudolf Polzer, git
In-Reply-To: <alpine.DEB.1.00.1001140132110.4985@pacific.mpi-cbg.de>
On Thu, Jan 14, 2010 at 9:33 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>> I've wanted this for a long time, but discussions about it always seem
>> to end up petering out...
>
> That is not fair. I came up with a patch already years ago. You could
> always have applied it to your own source, maybe after tweaking. And then
> maybe lobbying for it.
Ah, sorry, I didn't mean anything against your patch, I just didn't
know about it.
I don't track this list as well as I could....
[Do you have a pointer to your patch?]
Thanks,
-Miles
--
Do not taunt Happy Fun Ball.
^ permalink raw reply
* Re: [PATCH] git push --track
From: Miles Bader @ 2010-01-14 0:46 UTC (permalink / raw)
To: Rudolf Polzer; +Cc: git
In-Reply-To: <871vht7cs2.fsf@catnip.gol.com>
BTW, I was _just_ going to post a message saying "whatever happened to
push --track", but then decided to check the list once more, and saw
your message...!
-Miles
--
Dawn, n. When men of reason go to bed.
^ permalink raw reply
* Re: Unable to get "pretty" URL aliases working
From: Adam Nielsen @ 2010-01-14 0:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vockytrwy.fsf@alter.siamese.dyndns.org>
>> What actually happens when you use the ssh:// style connection?
>
> Be it ssh://host/full/path or host:/full/path or host:path/in/home, you
> log in as whatver ssh identifies you as to the server, and start a
> server-side git process over there.
Ah ok, that makes more sense. Strange then if it's a server-side git
process that it ignores the server's /etc/gitconfig where aliases can be
set up.
> With ssh://host/path notation, there is no way to specify any relative
> path (i.e. "/path" part begins at root) so it will mean the same thing for
> everybody (unless you are getting chrooted or something), while host:path
> notation allows relative path which will be taken relative as where you
> are, i.e. home directory of the user on the server.
In that case I symlinked my repository folder to /git so that SSH users
can "cd /git/project.git" and this seems to work well. I can now use
git URLs like ssh://server/git/project.git even though the repos are
buried much deeper down in the tree.
Thanks for the explanations!
Cheers,
Adam.
^ permalink raw reply
* [PATCH 1/9] gitweb: Load checking
From: John 'Warthog9' Hawley @ 2010-01-14 1:22 UTC (permalink / raw)
To: git
In-Reply-To: <1263432185-21334-1-git-send-email-warthog9@eaglescrag.net>
From: John 'Warthog9' Hawley <warthog9@kernel.org>
This changes slightly the behavior of gitweb, so that it verifies
that the box isn't inundated with before attempting to serve gitweb.
If the box is overloaded, it basically returns a 503 Server Unavailable
until the load falls below the defined threshold. This helps dramatically
if you have a box that's I/O bound, reaches a certain load and you
don't want gitweb, the I/O hog that it is, increasing the pain the
server is already undergoing.
This behavior is controlled by $maxload configuration variable.
Default is a load of 300, which for most cases should never be hit.
Unset it (set it to undefined value, i.e. undef) to turn off checking.
Currently it requires that '/proc/loadavg' file exists, otherwise the
load check is bypassed (load is taken to be 0). So platforms that do
not implement '/proc/loadavg' currently cannot use this feature.
(provisions are included for additional checks to be added by others)
Signed-off-by: John 'Warthog9' Hawley <warthog9@kernel.org>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/README | 7 ++++++-
gitweb/gitweb.perl | 45 +++++++++++++++++++++++++++++++++++++++++----
2 files changed, 47 insertions(+), 5 deletions(-)
diff --git a/gitweb/README b/gitweb/README
index e34ee79..6c2c8e1 100644
--- a/gitweb/README
+++ b/gitweb/README
@@ -174,7 +174,7 @@ not include variables usually directly set during build):
Base URL for relative URLs in pages generated by gitweb,
(e.g. $logo, $favicon, @stylesheets if they are relative URLs),
needed and used only for URLs with nonempty PATH_INFO via
- <base href="$base_url>. Usually gitweb sets its value correctly,
+ <base href="$base_url">. Usually gitweb sets its value correctly,
and there is no need to set this variable, e.g. to $my_uri or "/".
* $home_link
Target of the home link on top of all pages (the first part of view
@@ -228,6 +228,11 @@ not include variables usually directly set during build):
repositories from launching cross-site scripting (XSS) attacks. Set this
to true if you don't trust the content of your repositories. The default
is false.
+ * $maxload
+ Used to set the maximum load that we will still respond to gitweb queries.
+ If server load exceed this value then return "503 Service Unavaliable" error.
+ Server load is taken to be 0 if gitweb cannot determine its value. Set it to
+ undefined value to turn it off. The default is 300.
Projects list file format
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 7e477af..0a07d3a 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -221,6 +221,12 @@ our %avatar_size = (
'double' => 32
);
+# Used to set the maximum load that we will still respond to gitweb queries.
+# If server load exceed this value then return "503 server busy" error.
+# If gitweb cannot determined server load, it is taken to be 0.
+# Leave it undefined (or set to 'undef') to turn off load checking.
+our $maxload = 300;
+
# You define site-wide feature defaults here; override them with
# $GITWEB_CONFIG as necessary.
our %feature = (
@@ -551,6 +557,32 @@ if (-e $GITWEB_CONFIG) {
do $GITWEB_CONFIG_SYSTEM if -e $GITWEB_CONFIG_SYSTEM;
}
+# Get loadavg of system, to compare against $maxload.
+# Currently it requires '/proc/loadavg' present to get loadavg;
+# if it is not present it returns 0, which means no load checking.
+sub get_loadavg {
+ if( -e '/proc/loadavg' ){
+ open my $fd, '<', '/proc/loadavg'
+ or return 0;
+ my @load = split(/\s+/, scalar <$fd>);
+ close $fd;
+
+ # The first three columns measure CPU and IO utilization of the last one,
+ # five, and 10 minute periods. The fourth column shows the number of
+ # currently running processes and the total number of processes in the m/n
+ # format. The last column displays the last process ID used.
+ return $load[0] || 0;
+ }
+ # additional checks for load average should go here for things that don't export
+ # /proc/loadavg
+
+ return 0;
+}
+
+if (defined $maxload && get_loadavg() > $maxload) {
+ die_error(503, "The load average on the server is too high");
+}
+
# version of the core git binary
our $git_version = qx("$GIT" --version) =~ m/git version (.*)$/ ? $1 : "unknown";
$number_of_git_cmds++;
@@ -3354,14 +3386,19 @@ sub git_footer_html {
# 500: The server isn't configured properly, or
# an internal error occurred (e.g. failed assertions caused by bugs), or
# an unknown error occurred (e.g. the git binary died unexpectedly).
+# 503: The server is currently unavailable (because it is overloaded,
+# or down for maintenance). Generally, this is a temporary state.
sub die_error {
my $status = shift || 500;
my $error = shift || "Internal server error";
- my %http_responses = (400 => '400 Bad Request',
- 403 => '403 Forbidden',
- 404 => '404 Not Found',
- 500 => '500 Internal Server Error');
+ my %http_responses = (
+ 400 => '400 Bad Request',
+ 403 => '403 Forbidden',
+ 404 => '404 Not Found',
+ 500 => '500 Internal Server Error',
+ 503 => '503 Service Unavailable',
+ );
git_header_html($http_responses{$status});
print <<EOF;
<div class="page_body">
--
1.6.5.2
^ permalink raw reply related
* [PATCH 6/9] gitweb: add a get function to compliment print_sort_th
From: John 'Warthog9' Hawley @ 2010-01-14 1:23 UTC (permalink / raw)
To: git
In-Reply-To: <1263432185-21334-6-git-send-email-warthog9@eaglescrag.net>
This adds a get function for print_sort_th so that the basic
function can be used outside of their straight printing operation.
---
gitweb/gitweb.perl | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index d38aad6..07fdeb5 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -4375,17 +4375,24 @@ sub fill_project_list_info {
# print 'sort by' <th> element, generating 'sort by $name' replay link
# if that order is not selected
sub print_sort_th {
+ print get_sort_th(@_);
+}
+
+sub get_sort_th {
my ($name, $order, $header) = @_;
+ my $sortth = "";
$header ||= ucfirst($name);
if ($order eq $name) {
- print "<th>$header</th>\n";
+ $sortth .= "<th>$header</th>\n";
} else {
- print "<th>" .
+ $sortth .= "<th>" .
$cgi->a({-href => href(-replay=>1, order=>$name),
-class => "header"}, $header) .
"</th>\n";
}
+
+ return $sortth;
}
sub git_project_list_body {
--
1.6.5.2
^ 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