* Re: What's cooking in git.git (Nov 2008, #01; Sun, 02)
From: David Syzdek @ 2008-11-02 23:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, David M. Syzdek, pasky
In-Reply-To: <7vbpwx3j7q.fsf@gitster.siamese.dyndns.org>
On Sun, Nov 2, 2008 at 12:34 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Here are the topics that have been cooking. Commits prefixed
> with '-' are only in 'pu' while commits prefixed with '+' are
> in 'next'.
>
> The topics list the commits in reverse chronological order. The topics
> meant to be merged to the maintenance series have "maint-" in their names.
>
> There are backlog patches I'm planning to deal with later today; they do
> not appear in this list.
>
> ----------------------------------------------------------------
> [New Topics]
>
> * mv/maint-branch-m-symref (Sat Nov 1 00:25:44 2008 +0100) 5 commits
> + update-ref --no-deref -d: handle the case when the pointed ref is
> packed
> + git branch -m: forbid renaming of a symref
> + Fix git update-ref --no-deref -d.
> + rename_ref(): handle the case when the reflog of a ref does not
> exist
> + Fix git branch -m for symrefs.
>
> * rs/blame (Sat Oct 25 15:31:36 2008 +0200) 5 commits
> - blame: use xdi_diff_hunks(), get rid of struct patch
> - add xdi_diff_hunks() for callers that only need hunk lengths
> - Allow alternate "low-level" emit function from xdl_diff
> - Always initialize xpparam_t to 0
> - blame: inline get_patch()
>
> * ds/uintmax-config (Sun Oct 26 03:52:47 2008 -0800) 2 commits
> - Add Makefile check for FreeBSD 4.9-SECURITY
> - Build: add NO_UINTMAX_T to support ancient systems
>
> I amended the topmost one to widen the applicability of this new feature
> to all FreeBSD 4.*, not limited to 4.9-SECURITY; testing before this hits
> 'next' is appreciated.
>
> * ds/autoconf (Sun Nov 2 01:04:46 2008 -0700) 2 commits
> - DONTMERGE: fixup with a convenience macro
> - autoconf: Add link tests to each AC_CHECK_FUNC() test
>
> The topmost one is my attempt to simplify the new way of checking; the
> resulting configure.ac produces the identical configure script with or
> without it, so I think it is Ok, but testing before this hits 'next' is
> appreciated. If all goes well, I think the two should be squashed into
> one patch.
I tested the above changes on FreeBSD. The changes worked on FreeBSD
4.9 worked.
However pthread is linked on FreeBSD 4.x by using `-pthread' instead
of `-lpthread'. The current pu branch forces the use of Pthreads and
links using an invalid flag. I am working on a patch now.
^ permalink raw reply
* Re: commit type
From: bd_ @ 2008-11-02 23:02 UTC (permalink / raw)
To: 7rans; +Cc: git
In-Reply-To: <loom.20081101T034635-562@post.gmane.org>
On Fri, Oct 31, 2008 at 11:15 PM, 7rans <transfire@gmail.com> wrote:
> Johannes Schindelin <Johannes.Schindelin <at> gmx.de> writes:
>
>> So you want to force this onto all Git users?
>
> Not at all. It would be a purely optional. You would never even need to know the
> feature existed if you didn't want to use it. So I'm not sure how that is
> forcing it upon anyone.
>
> Moreover, I suggested it b/c I would find such a feature very useful, and, by
> extension, thought others might as well. Perhaps others have done something
> similar, in which case it would be interesting the hear their take, or on the
> other hand they've never considered it before, but now can consider the
> potential utility of just such a feature.
>
>> If yes: that murmur you hear in the background, it might well be the
>> collective "thanks, but no thanks" of people who do not want that type of
>> distinction between different commits
>
> There is no need to make one. It's purely annotative.
The problem with this approach is that it begins to dictate a set of
annotations which are considered 'more important' by the git core than
others. By allowing in your 'commit type', it sets a precedent that
git will add random, possibly not backwards compatible metadata
changes just to support the local policies of some subset of git
users. It's far better to provide a generic feature that will cover
all users; and using the commit description, with hooks to enforce
proper format according to local policy, is just that.
If using the commit description, with hooks to enforce whatever
formatting you prefer, is not sufficient for your needs, then it would
be useful to discuss exactly how this would be deficient, and then
possibly think about adding a /generic/ feature that meets your needs.
^ permalink raw reply
* Re: git-cvsimport BUG: some commits are completely out of phase (but cvsps sees them all right)
From: Francis Galiegue @ 2008-11-02 22:31 UTC (permalink / raw)
To: tomi.pakarinen; +Cc: git
In-Reply-To: <f299b4f30811021421w2ef43792l7514ab3a0506077a@mail.gmail.com>
Le Sunday 02 November 2008 23:21:44 Tomi Pakarinen, vous avez écrit :
> CVS's branch does not appear on cvsps's output, until you do a commit
> to it. git-cvsimport
> relies on cvsps and can not do much about this...
>
Well, there's another file that cvsps generate (in $HOME/.cvsps) that helps
here and that is named ":<method>:<method_args>:#path#to#cvsroot#modulename."
This file contains the needed information. As far as I can see though,
git-cvsimport does not use it.
> Last problem may arise, if you try to do incremental imports from cvs to
> git. For incremental imports you must start import from same location in
> cvs each time.
> If you have made first import from beginning of history, sequent
> imports must start
> from there too. Otherwise cvsps will renumber patch sets.
>
The plan would be to convert all modules in one go, with no one committing in
the meantime, so that's not a problem.
I'll try and dig a little deeper into git-cvsimport and see if I can make it
use this information...
--
fge
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Junio C Hamano @ 2008-11-02 22:27 UTC (permalink / raw)
To: Jeff King
Cc: Sam Vilain, git, Johannes Schindelin, Scott Chacon,
Tom Preston-Werner, J.H., Christian Couder, Kai Blin
In-Reply-To: <20081031003154.GA5745@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> + * 'git push --matching' does what 'git push' does today (without
>> + explicit configuration)
>
> I think this is reasonable even without other changes, just to override
> any configuration.
I don't. Can't you say "git push $there HEAD" these days? I vaguely
recall that there is a way to configure push that way for people too lazy
to type "origin HEAD" after "git push".
>> + * 'git export' command that does what
>> + 'git archive --format=tar --prefix=dir | tar x' does now
>
> I agree, if you mean "does what ... does now" means "looks to the user
> like ... is happening". This is much more sanely done using
> git-checkout-index (though somebody suggested "remote export", which
> would need to use tar itself).
I think I was neutral in the discussion that led to the removal of
"git-export", but the rationale IIRC was exactly because "git-export" can
be done by simply piping "git-tar" to tar. On the other hand, if all you
had was "export" and you wanted to create a release tar/zip ball, you have
to first create a (potentially huge) hierarchy in the filesystem only to
archive it. This change needs to defend that the benefit of being able to
create a new non-git checkout elsewhere on the filesystem far outweighs
the downside of addition of another command (i.e. "eek, why does git have
that many commands" from new people).
^ permalink raw reply
* Re: git-cvsimport BUG: some commits are completely out of phase (but cvsps sees them all right)
From: Tomi Pakarinen @ 2008-11-02 22:21 UTC (permalink / raw)
To: Francis Galiegue; +Cc: git
In-Reply-To: <200811022203.41092.fg@one2team.net>
CVS's branch does not appear on cvsps's output, until you do a commit
to it. git-cvsimport
relies on cvsps and can not do much about this...
Last problem may arise, if you try to do incremental imports from cvs to git.
For incremental imports you must start import from same location in
cvs each time.
If you have made first import from beginning of history, sequent
imports must start
from there too. Otherwise cvsps will renumber patch sets.
Tomi.
On Sun, Nov 2, 2008 at 11:03 PM, Francis Galiegue <fg@one2team.net> wrote:
> Maybe it's due to the other bug that I reported with git-cvsimport a few days
> ago: namely, it does NOT see branches created by CVS with no commits in them
> (ie, create the branch and that's it, don't touch anything).
>
> The problem is very serious, since it seems to trigger another bug which
> prevents git-cvsimport from working at all. cvsps DOES see the commit
> correctly (branc exists for this file at 1.47.6):
>
> ---
> Members:
>
> src/java/com/one2team/database/bean/impl/relation/reporting/Register.java:1.47->1.47.6.1
> ---
>
> But on the imported git repository, the diff is rather 1.60 -> 1.47.6.1! As a
> result, the repository is plain unusable.
>
> As to the first problem, git finds 6 branches, cvs log finds 8 for the same
> module. git finds 22 tags, cvs log finds 29!
>
> --
> fge
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Junio C Hamano @ 2008-11-02 22:17 UTC (permalink / raw)
To: Pierre Habouzit
Cc: Nicolas Pitre, Matthieu Moy, Theodore Tso, Sam Vilain, git
In-Reply-To: <20081030170329.GK24098@artemis.corp>
Pierre Habouzit <madcoder@debian.org> writes:
> On Thu, Oct 30, 2008 at 05:00:18PM +0000, Nicolas Pitre wrote:
>
>> If you have a file argument, the --hard option is redundant, isn't it?
>> So what about simply "git reset <file>" ?
>
> errrrm, git reset <file> resets the index notion of the file to its status
> in HEAD... which I'm sure is *somehow* useful to "some" people ;P
I'd agree that 'reset' is rather unfortunate. It very originally was all
about the index (the "mixed" semantics, specifically "git reset" without
any committish nor any pathspec, was the original use case) and nothing
else. IOW, "I staged a wrong change, let's start over by discarding all
staged changes". A logical extension to it is "git reset -- pathspec",
IOW, "I know which paths I fubared, please reset only these paths, as
other staged changes are Ok".
So "reset <file>" is very much useful.
Then 'reset' learned to also muck with HEAD, so "reset HEAD^" (still
mixed, without any pathspec) can be used to amend the latest commit but
without losing the state you would eventually want to arrive at. A
logical extension to this was "git reset --hard HEAD^" to nuking instead
of amending the mistake, and "git reset --soft HEAD^" to save the trouble
of staging the changes when the mistake you are fixing is small compared
to the entire change.
"checkout [$committish] $path" came much later, and the command is all
about index and files, and never about resetting HEAD. "checkout $path"
does "reset --hard $path" (notice there is no $committish in either one)
would have done, so we stopped enhancing the "reset" command in that
direction.
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Junio C Hamano @ 2008-11-02 22:01 UTC (permalink / raw)
To: Theodore Tso; +Cc: Sam Vilain, git, Sam Vilain
In-Reply-To: <20081030143918.GB14744@mit.edu>
Theodore Tso <tytso@mit.edu> writes:
> Here are my favorites:
>
> * Add the command "git revert-file <files>" which is syntactic sugar for:
>
> git checkout HEAD -- <files>
This is good; I do not recall offhand what we do if some of the <files> do
not appear in HEAD right now, but I have a suspicion that it would be a
no-op, in which case interested parties may first want to fix checkout to
remove such paths.
Also I thiink you can add "git revert-commit [$committish]" as a synonym
to the current "git revert [$committish]" if it makes things easier to
explain to others.
> * Change the argument handling for "git format-patch" so it is
> consistent with everything else which takes a set of commits. Yes,
> it means that where people have gotten used to typing "git
> format-patch origin", they'll have to type instead: "git
> format-patch origin..", but's much more consistent.
I think that has already happened some time ago in the sense that you can
say "origin.." and it does what you want. I do not think it merits to
deprecate the original one --- if you do not like it, you do not use it
nor teach it to others.
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Junio C Hamano @ 2008-11-02 21:53 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Sam Vilain, git
In-Reply-To: <20081030132453.GB24098@artemis.corp>
Pierre Habouzit <madcoder@debian.org> writes:
> * 'git track' would do what git add -N does now.
> * 'git untrack' would do what 'git rm --cached' does now.
Ok with me up to here.
>> + * 'git undo' would do what 'git checkout HEAD --' does now
> ...
> I have no constructive proposal to replace it though, but I believe git
> undo would cause lots of harm.
I'm in agreement.
> * git-send-email should be either more interactive, or less: either
> just use the damn configuration, or propose a mode where it spawns
> an editor for each patch so that you can add further comments.
In principle I'd agree, but I use send-email non-interactively myself (I
type Meta/SE where Meta is an independent checkout of my 'todo' branch),
so I am not sure if the "just use the configuration" is an added
requirement. I also have this in .git/config in the repo:
[sendemail]
smtpserver = /usr/bin/msmtp
to = git@vger.kernel.org
suppressfrom
signedoffcc = false
> * git-send-email should be able to format-patches by himself (IOW
> accept most of format-patch arguments and deal with the patch list
> by himself, which is usable if the previous point is implemented).
I earlier was against this, mostly out of the "each tool to do the job it
was designed to do well" principle, but with your workflow description and
Peff's comment, I am open to add this kind of "run format-patch internally"
wrapper behaviour to send-email which is already a Porcelain anyway.
>> + * 'git am -3' the default; with global option to make it not the
>> + default for those that prefer the speed of -2
I am moderately negative on this, but not because of performance concern.
The --3way fall back is done only when it is necessary, and there is no
"prefer the speed" involved. It is between "stop when the patch does not
apply because there may be something iffy going on" and "assume it is Ok
in such an iffy case to pretend that you apply the patch to the original
copy and cherry-pick the result to your updated tree". IOW, it is a
safety concern.
^ permalink raw reply
* What's in git.git (Nov 2008, #01; Sun, 02)
From: Junio C Hamano @ 2008-11-02 21:35 UTC (permalink / raw)
To: git
There are several topic branches destined for 'maint' that have been
cooking and have graduated to 'master', and I'll make the noise about
1.6.0.4 louder once they are merged, but not yet.
On the 'master' front, there are quite a few git-gui updates.
* The 'maint' branch has these fixes since the last announcement.
Alex Riesen (3):
Plug a memleak in builtin-revert
Add --verbose|-v to test-chmtime
Use test-chmtime -v instead of perl in t5000 to get mtime of a file
Charles Bailey (1):
git-archive: work in bare repos
Deskin Miller (2):
git-svn: change dashed git-config to git config
git-svn: change dashed git-commit-tree to git commit-tree
Gustaf Hendeby (1):
git-gui: Help identify aspell version on Windows too
Jakub Narebski (1):
Documentation/gitattributes: Add subsection header for each attribute
Jan Krüger (1):
Documentation: clarify information about 'ident' attribute
Jeff King (4):
correct cache_entry allocation
pack-objects: avoid reading uninitalized data
fix overlapping memcpy in normalize_absolute_path
send-pack: do not send out single-level refs such as refs/stash
Jonas Fonseca (1):
asciidoc: add minor workaround to add an empty line after code blocks
Junio C Hamano (1):
Start 1.6.0.4 cycle
Linus Torvalds (1):
Add file delete/create info when we overflow rename_limit
Markus Heidelberg (1):
bash completion: add doubledash to "git show"
Nanako Shiraishi (1):
Install git-cvsserver in $(bindir)
Pierre Habouzit (1):
git send-email: avoid leaking directory file descriptors.
Thomas Rast (1):
add -p: warn if only binary changes present
Tom Preston-Werner (1):
add instructions on how to send patches to the mailing list with Gmail
Tommi Virtanen (1):
Install git-shell in bindir, too
* The 'master' branch has these since the last announcement
in addition to the above.
Alexander Gavrilov (6):
git-gui: Make Ctrl-T safe to use for conflicting files.
git-gui: Fix the blame window shape.
git-gui: Add a search command to the blame viewer.
git-gui: Fix the blame viewer destroy handler.
git-gui: Add a dialog that shows the OpenSSH public key.
git-gui: Add a simple implementation of SSH_ASKPASS.
Christian Stimming (1):
git-gui: Update German translation.
Jan Krüger (1):
Introduce receive.denyDeletes
Joey Hess (1):
git-daemon: set REMOTE_ADDR to client address
Johannes Sixt (6):
git-gui: Do not automatically stage file after merge tool finishes
git-gui: Remove space from the end of aspell's reply before processing
git-gui: Fix switch statement in lib/merge.tcl
git-gui: Show a round number of bytes of large untracked text files
git-gui: Mark-up strings in show_{other,unmerged}_diff() for localization
git-gui: Do not munge conflict marker lines in a normal diff
Junio C Hamano (4):
receive-pack: fix "borrowing from alternate object store" implementation
compat/cygwin.c: make runtime detection of lstat/stat lessor impact
Stop using compat/regex.c on platforms with working regexp library
Update draft release notes to 1.6.1
Petr Baudis (12):
git-gui: Clarify the Remote -> Delete... action
git-gui: Squash populate_{push,fetch}_menu to populate_remotes_menu
git-gui: Add support for adding remotes
git-gui: Add support for removing remotes
git-gui: mkdir -p when initializing new remote repository
git-gui: Use git web--browser for web browsing
git-gui: Add Explore Working Copy to the Repository menu
git-gui: gui.autoexplore makes explorer to pop up automatically after
picking
git-gui: Avoid using the term URL when specifying repositories
git-gui: Make input boxes in init/clone/open dialogs consistent
git-gui: Fix removing non-pushable remotes
git-gui: Fix fetching from remotes when adding them
Shawn O. Pearce (1):
git-gui: Show/hide "Sign Off" based on nocommitmsg option
Tom Preston-Werner (1):
connect.c: add a way for git-daemon to pass an error back to client
^ permalink raw reply
* Re: [PATCH 1/3] git send-email: make the message file name more specific.
From: Ian Hilt @ 2008-11-02 21:34 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Junio C Hamano, git
In-Reply-To: <20081102093533.GE4066@artemis>
On Sun, 2 Nov 2008, Pierre Habouzit wrote:
> On Sun, Nov 02, 2008 at 06:18:08AM +0000, Junio C Hamano wrote:
> > Having said that, if we were to do this, let's do it the right way and put
> > these "temporary" files under $GIT_DIR.
>
> Agreed, I should have done that.
Perhaps like this:
my $compose_filename = $repo->repo_path() . "/sendemail.msg.$$";
where $repo is a repository instance.
Ian
^ permalink raw reply
* What's cooking in git.git (Nov 2008, #01; Sun, 02)
From: Junio C Hamano @ 2008-11-02 21:34 UTC (permalink / raw)
To: git; +Cc: David M. Syzdek, pasky
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'.
The topics list the commits in reverse chronological order. The topics
meant to be merged to the maintenance series have "maint-" in their names.
There are backlog patches I'm planning to deal with later today; they do
not appear in this list.
----------------------------------------------------------------
[New Topics]
* mv/maint-branch-m-symref (Sat Nov 1 00:25:44 2008 +0100) 5 commits
+ update-ref --no-deref -d: handle the case when the pointed ref is
packed
+ git branch -m: forbid renaming of a symref
+ Fix git update-ref --no-deref -d.
+ rename_ref(): handle the case when the reflog of a ref does not
exist
+ Fix git branch -m for symrefs.
* rs/blame (Sat Oct 25 15:31:36 2008 +0200) 5 commits
- blame: use xdi_diff_hunks(), get rid of struct patch
- add xdi_diff_hunks() for callers that only need hunk lengths
- Allow alternate "low-level" emit function from xdl_diff
- Always initialize xpparam_t to 0
- blame: inline get_patch()
* ds/uintmax-config (Sun Oct 26 03:52:47 2008 -0800) 2 commits
- Add Makefile check for FreeBSD 4.9-SECURITY
- Build: add NO_UINTMAX_T to support ancient systems
I amended the topmost one to widen the applicability of this new feature
to all FreeBSD 4.*, not limited to 4.9-SECURITY; testing before this hits
'next' is appreciated.
* ds/autoconf (Sun Nov 2 01:04:46 2008 -0700) 2 commits
- DONTMERGE: fixup with a convenience macro
- autoconf: Add link tests to each AC_CHECK_FUNC() test
The topmost one is my attempt to simplify the new way of checking; the
resulting configure.ac produces the identical configure script with or
without it, so I think it is Ok, but testing before this hits 'next' is
appreciated. If all goes well, I think the two should be squashed into
one patch.
* jk/diff-convfilter-test-fix (Fri Oct 31 01:09:13 2008 -0400) 4 commits
+ Avoid using non-portable `echo -n` in tests.
+ add userdiff textconv tests
+ document the diff driver textconv feature
+ diff: add missing static declaration
* ar/maint-mksnpath (Mon Oct 27 11:22:09 2008 +0100) 7 commits
+ Use git_pathdup instead of xstrdup(git_path(...))
+ git_pathdup: returns xstrdup-ed copy of the formatted path
+ Fix potentially dangerous use of git_path in ref.c
+ Add git_snpath: a .git path formatting routine with output buffer
+ Fix potentially dangerous uses of mkpath and git_path
+ Fix mkpath abuse in dwim_ref and dwim_log of sha1_name.c
+ Add mksnpath which allows you to specify the output buffer
* ar/mksnpath (Thu Oct 30 18:08:58 2008 -0700) 10 commits
+ Merge branch 'ar/maint-mksnpath' into ar/mksnpath
+ Use git_pathdup instead of xstrdup(git_path(...))
+ git_pathdup: returns xstrdup-ed copy of the formatted path
+ Fix potentially dangerous use of git_path in ref.c
+ Add git_snpath: a .git path formatting routine with output buffer
+ Fix potentially dangerous uses of mkpath and git_path
+ Merge branch 'ar/maint-mksnpath' into HEAD
+ Fix potentially dangerous uses of mkpath and git_path
+ Fix mkpath abuse in dwim_ref and dwim_log of sha1_name.c
+ Add mksnpath which allows you to specify the output buffer
----------------------------------------------------------------
[Will be merged to 'master' soon]
* cj/maint-gitpm-fix-maybe-self (Sat Oct 18 20:25:12 2008 +0200) 1 commit
+ Git.pm: do not break inheritance
Looked Ok; will be in 'master' soon.
* gb/gitweb-pathinfo (Tue Oct 21 21:34:54 2008 +0200) 5 commits
+ gitweb: generate parent..current URLs
+ gitweb: parse parent..current syntax from PATH_INFO
+ gitweb: use_pathinfo filenames start with /
+ gitweb: generate project/action/hash URLs
+ gitweb: parse project/action/hash_base:filename PATH_INFO
Seventh iteration.
* ag/blame-encoding (Wed Oct 22 00:55:57 2008 +0400) 1 commit
+ builtin-blame: Reencode commit messages according to git-log
rules.
Looked Ok; will be in 'master' soon.
* mv/parseopt-checkout-index (Sat Oct 18 03:17:23 2008 +0200) 1 commit
+ parse-opt: migrate builtin-checkout-index.
Looked Ok; will be in 'master' soon.
* sh/rebase-i-p (Wed Oct 22 11:59:30 2008 -0700) 9 commits
+ git-rebase--interactive.sh: comparision with == is bashism
+ rebase-i-p: minimum fix to obvious issues
+ rebase-i-p: if todo was reordered use HEAD as the rewritten parent
+ rebase-i-p: do not include non-first-parent commits touching
UPSTREAM
+ rebase-i-p: only list commits that require rewriting in todo
+ rebase-i-p: fix 'no squashing merges' tripping up non-merges
+ rebase-i-p: delay saving current-commit to REWRITTEN if squashing
+ rebase-i-p: use HEAD for updating the ref instead of mapping
OLDHEAD
+ rebase-i-p: test to exclude commits from todo based on its parents
Changes the `rebase -i -p` behavior to behave like git sequencer's
rewrite of `rebase -i` would behave.
* np/index-pack (Thu Oct 23 15:05:59 2008 -0400) 5 commits
+ index-pack: don't leak leaf delta result
+ improve index-pack tests
+ fix multiple issues in index-pack
+ index-pack: smarter memory usage during delta resolution
+ index-pack: rationalize delta resolution code
The buglets that caused people on 'next' some surprises are quickly
killed. Thanks.
----------------------------------------------------------------
[Stalled]
* jk/diff-convfilter (Sun Oct 26 00:50:02 2008 -0400) 8 commits
- enable textconv for diff in verbose status/commit
- wt-status: load diff ui config
* nd/narrow (Wed Oct 1 11:04:09 2008 +0700) 9 commits
- grep: skip files outside sparse checkout area
- checkout_entry(): CE_NO_CHECKOUT on checked out entries.
- Prevent diff machinery from examining worktree outside sparse
checkout
- ls-files: Add tests for --sparse and friends
- update-index: add --checkout/--no-checkout to update
CE_NO_CHECKOUT bit
- update-index: refactor mark_valid() in preparation for new options
- ls-files: add options to support sparse checkout
- Introduce CE_NO_CHECKOUT bit
- Extend index to save more flags
Needs review.
* jn/gitweb-customlinks (Sun Oct 12 00:02:32 2008 +0200) 1 commit
- gitweb: Better processing format string in custom links in navbar
Waiting for some sort of response from Pasky.
* jc/gitweb-fix-cloud-tag (Tue Oct 14 21:27:12 2008 -0700) 1 commit
+ Fix reading of cloud tags
Request-for-review-and-ack sent; still waiting for response.
----------------------------------------------------------------
[Dropped]
* bd/blame (Thu Aug 21 18:22:01 2008 -0500) 5 commits
. Use xdiff caching to improve git blame performance
. Allow xdiff machinery to cache hash results for a file
. Always initialize xpparam_t to 0
. Bypass textual patch generation and parsing in git blame
. Allow alternate "low-level" emit function from xdl_diff
Réne started code restructuring, which is queued to 'pu'; this series is
dropped.
----------------------------------------------------------------
[On Hold]
* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit
- "git push": tellme-more protocol extension
This seems to have a deadlock during communication between the peers.
Someone needs to pick up this topic and resolve the deadlock before it can
continue.
* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits
- blame: show "previous" information in --porcelain/--incremental
format
- git-blame: refactor code to emit "porcelain format" output
* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
- diff: enable "too large a rename" warning when -M/-C is explicitly
asked for
This would be the right thing to do for command line use,
but gitk will be hit due to tcl/tk's limitation, so I am holding
this back for now.
^ permalink raw reply
* git-cvsimport BUG: some commits are completely out of phase (but cvsps sees them all right)
From: Francis Galiegue @ 2008-11-02 21:03 UTC (permalink / raw)
To: git
Maybe it's due to the other bug that I reported with git-cvsimport a few days
ago: namely, it does NOT see branches created by CVS with no commits in them
(ie, create the branch and that's it, don't touch anything).
The problem is very serious, since it seems to trigger another bug which
prevents git-cvsimport from working at all. cvsps DOES see the commit
correctly (branc exists for this file at 1.47.6):
---
Members:
src/java/com/one2team/database/bean/impl/relation/reporting/Register.java:1.47->1.47.6.1
---
But on the imported git repository, the diff is rather 1.60 -> 1.47.6.1! As a
result, the repository is plain unusable.
As to the first problem, git finds 6 branches, cvs log finds 8 for the same
module. git finds 22 tags, cvs log finds 29!
--
fge
^ permalink raw reply
* Git and Media repositories....
From: Tim Ansell @ 2008-11-02 19:50 UTC (permalink / raw)
To: git
Hey guys,
Last week at the gittogether I lead some discussions about how we could
make Git better support large media repositories (which is one area
where Subversion still make sense). It was suggested that I post to this
list to get a discussion going.
The general idea is that we always clone the complete meta-data (tags,
commits and trees) and then only clone blobs when they are needed (using
something like alternates). This allows us to support shallow, narrow
and sparse checkouts while still being able to perform operations such
as committing and merging.
You can find a copy of the summary presentation at
http://www.thousandparsec.net/~tim/media+git.pdf
I have started working on adapting git to check a remote http alternate
to provide a proof of concept.
I appreciate any help or suggestions.
Tim 'mithro' Ansell
^ permalink raw reply
* Re: [PATCH 3/7] Documentation: rework SHA1 description in git push
From: Anders Melchiorsen @ 2008-11-02 20:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1vxxba2c.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Anders Melchiorsen <mail@cup.kalibalik.dk> writes:
>
>> Get rid of a double pair of parentheses. The arbitrary SHA1 is a
>> special case, so it can be postponed a bit.
>
> Hmmm...
>
> Strictly speaking, arbitrary SHA-1 is the general case, and branch name is
> a special case of it, but in practice, branch name is the most frequently
> used form, and that is why it has the short-hand convention that allows it
> to to be pushed to the same name.
Right, that was poor wording. When I said "special case", I meant it
as "rare use case".
>> Also mention HEAD, which is possibly the most useful SHA1 in this
>> situation.
>
> HEAD is indeed useful, but it falls into the special case of "branch
> name", not "arbitrary SHA-1 expression". This distinction is important
> because you can push "HEAD" without colon and it will act as if you said
> master:master (or whatever branch you are currently on). This is already
> described in the existing doc:
>
> The local ref that matches <src> is used
> to fast forward the remote ref that matches <dst> (or, if no <dst> was
> specified, the same ref that <src> referred to locally).
Oh, I did (obviously) not realize that you can use HEAD in that way,
and actually I cannot read that from the quoted paragraph even now
that I know about it.
It seems to me that HEAD is a special-special case, and that it is not
even mentioned in the current documentation. With my current
understanding, I would say that HEAD can work both as a "branch name"
(that discovers its own name automatically) and as an "arbitrary
SHA-1" (with a detached head).
>> --- a/Documentation/git-push.txt
>> +++ b/Documentation/git-push.txt
>> @@ -38,9 +38,7 @@ OPTIONS
>> by the source ref, followed by a colon `:`, followed by
>> the destination ref.
>> +
>> -The <src> side represents the source branch (or arbitrary
>> -"SHA1 expression", such as `master~4` (four parents before the
>> -tip of `master` branch); see linkgit:git-rev-parse[1]) that you
>> +The <src> side represents the source branch that you
>> want to push. The <dst> side represents the destination location.
>
> The <src> is often the name of the branch you would want to push, but it
> can be any arbitrary "SHA-1 expression", such as `master~4` (four parents
> before the tip of `master` branch -- see linkgit:git-rev-parse[1]), or
> `HEAD` (the tip of the current branch). The <dst> tells which ref on the
> remote side is updated with this push.
>
> The object referenced by <src> is used to fast forward the ref <dst> on
> the remote side. You can omit <dst> to update the same ref on the remote
> side as <src> (<src> is often the name of a branch you push, and often you
> push to the same branch on the remote side; `git push HEAD` is a handy way
> to push only the current branch to the remote side under the same name).
> If the optional leading plus `{plus}` is used, the remote ref is updated
> even if it does not result in a fast forward update.
I find those paragraphs hard to read. The shorter sentences and lack
of parentheses in my patch series was more to my taste. I actually
think that the examples, like explaining master~4, detracts from the
main topic and makes it harder to find the information.
>> @@ -193,6 +195,10 @@ git push origin master::
>> with it. If `master` did not exist remotely, it would be
>> created.
>>
>> +git push origin HEAD:master::
>> + Push the current head to the remote ref matching `master` in
>> + the `origin` repository.
>> +
>
> Additional example is good, but you would want to tell readers that this
> would be useful when your current branch is _not_ 'master'.
Right.
Cheers,
Anders.
^ permalink raw reply
* Re: Offtopic [Re: Can't use gitk.]
From: Paolo Ciarrocchi @ 2008-11-02 19:28 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Franck, Andreas Ericsson, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0511141005590.3263@g5.osdl.org>
On Mon, Nov 14, 2005 at 7:24 PM, Linus Torvalds <torvalds@osdl.org> wrote:
>
> On Mon, 14 Nov 2005, Franck wrote:
Sorry for commenting on this email only now but I found it in my
archive while looking for a different thread :-)
>> oops, sorry Andreas for that ! I use to spelling this name without 's'
>> that's why I did the mistake I think.
>
> In Finland and Sweden Andrea without the "s" is a girls name, while
> Andreas with the "s" (or André without "-as") is a boy.
>
> It's not even very rare. "Andrea" was the 84th most popular female name in
> Sweden in 2000.
>
> It can be confusing, since in Italy (and, I think, southern Germany and
> much of Eastern Europe), "Andrea" is a boy, and in fact, the name
> originally comes from the Greek meaning "man".
In Italy Andrea might be a girl as well even if that name is often
used for a boy.
Ciao,
--
Paolo
http://paolo.ciarrocchi.googlepages.com/
^ permalink raw reply
* Re: Pull request for sub-tree merge into /contrib/gitstats
From: Sverre Rabbelier @ 2008-11-02 19:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailinglist
In-Reply-To: <7vljw5evj5.fsf@gitster.siamese.dyndns.org>
[Sorry for the late reply, have been travelling, sleeping, and
catching up with family in the past few days]
On Thu, Oct 30, 2008 at 20:24, Junio C Hamano <gitster@pobox.com> wrote:
> I have a mixed feeling about this. From a longer-term perspective, do you
> really want this to be a part of git.git repository?
My main reason for wanting to have it in git.git is getting additional
exposure, being in /contrib seems like a good way to do that.
> I do not mind having notes to endorse and advocate "stats" as one of the
> "Third party packages that may make your git life more pleasuable", just
> like tig, stgit, guilt and topgit, but I cannot convince myself that
> merging it as a subtree is the right thing to do at this point.
Heh, blame Johannes for that one; the main reason for not doing
something like this earlier was my uncertaincy as to -what- to do.
Dscho suggested to request-pull a subtree merge, which is what I did.
> The "stats" tool, at least at the conceptual level, shares one important
> property with tools like gitk and gitweb: it could be useful to people
> whose sources are not in git repositories but in say Hg or Bzr, with some
> effort. The code may need refactoring to make it easier to plug in
> different backends and writing actual backends (aka "porting"), but that
> is something you can expect people with different backends to help you
> with.
This is true, it uses a python wrapper around git, but with some work
it could be make to use a more abstract wrapper instead, that allows
the use of different backends.
> However, it would be awkward for the contrib/ area in git.git to carry a
> lot of code that are only needed to produce stat data from non-git
> repositories, once such a porting effort begins.
I reckon it would not be a lot of code, but I agree, that would be awkward.
> It's perfectly fine if you are not interested in any of the other
> backends, and tell the people that they are welcome to fork it never to
> merge back. But if this were my brainchild, I'd imagine I'd be wishing to
> be able to buy back the improvements to the "core stats" parts that are
> done by people with other backends. I would imagine binding the current
> code as part of git.git would make such improvements harder to manage,
> both for you (who wants to buy back the changes made by others on
> different backends) and for others on different backends (who want to
> merge the changes made by you to their forks).
This is true, if there is indeed interest from other backends to use
this kind of functionality, I would welcome the patches. In such a
case being in git.git/contrib might not be a good thing.
> Perhaps pointing at your tree as a submodule would be the right thing to
> do; then git.git proper will be just one of the users of "stats" tool.
Would a subdir in git.git for such submodules be a good idea? That way
we don't have to worry about a conflict between (for example) git-gui
as a subdir, and git-gui as a submodule.
> How about making that as a mid-to-longer term goal? When we eject git-gui
> and gitk from git.git and make them a submodule (wasn't that supposed to
> happen in 1.8 or 2.0 timeframe?), we may also add "stats" as a submodule?
I didn't know there was a timeframe for this, I thought your
suggestion tree to eject-and-make-into-submodule was somewhat ignored;
if there are indeed plans for this, I would be ok with having
git-stats as a submodule instead.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: commit takes 8 secs; but instant when offline - can I fix this?
From: Linus Torvalds @ 2008-11-02 19:18 UTC (permalink / raw)
To: Brendan Macmillan; +Cc: Thomas Rast, git
In-Reply-To: <7d856ea50811020834n3a252ae2r21d36b24c10eebbf@mail.gmail.com>
On Mon, 3 Nov 2008, Brendan Macmillan wrote:
>
> Many thanks for the explanation, and it's now instant.
>
> To ~/.gitconfig, I added:
>
> [user]
> email = myemail@address.com
I'd like to point out that in addition to making git not try to figure out
your hostname, you may well want to try to fix your setup so that it
doesn't take that long in the first place.
In fact, you might use "git commit" (or "git var -l" which probably shows
the same 8-second thing more easily without needing anything else) as a
way to debug what it is that takes too long.
Because even though adding your email to yout .gitconfig file is the right
solution _anyway_ (because the git guess is rather more flaky than you
just telling it what host to use), I bet there are other programs that
will have the same 8-second delay, and you are better off trying to just
fix your DNS problem.
Linus
^ permalink raw reply
* [PATCH (GITK) v3 6/6] gitk: Explicitly position popup windows.
From: Alexander Gavrilov @ 2008-11-02 18:59 UTC (permalink / raw)
To: git; +Cc: Paul Mackerras
In-Reply-To: <1225652389-22082-6-git-send-email-angavrilov@gmail.com>
For some reason, on Windows all transient windows are placed
in the upper left corner of the screen. Thus, it is necessary
to explicitly position the windows relative to their parent.
For simplicity this patch uses the function that is used
internally by Tk dialogs.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
I wrapped the call to tk::PlaceWindow in a
helper function to minimize the number of
places to change if something happens to it.
-- Alexander
gitk | 25 +++++++++++++++++++++++--
1 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/gitk b/gitk
index 5b4eaa2..7d153a3 100755
--- a/gitk
+++ b/gitk
@@ -1739,7 +1739,13 @@ proc removehead {id name} {
unset headids($name)
}
-proc show_error {w top msg} {
+proc center_window {window origin} {
+ # Use a handy function from Tk. Note that it
+ # calls 'update' to figure out dimensions.
+ tk::PlaceWindow $window widget $origin
+}
+
+proc show_error {w top msg {owner {}}} {
message $w.m -text $msg -justify center -aspect 400
pack $w.m -side top -fill x -padx 20 -pady 20
button $w.ok -text [mc OK] -command "destroy $top"
@@ -1748,6 +1754,9 @@ proc show_error {w top msg} {
bind $top <Key-Return> "destroy $top"
bind $top <Key-space> "destroy $top"
bind $top <Key-Escape> "destroy $top"
+ if {$owner ne {}} {
+ center_window $top $owner
+ }
tkwait window $top
}
@@ -1755,7 +1764,7 @@ proc error_popup {msg {owner .}} {
set w .error
toplevel $w
wm transient $w $owner
- show_error $w $w $msg
+ show_error $w $w $msg $owner
}
proc confirm_popup {msg {owner .}} {
@@ -1774,6 +1783,7 @@ proc confirm_popup {msg {owner .}} {
bind $w <Key-Return> "set confirm_ok 1; destroy $w"
bind $w <Key-space> "set confirm_ok 1; destroy $w"
bind $w <Key-Escape> "destroy $w"
+ center_window $w $owner
tkwait window $w
return $confirm_ok
}
@@ -2572,6 +2582,7 @@ Use and redistribute under the terms of the GNU General Public License"] \
bind $w <Visibility> "focus $w.ok"
bind $w <Key-Escape> "destroy $w"
bind $w <Key-Return> "destroy $w"
+ center_window $w .
}
proc keys {} {
@@ -2635,6 +2646,7 @@ proc keys {} {
bind $w <Visibility> "focus $w.ok"
bind $w <Key-Escape> "destroy $w"
bind $w <Key-Return> "destroy $w"
+ center_window $w .
}
# Procedures for manipulating the file list window at the
@@ -3687,6 +3699,7 @@ proc vieweditor {top n title} {
grid columnconfigure $top.buts 1 -weight 1 -uniform a
grid columnconfigure $top.buts 2 -weight 1 -uniform a
pack $top.buts -in $top -side top -fill x
+ center_window $top .
focus $top.t
}
@@ -7950,6 +7963,7 @@ proc mkpatch {} {
grid columnconfigure $top.buts 1 -weight 1 -uniform a
grid $top.buts - -pady 10 -sticky ew
focus $top.fname
+ center_window $top .
}
proc mkpatchrev {} {
@@ -8024,6 +8038,7 @@ proc mktag {} {
grid columnconfigure $top.buts 1 -weight 1 -uniform a
grid $top.buts - -pady 10 -sticky ew
focus $top.tag
+ center_window $top .
}
proc domktag {} {
@@ -8131,6 +8146,7 @@ proc writecommit {} {
grid columnconfigure $top.buts 1 -weight 1 -uniform a
grid $top.buts - -pady 10 -sticky ew
focus $top.fname
+ center_window $top .
}
proc wrcomgo {} {
@@ -8181,6 +8197,7 @@ proc mkbranch {} {
grid columnconfigure $top.buts 1 -weight 1 -uniform a
grid $top.buts - -pady 10 -sticky ew
focus $top.name
+ center_window $top .
}
proc mkbrgo {top} {
@@ -8341,6 +8358,7 @@ proc resethead {} {
bind $w <Key-Escape> [list destroy $w]
pack $w.cancel -side right -fill x -padx 20 -pady 20
bind $w <Visibility> "grab $w; focus $w"
+ center_window $w .
tkwait window $w
if {!$confirm_ok} return
if {[catch {set fd [open \
@@ -8526,6 +8544,7 @@ proc showrefs {} {
bind $top.list <ButtonRelease-1> {sel_reflist %W %x %y; break}
set reflist {}
refill_reflist
+ center_window $top .
}
proc sel_reflist {w x y} {
@@ -9878,6 +9897,7 @@ proc choosefont {font which} {
grid columnconfigure $top.buts 1 -weight 1 -uniform a
pack $top.buts -side bottom -fill x
trace add variable fontparam write chg_fontparam
+ center_window $top $prefstop
} else {
raise $top
$top.c itemconf text -text $which
@@ -10060,6 +10080,7 @@ proc doprefs {} {
grid columnconfigure $top.buts 1 -weight 1 -uniform a
grid $top.buts - - -pady 10 -sticky ew
bind $top <Visibility> "focus $top.buts.ok"
+ center_window $top .
}
proc choose_extdiff {} {
--
1.6.0.3.15.gb8d36
^ permalink raw reply related
* [PATCH (GITK) v3 5/6] gitk: Implement a user-friendly Edit View dialog.
From: Alexander Gavrilov @ 2008-11-02 18:59 UTC (permalink / raw)
To: git; +Cc: Paul Mackerras
In-Reply-To: <1225652389-22082-5-git-send-email-angavrilov@gmail.com>
Originally gitk required the user to specify all limiting
options manually in the same field with the list of commits.
It is rather unfriendly for new users, who may not know
which options can be used, or, indeed, that it is possible
to specify them at all.
This patch modifies the dialog to present the most useful
options as individual fields. Note that options that may
be useful to an extent, but produce a severely broken view,
are deliberately not included.
It is still possible to specify options in the commit list
field, but when the dialog is reopened, they will be extracted
into their own separate fields.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
gitk | 207 ++++++++++++++++++++++++++++++++++++++++++++++++++++--------------
1 files changed, 163 insertions(+), 44 deletions(-)
diff --git a/gitk b/gitk
index 71f1b27..5b4eaa2 100755
--- a/gitk
+++ b/gitk
@@ -3479,8 +3479,8 @@ proc shellsplit {str} {
# Code to implement multiple views
proc newview {ishighlight} {
- global nextviewnum newviewname newviewperm newishighlight
- global newviewargs revtreeargs viewargscmd newviewargscmd curview
+ global nextviewnum newviewname newishighlight
+ global revtreeargs viewargscmd newviewopts curview
set newishighlight $ishighlight
set top .gitkview
@@ -3489,9 +3489,9 @@ proc newview {ishighlight} {
return
}
set newviewname($nextviewnum) "[mc "View"] $nextviewnum"
- set newviewperm($nextviewnum) 0
- set newviewargs($nextviewnum) [shellarglist $revtreeargs]
- set newviewargscmd($nextviewnum) $viewargscmd($curview)
+ set newviewopts($nextviewnum,perm) 0
+ set newviewopts($nextviewnum,cmd) $viewargscmd($curview)
+ decode_view_opts $nextviewnum $revtreeargs
vieweditor $top $nextviewnum [mc "Gitk view definition"]
}
@@ -3505,53 +3505,167 @@ proc edit_or_newview {} {
}
}
+set known_view_options {
+ {perm b . {} {mc "Remember this view"}}
+ {args t50= + {} {mc "Commits to include (arguments to git log):"}}
+ {all b * "--all" {mc "Use all refs"}}
+ {dorder b . {"--date-order" "-d"} {mc "Strictly sort by date"}}
+ {lright b . "--left-right" {mc "Mark branch sides"}}
+ {since t15 + {"--since=*" "--after=*"} {mc "Since date:"}}
+ {until t15 . {"--until=*" "--before=*"} {mc "Until date:"}}
+ {limit t10 + "--max-count=*" {mc "Max count:"}}
+ {skip t10 . "--skip=*" {mc "Skip:"}}
+ {first b . "--first-parent" {mc "Limit to first parent"}}
+ {cmd t50= + {} {mc "Command to generate more commits to include:"}}
+ }
+
+proc encode_view_opts {n} {
+ global known_view_options newviewopts
+
+ set rargs [list]
+ foreach opt $known_view_options {
+ set patterns [lindex $opt 3]
+ if {$patterns eq {}} continue
+ set pattern [lindex $patterns 0]
+
+ set val $newviewopts($n,[lindex $opt 0])
+
+ if {[lindex $opt 1] eq "b"} {
+ if {$val} {
+ lappend rargs $pattern
+ }
+ } else {
+ set val [string trim $val]
+ if {$val ne {}} {
+ set pfix [string range $pattern 0 end-1]
+ lappend rargs $pfix$val
+ }
+ }
+ }
+ return [concat $rargs [shellsplit $newviewopts($n,args)]]
+}
+
+proc decode_view_opts {n view_args} {
+ global known_view_options newviewopts
+
+ foreach opt $known_view_options {
+ if {[lindex $opt 1] eq "b"} {
+ set val 0
+ } else {
+ set val {}
+ }
+ set newviewopts($n,[lindex $opt 0]) $val
+ }
+ set oargs [list]
+ foreach arg $view_args {
+ if {[regexp -- {^-([0-9]+)$} $arg arg cnt]
+ && ![info exists found(limit)]} {
+ set newviewopts($n,limit) $cnt
+ set found(limit) 1
+ continue
+ }
+ catch { unset val }
+ foreach opt $known_view_options {
+ set id [lindex $opt 0]
+ if {[info exists found($id)]} continue
+ foreach pattern [lindex $opt 3] {
+ if {![string match $pattern $arg]} continue
+ if {[lindex $opt 1] ne "b"} {
+ set size [string length $pattern]
+ set val [string range $arg [expr {$size-1}] end]
+ } else {
+ set val 1
+ }
+ set newviewopts($n,$id) $val
+ set found($id) 1
+ break
+ }
+ if {[info exists val]} break
+ }
+ if {[info exists val]} continue
+ lappend oargs $arg
+ }
+ set newviewopts($n,args) [shellarglist $oargs]
+}
+
proc editview {} {
global curview
- global viewname viewperm newviewname newviewperm
- global viewargs newviewargs viewargscmd newviewargscmd
+ global viewname viewperm newviewname newviewopts
+ global viewargs viewargscmd
set top .gitkvedit-$curview
if {[winfo exists $top]} {
raise $top
return
}
- set newviewname($curview) $viewname($curview)
- set newviewperm($curview) $viewperm($curview)
- set newviewargs($curview) [shellarglist $viewargs($curview)]
- set newviewargscmd($curview) $viewargscmd($curview)
+ set newviewname($curview) $viewname($curview)
+ set newviewopts($curview,perm) $viewperm($curview)
+ set newviewopts($curview,cmd) $viewargscmd($curview)
+ decode_view_opts $curview $viewargs($curview)
vieweditor $top $curview "Gitk: edit view $viewname($curview)"
}
proc vieweditor {top n title} {
- global newviewname newviewperm viewfiles bgcolor
+ global newviewname newviewopts viewfiles bgcolor
+ global known_view_options
toplevel $top
wm title $top $title
wm transient $top .
+
+ # View name
+ frame $top.nfr
label $top.nl -text [mc "Name"]
entry $top.name -width 20 -textvariable newviewname($n)
- grid $top.nl $top.name -sticky w -pady 5
- checkbutton $top.perm -text [mc "Remember this view"] \
- -variable newviewperm($n)
- grid $top.perm - -pady 5 -sticky w
- message $top.al -aspect 1000 \
- -text [mc "Commits to include (arguments to git log):"]
- grid $top.al - -sticky w -pady 5
- entry $top.args -width 50 -textvariable newviewargs($n) \
- -background $bgcolor
- grid $top.args - -sticky ew -padx 5
-
- message $top.ac -aspect 1000 \
- -text [mc "Command to generate more commits to include:"]
- grid $top.ac - -sticky w -pady 5
- entry $top.argscmd -width 50 -textvariable newviewargscmd($n) \
- -background white
- grid $top.argscmd - -sticky ew -padx 5
-
- message $top.l -aspect 1000 \
+ pack $top.nfr -in $top -fill x -pady 5 -padx 3
+ pack $top.nl -in $top.nfr -side left -padx {0 30}
+ pack $top.name -in $top.nfr -side left
+
+ # View options
+ set cframe $top.nfr
+ set cexpand 0
+ set cnt 0
+ foreach opt $known_view_options {
+ set id [lindex $opt 0]
+ set type [lindex $opt 1]
+ set flags [lindex $opt 2]
+ set title [eval [lindex $opt 4]]
+ set lxpad 0
+
+ if {$flags eq "+" || $flags eq "*"} {
+ set cframe $top.fr$cnt
+ incr cnt
+ frame $cframe
+ pack $cframe -in $top -fill x -pady 3 -padx 3
+ set cexpand [expr {$flags eq "*"}]
+ } else {
+ set lxpad 5
+ }
+
+ if {$type eq "b"} {
+ checkbutton $cframe.c_$id -text $title -variable newviewopts($n,$id)
+ pack $cframe.c_$id -in $cframe -side left \
+ -padx [list $lxpad 0] -expand $cexpand -anchor w
+ } elseif {[regexp {^t(\d+)$} $type type sz]} {
+ message $cframe.l_$id -aspect 1500 -text $title
+ entry $cframe.e_$id -width $sz -background $bgcolor \
+ -textvariable newviewopts($n,$id)
+ pack $cframe.l_$id -in $cframe -side left -padx [list $lxpad 0]
+ pack $cframe.e_$id -in $cframe -side left -expand 1 -fill x
+ } elseif {[regexp {^t(\d+)=$} $type type sz]} {
+ message $cframe.l_$id -aspect 1500 -text $title
+ entry $cframe.e_$id -width $sz -background $bgcolor \
+ -textvariable newviewopts($n,$id)
+ pack $cframe.l_$id -in $cframe -side top -pady [list 3 0] -anchor w
+ pack $cframe.e_$id -in $cframe -side top -fill x
+ }
+ }
+
+ # Path list
+ message $top.l -aspect 1500 \
-text [mc "Enter files and directories to include, one per line:"]
- grid $top.l - -sticky w
- text $top.t -width 40 -height 10 -background $bgcolor -font uifont
+ pack $top.l -in $top -side top -pady [list 7 0] -anchor w -padx 3
+ text $top.t -width 40 -height 5 -background $bgcolor -font uifont
if {[info exists viewfiles($n)]} {
foreach f $viewfiles($n) {
$top.t insert end $f
@@ -3560,15 +3674,19 @@ proc vieweditor {top n title} {
$top.t delete {end - 1c} end
$top.t mark set insert 0.0
}
- grid $top.t - -sticky ew -padx 5
+ pack $top.t -in $top -side top -pady [list 0 5] -fill both -expand 1 -padx 3
frame $top.buts
button $top.buts.ok -text [mc "OK"] -command [list newviewok $top $n]
+ button $top.buts.apply -text [mc "Apply (F5)"] -command [list newviewok $top $n 1]
button $top.buts.can -text [mc "Cancel"] -command [list destroy $top]
+ bind $top <Control-Return> [list newviewok $top $n]
+ bind $top <F5> [list newviewok $top $n 1]
bind $top <Escape> [list destroy $top]
- grid $top.buts.ok $top.buts.can
+ grid $top.buts.ok $top.buts.apply $top.buts.can
grid columnconfigure $top.buts 0 -weight 1 -uniform a
grid columnconfigure $top.buts 1 -weight 1 -uniform a
- grid $top.buts - -pady 10 -sticky ew
+ grid columnconfigure $top.buts 2 -weight 1 -uniform a
+ pack $top.buts -in $top -side top -fill x
focus $top.t
}
@@ -3589,13 +3707,13 @@ proc allviewmenus {n op args} {
# doviewmenu $viewhlmenu 1 [list addvhighlight $n] $op $args
}
-proc newviewok {top n} {
+proc newviewok {top n {apply 0}} {
global nextviewnum newviewperm newviewname newishighlight
global viewname viewfiles viewperm selectedview curview
- global viewargs newviewargs viewargscmd newviewargscmd viewhlmenu
+ global viewargs viewargscmd newviewopts viewhlmenu
if {[catch {
- set newargs [shellsplit $newviewargs($n)]
+ set newargs [encode_view_opts $n]
} err]} {
error_popup "[mc "Error in commit selection arguments:"] $err" $top
return
@@ -3611,10 +3729,10 @@ proc newviewok {top n} {
# creating a new view
incr nextviewnum
set viewname($n) $newviewname($n)
- set viewperm($n) $newviewperm($n)
+ set viewperm($n) $newviewopts($n,perm)
set viewfiles($n) $files
set viewargs($n) $newargs
- set viewargscmd($n) $newviewargscmd($n)
+ set viewargscmd($n) $newviewopts($n,cmd)
addviewmenu $n
if {!$newishighlight} {
run showview $n
@@ -3623,7 +3741,7 @@ proc newviewok {top n} {
}
} else {
# editing an existing view
- set viewperm($n) $newviewperm($n)
+ set viewperm($n) $newviewopts($n,perm)
if {$newviewname($n) ne $viewname($n)} {
set viewname($n) $newviewname($n)
doviewmenu .bar.view 5 [list showview $n] \
@@ -3632,15 +3750,16 @@ proc newviewok {top n} {
# entryconf [list -label $viewname($n) -value $viewname($n)]
}
if {$files ne $viewfiles($n) || $newargs ne $viewargs($n) || \
- $newviewargscmd($n) ne $viewargscmd($n)} {
+ $newviewopts($n,cmd) ne $viewargscmd($n)} {
set viewfiles($n) $files
set viewargs($n) $newargs
- set viewargscmd($n) $newviewargscmd($n)
+ set viewargscmd($n) $newviewopts($n,cmd)
if {$curview == $n} {
run reloadcommits
}
}
}
+ if {$apply} return
catch {destroy $top}
}
--
1.6.0.3.15.gb8d36
^ permalink raw reply related
* [PATCH (GITK) v3 4/6] gitk: Make cherry-pick call git-citool on conflicts.
From: Alexander Gavrilov @ 2008-11-02 18:59 UTC (permalink / raw)
To: git; +Cc: Paul Mackerras
In-Reply-To: <1225652389-22082-4-git-send-email-angavrilov@gmail.com>
Now that git-gui has facilities to help users resolve
conflicts, it makes sense to launch it from other GUI
tools when they happen.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
gitk | 40 +++++++++++++++++++++++++++++++++++++++-
1 files changed, 39 insertions(+), 1 deletions(-)
diff --git a/gitk b/gitk
index f747c70..71f1b27 100755
--- a/gitk
+++ b/gitk
@@ -8110,6 +8110,32 @@ proc mkbrgo {top} {
}
}
+proc exec_citool {tool_args {baseid {}}} {
+ global commitinfo env
+
+ set save_env [array get env GIT_AUTHOR_*]
+
+ if {$baseid ne {}} {
+ if {![info exists commitinfo($baseid)]} {
+ getcommit $baseid
+ }
+ set author [lindex $commitinfo($baseid) 1]
+ set date [lindex $commitinfo($baseid) 2]
+ if {[regexp {^\s*(\S.*\S|\S)\s*<(.*)>\s*$} \
+ $author author name email]
+ && $date ne {}} {
+ set env(GIT_AUTHOR_NAME) $name
+ set env(GIT_AUTHOR_EMAIL) $email
+ set env(GIT_AUTHOR_DATE) $date
+ }
+ }
+
+ eval exec git citool $tool_args &
+
+ array unset env GIT_AUTHOR_*
+ array set env $save_env
+}
+
proc cherrypick {} {
global rowmenuid curview
global mainhead mainheadid
@@ -8128,7 +8154,19 @@ proc cherrypick {} {
# no error occurs, and exec takes that as an indication of error...
if {[catch {exec sh -c "git cherry-pick -r $rowmenuid 2>&1"} err]} {
notbusy cherrypick
- error_popup $err
+ if {[regexp -line \
+ {Entry '(.*)' would be overwritten by merge} $err msg fname]} {
+ error_popup [mc "Cherry-pick failed:
+file '%s' had local modifications.
+
+Please commit, reset or stash your changes." $fname]
+ } elseif {[regexp -line {^CONFLICT \(.*\):} $err msg]} {
+ # Force citool to read MERGE_MSG
+ file delete [file join [gitdir] "GITGUI_MSG"]
+ exec_citool {} $rowmenuid
+ } else {
+ error_popup $err
+ }
return
}
set newhead [exec git rev-parse HEAD]
--
1.6.0.3.15.gb8d36
^ permalink raw reply related
* [PATCH (GITK) v3 3/6] gitk: Add accelerators to frequently used menu commands.
From: Alexander Gavrilov @ 2008-11-02 18:59 UTC (permalink / raw)
To: git; +Cc: Paul Mackerras
In-Reply-To: <1225652389-22082-3-git-send-email-angavrilov@gmail.com>
This commit documents keyboard accelerators used for menu
commands in the menu, as it is usually done, and adds some
more, e.g. F4 to invoke Edit View.
The changes include a workaround for handling Shift-F4 on
systems where XKB binds special XF86_Switch_VT_* symbols
to Ctrl-Alt-F* combinations. Tk often receives these codes
when Shift-F* is pressed, so it is necessary to bind the
relevant actions to them as well.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
gitk | 36 +++++++++++++++++++++++++++++-------
1 files changed, 29 insertions(+), 7 deletions(-)
diff --git a/gitk b/gitk
index 41d3d2d..f747c70 100755
--- a/gitk
+++ b/gitk
@@ -1801,6 +1801,11 @@ proc setoptions {} {
# command to invoke for command, or {variable value} for radiobutton
proc makemenu {m items} {
menu $m
+ if {[tk windowingsystem] eq {aqua}} {
+ set M1T Cmd
+ } else {
+ set M1T Ctrl
+ }
foreach i $items {
set name [mc [lindex $i 1]]
set type [lindex $i 2]
@@ -1826,7 +1831,9 @@ proc makemenu {m items} {
-value [lindex $thing 1]
}
}
- eval $m add $params [lrange $i 4 end]
+ set tail [lrange $i 4 end]
+ regsub -all {\$M1T\y} $tail $M1T tail
+ eval $m add $params $tail
if {$type eq "cascade"} {
makemenu $m.$submenu $thing
}
@@ -1860,17 +1867,17 @@ proc makewindow {} {
makemenu .bar {
{mc "File" cascade {
{mc "Update" command updatecommits -accelerator F5}
- {mc "Reload" command reloadcommits}
+ {mc "Reload" command reloadcommits -accelerator $M1T-F5}
{mc "Reread references" command rereadrefs}
- {mc "List references" command showrefs}
- {mc "Quit" command doquit}
+ {mc "List references" command showrefs -accelerator F2}
+ {mc "Quit" command doquit -accelerator $M1T-Q}
}}
{mc "Edit" cascade {
{mc "Preferences" command doprefs}
}}
{mc "View" cascade {
- {mc "New view..." command {newview 0}}
- {mc "Edit view..." command editview -state disabled}
+ {mc "New view..." command {newview 0} -accelerator Shift-F4}
+ {mc "Edit view..." command editview -state disabled -accelerator F4}
{mc "Delete view" command delview -state disabled}
{xx "" separator}
{mc "All files" radiobutton {selectedview 0} -command {showview 0}}
@@ -2232,7 +2239,12 @@ proc makewindow {} {
bindkey <Key-Return> {dofind 1 1}
bindkey ? {dofind -1 1}
bindkey f nextfile
- bindkey <F5> updatecommits
+ bind . <F5> updatecommits
+ bind . <$M1B-F5> reloadcommits
+ bind . <F2> showrefs
+ bind . <Shift-F4> {newview 0}
+ catch { bind . <Shift-Key-XF86_Switch_VT_4> {newview 0} }
+ bind . <F4> edit_or_newview
bind . <$M1B-q> doquit
bind . <$M1B-f> {dofind 1 1}
bind . <$M1B-g> {dofind 1 0}
@@ -3483,6 +3495,16 @@ proc newview {ishighlight} {
vieweditor $top $nextviewnum [mc "Gitk view definition"]
}
+proc edit_or_newview {} {
+ global curview
+
+ if {$curview > 0} {
+ editview
+ } else {
+ newview 0
+ }
+}
+
proc editview {} {
global curview
global viewname viewperm newviewname newviewperm
--
1.6.0.3.15.gb8d36
^ permalink raw reply related
* [PATCH (GITK) v3 2/6] gitk: Make gitk dialog windows transient.
From: Alexander Gavrilov @ 2008-11-02 18:59 UTC (permalink / raw)
To: git; +Cc: Paul Mackerras
In-Reply-To: <1225652389-22082-2-git-send-email-angavrilov@gmail.com>
Transient windows are always kept above their parent,
and don't occupy any space in the taskbar, which is useful
for dialogs. Also, when transient is used, it is important
to bind windows to the correct parent.
This commit adds transient annotations to all dialogs,
ensures usage of the correct parent for error and
confirmation popups, and, as a side job, makes gitk
preserve the create tag dialog window in case of errors.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
gitk | 46 ++++++++++++++++++++++++++++------------------
1 files changed, 28 insertions(+), 18 deletions(-)
diff --git a/gitk b/gitk
index edef9e2..41d3d2d 100755
--- a/gitk
+++ b/gitk
@@ -1751,19 +1751,19 @@ proc show_error {w top msg} {
tkwait window $top
}
-proc error_popup msg {
+proc error_popup {msg {owner .}} {
set w .error
toplevel $w
- wm transient $w .
+ wm transient $w $owner
show_error $w $w $msg
}
-proc confirm_popup msg {
+proc confirm_popup {msg {owner .}} {
global confirm_ok
set confirm_ok 0
set w .confirm
toplevel $w
- wm transient $w .
+ wm transient $w $owner
message $w.m -text $msg -justify center -aspect 400
pack $w.m -side top -fill x -padx 20 -pady 20
button $w.ok -text [mc OK] -command "set confirm_ok 1; destroy $w"
@@ -2546,6 +2546,7 @@ proc about {} {
}
toplevel $w
wm title $w [mc "About gitk"]
+ wm transient $w .
message $w.m -text [mc "
Gitk - a commit viewer for git
@@ -2574,6 +2575,7 @@ proc keys {} {
}
toplevel $w
wm title $w [mc "Gitk key bindings"]
+ wm transient $w .
message $w.m -text "
[mc "Gitk key bindings:"]
@@ -3503,6 +3505,7 @@ proc vieweditor {top n title} {
toplevel $top
wm title $top $title
+ wm transient $top .
label $top.nl -text [mc "Name"]
entry $top.name -width 20 -textvariable newviewname($n)
grid $top.nl $top.name -sticky w -pady 5
@@ -3572,9 +3575,7 @@ proc newviewok {top n} {
if {[catch {
set newargs [shellsplit $newviewargs($n)]
} err]} {
- error_popup "[mc "Error in commit selection arguments:"] $err"
- wm raise $top
- focus $top
+ error_popup "[mc "Error in commit selection arguments:"] $err" $top
return
}
set files {}
@@ -7770,6 +7771,7 @@ proc mkpatch {} {
set patchtop $top
catch {destroy $top}
toplevel $top
+ wm transient $top .
label $top.title -text [mc "Generate patch"]
grid $top.title - -pady 10
label $top.from -text [mc "From:"]
@@ -7836,7 +7838,7 @@ proc mkpatchgo {} {
set cmd [lrange $cmd 1 end]
lappend cmd >$fname &
if {[catch {eval exec $cmd} err]} {
- error_popup "[mc "Error creating patch:"] $err"
+ error_popup "[mc "Error creating patch:"] $err" $patchtop
}
catch {destroy $patchtop}
unset patchtop
@@ -7856,6 +7858,7 @@ proc mktag {} {
set mktagtop $top
catch {destroy $top}
toplevel $top
+ wm transient $top .
label $top.title -text [mc "Create tag"]
grid $top.title - -pady 10
label $top.id -text [mc "ID:"]
@@ -7888,18 +7891,18 @@ proc domktag {} {
set id [$mktagtop.sha1 get]
set tag [$mktagtop.tag get]
if {$tag == {}} {
- error_popup [mc "No tag name specified"]
- return
+ error_popup [mc "No tag name specified"] $mktagtop
+ return 0
}
if {[info exists tagids($tag)]} {
- error_popup [mc "Tag \"%s\" already exists" $tag]
- return
+ error_popup [mc "Tag \"%s\" already exists" $tag] $mktagtop
+ return 0
}
if {[catch {
exec git tag $tag $id
} err]} {
- error_popup "[mc "Error creating tag:"] $err"
- return
+ error_popup "[mc "Error creating tag:"] $err" $mktagtop
+ return 0
}
set tagids($tag) $id
@@ -7908,6 +7911,7 @@ proc domktag {} {
addedtag $id
dispneartags 0
run refill_reflist
+ return 1
}
proc redrawtags {id} {
@@ -7946,7 +7950,7 @@ proc mktagcan {} {
}
proc mktaggo {} {
- domktag
+ if {![domktag]} return
mktagcan
}
@@ -7957,6 +7961,7 @@ proc writecommit {} {
set wrcomtop $top
catch {destroy $top}
toplevel $top
+ wm transient $top .
label $top.title -text [mc "Write commit to file"]
grid $top.title - -pady 10
label $top.id -text [mc "ID:"]
@@ -7994,7 +7999,7 @@ proc wrcomgo {} {
set cmd "echo $id | [$wrcomtop.cmd get]"
set fname [$wrcomtop.fname get]
if {[catch {exec sh -c $cmd >$fname &} err]} {
- error_popup "[mc "Error writing commit:"] $err"
+ error_popup "[mc "Error writing commit:"] $err" $wrcomtop
}
catch {destroy $wrcomtop}
unset wrcomtop
@@ -8013,6 +8018,7 @@ proc mkbranch {} {
set top .makebranch
catch {destroy $top}
toplevel $top
+ wm transient $top .
label $top.title -text [mc "Create new branch"]
grid $top.title - -pady 10
label $top.id -text [mc "ID:"]
@@ -8044,12 +8050,12 @@ proc mkbrgo {top} {
set cmdargs {}
set old_id {}
if {$name eq {}} {
- error_popup [mc "Please specify a name for the new branch"]
+ error_popup [mc "Please specify a name for the new branch"] $top
return
}
if {[info exists headids($name)]} {
if {![confirm_popup [mc \
- "Branch '%s' already exists. Overwrite?" $name]]} {
+ "Branch '%s' already exists. Overwrite?" $name] $top]} {
return
}
set old_id $headids($name)
@@ -8310,6 +8316,7 @@ proc showrefs {} {
}
toplevel $top
wm title $top [mc "Tags and heads: %s" [file tail [pwd]]]
+ wm transient $top .
text $top.list -background $bgcolor -foreground $fgcolor \
-selectbackground $selectbgcolor -font mainfont \
-xscrollcommand "$top.xsb set" -yscrollcommand "$top.ysb set" \
@@ -9637,6 +9644,7 @@ proc mkfontdisp {font top which} {
proc choosefont {font which} {
global fontparam fontlist fonttop fontattr
+ global prefstop
set fontparam(which) $which
set fontparam(font) $font
@@ -9650,6 +9658,7 @@ proc choosefont {font which} {
font create sample
eval font config sample [font actual $font]
toplevel $top
+ wm transient $top $prefstop
wm title $top [mc "Gitk font chooser"]
label $top.l -textvariable fontparam(which)
pack $top.l -side top
@@ -9766,6 +9775,7 @@ proc doprefs {} {
}
toplevel $top
wm title $top [mc "Gitk preferences"]
+ wm transient $top .
label $top.ldisp -text [mc "Commit list display options"]
grid $top.ldisp - -sticky w -pady 10
label $top.spacer -text " "
--
1.6.0.3.15.gb8d36
^ permalink raw reply related
* [PATCH (GITK) v3 1/6] gitk: Add Return and Escape bindings to dialogs.
From: Alexander Gavrilov @ 2008-11-02 18:59 UTC (permalink / raw)
To: git; +Cc: Paul Mackerras
In-Reply-To: <1225652389-22082-1-git-send-email-angavrilov@gmail.com>
It is often more convenient to dismiss or accept a
dialog using the keyboard, than by clicking buttons
on the screen. This commit adds key binding to make
it possible with gitk's dialogs.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
gitk | 21 +++++++++++++++++++++
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/gitk b/gitk
index 3fe1b47..edef9e2 100755
--- a/gitk
+++ b/gitk
@@ -1746,6 +1746,8 @@ proc show_error {w top msg} {
pack $w.ok -side bottom -fill x
bind $top <Visibility> "grab $top; focus $top"
bind $top <Key-Return> "destroy $top"
+ bind $top <Key-space> "destroy $top"
+ bind $top <Key-Escape> "destroy $top"
tkwait window $top
}
@@ -1769,6 +1771,9 @@ proc confirm_popup msg {
button $w.cancel -text [mc Cancel] -command "destroy $w"
pack $w.cancel -side right -fill x
bind $w <Visibility> "grab $w; focus $w"
+ bind $w <Key-Return> "set confirm_ok 1; destroy $w"
+ bind $w <Key-space> "set confirm_ok 1; destroy $w"
+ bind $w <Key-Escape> "destroy $w"
tkwait window $w
return $confirm_ok
}
@@ -2611,6 +2616,7 @@ proc keys {} {
-justify left -bg white -border 2 -relief groove
pack $w.m -side top -fill both -padx 2 -pady 2
button $w.ok -text [mc "Close"] -command "destroy $w" -default active
+ bind $w <Key-Escape> [list destroy $w]
pack $w.ok -side bottom
bind $w <Visibility> "focus $w.ok"
bind $w <Key-Escape> "destroy $w"
@@ -3533,6 +3539,7 @@ proc vieweditor {top n title} {
frame $top.buts
button $top.buts.ok -text [mc "OK"] -command [list newviewok $top $n]
button $top.buts.can -text [mc "Cancel"] -command [list destroy $top]
+ bind $top <Escape> [list destroy $top]
grid $top.buts.ok $top.buts.can
grid columnconfigure $top.buts 0 -weight 1 -uniform a
grid columnconfigure $top.buts 1 -weight 1 -uniform a
@@ -7793,6 +7800,8 @@ proc mkpatch {} {
frame $top.buts
button $top.buts.gen -text [mc "Generate"] -command mkpatchgo
button $top.buts.can -text [mc "Cancel"] -command mkpatchcan
+ bind $top <Key-Return> mkpatchgo
+ bind $top <Key-Escape> mkpatchcan
grid $top.buts.gen $top.buts.can
grid columnconfigure $top.buts 0 -weight 1 -uniform a
grid columnconfigure $top.buts 1 -weight 1 -uniform a
@@ -7864,6 +7873,8 @@ proc mktag {} {
frame $top.buts
button $top.buts.gen -text [mc "Create"] -command mktaggo
button $top.buts.can -text [mc "Cancel"] -command mktagcan
+ bind $top <Key-Return> mktaggo
+ bind $top <Key-Escape> mktagcan
grid $top.buts.gen $top.buts.can
grid columnconfigure $top.buts 0 -weight 1 -uniform a
grid columnconfigure $top.buts 1 -weight 1 -uniform a
@@ -7967,6 +7978,8 @@ proc writecommit {} {
frame $top.buts
button $top.buts.gen -text [mc "Write"] -command wrcomgo
button $top.buts.can -text [mc "Cancel"] -command wrcomcan
+ bind $top <Key-Return> wrcomgo
+ bind $top <Key-Escape> wrcomcan
grid $top.buts.gen $top.buts.can
grid columnconfigure $top.buts 0 -weight 1 -uniform a
grid columnconfigure $top.buts 1 -weight 1 -uniform a
@@ -8014,6 +8027,8 @@ proc mkbranch {} {
frame $top.buts
button $top.buts.go -text [mc "Create"] -command [list mkbrgo $top]
button $top.buts.can -text [mc "Cancel"] -command "catch {destroy $top}"
+ bind $top <Key-Return> [list mkbrgo $top]
+ bind $top <Key-Escape> "catch {destroy $top}"
grid $top.buts.go $top.buts.can
grid columnconfigure $top.buts 0 -weight 1 -uniform a
grid columnconfigure $top.buts 1 -weight 1 -uniform a
@@ -8138,6 +8153,7 @@ proc resethead {} {
button $w.ok -text [mc OK] -command "set confirm_ok 1; destroy $w"
pack $w.ok -side left -fill x -padx 20 -pady 20
button $w.cancel -text [mc Cancel] -command "destroy $w"
+ bind $w <Key-Escape> [list destroy $w]
pack $w.cancel -side right -fill x -padx 20 -pady 20
bind $w <Visibility> "grab $w; focus $w"
tkwait window $w
@@ -8315,6 +8331,7 @@ proc showrefs {} {
pack $top.f.l -side left
grid $top.f - -sticky ew -pady 2
button $top.close -command [list destroy $top] -text [mc "Close"]
+ bind $top <Key-Escape> [list destroy $top]
grid $top.close -
grid columnconfigure $top 0 -weight 1
grid rowconfigure $top 0 -weight 1
@@ -9666,6 +9683,8 @@ proc choosefont {font which} {
frame $top.buts
button $top.buts.ok -text [mc "OK"] -command fontok -default active
button $top.buts.can -text [mc "Cancel"] -command fontcan -default normal
+ bind $top <Key-Return> fontok
+ bind $top <Key-Escape> fontcan
grid $top.buts.ok $top.buts.can
grid columnconfigure $top.buts 0 -weight 1 -uniform a
grid columnconfigure $top.buts 1 -weight 1 -uniform a
@@ -9845,6 +9864,8 @@ proc doprefs {} {
frame $top.buts
button $top.buts.ok -text [mc "OK"] -command prefsok -default active
button $top.buts.can -text [mc "Cancel"] -command prefscan -default normal
+ bind $top <Key-Return> prefsok
+ bind $top <Key-Escape> prefscan
grid $top.buts.ok $top.buts.can
grid columnconfigure $top.buts 0 -weight 1 -uniform a
grid columnconfigure $top.buts 1 -weight 1 -uniform a
--
1.6.0.3.15.gb8d36
^ permalink raw reply related
* [PATCH (GITK) v3 0/6] Enhance popup dialogs in gitk.
From: Alexander Gavrilov @ 2008-11-02 18:59 UTC (permalink / raw)
To: git; +Cc: Paul Mackerras
This is a resend of my gitk patches rebased on top of the current
master. I also split the first patch into three parts.
Alexander Gavrilov (6):
gitk: Add Return and Escape bindings to dialogs.
gitk: Make gitk dialog windows transient.
gitk: Add accelerators to frequently used menu commands.
gitk: Make cherry-pick call git-citool on conflicts.
gitk: Implement a user-friendly Edit View dialog.
gitk: Explicitly position popup windows.
gitk | 375 +++++++++++++++++++++++++++++++++++++++++++++++++++++-------------
1 files changed, 303 insertions(+), 72 deletions(-)
^ permalink raw reply
* Re: [PATCH] git-diff: Add --staged as a synonym for --cached.
From: Björn Steinbrink @ 2008-11-02 18:54 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, Johannes Schindelin, David Symonds, git, Stephan Beyer
In-Reply-To: <7vljw2yo93.fsf@gitster.siamese.dyndns.org>
On 2008.11.02 10:30:16 -0800, Junio C Hamano wrote:
> Björn Steinbrink <B.Steinbrink@gmx.de> writes:
>
> > Looking at --cached/--index we have basically three things:
> >
> > --cached to refer to the state of the index (diff, grep, [stash], ...)
> > --cached to _work on_ the index only (rm, apply, ...)
> > --index to _work on_ both the index and the working tree (apply, ...)
>
> I think the earlier two are the same thing. The only difference between
> them is that in the first one, the definition of your "work on" happens to
> be a read-only operation. Am I mistaken?
Yeah, I actually wanted to change that "work on" to a simple "change",
but forgot to do that before sending... :-(
The idea was that currently "--cached" can be "passive" (just look at
the index instead of the working tree) or "active" (change the index
instead of the working tree). Thus there could be three "flag words",
and their usage can be unified, including stash.
"git diff [my] --staged [changes]"
"git stash [but] --keep-staged [changes]"
"git apply [and] --stage my_patch"
"git rm [but] --stage-only some_file"
OK, the last one is still not even close to a proper sentence, and but I
guess you get the idea ;-)
> > A quick look through Documentation/ revealed only one problematic case,
> > which is ls-files that already has a --stage option. And that looks like
> > a dealbreaker :-(
>
> 'ls-files' is primarily about the index contents and all else is a fluff
> ;-)
>
> You could say --show-stage-too if you wanted to, but the command is a
> plumbing to begin with, so perhaps if we can identify the cases where
> people need to use the command and enhance some Porcelain (likely
> candidate is 'status' or perhaps 'status --short') to give the information
> people use ls-files for, we hopefully wouldn't have to change ls-files
> itself at all.
>
> The only case I use ls-files these days when I am _using_ git (as opposed
> to developing/debugging git) is "git ls-files -u" to get the list of still
> unmerged paths during a conflicted merge.
Heh, that's probably the one thing for which I use "git status" the
most.
Björn
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox