Re: git log: Add a switch to limit the number of displayed lines from the commit messages

Junio C Hamano wrote: > Or inside "less" that is spawned by "git log -p", I often say this: > > /^commit .*|^diff --git .* > > and navigate with 'n' and 'p'. Hm, that implies an interesting trick. If I run LESS='FRSX +/^commit |^diff --git ' git log -p then 'n' and shift+'n' can be

nike high heels online shop

nike high heels online shop Flugreisen weitestgehend weiterhin wiedergeboren einmal mehr, die Ware einige exquisite Leichtathletik nike air passt größten britischen Schuh Layout werden. Wir haben gesehen, Nike geschieht zu tun brauchen in diesen Tage

[bug, git-svn] error: too many matches for svn-remote.svn.added-placeholder

When trying to clone a big svn repository using git-svn, with many empty folders, after a while I started getting many "error: too many matches for svn-remote.svn.added-placeholder" errors. The following url has a suggestion for a temporary fix: http://stackoverflow.com/questions/14512292/git-svn-

Nike Free Run

Nike Free Run 2 Es ist immer wieder erstaunlich, welche eine Menge Käufer behaupten die Schuhe eine gute Sache. Der Hersteller, die Nike Eigenkapital umfasst jeder der den noch dazu führt, daß die Ware zuverlässig und begehrt. Wenn Sie ein Ergebnis gibt, durch

Re: [PATCH] mergetool--lib: refactor {diff,merge}_cmd logic

On Sun, Jun 16, 2013 at 10:51 AM, John Keeping wrote: > Instead of needing a wrapper to call the diff/merge command, simply > provide the diff_cmd and merge_cmd functions for user-specified tools in > the same way as we do for built-in tools. > > Signed-off-by: John Keeping > --- This is a nice

Re: [PATCH v2 0/6] Fix checkout-dash to work with rebase

Ramkumar Ramachandra writes: > So after extensive discussions with Junio, I have updated [5/6] to > special-case rebase and rebase -i instead of dropping the "HEAD > detached from" message altogether. Also, [1/6] includes two more > tests, as suggested by Junio. > > Junio: The message is now the

Re: REQUEST PULL: git-gui

