Re: Is there any efficient way to track history of a piece of code?

On Thu, 8 May 2014, Jianyu Zhan wrote: That being said, storing abstract syntax tree, instead of raw object in git. But that goes too far... well, there are the clean/smudge filters, you can have it run everything through a prettyprinter as it's checked in. with a little effort, you could d

Re: [PATCH v1 02/25] contrib: remove 'hg-to-git'

On Thu, May 08, 2014 at 07:58:13PM -0500, Felipe Contreras wrote: > There hasn't been any real activity on it since 2010. > > Plus there are better out-of-tree tools. > > No tests and no real documentation either. ACK, "git clone hg::..." is what one is supposed to use today, I guess. signat

[PATCH] How to keep a project's canonical history correct.

During the mail thread about "Pull is mostly evil" a user asked how the first parent could become reversed. This howto explains how the first parent can get reversed when viewed by the project and then explains a method to keep the history correct. Signed-off-by: Stephen P. Smith --- Documentat

Re: [PATCH v1 1/2] Remove 'git archimport'

Felipe Contreras wrote: > No updates since 2010, and no tests. Who benefits from this removal? Is this causing a maintenance burden for Junio? > Plus, foreign SCM tools should live out-of-tree anyway. Even if so, there ought to be a transitionary period in case there are any users. We would n

Re: Conforming to pep8

On Thu, May 08, 2014 at 11:36:29PM -0500, Felipe Contreras wrote: > William Giokas wrote: > > E401: Multi-line imports seems like something that would just be > > changing one line > > Yes, and make the code very annoying. It's 1 extra line in git-remote-hg, and 4 lines in git-remote-bzr. I'll ev

Re: Conforming to pep8

William Giokas wrote: > On Thu, May 08, 2014 at 09:10:25PM -0500, Felipe Contreras wrote: > > William Giokas wrote: > > > Which is a whole bunch of errors and warnings thrown by pep8. Is pep8 > > > just getting put by the wayside? I would much rather have these > > > scripts conform to that and hav

[PATCH] fixup! completion: graduate out of contrib

Actually we need a symlink for gitk. At least ArchLinux doesn't do that, so we would be fixing at least one bug. Signed-off-by: Felipe Contreras --- Makefile | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Makefile b/Makefile index 2690903..a3d27d8 100644 --- a/Makefile +++ b/Makefile @@

[PATCH v2] completion: graduate out of contrib

These have been stable and widely used for quite a long time, they even have tests outside of the contrib area, and most distributions ship them, so they can be considered part of the core already. We should be consistent and either we move the tests to contrib, or we move the completions out of c

Re: Conforming to pep8

On Thu, May 08, 2014 at 09:10:25PM -0500, Felipe Contreras wrote: > William Giokas wrote: > > Which is a whole bunch of errors and warnings thrown by pep8. Is pep8 > > just getting put by the wayside? I would much rather have these > > scripts conform to that and have an actual coding style rather

Re: [PATCH] svn-fe: Conform to pep8

On Thu, May 08, 2014 at 07:46:33PM -0700, Jonathan Nieder wrote: > Hi, > > William Giokas wrote: > > > Quite a large change, most of this was whitespace changes, though there > > were a few places where I removed a comma or added a few characters. > > Should pass through pep8 and pass every test.

Re: [PATCH] svn-fe: Conform to pep8

