Re: [PATCH] mergetools: Add tortoisegitmerge helper

On Thu, Jan 24, 2013 at 11:21 PM, Junio C Hamano wrote: > David Aguilar writes: > This paragraph needs to be rewritten to unconfuse readers. The > original is barely intelligible, and it becomes unreadable as the > set of tools subtracted by "minus" and added by "plus" grows. >>

Re: segmentation fault (nullpointer) with git log --submodule -p

Just to note, the proposals so far don't prevent a "smart-ass" function from freeing the buffer when it's called underneath the use/release scope, as in: with_commit_buffer(commit); { fn1_needing_buffer(commit); walk_rev_tree_or_something(); fn2_needing_buffer(commit); } d

Re: segmentation fault (nullpointer) with git log --submodule -p

Jonathan Nieder writes: > Hi, > > Junio C Hamano wrote: > >> I've been toying with an idea along this line. > > Heh. Just for fun, here's an uglier version: Much nicer, though. > > struct wcb_data { > int had_buffer; > int using_buffer; > }; > #def

Re: [PATCH] mergetools: Add tortoisegitmerge helper

David Aguilar writes: > Even though the old tortoisemerge and the new tortoisegitmerge > have completely different syntax, could we still use the existence > of one when deciding which syntax to use? > ... > ...and then later merge_cmd and diff_cmd > can delegate to {diff,merge}_cmd_legacy() and

Any Identity tiffany bracelet Is certainly Associated Utilizing High quality

Anytime people speaks about superior wineglass job, any identity Tiffany without delay arrives at thought process. * tiffany uk * has got earned terrific attraction meant for about seventy-five together with 20 years. It had become involving some sort of Nor

That Temptations In pandora jewelry charms

That picture, Avatar, contains earn very good worldwide recognition throughout the world, additionally, the exquisite Pandora intercontinental from this picture catches a persons vision of most many people. Pandora develops into the latest ideas fairly recently, it is utilized for a number of poi

Re: [PATCH] mergetools: Add tortoisegitmerge helper

On Thu, Jan 24, 2013 at 2:15 PM, Junio C Hamano wrote: > Sven Strickroth writes: > >> Am 24.01.2013 20:51 schrieb Junio C Hamano: >>> Sven Strickroth writes: >>> - The TortoiseGit team renamed TortoiseMerge.exe to TortoiseGitMerge.exe (starting with 1.8.0) in order to make clear that

[PATCH] .gitignore: ignore generated gitk-git/gitk-wish

Signed-off-by: Nguyễn Thái Ngọc Duy --- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index aa258a6..63d4904 100644 --- a/.gitignore +++ b/.gitignore @@ -171,6 +171,7 @@ /git-whatchanged /git-write-tree /git-core-*/?* +/gitk-git/gitk-wish /gitweb/GITW

These materials Could Normally Always be cheap links of london bracelets Based Via Flea

All your family members can be * links of london sale * quite exclusive rear. While getaways, 1st birthdays plus backlinks involving manchester substitute gift-giving characteristics surface, you'll want to present the most beneficial for you to all yo

Re: segmentation fault (nullpointer) with git log --submodule -p

Hi, Junio C Hamano wrote: > I've been toying with an idea along this line. Heh. Just for fun, here's an uglier version: struct wcb_data { int had_buffer; int using_buffer; }; #define WITH_COMMIT_BUFFER_DATA_INIT { 0, 0 } extern v

Re: [PATCH 4/4] git-difftool: use git-mergetool--lib for "--tool-help"

On Thu, Jan 24, 2013 at 11:55 AM, John Keeping wrote: > The "--tool-help" option to git-difftool currently displays incorrect > output since it uses the names of the files in > "$GIT_EXEC_PATH/mergetools/" rather than the list of command names in > git-mergetool--lib. > > Fix this by simply delega

Re: [PATCH 1/3] mergetool--lib: fix startup options for gvimdiff tool

On Wed, Jan 23, 2013 at 11:16 PM, Alexey Shumkin wrote: > Options are taken from /mergetools/vim > > Signed-off-by: Alexey Shumkin > --- > git-gui/lib/mergetool.tcl | 8 +++- > 1 file changed, 7 insertions(+), 1 deletion(-) A better long-term solution might be to teach git gui to use "git d

Re: [PATCH v4 0/3] Finishing touches to "push" advises

