RESPOND URGENTLY!!

Greetings from George Daniels I am George Daniels, a Banker and credit system programmer (HSBC bank). I saw your email address while browsing through the bank D.T.C Screen in my office yesterday so I decided to use this very chance to know you. I believe we should use every opportunity to know ea

Re: [PATCH] TIG: Fix to reinstate proper operation with no arguments

On Thu, Jul 18, 2013 at 9:30 AM, Drew Northup wrote: > > Somehow this patch breaks the main view to not open the correct commit in > diff view when is pressed. Back to the debugger... Does this (possibly white-space damaged) patch work for you? diff --git a/tig.c b/tig.c index ba9ba98..74a2928

Re: [PATCH] Add the GIT_SENTINEL macro

Junio C Hamano wrote: > It seems to apply well on the tip of jk/gcc-function-attributes. > > - This macro is not about "git" at all, so I'll edit the patch to >call it GCC_ATTR_SENTINEL before applying. Would naming it something like LAST_ARG_MUST_BE_NULL instead make sense? That way, if so

Re: [PATCH 6/6] diff: deprecate -q option to diff-files

Junio C Hamano wrote: > We should remove the support for "-q" in Git 2.0. No. I hope you are teasing. I don't mind seeing support for "-q" dropped, but I really don't think it's worth delaying git 2.0 for that. Would s/in Git 2.0/in some future release/ be ok? The patch text itself looks

Re: [PATCH] Add the GIT_SENTINEL macro

Ramsay Jones writes: > The sentinel function attribute is not understood by versions of > the gcc compiler prior to v4.0. At present, for earlier versions > of gcc, the build issues 108 warnings related to the unknown > attribute. In order to suppress the warnings, we conditionally > define the G

[PATCH 7/6] diff: remove "diff-files -q" at Git 2.0 version boundary

This was inherited from "show-diff -q" that was invented to tell comparison between the index and the working tree to ignore only removals in 2005. These days, it is spelled as "--diff-filter=d". Signed-off-by: Junio C Hamano --- * And this is the endgame. diff-lib.c | 3 --- diff-no-in

Re: [PATCH v2] pull: require choice between rebase/merge on non-fast-forward pull

On Thu, Jul 18, 2013 at 3:35 PM, Junio C Hamano wrote: > Add a safety valve to fail "git pull" that does not explicitly > specify what branch from which repository to integrate your history > with, when it is neither a fast-forward or "already up-to-date", > until/unless the user expressed her pre

What's cooking in git.git (Jul 2013, #06; Thu, 18)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. Quite a many topics are now in 'master', and 'next' has been shrinking in a reasonable pace, but there are some biggies remaining (including the

Re: [PATCH v4 0/2] allow git-svn fetching to work using serf

On Jul 18, 2013, at 16:34, Junio C Hamano wrote: "Kyle J. McKay" writes: This patch allows git-svn to fetch successfully using the serf library when given an https?: url to fetch from. ... Versions v2-v3 of the patch introduced a bug when attempting to change the _temp_cache function to use th

[PATCH 0/1] incremental update against 'next' branch

NOTE: This patch requires: 4e63dcc Git.pm: add new temp_is_locked function which is currently in next. Versions v2-v3 of the "allow git-svn fetching to work using serf" patch introduced a bug when attempting to change the Git.pm _temp_cache function to use the new temp_is_locked function at th

[PATCH 1/1] Git.pm: revert _temp_cache use of temp_is_locked

When the temp_is_locked function was introduced, there was a desire to make _temp_cache use it. Unfortunately due to the various tests and logic flow involved changing the _temp_cache function to use the new temp_is_locked function is problematic as _temp_cache needs a slightly different test than

Re: [PATCH v4 2/2] git-svn: allow git-svn fetching to work using serf

Jonathan Nieder wrote: > (cc-ing Eric Wong, who maintains git-svn and knows both it and > the libsvn perl bindings much better than I do) I doubt that's the case anymore. I've hardly looked at SVN in many years, now. Anyways, if the patches: 1) do not introduce regressions 2) fixes real proble

Re: [PATCH v4 0/2] allow git-svn fetching to work using serf

"Kyle J. McKay" writes: > This patch allows git-svn to fetch successfully using the > serf library when given an https?: url to fetch from. > ... > Versions v2-v3 of the patch introduced a bug when attempting > to change the _temp_cache function to use the new > temp_is_locked function at the sug

Re: [RFC/PATCH v2 1/1] cygwin: Add fast_lstat() and fast_fstat() functions

Mark Levedahl writes: > Unlike the results on the fast Win7 laptop, the above show > statistically significant slow down from the fast_lstat approach. I'm > just not seeing a case for the special case handling, and of course > Junio has already voted with his preference of removing the special >

Re: [PATCH v4 2/2] git-svn: allow git-svn fetching to work using serf

On Jul 18, 2013, at 12:29, Jonathan Nieder wrote: (cc-ing Eric Wong, who maintains git-svn and knows both it and the libsvn perl bindings much better than I do) Kyle J. McKay wrote: David Rothenberger has determined the cause to be that ra_serf does not drive the delta editor in a depth-first

Re: [PATCH 1/2] git_mkstemps: correctly test return value of open()

> From: Junio C Hamano > > +test_expect_success 'git_mkstemps_mode does not fail if fd 0 is not open' ' > > + git init && > > + echo Test. >test-file && > > + git add test-file && > > + git commit -m Message. <&- > > +' > > + > > Yup. I wonder how it would fail without the fix, though ;

Re: [PATCH 1/2] git_mkstemps: correctly test return value of open()

wor...@alum.mit.edu (Dale R. Worley) writes: >> From: Junio C Hamano >> >> That's just a plain-vanilla part of POSIX shell behaviour, no? >> >> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_07_05 > > "Close standard input" is so weird I never thought it was Pos

[PATCH] git p4 test: Check ignore files with client spec

This test confirms that a file can be ignored during git p4 sync if if is excluded in P4 client specification. Signed-off-by: Vitor Antunes --- t/t9801-git-p4-branch.sh | 23 --- 1 file changed, 20 insertions(+), 3 deletions(-) diff --git a/t/t9801-git-p4-branch.sh b/t/t9801

[PATCH] git add -e: Explicitly specify that patch should have no color

After this commit: 4c7f1819b3c142ace98269a556bc929c80e7c9fd make color.ui default to 'auto' the patch file for 'git add -e' receives all the color codes. This is because diffopt.use_color defaults to -1, which causes want_color to now return 'auto'. By explicitly setting use_color to 0, we ca

Re: [PATCH 1/2] git_mkstemps: correctly test return value of open()

> From: Junio C Hamano > > That's just a plain-vanilla part of POSIX shell behaviour, no? > > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_07_05 "Close standard input" is so weird I never thought it was Posix. In that case, we can eliminate the C helper progr

Re: [RFC/PATCH v2 1/1] cygwin: Add fast_lstat() and fast_fstat() functions

On 07/18/2013 05:49 PM, Torsten Bögershausen wrote: On 2013-07-18 19.50, Ramsay Jones wrote: Hmm, that looks good. :-D Torsten reported a performance boost using the win32 stat() implementation on a linux git repo (2s -> 1s, if I recall correctly) on cygwin 1.7. Do you have a larger repo avail

[PATCH 2/2] describe: fix --contains when a tag is given as input

"git describe" takes a commit and gives it a name based on tags in its neighbourhood. The command does take a commit-ish but when given a tag that points at a commit, it should dereference the tag before computing the name for the commit. As the whole processing is internally delegated to name-re

[PATCH 1/2] name-rev: differentiate between tags and commits they point at

"git name-rev --stdin" has been fixed to convert an object name that points at a tag to a refname of the tag. The codepath to handle its command line arguments, however, fed the commit that the tag points at to the underlying naming machinery. With this fix, you will get this: $ git name-rev

[PATCH 0/2] Finishing touches to "name-rev" fix

This is an update to finish the jc/name-rev-exact-ref topic, which fixed the command to convert an object name that points at a tag to a refname of the tag (earlier, it did not show anything). The codepath to handle its command line arguments, however, fed the commit that the tag points at to the

Re: git subtree push mangles commit message newlines

Never mind, this is already fixed in a5b8e28e4eb. Sorry for the noise. Jaap On Thu, Jul 18, 2013 at 11:22:33PM +0200, Jaap Eldering wrote: > Hi all, > > I recently started using git-subtree and ran into a small issue when > pushing to the subtree repository: newlines in the commit message seem

Re: [RFC/PATCH v2 1/1] cygwin: Add fast_lstat() and fast_fstat() functions

On 2013-07-18 19.50, Ramsay Jones wrote: > Mark Levedahl wrote: >> On 07/15/2013 10:06 PM, Torsten Bögershausen wrote: >>> On 2013-07-15 21.49, Junio C Hamano wrote: Mark Levedahl writes: >> In order to limit the adverse effects caused by this implementation, >> we provide a new

[PATCH] test-lib.sh - define and use GREP_STRIPS_CR

Define a common macro for grep needing -U to allow tests to not need to inquire of specific platforms needing this option. Change t3032 and t5560 to use this rather than testing explicitly for mingw. This fixes these two tests on Cygwin. Signed-off-by: Mark Levedahl --- This replaces my earlier p

Re: [PATCH] t3032 - make compatible with systems using \r\n as a line ending

On 07/18/2013 03:19 PM, Ramsay Jones wrote: Jonathan Nieder wrote: Mark Levedahl wrote: Subtests 6, 7, and 9 rely test that merge-recursive correctly ignores whitespace when so directed. Change the particular whitespace sequences to be ones that are not known line endings so the whitespace is

git subtree push mangles commit message newlines

Hi all, I recently started using git-subtree and ran into a small issue when pushing to the subtree repository: newlines in the commit message seem not to be preserved. I was using git-subtree from [1], but can also reproduce this with the version from the main git source-tree commit 634392b26275

[PATCH 1/3] treewalk.c: Rename variable ret to cb_bits and remove some dead lines.

The variable name ret sounds like the variable to be returned, but since e6c111b4 we return error. Hence the variable name is miss leading. As this variable is used only to extract the bits from the callback of a tree object, I named it cb_bits for callback bits. Also the assignment to 0 was remov

[PATCH 2/3] http-push.c, add_send_request: Do not initialize transfer_request.

That pointer will be assigned to new memory via request = xmalloc(sizeof(*request)); 20 lines later unconditionally anyway, so it's safe to not assign it to an arbitrary variable. As this patch is a micro-optimization (for readability?) it would be nice to have as little work with this patch, so m

[PATCH 3/3] apply, find_name_traditional: Do not initialize len to the lines length.

The variable len is set to len = strchrnul(line, '\n') - line; unconditionally 9 lines later, hence we can remove the call to strlen. Signed-off-by: Stefan Beller --- builtin/apply.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtin/apply.c b/builtin/apply.c index 12186

Re: [RFC/PATCH] Add the NO_SENTINEL build variable

Ramsay Jones writes: > Jonathan Nieder wrote: >> Ramsay Jones wrote: >> >>> One of the three gcc compilers that I use does not understand the >>> sentinel function attribute. (so, it spews 108 warning messages) >> >> Do you know what version of gcc introduced the sentinel attribute? >> Would it

[PATCH5/(4+1)] Fix git-gui/po/ja.po

Signed-off-by: Yamada Saburo --- git-gui/po/ja.po | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/git-gui/po/ja.po b/git-gui/po/ja.po index 05215b9..83aeb05 100644 --- a/git-gui/po/ja.po +++ b/git-gui/po/ja.po @@ -9,9 +9,8 @@ msgstr "" "Report-Msgid-Bugs-To: \n" "POT-Cr

Re: [PATCH] Add the GIT_SENTINEL macro

Ramsay Jones wrote: > This was built on the next branch All the uses of the sentinel attribute seem to come from eccb6149 (use "sentinel" function attribute for variadic lists, 2013-07-09), so this should be okay to go on top of the jk/gcc-function-attributes branch. > --- a/git-compat-util.h >

Re: [PATCH 1/2] git_mkstemps: correctly test return value of open()

On Thu, Jul 18, 2013 at 1:32 PM, Dale R. Worley wrote: > I've been looking into writing a proper test for this patch. My first > attempt tests the symptom that was seen initially, that "git commit" > fails if fd 0 is closed. > > One problem is how to arrange for fd 0 to be closed. I could use th

Fwd: [PATCH 2/4] Update git-gui/po/ja.po (Git-gui Japanese)

-- Forwarded message -- From: Yamada Saburo Date: 2013/7/19 Subject: Re: [PATCH 2/4] Update git-gui/po/ja.po (Git-gui Japanese) To: Junio C Hamano Hi Hamano, > I suspect that is not a name Real name. >> +"Language: \n" >What is this about I used QT Linguist for Win. This l

Fwd: [PATCH 4/4] Update Japanese translation (Git-gui)

