* Re: TopGit release?
From: Bert Wesarg @ 2010-12-15 14:54 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Peter Simons, git, martin f krafft, Per Cederqvist, Olaf Dabrunz,
Thomas Moschny
In-Reply-To: <20101215080148.GA28971@pengutronix.de>
2010/12/15 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:
> Hello,
>
> On Tue, Dec 14, 2010 at 07:37:50PM +0100, Peter Simons wrote:
>> I was wondering whether there's a chance that we'll have a new release
>> of TopGit in the foreseeable future? Version 0.8 seems to be quite old
>> by now, but still there's no observable progress in getting a new
>> version tagged. Is this project still alive?
> There are a few patches pending, but I currently don't find the time to
> go through and apply them[1]. Moreover I hardly use topgit anymore.
> So if someone with interest in topgit wants to step forward to help this
> would be very appreciated.
>
> Best regards
> Uwe
>
> [1] http://thread.gmane.org/gmane.comp.version-control.git/159433
> hint to Bert: this series doesn't apply to master
I know, you applied a patch, which was rendered obsolete with this
patch series. you commited on Nov 02, and I send the series Oct 20.
Bert
> --
> Pengutronix e.K. | Uwe Kleine-König |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
>
^ permalink raw reply
* Re: [PATCH] completion: add missing configuration variables
From: Jeff King @ 2010-12-15 13:00 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: git, Junio C Hamano
In-Reply-To: <1292395613-12859-1-git-send-email-martin.von.zweigbergk@gmail.com>
On Wed, Dec 15, 2010 at 07:46:53AM +0100, Martin von Zweigbergk wrote:
> The color.grep.external option has been deleted. Should it be deleted
> from here or do we want to help users run e.g.
> 'git config --unset color.grep.external'? Same goes for
> add.ignore-errors.
IMHO, they should go away. People who have them can figure out how to
delete them, but it is more important not to advertise them to people
who are adding variables.
As an aside, I would think "--unset" should actually choose from the set
of configured variables for completion (i.e., "git config --list | cut
-d= -f1"). But that would obviously be a separate patch.
> I didn't find any references to 'diff.renameLimit.' even in 98171a0
> (bash completion: Sync config variables with their man pages,
> 2008-12-15) in which it was introduced in the completions script. I
> hope it was safe to remove it.
Yeah, I don't think it has ever existed.
> Some variables are documented with camelCase but read in all
> lowercase in the code. Not worth updating the code just for that, is
> it?
All variables are case-insensitive. The config parser down-cases them,
so all code should treat tham as all-lowercase. However, we tend to
document them as camelCase for readability.
The completion code should match case-insensitively, too. It doesn't
seem to now, but I suspect it is not a problem in practice because the
first camelCase word is often enough to get a match, and is lowercase
itself.
> I hope none of the added variables are deprecated. After having a
> quick look in git-config(1), I think they should not be.
All looked OK from my quick glance.
One note:
> color.diff
> color.diff.commit
> color.diff.frag
> + color.diff.func
> color.diff.meta
> color.diff.new
> color.diff.old
> color.diff.plain
> color.diff.whitespace
We have color.diff.branch coming soon (I think it is in 'next' now).
-Peff
^ permalink raw reply
* [PATCH] completion: add missing configuration variables
From: Martin von Zweigbergk @ 2010-12-15 6:46 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Martin von Zweigbergk
Quite a few configuration variables have been added since 226b343
(completion: add missing configuration variables to _git_config(),
2009-05-03). Add these variables to the Bash completion script.
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
---
The color.grep.external option has been deleted. Should it be deleted
from here or do we want to help users run e.g.
'git config --unset color.grep.external'? Same goes for
add.ignore-errors.
I didn't find any references to 'diff.renameLimit.' even in 98171a0
(bash completion: Sync config variables with their man pages,
2008-12-15) in which it was introduced in the completions script. I
hope it was safe to remove it.
Some variables are documented with camelCase but read in all
lowercase in the code. Not worth updating the code just for that, is
it?
I hope none of the added variables are deprecated. After having a
quick look in git-config(1), I think they should not be.
contrib/completion/git-completion.bash | 67 +++++++++++++++++++++++++++++++-
1 files changed, 65 insertions(+), 2 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 604fa79..1e2e864 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1865,29 +1865,51 @@ _git_config ()
esac
__gitcomp "
add.ignore-errors
+ add.ignoreErrors
+ advice.commitBeforeMerge
+ advice.detachedHead
+ advice.implicitIdentity
+ advice.pushNonFastForward
+ advice.resolveConflict
+ advice.statusHints
alias.
+ am.keepcr
apply.ignorewhitespace
apply.whitespace
branch.autosetupmerge
branch.autosetuprebase
+ browser.
clean.requireForce
color.branch
color.branch.current
color.branch.local
color.branch.plain
color.branch.remote
+ color.decorate.HEAD
+ color.decorate.branch
+ color.decorate.remoteBranch
+ color.decorate.stash
+ color.decorate.tag
color.diff
color.diff.commit
color.diff.frag
+ color.diff.func
color.diff.meta
color.diff.new
color.diff.old
color.diff.plain
color.diff.whitespace
color.grep
+ color.grep.context
color.grep.external
+ color.grep.filename
+ color.grep.function
+ color.grep.linenumber
color.grep.match
+ color.grep.selected
+ color.grep.separator
color.interactive
+ color.interactive.error
color.interactive.header
color.interactive.help
color.interactive.prompt
@@ -1901,21 +1923,29 @@ _git_config ()
color.status.untracked
color.status.updated
color.ui
+ commit.status
commit.template
+ core.abbrevguard
+ core.askpass
+ core.attributesfile
core.autocrlf
core.bare
+ core.bigFileThreshold
core.compression
core.createObject
core.deltaBaseCacheLimit
core.editor
+ core.eol
core.excludesfile
core.fileMode
core.fsyncobjectfiles
core.gitProxy
core.ignoreCygwinFSTricks
core.ignoreStat
+ core.ignorecase
core.logAllRefUpdates
core.loosecompression
+ core.notesRef
core.packedGitLimit
core.packedGitWindowSize
core.pager
@@ -1925,6 +1955,7 @@ _git_config ()
core.repositoryFormatVersion
core.safecrlf
core.sharedRepository
+ core.sparseCheckout
core.symlinks
core.trustctime
core.warnAmbiguousRefs
@@ -1932,9 +1963,10 @@ _git_config ()
core.worktree
diff.autorefreshindex
diff.external
+ diff.ignoreSubmodules
diff.mnemonicprefix
+ diff.noprefix
diff.renameLimit
- diff.renameLimit.
diff.renames
diff.suppressBlankEmpty
diff.tool
@@ -1952,6 +1984,8 @@ _git_config ()
format.subjectprefix
format.suffix
format.thread
+ format.to
+ gc.
gc.aggressiveWindow
gc.auto
gc.autopacklimit
@@ -1989,15 +2023,20 @@ _git_config ()
http.lowSpeedLimit
http.lowSpeedTime
http.maxRequests
+ http.minSessions
http.noEPSV
+ http.postBuffer
http.proxy
http.sslCAInfo
http.sslCAPath
http.sslCert
+ http.sslCertPasswordProtected
http.sslKey
http.sslVerify
+ http.useragent
i18n.commitEncoding
i18n.logOutputEncoding
+ imap.authMethod
imap.folder
imap.host
imap.pass
@@ -2006,6 +2045,7 @@ _git_config ()
imap.sslverify
imap.tunnel
imap.user
+ init.templatedir
instaweb.browser
instaweb.httpd
instaweb.local
@@ -2013,19 +2053,29 @@ _git_config ()
instaweb.port
interactive.singlekey
log.date
+ log.decorate
log.showroot
mailmap.file
man.
man.viewer
+ merge.
merge.conflictstyle
merge.log
merge.renameLimit
+ merge.renormalize
merge.stat
merge.tool
merge.verbosity
mergetool.
mergetool.keepBackup
+ mergetool.keepTemporaries
mergetool.prompt
+ notes.displayRef
+ notes.rewrite.
+ notes.rewrite.amend
+ notes.rewrite.rebase
+ notes.rewriteMode
+ notes.rewriteRef
pack.compression
pack.deltaCacheLimit
pack.deltaCacheSize
@@ -2036,31 +2086,42 @@ _git_config ()
pack.window
pack.windowMemory
pager.
+ pretty.
pull.octopus
pull.twohead
push.default
+ rebase.autosquash
rebase.stat
+ receive.autogc
receive.denyCurrentBranch
+ receive.denyDeleteCurrent
receive.denyDeletes
receive.denyNonFastForwards
receive.fsckObjects
receive.unpackLimit
+ receive.updateserverinfo
+ remotes.
repack.usedeltabaseoffset
rerere.autoupdate
rerere.enabled
+ sendemail.
sendemail.aliasesfile
- sendemail.aliasesfiletype
+ sendemail.aliasfiletype
sendemail.bcc
sendemail.cc
sendemail.cccmd
sendemail.chainreplyto
sendemail.confirm
sendemail.envelopesender
+ sendemail.from
+ sendemail.identity
sendemail.multiedit
sendemail.signedoffbycc
+ sendemail.smtpdomain
sendemail.smtpencryption
sendemail.smtppass
sendemail.smtpserver
+ sendemail.smtpserveroption
sendemail.smtpserverport
sendemail.smtpuser
sendemail.suppresscc
@@ -2071,6 +2132,8 @@ _git_config ()
showbranch.default
status.relativePaths
status.showUntrackedFiles
+ status.submodulesummary
+ submodule.
tar.umask
transfer.unpackLimit
url.
--
1.7.3.2.864.gbbb96
^ permalink raw reply related
* Re: subdirectory-filter does not delete files before the directory came into existence?
From: Jan Wielemaker @ 2010-12-15 12:22 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <201012150003.30127.trast@student.ethz.ch>
The reported problems also apply to the next module. What appears to
work is this:
* Walk through the history, finding the commit where the directory
is created.
* use git tag -l --contains <commit that created dir> to get the
tags we want to keep.
* get all tags, use comm and delete the tags not in the `contained'
set above.
Not very friendly and I'm (with Thomas) about the status of these
findings. I like to thank Thomas for giving me the right clue.
Regards --- Jan
On Wed, 2010-12-15 at 00:03 +0100, Thomas Rast wrote:
> Jan Wielemaker wrote:
> > I try to extract a directory. The result is fine, but there is a lot
> > of history in the result from *before* the directory was added to the
> > project. Why? How can I get rid of this?
> [...]
> > Now use e.g. qgit to look at the history. As from 03/07/2002, when
> > the packages/odbc directory was created, all looks just fine. Before
> > though ...
>
> That history is not connected to the filtered one. git-filter-branch
> alerts you to it with messages like
>
> WARNING: Ref 'refs/tags/V5.0.4' is unchanged
> WARNING: Ref 'refs/tags/V5.0.5' is unchanged
> WARNING: Ref 'refs/tags/V5.0.6' is unchanged
> WARNING: Ref 'refs/tags/V5.0.7' is unchanged
>
> I haven't made up my mind if this is a bug report or a feature
> request, but in any case you can delete all of them and the problem
> goes away.
>
^ permalink raw reply
* Re: subdirectory-filter does not delete files before the directory came into existence?
From: Jan Wielemaker @ 2010-12-15 10:40 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <201012150003.30127.trast@student.ethz.ch>
In addition to my previous reply: Looking at the result of the
initial filter, if remove all unchanged refs I loose the history
before 2008. Qgit however shows a broken history at the start
of the directory in 2002. If I keep deleting the tag that is
the head of older stuff I end up with what I hoped in the first
place. This is of course a bit tedious :-(
You can view the result at
git://www.swi-prolog.org/home/pl/git/packages/odbc.git
I'll split some more packages. Curious to what is going to happen ...
Regards --- Jan
On Wed, 2010-12-15 at 00:03 +0100, Thomas Rast wrote:
> Jan Wielemaker wrote:
> > I try to extract a directory. The result is fine, but there is a lot
> > of history in the result from *before* the directory was added to the
> > project. Why? How can I get rid of this?
> [...]
> > Now use e.g. qgit to look at the history. As from 03/07/2002, when
> > the packages/odbc directory was created, all looks just fine. Before
> > though ...
>
> That history is not connected to the filtered one. git-filter-branch
> alerts you to it with messages like
>
> WARNING: Ref 'refs/tags/V5.0.4' is unchanged
> WARNING: Ref 'refs/tags/V5.0.5' is unchanged
> WARNING: Ref 'refs/tags/V5.0.6' is unchanged
> WARNING: Ref 'refs/tags/V5.0.7' is unchanged
>
> I haven't made up my mind if this is a bug report or a feature
> request, but in any case you can delete all of them and the problem
> goes away.
>
^ permalink raw reply
* Re: subdirectory-filter does not delete files before the directory came into existence?
From: Jan Wielemaker @ 2010-12-15 9:50 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <201012150003.30127.trast@student.ethz.ch>
Dear Thomas,
On Wed, 2010-12-15 at 00:03 +0100, Thomas Rast wrote:
> Jan Wielemaker wrote:
> > I try to extract a directory. The result is fine, but there is a lot
> > of history in the result from *before* the directory was added to the
> > project. Why? How can I get rid of this?
> [...]
> > Now use e.g. qgit to look at the history. As from 03/07/2002, when
> > the packages/odbc directory was created, all looks just fine. Before
> > though ...
>
> That history is not connected to the filtered one. git-filter-branch
> alerts you to it with messages like
>
> WARNING: Ref 'refs/tags/V5.0.4' is unchanged
> WARNING: Ref 'refs/tags/V5.0.5' is unchanged
> WARNING: Ref 'refs/tags/V5.0.6' is unchanged
> WARNING: Ref 'refs/tags/V5.0.7' is unchanged
Thanks for the insight. Catching these errors and running git tag -d on
them gets me a nice and clean history. Only ... It starts in
12/08/2008 instead of 03/07/2002. This is (almost) compatible with the
filtering feedback that says it rewrote 174 commits. The filtered and
cleaned history contains 171.
This is a bit odd. If I open qgit on the original (before filtering)
and show the history of odbc.c, it looks like a nice and continuous
one going back to 2002. Also
git log --oneline packages/odbc/odbc.c
shows a history that starts with "First public version of ODBC
interface"
Of course, this is a project with a long history that was converted
from CVS, but the history looks unbroken, so why does filtering a
directory breaks it?
> I haven't made up my mind if this is a bug report or a feature
> request, but in any case you can delete all of them and the problem
> goes away.
Isn't it true that you will have info from before introducing a
directory whenever there are tags that are older than the directory?
If that is the case, it looks wrong to me. I want to filter the
directory, so the repository from before the existence of the
directory is not interesting. Of course, things change if the
directory was created by renaming files that where already in
the repository. I don't know what one should `expect' in that
case. Here, the directory was added from new files, so it is
quite clear what one should expect.
Regards --- Jan
^ permalink raw reply
* Re: [PATCH 11/14] t3032-*.sh: Pass the -b (--binary) option to sed on cygwin
From: Eric Sunshine @ 2010-12-15 9:30 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Ramsay Jones, GIT Mailing-list, Pat Thoyts
In-Reply-To: <4D087AC7.2090705@viscovery.net>
On 12/15/2010 3:22 AM, Johannes Sixt wrote:
> Am 12/15/2010 0:32, schrieb Eric Sunshine:
>> On 12/14/2010 2:24 PM, Junio C Hamano wrote:
>>> Ramsay Jones<ramsay@ramsay1.demon.co.uk> writes:
>>>> The test using the conflict_hunks helper function (test 9) fails
>>>> on cygwin, since sed (by default) throws away the CR from CRLF
>>>> line endings. This behaviour is undesirable, since the validation
>>>> code expects the CRLF line-ending to be present. In order to fix
>>>> the problem we pass the -b (--binary) option to sed, using the
>>>> SED_OPTIONS variable. We use the SED_STRIPS_CR prerequisite in the
>>>> conditional initialisation of SED_OPTIONS.
>>>>
>>>> Signed-off-by: Ramsay Jones<ramsay@ramsay1.demon.co.uk>
>>>> ---
>>>>
>>>> Note that this test does not fail on MinGW, but I don't
>>>> really know why, given commit ca02ad3... ahem ;-)
>>>
>>> Ahem, indeed. Why?
>>
>> t3032 does indeed fail on MinGW, and was fixed in the msysgit port by [1],
>> but was subsequently "lost" when msysgit was rebased onto junio/next [2]
>> which did not have that test. Consequently, the fix never made it into the
>> mainline git source.
>
> Sorry, but on MinGW, I only need the GREP_OPTIONS part of that fix, but
> not the SED_OPTIONS. It's also mysterious for me.
>
> OTOH, the fix in ca02ad3 that applies to t6038, does not work for me as is
> because my sed does not understand -b; it needs --nocr. Maybe it is the
> sed version that makes the difference?
>
> D:\Src\mingw-git\t>sed --version
> GNU sed version 3.02
Failure of t3032 was reported by Pat Thoyts [1] when preparing for the
v1.7.3 release. The problem was diagnosed and patched via [2] under the
standard msysgit netinstall [3] environment. From commit message [2],
GREP_OPTIONS and SED_OPTIONS were applied to resolve distinct cases of
line-terminator "corruption" (t3032.4-t3032.8 and t3032.9, respectively)
within that environment at the time the patch was prepared.
Your tool versions may indeed not be compatible with those of the
netinstall environment [3]:
$ sed --version
GNU sed version 4.2.1
Unfortunately, the old --nocr is not recognized by modern GNU sed:
$ sed --nocr
sed: unrecognized option `--nocr'
[1]:
http://groups.google.com/group/msysgit/browse_thread/thread/70110298ae72caea/a39b121bb0feccf4?lnk=gst&q=t3032#a39b121bb0feccf4
[2]:
http://groups.google.com/group/msysgit/browse_thread/thread/587d32ee034b0cbe/dca93dc6ad755012#dca93dc6ad755012
[3]: http://code.google.com/p/msysgit/downloads/list
[msysGit-netinstall-1.7.3.1-preview20101002.exe]
-- ES
^ permalink raw reply
* Re: html userdiff is not showing all my changes
From: Michael J Gruber @ 2010-12-15 9:29 UTC (permalink / raw)
To: matthijs, Scott Johnson, git, trast
In-Reply-To: <20101215091250.GO3069@login.drsnuggles.stderr.nl>
Matthijs Kooijman venit, vidit, dixit 15.12.2010 10:12:
> Hi Michael,
>
>> If a wordRegex can make parts of diff disappear than there is problem
>> deeper in the diff machinery.
> It can do exactly that. The word regex determines what is a word, but
> everything else is counted as "whitespace". The word diff view shows
> only differences in words, not in whitespace (which is intentional,
> since whitespace changes in things like LaTeX or HTML are not
> interesting). Note that it doesn't show whitespace _differences_, but it
> does show the whitespace itself (taken from the "new" version of the
> file).
Yep, I just found out myself experimenting with a wordRegex for csv.
Seems like quite a "Gimme rope" feature...
So, it's the regex.
> So, if the word regex somehow doesn't match the second line at all (or
> at least not the differen part), the differences could get ignored.
>
>> Can you trim this down to a minimal example?
> That would be useful in any case.
What strikes me is that both lines are semantically identical, yet one
is treated correctly and the other isn't.
Michael
^ permalink raw reply
* Re: html userdiff is not showing all my changes
From: Matthijs Kooijman @ 2010-12-15 9:12 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Scott Johnson, git, trast
In-Reply-To: <4D08850D.3010402@drmicha.warpmail.net>
[-- Attachment #1: Type: text/plain, Size: 773 bytes --]
Hi Michael,
> If a wordRegex can make parts of diff disappear than there is problem
> deeper in the diff machinery.
It can do exactly that. The word regex determines what is a word, but
everything else is counted as "whitespace". The word diff view shows
only differences in words, not in whitespace (which is intentional,
since whitespace changes in things like LaTeX or HTML are not
interesting). Note that it doesn't show whitespace _differences_, but it
does show the whitespace itself (taken from the "new" version of the
file).
So, if the word regex somehow doesn't match the second line at all (or
at least not the differen part), the differences could get ignored.
> Can you trim this down to a minimal example?
That would be useful in any case.
Gr.
Matthijs
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH v3 3/8] mingw: make failures to unlink or move raise a question
From: Erik Faye-Lund @ 2010-12-15 9:09 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Heiko Voigt, Johannes Sixt, Pat Thoyts,
msysgit, git, Albert Dvornik
In-Reply-To: <7v1v5jrb1f.fsf@alter.siamese.dyndns.org>
On Wed, Dec 15, 2010 at 4:05 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>>> > @@ -129,6 +130,78 @@ static inline int is_file_in_use_error(DWORD errcode)
>>> > return 0;
>>> > }
>>> >
>>> > +static int read_yes_no_answer()
>>>
>>> Perhaps "static int read_yes_no_answer(void)" for portability?
>>
>> LOL. This file is called compat/mingw.c... :-)
>
> I had the same reaction. Maybe MinGW will get a different compiler
> someday ;-)
>
We already have; compat/msvc.c includes compat/mingw.c. mingw.c is
called mingw.c because it was the first native windows port, not
because it will always be compiled with MinGW. So this file is REALLY
more about the OS than the compiler.
I don't think MSVC has a problem with this declaration either, but
wouldn't it be nicer if we had Windows-code that was as portable as
possible across compilers? I've also been playing around with the idea
of using LLVM's clang for Git on Windows, because it's support for
cross compiling between 32bit and 64bit is a bit less nasty than
MinGW's. This might never come happen, and I don't know if clang
supports this or not. And then there's Intel's ICC that some times
outperforms GCC. I don't think it would hurt fixing it in case people
will port - one less trip-wire in the code.
But I of course only suggest this because this is new code. It's easy
to change it to be slightly more portable (and more consistent with
the rest of the code base), so why not?
^ permalink raw reply
* Re: html userdiff is not showing all my changes
From: Michael J Gruber @ 2010-12-15 9:06 UTC (permalink / raw)
To: Scott Johnson; +Cc: git, trast
In-Reply-To: <561247.22837.qm@web110707.mail.gq1.yahoo.com>
Scott Johnson venit, vidit, dixit 15.12.2010 04:47:
> I am attempting to do a word diff of an html source file. Part of the removed
> html is disappearing from the diff when I enable the fancy html word diff.
>
> Here's the output from basic `git diff`:
> diff --git a/adv_layout_source.html b/adv_layout_source.html
> index 18a81dd..c4ed609 100644
> --- a/adv_layout_source.html
> +++ b/adv_layout_source.html
> @@ -42,8 +42,8 @@
> <ul>
> <li class="ydn-patterns"><em></em><a href="#">ydn-patterns</a></li>
> <li class="ydn-mail"><em></em><a href="#">ydn-mail</a></li>
> - <li class="yws-maps"><em></em><a href="#">yws-maps</a></li>
> - <li class="ydn-delicious"><em></em><a href="#">ydn-delicious</a></li>
> + <li><em></em><a href="#">yws-maps</a></li>
> + <li><em></em><a href="#">ydn-delicious</a></li>
> <li class="yws-flickr"><em></em><a href="#">yws-flickr</a></li>
> <li class="yws-events"><em></em><a href="#">yws-events</a></li>
> </ul>
>
>
> Here's the default `git diff --word-diff`:
> diff --git a/adv_layout_source.html b/adv_layout_source.html
> index 18a81dd..c4ed609 100644
> --- a/adv_layout_source.html
> +++ b/adv_layout_source.html
> @@ -42,8 +42,8 @@
> <ul>
> <li class="ydn-patterns"><em></em><a href="#">ydn-patterns</a></li>
> <li class="ydn-mail"><em></em><a href="#">ydn-mail</a></li>
> [-<li class="yws-maps"><em></em><a-]{+<li><em></em><a+}
> href="#">yws-maps</a></li>
> [-<li class="ydn-delicious"><em></em><a-]{+<li><em></em><a+}
> href="#">ydn-delicious</a></li>
> <li class="yws-flickr"><em></em><a href="#">yws-flickr</a></li>
> <li class="yws-events"><em></em><a href="#">yws-events</a></li>
> </ul>
>
> Which is correct, but less than ideal because it highlights much more than the
> actual changes.
>
> So I create a .gitattributes file with one line:
> *.html diff=html
>
> And rerun `git diff --word-diff`:
> diff --git a/adv_layout_source.html b/adv_layout_source.html
> index 18a81dd..c4ed609 100644
> --- a/adv_layout_source.html
> +++ b/adv_layout_source.html
> @@ -42,8 +42,8 @@
> <ul>
> <li class="ydn-patterns"><em></em><a href="#">ydn-patterns</a></li>
> <li class="ydn-mail"><em></em><a href="#">ydn-mail</a></li>
> <li[-class="yws-maps"-]><em></em><a href="#">yws-maps</a></li>
> <li><em></em><a href="#">ydn-delicious</a></li>
> <li class="yws-flickr"><em></em><a href="#">yws-flickr</a></li>
> <li class="yws-events"><em></em><a href="#">yws-events</a></li>
> </ul>
>
> Yikes! What happened to the second line of changes? The removed code is not
> displayed at all.
>
> This is running git 1.7.3.3.
>
> I suspect the problem is in the html patterns in userdiff.c, but I don't
> understand the word-diff-regex well enough to fix it.
The wordRegex should really only control what comprises a word, i.e. the
granularity of --word-diff. (Where do we insert additional line-breaks
before running ordinary diff?)
If a wordRegex can make parts of diff disappear than there is problem
deeper in the diff machinery. Can you trim this down to a minimal example?
Michael
^ permalink raw reply
* [PATCH] get_sha1: handle special case $commit^{/}
From: Nguyễn Thái Ngọc Duy @ 2010-12-15 9:02 UTC (permalink / raw)
To: git, Junio C Hamano
Cc: Jonathan Niedier, Kevin Ballard, Yann Dirson, Jeff King,
Jakub Narebski, Thiago Farina,
Nguyễn Thái Ngọc Duy
In-Reply-To: <AANLkTimy5MVkxDzXqzA8T4DHJmzsSAvwqVVzRvWw5KA0@mail.gmail.com>
Empty regex pattern should always match. But the exact behavior of
regexec() may vary. Because it always matches anyway, we can just
return 'matched' without calling regex machinery.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
On top of nd/oneline-sha1-name-from-specific-ref
sha1_name.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index 1ba4bc3..c5c59ce 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -599,6 +599,13 @@ static int peel_onion(const char *name, int len, unsigned char *sha1)
int ret;
struct commit_list *list = NULL;
+ /*
+ * $commit^{/}. Some regex implementation may reject.
+ * We don't need regex anyway. '' pattern always matches.
+ */
+ if (sp[1] == '}')
+ return 0;
+
prefix = xstrndup(sp + 1, name + len - 1 - (sp + 1));
commit_list_insert((struct commit *)o, &list);
ret = get_sha1_oneline(prefix, sha1, list);
--
1.7.3.3.476.g10a82
^ permalink raw reply related
* Re: When I merge, a binary file conflict,how can I select between 2 versions?
From: Chunlin Zhang @ 2010-12-15 9:01 UTC (permalink / raw)
To: git
In-Reply-To: <20101215083301.GA6946@LK-Perkele-V2.elisa-laajakaista.fi>
Ilari Liusvaara <ilari.liusvaara <at> elisanet.fi> writes:
> git checkout --theirs -- <file>
> git add <file>
Thanks you very much.That is what I want!
^ permalink raw reply
* Re: When I merge, a binary file conflict,how can I select between 2 versions?
From: Ilari Liusvaara @ 2010-12-15 8:33 UTC (permalink / raw)
To: Chunlin Zhang; +Cc: git
In-Reply-To: <loom.20101215T084919-573@post.gmane.org>
On Wed, Dec 15, 2010 at 08:00:08AM +0000, Chunlin Zhang wrote:
> The only way now I know is to replace the file with the version file I want in
> working copy,and then git add and git commit.I think it is inconvenient.
>
> Then I think if there is some command to select local or remote version file to
> add more easier,because it is obviously git keep 2 version file.
IIRC,
git checkout --theirs -- <file>
git add <file>
-Ilari
^ permalink raw reply
* Re: [PATCH 11/14] t3032-*.sh: Pass the -b (--binary) option to sed on cygwin
From: Johannes Sixt @ 2010-12-15 8:22 UTC (permalink / raw)
To: Eric Sunshine; +Cc: Junio C Hamano, Ramsay Jones, GIT Mailing-list
In-Reply-To: <4D07FE91.2090003@sunshineco.com>
Am 12/15/2010 0:32, schrieb Eric Sunshine:
> On 12/14/2010 2:24 PM, Junio C Hamano wrote:
>> Ramsay Jones<ramsay@ramsay1.demon.co.uk> writes:
>>> The test using the conflict_hunks helper function (test 9) fails
>>> on cygwin, since sed (by default) throws away the CR from CRLF
>>> line endings. This behaviour is undesirable, since the validation
>>> code expects the CRLF line-ending to be present. In order to fix
>>> the problem we pass the -b (--binary) option to sed, using the
>>> SED_OPTIONS variable. We use the SED_STRIPS_CR prerequisite in the
>>> conditional initialisation of SED_OPTIONS.
>>>
>>> Signed-off-by: Ramsay Jones<ramsay@ramsay1.demon.co.uk>
>>> ---
>>>
>>> Note that this test does not fail on MinGW, but I don't
>>> really know why, given commit ca02ad3... ahem ;-)
>>
>> Ahem, indeed. Why?
>
> t3032 does indeed fail on MinGW, and was fixed in the msysgit port by [1],
> but was subsequently "lost" when msysgit was rebased onto junio/next [2]
> which did not have that test. Consequently, the fix never made it into the
> mainline git source.
Sorry, but on MinGW, I only need the GREP_OPTIONS part of that fix, but
not the SED_OPTIONS. It's also mysterious for me.
OTOH, the fix in ca02ad3 that applies to t6038, does not work for me as is
because my sed does not understand -b; it needs --nocr. Maybe it is the
sed version that makes the difference?
D:\Src\mingw-git\t>sed --version
GNU sed version 3.02
...
-- Hannes
^ permalink raw reply
* Re: TopGit release?
From: Uwe Kleine-König @ 2010-12-15 8:01 UTC (permalink / raw)
To: Peter Simons
Cc: git, martin f krafft, Bert Wesarg, Per Cederqvist, Olaf Dabrunz,
Thomas Moschny
In-Reply-To: <87ei9k42v5.fsf@write-only.cryp.to>
Hello,
On Tue, Dec 14, 2010 at 07:37:50PM +0100, Peter Simons wrote:
> I was wondering whether there's a chance that we'll have a new release
> of TopGit in the foreseeable future? Version 0.8 seems to be quite old
> by now, but still there's no observable progress in getting a new
> version tagged. Is this project still alive?
There are a few patches pending, but I currently don't find the time to
go through and apply them[1]. Moreover I hardly use topgit anymore.
So if someone with interest in topgit wants to step forward to help this
would be very appreciated.
Best regards
Uwe
[1] http://thread.gmane.org/gmane.comp.version-control.git/159433
hint to Bert: this series doesn't apply to master
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* When I merge, a binary file conflict,how can I select between 2 versions?
From: Chunlin Zhang @ 2010-12-15 8:00 UTC (permalink / raw)
To: git
The only way now I know is to replace the file with the version file I want in
working copy,and then git add and git commit.I think it is inconvenient.
When I use "git mergetool",it output:
'''
Merging the files: binary_example.png
Normal merge conflict for 'binary_example.png':
{local}: modified
{remote}: modified
Hit return to start merge resolution tool (meld):
'''
Then I think if there is some command to select local or remote version file to
add more easier,because it is obviously git keep 2 version file.
Does anyone know it?
Thanks!
^ permalink raw reply
* Re: Re: [PATCH v3 3/8] mingw: make failures to unlink or move raise a question
From: Heiko Voigt @ 2010-12-15 7:48 UTC (permalink / raw)
To: Junio C Hamano
Cc: kusmabite, Johannes Sixt, Pat Thoyts, msysgit, git,
Albert Dvornik, Johannes Schindelin
In-Reply-To: <7vk4jbrjxn.fsf@alter.siamese.dyndns.org>
Hi,
On Tue, Dec 14, 2010 at 03:52:52PM -0800, Junio C Hamano wrote:
> Erik Faye-Lund <kusmabite@gmail.com> writes:
>
> > Since you're doing case insensitive checks for "yes" and "no", perhaps
> > it'd make sense to allow upper case 'Y' and 'N' also? Something like:
> >
> > - if (answer[0] == 'n' && strlen(answer) == 1)
> > + if (tolower(answer[0]) == 'n' && strlen(answer) == 1)
> >
> > hm?
>
> Why not
>
> if (tolower(answer[0]) == 'n' && !answer[1])
>
> think of the case answer[] is very long ;-)
Will change as stated in the previous email but of course using this
code for efficiency ;) Can anybody estimate how fast the user would need
to type to actually make this noticeable and how much heat that would
produce on the keyboard?
> >> + if (!isatty(_fileno(stdin)) || !isatty(_fileno(stderr)))
> >> + return 0;
> >
> > I'm wondering, doesn't this make the semantics a bit wrong? The
> > function is called "ask_user_yes_no", but it might end up not asking
> > after all.
>
> I don't think that is such a big issue.
>
> Imagine you had only getenv("GIT_ASK_YESNO") codepath, and no fallback
> "tty" codepath. And you ship with a separate program as a default
> "asker".
>
> The implementation of that asker happens to read yes/no from the tty, but
> it defauts to "no" if there is no tty interaction available.
>
> If you view it that way, the code we see above is just an optimization to
> avoid spawning that default "asker" as a separate process.
I do not mind to change this function name to make it more match what
its doing. Since code is read way more often than written I think this
makes sense. See my other email about the suggestion.
> I was more puzzled by the code to formulate question[]; why doesn't it
> build the same question for both codepaths and spit that out to stderr
> with fputs() in the fallvack asker?
Do you mean that I append " (y/n)? " ? For the (y/n) you can think of it
as the tui implementation of the yes/no button. I can see that the ?
might need to go into the question string itself. Is it that what you
meant?
Cheers Heiko
^ permalink raw reply
* Re: Re: [PATCH v3 3/8] mingw: make failures to unlink or move raise a question
From: Heiko Voigt @ 2010-12-15 7:36 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Erik Faye-Lund, Johannes Sixt, Pat Thoyts, msysgit, git,
Junio C Hamano, Albert Dvornik
In-Reply-To: <alpine.DEB.1.00.1012150109340.1461@bonsai2>
Hi,
On Wed, Dec 15, 2010 at 01:11:03AM +0100, Johannes Schindelin wrote:
> On Tue, 14 Dec 2010, Erik Faye-Lund wrote:
>
> > On Tue, Dec 14, 2010 at 11:21 PM, Heiko Voigt <hvoigt@hvoigt.net> wrote:
[...]
> > > + if (answer[0] == 'y' && strlen(answer) == 1)
> > > + return 1;
> > > + if (!strncasecmp(answer, "yes", sizeof(answer)))
> > > + return 1;
> > > + if (answer[0] == 'n' && strlen(answer) == 1)
> > > + return 0;
> > > + if (!strncasecmp(answer, "no", sizeof(answer)))
> > > + return 0;
> >
> > Since you're doing case insensitive checks for "yes" and "no", perhaps
> > it'd make sense to allow upper case 'Y' and 'N' also? Something like:
> >
> > - if (answer[0] == 'n' && strlen(answer) == 1)
> > + if (tolower(answer[0]) == 'n' && strlen(answer) == 1)
> >
> > hm?
>
> Makes sense to me.
Will do in the next iteration.
> > > +static int ask_user_yes_no(const char *format, ...)
[...]
> >
> > I'm wondering, doesn't this make the semantics a bit wrong? The
> > function is called "ask_user_yes_no", but it might end up not asking
> > after all. Perhaps it should be called something that reflects this?
> > "maybe_ask_yes_no", "ask_yes_no_if_tty", "should_retry"? I don't have
> > a non-ugly suggestion, but I suspect something like that might leave
> > other people less puzzled when reading the code.
>
> I like ask_yes_no_if_tty.
How about ask_yes_no_if_possible() ? Since we do not just rely on tty
but still have GIT_ASK_YESNO to get to the user I think this would be
a closer description of what happens.
Cheers Heiko
^ permalink raw reply
* Re: Re: [PATCH v3 3/8] mingw: make failures to unlink or move raise a question
From: Heiko Voigt @ 2010-12-15 7:28 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Erik Faye-Lund, Johannes Sixt, Pat Thoyts,
msysgit, git, Albert Dvornik
In-Reply-To: <7v1v5jrb1f.fsf@alter.siamese.dyndns.org>
On Tue, Dec 14, 2010 at 07:05:00PM -0800, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> > @@ -129,6 +130,78 @@ static inline int is_file_in_use_error(DWORD errcode)
> >> > return 0;
> >> > }
> >> >
> >> > +static int read_yes_no_answer()
> >>
> >> Perhaps "static int read_yes_no_answer(void)" for portability?
> >
> > LOL. This file is called compat/mingw.c... :-)
>
> I had the same reaction. Maybe MinGW will get a different compiler
> someday ;-)
>
> > But I have no objection to stay with the convention of the rest of Git.
> > Nobody needs to convince me that consistency is good.
>
> I recall there are a few old-style declaration in compat/ directory,
> especially in borrowed code like nedmalloc/ and possibly regex/, and
> I am not so sure if we want to touch them.
>
> I'll leave this up to msysgit folks.
I do not mind changing this sincce I need to change this patch anyway.
Will do in the next iteration.
Cheers Heiko
^ permalink raw reply
* [MERGE PATCH 3/3] Merge branch 'master' (early part) into pd/bash-4-completion
From: Jonathan Nieder @ 2010-12-15 6:42 UTC (permalink / raw)
To: Junio C Hamano
Cc: SZEDER Gábor, Peter van der Does, Shawn O. Pearce, git,
Marc Branchaud, Brian Gernhardt, Kevin Ballard, Mathias Lafeldt,
Stephen Boyd
In-Reply-To: <20101215062403.GA20492@burratino>
* 'master' (early part): (529 commits)
completion: fix zsh check under bash with 'set -u'
Fix copy-pasted comments related to tree diff handling.
Git 1.7.3.2
{cvs,svn}import: use the new 'git read-tree --empty'
t/t9001-send-email.sh: fix stderr redirection in 'Invalid In-Reply-To'
Clarify and extend the "git diff" format documentation
git-show-ref.txt: clarify the pattern matching
documentation: git-config minor cleanups
Update test script annotate-tests.sh to handle missing/extra authors
...
Conflicts:
GIT-VERSION-GEN
RelNotes
contrib/completion/git-completion.bash
---
Suggestions for further work:
- check edge cases:
git log --pretty m<tab><tab> should complete formats
git log --pretty =<tab><tab> should complain
git log --pretty= m<tab><tab> should complete commits
- use a custom function to avoid repeating
_get_comp_words_by_ref -n =:
As an application, consider teaching git to complete
git show HEAD@{<tab><tab> completes to numbers and "upstream"
Would the argument to -n need an @ for that?
- get the zsh completion to actually work. :) Even without this
series, it seems it is willing to complete subcommand names and
switches for git but nothing more.
- adopt the rest of bash_completion's _get_comp_words_by_ref logic,
so
git log --pretty=m<cursor>master <tab><tab>
completes formats starting with 'm', not formats starting with 'mmaster'.
If something turned out buggy, I'd be glad to fix it, but aside from
that I probably will not be working much more on this topic. (Perhaps
an actual tab completion user would have a better sense of which
aspects are worth working on.) Please feel free to pick it up and run
in whatever direction you please.
Good night,
Jonathan
diff --cc contrib/completion/git-completion.bash
index 1747091,168669b..d117055
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@@ -321,135 -327,6 +327,162 @@@ __gitcomp_1 (
done
}
+# The following function is based on code from:
+#
+# bash_completion - programmable completion functions for bash 3.2+
+#
+# Copyright © 2006-2008, Ian Macdonald <ian@caliban.org>
+# © 2009-2010, Bash Completion Maintainers
+# <bash-completion-devel@lists.alioth.debian.org>
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software Foundation,
+# Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+#
+# The latest version of this software can be obtained here:
+#
+# http://bash-completion.alioth.debian.org/
+#
+# RELEASE: 2.x
+
+# This function can be used to access a tokenized list of words
+# on the command line:
+#
+# __git_reassemble_comp_words_by_ref '=:'
+# if test "${words_[cword_-1]}" = -w
+# then
+# ...
+# fi
+#
+# The argument should be a collection of characters from the list of
+# word completion separators (COMP_WORDBREAKS) to treat as ordinary
+# characters.
+#
+# This is roughly equivalent to going back in time and setting
+# COMP_WORDBREAKS to exclude those characters. The intent is to
+# make option types like --date=<type> and <rev>:<path> easy to
+# recognize by treating each shell word as a single token.
+#
+# It is best not to set COMP_WORDBREAKS directly because the value is
+# shared with other completion scripts. By the time the completion
+# function gets called, COMP_WORDS has already been populated so local
+# changes to COMP_WORDBREAKS have no effect.
+#
+# Output: words_, cword_, cur_.
+
+__git_reassemble_comp_words_by_ref()
+{
+ local exclude i j first
+ # Which word separators to exclude?
+ exclude="${1//[^$COMP_WORDBREAKS]}"
+ cword_=$COMP_CWORD
+ if [ -z "$exclude" ]; then
+ words_=("${COMP_WORDS[@]}")
+ return
+ fi
+ # List of word completion separators has shrunk;
+ # re-assemble words to complete.
+ for ((i=0, j=0; i < ${#COMP_WORDS[@]}; i++, j++)); do
+ # Append each nonempty word consisting of just
+ # word separator characters to the current word.
+ first=t
+ while
+ [ $i -gt 0 ] &&
+ [ -n "${COMP_WORDS[$i]}" ] &&
+ # word consists of excluded word separators
+ [ "${COMP_WORDS[$i]//[^$exclude]}" = "${COMP_WORDS[$i]}" ]
+ do
+ # Attach to the previous token,
+ # unless the previous token is the command name.
+ if [ $j -ge 2 ] && [ -n "$first" ]; then
+ ((j--))
+ fi
+ first=
+ words_[$j]=${words_[j]}${COMP_WORDS[i]}
+ if [ $i = $COMP_CWORD ]; then
+ cword_=$j
+ fi
+ if (($i < ${#COMP_WORDS[@]} - 1)); then
+ ((i++))
+ else
+ # Done.
+ return
+ fi
+ done
+ words_[$j]=${words_[j]}${COMP_WORDS[i]}
+ if [ $i = $COMP_CWORD ]; then
+ cword_=$j
+ fi
+ done
+}
+
+if ! type _get_comp_words_by_ref >/dev/null 2>&1; then
++if [[ -z ${ZSH_VERSION:+set} ]]; then
+_get_comp_words_by_ref ()
+{
+ local exclude cur_ words_ cword_
+ if [ "$1" = "-n" ]; then
+ exclude=$2
+ shift 2
+ fi
+ __git_reassemble_comp_words_by_ref "$exclude"
+ cur_=${words_[cword_]}
+ while [ $# -gt 0 ]; do
+ case "$1" in
+ cur)
+ cur=$cur_
+ ;;
+ prev)
+ prev=${words_[$cword_-1]}
+ ;;
+ words)
+ words=("${words_[@]}")
+ ;;
+ cword)
+ cword=$cword_
+ ;;
+ esac
+ shift
+ done
+}
++else
++_get_comp_words_by_ref ()
++{
++ while [ $# -gt 0 ]; do
++ case "$1" in
++ cur)
++ cur=${COMP_WORDS[COMP_CWORD]}
++ ;;
++ prev)
++ prev=${COMP_WORDS[COMP_CWORD-1]}
++ ;;
++ words)
++ words=("${COMP_WORDS[@]}")
++ ;;
++ cword)
++ cword=$COMP_CWORD
++ ;;
++ -n)
++ # assume COMP_WORDBREAKS is already set sanely
++ shift
++ ;;
++ esac
++ shift
++ done
++}
++fi
+fi
+
# __gitcomp accepts 1, 2, 3, or 4 arguments
# generates completion reply with compgen
__gitcomp ()
@@@ -2522,10 -2345,13 +2555,15 @@@ _git (
{
local i c=1 command __git_dir
+ if [[ -n ${ZSH_VERSION-} ]]; then
+ emulate -L bash
+ setopt KSH_TYPESET
+ fi
+
- while [ $c -lt $COMP_CWORD ]; do
- i="${COMP_WORDS[c]}"
+ local cur words cword
+ _get_comp_words_by_ref -n =: cur words cword
+ while [ $c -lt $cword ]; do
+ i="${words[c]}"
case "$i" in
--git-dir=*) __git_dir="${i#--git-dir=}" ;;
--bare) __git_dir="." ;;
@@@ -2568,9 -2394,14 +2606,14 @@@
_gitk ()
{
+ if [[ -n ${ZSH_VERSION-} ]]; then
+ emulate -L bash
+ setopt KSH_TYPESET
+ fi
+
__git_has_doubledash && return
- local cur="${COMP_WORDS[COMP_CWORD]}"
+ local cur
local g="$(__gitdir)"
local merge=""
if [ -f "$g/MERGE_HEAD" ]; then
^ permalink raw reply
* [PATCH 2/3] bash: simple reimplementation of _get_comp_words_by_ref
From: Jonathan Nieder @ 2010-12-15 6:27 UTC (permalink / raw)
To: Junio C Hamano
Cc: SZEDER Gábor, Peter van der Does, Shawn O. Pearce, git,
Marc Branchaud, Brian Gernhardt, Kevin Ballard, Mathias Lafeldt,
Stephen Boyd
In-Reply-To: <20101215062403.GA20492@burratino>
Add a minimal implementation of _get_comp_words_by_ref so
$ git show head:g <tab><tab>
on bash 4 can complete paths within the head commit without requiring
the bash_completion functions to be loaded. This is a follow-up to
the previous patch (bash: get --pretty=m<tab> completion to work with
bash v4).
Based on bash-completion 2.x (commit bf763033, 2010-10-26) but tweaked
for simplicity and to allow zsh to parse the code.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Improved-by: SZEDER Gábor <szeder@ira.uka.de>
---
contrib/completion/git-completion.bash | 118 +++++++++++++++++++++++++++++--
1 files changed, 110 insertions(+), 8 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 68b68d0..1747091 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -321,26 +321,128 @@ __gitcomp_1 ()
done
}
+# The following function is based on code from:
+#
+# bash_completion - programmable completion functions for bash 3.2+
+#
+# Copyright © 2006-2008, Ian Macdonald <ian@caliban.org>
+# © 2009-2010, Bash Completion Maintainers
+# <bash-completion-devel@lists.alioth.debian.org>
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software Foundation,
+# Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+#
+# The latest version of this software can be obtained here:
+#
+# http://bash-completion.alioth.debian.org/
+#
+# RELEASE: 2.x
+
+# This function can be used to access a tokenized list of words
+# on the command line:
+#
+# __git_reassemble_comp_words_by_ref '=:'
+# if test "${words_[cword_-1]}" = -w
+# then
+# ...
+# fi
+#
+# The argument should be a collection of characters from the list of
+# word completion separators (COMP_WORDBREAKS) to treat as ordinary
+# characters.
+#
+# This is roughly equivalent to going back in time and setting
+# COMP_WORDBREAKS to exclude those characters. The intent is to
+# make option types like --date=<type> and <rev>:<path> easy to
+# recognize by treating each shell word as a single token.
+#
+# It is best not to set COMP_WORDBREAKS directly because the value is
+# shared with other completion scripts. By the time the completion
+# function gets called, COMP_WORDS has already been populated so local
+# changes to COMP_WORDBREAKS have no effect.
+#
+# Output: words_, cword_, cur_.
+
+__git_reassemble_comp_words_by_ref()
+{
+ local exclude i j first
+ # Which word separators to exclude?
+ exclude="${1//[^$COMP_WORDBREAKS]}"
+ cword_=$COMP_CWORD
+ if [ -z "$exclude" ]; then
+ words_=("${COMP_WORDS[@]}")
+ return
+ fi
+ # List of word completion separators has shrunk;
+ # re-assemble words to complete.
+ for ((i=0, j=0; i < ${#COMP_WORDS[@]}; i++, j++)); do
+ # Append each nonempty word consisting of just
+ # word separator characters to the current word.
+ first=t
+ while
+ [ $i -gt 0 ] &&
+ [ -n "${COMP_WORDS[$i]}" ] &&
+ # word consists of excluded word separators
+ [ "${COMP_WORDS[$i]//[^$exclude]}" = "${COMP_WORDS[$i]}" ]
+ do
+ # Attach to the previous token,
+ # unless the previous token is the command name.
+ if [ $j -ge 2 ] && [ -n "$first" ]; then
+ ((j--))
+ fi
+ first=
+ words_[$j]=${words_[j]}${COMP_WORDS[i]}
+ if [ $i = $COMP_CWORD ]; then
+ cword_=$j
+ fi
+ if (($i < ${#COMP_WORDS[@]} - 1)); then
+ ((i++))
+ else
+ # Done.
+ return
+ fi
+ done
+ words_[$j]=${words_[j]}${COMP_WORDS[i]}
+ if [ $i = $COMP_CWORD ]; then
+ cword_=$j
+ fi
+ done
+}
+
if ! type _get_comp_words_by_ref >/dev/null 2>&1; then
_get_comp_words_by_ref ()
{
+ local exclude cur_ words_ cword_
+ if [ "$1" = "-n" ]; then
+ exclude=$2
+ shift 2
+ fi
+ __git_reassemble_comp_words_by_ref "$exclude"
+ cur_=${words_[cword_]}
while [ $# -gt 0 ]; do
case "$1" in
cur)
- cur=${COMP_WORDS[COMP_CWORD]}
+ cur=$cur_
;;
prev)
- prev=${COMP_WORDS[COMP_CWORD-1]}
+ prev=${words_[$cword_-1]}
;;
words)
- words=("${COMP_WORDS[@]}")
+ words=("${words_[@]}")
;;
cword)
- cword=$COMP_CWORD
- ;;
- -n)
- # assume COMP_WORDBREAKS is already set sanely
- shift
+ cword=$cword_
;;
esac
shift
--
1.7.3.3.573.g0bcfc
^ permalink raw reply related
* [PATCH 1/3] bash: get --pretty=m<tab> completion to work with bash v4
From: Jonathan Nieder @ 2010-12-15 6:26 UTC (permalink / raw)
To: Junio C Hamano
Cc: SZEDER Gábor, Peter van der Does, Shawn O. Pearce, git,
Marc Branchaud, Brian Gernhardt, Kevin Ballard, Mathias Lafeldt,
Stephen Boyd
In-Reply-To: <20101215062403.GA20492@burratino>
From: Peter van der Does <peter@avirtualhome.com>
Bash's programmable completion provides the COMP_WORDS array variable,
which holds the individual words in the current command line. In bash
versions prior to v4 "words are split on shell metacharacters as the
shell parser would separate them" (quote from bash v3.2.48's man
page). This behavior has changed with bash v4, and the command line
"is split into words as readline would split it, using COMP_WORDBREAKS
as" "the set of characters that the readline library treats as word
separators" (quote from bash v4's man page).
Since COMP_WORDBREAKS contains the characters : and = by default, this
behavior change in bash affects git's completion script. For example,
before bash 4, running
$ git log --pretty=m <tab><tab>
would give a list of pretty-printing formats starting with 'm' but now
it completes on branch names.
It would be possible to work around this by removing '=' and ':' from
COMP_WORDBREAKS, but as noticed in v1.5.6.4~9^2 (bash completion:
Resolve git show ref:path<tab> losing ref: portion, 2008-07-15), that
would break *other* completion scripts. The bash-completion library
includes a better workaround: the _get_comp_words_by_ref function
re-assembles a copy of COMP_WORDS, excluding a collection of word
separators of the caller's choice. Use it.
As a bonus, this improves behavior when tab is pressed with the cursor
in the middle of a word if the bash-completion lib is loaded.
To avoid breaking setups with the bash-completion library not already
loaded, if the _get_comp_words_by_ref function is not defined then use
a shim that just reads COMP_WORDS instead (no change from the current
behavior in that case).
Signed-off-by: Peter van der Does <peter@avirtualhome.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Explained-by: SZEDER Gábor <szeder@ira.uka.de>
---
contrib/completion/git-completion.bash | 236 +++++++++++++++++++++----------
1 files changed, 160 insertions(+), 76 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 82e6609..68b68d0 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -321,11 +321,39 @@ __gitcomp_1 ()
done
}
+if ! type _get_comp_words_by_ref >/dev/null 2>&1; then
+_get_comp_words_by_ref ()
+{
+ while [ $# -gt 0 ]; do
+ case "$1" in
+ cur)
+ cur=${COMP_WORDS[COMP_CWORD]}
+ ;;
+ prev)
+ prev=${COMP_WORDS[COMP_CWORD-1]}
+ ;;
+ words)
+ words=("${COMP_WORDS[@]}")
+ ;;
+ cword)
+ cword=$COMP_CWORD
+ ;;
+ -n)
+ # assume COMP_WORDBREAKS is already set sanely
+ shift
+ ;;
+ esac
+ shift
+ done
+}
+fi
+
# __gitcomp accepts 1, 2, 3, or 4 arguments
# generates completion reply with compgen
__gitcomp ()
{
- local cur="${COMP_WORDS[COMP_CWORD]}"
+ local cur
+ _get_comp_words_by_ref -n =: cur
if [ $# -gt 2 ]; then
cur="$3"
fi
@@ -384,7 +412,8 @@ __git_tags ()
__git_refs ()
{
local i is_hash=y dir="$(__gitdir "${1-}")"
- local cur="${COMP_WORDS[COMP_CWORD]}" format refs
+ local cur format refs
+ _get_comp_words_by_ref -n =: cur
if [ -d "$dir" ]; then
case "$cur" in
refs|refs/*)
@@ -482,7 +511,8 @@ __git_compute_merge_strategies ()
__git_complete_file ()
{
- local pfx ls ref cur="${COMP_WORDS[COMP_CWORD]}"
+ local pfx ls ref cur
+ _get_comp_words_by_ref -n =: cur
case "$cur" in
?*:*)
ref="${cur%%:*}"
@@ -530,7 +560,8 @@ __git_complete_file ()
__git_complete_revlist ()
{
- local pfx cur="${COMP_WORDS[COMP_CWORD]}"
+ local pfx cur
+ _get_comp_words_by_ref -n =: cur
case "$cur" in
*...*)
pfx="${cur%...*}..."
@@ -550,11 +581,12 @@ __git_complete_revlist ()
__git_complete_remote_or_refspec ()
{
- local cmd="${COMP_WORDS[1]}"
- local cur="${COMP_WORDS[COMP_CWORD]}"
+ local cur words cword
+ _get_comp_words_by_ref -n =: cur words cword
+ local cmd="${words[1]}"
local i c=2 remote="" pfx="" lhs=1 no_complete_refspec=0
- while [ $c -lt $COMP_CWORD ]; do
- i="${COMP_WORDS[c]}"
+ while [ $c -lt $cword ]; do
+ i="${words[c]}"
case "$i" in
--mirror) [ "$cmd" = "push" ] && no_complete_refspec=1 ;;
--all)
@@ -622,13 +654,14 @@ __git_complete_remote_or_refspec ()
__git_complete_strategy ()
{
+ local cur prev
+ _get_comp_words_by_ref -n =: cur prev
__git_compute_merge_strategies
- case "${COMP_WORDS[COMP_CWORD-1]}" in
+ case "$prev" in
-s|--strategy)
__gitcomp "$__git_merge_strategies"
return 0
esac
- local cur="${COMP_WORDS[COMP_CWORD]}"
case "$cur" in
--strategy=*)
__gitcomp "$__git_merge_strategies" "" "${cur##--strategy=}"
@@ -788,10 +821,10 @@ __git_aliased_command ()
# __git_find_on_cmdline requires 1 argument
__git_find_on_cmdline ()
{
- local word subcommand c=1
-
- while [ $c -lt $COMP_CWORD ]; do
- word="${COMP_WORDS[c]}"
+ local word subcommand c=1 words cword
+ _get_comp_words_by_ref -n =: words cword
+ while [ $c -lt $cword ]; do
+ word="${words[c]}"
for subcommand in $1; do
if [ "$subcommand" = "$word" ]; then
echo "$subcommand"
@@ -804,9 +837,10 @@ __git_find_on_cmdline ()
__git_has_doubledash ()
{
- local c=1
- while [ $c -lt $COMP_CWORD ]; do
- if [ "--" = "${COMP_WORDS[c]}" ]; then
+ local c=1 words cword
+ _get_comp_words_by_ref -n =: words cword
+ while [ $c -lt $cword ]; do
+ if [ "--" = "${words[c]}" ]; then
return 0
fi
c=$((++c))
@@ -818,7 +852,8 @@ __git_whitespacelist="nowarn warn error error-all fix"
_git_am ()
{
- local cur="${COMP_WORDS[COMP_CWORD]}" dir="$(__gitdir)"
+ local cur dir="$(__gitdir)"
+ _get_comp_words_by_ref -n =: cur
if [ -d "$dir"/rebase-apply ]; then
__gitcomp "--skip --continue --resolved --abort"
return
@@ -842,7 +877,8 @@ _git_am ()
_git_apply ()
{
- local cur="${COMP_WORDS[COMP_CWORD]}"
+ local cur
+ _get_comp_words_by_ref -n =: cur
case "$cur" in
--whitespace=*)
__gitcomp "$__git_whitespacelist" "" "${cur##--whitespace=}"
@@ -865,7 +901,8 @@ _git_add ()
{
__git_has_doubledash && return
- local cur="${COMP_WORDS[COMP_CWORD]}"
+ local cur
+ _get_comp_words_by_ref -n =: cur
case "$cur" in
--*)
__gitcomp "
@@ -879,7 +916,8 @@ _git_add ()
_git_archive ()
{
- local cur="${COMP_WORDS[COMP_CWORD]}"
+ local cur
+ _get_comp_words_by_ref -n =: cur
case "$cur" in
--format=*)
__gitcomp "$(git archive --list)" "" "${cur##--format=}"
@@ -923,10 +961,11 @@ _git_bisect ()
_git_branch ()
{
- local i c=1 only_local_ref="n" has_r="n"
+ local i c=1 only_local_ref="n" has_r="n" cur words cword
- while [ $c -lt $COMP_CWORD ]; do
- i="${COMP_WORDS[c]}"
+ _get_comp_words_by_ref -n =: cur words cword
+ while [ $c -lt $cword ]; do
+ i="${words[c]}"
case "$i" in
-d|-m) only_local_ref="y" ;;
-r) has_r="y" ;;
@@ -934,7 +973,7 @@ _git_branch ()
c=$((++c))
done
- case "${COMP_WORDS[COMP_CWORD]}" in
+ case "$cur" in
--*)
__gitcomp "
--color --no-color --verbose --abbrev= --no-abbrev
@@ -954,8 +993,10 @@ _git_branch ()
_git_bundle ()
{
- local cmd="${COMP_WORDS[2]}"
- case "$COMP_CWORD" in
+ local words cword
+ _get_comp_words_by_ref -n =: words cword
+ local cmd="${words[2]}"
+ case "$cword" in
2)
__gitcomp "create list-heads verify unbundle"
;;
@@ -976,7 +1017,8 @@ _git_checkout ()
{
__git_has_doubledash && return
- local cur="${COMP_WORDS[COMP_CWORD]}"
+ local cur
+ _get_comp_words_by_ref -n =: cur
case "$cur" in
--conflict=*)
__gitcomp "diff3 merge" "" "${cur##--conflict=}"
@@ -1000,7 +1042,8 @@ _git_cherry ()
_git_cherry_pick ()
{
- local cur="${COMP_WORDS[COMP_CWORD]}"
+ local cur
+ _get_comp_words_by_ref -n =: cur
case "$cur" in
--*)
__gitcomp "--edit --no-commit"
@@ -1015,7 +1058,8 @@ _git_clean ()
{
__git_has_doubledash && return
- local cur="${COMP_WORDS[COMP_CWORD]}"
+ local cur
+ _get_comp_words_by_ref -n =: cur
case "$cur" in
--*)
__gitcomp "--dry-run --quiet"
@@ -1027,7 +1071,8 @@ _git_clean ()
_git_clone ()
{
- local cur="${COMP_WORDS[COMP_CWORD]}"
+ local cur
+ _get_comp_words_by_ref -n =: cur
case "$cur" in
--*)
__gitcomp "
@@ -1054,7 +1099,8 @@ _git_commit ()
{
__git_has_doubledash && return
- local cur="${COMP_WORDS[COMP_CWORD]}"
+ local cur
+ _get_comp_words_by_ref -n =: cur
case "$cur" in
--cleanup=*)
__gitcomp "default strip verbatim whitespace
@@ -1089,7 +1135,8 @@ _git_commit ()
_git_describe ()
{
- local cur="${COMP_WORDS[COMP_CWORD]}"
+ local cur
+ _get_comp_words_by_ref -n =: cur
case "$cur" in
--*)
__gitcomp "
@@ -1121,7 +1168,8 @@ _git_diff ()
{
__git_has_doubledash && return
- local cur="${COMP_WORDS[COMP_CWORD]}"
+ local cur
+ _get_comp_words_by_ref -n =: cur
case "$cur" in
--*)
__gitcomp "--cached --staged --pickaxe-all --pickaxe-regex
@@ -1142,7 +1190,8 @@ _git_difftool ()
{
__git_has_doubledash && return
- local cur="${COMP_WORDS[COMP_CWORD]}"
+ local cur
+ _get_comp_words_by_ref -n =: cur
case "$cur" in
--tool=*)
__gitcomp "$__git_mergetools_common kompare" "" "${cur##--tool=}"
@@ -1167,7 +1216,8 @@ __git_fetch_options="
_git_fetch ()
{
- local cur="${COMP_WORDS[COMP_CWORD]}"
+ local cur
+ _get_comp_words_by_ref -n =: cur
case "$cur" in
--*)
__gitcomp "$__git_fetch_options"
@@ -1179,7 +1229,8 @@ _git_fetch ()
_git_format_patch ()
{
- local cur="${COMP_WORDS[COMP_CWORD]}"
+ local cur
+ _get_comp_words_by_ref -n =: cur
case "$cur" in
--thread=*)
__gitcomp "
@@ -1211,7 +1262,8 @@ _git_format_patch ()
_git_fsck ()
{
- local cur="${COMP_WORDS[COMP_CWORD]}"
+ local cur
+ _get_comp_words_by_ref -n =: cur
case "$cur" in
--*)
__gitcomp "
@@ -1226,7 +1278,8 @@ _git_fsck ()
_git_gc ()
{
- local cur="${COMP_WORDS[COMP_CWORD]}"
+ local cur
+ _get_comp_words_by_ref -n =: cur
case "$cur" in
--*)
__gitcomp "--prune --aggressive"
@@ -1245,7 +1298,8 @@ _git_grep ()
{
__git_has_doubledash && return
- local cur="${COMP_WORDS[COMP_CWORD]}"
+ local cur
+ _get_comp_words_by_ref -n =: cur
case "$cur" in
--*)
__gitcomp "
@@ -1268,7 +1322,8 @@ _git_grep ()
_git_help ()
{
- local cur="${COMP_WORDS[COMP_CWORD]}"
+ local cur
+ _get_comp_words_by_ref -n =: cur
case "$cur" in
--*)
__gitcomp "--all --info --man --web"
@@ -1286,7 +1341,8 @@ _git_help ()
_git_init ()
{
- local cur="${COMP_WORDS[COMP_CWORD]}"
+ local cur
+ _get_comp_words_by_ref -n =: cur
case "$cur" in
--shared=*)
__gitcomp "
@@ -1306,7 +1362,8 @@ _git_ls_files ()
{
__git_has_doubledash && return
- local cur="${COMP_WORDS[COMP_CWORD]}"
+ local cur
+ _get_comp_words_by_ref -n =: cur
case "$cur" in
--*)
__gitcomp "--cached --deleted --modified --others --ignored
@@ -1360,12 +1417,13 @@ _git_log ()
{
__git_has_doubledash && return
- local cur="${COMP_WORDS[COMP_CWORD]}"
local g="$(git rev-parse --git-dir 2>/dev/null)"
local merge=""
if [ -f "$g/MERGE_HEAD" ]; then
merge="--merge"
fi
+ local cur
+ _get_comp_words_by_ref -n =: cur
case "$cur" in
--pretty=*)
__gitcomp "$__git_log_pretty_formats
@@ -1419,7 +1477,8 @@ _git_merge ()
{
__git_complete_strategy && return
- local cur="${COMP_WORDS[COMP_CWORD]}"
+ local cur
+ _get_comp_words_by_ref -n =: cur
case "$cur" in
--*)
__gitcomp "$__git_merge_options"
@@ -1430,7 +1489,8 @@ _git_merge ()
_git_mergetool ()
{
- local cur="${COMP_WORDS[COMP_CWORD]}"
+ local cur
+ _get_comp_words_by_ref -n =: cur
case "$cur" in
--tool=*)
__gitcomp "$__git_mergetools_common tortoisemerge" "" "${cur##--tool=}"
@@ -1451,7 +1511,8 @@ _git_merge_base ()
_git_mv ()
{
- local cur="${COMP_WORDS[COMP_CWORD]}"
+ local cur
+ _get_comp_words_by_ref -n =: cur
case "$cur" in
--*)
__gitcomp "--dry-run"
@@ -1469,12 +1530,14 @@ _git_name_rev ()
_git_notes ()
{
local subcommands="edit show"
+ local words cword
+ _get_comp_words_by_ref -n =: words cword
if [ -z "$(__git_find_on_cmdline "$subcommands")" ]; then
__gitcomp "$subcommands"
return
fi
- case "${COMP_WORDS[COMP_CWORD-1]}" in
+ case "${words[cword-1]}" in
-m|-F)
COMPREPLY=()
;;
@@ -1488,7 +1551,8 @@ _git_pull ()
{
__git_complete_strategy && return
- local cur="${COMP_WORDS[COMP_CWORD]}"
+ local cur
+ _get_comp_words_by_ref -n =: cur
case "$cur" in
--*)
__gitcomp "
@@ -1504,8 +1568,9 @@ _git_pull ()
_git_push ()
{
- local cur="${COMP_WORDS[COMP_CWORD]}"
- case "${COMP_WORDS[COMP_CWORD-1]}" in
+ local cur prev
+ _get_comp_words_by_ref -n =: cur prev
+ case "$prev" in
--repo)
__gitcomp "$(__git_remotes)"
return
@@ -1528,7 +1593,9 @@ _git_push ()
_git_rebase ()
{
- local cur="${COMP_WORDS[COMP_CWORD]}" dir="$(__gitdir)"
+ local dir="$(__gitdir)"
+ local cur
+ _get_comp_words_by_ref -n =: cur
if [ -d "$dir"/rebase-apply ] || [ -d "$dir"/rebase-merge ]; then
__gitcomp "--continue --skip --abort"
return
@@ -1558,7 +1625,8 @@ __git_send_email_suppresscc_options="author self cc bodycc sob cccmd body all"
_git_send_email ()
{
- local cur="${COMP_WORDS[COMP_CWORD]}"
+ local cur
+ _get_comp_words_by_ref -n =: cur
case "$cur" in
--confirm=*)
__gitcomp "
@@ -1600,9 +1668,11 @@ _git_stage ()
__git_config_get_set_variables ()
{
- local prevword word config_file= c=$COMP_CWORD
+ local words cword
+ _get_comp_words_by_ref -n =: words cword
+ local prevword word config_file= c=$cword
while [ $c -gt 1 ]; do
- word="${COMP_WORDS[c]}"
+ word="${words[c]}"
case "$word" in
--global|--system|--file=*)
config_file="$word"
@@ -1630,9 +1700,9 @@ __git_config_get_set_variables ()
_git_config ()
{
- local cur="${COMP_WORDS[COMP_CWORD]}"
- local prv="${COMP_WORDS[COMP_CWORD-1]}"
- case "$prv" in
+ local cur prev
+ _get_comp_words_by_ref -n =: cur prev
+ case "$prev" in
branch.*.remote)
__gitcomp "$(__git_remotes)"
return
@@ -1642,13 +1712,13 @@ _git_config ()
return
;;
remote.*.fetch)
- local remote="${prv#remote.}"
+ local remote="${prev#remote.}"
remote="${remote%.fetch}"
__gitcomp "$(__git_refs_remotes "$remote")"
return
;;
remote.*.push)
- local remote="${prv#remote.}"
+ local remote="${prev#remote.}"
remote="${remote%.push}"
__gitcomp "$(git --git-dir="$(__gitdir)" \
for-each-ref --format='%(refname):%(refname)' \
@@ -2039,7 +2109,8 @@ _git_reset ()
{
__git_has_doubledash && return
- local cur="${COMP_WORDS[COMP_CWORD]}"
+ local cur
+ _get_comp_words_by_ref -n =: cur
case "$cur" in
--*)
__gitcomp "--merge --mixed --hard --soft --patch"
@@ -2051,7 +2122,8 @@ _git_reset ()
_git_revert ()
{
- local cur="${COMP_WORDS[COMP_CWORD]}"
+ local cur
+ _get_comp_words_by_ref -n =: cur
case "$cur" in
--*)
__gitcomp "--edit --mainline --no-edit --no-commit --signoff"
@@ -2065,7 +2137,8 @@ _git_rm ()
{
__git_has_doubledash && return
- local cur="${COMP_WORDS[COMP_CWORD]}"
+ local cur
+ _get_comp_words_by_ref -n =: cur
case "$cur" in
--*)
__gitcomp "--cached --dry-run --ignore-unmatch --quiet"
@@ -2079,7 +2152,8 @@ _git_shortlog ()
{
__git_has_doubledash && return
- local cur="${COMP_WORDS[COMP_CWORD]}"
+ local cur
+ _get_comp_words_by_ref -n =: cur
case "$cur" in
--*)
__gitcomp "
@@ -2097,7 +2171,8 @@ _git_show ()
{
__git_has_doubledash && return
- local cur="${COMP_WORDS[COMP_CWORD]}"
+ local cur
+ _get_comp_words_by_ref -n =: cur
case "$cur" in
--pretty=*)
__gitcomp "$__git_log_pretty_formats
@@ -2121,7 +2196,8 @@ _git_show ()
_git_show_branch ()
{
- local cur="${COMP_WORDS[COMP_CWORD]}"
+ local cur
+ _get_comp_words_by_ref -n =: cur
case "$cur" in
--*)
__gitcomp "
@@ -2138,7 +2214,8 @@ _git_show_branch ()
_git_stash ()
{
- local cur="${COMP_WORDS[COMP_CWORD]}"
+ local cur
+ _get_comp_words_by_ref -n =: cur
local save_opts='--keep-index --no-keep-index --quiet --patch'
local subcommands='save list show apply clear drop pop create branch'
local subcommand="$(__git_find_on_cmdline "$subcommands")"
@@ -2183,7 +2260,8 @@ _git_submodule ()
local subcommands="add status init update summary foreach sync"
if [ -z "$(__git_find_on_cmdline "$subcommands")" ]; then
- local cur="${COMP_WORDS[COMP_CWORD]}"
+ local cur
+ _get_comp_words_by_ref -n =: cur
case "$cur" in
--*)
__gitcomp "--quiet --cached"
@@ -2227,7 +2305,8 @@ _git_svn ()
--edit --rmdir --find-copies-harder --copy-similarity=
"
- local cur="${COMP_WORDS[COMP_CWORD]}"
+ local cur
+ _get_comp_words_by_ref -n =: cur
case "$subcommand,$cur" in
fetch,--*)
__gitcomp "--revision= --fetch-all $fc_opts"
@@ -2299,8 +2378,10 @@ _git_svn ()
_git_tag ()
{
local i c=1 f=0
- while [ $c -lt $COMP_CWORD ]; do
- i="${COMP_WORDS[c]}"
+ local words cword prev
+ _get_comp_words_by_ref -n =: words cword prev
+ while [ $c -lt $cword ]; do
+ i="${words[c]}"
case "$i" in
-d|-v)
__gitcomp "$(__git_tags)"
@@ -2313,7 +2394,7 @@ _git_tag ()
c=$((++c))
done
- case "${COMP_WORDS[COMP_CWORD-1]}" in
+ case "$prev" in
-m|-F)
COMPREPLY=()
;;
@@ -2339,8 +2420,10 @@ _git ()
{
local i c=1 command __git_dir
- while [ $c -lt $COMP_CWORD ]; do
- i="${COMP_WORDS[c]}"
+ local cur words cword
+ _get_comp_words_by_ref -n =: cur words cword
+ while [ $c -lt $cword ]; do
+ i="${words[c]}"
case "$i" in
--git-dir=*) __git_dir="${i#--git-dir=}" ;;
--bare) __git_dir="." ;;
@@ -2352,7 +2435,7 @@ _git ()
done
if [ -z "$command" ]; then
- case "${COMP_WORDS[COMP_CWORD]}" in
+ case "$cur" in
--*) __gitcomp "
--paginate
--no-pager
@@ -2385,12 +2468,13 @@ _gitk ()
{
__git_has_doubledash && return
- local cur="${COMP_WORDS[COMP_CWORD]}"
+ local cur
local g="$(__gitdir)"
local merge=""
if [ -f "$g/MERGE_HEAD" ]; then
merge="--merge"
fi
+ _get_comp_words_by_ref -n =: cur
case "$cur" in
--*)
__gitcomp "
--
1.7.3.3.573.g0bcfc
^ permalink raw reply related
* [PATCH v5.1 0/3] Make git-completion Bash 4 compatible
From: Jonathan Nieder @ 2010-12-15 6:24 UTC (permalink / raw)
To: Junio C Hamano
Cc: SZEDER Gábor, Peter van der Does, Shawn O. Pearce, git,
Marc Branchaud, Brian Gernhardt, Kevin Ballard, Mathias Lafeldt,
Stephen Boyd
In-Reply-To: <7v1v5tpa7b.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
>>> On Thu, Dec 02, 2010 at 03:02:07PM -0600, Jonathan Nieder wrote:
>>>> Add a minimal implementation of _get_comp_words_by_ref,
>>>> the routine used to work around bash 4.0's COMP_WORDS semantics.
>>>>
>>>> Based on bash-completion 2.x (commit bf763033, 2010-10-26) but
>>>> tweaked for simplicity and to allow zsh to at least parse the
>>>> code.
[...]
> Sorry, but whose repository does that object live in?
Agh, sorry for the mess. Please fetch
git://repo.or.cz/git/jrn.git pd/bash-4-completion
to receive the following history:
o [maint-1.7.2] --- A --- B --- M [FETCH_HEAD]
/
o [master (early part)]
[A] bash: get --pretty=m<tab> completion to work with bash v4
(by Peter)
[B] bash: simple reimplementation of _get_comp_words_by_ref
(discussed above)
[M] Merge branch 'master' (early part) into pd/bash-4-completion
(zsh compatibility)
[master (early part)] completion: fix zsh check under bash with 'set -u'
(2010-10-28 11:45:00 -0700).
A and B are the patches sent previously in this thread, rebased on an
older code base to avoid the zsh support. A combined diff for the
merge 'M' will follow. Thoughts, suggestions, acks, test reports
would be welcome.
Thanks for your patience.
Jonathan
^ permalink raw reply
* html userdiff is not showing all my changes
From: Scott Johnson @ 2010-12-15 3:47 UTC (permalink / raw)
To: git, trast
I am attempting to do a word diff of an html source file. Part of the removed
html is disappearing from the diff when I enable the fancy html word diff.
Here's the output from basic `git diff`:
diff --git a/adv_layout_source.html b/adv_layout_source.html
index 18a81dd..c4ed609 100644
--- a/adv_layout_source.html
+++ b/adv_layout_source.html
@@ -42,8 +42,8 @@
<ul>
<li class="ydn-patterns"><em></em><a href="#">ydn-patterns</a></li>
<li class="ydn-mail"><em></em><a href="#">ydn-mail</a></li>
- <li class="yws-maps"><em></em><a href="#">yws-maps</a></li>
- <li class="ydn-delicious"><em></em><a href="#">ydn-delicious</a></li>
+ <li><em></em><a href="#">yws-maps</a></li>
+ <li><em></em><a href="#">ydn-delicious</a></li>
<li class="yws-flickr"><em></em><a href="#">yws-flickr</a></li>
<li class="yws-events"><em></em><a href="#">yws-events</a></li>
</ul>
Here's the default `git diff --word-diff`:
diff --git a/adv_layout_source.html b/adv_layout_source.html
index 18a81dd..c4ed609 100644
--- a/adv_layout_source.html
+++ b/adv_layout_source.html
@@ -42,8 +42,8 @@
<ul>
<li class="ydn-patterns"><em></em><a href="#">ydn-patterns</a></li>
<li class="ydn-mail"><em></em><a href="#">ydn-mail</a></li>
[-<li class="yws-maps"><em></em><a-]{+<li><em></em><a+}
href="#">yws-maps</a></li>
[-<li class="ydn-delicious"><em></em><a-]{+<li><em></em><a+}
href="#">ydn-delicious</a></li>
<li class="yws-flickr"><em></em><a href="#">yws-flickr</a></li>
<li class="yws-events"><em></em><a href="#">yws-events</a></li>
</ul>
Which is correct, but less than ideal because it highlights much more than the
actual changes.
So I create a .gitattributes file with one line:
*.html diff=html
And rerun `git diff --word-diff`:
diff --git a/adv_layout_source.html b/adv_layout_source.html
index 18a81dd..c4ed609 100644
--- a/adv_layout_source.html
+++ b/adv_layout_source.html
@@ -42,8 +42,8 @@
<ul>
<li class="ydn-patterns"><em></em><a href="#">ydn-patterns</a></li>
<li class="ydn-mail"><em></em><a href="#">ydn-mail</a></li>
<li[-class="yws-maps"-]><em></em><a href="#">yws-maps</a></li>
<li><em></em><a href="#">ydn-delicious</a></li>
<li class="yws-flickr"><em></em><a href="#">yws-flickr</a></li>
<li class="yws-events"><em></em><a href="#">yws-events</a></li>
</ul>
Yikes! What happened to the second line of changes? The removed code is not
displayed at all.
This is running git 1.7.3.3.
I suspect the problem is in the html patterns in userdiff.c, but I don't
understand the word-diff-regex well enough to fix it.
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox