* 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: Newbie to git
From: mysql.jorge @ 2009-12-28 10:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8wcnx2lq.fsf@alter.siamese.dyndns.org>
> If you are addressing Andreas, why does your mail have:
>
> To: <git@vger.kernel.org>
> Cc: <git@vger.kernel.org>
>
> and no other addressee???
My error, sorry :)
> 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.
Thank you, i understood, i believe i really did. did that test and it's
OK.
But let me reask in another way:
I want to setup the git server, to accept new branch's created in a remote
place that will be push'ed to it, please correct me, 'cause i'm doing
something wrong and i don't know what yet.
- setup git server to run with:
/usr/lib/git-core/git-daemon --reuseaddr --syslog --export-all
--enable=receive-pack --verbose --base-path=/home/apache/gitprojects
- created directory /home/apache/gitprojects
- git init --bare /home/apache/gitprojects
- what will be my link on the remote? "git://192.168.1.206" just?
- From now on, how can I have access to push projects that exist on other
machine?
Sorry for the questions... they are newbie!
Jorge,
^ permalink raw reply
* [PATCH] Allow git to use any HTTP authentication method.
From: Lénaïc Huard @ 2009-12-28 10:54 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: Text/Plain, Size: 1113 bytes --]
Hello,
As I need to access some of my git repositories behind a corporate company
firewall, I use the http access method. And, as I don't want my passwords to be
sent in clear text over the network, I have configured my web server to use «
Digest » authentication instead of the old « Basic » authentication.
This authentication method is now well handled by modern software.
Unfortunately, current git version only handles « Basic » authentication.
When attempting to access my repository, I get the following error message:
error: The requested URL returned error: 401 while accessing
http://XXX@YYY.ZZ/test.git/info/refs
The web server, on its side, has refused the transaction because of the wrong
authentication method used:
Digest: client used wrong authentication scheme `Basic': /test.git/info/refs
The attached patch makes git configure libcurl to negotiate the most suitable
HTTP authentication method.
Thanks to that patch, I manage to clone and fetch my git repository hosted on
my web server requesting an authentication through the « Digest » method.
Lénaïc.
[-- Attachment #2: 0001-Allow-git-to-use-any-HTTP-authentication-method.patch --]
[-- Type: text/x-patch, Size: 966 bytes --]
From 2acab3ae894c3ea835279a864e654e1c5e956e80 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?L=C3=A9na=C3=AFc=20Huard?= <lenaic@lhuard.fr.eu.org>
Date: Mon, 28 Dec 2009 10:52:35 +0100
Subject: [PATCH] Allow git to use any HTTP authentication method.
By default, libcurl performs "Basic" HTTP authentication.
This method transmits passwords in clear text.
libcurl needs some settings in order to use a safest HTTP authentication
method like "Digest" for example.
---
http.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/http.c b/http.c
index ed6414a..2d9df76 100644
--- a/http.c
+++ b/http.c
@@ -233,6 +233,10 @@ static CURL *get_curl_handle(void)
init_curl_http_auth(result);
+#if LIBCURL_VERSION_NUM >= 0x070a06
+ curl_easy_setopt(result, CURLOPT_HTTPAUTH, CURLAUTH_ANY);
+#endif
+
if (ssl_cert != NULL)
curl_easy_setopt(result, CURLOPT_SSLCERT, ssl_cert);
if (has_cert_password())
--
1.6.5.7
^ permalink raw reply related
* Re: [PATCH] Allow git to use any HTTP authentication method.
From: Martin Storsjö @ 2009-12-28 12:09 UTC (permalink / raw)
To: Lénaïc Huard; +Cc: git
In-Reply-To: <200912281154.09442.lenaic@lhuard.fr.eu.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 582 bytes --]
Hi Lénaïc,
On Mon, 28 Dec 2009, Lénaïc Huard wrote:
> The attached patch makes git configure libcurl to negotiate the most suitable
> HTTP authentication method.
> Thanks to that patch, I manage to clone and fetch my git repository hosted on
> my web server requesting an authentication through the « Digest » method.
Something similar has already been queued for inclusion, and is available
in the branch 'next', in commit b8ac923010484908d8426cb8ded5ad7e8c21a7f6.
The patch available there requires you to set http.authAny for the libcurl
option to be enabled.
// Martin
^ permalink raw reply
* Re: [PATCH] Allow git to use any HTTP authentication method.
From: Tay Ray Chuan @ 2009-12-28 12:12 UTC (permalink / raw)
To: Martin Storsjö; +Cc: Lénaïc Huard, git
In-Reply-To: <alpine.DEB.2.00.0912281406210.5582@cone.home.martin.st>
Hi,
On Mon, Dec 28, 2009 at 8:09 PM, Martin Storsjö <martin@martin.st> wrote:
> Hi Lénaďc,
>
> On Mon, 28 Dec 2009, Lénaďc Huard wrote:
>
>> The attached patch makes git configure libcurl to negotiate the most suitable
>> HTTP authentication method.
>> Thanks to that patch, I manage to clone and fetch my git repository hosted on
>> my web server requesting an authentication through the « Digest » method.
>
> Something similar has already been queued for inclusion, and is available
> in the branch 'next', in commit b8ac923010484908d8426cb8ded5ad7e8c21a7f6.
> The patch available there requires you to set http.authAny for the libcurl
> option to be enabled.
...or setting the environment variable GIT_HTTP_AUTH_ANY.
(by the way, Martin was referring to setting http.authAny in your git
configuration.)
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [PATCH] Allow git to use any HTTP authentication method.
From: Matthieu Moy @ 2009-12-28 12:37 UTC (permalink / raw)
To: Lénaïc Huard; +Cc: git
In-Reply-To: <200912281154.09442.lenaic@lhuard.fr.eu.org>
Lénaïc Huard <lenaic@lhuard.fr.eu.org> writes:
> The attached patch makes git configure libcurl to negotiate the most suitable
> HTTP authentication method.
Thanks for your contribution.
Read other people's reply about the need for this patch.
Other than that, please read git/Documentation/SubmittingPatches in
Git's source code. In short: inline patches, don't attach them, and
use Signed-Off-By to acknowledge that your patch can be legally
included in Git's official version.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Need some help with git rebase
From: Sylvain RABOT @ 2009-12-28 13:33 UTC (permalink / raw)
To: git
Hello everybody,
I'm trying to backport a feature branch which is based on the master
branch into another branch also based on master but older :
a--a--a--a--a--a--a--a--a feature
/
--x--x--x--x--x--x--x--x--x--x--x--x master
\
o--o--o--o--o--o--o 12.72.1
This is what I would like :
a--a--a--a--a--a--a--a--a feature
/
--x--x--x--x--x--x--x--x--x--x--x--x master
\
o--o--o--o--o--o--o--a--a--a--a--a--a--a--a--a 12.72.1
And this is what I get with git rebase --onto 12.72.1 master feature
o--o--o--o--o--o--o--a--a--a--a--a--a--a--a--a feature
/
--x--x--x--x--x--x--x--x--x--x--x--x master
\
o--o--o--o--o--o--o--a--a--a--a--a--a--a--a--a 12.72.1
Can you exlain to me what I need to do to get what I expect.
Best regards.
--
Sylvain
^ permalink raw reply
* Re: [PATCH] Allow git to use any HTTP authentication method.
From: Shawn O. Pearce @ 2009-12-28 15:37 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: Martin Storsj?, L?na?c Huard, git
In-Reply-To: <be6fef0d0912280412w58401f10n972f9198144cd580@mail.gmail.com>
Tay Ray Chuan <rctay89@gmail.com> wrote:
> On Mon, Dec 28, 2009 at 8:09 PM, Martin Storsj?? <martin@martin.st> wrote:
> > On Mon, 28 Dec 2009, L??na??c Huard wrote:
> >
> >> The attached patch makes git configure libcurl to negotiate the most suitable
> >> HTTP authentication method.
...
> > Something similar has already been queued for inclusion, and is available
> > in the branch 'next', in commit b8ac923010484908d8426cb8ded5ad7e8c21a7f6.
> > The patch available there requires you to set http.authAny for the libcurl
> > option to be enabled.
Uh, stupid question, but why must we enable this option? I don't
have to enable something in my browser before I use digest auth to
visit a website, why do I need to enable it in git?
How does one use git clone with an http:// URL with digest
authentication? Its not obvious to the user that you would need
to first export an obtuse environment variable to get something
that should Just Work(tm).
Yes, I realize you may need to perform an extra HTTP request to
start the transaction, but why aren't we doing that? Isn't it only
1 additional request to discover the desired authentication method?
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Allow git to use any HTTP authentication method.
From: Martin Storsjö @ 2009-12-28 15:50 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Tay Ray Chuan, L?na?c Huard, git
In-Reply-To: <20091228153701.GA2252@spearce.org>
On Mon, 28 Dec 2009, Shawn O. Pearce wrote:
> Uh, stupid question, but why must we enable this option? I don't
> have to enable something in my browser before I use digest auth to
> visit a website, why do I need to enable it in git?
>
> How does one use git clone with an http:// URL with digest
> authentication? Its not obvious to the user that you would need
> to first export an obtuse environment variable to get something
> that should Just Work(tm).
>
> Yes, I realize you may need to perform an extra HTTP request to
> start the transaction, but why aren't we doing that? Isn't it only
> 1 additional request to discover the desired authentication method?
Initially when I added support for this, curl sessions weren't reused, so
every single request had to be duplicated if authentication was used,
adding quite a bit of overhead.
Now that sessions are reused properly, I tend to agree that this should be
enabled automatically.
Any other opinions on this, Tay or Junio?
Should I send in a new patch that removes the http.authAny option and
always enables this, or send a rewritten version of the patch that already
is in 'next'?
// Martin
^ permalink raw reply
* Re: [PATCH] Allow git to use any HTTP authentication method.
From: Shawn O. Pearce @ 2009-12-28 15:53 UTC (permalink / raw)
To: Martin Storsj?; +Cc: Tay Ray Chuan, L?na?c Huard, git
In-Reply-To: <alpine.DEB.2.00.0912281745540.5582@cone.home.martin.st>
Martin Storsj? <martin@martin.st> wrote:
> Initially when I added support for this, curl sessions weren't reused, so
> every single request had to be duplicated if authentication was used,
> adding quite a bit of overhead.
>
> Now that sessions are reused properly, I tend to agree that this should be
> enabled automatically.
Oh, that makes sense, thanks for the explanation.
> Should I send in a new patch that removes the http.authAny option and
> always enables this, or send a rewritten version of the patch that already
> is in 'next'?
I'm not Junio, but I would suggest sending in a new patch series,
and asking Junio politely to revert the one that is currently in
next before merging in the new series.
If we really are killing http.authAny before it hits master, there
is no reason for it to appear in the final project history.
--
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-28 15:59 UTC (permalink / raw)
To: Tarmigan; +Cc: Junio C Hamano, git, rctay89, drizzd, warthog9
In-Reply-To: <905315640912272007i8b4904dv2b93879789b453fb@mail.gmail.com>
Tarmigan <tarmigan+git@gmail.com> wrote:
> 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.
...
> I've been thinking that the not_found() to a forbidden() instead.
Oh. Interesting question.
Because you can't resolve the access error by authenticating to
the server, we may actually want to just return not_found() here
with a message in the log of "Repository not exported: '%s'".
That would mirror the behavior of git-daemon.
--
Shawn.
^ permalink raw reply
* [PATCH RESEND] git gui: Use git diff --submodule when available
From: Jens Lehmann @ 2009-12-28 16:22 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Git Mailing List, Junio C Hamano
Changed the use of submodule summary to diff --submodule because the
implementation in C is much faster than the submodule script. Also a test
has been added to make sure that the underlying git supports the diff
option --submodule (which was introduced in 1.6.6).
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
git-gui/lib/diff.tcl | 21 +++++++++------------
1 files changed, 9 insertions(+), 12 deletions(-)
diff --git a/git-gui/lib/diff.tcl b/git-gui/lib/diff.tcl
index bd5d189..0623e3e 100644
--- a/git-gui/lib/diff.tcl
+++ b/git-gui/lib/diff.tcl
@@ -281,6 +281,14 @@ proc start_show_diff {cont_info {add_opts {}}} {
}
}
+ if {[git-version >= "1.6.6"]} {
+ if {[string match {160000 *} [lindex $s 2]]
+ || [string match {160000 *} [lindex $s 3]]} {
+ set is_submodule_diff 1
+ lappend cmd --submodule
+ }
+ }
+
lappend cmd -p
lappend cmd --no-color
if {$repo_config(gui.diffcontext) >= 1} {
@@ -296,16 +304,6 @@ proc start_show_diff {cont_info {add_opts {}}} {
lappend cmd $path
}
- if {[string match {160000 *} [lindex $s 2]]
- || [string match {160000 *} [lindex $s 3]]} {
- set is_submodule_diff 1
- if {$w eq $ui_index} {
- set cmd [list submodule summary --cached -- $path]
- } else {
- set cmd [list submodule summary --files -- $path]
- }
- }
-
if {[catch {set fd [eval git_read --nice $cmd]} err]} {
set diff_active 0
unlock_index
@@ -387,8 +385,7 @@ proc read_diff {fd cont_info} {
}
} elseif {$is_submodule_diff} {
if {$line == ""} continue
- if {[regexp {^\* } $line]} {
- set line [string replace $line 0 1 {Submodule }]
+ if {[regexp {^Submodule } $line]} {
set tags d_@
} else {
set op [string range $line 0 2]
--
1.6.6.rc2.274.g2cee7
^ permalink raw reply related
* Re: Newbie to git
From: Eugene Sajine @ 2009-12-28 16:51 UTC (permalink / raw)
To: mysql.jorge; +Cc: Junio C Hamano, git
In-Reply-To: <7a0ae9cb57a1bc55653872ab254ea922@192.168.1.222>
On Mon, Dec 28, 2009 at 5:34 AM, <mysql.jorge@decimal.pt> wrote:
>> If you are addressing Andreas, why does your mail have:
>>
>> To: <git@vger.kernel.org>
>> Cc: <git@vger.kernel.org>
>>
>> and no other addressee???
>
> My error, sorry :)
>
>> 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.
>
> Thank you, i understood, i believe i really did. did that test and it's
> OK.
> But let me reask in another way:
>
> I want to setup the git server, to accept new branch's created in a remote
> place that will be push'ed to it, please correct me, 'cause i'm doing
> something wrong and i don't know what yet.
>
> - setup git server to run with:
> /usr/lib/git-core/git-daemon --reuseaddr --syslog --export-all
> --enable=receive-pack --verbose --base-path=/home/apache/gitprojects
>
> - created directory /home/apache/gitprojects
> - git init --bare /home/apache/gitprojects
>
> - what will be my link on the remote? "git://192.168.1.206" just?
> - From now on, how can I have access to push projects that exist on other
> machine?
>
> Sorry for the questions... they are newbie!
> Jorge,
Your /home/apache/gitprojects is a folder where your git repositories
are supposed to be placed.
Your Git repository = your project.
By running a git daemon the way you do - you say that you are going to
serve all repositories from /home/apache/gitprojects.
Bare repo = repo without working copy - the one which contains only
history and git objects (imagine it to be only .git folder from normal
repo) Therefore for bare repos there is a naming convention so they
have .git extension, while normal repo doesn't. So, myProject.git is
server based bare repo, while myProject is a local repo.
Finally you have /home/apache/gitprojects/myProject.git
The URL to clone from there will be - should be shown to you by CGIT
if you have everything correctly set up
git://192.168.1.206/myProject.git
Hope that helps,
Eugene
^ permalink raw reply
* Re: [PATCH 2/2] Smart-http: check if repository is OK to export before serving it
From: Tarmigan @ 2009-12-28 16:57 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git, rctay89, drizzd, warthog9
In-Reply-To: <20091228155931.GC2252@spearce.org>
On Mon, Dec 28, 2009 at 10:59 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
> Tarmigan <tarmigan+git@gmail.com> wrote:
>> I've been thinking that the not_found() to a forbidden() instead.
>
> Oh. Interesting question.
>
> Because you can't resolve the access error by authenticating to
> the server, we may actually want to just return not_found() here
> with a message in the log of "Repository not exported: '%s'".
I'm no http expert, but isn't that what 401 would be? From
http://tools.ietf.org/html/rfc2616#section-10.4.4
403 Forbidden
The server understood the request, but is refusing to fulfill it.
Authorization will not help and the request SHOULD NOT be repeated.
If the request method was not HEAD and the server wishes to make
public why the request has not been fulfilled, it SHOULD describe the
reason for the refusal in the entity. If the server does not wish to
make this information available to the client, the status code 404
(Not Found) can be used instead.
which to me points to 403 instead of 404.
I don't have a strong preference, and will resend with those changes
if you'd prefer 404.
Thanks,
Tarmigan
^ 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-28 17:08 UTC (permalink / raw)
To: Tarmigan; +Cc: Junio C Hamano, git, rctay89, drizzd, warthog9
In-Reply-To: <905315640912280857g710b45fcne21a21d53ff0fedf@mail.gmail.com>
Tarmigan <tarmigan+git@gmail.com> wrote:
> On Mon, Dec 28, 2009 at 10:59 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
> > Tarmigan <tarmigan+git@gmail.com> wrote:
> >> I've been thinking that the not_found() to a forbidden() instead.
> >
> > Because you can't resolve the access error by authenticating to
> > the server, we may actually want to just return not_found() here
> > with a message in the log of "Repository not exported: '%s'".
>
> I'm no http expert, but isn't that what 401 would be? From
> http://tools.ietf.org/html/rfc2616#section-10.4.4
> 403 Forbidden
> The server understood the request, but is refusing to fulfill it.
> Authorization will not help and the request SHOULD NOT be repeated.
> If the request method was not HEAD and the server wishes to make
> public why the request has not been fulfilled, it SHOULD describe the
> reason for the refusal in the entity. If the server does not wish to
> make this information available to the client, the status code 404
> (Not Found) can be used instead.
> which to me points to 403 instead of 404.
Good point, that is 403. But the last sentance leads me to believe
404 might be a better use here. Under git-daemon we don't tell
the client the difference between "Not Found" and "Not Exported",
so I think we should be doing the same thing here under HTTP.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Allow git to use any HTTP authentication method.
From: Tay Ray Chuan @ 2009-12-28 17:15 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Junio C Hamano, Martin Storsj?, Lénaïc Huard, git
In-Reply-To: <20091228155346.GB2252@spearce.org>
Hi,
On Mon, Dec 28, 2009 at 11:53 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> Martin Storsj? <martin@martin.st> wrote:
>> Should I send in a new patch that removes the http.authAny option and
>> always enables this, or send a rewritten version of the patch that already
>> is in 'next'?
>
> I'm not Junio, but I would suggest sending in a new patch series,
> and asking Junio politely to revert the one that is currently in
> next before merging in the new series.
>
> If we really are killing http.authAny before it hits master, there
> is no reason for it to appear in the final project history.
hmm, a few days back Junio (added to Cc list) sent out an email
regarding branch shuffling and dropping topics from 'next'. Junio,
could we piggyback on this?
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [PATCH] Allow git to use any HTTP authentication method.
From: Junio C Hamano @ 2009-12-28 18:04 UTC (permalink / raw)
To: Tay Ray Chuan
Cc: Shawn O. Pearce, Junio C Hamano, Martin Storsj?,
Lénaïc Huard, git
In-Reply-To: <be6fef0d0912280915k1320110o6a361a0950aa60f6@mail.gmail.com>
Tay Ray Chuan <rctay89@gmail.com> writes:
> On Mon, Dec 28, 2009 at 11:53 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
>> Martin Storsj? <martin@martin.st> wrote:
>>> Should I send in a new patch that removes the http.authAny option and
>>> always enables this, or send a rewritten version of the patch that already
>>> is in 'next'?
>>
>> I'm not Junio, but I would suggest sending in a new patch series,
>> and asking Junio politely to revert the one that is currently in
>> next before merging in the new series.
>>
>> If we really are killing http.authAny before it hits master, there
>> is no reason for it to appear in the final project history.
>
> hmm, a few days back Junio (added to Cc list) sent out an email
> regarding branch shuffling and dropping topics from 'next'. Junio,
> could we piggyback on this?
If people want to go that way that is fine by me, but unlike the ones that
are _ejected_ from next without trace, if we are going to have the primary
feature the patch introduces and changing only a minor detail of external
interface, I don't think we gain much by hinding that story from the
history, especially for something that has been cooking in 'next'.
A separate follow-up commit would be more honest about the feature's
history. Also a follow-up patch to remove conditionals is much easier to
review than a resend of a rewritten patch, especially when the original
was reviewed adequately for its primary codepath to implement the feature.
Would it be just a matter of queueing something like this on top of
b8ac923 (Add an option for using any HTTP authentication scheme, not only
basic, 2009-11-27)?
-- >8 --
From: "Shawn O. Pearce" <spearce@spearce.org>,
Subject: Remove http.authAny
Back when the feature to use different HTTP authentication methods was
originally written, it needed an extra HTTP request for everything when
the feature was in effect, because we didn't reuse curl sessions.
However, b8ac923 (Add an option for using any HTTP authentication scheme,
not only basic, 2009-11-27) builds on top of an updated codebase that does
reuse curl sessions; there is no need to manually avoid the extra overhead
by making this configurable anymore.
---
Documentation/config.txt | 7 -------
http.c | 17 +----------------
2 files changed, 1 insertions(+), 23 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index a54ede3..b77d66d 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1158,13 +1158,6 @@ http.noEPSV::
support EPSV mode. Can be overridden by the 'GIT_CURL_FTP_NO_EPSV'
environment variable. Default is false (curl will use EPSV).
-http.authAny::
- Allow any HTTP authentication method, not only basic. Enabling
- this lowers the performance slightly, by having to do requests
- without any authentication to discover the authentication method
- to use. Can be overridden by the 'GIT_HTTP_AUTH_ANY'
- environment variable. Default is false.
-
i18n.commitEncoding::
Character encoding the commit messages are stored in; git itself
does not care per se, but this information is necessary e.g. when
diff --git a/http.c b/http.c
index aeb69b3..01e0fdc 100644
--- a/http.c
+++ b/http.c
@@ -40,9 +40,6 @@ static long curl_low_speed_time = -1;
static int curl_ftp_no_epsv;
static const char *curl_http_proxy;
static char *user_name, *user_pass;
-#ifdef LIBCURL_CAN_HANDLE_AUTH_ANY
-static int curl_http_auth_any = 0;
-#endif
#if LIBCURL_VERSION_NUM >= 0x071700
/* Use CURLOPT_KEYPASSWD as is */
@@ -197,12 +194,6 @@ static int http_options(const char *var, const char *value, void *cb)
http_post_buffer = LARGE_PACKET_MAX;
return 0;
}
-#ifdef LIBCURL_CAN_HANDLE_AUTH_ANY
- if (!strcmp("http.authany", var)) {
- curl_http_auth_any = git_config_bool(var, value);
- return 0;
- }
-#endif
/* Fall back on the default ones */
return git_default_config(var, value, cb);
@@ -254,8 +245,7 @@ static CURL *get_curl_handle(void)
curl_easy_setopt(result, CURLOPT_NETRC, CURL_NETRC_OPTIONAL);
#endif
#ifdef LIBCURL_CAN_HANDLE_AUTH_ANY
- if (curl_http_auth_any)
- curl_easy_setopt(result, CURLOPT_HTTPAUTH, CURLAUTH_ANY);
+ curl_easy_setopt(result, CURLOPT_HTTPAUTH, CURLAUTH_ANY);
#endif
init_curl_http_auth(result);
@@ -408,11 +398,6 @@ void http_init(struct remote *remote)
if (getenv("GIT_CURL_FTP_NO_EPSV"))
curl_ftp_no_epsv = 1;
-#ifdef LIBCURL_CAN_HANDLE_AUTH_ANY
- if (getenv("GIT_HTTP_AUTH_ANY"))
- curl_http_auth_any = 1;
-#endif
-
if (remote && remote->url && remote->url[0]) {
http_auth_init(remote->url[0]);
if (!ssl_cert_password_required &&
^ permalink raw reply related
* Re: [PATCH] Allow git to use any HTTP authentication method.
From: Martin Storsjö @ 2009-12-28 18:10 UTC (permalink / raw)
To: Junio C Hamano
Cc: Tay Ray Chuan, Shawn O. Pearce, Lénaïc Huard, git
In-Reply-To: <7vd41zrn4n.fsf@alter.siamese.dyndns.org>
On Mon, 28 Dec 2009, Junio C Hamano wrote:
> Would it be just a matter of queueing something like this on top of
> b8ac923 (Add an option for using any HTTP authentication scheme, not only
> basic, 2009-11-27)?
Looks good to me:
Acked-by: Martin Storsjo <martin@martin.st>
// Martin
^ permalink raw reply
* Re: [PATCH] Allow git to use any HTTP authentication method.
From: Shawn O. Pearce @ 2009-12-28 18:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Tay Ray Chuan, Martin Storsj?, L??na??c Huard, git
In-Reply-To: <7vd41zrn4n.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> -- >8 --
> From: "Shawn O. Pearce" <spearce@spearce.org>,
> Subject: Remove http.authAny
Ack.
But I'm not sure I should be the author, you did all of the legwork
and therefore should get credit for it. :-)
--
Shawn.
^ permalink raw reply
* [PATCH] Documentation: commit: explain the non-meaning of S-o-b
From: Jan Krüger @ 2009-12-28 18:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git ML
In the manpage for git commit, the option --signoff is mentioned but
there is no explanation of what it actually means. Add a brief hint that
S-o-b doesn't have a pre-defined meaning.
Signed-off-by: Jan Krüger <jk@jk.gs>
---
Semi-resend. Nobody commented on this when I first sent it in early
December, so here it is again, with a slightly more verbose
explanation. The repetition is intentional.
Documentation/git-commit.txt | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index d227cec..cae510b 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -114,7 +114,10 @@ OPTIONS
-s::
--signoff::
Add Signed-off-by line by the committer at the end of the commit
- log message.
+ log message. This line has no inherent meaning; it is up to the
+ potential recipient of the commit to decide what it stands for.
+ It is typically understood as an assurance by the committer that
+ the commit conforms to the receiving project's commit guidelines.
-n::
--no-verify::
--
1.6.5.3.171.ge36e
^ permalink raw reply related
* immutable tags?
From: Carlos Santana @ 2009-12-28 20:04 UTC (permalink / raw)
To: git
I would like to know if there is any difference between branches and
tags. Is it only conceptual - convention to be followed by a developer
or some technical difference? e.g. : Is it possible to create
immutable tags so that nothing can be checked in to that 'tagged
directory'?
-
CS.
^ permalink raw reply
* Re: immutable tags?
From: david @ 2009-12-28 20:25 UTC (permalink / raw)
To: Carlos Santana; +Cc: git
In-Reply-To: <92c9564e0912281204h13c6a566w95069023e6909eda@mail.gmail.com>
On Mon, 28 Dec 2009, Carlos Santana wrote:
> I would like to know if there is any difference between branches and
> tags. Is it only conceptual - convention to be followed by a developer
> or some technical difference? e.g. : Is it possible to create
> immutable tags so that nothing can be checked in to that 'tagged
> directory'?
tags are pointers into the tree. tags do not change.
in git directories are not tagged, so I'm not sure what you are working
towards here.
David Lang
^ permalink raw reply
* [PATCH 5/5] gitk: Use consistent font for all text input fields
From: Mark Hills @ 2009-12-28 20:04 UTC (permalink / raw)
To: git
In-Reply-To: <1262030643-12952-4-git-send-email-mark@pogo.org.uk>
Instead of setting the font for specific widgets, set the font for the
widget type. If themed widgets are not available, this is via the X
resources. If themed widgets are available, the theme font is used.
The exception is the SHA1 ID which is forced to use the fixed-width
font, even where themed widgets are used.
Signed-off-by: Mark Hills <mark@pogo.org.uk>
---
gitk-git/gitk | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index 5008753..13da663 100644
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -1874,7 +1874,8 @@ proc setoptions {} {
option add *Menubutton.font uifont startupFile
option add *Label.font uifont startupFile
option add *Message.font uifont startupFile
- option add *Entry.font uifont startupFile
+ option add *Entry.font textfont startupFile
+ option add *Text.font textfont startupFile
option add *Labelframe.font uifont startupFile
option add *Spinbox.font textfont startupFile
option add *Listbox.font mainfont startupFile
@@ -2173,7 +2174,7 @@ proc makewindow {} {
set findstring {}
set fstring .tf.lbar.findstring
lappend entries $fstring
- ${NS}::entry $fstring -width 30 -font textfont -textvariable findstring
+ ${NS}::entry $fstring -width 30 -textvariable findstring
trace add variable findstring write find_change
set findtype [mc "Exact"]
set findtypemenu [makedroplist .tf.lbar.findtype \
@@ -2216,7 +2217,7 @@ proc makewindow {} {
pack .bleft.top.search -side left -padx 5
set sstring .bleft.top.sstring
set searchstring ""
- ${NS}::entry $sstring -width 20 -font textfont -textvariable searchstring
+ ${NS}::entry $sstring -width 20 -textvariable searchstring
lappend entries $sstring
trace add variable searchstring write incrsearch
pack $sstring -side left -expand 1 -fill x
@@ -4036,7 +4037,7 @@ proc vieweditor {top n title} {
} elseif {$type eq "path"} {
${NS}::label $top.l -text $title
pack $top.l -in $top -side top -pady [list 3 0] -anchor w -padx 3
- text $top.t -width 40 -height 5 -background $bgcolor -font uifont
+ text $top.t -width 40 -height 5 -background $bgcolor
if {[info exists viewfiles($n)]} {
foreach f $viewfiles($n) {
$top.t insert end $f
--
1.6.6
^ permalink raw reply related
* [PATCH 1/5] gitk: Remove forced use of sans-serif font
From: Mark Hills @ 2009-12-28 20:03 UTC (permalink / raw)
To: git
The X resources set using uifont cover this case.
Signed-off-by: Mark Hills <mark@pogo.org.uk>
---
gitk-git/gitk | 12 ------------
1 files changed, 0 insertions(+), 12 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index 364c7a8..c58fd58 100644
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -10513,7 +10513,6 @@ proc mkfontdisp {font top which} {
set fontpref($font) [set $font]
${NS}::button $top.${font}but -text $which \
-command [list choosefont $font $which]
- if {!$use_ttk} {$top.${font}but configure -font optionfont}
${NS}::label $top.$font -relief flat -font $font \
-text $fontattr($font,family) -justify left
grid x $top.${font}but $top.$font -sticky w
@@ -10776,15 +10775,6 @@ proc doprefs {} {
mkfontdisp textfont $top [mc "Diff display font"]
mkfontdisp uifont $top [mc "User interface font"]
- if {!$use_ttk} {
- foreach w {maxpctl maxwidthl showlocal autoselect tabstopl ntag
- ldiff lattr extdifff.l extdifff.b bgbut fgbut
- diffoldbut diffnewbut hunksepbut markbgbut selbgbut
- want_ttk ttk_note} {
- $top.$w configure -font optionfont
- }
- }
-
${NS}::frame $top.buts
${NS}::button $top.buts.ok -text [mc "OK"] -command prefsok -default active
${NS}::button $top.buts.can -text [mc "Cancel"] -command prefscan -default normal
@@ -11396,8 +11386,6 @@ namespace import ::msgcat::mc
catch {source ~/.gitk}
-font create optionfont -family sans-serif -size -12
-
parsefont mainfont $mainfont
eval font create mainfont [fontflags mainfont]
eval font create mainfontbold [fontflags mainfont 1]
--
1.6.6
^ permalink raw reply related
* [PATCH 2/5] gitk: Set the font for all spinbox widgets
From: Mark Hills @ 2009-12-28 20:04 UTC (permalink / raw)
To: git
In-Reply-To: <1262030643-12952-1-git-send-email-mark@pogo.org.uk>
Use the X resources to set the font, removing the need to set the font
for specific widgets.
Signed-off-by: Mark Hills <mark@pogo.org.uk>
---
gitk-git/gitk | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index c58fd58..299a2ae 100644
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -1876,6 +1876,7 @@ proc setoptions {} {
option add *Message.font uifont startupFile
option add *Entry.font uifont startupFile
option add *Labelframe.font uifont startupFile
+ option add *Spinbox.font textfont startupFile
}
# Make a menu and submenus.
@@ -2226,7 +2227,7 @@ proc makewindow {} {
-command changediffdisp -variable diffelide -value {1 0}
${NS}::label .bleft.mid.labeldiffcontext -text " [mc "Lines of context"]: "
pack .bleft.mid.diff .bleft.mid.old .bleft.mid.new -side left
- spinbox .bleft.mid.diffcontext -width 5 -font textfont \
+ spinbox .bleft.mid.diffcontext -width 5 \
-from 0 -increment 1 -to 10000000 \
-validate all -validatecommand "diffcontextvalidate %P" \
-textvariable diffcontextstring
--
1.6.6
^ 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