-- Forwarded message -- From: Yamada Saburo Date: 2013/7/19 Subject: Re: [PATCH 4/4] Update Japanese translation (Git-gui) To: Junio C Hamano Hi Hamano, > dubious ones like this (there is no change to the string, just the > way msgstr is formatted to make them all overlong sing

Re: [PATCH 1/2] git_mkstemps: correctly test return value of open()

On Thu, Jul 18, 2013 at 4:32 PM, Dale R. Worley wrote: > I've been looking into writing a proper test for this patch. My first > attempt tests the symptom that was seen initially, that "git commit" > fails if fd 0 is closed. > > One problem is how to arrange for fd 0 to be closed. I could use th

Re: [PATCH] Fix some sparse warnings

On Thu, Jul 18, 2013 at 09:25:50PM +0100, Ramsay Jones wrote: > Sparse issues some "Using plain integer as NULL pointer" warnings. > Each warning relates to the use of an '{0}' initialiser expression > in the declaration of an 'struct object_info'. The first field of > this structure has pointer t

Re: [PATCH 1/2] git_mkstemps: correctly test return value of open()

I've been looking into writing a proper test for this patch. My first attempt tests the symptom that was seen initially, that "git commit" fails if fd 0 is closed. One problem is how to arrange for fd 0 to be closed. I could use the bash redirection "<&-", but I think you want to be more portabl

Re: [PATCH] Add the GIT_SENTINEL macro

On Thu, Jul 18, 2013 at 09:02:12PM +0100, Ramsay Jones wrote: > The sentinel function attribute is not understood by versions of > the gcc compiler prior to v4.0. At present, for earlier versions > of gcc, the build issues 108 warnings related to the unknown > attribute. In order to suppress the w

Re: t3032 incompatible with Cygwin/Windows

Mark Levedahl wrote: > Subtests 6,7, and 9 of t3032 fail on Cygwin, and I presume will fail on > msysgit for similar reasons. Looking at test 6, the expected result is a > line ending with \r\n in text.txt. This line is extracted with grep > (grep 'justice and holiness' text.txt > actual), with

[PATCH] Fix some sparse warnings

Sparse issues some "Using plain integer as NULL pointer" warnings. Each warning relates to the use of an '{0}' initialiser expression in the declaration of an 'struct object_info'. The first field of this structure has pointer type. Thus, in order to suppress these warnings, we replace the initial

Re: [PATCH] t3032 - make compatible with systems using \r\n as a line ending

Jonathan Nieder wrote: > Mark Levedahl wrote: > >> Subtests 6, 7, and 9 rely test that merge-recursive correctly >> ignores whitespace when so directed. Change the particular whitespace >> sequences to be ones that are not known line endings so the whitespace >> is not changed when being extracted

Re: [PATCH] Fix some sparse warnings

Jeff King wrote: > On Tue, Jul 16, 2013 at 07:57:20AM +0200, Johannes Sixt wrote: > >> Am 7/15/2013 19:31, schrieb Ramsay Jones: >>> Sparse issues three "Using plain integer as NULL pointer" warnings. >>> Each warning relates to the use of an '{0}' initialiser expression >>> in the declaration of

Re: [RFC/PATCH v2 1/1] cygwin: Add fast_lstat() and fast_fstat() functions

Mark Levedahl wrote: > On 07/15/2013 10:06 PM, Torsten Bögershausen wrote: >> On 2013-07-15 21.49, Junio C Hamano wrote: >>> Mark Levedahl writes: >>> > In order to limit the adverse effects caused by this implementation, > we provide a new "fast stat" interface, which allows us to use thi

[PATCH] Add the GIT_SENTINEL macro

The sentinel function attribute is not understood by versions of the gcc compiler prior to v4.0. At present, for earlier versions of gcc, the build issues 108 warnings related to the unknown attribute. In order to suppress the warnings, we conditionally define the GIT_SENTINEL macro to provide the

Re: [RFC/PATCH] Add the NO_SENTINEL build variable

Jonathan Nieder wrote: > Ramsay Jones wrote: > >> One of the three gcc compilers that I use does not understand the >> sentinel function attribute. (so, it spews 108 warning messages) > > Do you know what version of gcc introduced the sentinel attribute? > Would it make sense for the ifdef in git

Re: [PATCH v3 0/3] Switch German translation to G+E

Thomas Rast writes: > Ralf Thielow writes: > >> This is a resend of v3 because at least one patch was >> damaged last time for whatever reason. >> >> Ralf Thielow (3): >> l10n: de.po: switch from pure German to German+English (part 1) >> l10n: de.po: switch from pure German to German+English

Re: [PATCH v3 1/2] Git.pm: add new temp_is_locked function

Kyle J. McKay wrote: > That change was made as a result of this feedback: > > On Jul 6, 2013, at 17:11, Jonathan Nieder wrote: >> Kyle McKay wrote: >> >>> The temp_is_locked function can be used to determine whether >>> or not a given name previously passed to temp_acquire is >>> currently locked.

[PATCH v2] pull: require choice between rebase/merge on non-fast-forward pull

Because it is so easy to let Git handle automatically a trivial merge with "git pull", a person who is new to Git may not realize that the project s/he is interacting with may prefer a "rebase" workflow. Add a safety valve to fail "git pull" that does not explicitly specify what branch from which

Re: [PATCH v4 2/2] git-svn: allow git-svn fetching to work using serf

(cc-ing Eric Wong, who maintains git-svn and knows both it and the libsvn perl bindings much better than I do) Kyle J. McKay wrote: > David Rothenberger has determined the cause to > be that ra_serf does not drive the delta editor in a depth-first > manner [...]. Instead, the calls come in this o

[PATCH v4 1/2] Git.pm: add new temp_is_locked function

The temp_is_locked function can be used to determine whether or not a given name previously passed to temp_acquire is currently locked. Signed-off-by: Kyle J. McKay --- perl/Git.pm | 31 ++- 1 file changed, 30 insertions(+), 1 deletion(-) diff --git a/perl/Git.pm b/p

[PATCH v4 2/2] git-svn: allow git-svn fetching to work using serf

When attempting to git-svn fetch files from an svn https?: url using the serf library (the only choice starting with svn 1.8) the following errors can occur: Temp file with moniker 'svn_delta' already in use at Git.pm line 1250 Temp file with moniker 'git_blob' already in use at Git.pm line 1250

[PATCH v4 0/2] allow git-svn fetching to work using serf

This patch allows git-svn to fetch successfully using the serf library when given an https?: url to fetch from. Unfortunately some svn servers do not seem to be configured well for use with the serf library. This can cause fetching to take longer compared to the neon library or actually cause tim

Re: [PATCH v3 1/2] Git.pm: add new temp_is_locked function

On Jul 18, 2013, at 11:34, David Rothenberger wrote: Kyle J. McKay gmail.com> writes: +sub temp_is_locked { + my ($self, $name) = _maybe_self( _); + my $temp_fd = \$TEMP_FILEMAP{$name}; + + defined $$temp_fd && $$temp_fd->opened && $TEMP_FILES{$$temp_fd} {locked}; +} + =item tem

[RFC/PATCH] rev-parse(1): logically group options

The options section of the git-rev-parse manual page has grown organically so that there now does not seem to be much logic behind the ordering of the options. It also does not make it clear that certain options must appear first on the command line. Address this by reorganising the options into

Re: [PATCH 4/4] Update Japanese translation (Git-gui)

悪魔野玉茶無 writes: > @@ -124,26 +127,23 @@ msgstr "コミット予定済、ファイル無し" > > #: git-gui.sh:2087 > msgid "File type changed, not staged" > -msgstr "ファイル型変更、コミット未予定" > +msgstr "ファイルタイプ変更、コミット未予定" There are good changes like this in this patch, and ... > #: git-gui.sh:3095 > #, tcl-format > msgid "fat

Re: [PATCH v3 1/2] Git.pm: add new temp_is_locked function

Kyle J. McKay gmail.com> writes: > +sub temp_is_locked { > + my ($self, $name) = _maybe_self( _); > + my $temp_fd = \$TEMP_FILEMAP{$name}; > + > + defined $$temp_fd && $$temp_fd->opened && > $TEMP_FILES{$$temp_fd}{locked}; > +} > + > =item temp_release ( NAME ) > > =item temp_rel

Re: [PATCH 2/4] Update git-gui/po/ja.po (Git-gui Japanese)

悪魔野玉茶無 writes: I suspect that is not a name (and I somehow have suspicion that the S-o-b is not real, either), but if you send patches as somebody that does not match your sign-off, please add From: Yamada Saburo followed by a blank line at the very beginning of the e-mail body. That

Re: [PATCH v2 1/2] Documentation: remove --prune from pack-refs examples

Jonathon Mah writes: > The option has been the default for a while, and doesn't otherwise > appear in the page. > > Signed-off-by: Jonathon Mah > --- > > Forgot sign-off in v1. Also, I was unsure whether to rewrap the > lines (and if so, to how many columns); erred on the side of > minimal chang

Re: [PATCH] pull: require choice between rebase/merge on non-fast-forward pull

Andreas Schwab writes: > John Keeping writes: > >> On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote: >>> diff --git a/git-pull.sh b/git-pull.sh >>> index 638aabb..4a6a863 100755 >>> --- a/git-pull.sh >>> +++ b/git-pull.sh >>> @@ -264,6 +274,30 @@ case "$merge_head" in >>>

Re: [PATCH 2/2] Documentation: fix git-prune example usage

Jonathon Mah writes: > --- > Documentation/git-prune.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Thanks. Can we have your sign-off? > > diff --git a/Documentation/git-prune.txt b/Documentation/git-prune.txt > index 80d01b0..bf82410 100644 > --- a/Documentation/git-prune.txt >

Re: [PATCH 1/2] git_mkstemps: correctly test return value of open()

Junio C Hamano writes: > Drew Northup writes: > >> I presume that I should apply this change to my porting of >> git_mkstemps_mode() to tig. If there are no complaints about this for >> a couple of days I will do so. > > Hmph, Thomas and I were actually asking you to give us > > Signed-off

Re: [PATCH 1/2] git_mkstemps: correctly test return value of open()

Drew Northup writes: > I presume that I should apply this change to my porting of > git_mkstemps_mode() to tig. If there are no complaints about this for > a couple of days I will do so. Hmph, Thomas and I were actually asking you to give us Signed-off-by: Drew Northup for the patch i

Re: [PATCH 5/6] blame-options.txt: place each -L option variation on its own line

Thomas Rast writes: > Eric Sunshine writes: > >> Standard practice in Git documentation is for each variation of an >> option (such as: -p / --porcelain) to be placed on its own line in the >> OPTIONS table. The -L option does not follow suit. It cuddles >> "-L ," and "-L :", separated by a comm

gitk: "Show origin of this line" triggered programatically

The "Show origin of this line" context menu command on a line in a patch in gitk is by far my most frequently used way of navigating back in history. It's so much faster than git gui blame. Now, I wish it were available right from my text editor, showing me the origin of the line under the cursor

Re: [RFC/PATCH v2 1/1] cygwin: Add fast_lstat() and fast_fstat() functions

Mark Levedahl writes: > Cygwin 1.7 is very different than the earlier, no longer supported, > and no longer available Cygwin variants in many ways, but stat is one > of them. Cygwin 1.7 uses Windows ACLs to represent file permissions, > and therefore gets the file permissions directly from the un

Re: Git tag output order is incorrect (IMHO)

Rahul Bansal writes: > IMHO "git tag" is expected to show tag-list ordered by versions. A git tag can be anything, not related to versions at all. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something

Re: [PATCH] pull: require choice between rebase/merge on non-fast-forward pull

John Keeping writes: > On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote: >> diff --git a/git-pull.sh b/git-pull.sh >> index 638aabb..4a6a863 100755 >> --- a/git-pull.sh >> +++ b/git-pull.sh >> @@ -264,6 +274,30 @@ case "$merge_head" in >> die "$(gettext "Cannot rebase o

Re: Re* [PATCH] send-email: improve SSL certificate verification

Junio C Hamano wrote: > Ramkumar, as you will still be the primary author of the resulting > commit, I tentatively added a line for your sign-off even though you > haven't signed off _this_ version yet, so that I would not forget. > If this version looks good, please tell us you would. Yeah, it se

[PATCH 1/4] Update git-gui/po/git-gui.pot

Signed-off-by: Yamada Saburo --- git-gui/po/git-gui.pot | 1045 ++-- 1 file changed, 567 insertions(+), 478 deletions(-) diff --git a/git-gui/po/git-gui.pot b/git-gui/po/git-gui.pot index 0c94f9c..6ebfc94 100644 --- a/git-gui/po/git-gui.pot +++ b/git-g

[PATCH 1/4] Update git-gui/po/git-gui.pot

Signed-off-by: Yamada Saburo --- git-gui/po/git-gui.pot | 1045 ++-- 1 file changed, 567 insertions(+), 478 deletions(-) diff --git a/git-gui/po/git-gui.pot b/git-gui/po/git-gui.pot index 0c94f9c..6ebfc94 100644 --- a/git-gui/po/git-gui.pot +++ b/git-g

[PATCH 4/4] Update Japanese translation (Git-gui)

Signed-off-by: Yamada Saburo --- git-gui/po/ja.po | 153 ++- 1 file changed, 73 insertions(+), 80 deletions(-) diff --git a/git-gui/po/ja.po b/git-gui/po/ja.po index 0bbe504..05215b9 100644 --- a/git-gui/po/ja.po +++ b/git-gui/po/ja.po @@ -7,14

[PATCH 3/4] Add Git-gui Translate ("yes", "no", "ask")

Signed-off-by: Yamada Saburo --- git-gui/lib/option.tcl | 2 +- git-gui/po/git-gui.pot | 14 +- 2 files changed, 14 insertions(+), 2 deletions(-) diff --git a/git-gui/lib/option.tcl b/git-gui/lib/option.tcl index 0cf1da1..7af858c 100644 --- a/git-gui/lib/option.tcl +++ b/git-gui/lib

[PATCH 0/4] git-gui translation update

git-gui/lib/option.tcl |2 +- git-gui/po/git-gui.pot | 1057 git-gui/po/ja.po | 1147 ++-- 3 files changed, 1200 insertions(+), 1006 deletions(-) -- To unsubscribe from this list: send the line "unsu

[PATCH v2 2/2] Documentation: fix git-prune example usage

Signed-off-by: Jonathon Mah --- Documentation/git-prune.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-prune.txt b/Documentation/git-prune.txt index 80d01b0..bf82410 100644 --- a/Documentation/git-prune.txt +++ b/Documentation/git-prune.txt @@ -59,7 +59,

[PATCH v2 1/2] Documentation: remove --prune from pack-refs examples

The option has been the default for a while, and doesn't otherwise appear in the page. Signed-off-by: Jonathon Mah --- Forgot sign-off in v1. Also, I was unsure whether to rewrap the lines (and if so, to how many columns); erred on the side of minimal changes. Documentation/git-pack-refs.txt |

Re* [PATCH] send-email: improve SSL certificate verification

Torsten Bögershausen writes: > I wasn't sure where to apply the patch, so I manually copy/paste it > on top of pu: > commit 6b1ca0f4d443ee8716857b871b0513ae85c9f112 > Merge: bce90ab f351fcf > > Thanks, t9001 passes on Mac OS X 10.6. > To be sure I didn't messed it up, please see the diff below. >

Re: Git tag output order is incorrect (IMHO)

On Thu, Jul 18, 2013 at 10:57 PM, Rahul Bansal wrote: > Hi Day, > > I am aware of that command as well. > > I think `git tag` current default order is string-based sorting. I > felt version-number based sorting and/or create-date based sorting > will be more appropriate. ok you mean the _default_

Re: Git tag output order is incorrect (IMHO)

Thanks again Duy. :-) Sorry for misspelling your name in earlier email. -- Rahul Bansal | Founder & CEO | rtCamp Solutions Pvt. Ltd. Skype: rahul286 | Twitter: @rahul286 | Web: http://rtcamp.com/ On Thu, Jul 18, 2013 at 9:26 PM, Duy Nguyen wrote: > On Thu, Jul 18, 2013 at 10:51 PM, Duy Nguyen

