* git-gui PATCH Keep repo_config(gui.recentrepos) and .gitconfig in synch
From: Christopher Beelby @ 2010-01-23 19:21 UTC (permalink / raw)
To: git
In-Reply-To: <564f37c41001231118m3f253259g8876ac4fb2b927c2@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1350 bytes --]
This patch addresses two issues:
1. When the number of recent repo's gets to ten there can be a
situation where an item is removed from the .gitconfig file via
a call to git config --unset, but the internal representation of
that file (repo_config(gui.recentrepo)) is not updated. Then a
subsequent attempt to remove an item from the list fails because
git-gui attempts to call --unset on a value that has already been
removed. This leads to duplicates in the .gitconfig file, which
then also cause errors if the git-gui tries to --unset them (rather
than using --unset-all. --unset-all is not used because it is not
expected that duplicates should ever be allowed to exist.)
For complete step-by-step instructions on how to cause these situations
in git-gui see my comment on the msysgit project at
http://code.google.com/p/msysgit/issues/detail?id=362&colspec=ID%20Type%20Status%20Priority%20Component%20Owner%20Summary#c9
2. When loading the list of recent repositories (proc _get_recentrepos)
if a repo in the list is not considered a valid git reposoitory
then we should go ahead and remove it so it doesn't take up a slot
in the list (since we limit to 10 items). This will prevent a bunch of
invalid entries in the list (which are not shown) from making valid
entries dissapear off the list even when there are less than ten valid
entries.
[-- Attachment #2: patch1.patch --]
[-- Type: application/octet-stream, Size: 875 bytes --]
diff --git a/git-gui/lib/choose_repository.tcl b/git-gui/lib/choose_repository.tcl
index 633cc57..3f8f303 100644
--- a/git-gui/lib/choose_repository.tcl
+++ b/git-gui/lib/choose_repository.tcl
@@ -235,6 +235,8 @@ proc _get_recentrepos {} {
foreach p [get_config gui.recentrepo] {
if {[_is_git [file join $p .git]]} {
lappend recent $p
+ } else {
+ _unset_recentrepo $p
}
}
return [lsort $recent]
@@ -243,6 +245,7 @@ proc _get_recentrepos {} {
proc _unset_recentrepo {p} {
regsub -all -- {([()\[\]{}\.^$+*?\\])} $p {\\\1} p
git config --global --unset gui.recentrepo "^$p\$"
+ load_config 1
}
proc _append_recentrepos {path} {
@@ -261,6 +264,7 @@ proc _append_recentrepos {path} {
lappend recent $path
git config --global --add gui.recentrepo $path
+ load_config 1
while {[llength $recent] > 10} {
_unset_recentrepo [lindex $recent 0]
^ permalink raw reply related
* Re: [PATCH] If deriving SVN_SSH from GIT_SSH on msys, also add quotes
From: Junio C Hamano @ 2010-01-23 19:33 UTC (permalink / raw)
To: Sebastian Schuberth
Cc: Sverre Rabbelier, git, Eric Wong, Johannes Schindelin, jugg
In-Reply-To: <4B5B05AC.2050200@gmail.com>
Sebastian Schuberth <sschuberth@gmail.com> writes:
> In contrast to GIT_SSH, SVN_SSH requires quotes for paths that contain
> spaces. As GIT_SSH will not work if it contains quotes, it is safe to
> assume it never contains quotes. Also, adding quotes to SVN_SSH for paths
> that do not contain spaces does no harm. So we always add quotes when
> deriving SVN_SSH from GIT_SSH.
>
> This fixes msysGit issue 385, see
> http://code.google.com/p/msysgit/issues/detail?id=385
>
> Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
As the patch clearly is inside "msys-only" codepath, I don't mind
bypassing Eric and apply this directly to my tree before I tag 1.7.0-rc0,
but may I ask why this quoting magic matters only on msys?
> ---
> git-svn.perl | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/git-svn.perl b/git-svn.perl
> index 650c9e5..ef39a9f 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -26,6 +26,7 @@ if (! exists $ENV{SVN_SSH}) {
> $ENV{SVN_SSH} = $ENV{GIT_SSH};
> if ($^O eq 'msys') {
> $ENV{SVN_SSH} =~ s/\\/\\\\/g;
> + $ENV{SVN_SSH} =~ s/(.*)/"$1"/;
> }
> }
> }
> --
> 1.6.6.265.ga0f40
^ permalink raw reply
* Re: [PATCH v2 1/2] user-manual: general quoting improvements (p1)
From: Daniel @ 2010-01-23 19:52 UTC (permalink / raw)
To: git, Felipe Contreras; +Cc: Nanako Shiraishi, Junio C Hamano, Felipe Contreras
In-Reply-To: <1264205935-19203-2-git-send-email-felipe.contreras@gmail.com>
> This standarizes the way quotes are handled following semantic rules,
> that make the final text easier to read.
>
> Here are the general rules:
>
> * A command (something that the user must type), goes in backticks. So
> that the final text appears in monospaced text. e.g. `git clone
> <repo>`
>
> * A common concept (or git lingo), also goes in backticks. So that it
> appears uniquely different from the rest of the text. e.g. `HEAD`
>
> * An example (something that can be easily replaced), goes into
> typewriter quotes. The final text is not formatted further, so they
> still appear as typewriter quotes. e.g. "linux-2.6"
>
> * A text that can be confused with normal text also goes into
> typewriter quotes. e.g. "path/to/file" "A"
>
> * Text that needs to be emphasized goes in single typewriter quotes. So
> that it's not confused as normal text. e.g. we often just use the
> term 'branch'.
>
> * Something that needs proper quotation goes into proper double quotes.
> So that it gets a dramatic effect, as in sombody is using his four
> quoting fingers. e.g. ``the index''
>
> * Something that needs strong emphasis so that the reader can't
> possibly miss it goes enclosed in asterisks. e.g. *not* tracking
>
> These rules are not automatic, which one to use depends on the context,
> and often they can be used together. For example, consider this:
>
> The branch 'test' is short for '"refs/heads/test"'
>
> In this case we want to highligh 'test' and 'refs/heads/test' so they go
> in single typewriter quotes, but also, we want to make clear the full
> refname is not confused as multiple words, so it goes inside double
> typewriter quotes.
>
> Also, sometimes a text can be both a command, and an example, but only
> one quoting format must be chosen.
>
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Maybe [regardless of its meritorical corectness) this is worth putting
in a separate file in Documentation/ so that people sending patches to
documentation will at least have a chance to read quoting rules and not
use quotes randomly.
-- Daniel
^ permalink raw reply
* Re: [RFC PATCH 00/10] gitweb: Simple file based output caching
From: J.H. @ 2010-01-23 19:55 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, John 'Warthog9' Hawley
In-Reply-To: <cover.1264198194.git.jnareb@gmail.com>
Just a heads up I wasn't able to get to these yesterday (Friday), but
I'll try and work in looking these over come Monday.
- John 'Warthog9' Hawley
On 01/22/2010 04:27 PM, Jakub Narebski wrote:
> This 10 patches long patch series is intended as proof of concept
> for splitting large 'gitweb: File based caching layer (from git.kernel.org)'
> mega-patch by John 'Warthog9' Hawley aka J.H., by starting small and
> adding features piece by piece.
>
> This patch is meant as replacement for last two patches:
> * [PATCH 8/9] gitweb: Convert output to using indirect file handle
> Message-ID: <1263432185-21334-9-git-send-email-warthog9@eaglescrag.net>
> * [PATCH 9/9] gitweb: File based caching layer (from git.kernel.org)
> Message-ID: <1263432185-21334-10-git-send-email-warthog9@eaglescrag.net>
>
> in the long patch series by J.H.
> * [PATCH 0/9] Gitweb caching v5
> http://thread.gmane.org/gmane.comp.version-control.git/136913
>
> Note that this patch series is part of 'gitweb/cache-kernel' branch of
> http://repo.or.cz/w/git/jnareb-git.git repository (gitweb link), built
> on top of modified patches from 'Gitweb caching v2' series (from
> 'gitweb-ml-v2' branch of http://git.kernel.org/?p=git/warthog9/gitweb.git
> repository). Therefore they might not apply as straight replacements
> on top of early parts of 'gitweb-ml-v5' branch.
>
> This is work in progress (showing how I see introducing output caching
> to gitweb), it lacks proper documentation (POD for gitweb/cache.pm,
> new configuration variables in gitweb/README, perhaps "Gitweb caching"
> section in gitweb/README and gitweb/cache.pm mentioned in gitweb/INSTALL),
> and commits/patches marked '(WIP)' lacks proper commit message.
>
> Just food for thought...
>
> Table of contents:
> ~~~~~~~~~~~~~~~~~~
> [RFC PATCH 01/10] gitweb: Print to explicit filehandle (preparing
> for caching)
> [RFC PATCH 02/10] gitweb: href(..., -path_info => 0|1)
> [RFC PATCH 03/10] gitweb/cache.pm - Very simple file based caching
> [RFC PATCH 04/10] gitweb/cache.pm - Stat-based cache expiration
> [RFC PATCH 05/10] gitweb: Use Cache::Cache compatibile (get, set)
> output caching (WIP)
> [RFC PATCH 06/10] gitweb/cache.pm - Adaptive cache expiration time (WIP)
> [RFC PATCH 07/10] gitweb: Use CHI compatibile (compute method) caching (WIP)
> [RFC PATCH 08/10] gitweb/cache.pm - Use locking to avoid 'stampeding herd'
> problem (WIP)
> [RFC PATCH 09/10] gitweb/cache.pm - Serve stale data when waiting for
> filling cache (WIP)
> [RFC PATCH 10/10] gitweb: Show appropriate "Generating..." page when
> regenerating cache (WIP)
>
>
> Diffstat:
> ~~~~~~~~~
>
> gitweb/cache.pm | 566 ++++++++++
> gitweb/gitweb.perl | 1923 +++++++++++++++++---------------
> t/gitweb-lib.sh | 2 +
> t/t9500-gitweb-standalone-no-errors.sh | 13 +
> t/t9503-gitweb-caching.sh | 32 +
> t/t9503/test_cache_interface.pl | 195 ++++
> t/test-lib.sh | 3 +
> 7 files changed, 1836 insertions(+), 898 deletions(-)
> create mode 100644 gitweb/cache.pm
> create mode 100755 t/t9503-gitweb-caching.sh
> create mode 100755 t/t9503/test_cache_interface.pl
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2010, #07; Fri, 22)
From: Junio C Hamano @ 2010-01-23 20:03 UTC (permalink / raw)
To: Jens Lehmann; +Cc: git
In-Reply-To: <4B5B25C6.70604@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
> A patch that teaches "git diff --submodule" to display if the submodule
> contains new untracked and/or modified files is also almost ready.
How does "git submodule summary" show them? If it doesn't, then I don't
think we would want to show them, either, as my understanding is that a
longer-term plan is to use "diff --submodule" in git-gui to replace it.
> Would
> you consider it for inclusion into 1.7.0 too or shall i wait until after
> the release?
If a feature is not in 'master' already, I think it is too late to be
included in 1.7.0, if that is what you are asking. But if you start the
usual cycle of working on, asking others to review and polishing it before
the release, it would give us better designed and more tested version in
1.7.1, no?
> diff --git a/diff-lib.c b/diff-lib.c
> index ec2e2ac..e896b9c 100644
> --- a/diff-lib.c
> +++ b/diff-lib.c
> @@ -161,7 +161,10 @@ int run_diff_files(struct rev_info *revs, unsigned int option)
> continue;
> }
>
> - if ((ce_uptodate(ce) && !S_ISGITLINK(ce->ce_mode)) || ce_skip_worktree(ce))
> + if ((ce_uptodate(ce)
> + && (!S_ISGITLINK(ce->ce_mode)
> + || DIFF_OPT_TST(&revs->diffopt, IGNORE_SUBMODULES)))
> + || ce_skip_worktree(ce))
> continue;
I think this is sensible; the frontend knows that it doesn't care about submodules.
> @@ -179,6 +182,7 @@ int run_diff_files(struct rev_info *revs, unsigned int option)
> }
> changed = ce_match_stat(ce, &st, ce_option);
> if (S_ISGITLINK(ce->ce_mode)
> + && !DIFF_OPT_TST(&revs->diffopt, IGNORE_SUBMODULES)
> && (!changed || (revs->diffopt.output_format & DIFF_FORMAT_PATCH))
> && is_submodule_modified(ce->name)) {
> changed = 1;
Likewise, but with one "hmph". This codepath deals with a path that is a
submodule in the index (the work tree may still have submodule, removed
it, or replaced it with a regular file). However, in the codepath that
follows this up to the call to diff_change(), is_submodule_modified() is
not called if the work tree has a submodule in a path that used to be
something else. Do we want one?
> @@ -220,7 +224,7 @@ static int get_stat_data(struct cache_entry *ce,
> const unsigned char **sha1p,
> unsigned int *modep,
> int cached, int match_missing,
> - unsigned *dirty_submodule, int output_format)
> + unsigned *dirty_submodule, struct diff_options *diffopt)
> {
> const unsigned char *sha1 = ce->sha1;
> unsigned int mode = ce->ce_mode;
Below the context of this hunk, we seem to do this:
if (!cached && !ce_uptodate(ce)) {
...
if gitlink then call is_submodule_modified()
}
But isn't it inconsistent with hunk at the beginning of this patch (ll 161-170)
that essentially says "entries that is ce_uptodate() is Ok, but if it is a
gitlink we need to look deeper"? Why isn't this function looking deeper
even when we see that the submodule entry is ce_uptodate()?
Side note: the lack of ce_skip_worktree() check is Ok. The callers of
get_stat_data() are show_new_file() and show_mododified() but they are
never called from their sole caller, do_oneway_diff(), on a skipped
worktree entry.
> @@ -241,7 +245,8 @@ static int get_stat_data(struct cache_entry *ce,
> }
> changed = ce_match_stat(ce, &st, 0);
> if (S_ISGITLINK(ce->ce_mode)
> - && (!changed || (output_format & DIFF_FORMAT_PATCH))
> + && !DIFF_OPT_TST(diffopt, IGNORE_SUBMODULES)
> + && (!changed || (diffopt->output_format & DIFF_FORMAT_PATCH))
> && is_submodule_modified(ce->name)) {
> changed = 1;
> *dirty_submodule = 1;
This hunk by itself is Ok, but I am still puzzled about a case where you
have "seemingly clean because ce_uptodate() says so, but submodule work
tree or index might be dirty" case, in which this code won't trigger.
^ permalink raw reply
* Re: [PATCH] Handle double slashes in make_relative_path()
From: Junio C Hamano @ 2010-01-23 20:04 UTC (permalink / raw)
To: Johannes Sixt
Cc: Robin Rosenberg, Junio C Hamano, Thomas Rast, git, Linus Torvalds
In-Reply-To: <201001231409.30706.j6t@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
> On Samstag, 23. Januar 2010, Robin Rosenberg wrote:
>> It seems this function does something unhealthy when you pass a path of the
>> form //server/share. On windows dropping the double // at the beginning
>> makes it a different path since // is the UNC prefix.
>
> There is no problem in practice.
>
> The function returns either the input unmodified, or it strips also at least
> one directory component, except when base is only "/" (or "//" or "///"...).
> I said in practice, because on Windows it does not make sense to invoke git
> with (literally)
>
> git --git-dir=//server/share/repo.git --work-tree=/ ...
>
> i.e., without a drive prefix before the slash of --work-tree.
If you did this:
git --git-dir=//reposerver/repo.git --work-tree=//buildserver/workarea
then we would say "one is not a prefix of the other", so it would be
fine. At least I don't think the "recover from unintentionally doubled
slashes in user supplied path" fix is introducing any new problem in that
case.
If on the other hand, if you did this:
git --git-dir=//server/repo.git --work-tree=//server/workarea
that also would be Ok.
I think one issue is what happens when you did this:
cd //server
git --git-dir=//server/repo/repo.git --work-tree=repo
Does msysgit implementation figures out that the work tree is located at
"//server/repo" when get_git_work_tree() is asked to produce an absolute
path so that it can be compared with //server/repo/repo.git with the code?
If it does (with the leading double slash), then "doubled slahses fix" is
a regression we should do something about it. If it doesn't, then it
probably doesn't matter.
^ permalink raw reply
* Re: [PATCH] Documentation: rev-list: fix synopsys for --tags and and --remotes
From: Junio C Hamano @ 2010-01-23 20:04 UTC (permalink / raw)
To: Christian Couder; +Cc: git, Ilari Liusvaara, Johannes Sixt
In-Reply-To: <20100123072627.6509.86297.chriscool@tuxfamily.org>
I had to stare at lines before and after the change for two minutes to
notice what is being fixed ;-).
Good eyes; thanks.
^ permalink raw reply
* Re: [PATCH] Documentation: rev-list: fix synopsys for --tags and and --remotes
From: Sverre Rabbelier @ 2010-01-23 20:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Christian Couder, git, Ilari Liusvaara, Johannes Sixt
In-Reply-To: <7vr5pgbnbb.fsf@alter.siamese.dyndns.org>
Heya,
On Sat, Jan 23, 2010 at 21:04, Junio C Hamano <gitster@pobox.com> wrote:
> I had to stare at lines before and after the change for two minutes to
> notice what is being fixed ;-).
To save others the time: the = signs were moved to inside the brackets
where they belong, since the old documentation says that --tags= is a
valid argument.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] If deriving SVN_SSH from GIT_SSH on msys, also add quotes
From: Sebastian Schuberth @ 2010-01-23 20:11 UTC (permalink / raw)
To: Junio C Hamano
Cc: Sverre Rabbelier, git, Eric Wong, Johannes Schindelin, jugg
In-Reply-To: <7vd410d3as.fsf@alter.siamese.dyndns.org>
On Sat, Jan 23, 2010 at 20:33, Junio C Hamano <gitster@pobox.com> wrote:
>> This fixes msysGit issue 385, see
>> http://code.google.com/p/msysgit/issues/detail?id=385
>>
>> Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
>
> As the patch clearly is inside "msys-only" codepath, I don't mind
> bypassing Eric and apply this directly to my tree before I tag 1.7.0-rc0,
> but may I ask why this quoting magic matters only on msys?
To be honest, I'm not exactly sure why this is required. Maybe the SVN
Perl module does some different path mangling than a normal MSYS SVN
binary would do. We're already setting SVN_SSH like this (that is,
using double-backslashes and quotes) in the msysGit installer, see the
discussion at [1]. This patch basically just does the same thing for
people that initially chose to not modify the environment during the
msysGit installation, but later change GIT_SSH manually, and forget to
set SVN_SSH, too.
[1] http://code.google.com/p/msysgit/issues/detail?id=305#c8
--
Sebastian Schuberth
^ permalink raw reply
* Re: [PATCH] Handle double slashes in make_relative_path()
From: Junio C Hamano @ 2010-01-23 20:14 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Sixt, Robin Rosenberg, Thomas Rast, git, Linus Torvalds
In-Reply-To: <7vwrz8bnbj.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I think one issue is what happens when you did this:
>
> cd //server
> git --git-dir=//server/repo/repo.git --work-tree=repo
>
> Does msysgit implementation figures out that the work tree is located at
> "//server/repo" when get_git_work_tree() is asked to produce an absolute
> path so that it can be compared with //server/repo/repo.git with the code?
> If it does (with the leading double slash), then "doubled slahses fix" is
> a regression we should do something about it. If it doesn't, then it
> probably doesn't matter.
Nah, I wasn't thinking straight. What happens if you did this?
git --git-dir=//git/repo/repo.git --work-tree=/git/repo
where "//git/repo" is on the "git server" and you are working in local
hierarchy "/git/repo"?
^ permalink raw reply
* Re: [PATCH] Handle double slashes in make_relative_path()
From: Johannes Sixt @ 2010-01-23 20:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Robin Rosenberg, Thomas Rast, git, Linus Torvalds
In-Reply-To: <7viqasbmtc.fsf@alter.siamese.dyndns.org>
On Samstag, 23. Januar 2010, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
> > I think one issue is what happens when you did this:
> >
> > cd //server
> > git --git-dir=//server/repo/repo.git --work-tree=repo
> >
> > Does msysgit implementation figures out that the work tree is located at
> > "//server/repo" when get_git_work_tree() is asked to produce an absolute
> > path so that it can be compared with //server/repo/repo.git with the
> > code? If it does (with the leading double slash), then "doubled slahses
> > fix" is a regression we should do something about it. If it doesn't,
> > then it probably doesn't matter.
>
> Nah, I wasn't thinking straight. What happens if you did this?
>
> git --git-dir=//git/repo/repo.git --work-tree=/git/repo
>
> where "//git/repo" is on the "git server" and you are working in local
> hierarchy "/git/repo"?
Ah, right, this would not do the right thing. (But I can't verify this claim
right now.)
The problem is that /git/repo without a drive prefix is a valid path and it
means the path that begins at the same drive that CWD currently is. I would
not dismiss this form of paths as too exotic, so we should care about them.
OTOH, it can be worked around easily by the user (just insert the drive
prefix). Dunno...
-- Hannes
^ permalink raw reply
* Re: [PATCH] Handle double slashes in make_relative_path()
From: Sverre Rabbelier @ 2010-01-23 21:01 UTC (permalink / raw)
To: Johannes Sixt
Cc: Junio C Hamano, Robin Rosenberg, Thomas Rast, git, Linus Torvalds
In-Reply-To: <201001232141.49556.j6t@kdbg.org>
Heya,
On Sat, Jan 23, 2010 at 21:41, Johannes Sixt <j6t@kdbg.org> wrote:
> OTOH, it can be worked around easily by the user (just insert the drive
> prefix). Dunno...
I think it's preferable to keep the old behavior where we fail if the
user gives us an invalid argument, rather than fix a user error and
break on a a valid argument instead. I think we should be correct
first, and try and fix incorrect user behavior after.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Modern Git GUI
From: André Harms @ 2010-01-23 21:40 UTC (permalink / raw)
To: git
Hi,
I know there are several GUIs out there for Git. They are all
functional and most of them can be used in the daily work with Git.
In my opinion one thing combines them: they aren't very pretty.
I currently prefer the CLI to work with Git because it's quick and I
am happy with it. But I think there are people out there, who don't
want to use the command-line because they are afraid of doing
something wrong or anything like this. Additionally the CLI and
unattractive GUIs are barriers to people who are not familar with a
SCM-system.
So I thought about developing a new kind of GUI for Git that looks
modern and attractive (you know... some eye-candy stuff) and that is
easy to use. In addition I thought about a built-in console (like we
know it from first person shooters) so that also people who prefer the
CLI might use this GUI application too.
Is there anybody who agrees or disagrees? I really would appreciate
some feedback about that idea.
P.S.:
Normally I come up with such ideas to the public and ask what others
think about it when I have some mockups. I am sorry that I haven't any
right now.
^ permalink raw reply
* [PATCH (resend 3)] git gui: Use git diff --submodule when available
From: Jens Lehmann @ 2010-01-23 22:04 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Git Mailing List
The necessary feature is present since 1.6.6, it would be good
to have this patch in the next release (see numbers below).
Shawn, This is a third re-send, in case you missed the previous
rounds. Thanks.
-- >8 --
Subject: [PATCH] git gui: Use git diff --submodule when available
Doing so is much faster and gives the same output. Here are some
numbers:
time git submodule summary
<snip>
real 0m0.219s
user 0m0.050s
sys 0m0.111s
time git diff --submodule
<snip>
real 0m0.012s
user 0m0.003s
sys 0m0.009s
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.1.558.gc20e6.dirty
^ permalink raw reply related
* [PATCH] Documentation: add missing :: in config.txt
From: Thomas Rast @ 2010-01-23 22:13 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
bed575e (commit: support commit.status, --status, and --no-status,
2009-12-07) forgot to add the :: that sets off an item from the
paragraph that explains it, breaking the layout.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
[I'm merely sending this out because I stumbled over it. All the mail
Cced to me unfortunately has to wait till tomorrow.]
Documentation/config.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 8dcb191..17901e2 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -716,7 +716,7 @@ color.ui::
terminal. When more specific variables of color.* are set, they always
take precedence over this setting. Defaults to false.
-commit.status
+commit.status::
A boolean to enable/disable inclusion of status information in the
commit message template when using an editor to prepare the commit
message. Defaults to true.
--
1.6.6.1.577.gf1430
^ permalink raw reply related
* [PATCH] Documentation: move away misplaced 'push --upstream' description
From: Thomas Rast @ 2010-01-23 22:18 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
e9fcd1e (Add push --set-upstream, 2010-01-16) inadvertently patched
the description of --upstream in the middle of that of --repo.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
[And this, too.]
Documentation/git-push.txt | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index c63932b..73a921c 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -122,13 +122,6 @@ nor in any Push line of the corresponding remotes file---see below).
the name "origin" is used. For this latter case, this option
can be used to override the name "origin". In other words,
the difference between these two commands
-
--u::
---set-upstream::
- For every branch that is up to date or successfully pushed, add
- upstream (tracking) reference, used by argument-less
- linkgit:git-pull[1] and other commands. For more information,
- see 'branch.<name>.merge' in linkgit:git-config[1].
+
--------------------------
git push public #1
@@ -139,6 +132,13 @@ is that #1 always pushes to "public" whereas #2 pushes to "public"
only if the current branch does not track a remote branch. This is
useful if you write an alias or script around 'git push'.
+-u::
+--set-upstream::
+ For every branch that is up to date or successfully pushed, add
+ upstream (tracking) reference, used by argument-less
+ linkgit:git-pull[1] and other commands. For more information,
+ see 'branch.<name>.merge' in linkgit:git-config[1].
+
--thin::
--no-thin::
These options are passed to 'git send-pack'. Thin
--
1.6.6.1.577.gf1430
^ permalink raw reply related
* Re: [PATCH] git-gui: handle really long error messages in updateindex.
From: Shawn O. Pearce @ 2010-01-23 22:23 UTC (permalink / raw)
To: Pat Thoyts; +Cc: git, msysgit
In-Reply-To: <87bphqui9t.fsf@users.sourceforge.net>
Pat Thoyts <patthoyts@users.sourceforge.net> wrote:
> As reported to msysGit (bug #340) it is possible to get some very long
> error messages when updating the index. The use of a label to display
> this prevents scrolling the output. This patch replaces the label with
> a scrollable text widget configured to look like a label.
>
> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
> ---
> lib/index.tcl | 34 ++++++++++++++++++----------------
> 1 files changed, 18 insertions(+), 16 deletions(-)
Thanks, applied.
--
Shawn.
^ permalink raw reply
* Re: [PATCH (resend 3)] git gui: Use git diff --submodule when available
From: Shawn O. Pearce @ 2010-01-23 22:34 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Git Mailing List
In-Reply-To: <4B5B725C.6060301@web.de>
Jens Lehmann <Jens.Lehmann@web.de> wrote:
> The necessary feature is present since 1.6.6, it would be good
> to have this patch in the next release (see numbers below).
>
> Shawn, This is a third re-send, in case you missed the previous
> rounds. Thanks.
I didn't miss them, I just was ignoring git-gui patches for a while.
I only work on git-gui in short spurts.
I actually just applied a modified version of your patch, so diff
on submodules still works via submodule summary if git < 1.6.6.
--
Shawn.
^ permalink raw reply
* Re: git-gui PATCH Keep repo_config(gui.recentrepos) and .gitconfig in synch
From: Shawn O. Pearce @ 2010-01-23 22:39 UTC (permalink / raw)
To: Christopher Beelby; +Cc: git
In-Reply-To: <564f37c41001231121o10f88b6cwc35a126a0e79d3fc@mail.gmail.com>
Christopher Beelby <chris@celabs.com> wrote:
> This patch addresses two issues:
Thanks, applied. In the future please follow the SubmittingPatches
guidelines, which includes sending the patch inline in your message
using the formatting created by `git format-patch`.
--
Shawn.
^ permalink raw reply
* Re: [GIT-GUI PATCH] Correctly launch gitk for branch whose name matches a local file
From: Shawn O. Pearce @ 2010-01-23 22:41 UTC (permalink / raw)
To: Peter Krefting; +Cc: Git Mailing List
In-Reply-To: <20100121121848.BE37D2FC47@perkele>
Peter Krefting <peter@softwolves.pp.se> wrote:
> When trying to run gitk on a branch name whose name matches a local file,
> it will toss an error saying that the name is ambiguous. Adding a pair
> of dashes will make gitk parse the options to the left of it as branch
> names. Since wish eats the first pair of dashes we throw at it, we need
> to add a second one to ensure they get through.
>
> Signed-off-by: Peter Krefting <peter@softwolves.pp.se>
> ---
> git-gui.sh | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Thanks, applied.
--
Shawn.
^ permalink raw reply
* Re: [PATCH (resend 3)] git gui: Use git diff --submodule when available
From: Jens Lehmann @ 2010-01-23 22:42 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Git Mailing List
In-Reply-To: <20100123223458.GB12679@spearce.org>
Am 23.01.2010 23:34, schrieb Shawn O. Pearce:
> I actually just applied a modified version of your patch, so diff
> on submodules still works via submodule summary if git < 1.6.6.
One caveat: This will only work in versions 1.6.4 and above, as i
had to add the --files option to git submodule summary to make it
work.
^ permalink raw reply
* Re: [PATCH] git-gui: Unstaging a partly staged entry didn't update file_states correctly
From: Shawn O. Pearce @ 2010-01-23 22:43 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <4B1D672F.3030805@web.de>
Jens Lehmann <Jens.Lehmann@web.de> wrote:
> When unstaging a partly staged file or submodule, the file_states list
> was not updated properly (unless unstaged linewise). Its index_info part
> did not contain the former head_info as it should have but kept its old
> value.
>
> This seems not to have had any bad effects but diminishes the value of
> the file_states list for future enhancements.
>
> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
> ---
Thanks, applied.
--
Shawn.
^ permalink raw reply
* [PATCH] Documentation: merge: use MERGE_HEAD to refer to the remote branch
From: Jonathan Nieder @ 2010-01-23 22:48 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Junio C Hamano
In-Reply-To: <201001101324.47025.trast@student.ethz.ch>
commit 57bddb11 (Documentation/git-merge: reword references to
"remote" and "pull", 2010-01-07) fixed the manual to drop the
assumption that the other branch being merged is from a remote
repository. Unfortunately, in a few places, to do so it
introduced the antecedentless phrase "their versions". Worse, in
passages like the following, 'they' is playing two roles.
| highlighting changes from both the HEAD and their versions.
|
| * Look at the diffs on their own. 'git log --merge -p <path>'
Using HEAD and MERGE_HEAD nicely assigns terminology to "our" and
"their" sides. It also provides the reader with practice using
names that git will recognize on the command line.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Thomas Rast wrote:
> Jonathan Nieder wrote:
>> Maybe:
>>
>> | * Look at the diffs. 'git diff' will show a three-way diff,
>> | highlighting changes from both the HEAD and MERGE_HEAD
>> | versions.
>
> I like this idea, as it nicely assigns terminology to the "their"
> side. We need to explain MERGE_HEAD (it's not in the manpage yet),
> but that should fit in somewhere.
Here is a try. This applies on top of the series to clarify 'git
merge' documentation [1] I sent earlier today, which conveniently
enough explains MERGE_HEAD a few sections earlier.
Thanks for the encouragement,
Jonathan
[1] http://thread.gmane.org/gmane.comp.version-control.git/137818
Documentation/git-merge.txt | 14 ++++++++------
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index 7aa3f3f..4b1b2f5 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -215,15 +215,17 @@ You can work through the conflict with a number of tools:
mergetool which will work you through the merge.
* Look at the diffs. `git diff` will show a three-way diff,
- highlighting changes from both the HEAD and their versions.
+ highlighting changes from both the `HEAD` and `MERGE_HEAD`
+ versions.
- * Look at the diffs on their own. `git log --merge -p <path>`
- will show diffs first for the HEAD version and then
- their version.
+ * Look at the diffs from each branch. `git log --merge -p <path>`
+ will show diffs first for the `HEAD` version and then the
+ `MERGE_HEAD` version.
* Look at the originals. `git show :1:filename` shows the
- common ancestor, `git show :2:filename` shows the HEAD
- version and `git show :3:filename` shows their version.
+ common ancestor, `git show :2:filename` shows the `HEAD`
+ version, and `git show :3:filename` shows the `MERGE_HEAD`
+ version.
EXAMPLES
--
1.6.6
^ permalink raw reply related
* Re: [PATCH 2/2] git-gui: Add a special diff popup menu for submodules
From: Shawn O. Pearce @ 2010-01-23 22:57 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Git Mailing List
In-Reply-To: <4B3F7B49.2030100@web.de>
Jens Lehmann <Jens.Lehmann@web.de> wrote:
> To make it easier for users to deal with submodules, a special diff popup
> menu has been added for submodules. The "Show Less Context" and "Show More
> Context" entries have been removed, as they don't make any sense for a
> submodule summary. Four new entries are added to the top of the popup menu
> to gain access to more detailed information about the changes in a
> submodule than the plain summary does offer. These are:
> - "Visualize These Changes In The Submodule"
> starts gitk showing the selected commit range
> - "Visualize These Changes In The Submodule"
> starts gitk showing the whole submodule history of the current branch
> - "Visualize All Branch History In The Submodule"
> starts gitk --all in the submodule
> - "Start git gui In The Submodule"
> guess what :-)
>
> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
> ---
> git-gui/git-gui.sh | 127 +++++++++++++++++++++++++++++++++++++++++++++-------
> 1 files changed, 110 insertions(+), 17 deletions(-)
Thanks, applied.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 2/2] Make it possible to apply a range of changes at once
From: Shawn O. Pearce @ 2010-01-23 23:05 UTC (permalink / raw)
To: jepler; +Cc: git, Heiko Voigt, Peter Baumann
In-Reply-To: <1260231763-19194-3-git-send-email-jepler@unpythonic.net>
jepler@unpythonic.net wrote:
> From: Jeff Epler <jepler@unpythonic.net>
>
> Signed-off-by: Jeff Epler <jepler@unpythonic.net>
> ---
> git-gui.sh | 15 +++-
> lib/diff.tcl | 242 ++++++++++++++++++++++++++++++++++------------------------
> 2 files changed, 153 insertions(+), 104 deletions(-)
Thanks, applied.
--
Shawn.
^ 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