On Thu, Jan 24, 2013 at 11:04 PM, Junio C Hamano wrote: > Would it be sufficient to do this? I think "the tag already exists > in the remote" is already clear that we are talking about the > destination. Good point. > diff --git a/builtin/push.c b/builtin/push.c > index a2b3fbe..78789be 100644

Re: [PATCH v4 0/3] Finishing touches to "push" advises

Chris Rorvick writes: > Had I written the the "already exists" advice in the context of these > additional statuses I would have said "the destination *tag* reference > already exists", or maybe even just "the destination *tag* already > exists". Yeah, now we do not use "already exists" for anyt

Re: [PATCH] Update renamed file merge-file.h in Makefile

Oops, I find it is already fixed in commit a60521bc6099ce89d05ef2160d2e3c30a106fda7. commit a60521bc6099ce89d05ef2160d2e3c30a106fda7 Author: Ramsay Jones Date: Tue Jan 22 16:47:47 2013 + Makefile: Replace merge-file.h with merge-blobs.h in LIB_H Commit fa2364ec ("Which merge_file

Re: What's cooking in git.git (Jan 2013, #08; Tue, 22)

On Wed, Jan 23, 2013 at 3:12 PM, John Keeping wrote: > The existing script (git-cvsimport.perl) won't ever work with cvsps-3 > since features it relies on have been removed. Not reporting the ancestry branch seems to be the big one. Are there others? I had a version of the Perl script sort of w

Re: [PATCH v3 01/10] wildmatch: fix "**" special case

Duy Nguyen writes: > On Fri, Jan 25, 2013 at 1:22 AM, Junio C Hamano wrote: >> Duy Nguyen writes: >> >>> I don't think we need to support two different sets of wildcards in >>> the long run. I'm thinking of adding ":(glob)" with WM_PATHNAME. >>> Pathspec without :(glob) still uses the current w

Git 1.8.2 l10n round 1

Dear l10n team members, New "git.pot" is generated from v1.8.1-476-gec3ae6e in the master branch. l10n: Update git.pot (11 new, 7 removed messages) Generate po/git.pot from v1.8.1-476-gec3ae6e, and there are 11 new and 7 removed messages. Signed-off-by: Jiang Xin This update i

Re: [PATCH v4 0/3] Finishing touches to "push" advises

On Wed, Jan 23, 2013 at 3:55 PM, Junio C Hamano wrote: > This builds on Chris Rorvick's earlier effort to forbid unforced > updates to refs/tags/ hierarchy and giving sensible error and advise > messages for that case (we are not rejecting such a push due to fast > forwardness, and suggesting to f

Re: [PATCH] t9902: protect test from stray build artifacts

On Thu, Jan 24, 2013 at 08:19:30PM -0800, Junio C Hamano wrote: > > Ahh, ok, we show one element per line and just make sure "bundle" > > is there, and we do not care what other buns appear in the output. > > > Not so quick, though. The lower level "read from help -a" is only > run once and its o

Re: segmentation fault (nullpointer) with git log --submodule -p

Jeff King writes: > ... I know it gets the job done, but in my > experience, macros which do not behave syntactically like functions are > usually a good sign that you are doing something gross and > unmaintainable. Yeah, it is a bit too cute for my taste, too, even though it was fun ;-) -- To u

Re: [PATCH] t9902: protect test from stray build artifacts

Junio C Hamano writes: > Jeff King writes: > >> This looks good to me. >> >> The only thing I might add is a test just to double-check that "git help >> -a" is parsed correctly. Like: >> >> test_expect_success 'command completion works without test harness' ' >>GIT_TESTING_COMMAND_

Re: [PATCH] t9902: protect test from stray build artifacts

On Thu, Jan 24, 2013 at 08:11:07PM -0800, Junio C Hamano wrote: > Jeff King writes: > > > This looks good to me. > > > > The only thing I might add is a test just to double-check that "git help > > -a" is parsed correctly. Like: > > > > test_expect_success 'command completion works without tes

Re: [PATCH] t9902: protect test from stray build artifacts

Jeff King writes: > This looks good to me. > > The only thing I might add is a test just to double-check that "git help > -a" is parsed correctly. Like: > > test_expect_success 'command completion works without test harness' ' >GIT_TESTING_COMMAND_COMPLETION= run_completion "git bun

Re: segmentation fault (nullpointer) with git log --submodule -p