Re: Git tag output order is incorrect (IMHO)

Hi Day, I am aware of that command as well. I think `git tag` current default order is string-based sorting. I felt version-number based sorting and/or create-date based sorting will be more appropriate. -- Rahul Bansal | Founder & CEO | rtCamp Solutions Pvt. Ltd. Skype: rahul286 | Twitter: @rah

Re: Git tag output order is incorrect (IMHO)

On Thu, Jul 18, 2013 at 10:51 PM, Duy Nguyen wrote: > Try > > git for-each-ref --sort=committerdate --format='%(refname:short)' refs/tags And I wondered why it did not seem right. Use this one instead git for-each-ref --sort=taggerdate --format='%(refname:short)' refs/tags make it --sort=-tagge

Re: Git tag output order is incorrect (IMHO)

On Thu, Jul 18, 2013 at 10:27 PM, Rahul Bansal wrote: > I am posting here first time, so please excuse me if this is not right place > to send something like this. > > Please check - > http://stackoverflow.com/questions/6091306/can-i-make-git-print-x-y-z-style-tag-names-in-a-sensible-order > > A

Git tag output order is incorrect (IMHO)

I am posting here first time, so please excuse me if this is not right place to send something like this. Please check - http://stackoverflow.com/questions/6091306/can-i-make-git-print-x-y-z-style-tag-names-in-a-sensible-order And also - https://github.com/gitlabhq/gitlabhq/issues/4565 IMHO "g