Pulled (but I won't really work on Sunday night so the integration and pushout will be done tomorrow). Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: git log: Add a switch to limit the number of displayed lines from the commit messages

Jonathan Nieder writes: >> there are people out there disliking elaborate commit messages, as going >> over `git log` is tedious as you have to scroll a lot. As I do not like >> the suggestion to make commit messages shorter by omitting certain >> details, a way to limit the number displayed line

[PATCH] wt-status: give better advice when cherry-pick is in progress

When cherry-pick is in progress, 'git status' gives the advice to run "git commit" to finish the cherry-pick. However, this won't continue the sequencer. "git status" should give the advice of running "git cherry-pick --continue" or "git cherry-pick --abort". Signed-off-by: Ralf Thielow --- t/t7

Re: [PATCH/RFC 1/3] t9903: add tests for git-prompt pcmode

"Eduardo R. D'Avila" writes: > git-prompt.sh lacks tests for PROMPT_COMMAND mode. > > Add tests for: > * pcmode prompt without colors > * pcmode prompt with colors for bash > * pcmode prompt with colors for zsh > > Having these tests enables an upcoming refactor in > a safe way. > > Signed-off-by

Re: [PATCH] config doc: rewrite push.default section

Ramkumar Ramachandra writes: > Design by Junio. Not necessary. The conclusion of discussion is a result of collaboration. Thanks for writing it down. It is a good start, but I agree with reviews by Philip Oakley and Matthieu Moy we already saw. - To understand "if central, works as upstre

Re: [PATCH 1/2] show-ref.c: Add missing call to git_config()

Ramsay Jones writes: > At present, 'git show-ref' ignores any attempt to set config > variables (e.g. core.checkstat) from the command line using > the -c option to git. I think what you really want to see is not giving "-c" and have it honored. "git show-ref" does not honor configurati

Re: [PATCH 0/2] Slightly prettier reflog message from checkout

Ramkumar Ramachandra writes: > Junio C Hamano wrote: >> I view the two codepaths touched by these patches the other way >> around. > > I see. Thanks for the early feedback. I have some doubts. > >> An abbreviated unique SHA-1 you have today may not be unique >> tomorrow. > When did we guarante

Re: [PATCH 3/3] rebase: use peel_committish() where appropriate

Ramkumar Ramachandra writes: > Junio C Hamano wrote: >> You can also specify the commit at the end of the history to be >> rebased (very useful while trial runs to see where a series should >> apply): >> >> git rebase foo ":/Add B" >> >> This is already handled properly because it first gets

Re: [PATCH v3 1/2] am: handle stray $dotest directory

Ramkumar Ramachandra writes: > else > + # Possible stray $dotest directory in the independent-run > + # case; in the --rebasing case, it is upto the caller > + # (git-rebase--am) to take care of stray directories. > + if test -d "$dotest" && test -z "$rebasing" The $rebasing var

Re: [PATCH] rebase -i: fixup fixup! fixup!

Thomas Rast writes: > Isn't it a bit of an academic question? > ... > And once you have that, it seems a nicer and cleaner idea to generate > 'fixup! A' each time, instead of a successive sequence of > > fixup! A > fixup! fixup! A > fixup! fixup! fixup! A > ... As to reordering, you are

[RFC] speed up git submodule

I've been playing a bit with lua. It's an embedded scripting language with strong c integration. It's small and fast. The interesting feature would be to run C-functions direct inside lua. I suppose that would increase speed even more, at the same time as we have the convinence of a interpreted la

Re: [PATCH V3 1/4] git-mw: Introduction of GitMediawiki.pm

On 16 June 2013 22:18, Matthieu Moy wrote: > benoit.per...@ensimag.fr writes: > >> changes from the V2: >> - Add a way to test, without installation, code that uses GitMediawiki.pm. > > This still needs to be documented, even very quickly, somewhere in the > code (e.g a comment in the Makefile).

Re: English/German terminology, git.git's de.po, and pro-git

On Thursday 2013-05-23 20:16, Bernhard R. Link wrote: >> >> Not sure if German users would know what "hunk" means, in case we >> leave it untranslated. And I'm not sure if I would understand "Kontext". >> I tend to leave it untranslated. > >Anyone found a German translation of the Patch manpage? T

Re: [PATCH RFC] git-remote-mediawiki: push-by-rev

Célestin Matte writes: > This uses subroutines used by the fetch-by-rev strategy. I'm not sure it's > actually complete: can it be that simple? The function says: # Get the last remote revision without taking in account which pages are # tracked or not. This function makes a single request

Re: [PATCH V3 4/4] git-mw: Add preview subcommand into git mw.

[ Just a quick look, no time for a detailed review ] benoit.per...@ensimag.fr writes: > From: Benoit Person > > Add the subcommand to 'git-mw.perl'. That's already said in the Subject field. > Add a new constant in GitMediawiki.pm 'HTTP_CODE_PAGE_NOT_FOUND'. And this brings zero information c

[PATCH RFC] git-remote-mediawiki: push-by-rev

From: Célestin Matte Add the push-by-rev option This allows one to look for changes by revision instead of by page. The result is a much faster push on little-activity wikis. Indeed, instead of sending one request by page to check that the remote revision is our local latest revision, we only sen

[PATCH RFC] git-remote-mediawiki: push-by-rev

From: Célestin Matte This patch intends to introduce the by_rev strategy for the push command, as already available for the fetch one. This uses subroutines used by the fetch-by-rev strategy. I'm not sure it's actually complete: can it be that simple? However, I tested on a local wiki and it seem

Re: [PATCH V3 1/4] git-mw: Introduction of GitMediawiki.pm

benoit.per...@ensimag.fr writes: > changes from the V2: > - Add a way to test, without installation, code that uses GitMediawiki.pm. This still needs to be documented, even very quickly, somewhere in the code (e.g a comment in the Makefile). > -build install clean: > +copy_pm: > + cp $(GIT

Re: [PATCH/RFC 3/4] git-mw: Adding git-mw.perl script

Benoît Person writes: >> I think you need an equivalent of Git's toplevel bin-wrappers/git, or >> perhaps use the same bin-wrapper/git but let "make install" in >> contrib/mw-to-git/ install GitMediawiki.pm in perl/blib/lib > Typo s/make install/make/ ? Yes. > For that one, I am not really sure

Re: [PATCH] config doc: rewrite push.default section

Ramkumar Ramachandra writes: > +* `current` - push the refspec "$HEAD". HEAD is resolved early to a > + branch name (referred to as $HEAD). In other words, push the > + current branch to update a branch with the same name on the pushing > + side. I'd put it the other way around: the intuiti

[PATCH] mergetool--lib: refactor {diff,merge}_cmd logic

Instead of needing a wrapper to call the diff/merge command, simply provide the diff_cmd and merge_cmd functions for user-specified tools in the same way as we do for built-in tools. Signed-off-by: John Keeping --- git-mergetool--lib.sh | 82 ++- 1

[PATCH/RFC 1/3] t9903: add tests for git-prompt pcmode

git-prompt.sh lacks tests for PROMPT_COMMAND mode. Add tests for: * pcmode prompt without colors * pcmode prompt with colors for bash * pcmode prompt with colors for zsh Having these tests enables an upcoming refactor in a safe way. Signed-off-by: Eduardo R. D'Avila --- 250 0 t/t9903-

[PATCH/RFC 3/3] git-prompt.sh: enable color prompt in non-pcmode

The use of colors in a prompt is only possible in pcmode (using the variable PROMPT_COMMAND). Enable color prompt in non-pcmode (using the variable PS1) for both Bash and ZSH. Signed-off-by: Eduardo R. D'Avila --- 15 9 contrib/completion/git-prompt.sh 19 0 t/t9903-bash-prom

[PATCH/RFC 2/3] git-prompt.sh: refactor colored prompt code

Remove duplication of logic to build gitstring. __git_ps1_colorize_gitstring() sets color codes and builds the prompt gitstring. It has duplicated code to handle color codes for bash and zsh shells. __git_ps1() also has duplicated logic to build the prompt gitstring. Remove duplication of logic t

[PATCH/RFC 0/3] enable color prompt in non-pcmode

The use of colors in a prompt is only possible in pcmode (using the variable PROMPT_COMMAND). Make color prompt work in non-pcmode (using the variable PS1) for both Bash and ZSH. This requires editing __git_ps1() and __git_ps1_colorize_gitstring(), which have duplicate code to handle the prompt g

[PATCH 2/2] Documentation/Makefile: move infodir to be with other '*dir's

Signed-off-by: John Keeping --- Documentation/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/Makefile b/Documentation/Makefile index af3d8a4..0cfdc36 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -81,6 +81,7 @@ DOC_MAN7 = $(patsubs

[PATCH 1/2] Documentation/Makefile: fix spaces around assignments

A simple style fix; no functional change. Signed-off-by: John Keeping --- Nothing in maint..pu is touching this at the moment, so hopefully this is a good time to fix the whitespace here. Documentation/Makefile | 42 +- 1 file changed, 21 insertions(+), 2

[PATCH v4 5/6] rev-parse: add --prefix option

This makes 'git rev-parse' behave as if it were invoked from the specified subdirectory of a repository, with the difference that any file paths which it prints are prefixed with the full path from the top of the working tree. This is useful for shell scripts where we may want to cd to the top of

[PATCH v4 3/6] t7403: add missing && chaining

Signed-off-by: John Keeping --- t/t7403-submodule-sync.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/t/t7403-submodule-sync.sh b/t/t7403-submodule-sync.sh index 38f6cc4..bf90098 100755 --- a/t/t7403-submodule-sync.sh +++ b/t/t7403-submodule-sync.sh @@ -174,7 +174,7 @@

[PATCH v4 4/6] submodule: show full path in error message

When --recursive was added to "submodule foreach" in commit 15fc56a (git submodule foreach: Add --recursive to recurse into nested submodules, 2009-08-19), the error message when the script returns a non-zero status was not updated to contain $prefix to show the full path. Fix this. Signed-off-by

[PATCH v4 6/6] submodule: drop the top-level requirement

Use the new rev-parse --prefix option to process all paths given to the submodule command, dropping the requirement that it be run from the top-level of the repository. Since the interpretation of a relative submodule URL depends on whether or not "remote.origin.url" is configured, explicitly bloc

[PATCH v4 0/6] submodule: drop the top-level requirement

Changes since v3: * There are four new patches, three of which are style fixes for existing tests and one fixes an existing error message to return a more accurate path when recursing. * You now cannot run "git submodule add " from a subdirectory. Because the interpretation of the URL chan

[PATCH v4 2/6] t7403: modernize style

Change the indentation to use tabs consistently and start content on the line after the paren opening a subshell. Also don't put a space in ">file" and remove ":" from ": >file" to be consistent with the majority of tests elsewhere. Signed-off-by: John Keeping --- t/t7403-submodule-sync.sh | 31

[PATCH v4 1/6] t7401: make indentation consistent

Only leading whitespace is changed in this patch. Signed-off-by: John Keeping --- t/t7401-submodule-summary.sh | 80 ++-- 1 file changed, 40 insertions(+), 40 deletions(-) diff --git a/t/t7401-submodule-summary.sh b/t/t7401-submodule-summary.sh index 30b4

Re: [PATCH 1/2] sha1_name: stop hard-coding 40-character hex checks

On Sat, Jun 15, 2013 at 1:38 PM, Ramkumar Ramachandra wrote: > In two places, get_sha1_basic() assumes that strings are possibly sha1 > hexes if they are 40 characters long, and calls get_sha1_hex() in these > two cases. This 40-character check is ugly and wrong: there is nothing > preventing a r

Re: [PATCH] config doc: rewrite push.default section

From: "Ramkumar Ramachandra" Sent: Sunday, June 16, 2013 11:06 AM Design by Junio. By detaching descriptions from the implementation, we're only confusing users. I've chosen to use the term "central workflow" to make the descriptions terse and readable, although I've stayed way from "triangu

Re: [PATCH] rebase -i: fixup fixup! fixup!

Junio C Hamano writes: > Andrew Pimlott writes: > >> Excerpts from Andrew Pimlott's message of Fri Jun 14 12:31:57 -0700 2013: >>> It happened to work and I added a test. But then it occurred to me that >>> it might have been better to fix commit --fixup/--squash to strip the >>> fixup! or squa

[PATCH] config doc: rewrite push.default section

Design by Junio. By detaching descriptions from the implementation, we're only confusing users. I've chosen to use the term "central workflow" to make the descriptions terse and readable, although I've stayed way from "triangular workflow" (referred to as non-central workflow). Yes, I hate writi

Re: [PATCH 0/2] Slightly prettier reflog message from checkout

Junio C Hamano wrote: > I view the two codepaths touched by these patches the other way > around. I see. Thanks for the early feedback. I have some doubts. > An abbreviated unique SHA-1 you have today may not be unique > tomorrow. There is no reason to deliberately lose information > (e.g. by

Re: [PATCH V3 0/4] git-remote-mediawiki: new tool to preview local changes without pushing

wrote: > Subject: [PATCH V3 0/4] git-remote-mediawiki: new tool to preview local > changes without pushing Quick tip: use git format-patch -v3. The uppercase 'V' indicates that you probably typed it out yourself, or used --subject-prefix="PATCH V3". -- To unsubscribe from this list: send the li

Re: git ignore logic does not work as advertised

On Saturday, June 15, 2013 06:07:59 PM John Keeping wrote: > Which version of Git are you using? You may be hitting a regression > that was introduced in Git 1.8.3 and is fixed in Git 1.8.3.1. updated from 1.8.3 to 1.8.3.1 and solved. Thank you. Thomas Koch, http://www.koch.ro -- To unsubscribe f

[PATCH v2 4/6] wt-status: remove unused field in grab_1st_switch_cbdata

The struct grab_1st_switch_cbdata has the field "found", which is set in grab_1st_switch() when a match is found. This information is redundant and unused by any caller: the return value of the function serves to communicate this information anyway. Remove the field. Signed-off-by: Ramkumar Rama

[PATCH v2 0/6] Fix checkout-dash to work with rebase

So after extensive discussions with Junio, I have updated [5/6] to special-case rebase and rebase -i instead of dropping the "HEAD detached from" message altogether. Also, [1/6] includes two more tests, as suggested by Junio. Junio: The message is now the constant "rebase in progress; onto $ONTO"

[PATCH v2 2/6] rebase: prepare to write reflog message for checkout

The branch-flipping rebase internally does is not 'checkout' as far as the end-user is concerned; therefore, rebase should never write "checkout: " messages to the reflog. To achieve this, set a sensible GIT_REFLOG_ACTION; checkout does not respect this variable yet, but a future patch will change

[PATCH v2 1/6] t/checkout-last: checkout - doesn't work after rebase

The following command $ git checkout - does not work as expected after a rebase. Every kind of rebase must behave in the exactly same way: for the purposes of checkout -, the rebase event should be inconsequential. Add four failing tests documenting this bug: two for a normal rebase, and anot

[PATCH v2 6/6] checkout: respect GIT_REFLOG_ACTION

GIT_REFLOG_ACTION is an environment variable specifying the reflog message to write after an action is completed. Several other commands including merge, reset, and commit respect it. Fix the failing tests in t/checkout-last by making checkout respect it too. You can now expect $ git checkout

[PATCH v2 3/6] rebase -i: prepare to write reflog message for checkout

The branch-flipping rebase -i internally does is not 'checkout' as far as the end-user is concerned; therefore, rebase -i should never write "checkout: " messages to the reflog. To achieve this, set a sensible GIT_REFLOG_ACTION; checkout does not respect this variable yet, but a future patch will

[PATCH v2 5/6] status: do not depend on rebase reflog messages

b397ea4 (status: show more info than "currently not on any branch", 2013-03-13) made the output of 'git status' richer in the case of a detached HEAD. Before this patch, with a detached HEAD: $ git status # Not currently on any branch. After the patch: $ git checkout v1.8.2 $ git status