Hi, William Giokas wrote: > Quite a large change, most of this was whitespace changes, though there > were a few places where I removed a comma or added a few characters. > Should pass through pep8 and pass every test. Thanks! Mind if I forge your sign-off? (See Documentation/SubmittingPatches

[PATCH] svn-fe: Conform to pep8

Quite a large change, most of this was whitespace changes, though there were a few places where I removed a comma or added a few characters. Should pass through pep8 and pass every test. --- contrib/svn-fe/svnrdump_sim.py | 93 +++--- 1 file changed, 52 insertio

Re: [PATCH v1 07/25] contrib: remove 'git-jump'

Jeff King wrote: > On Thu, May 08, 2014 at 07:58:18PM -0500, Felipe Contreras wrote: > > > No activity, no tests. > > Like diff-highlight, I don't think "no activity" is a useful indicator. > I use this daily, and several people have commented off-list to me that > they use it, too. Add tests th

Re: [PATCH v1 12/25] contrib: remove 'vim'

Hi, Jeff King wrote: > However, I would certainly agree that that period of time is probably > over; the scripts started shipping in upstream vim in mid-2008. I'd be > happy to see this directory go away whether or not the rest of contrib/ > is dropped. RHEL 6 has vim 7.2.something, so yeah, thi

[ANNOUNCE] tig-2.0.2

Here's another bug fix release that addresses an issue with loading the refs, main and grep views when gui.encoding was set, a build failure on OS X 10.6 as well as a few other bugs reported since 2.0.1. What is Tig? Tig is an ncurses-based text-mode interface for git. It functions ma

RE: Conforming to pep8

William Giokas wrote: > Which is a whole bunch of errors and warnings thrown by pep8. Is pep8 > just getting put by the wayside? I would much rather have these > scripts conform to that and have an actual coding style rather than > just be a hodge-podge of different styles. Personally I try to fol

Re: [PATCH v1 00/25] contrib: cleanup

Martin Langhoff wrote: > On Thu, May 8, 2014 at 8:58 PM, Felipe Contreras > wrote: > > > Let us be honest, the vast majority of tools in 'contrib/' have no chance > > of > > ever graduating, so let's remove them. > > > > I am curious -- have you checked what parts of contrib downstreams > packag

Re: Conforming to pep8

(cc-ing Pete Wyckoff who maintains git-p4 and Michael Haggerty who maintains git-multimail) Hi, William Giokas wrote: > - We follow PEP-8 (http://www.python.org/dev/peps/pep-0008/). > > It's even the first thing that you see when you go looking for 'python' > in the coding style document. I

Re: [PATCH v1 19/25] contrib: remove 'diff-highlight'

Jeff King wrote: > On Thu, May 08, 2014 at 07:58:30PM -0500, Felipe Contreras wrote: > > > No activity since 2012, no tests, no chance of ever graduating. > > I don't think "no activity" is an interesting indicator. This tool _is_ > actively maintained, but it has not needed any fixes since 2012.

Re: [PATCH v1 07/25] contrib: remove 'git-jump'

On Thu, May 08, 2014 at 07:58:18PM -0500, Felipe Contreras wrote: > No activity, no tests. Like diff-highlight, I don't think "no activity" is a useful indicator. I use this daily, and several people have commented off-list to me that they use it, too. Like diff-highlight, I'm happy to maintain

Re: [PATCH v1 12/25] contrib: remove 'vim'

On Thu, May 08, 2014 at 07:58:23PM -0500, Felipe Contreras wrote: > There's nothing there. It's not nothing; we used to carry the tools here, and replaced them with pointers when the tools themselves went away. That was certainly useful for a period of time. However, I would certainly agree that

Conforming to pep8

Hi all, So I have been looking into the python code in the git tree recently (contrib and core tree) and noticed that almost none of the files fully conform to pep8. Now I'm not just saying this because I like the code to be clean, readable and easily parsed by humans, but also because this is lai

Re: Output from "git blame A..B -- path" for the bottom commit is misleading

On Thu, May 08, 2014 at 02:56:46PM -0700, Junio C Hamano wrote: > In short: > > - I am not considering nor proposing to change the default at all. > > - I have two choices, either change the behaviour of "-b", or >introducing a new option (the latter includes "-b -b"); I am >slightly i

Re: [PATCH v1 19/25] contrib: remove 'diff-highlight'

On Thu, May 08, 2014 at 07:58:30PM -0500, Felipe Contreras wrote: > No activity since 2012, no tests, no chance of ever graduating. I don't think "no activity" is an interesting indicator. This tool _is_ actively maintained, but it has not needed any fixes since 2012. I use it for every single "g

Re: [PATCH v1 00/25] contrib: cleanup

On Thu, May 8, 2014 at 8:58 PM, Felipe Contreras wrote: > Let us be honest, the vast majority of tools in 'contrib/' have no chance of > ever graduating, so let's remove them. I am curious -- have you checked what parts of contrib downstreams package&ship? Are you planning on CC'ing the (inactive

[PATCH v1 2/2] Remove 'git quiltimport'

No updates since 2009 and no tests. Foreign SCM tools should live out-of-tree anyway. Cc: Johannes Schindelin Signed-off-by: Felipe Contreras --- .gitignore| 1 - Documentation/git-quiltimport.txt | 54 --- Makefile | 1 - comma

[PATCH v1 1/2] Remove 'git archimport'

No updates since 2010, and no tests. Plus, foreign SCM tools should live out-of-tree anyway. Cc: Eric Wong Cc: Martin Langhoff Signed-off-by: Felipe Contreras --- .gitignore |1 - Documentation/git-archimport.txt | 112 Makefile |1 -

[PATCH v1 0/2] Remove foreign SCMs

Both `git archimport` and `git quiltimport` haven't really been maintained, and they don't even have tests. There are tools in the contrib/ area that do have tests and are actively maintained, and they don't gradauate to the core. Let's not have double standards and remove these unused tools. F

[PATCH v1 10/25] contrib: reomve 'thunderbird-patch-inline'

No activity, no tests. Signed-off-by: Felipe Contreras --- contrib/thunderbird-patch-inline/README | 20 contrib/thunderbird-patch-inline/appp.sh | 55 2 files changed, 75 deletions(-) delete mode 100644 contrib/thunderbird-patch-inline/README del

[PATCH v1 11/25] contrib: remove 'workdir'

No activity since 2010, no documentation, no tests. Signed-off-by: Felipe Contreras --- contrib/workdir/git-new-workdir | 82 - 1 file changed, 82 deletions(-) delete mode 100755 contrib/workdir/git-new-workdir diff --git a/contrib/workdir/git-new-workdi

[PATCH v1 16/25] contrib: remove 'persistent-https'

No activity. No tests. No chance of ever moving into the core because it uses Go. Signed-off-by: Felipe Contreras --- contrib/persistent-https/LICENSE | 202 - contrib/persistent-https/Makefile | 38 --- contrib/persistent-https/README| 62 --

[PATCH v1 19/25] contrib: remove 'diff-highlight'

No activity since 2012, no tests, no chance of ever graduating. Cc: Jeff King Signed-off-by: Felipe Contreras --- contrib/diff-highlight/README | 152 - contrib/diff-highlight/diff-highlight | 173 -- 2 files changed, 325 delet

[PATCH v1 09/25] contrib: remove 'gitview'

No activity since 2007. Better out-of-tree tools out there. Cc: Aneesh Kumar K.V Signed-off-by: Felipe Contreras --- contrib/gitview/gitview | 1305 --- contrib/gitview/gitview.txt | 57 -- 2 files changed, 1362 deletions(-) delete mode 100755 con

[PATCH v1 24/25] contrib: remove 'hooks'

No activity since 2008, no tests, no documentation. Cc: Gerrit Pape Cc: Shawn O. Pearce Cc: Andy Parkins Signed-off-by: Felipe Contreras --- contrib/hooks/post-receive-email | 759 -- contrib/hooks/pre-auto-gc-battery | 42 --- contrib/hooks/setgitperms.p

[PATCH v1 13/25] contrib: remove 'svn-fe'

No activity since 2012, no tests. Cc: Jonathan Nieder Signed-off-by: Felipe Contreras --- contrib/svn-fe/.gitignore | 4 --- contrib/svn-fe/Makefile| 63 - contrib/svn-fe/svn-fe.c| 18 --- contrib/svn-fe/svn-fe.txt | 71

[PATCH v1 17/25] contrib: remove 'git-resurrect'

No activity, no documentation, no tests, no chance of ever graduating. Signed-off-by: Felipe Contreras --- contrib/git-resurrect.sh | 182 --- 1 file changed, 182 deletions(-) delete mode 100755 contrib/git-resurrect.sh diff --git a/contrib/git-resur

[PATCH v1 12/25] contrib: remove 'vim'

There's nothing there. Signed-off-by: Felipe Contreras --- contrib/vim/README | 22 -- 1 file changed, 22 deletions(-) delete mode 100644 contrib/vim/README diff --git a/contrib/vim/README b/contrib/vim/README deleted file mode 100644 index 8f16d06..000 --- a/contrib/vi

[PATCH v1 14/25] contrib: remove 'rerere-train'

No activity, no nothing. Signed-off-by: Felipe Contreras --- contrib/rerere-train.sh | 52 - 1 file changed, 52 deletions(-) delete mode 100755 contrib/rerere-train.sh diff --git a/contrib/rerere-train.sh b/contrib/rerere-train.sh deleted file mo

[PATCH v1 20/25] contrib: remove 'contacts'

There are better out-of-tree tools, and this tool is not planned to move into the core anyway. No tests either. Cc: Eric Sunshine Signed-off-by: Felipe Contreras --- contrib/contacts/git-contacts | 203 -- contrib/contacts/git-contacts.txt | 94

[PATCH v1 22/25] contrib: remove 'fast-import'

No tests, no documentation. No chance of ever graduating. Cc: Johannes Schindelin Cc: David Aguilar Signed-off-by: Felipe Contreras --- contrib/fast-import/git-import.perl | 64 - contrib/fast-import/git-import.sh | 38 --- contrib/fast-import/git-p4.README |

[PATCH v1 08/25] contrib: remove 'git-shell-commands'

No activity, no tests. Signed-off-by: Felipe Contreras --- contrib/git-shell-commands/README | 18 -- contrib/git-shell-commands/help | 18 -- contrib/git-shell-commands/list | 10 -- 3 files changed, 46 deletions(-) delete mode 100644 contrib/git-she

[PATCH v1 15/25] contrib: remove 'remotes2config'

No activity since 2007. No documentation, no tests. Signed-off-by: Felipe Contreras --- contrib/remotes2config.sh | 33 - 1 file changed, 33 deletions(-) delete mode 100755 contrib/remotes2config.sh diff --git a/contrib/remotes2config.sh b/contrib/remotes2config

[PATCH v1 03/25] contrib: remove 'stats'

No real activity since 2012 (or ever), no tests, no documentation. Signed-off-by: Felipe Contreras --- contrib/stats/git-common-hash | 26 -- contrib/stats/mailmap.pl | 70 -- contrib/stats/packinfo.pl | 212 -- 3 files changed,

[PATCH v1 05/25] contrib: remove 'convert-objects'

No activity since 2010, no tests, no documentation. Signed-off-by: Felipe Contreras --- contrib/convert-objects/convert-objects.c | 329 contrib/convert-objects/git-convert-objects.txt | 29 --- 2 files changed, 358 deletions(-) delete mode 100644 contrib/convert

[PATCH v1 07/25] contrib: remove 'git-jump'

No activity, no tests. Signed-off-by: Felipe Contreras --- contrib/git-jump/README | 92 --- contrib/git-jump/git-jump | 69 --- 2 files changed, 161 deletions(-) delete mode 100644 contrib/git-jump/README delete mod

[PATCH v1 04/25] contrib: remove 'buildsystems'

No activity since 2010, no documentation, no tests. Signed-off-by: Felipe Contreras --- contrib/buildsystems/Generators.pm| 42 -- contrib/buildsystems/Generators/QMake.pm | 189 - contrib/buildsystems/Generators/Vcproj.pm | 626 -- contrib/buildsyst

[PATCH v1 00/25] contrib: cleanup

Let us be honest, the vast majority of tools in 'contrib/' have no chance of ever graduating, so let's remove them. The vast majority of tools don't have documentation or tests, and aren't even maintained. A few, like 'remote-helpers', won't graduate even if they are perfect. These tools apparent

[PATCH v1 02/25] contrib: remove 'hg-to-git'

There hasn't been any real activity on it since 2010. Plus there are better out-of-tree tools. No tests and no real documentation either. Cc: Miklos Vajna Signed-off-by: Felipe Contreras --- contrib/hg-to-git/hg-to-git.py | 255 contrib/hg-to-git/hg-t

[PATCH v1 06/25] contrib: remove 'diffall'

No activity since 2010, no tests. Cc: Tim Henigan Signed-off-by: Felipe Contreras --- contrib/diffall/README | 31 -- contrib/diffall/git-diffall | 257 2 files changed, 288 deletions(-) delete mode 100644 contrib/diffall/README delete mo

Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)

David Lang wrote: > On Thu, 8 May 2014, Felipe Contreras wrote: > > If submodules were an integral part of Git that would be a possibility, > > but they are more like a hack. > > Well, if git.git can't use them, then how can anyone else be expected to. That is a very good question. > I haven't b

Submodule improvements (Re: What's cooking in git.git (Apr 2014, #09; Tue, 29))

Hi, David Lang wrote: > I haven't been paying close attention for a while, what would have > to be done to make submodules "an integral part of Git"? The series at http://thread.gmane.org/gmane.comp.version-control.git/241455 is a start. I'm hoping to get a reroll done soon and then I can talk

Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)

On Thu, 8 May 2014, Felipe Contreras wrote: Chris Packham wrote: On 06/05/14 11:50, Junio C Hamano wrote: The same argument would apply to git-svn, git-p4, and git-cvsimport, I would think. A bit of a crazy suggestion and a little off-topic. Assuming maintainers can be found what about havin

Re: [PATCH 0/4] remote-hg: more improvements

Felipe Contreras wrote: > Junio C Hamano wrote: > > I do not see a strong reason to move it out of contrib, either. > > Really? So why did you say this?[2] > > > > Either way, I think if things go well, remote-hg will prove it's > > > worth and move out of contrib and into git's core. > > > > T

Re: Output from "git blame A..B -- path" for the bottom commit is misleading

On Thu, May 08, 2014 at 11:32:01PM +0200, David Kastrup wrote: > Jeff King writes: > > > On Thu, May 08, 2014 at 01:52:38PM -0700, Junio C Hamano wrote: > > > >> ( 103) > >> 7bbc458b (Kyle J. McKay 2014-04-22 04:16:22 -0700 104) test_exp

Re: [PATCH 0/4] remote-hg: more improvements

Junio C Hamano wrote: > Felipe Contreras writes: > > > I already said this multiple times, but let me be clear once more: > > > > MASTER HAS A REGRESSION (for all versions of Mercurial). > > As you said, that is not a regression, isn't it? It is an old > breakage that existed even before 1.9 (w

Re: [PATCH 0/4] remote-hg: more improvements

Felipe Contreras writes: > I already said this multiple times, but let me be clear once more: > > MASTER HAS A REGRESSION (for all versions of Mercurial). As you said, that is not a regression, isn't it? It is an old breakage that existed even before 1.9 (was it 1.8.3 or something?) >> If you

Re: [PATCH 0/4] remote-hg: more improvements

Junio C Hamano wrote: > > I don't want to do anything for a "contrib" tool. > > > > It's already broken in v2.0 anyway. > > Yes, this is not even an old regression. Yes it is. It has nothing to do with with Mercurial v3.0, that's a separate issue. We've been doing a workaround since v1.8.3, and

Unexpected behavior using -c to pass url..insteadof

Is this the expected operation using git -c to override gitconfig settings? This is default behavior: $ git ls-remote git://original.site/origin fatal: unable to connect to original.site: This is what I expected, override with an insteadof url using -c on the command line: $ git

Re: t5539 fails on ubuntu for v2.0.0-rc2 - the SAME on 12.04 server

Hi, strange that no one gets the error. I get also on another server 12.04.4 LTS so the problem is not on a single VM or version. No idea? Fabio D'Alfonso 'Enabling Business Through IT' cell. +39.348.059.40.22 *** web: www.fabiodalfonso.com email: fabio.dalfo..

Re: Output from "git blame A..B -- path" for the bottom commit is misleading

John Keeping writes: > Yes, it's marking it as a boundary but I'm not convinced that's correct. > Compare these two cases: > > $ git blame Makefile | head -5 > 7a3fc144 (John Keeping 2013-12-26 17:37:53 + 1) REL_VERSION = v0.2 > 5c9829f9 (John Keeping 2013-07-29 17:03:26 +0100 2

Re: [PATCH 0/4] remote-hg: more improvements

Felipe Contreras writes: > Junio C Hamano wrote: >> In other words, I knew that you are capable enough to track down a >> bug in the code you wrote recently that made it violate the >> expectation you defined in your own tests. > > Wrong. The code in question was not recent, it was introdued in 1

Re: Output from "git blame A..B -- path" for the bottom commit is misleading

On Thu, May 08, 2014 at 11:10:24PM +0100, John Keeping wrote: > On Thu, May 08, 2014 at 02:58:58PM -0700, Junio C Hamano wrote: > > John Keeping writes: > > > > > On a slight tangent, I tried this in a fairly young repository and got > > > this (with master at v2.0.0-rc2-4-g1dc51c6): > > > > > >

Re: Output from "git blame A..B -- path" for the bottom commit is misleading

On Thu, May 08, 2014 at 02:58:58PM -0700, Junio C Hamano wrote: > John Keeping writes: > > > On a slight tangent, I tried this in a fairly young repository and got > > this (with master at v2.0.0-rc2-4-g1dc51c6): > > > > $ git blame Makefile | head -5 > > 7a3fc144 (John Keeping 2013-12-26 17

Re: Output from "git blame A..B -- path" for the bottom commit is misleading

John Keeping writes: > On a slight tangent, I tried this in a fairly young repository and got > this (with master at v2.0.0-rc2-4-g1dc51c6): > > $ git blame Makefile | head -5 > 7a3fc144 (John Keeping 2013-12-26 17:37:53 + 1) REL_VERSION = v0.2 > 5c9829f9 (John Keeping 2013-07-29

Re: Output from "git blame A..B -- path" for the bottom commit is misleading

In short: - I am not considering nor proposing to change the default at all. - I have two choices, either change the behaviour of "-b", or introducing a new option (the latter includes "-b -b"); I am slightly in favor of the latter, but not by a large margin. - I have two choices, regar

Re: Output from "git blame A..B -- path" for the bottom commit is misleading

On Thu, May 08, 2014 at 01:52:38PM -0700, Junio C Hamano wrote: > I am tempted to say "blame that is run without the --porcelain > option is a end-user facing Porcelain, and people should not be > reading its output in their scripts" and change the behaviour of the > "-b" option to instead show som

Re: [GUILT 25/28] "guilt push" now fails when there are no more patches to push.

On Thu, May 8, 2014 at 12:04 AM, Jeff Sipek wrote: > On Fri, Mar 21, 2014 at 08:32:03AM +0100, Per Cederqvist wrote: >> This makes it easier to script operations on the entire queue, for >> example run the test suite on each patch in the queue: >> >> guilt pop -a;while guilt push; do make test

Re: Output from "git blame A..B -- path" for the bottom commit is misleading

Jeff King writes: > On Thu, May 08, 2014 at 01:52:38PM -0700, Junio C Hamano wrote: > >> ( 103) >> 7bbc458b (Kyle J. McKay 2014-04-22 04:16:22 -0700 104) test_expect_... >> ( 105)

Re: Output from "git blame A..B -- path" for the bottom commit is misleading

On Thu, May 08, 2014 at 01:52:38PM -0700, Junio C Hamano wrote: > ( 103) > 7bbc458b (Kyle J. McKay 2014-04-22 04:16:22 -0700 104) test_expect_... > ( 105) test... > 7bbc458b

Re: Output from "git blame A..B -- path" for the bottom commit is misleading

Junio C Hamano writes: > If you run > > $ git blame -L103,107 v2.0.0-rc0..v2.0.0-rc2 t/t9117-git-svn-init-clone.sh > > you will see something like this: > > ^cc29195 (Junio C Hamano 2014-04-18 11:21:43 -0700 103) > 7bbc458b (Kyle J. McKay 2014-04-22 04:16:22 -0700 104) test_expect_.

Re: [PATCH 2/2] ignorecase: Fix git mv on insensitive filesystems

David Turner writes: >> Hmm, I would find it easier to read if it were: >> >> ... if (lstat(dst, &st) == 0 && >> !(ignore_case && !strcasecmp(src, dst))) { >> >> That is, "it is an error for dst to exist, unless we are on a case >> insensitive filesystem and sr

Output from "git blame A..B -- path" for the bottom commit is misleading

If you run $ git blame -L103,107 v2.0.0-rc0..v2.0.0-rc2 t/t9117-git-svn-init-clone.sh you will see something like this: ^cc29195 (Junio C Hamano 2014-04-18 11:21:43 -0700 103) 7bbc458b (Kyle J. McKay 2014-04-22 04:16:22 -0700 104) test_expect_... ^cc29195 (Junio C Hamano 2014-0

Bash v4 on msysgit?

How can I get Bash v4 for msysgit 1.9.2? I need it for 'globstar' shopt support. Thanks in advance. -- 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 2/2] ignorecase: Fix git mv on insensitive filesystems

> I also have not tried on Windows. I put in an email to the one > Windows-using friend I can think of to ask her to give Windows Explorer > (or whatever it's called these days) a try. My guess (based on a quick > Google search) would be is that it works without error, but I will send > an update

Re: [PATCH 2/2] ignorecase: Fix git mv on insensitive filesystems

On Thu, 2014-05-08 at 12:54 -0700, Junio C Hamano wrote: > dtur...@twopensource.com writes: > > > From: David Turner > > > > Make it possible to change the case of a filename on a > > case-insensitive filesystem using git mv. Change git mv to allow > > moves where the destination file exists if

[PATCH] Revert "submodules: fix ambiguous absolute paths under Windows"

This reverts commit 4dce7d9b408b2935b85721b54a2010eda7ec1be9, which was originally done to help Windows but was almost immediately reverted in msysGit, and the codebase kept this unnecessary divergence for almost two years. Signed-off-by: Stepan Kasal Signed-off-by: Junio C Hamano --- On Thu, Ma

Re: [PATCH 0/4] remote-hg: more improvements

James Denholm wrote: > Felipe, I would ask, suggest, beg, implore you to calm down. I am calmed down. I waited a day before replying to make sure of that. > It's generally not a good plan to alienate the maintainer of a > project, regardless of the correctness or incorrectness of one's > argument

Re: [GUILT 20/28] "guilt graph": Handle patch names containing quotes.

On Tue, May 6, 2014 at 10:24 PM, Jeff Sipek wrote: > On Fri, Mar 21, 2014 at 03:57:37AM -0400, Eric Sunshine wrote: >> On Fri, Mar 21, 2014 at 3:31 AM, Per Cederqvist wrote: >> > Quote quotes with a backslash in the "guitl graph" output. Otherwise, >> >> s/guitl/guilt/ > > Yep. Oups. Will fix.

Re: [PATCH] Windows: Always normalize paths to Windows-style

Stepan Kasal writes: > This one was accepted to git, but was reverted in msysGit almost > immediately by 64a8a03. Things stayed that way for 2 years. > So it seems no one has ever actually used this code. > Consequently, I propose to revert 4dce7d9b from git. OK, let's do this. I'd like you to

Re: [PATCH 0/4] remote-hg: more improvements

Junio C Hamano wrote: > In other words, I knew that you are capable enough to track down a > bug in the code you wrote recently that made it violate the > expectation you defined in your own tests. Wrong. The code in question was not recent, it was introdued in 1.8.3, more than one year ago. And

Re: [GUILT 07/28] Added test cases for "guilt fold".

On Thu, May 08, 2014 at 09:41:22PM +0200, Per Cederqvist wrote: > On Wed, May 7, 2014 at 11:06 PM, Jeff Sipek wrote: > > On Wed, May 07, 2014 at 10:59:56PM +0200, Per Cederqvist wrote: > >> On Tue, May 6, 2014 at 9:40 PM, Jeff Sipek wrote: > >> > On Fri, Mar 21, 2014 at 08:31:45AM +0100, Per Cede

Re: [PATCH 2/2] ignorecase: Fix git mv on insensitive filesystems

dtur...@twopensource.com writes: > From: David Turner > > Make it possible to change the case of a filename on a > case-insensitive filesystem using git mv. Change git mv to allow > moves where the destination file exists if the destination file has > the same name as the source file ignoring ca

Re: [PATCH 1/2] merge-recursive.c: Fix case-changing merge.

Thanks; I think this is identical to what we already have on the dt/merge-recursive-case-insensitive topic. -- 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: [GUILT 07/28] Added test cases for "guilt fold".

On Wed, May 7, 2014 at 11:06 PM, Jeff Sipek wrote: > On Wed, May 07, 2014 at 10:59:56PM +0200, Per Cederqvist wrote: >> On Tue, May 6, 2014 at 9:40 PM, Jeff Sipek wrote: >> > On Fri, Mar 21, 2014 at 08:31:45AM +0100, Per Cederqvist wrote: >> >> Test that we can combine any combination of patches

Re: Watchman support for git

On 03.05.2014 05:40, Felipe Contreras wrote: >>> That's very interesting. Do you get similar improvements when doing >>> something similar in Merurial (watchman vs . no watchman). >> >> I have not tried it. My understanding is that this is why Facebook >> wrote Watchman and added support for it t

Re: How to keep a project's canonical history correct.

"Stephen P. Smith" writes: > During the mail thread about "Pull is mostly evil" a user asked how > the first parent could become reversed. > > This howto explains how the first parent can get reversed when viewed > by the project and then explains a method to keep the history correct. > > Signed-

Re: [PATCH 0/4] remote-hg: more improvements

Felipe Contreras writes: >> There may be some other changes that this series depends on that I >> may have missed that caused this breakage. Can you take a look? > > I'm such a bad maintainer and I don't take constructive criticism well > why would you expect me to take a look? Because this was

Re: Is there any efficient way to track history of a piece of code?

Jianyu Zhan writes: > On Thu, May 8, 2014 at 3:00 PM, Jeff King wrote: >> Try "tig blame"[1]; from the blame view, the "," command will restart >> the blame at REF^ automatically. If you don't mind a more graphical >> interface, I think "git gui blame" can also reblame from the parent from >> t

Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)

Chris Packham writes: > A bit of a crazy suggestion and a little off-topic. Assuming maintainers > can be found what about having these foreign vcs interfaces as > submodules. That way they can be in Junio's tree as well as having their > own release cycles. The same could apply to git-gui, gitk

Re: [PATCH] contrib/subtree bugfix: Can't `add` annotated tag

James Denholm writes: > cmd_add_commit() is passed FETCH_HEAD by cmd_add_repository, which is > then rev-parsed into an object ID. However, if the user is fetching a > tag rather than a branch HEAD, such as by executing: > > $ git subtree add -P oldGit https://github.com/git/git.git tags/v1.8.0 >

Re: [GIT PULL] l10n update on Swedish

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: [PATCH] shell doc: remove stray "+" in example

Jeff King writes: > On Wed, May 07, 2014 at 04:44:01PM -0700, Jonathan Nieder wrote: > >> The git-shell(1) manpage says >> >> EXAMPLE >> To disable interactive logins, displaying a greeting >> instead: >> >> + >> >> $ chsh -s /usr/bin/

[PATCH 0/2] Re: ignorecase: Fix git mv on insensitive filesystems

Torsten Bögershausen wrote: > On 05/08/2014 08:37 AM, Johannes Sixt wrote: > > What if both inums are zero? Can this happen on any sane POSIX system? I > > don't know, but my gut feeling is that inode zero is too special to be > > allocated for files or directories. > > > > In that case, it is safe

[PATCH 1/2] merge-recursive.c: Fix case-changing merge.

From: David Turner On a case-insensitive filesystem, when merging, a file would be wrongly deleted from the working tree if an incoming commit had renamed it changing only its case. When merging a rename, the file with the old name would be deleted -- but since the filesystem considers the old n

[PATCH 2/2] ignorecase: Fix git mv on insensitive filesystems

From: David Turner Make it possible to change the case of a filename on a case-insensitive filesystem using git mv. Change git mv to allow moves where the destination file exists if the destination file has the same name as the source file ignoring case. Signed-off-by: David Turner --- builti

unexpected behaviour for "git diff --word-diff"

Hi, I get an unexpected behaviour for "git diff --word-diff" if 2 adjacent lines start and end with the same letter. I tried versions 1.7.9 and 1.9.0. Attached is a script with 7 examples. For each example, a file with 2 lines is compared to a file with the same lines, only 1 or 2 letters appende

Re: [BUG?] Patches created with 'diff.noprefix=true' don't 'git apply'.

Nathan Collins writes: >> What would you propose to make clickable in a renaming diff, though? > > Your 'Index' header looks good, and I would expect a renaming diff to > have something like > > Index: foo -> bar > > as in 'git status', Heh, please don't call "Index:" *mine* --- It is a CVS ab

Re: t5539 fails on ubuntu for v2.0.0-rc2

The message seems common around the apache issues but the previous test t5538 that uses start and stop routines works. Fabio D'Alfonso 'Enabling Business Through IT' cell. +39.348.059.40.22 *** web: www.fabiodalfonso.com email: fabio.dalfo...@fabiodalfonso.com <

Re: [PATCH] Standardize python shebangs

On Thu, May 8, 2014 at 1:48 PM, Matthieu Moy wrote: > It is very important that git-multimail keeps running with Python2 > (ideally, it could be portable Python 2 or 3, but it's not so easy to > do), but that would be strange to force even non-git-multimail-users to > use Python2 for that. FWIW,

Re: [PATCH] Standardize python shebangs

James Denholm writes: > On 8 May 2014 06:57:13 GMT+10:00, Matthieu Moy > wrote: >>Felipe Contreras writes: >> >>> Matthieu Moy wrote: Felipe Contreras writes: > If you want to use python2, then use '/usr/bin/env python2'. Err, yes, this is what the code does before your p

  1   2   >