Re: [PATCH] pull: require choice between rebase/merge on non-fast-forward pull

On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote: > diff --git a/git-pull.sh b/git-pull.sh > index 638aabb..4a6a863 100755 > --- a/git-pull.sh > +++ b/git-pull.sh > @@ -264,6 +274,30 @@ case "$merge_head" in > die "$(gettext "Cannot rebase onto multiple branches")" >

Re: Git counterpart to SVN bugtraq properties?

On 17.07.2013 15:33, John Keeping wrote: > On Wed, Jul 17, 2013 at 03:03:14PM +0200, Marc Strapetz wrote: >> I'm looking for a specification or guidelines on how a Git client should >> integrate with bug tracking systems. For SVN, one can use >> bugtraq-properties [1] to specify e.g. the issue trac

Re: [PATCH] TIG: Fix to reinstate proper operation with no arguments

Somehow this patch breaks the main view to not open the correct commit in diff view when is pressed. Back to the debugger... On 07/18/2013 12:51 AM, Drew Northup wrote: Since c7d67ab running "tig" with no options has failed with the error "tig: No revisions match the given arguments." This was

git svn exits with error error closing pipe: Bad file descriptor

After upgrade to subversion 1.8.0 on some repositories git svn clone shows two warnings: error closing pipe: Bad file descriptor at /home/users/kornet/giti/libexec/git-core/git-svn line 0. at exit. They appear because process git cat-file --batch exits before command_close_bidi_pipe is called by