On Thu, Jan 24, 2013 at 07:59:58PM -0800, Junio C Hamano wrote: > Junio C Hamano writes: > > > Jeff King writes: > > > >> ... (e.g., how should "log" know that a submodule diff might later want > >> to see the same entry? Should we optimistically free and then make it > >> easier for the later

Re: [PATCH 1/7] sha1_file: keep track of where an SHA-1 object comes from

On Fri, Jan 25, 2013 at 10:58 AM, Junio C Hamano wrote: > Duy Nguyen writes: > >> On Fri, Jan 25, 2013 at 12:45 AM, Junio C Hamano wrote: How about this way instead: we keep track of where objects come from so we can verify object source when we create or update something that

Re: segmentation fault (nullpointer) with git log --submodule -p

Junio C Hamano writes: > Jeff King writes: > >> ... (e.g., how should "log" know that a submodule diff might later want >> to see the same entry? Should we optimistically free and then make it >> easier for the later user to reliably ensure the buffer is primed? Or >> should we err on the side o

Re: [PATCH 1/7] sha1_file: keep track of where an SHA-1 object comes from

Duy Nguyen writes: > On Fri, Jan 25, 2013 at 12:45 AM, Junio C Hamano wrote: >>> How about this way instead: we keep track of where objects come from >>> so we can verify object source when we create or update something >>> that contains SHA-1. >> >> The overall approach taken by this series

[PATCH] Update renamed file merge-file.h in Makefile

Commit v1.8.1-rc0-3-gfa2364e renamed merge-file.h to merge-blobs.h, but forgot to update the reference of merge-file.h in Makefile. This would break the build of "po/git.pot", which depends on $(LOCALIZED_C), then fallback to the missing file "merge-file.h". Signed-off-by: Jiang Xin --- Makefile

Re: [PATCH] t9902: protect test from stray build artifacts

Jeff King wrote: > On Thu, Jan 24, 2013 at 03:07:42PM -0800, Junio C Hamano wrote[1]: >> Instrument the completion script and give it a way for us to tell >> what (subset of) subcommands we are going to ship. [...] > The only thing I might add is a test just to double-check that "git help > -a" is

Re: segmentation fault (nullpointer) with git log --submodule -p

On Fri, Jan 25, 2013 at 7:55 AM, Jeff King wrote: > On Thu, Jan 24, 2013 at 03:56:23PM -0800, Junio C Hamano wrote: > >> Jeff King writes: >> >> > ... (e.g., how should "log" know that a submodule diff might later want >> > to see the same entry? Should we optimistically free and then make it >>

Re: [PATCH 6/7] read-cache: refuse to create index referring to external objects

On Fri, Jan 25, 2013 at 2:15 AM, Junio C Hamano wrote: > Nguyễn Thái Ngọc Duy writes: > >> Signed-off-by: Nguyễn Thái Ngọc Duy >> --- >> read-cache.c | 20 >> 1 file changed, 20 insertions(+) >> >> diff --git a/read-cache.c b/read-cache.c >> index fda78bc..4579215 100644 >

Re: [PATCH v3 01/10] wildmatch: fix "**" special case

On Fri, Jan 25, 2013 at 1:22 AM, Junio C Hamano wrote: > Duy Nguyen writes: > >> I don't think we need to support two different sets of wildcards in >> the long run. I'm thinking of adding ":(glob)" with WM_PATHNAME. >> Pathspec without :(glob) still uses the current wildcards (i.e. no >> FNM_PAT

Re: [PATCH 1/7] sha1_file: keep track of where an SHA-1 object comes from

On Fri, Jan 25, 2013 at 12:45 AM, Junio C Hamano wrote: >> How about this way instead: we keep track of where objects come from >> so we can verify object source when we create or update something >> that contains SHA-1. > > The overall approach taken by this series may be worth considering, bu

Re: [PATCH] t9902: protect test from stray build artifacts

On Thu, Jan 24, 2013 at 03:07:42PM -0800, Junio C Hamano wrote: > When you have random build artifacts in your build directory, left > behind by running "make" while on another branch, the "git help -a" > command run by __git_list_all_commands in the completion script that > is being tested does n

Re: [regression] Re: [PATCHv2 10/15] drop length limitations on gecos-derived names and emails

On Thu, Jan 24, 2013 at 03:21:46PM -0800, Jonathan Nieder wrote: > This broke /etc/mailname handling. Before: > > $ git var GIT_COMMITTER_IDENT > Jonathan Nieder 1359069165 -0800 > > After: > > $ git var GIT_COMMITTER_IDENT > Jonathan Nieder 1359069192 -0800 Ick. I w

Re: segmentation fault (nullpointer) with git log --submodule -p

On Thu, Jan 24, 2013 at 03:56:23PM -0800, Junio C Hamano wrote: > Jeff King writes: > > > ... (e.g., how should "log" know that a submodule diff might later want > > to see the same entry? Should we optimistically free and then make it > > easier for the later user to reliably ensure the buffer

Re: segmentation fault (nullpointer) with git log --submodule -p

Jeff King writes: > ... (e.g., how should "log" know that a submodule diff might later want > to see the same entry? Should we optimistically free and then make it > easier for the later user to reliably ensure the buffer is primed? Or > should we err on the side of keeping it in place?). My kne

Re: [PATCH] parse_object: clear "parsed" when freeing buffers

On 2013-01-23, at 23:07, Jeff King wrote: > On Wed, Jan 23, 2013 at 01:25:04PM -0800, Jonathon Mah wrote: > >> Several areas of code would free buffers for object structs that >> contained them ("struct tree" and "struct commit"), but without clearing >> the "parsed" flag. parse_object would cle

Re: segmentation fault (nullpointer) with git log --submodule -p

On Thu, Jan 24, 2013 at 09:14:47PM +0700, Nguyen Thai Ngoc Duy wrote: > >>> I did. My bisection told me this is the suspect: > >>> > >>> ccdc603 (parse_object: try internal cache before reading object db) > >> > >> diff --git a/object.c b/object.c > >> index d8d09f9..6b06297 100644 > >> --- a/obje

[regression] Re: [PATCHv2 10/15] drop length limitations on gecos-derived names and emails

Hi Jeff, Jeff King wrote: > When we pull the user's name from the GECOS field of the > passwd file (or generate an email address based on their > username and hostname), we put the result into a > static buffer. [...] > The conversion is mostly mechanical: replace string copies > with strbuf equi

[PATCH] t9902: protect test from stray build artifacts

When you have random build artifacts in your build directory, left behind by running "make" while on another branch, the "git help -a" command run by __git_list_all_commands in the completion script that is being tested does not have a way to know that they are not part of the subcommands this buil

Re: [PATCH] t9902: Instruct git-completion.bash about a test mode

Le jeudi 24 janvier 2013 23:29:33, Junio C Hamano a écrit : > "Jean-Noël AVILA" writes: > > > My rational was to be sure to put the environment variable out of the > > way once the script has been sourced. I can make two alternative > > definitions of __git_list_all_commands () depending on the

Re: [PATCH v4 1/3] push: further clean up fields of "struct ref"

On Wed, Jan 23, 2013 at 4:55 PM, Junio C Hamano wrote: > The "nonfastforward" and "update" fields are only used while > deciding what value to assign to the "status" locally in a single > function. Remove them from the "struct ref". > > The "requires_force" field is not used to decide if the prop

Re: [PATCH] t9902: Instruct git-completion.bash about a test mode

"Jean-Noël AVILA" writes: > My rational was to be sure to put the environment variable out of the > way once the script has been sourced. I can make two alternative > definitions of __git_list_all_commands () depending on the presence of > $AUTHORIZED_CMD_LIST if you are worried about performa

Re: [PATCH] mergetools: Add tortoisegitmerge helper

Sven Strickroth writes: > Am 24.01.2013 20:51 schrieb Junio C Hamano: >> Sven Strickroth writes: >> >>> - The TortoiseGit team renamed TortoiseMerge.exe to TortoiseGitMerge.exe >>> (starting with 1.8.0) in order to make clear that this one has special >>> support for git and prevent confusi

Re: [PATCH] mergetools: Add tortoisegitmerge helper

Am 24.01.2013 20:51 schrieb Junio C Hamano: > Sven Strickroth writes: > >> - The TortoiseGit team renamed TortoiseMerge.exe to TortoiseGitMerge.exe >> (starting with 1.8.0) in order to make clear that this one has special >> support for git and prevent confusion with the TortoiseSVN TortoiseM

Re: [PATCH] t9902: Instruct git-completion.bash about a test mode

Le jeudi 24 janvier 2013 22:46:13, Junio C Hamano a écrit : > "Jean-Noël AVILA" writes: > > > In test mode, git completion should propose commands only if they > > belong to the list of authorized commands. > > > > Signed-off-by: Jean-Noel Avila > > --- > > > > Better show some code than try to

Re: [PATCH] t9902: Instruct git-completion.bash about a test mode

"Jean-Noël AVILA" writes: > In test mode, git completion should propose commands only if they > belong to the list of authorized commands. > > Signed-off-by: Jean-Noel Avila > --- > > Better show some code than try to explain. Here is what I mean by > "filter the output git help -a". Why do yo

Re: [PATCH] mergetool: clean up temp files when aborted

Phil Hord writes: > On Thu, Jan 24, 2013 at 2:54 PM, Junio C Hamano wrote: >> Phil Hord writes: >> ... >>> These temporary files should not remain after the mergetool operation is >>> completed. >> >> Aren't there cases where people "abort" so that they can have a >> chance inspect them outside

Re: [PATCH] mergetool: clean up temp files when aborted

On Thu, Jan 24, 2013 at 2:54 PM, Junio C Hamano wrote: > Phil Hord writes: > >> When handling a symlink conflict or a deleted-file conflict, mergetool >> stops to ask the user what to do. If the user chooses any option besides >> "(a)bort", then the temporary files which mergetool created in >> p

[PATCH] t9902: Instruct git-completion.bash about a test mode

In test mode, git completion should propose commands only if they belong to the list of authorized commands. Signed-off-by: Jean-Noel Avila --- Better show some code than try to explain. Here is what I mean by "filter the output git help -a". contrib/completion/git-completion.bash | 16 ++

Re: [PATCH] parse_object: clear "parsed" when freeing buffers

On 2013-01-23, at 23:07, Jeff King wrote: > On Wed, Jan 23, 2013 at 01:25:04PM -0800, Jonathon Mah wrote: > >> Several areas of code would free buffers for object structs that >> contained them ("struct tree" and "struct commit"), but without clearing >> the "parsed" flag. parse_object would cle

Re: [PATCH 0/4] Fix "git difftool --tool-help"

Nice code reduction ;-) Thanks, will queue. -- 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: [PATCH v4 3/4] pretty: Add failing tests: user format ignores i18n.logOutputEncoding setting

Alexey Shumkin writes: > diff --git a/t/t6006-rev-list-format.sh b/t/t6006-rev-list-format.sh > index c248509..4db43a4 100755 > --- a/t/t6006-rev-list-format.sh > +++ b/t/t6006-rev-list-format.sh > ... > @@ -112,12 +133,12 @@ commit $head2 > commit $head1 > EOF > > -test_format raw-body %B <<

Re: [PATCH] git-cvsimport.txt: cvsps-2 is deprecated

John Keeping writes: > On Thu, Jan 24, 2013 at 12:04:11PM -0800, Junio C Hamano wrote: >> John Keeping writes: >> >> > git-cvsimport relies on version 2 of cvsps and does not work with the >> > new version 3. Since cvsps 3.x does not currently work as well as >> > version 2 for incremental imp

Re: [PATCH v4 3/4] pretty: Add failing tests: user format ignores i18n.logOutputEncoding setting

Alexey Shumkin writes: > The following two commands are expected to give the same output to a terminal: > > $ git log --oneline --no-color > $ git log --pretty=format:'%h %s' > > However, the former pays attention to i18n.logOutputEncoding > configuration, while the latter does not wh

Re: [PATCH v4 2/4] t7102 (reset): refactoring: don't hardcode SHA-1 in expected outputs

Alexey Shumkin writes: > The expected SHA-1 digests are always available in variables. Use > them instead of hardcoding. > > Signed-off-by: Alexey Shumkin > --- Looks good (" refactoring:" in the title may not want to be there, though). Thanks. > t/t7102-reset.sh | 41 +-

Re: [PATCH v4 1/4] t6006 (rev-list-format): don't hardcode SHA-1 in expected outputs

Alexey Shumkin writes: > The expected SHA-1 digests are always available in variables. Use > them instead of hardcoding. > > Signed-off-by: Alexey Shumkin > --- > t/t6006-rev-list-format.sh | 130 > + > 1 file changed, 72 insertions(+), 58 deletions

Re: [PATCH] git-cvsimport.txt: cvsps-2 is deprecated

On Thu, Jan 24, 2013 at 12:04:11PM -0800, Junio C Hamano wrote: > John Keeping writes: > > > git-cvsimport relies on version 2 of cvsps and does not work with the > > new version 3. Since cvsps 3.x does not currently work as well as > > version 2 for incremental import, document this fact. > > >

Re: [PATCH] git-cvsimport.txt: cvsps-2 is deprecated

John Keeping writes: > git-cvsimport relies on version 2 of cvsps and does not work with the > new version 3. Since cvsps 3.x does not currently work as well as > version 2 for incremental import, document this fact. > > Specifically, there is no way to make new git-cvsimport that supports > cvs

[PATCH 4/4] git-difftool: use git-mergetool--lib for "--tool-help"

The "--tool-help" option to git-difftool currently displays incorrect output since it uses the names of the files in "$GIT_EXEC_PATH/mergetools/" rather than the list of command names in git-mergetool--lib. Fix this by simply delegating the "--tool-help" argument to the show_tool_help function in

[PATCH 3/4] git-mergetool: don't hardcode 'mergetool' in show_tool_help

When using show_tool_help from git-difftool we will want it to print "git difftool" not "git mergetool" so use "git ${TOOL_MODE}tool". Signed-off-by: John Keeping --- git-mergetool--lib.sh | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/git-mergetool--lib.sh b/git-merge

[PATCH 2/4] git-mergetool: remove redundant assignment

TOOL_MODE is set at the top of git-mergetool.sh so there is no need to set it again in show_tool_help. Removing this lets us re-use show_tool_help in git-difftool. Signed-off-by: John Keeping --- git-mergetool--lib.sh | 1 - 1 file changed, 1 deletion(-) diff --git a/git-mergetool--lib.sh b/gi

[PATCH 1/4] git-mergetool: move show_tool_help to mergetool--lib

This is the first step in unifying "git difftool --tool-help" and "git mergetool --tool-help". Signed-off-by: John Keeping --- git-mergetool--lib.sh | 37 + git-mergetool.sh | 37 - 2 files changed, 37 insertions(+), 37

[PATCH 0/4] Fix "git difftool --tool-help"

The "--tool-help" option to git-difftool currently displays incorrect output since it uses the names of the files in "$GIT_EXEC_PATH/mergetools/" rather than the list of command names in git-mergetool--lib. This series fixes this by changing it to simply delegate to a function in git-mergetool--li

Re: [PATCH] mergetool: clean up temp files when aborted

Phil Hord writes: > When handling a symlink conflict or a deleted-file conflict, mergetool > stops to ask the user what to do. If the user chooses any option besides > "(a)bort", then the temporary files which mergetool created in > preparation for handling the conflict are removed. But these te

Re: [PATCH] mergetools: Add tortoisegitmerge helper

Sven Strickroth writes: > - The TortoiseGit team renamed TortoiseMerge.exe to TortoiseGitMerge.exe > (starting with 1.8.0) in order to make clear that this one has special > support for git and prevent confusion with the TortoiseSVN TortoiseMerge > version. Wouldn't it make more sense in s

[PATCH] git-cvsimport.txt: cvsps-2 is deprecated

git-cvsimport relies on version 2 of cvsps and does not work with the new version 3. Since cvsps 3.x does not currently work as well as version 2 for incremental import, document this fact. Specifically, there is no way to make new git-cvsimport that supports cvsps 3.x and have a seamless transit

Re: [PATCH 6/7] read-cache: refuse to create index referring to external objects

Nguyễn Thái Ngọc Duy writes: > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > read-cache.c | 20 > 1 file changed, 20 insertions(+) > > diff --git a/read-cache.c b/read-cache.c > index fda78bc..4579215 100644 > --- a/read-cache.c > +++ b/read-cache.c > @@ -1720,6 +1720,26 @@

Re: [PATCH] send-email: Honor multi-part email messages

Shumkin Alexey writes: > I've meant you did not reply to my last message in this thread > http://thread.gmane.org/gmane.comp.version-control.git/181791 Please repost the patch (with possible updates) for review when attempting to resurrect an ancient topic, instead of forcing people to hunt for

Re: [PATCH] send-email: Honor multi-part email messages

I've meant you did not reply to my last message in this thread http://thread.gmane.org/gmane.comp.version-control.git/181791 2013/1/24 Junio C Hamano > > Alexey Shumkin writes: > > > Bump > > Bump what??? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message

[PATCH] mergetool: clean up temp files when aborted

When handling a symlink conflict or a deleted-file conflict, mergetool stops to ask the user what to do. If the user chooses any option besides "(a)bort", then the temporary files which mergetool created in preparation for handling the conflict are removed. But these temporary files are not remove

Re: [PATCH v3 01/10] wildmatch: fix "**" special case

Duy Nguyen writes: > I don't think we need to support two different sets of wildcards in > the long run. I'm thinking of adding ":(glob)" with WM_PATHNAME. > Pathspec without :(glob) still uses the current wildcards (i.e. no > FNM_PATHNAME). At some point, like 2.0, we either switch the behavior

Re: [PATCH] send-email: Honor multi-part email messages

Alexey Shumkin writes: > Bump Bump what??? -- 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: [PATCH 1/7] sha1_file: keep track of where an SHA-1 object comes from

Nguyễn Thái Ngọc Duy writes: > We currently know if an object is loose or packed. We do not know if > it's from the repo's object database, or via alternates > mechanism. With this patch, sha1_object_info_extended() can tell if an > object comes from alternates source (and which one). > > Signed-

Re: [PATCH 1/2] upload-pack: avoid parsing objects during ref advertisement

Jeff King writes: > And yeah, this should use lookup_unknown_object to extend the > optimization to mark_our_ref (and avoid removing it for the > ref-advertisement case, of course). Thanks for sanity checking. Here is what is queued at the bottom of the hide-refs topic. -- >8 -- Date: Fri, 18

Re: [PATCH v4 3/3] push: introduce REJECT_FETCH_FIRST and REJECT_NEEDS_FORCE

Jeff King writes: > I wonder if we can reword it to explain more about why we do not have > the object, without getting too inaccurate. Something like: > > Updates were rejected because the remote contains objects that you do > not have locally. This is usually caused by another repository pu

Re: [PATCH] parse_object: clear "parsed" when freeing buffers

Jeff King writes: > The ensure_commit_buffer function could look something like: > > int ensure_commit_buffer(struct commit *item) > { > enum object_type type; > unsigned long size; > > if (!item) > return -1; > if (!item->object.parse

Re: segmentation fault (nullpointer) with git log --submodule -p

On Thu, Jan 24, 2013 at 9:06 PM, Stefan Näwe wrote: > Am Donnerstag, 24. Januar 2013 14:40:47 schrieb Duy Nguyen: >> On Thu, Jan 24, 2013 at 7:11 PM, Stefan Näwe >> wrote: Does it fail with older versions of git? If so, can you bisect? >>> >>> I did. My bisection told me this is the suspect:

Re: segmentation fault (nullpointer) with git log --submodule -p

Am Donnerstag, 24. Januar 2013 14:40:47 schrieb Duy Nguyen: > On Thu, Jan 24, 2013 at 7:11 PM, Stefan Näwe > wrote: >>> Does it fail with older versions of git? If so, can you bisect? >> >> I did. My bisection told me this is the suspect: >> >> ccdc603 (parse_object: try internal cache before read

Re: segmentation fault (nullpointer) with git log --submodule -p

On Thu, Jan 24, 2013 at 7:11 PM, Stefan Näwe wrote: >> Does it fail with older versions of git? If so, can you bisect? > > I did. My bisection told me this is the suspect: > > ccdc603 (parse_object: try internal cache before reading object db) diff --git a/object.c b/object.c index d8d09f9..6b062

Re: segmentation fault (nullpointer) with git log --submodule -p

Am 23.01.2013 21:02, schrieb Jeff King: > On Wed, Jan 23, 2013 at 03:38:16PM +0100, Armin wrote: > >> Hello dear git people. >> >> I experience a reproducible segmentation fault on one of my >> repositories when doing a "git log --submodule -p", tested with newest >> version on Arch Linux (git ver

Re: [PATCH] mergetools: Add tortoisegitmerge helper

Am 21.01.2013 09:26 schrieb Sven Strickroth: > - The TortoiseGit team renamed TortoiseMerge.exe to TortoiseGitMerge.exe > (starting with 1.8.0) in order to make clear that this one has special > support for git and prevent confusion with the TortoiseSVN TortoiseMerge > version. > - The tortoi

Re: [PATCH] send-email: Honor multi-part email messages

Bump -- 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

[PULL (updated)] git-svn updates for master

I've squashed the change I mentioned in http://mid.gmane.org/20130124101417.ga22...@dcvr.yhbt.net to Barry's commit, and added Jonathan's Reviewed-by to my cleanup commit. The following changes since commit ec3ae6ec46ed48383ae40643990f169b65a563cc: Merge git://ozlabs.org/~paulus/gitk (2013-01-2

Re: [PATCH v3 0/2] Make git-svn work with gitdir links

Junio C Hamano wrote: > Eric Wong writes: > > > diff --git a/git-svn.perl b/git-svn.perl > > index c232798..e5bd292 100755 > > --- a/git-svn.perl > > +++ b/git-svn.perl > > @@ -332,11 +332,13 @@ if ($cmd && $cmd =~ /(?:clone|init|multi-init)$/) { > > $ENV{GIT_DIR} = command_oneline([

[PATCH v4 3/4] pretty: Add failing tests: user format ignores i18n.logOutputEncoding setting

The following two commands are expected to give the same output to a terminal: $ git log --oneline --no-color $ git log --pretty=format:'%h %s' However, the former pays attention to i18n.logOutputEncoding configuration, while the latter does not when it format "%s". Log messages w

[PATCH v4 2/4] t7102 (reset): refactoring: don't hardcode SHA-1 in expected outputs

The expected SHA-1 digests are always available in variables. Use them instead of hardcoding. Signed-off-by: Alexey Shumkin --- t/t7102-reset.sh | 41 + 1 file changed, 21 insertions(+), 20 deletions(-) diff --git a/t/t7102-reset.sh b/t/t7102-reset.sh in

[PATCH v4 1/4] t6006 (rev-list-format): don't hardcode SHA-1 in expected outputs

The expected SHA-1 digests are always available in variables. Use them instead of hardcoding. Signed-off-by: Alexey Shumkin --- t/t6006-rev-list-format.sh | 130 + 1 file changed, 72 insertions(+), 58 deletions(-) diff --git a/t/t6006-rev-list-format

[PATCH v4 0/4] Reroll patches against v1.8.1.1

Wf! Reroll my patches again after 1.5 years ;) They must be applied against v1.8.1.1 Sorry for my laziness ;) Alexey Shumkin (4): t6006 (rev-list-format): don't hardcode SHA-1 in expected outputs t7102 (reset): refactoring: don't hardcode SHA-1 in expected outputs pretty: Add failing te

[PATCH 7/7] refs: do not update ref(log) referring to external objects

Signed-off-by: Nguyễn Thái Ngọc Duy --- refs.c | 24 1 file changed, 24 insertions(+) diff --git a/refs.c b/refs.c index 541fec2..86003af 100644 --- a/refs.c +++ b/refs.c @@ -2014,6 +2014,18 @@ static int log_ref_write(const char *refname, const unsigned char *old_sha1

[PATCH 6/7] read-cache: refuse to create index referring to external objects

Signed-off-by: Nguyễn Thái Ngọc Duy --- read-cache.c | 20 1 file changed, 20 insertions(+) diff --git a/read-cache.c b/read-cache.c index fda78bc..4579215 100644 --- a/read-cache.c +++ b/read-cache.c @@ -1720,6 +1720,26 @@ static int ce_write_entry(git_SHA_CTX *c, int fd,

[PATCH 5/7] sha1_file: refuse to write tags referring to external objects

Signed-off-by: Nguyễn Thái Ngọc Duy --- sha1_file.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/sha1_file.c b/sha1_file.c index ec3a040..01681e5 100644 --- a/sha1_file.c +++ b/sha1_file.c @@ -2666,6 +2666,12 @@ static void check_sha1_file_for_external_source(const char *buf,

[PATCH 4/7] sha1_file: refuse to write trees referring to external objects

Signed-off-by: Nguyễn Thái Ngọc Duy --- sha1_file.c | 23 +++ 1 file changed, 23 insertions(+) diff --git a/sha1_file.c b/sha1_file.c index 5948dcb..ec3a040 100644 --- a/sha1_file.c +++ b/sha1_file.c @@ -2643,6 +2643,29 @@ static void check_sha1_file_for_external_source(cons

[PATCH 3/7] sha1_file: refuse to write commits referring to external objects

Signed-off-by: Nguyễn Thái Ngọc Duy --- sha1_file.c | 34 ++ 1 file changed, 34 insertions(+) diff --git a/sha1_file.c b/sha1_file.c index af71122..5948dcb 100644 --- a/sha1_file.c +++ b/sha1_file.c @@ -2615,12 +2615,46 @@ static int write_loose_object(const unsi

[PATCH 2/7] sha1_file: separate alt object db from own repos and submodules's

A submodule's object database may be imported to in-core object pool for a quick peek without paying the price of running a separate git command. These databases are marked in for stricter checks later to avoid accidentially refering to a submodule's SHA-1 from main repo (except in gitlinks). Sign

[PATCH 1/7] sha1_file: keep track of where an SHA-1 object comes from

We currently know if an object is loose or packed. We do not know if it's from the repo's object database, or via alternates mechanism. With this patch, sha1_object_info_extended() can tell if an object comes from alternates source (and which one). Signed-off-by: Nguyễn Thái Ngọc Duy --- How abo