Re: [PATCH 1/2] git_mkstemps: correctly test return value of open()

I presume that I should apply this change to my porting of git_mkstemps_mode() to tig. If there are no complaints about this for a couple of days I will do so. REF: $gmane/229961 On 07/17/2013 03:29 PM, Junio C Hamano wrote: Thomas Rast writes: Thomas Rast writes: From: "Dale R. Worley"

[PATCH v2 1/2] apply, entry: speak of submodules instead of subprojects

There are only four (with some generous rounding) instances in the current source code where we speak of "subproject" instead of "submodule". They are as follows: * one error message in git-apply and two in entry.c * the patch format for submodule changes The latter was introduced in 0478675 (E

[PATCH v2 2/2] show-branch: fix description of --date-order

The existing description reads as if it somehow applies a filter. Change it to explain that it is merely about the ordering. Message-proposed-by: Jonathan Nieder Signed-off-by: Thomas Rast --- builtin/show-branch.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/builtin/

Re: git svn fetch segfault on exit

Jonathan Lambrechts writes: > Every git svn call that involves a fetch produces a segmentation fault > on exit (but the operation succeeds). > > *** Error in `/usr/bin/perl': double free or corruption (!prev): > 0x02ce1ac0 *** > === Backtrace: = > /usr/lib/libc.so.6(+0x788ae)[

Re: [PATCH v3 0/3] Switch German translation to G+E

Ralf Thielow writes: > This is a resend of v3 because at least one patch was > damaged last time for whatever reason. > > Ralf Thielow (3): > l10n: de.po: switch from pure German to German+English (part 1) > l10n: de.po: switch from pure German to German+English (part 2) > l10n: de.po: swit

Re: [PATCH 5/6] blame-options.txt: place each -L option variation on its own line

Eric Sunshine writes: > Standard practice in Git documentation is for each variation of an > option (such as: -p / --porcelain) to be placed on its own line in the > OPTIONS table. The -L option does not follow suit. It cuddles > "-L ," and "-L :", separated by a comma. This is > inconsistent and

Re: [PATCH 0/6] fix blame -L regression; add tests

Eric Sunshine writes: > This series fixes a regression in "blame -L X,-N", adds blame -L tests, > and makes minor documentation adjustments. The tests, in particular, > were motivated by the desire to revisit and continue working on [1] > which extends git-blame to accept multiple -L's. That topi

git svn fetch segfault on exit

Hi, I'm using archlinux with git version 1.8.3.3, svn version 1.8.0 (r1490375) and perl v5.18.0 (built for x86_64-linux-thread-multi) Every git svn call that involves a fetch produces a segmentation fault on exit (but the operation succeeds). *** Error in `/usr/bin/perl': double free or corr

nike air max 1 Damen

NIKE FREE three.0 V2 HERREN Im Jahr 2005 wurde Messi angewiesen, seinen Vertrag mit Nike zu verbessern, aber er berichtet Nr. Möglicherweise erhält Messi einige Vorteile oder vielleicht Versuchung von Adidas, und nike air max 1 Damen dann hat er zusätzlich mod

Thomas Sabo Charms Armband

Thomas Sabo Charms Armband ist in der Regel für den großen mythischen neben eleganten Schmuck Thema Materialien Inhalt zusammen mit Blogs alle den Weg durch jeden, der betroffenen ist. Dies ist wirklich eine ausgezeichnete zuverlässige und folgenden wirklich berüh

  1   2   >