Re: [PATCH] fixup! t3210: test for spurious error messages for dangling packed refs

On 04/24/2013 05:25 PM, Michael Haggerty wrote: > On 04/23/2013 07:50 PM, Junio C Hamano wrote: >> Michael Haggerty writes: >> >>> Let me know if you would prefer that I re-roll. >> >> Your fix-up cleanly applied to the result of applying the series up >> to 16/33 and it was trivial to squash it i

Re: [ANNOUNCE] Git v1.8.3-rc0

On 04/27/2013 04:24 AM, shawn wilson wrote: > On Fri, Apr 26, 2013 at 8:22 PM, Junio C Hamano wrote: > >> * There was no good way to ask "I have a random string that came from >>outside world. I want to turn it into a 40-hex object name while >>making sure such an object exists". A new

[PATCH] clone: allow cloning local paths with colons in them

Usually "foo:bar" is interpreted as an ssh url. This patch allows to clone from such paths by putting at least one slash before the colon (i.e. /path/to/foo:bar or just ./foo:bar). file://foo:bar should also work, but local optimizations are off in that case, which may be unwanted. While at there,

Re: [PATCH v4 01/11] Add new git-related helper to contrib

Felipe Contreras wrote: > That's fine, I was mostly asking Ramkumar who earlier argued earlier > versions of this patch were not understandable. Sorry, still catching up with list emails. At a glance, part 1 looks much better. Will read through more carefully soon. Thanks. -- To unsubscribe fro

Re: [PATCH v3 0/9] remote-helpers: fixes and cleanups

Felipe Contreras wrote: > Updated the commit messages, so we say Bazaar instead of Mercurial, and stuff. > > Here's a bunch of cleanups mostly to synchronize remote-bzr and remote-hg. Looks reasonable. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a mess

Re: [PATCH v5] git-completion.bash: add support for path completion

On Tue, Apr 23, 2013 at 10:25 AM, Manlio Perillo wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Il 21/04/2013 12:14, Felipe Contreras ha scritto: >> On Fri, Jan 11, 2013 at 12:48 PM, Manlio Perillo >> wrote: >>> The git-completion.bash script did not implemented full, git aware, >>>

Re: [ANNOUNCE] Git v1.8.3-rc0

On Fri, Apr 26, 2013 at 8:22 PM, Junio C Hamano wrote: > * There was no good way to ask "I have a random string that came from >outside world. I want to turn it into a 40-hex object name while >making sure such an object exists". A new peeling suffix ^{object} >can be used for that

Re: [PATCH] clean: confirm before cleaning files and directories

2013/4/27 Junio C Hamano : > Junio C Hamano writes: > >> Matthieu Moy writes: >> >>> The nice thing with the confirmation dialog is that it shows the list >>> before asking (and unlike 'rm -i', it asks only once). >> >> I wouldn't object to having "clean -i", which automatically defeats >> the re

Re: [PATCH 0/5] Minor additions to git-completion.bash

On Wed, Apr 24, 2013 at 2:49 PM, Ramkumar Ramachandra wrote: > Ramkumar Ramachandra wrote: >> [...] > > Any updates on this? FWIW they all look OK to me. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org M

Re: [PATCH 12/20] remote-bzr: split marks file

On Fri, Apr 26, 2013 at 7:17 PM, Junio C Hamano wrote: > Felipe Contreras writes: > >> And in case anybody is thinking that remote-bzr is really a too fast >> moving target; even if this managed to land in 'master', it's likely >> that people were not able to push at all, and in fact, many were n

What's cooking in git.git (Apr 2013, #09; Fri, 26)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The release candidate preview 1.8.3-rc0 has been tagged. I'd like to see people focus on catching and fixing last minute regressions and incompl

[ANNOUNCE] Git v1.8.3-rc0

A release candidate preview Git v1.8.3-rc0 is now available for testing at the usual places. The release tarballs are found at: http://code.google.com/p/git-core/downloads/list and their SHA-1 checksums are: f0b0b415f0c693865895c1918859b12c4a7d5b17 git-1.8.3.rc0.tar.gz 089efc61b3d45504cb53

[ANNOUNCE] Git v1.8.2.2

The latest maintenance release Git v1.8.2.2 is now available at the usual places. The release tarballs are found at: http://code.google.com/p/git-core/downloads/list and their SHA-1 checksums are: 47a86a0a4f92998f21ada77be146676ecfd2e4af git-1.8.2.2.tar.gz 8f334c0f5433ad7513680ffd0bf0f29dd

Re: [PATCH 12/20] remote-bzr: split marks file

Felipe Contreras writes: > And in case anybody is thinking that remote-bzr is really a too fast > moving target; even if this managed to land in 'master', it's likely > that people were not able to push at all, and in fact, many were not > even able to clone in 1.8.2. So, hardly could be consider

Re: [PATCH 12/20] remote-bzr: split marks file

On Thu, Apr 25, 2013 at 8:08 PM, Felipe Contreras wrote: > This way all the remotes can share the same git objects, and the same > marks. The information we want to store per remote is very small. > > The code transparently converts from one organization of marks, to the > other. It's rather smoot

Re* [PATCH] git-remote-testgit: avoid process substitution

Felipe Contreras writes: > No, it wouldn't, but I don't think there's any way to do \<\> or \b in globs. This should do in the meantime, but it further needs: - J6t's sign off for the follow-up part to remove remaining bash-isms to complete this patch (the last part of the patch is from

Re: [PATCH v4 01/11] Add new git-related helper to contrib

On Fri, Apr 26, 2013 at 6:01 PM, Junio C Hamano wrote: > Felipe Contreras writes: > >> On Thu, Apr 25, 2013 at 2:59 PM, Felipe Contreras >> wrote: >>> This script find people that might be interested in a patch, by going >>> back through the history for each single hunk modified, and finding >>>

Re: [PATCH v3 0/9] remote-helpers: fixes and cleanups

Junio C Hamano writes: > Junio C Hamano writes: > >> Felipe Contreras writes: >> >>> Updated the commit messages, so we say Bazaar instead of Mercurial, and >>> stuff. >>> >>> Here's a bunch of cleanups mostly to synchronize remote-bzr and remote-hg. >> >> Thanks. Will queue on 'pu' without l

Re: [PATCH v4 01/11] Add new git-related helper to contrib

Felipe Contreras writes: > On Thu, Apr 25, 2013 at 2:59 PM, Felipe Contreras > wrote: >> This script find people that might be interested in a patch, by going >> back through the history for each single hunk modified, and finding >> people that reviewed, acknowledge, signed, or authored the code

Re: [PATCH v4 01/11] Add new git-related helper to contrib

Hi, On Thu, Apr 25, 2013 at 2:59 PM, Felipe Contreras wrote: > This script find people that might be interested in a patch, by going > back through the history for each single hunk modified, and finding > people that reviewed, acknowledge, signed, or authored the code the > patch is modifying. >

Re: [PATCH] git-remote-testgit: avoid process substitution

On Fri, Apr 26, 2013 at 5:25 PM, Junio C Hamano wrote: > Felipe Contreras writes: > >> On Thu, Apr 25, 2013 at 12:56 AM, Johannes Sixt wrote: >>> From: Johannes Sixt >>> >>> Bash on Windows does not implement process substitution. >> >> Nevermind, reporting all the refs creates a lot of irrelev

Re: [PATCH v3 0/9] remote-helpers: fixes and cleanups

On Fri, Apr 26, 2013 at 5:23 PM, Junio C Hamano wrote: > Junio C Hamano writes: > >> Felipe Contreras writes: >> >>> Updated the commit messages, so we say Bazaar instead of Mercurial, and >>> stuff. >>> >>> Here's a bunch of cleanups mostly to synchronize remote-bzr and remote-hg. >> >> Thanks

Re: [PATCH] git-remote-testgit: avoid process substitution

Felipe Contreras writes: > On Thu, Apr 25, 2013 at 12:56 AM, Johannes Sixt wrote: >> From: Johannes Sixt >> >> Bash on Windows does not implement process substitution. > > Nevermind, reporting all the refs creates a lot of irrelevant output, > this version is fine. When $before has this in it:

Re: [PATCH v3 0/9] remote-helpers: fixes and cleanups

Junio C Hamano writes: > Felipe Contreras writes: > >> Updated the commit messages, so we say Bazaar instead of Mercurial, and >> stuff. >> >> Here's a bunch of cleanups mostly to synchronize remote-bzr and remote-hg. > > Thanks. Will queue on 'pu' without looking. Actually, I was going to me

Re: [PATCH 1/9] remote-bzr: trivial cleanups

On Fri, Apr 26, 2013 at 5:10 PM, Junio C Hamano wrote: > Felipe Contreras writes: > >> Good, so I'll keep sending the patches, because our users benefit from >> the review. > > Just for the record, a patch sent to the list which nobody bothered > to read does not really count as reviewed. No, bu

Re: [PATCH v3 0/9] remote-helpers: fixes and cleanups

Felipe Contreras writes: > Updated the commit messages, so we say Bazaar instead of Mercurial, and stuff. > > Here's a bunch of cleanups mostly to synchronize remote-bzr and remote-hg. Thanks. Will queue on 'pu' without looking. -- To unsubscribe from this list: send the line "unsubscribe git"

Re: [PATCH 1/9] remote-bzr: trivial cleanups

Felipe Contreras writes: > Good, so I'll keep sending the patches, because our users benefit from > the review. Just for the record, a patch sent to the list which nobody bothered to read does not really count as reviewed. You can either (1) pace yourself when people are otherwise busy; or

Re: [PATCH] git-remote-testgit: avoid process substitution

On Thu, Apr 25, 2013 at 12:56 AM, Johannes Sixt wrote: > From: Johannes Sixt > > Bash on Windows does not implement process substitution. Nevermind, reporting all the refs creates a lot of irrelevant output, this version is fine. Acknowledged-by: Felipe Contreras -- Felipe Contreras -- To un

Re: [PATCH 0/2] "git add -A/--no-all" finishing touches

Junio C Hamano wrote: > --- a/builtin/add.c > +++ b/builtin/add.c > @@ -495,6 +495,8 @@ int cmd_add(int argc, const char **argv, const char > *prefix) > refresh(verbose, pathspec); > goto finish; > } > + if (implicit_dot && !prefix) > + refresh_ca

Re: [PATCH 00/20] remote-bzr: massive changes

On Fri, Apr 26, 2013 at 11:51 AM, Junio C Hamano wrote: > Felipe Contreras writes: > >> On Thu, Apr 25, 2013 at 8:07 PM, Felipe Contreras >> wrote: >> >> I forgot to mention; these apply on top of the previous 'fixes and cleanups'. > > Then I should probably wait for v2 6/9 of that series is rer

[PATCH v3 8/9] remote-bzr: strip extra newline

It's added by fast-export, the user didn't type it. Signed-off-by: Felipe Contreras --- contrib/remote-helpers/git-remote-bzr | 4 1 file changed, 4 insertions(+) diff --git a/contrib/remote-helpers/git-remote-bzr b/contrib/remote-helpers/git-remote-bzr index 8617e25..9f56297 100755 --- a

[PATCH v3 9/9] remote-bzr: use proper push method

Not just randomly synchronize the revisions with no checks at all. This is the way bazaar's UI does it. Also, add a non-ff check. Signed-off-by: Felipe Contreras --- contrib/remote-helpers/git-remote-bzr | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/contrib/remo

[PATCH v3 7/9] remote-bzr: tell bazaar to be quiet

Otherwise we get notification, progress bars, and what not. Signed-off-by: Felipe Contreras --- contrib/remote-helpers/git-remote-bzr | 3 +++ 1 file changed, 3 insertions(+) diff --git a/contrib/remote-helpers/git-remote-bzr b/contrib/remote-helpers/git-remote-bzr index dda2932..8617e25 10075

[PATCH v3 6/9] remote-bzr: store converted URL

Bazaar might convert the URL to something more appropriate, like an absolute path. Lets store that instead of the original URL, which won't work from a different working directory if it's relative. Signed-off-by: Felipe Contreras --- contrib/remote-helpers/git-remote-bzr | 13 - 1 fi

[PATCH v3 5/9] remote-hg: use hashlib instead of hg sha1 util

To be in sync with remote-bzr. Signed-off-by: Felipe Contreras --- contrib/remote-helpers/git-remote-hg | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg index 80b3606..06920f2 100755 --- a/contrib

[PATCH v3 3/9] remote-bzr: fix bad state issue

Carried from remote-hg. The problem reportedly happened after doing a push that fails, the abort causes the state of remote-hg to go bad, this happens because remote-hg's marks are not stored, but 'git fast-export' marks are. Ensure that the marks are _always_ stored. Signed-off-by: Felipe Contr

[PATCH v3 4/9] remote-bzr: add support to push URLs

Just like in remote-hg. Signed-off-by: Felipe Contreras --- contrib/remote-helpers/git-remote-bzr | 16 +--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/contrib/remote-helpers/git-remote-bzr b/contrib/remote-helpers/git-remote-bzr index 7b6584e..f1d6d5e 100755 ---

[PATCH v3 2/9] remote-hg: remove extra check

Not needed since we use xrange ourselves. Signed-off-by: Felipe Contreras --- contrib/remote-helpers/git-remote-hg | 4 1 file changed, 4 deletions(-) diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg index cfa96c1..80b3606 100755 --- a/contrib/remot

[PATCH v3 1/9] remote-helpers: trivial cleanups

No functional changes. Typos, unused variables, redundant operations, and white-spaces. Signed-off-by: Felipe Contreras --- contrib/remote-helpers/git-remote-bzr | 7 --- contrib/remote-helpers/git-remote-hg | 2 +- 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/contrib/remo

[PATCH v3 0/9] remote-helpers: fixes and cleanups

Updated the commit messages, so we say Bazaar instead of Mercurial, and stuff. Here's a bunch of cleanups mostly to synchronize remote-bzr and remote-hg. Felipe Contreras (9): remote-helpers: trivial cleanups remote-hg: remove extra check remote-bzr: fix bad state issue remote-bzr: add su

Re: Itches with the current rev spec

Felipe Contreras writes: > I don't know what 'git rebase master' does, but I would expect 'git > rebase --onto=master' to do the same thing. Then, if 'git rebase > --onto=next master..topic' makes sense, so should 'git rebase next > master..topic'. > > Moreover, it often annoys me that 'git rebas

Re: [PATCH 1/9] remote-bzr: trivial cleanups

On Fri, Apr 26, 2013 at 3:17 PM, Ramkumar Ramachandra wrote: > Felipe Contreras wrote: >> The importance of users changes all the time. The 15 year old kid in >> Sao Paulo might not be important today, but he might be the single >> most important contributor ten years from now. Hell, he might even

Re: [PATCH 1/9] remote-bzr: trivial cleanups

On Fri, Apr 26, 2013 at 3:28 PM, Ramkumar Ramachandra wrote: >> Reason is not a tool for appreciating art, reason is a tool for >> discovering truth, and if when arguing you are not interested in what >> is actually true, I'm not interested in arguing with you. > > There is no great truth to be d

Re: [PATCH 0/2] "git add -A/--no-all" finishing touches

Junio C Hamano writes: > Jonathan Nieder writes: > >> Maybe the warning should happen after add_file_to_index() has run, >> letting git compare the old and new index entries for that path? > > Yeah, new and deleted cases we do not have to worry about, so a > no-op add_file_to_index() is the only

Re: "git grep" parallelism question

On Fri, Apr 26, 2013 at 12:19 PM, Junio C Hamano wrote: > > OK, you have to recompile at least once for experiment, so perhaps > building the test binary with this patch may help. So here's my experiment on my machine with this patch and the kernel tree. First I did the warm-cache case: for i

Re: [PATCH 1/9] remote-bzr: trivial cleanups

On Fri, Apr 26, 2013 at 3:03 PM, Ramkumar Ramachandra wrote: > Felipe Contreras wrote: >> A fine way to start is to not rattle away in trivial inconsequential patches. > > I have something from Linus (TM) this time :) > > https://lkml.org/lkml/2004/12/20/255 I happen to agree with that, specially

Re: [PATCH 1/9] remote-bzr: trivial cleanups

Felipe Contreras wrote: > If you are so keen in receiving feedback from your fellow developers, > you should eventually send an email summarizing the issues and the > proposal for everyone to understand. Thanks. I'll do that in the morning. > Reason is not a tool for appreciating art, reason is

Re: [PATCH 1/9] remote-bzr: trivial cleanups

On Fri, Apr 26, 2013 at 2:56 PM, Ramkumar Ramachandra wrote: > Felipe Contreras wrote: >> We all benefit from these patches being reviewed in the git mailing >> list, nobody has claimed otherwise. You are making the error of >> assuming that your review was actionable, that I should have done >> s

Re: [PATCH 1/9] remote-bzr: trivial cleanups

Felipe Contreras wrote: > The importance of users changes all the time. The 15 year old kid in > Sao Paulo might not be important today, but he might be the single > most important contributor ten years from now. Hell, he might even > replace Junio as the maintainer. Yes, they do. Did I say that

Re: [PATCH 1/9] remote-bzr: trivial cleanups

Felipe Contreras wrote: > A fine way to start is to not rattle away in trivial inconsequential patches. I have something from Linus (TM) this time :) https://lkml.org/lkml/2004/12/20/255 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.k

Re: [PATCH 1/9] remote-bzr: trivial cleanups

On Fri, Apr 26, 2013 at 2:30 PM, Ramkumar Ramachandra wrote: > [completely off-topic; don't worry, we're just having a friendly chat] > > Felipe Contreras wrote: >> If you are not prepared to defend your review, so are others, why to >> you blame that on me? If you were right, you would be shown t

Re: [PATCH 1/9] remote-bzr: trivial cleanups

Ramkumar Ramachandra wrote: > Diversity is certainly healthy, and I it would be nice to have you in > the community. We just have to find a way to keep the conflict down. After all, what are we asking for? Better commit messages. Why are you making such a big deal out of it? You want diversity

Re: [PATCH 1/9] remote-bzr: trivial cleanups

Felipe Contreras wrote: > We all benefit from these patches being reviewed in the git mailing > list, nobody has claimed otherwise. You are making the error of > assuming that your review was actionable, that I should have done > something, fix the commit message I suppose, but I don't think that's

[RFC/PATCH 3/3] simplify-merges: drop merge from irrelevant side branch

Reimplement commit 4b7f53da on top of the new simplify-merges infrastructure, tightening the condition to only consider root parents; the original version incorrectly dropped parents that were TREESAME to anything. Original log message follows. The merge simplification rule stated in 6546b59 (rev

Re: Itches with the current rev spec

On Fri, Apr 26, 2013 at 12:49 PM, Junio C Hamano wrote: > Johannes Sixt writes: > >> Allow alternative spelling of >> >>git rebase -i master topic >> >> like this: >> >>git rebase -i master..topic >> >> (as always, the default for topic is HEAD). > > I actually made this typo a few times

[RFC/PATCH 2/3] simplify-merges: never remove all TREESAME parents

In the event of an odd merge, we may find ourselves TREESAME to apparently redundant parents. Prevent simplify_merges() from removing every TREESAME parent - in the event of such a merge it's useful to see where we came actually from came. Signed-off-by: Kevin Bracey --- Documentation/rev-list-o

Re: [PATCH 1/9] remote-bzr: trivial cleanups

Felipe Contreras wrote: > If you don't understand the reasoning and history behind remote-bzr, > you might be doing a disservice to everyone by commenting at all. Felipe, I'm trying to help. If you think my review lacked context, you can write me a paragraph/ link me to an email and I will read i

Re: [PATCH 1/9] remote-bzr: trivial cleanups

On Fri, Apr 26, 2013 at 1:53 PM, Ramkumar Ramachandra wrote: > Felipe Contreras wrote: >> What is your objective, do you want to help this project move forward or not? > > Forward, please. > > I want a solution to this persistent problem of conflict though. And > I presented one in my previous em

[RFC/PATCH 1/3] revision.c: tighten up TREESAME handling of merges

Historically TREESAME was set on a commit if it was TREESAME to _any_ of its parents. This is not optimal, as such a merge could still be worth showing, particularly if it is an odd "-s ours" merge that (possibly accidentally) dropped a change. And the problem is further compounded by the fact that

Re: [PATCH 1/9] remote-bzr: trivial cleanups

[completely off-topic; don't worry, we're just having a friendly chat] Felipe Contreras wrote: > If you are not prepared to defend your review, so are others, why to > you blame that on me? If you were right, you would be shown to be > right. Period. Felipe, there are some things that are worth a

Re: [RFC/PATCH] Make --full-history consider more merges

On 25/04/2013 21:19, Junio C Hamano wrote: How many decorations are we talking about here? One for each merge commit in the entire history? Do we have a cue that can tell us when we are really done with a commit that lets us discard the associated data as we go on digging, keeping the size of o

Re: "git grep" parallelism question

Linus Torvalds writes: > Yes. Also, I'm not sure if the 15% possible improvement on my SSD case > is even worth it for something that in the end isn't necessarily the > common case. Cold cache being uncommon case would be forever true but more and more people are on SSD, and 15% is not a trivial

Re: [PATCH 1/9] remote-bzr: trivial cleanups

On Fri, Apr 26, 2013 at 4:32 AM, Ramkumar Ramachandra wrote: > Felipe Contreras wrote: > Junio C Hamano wrote: >> I do >> not agree with Ram at all when he says that developers are more >> important than users, and I agree with you that the project exists >> for users, and not for developers. > >

Re: [PATCH] clean: confirm before cleaning files and directories

Junio C Hamano writes: > Matthieu Moy writes: > >> The nice thing with the confirmation dialog is that it shows the list >> before asking (and unlike 'rm -i', it asks only once). > > I wouldn't object to having "clean -i", which automatically defeats > the requireforce option. > > As to a huge s

[PATCH 2/2] test output: respect $TEST_OUTPUT_DIRECTORY

Most test results go in $TEST_OUTPUT_DIRECTORY, but the output files for tests run with --tee or --valgrind just use bare "test-results". Changes these so that they do respect $TEST_OUTPUT_DIRECTORY. As a result of this, the valgrind/analyze.sh script may no longer inspect the correct files so it

[PATCH 1/2] t/Makefile: fix result handling with TEST_OUTPUT_DIRECTORY

When TEST_OUTPUT_DIRECTORY is set, the test results will be generated in "$TEST_OUTPUT_DIRECTORY/test-results", which may not be the same as "test-results" in t/Makefile. This causes the aggregate-results target to fail as it finds no count files. Fix this by introducing TEST_RESULTS_DIRECTORY an

Re: "git grep" parallelism question

On Fri, Apr 26, 2013 at 11:47 AM, Junio C Hamano wrote: > > The real issue may be that we do not have a good estimate of how > many paths are involved in the request before starting these > threads, though. Yes. Also, I'm not sure if the 15% possible improvement on my SSD case is even worth it fo

Re: [PATCH 1/9] remote-bzr: trivial cleanups

Felipe Contreras wrote: > What is your objective, do you want to help this project move forward or not? Forward, please. I want a solution to this persistent problem of conflict though. And I presented one in my previous email: Here's my solution to the problem: maintain your project outside gi

Re: [PATCH 1/9] remote-bzr: trivial cleanups

On Fri, Apr 26, 2013 at 7:19 AM, Ramkumar Ramachandra wrote: > Felipe Contreras wrote: >> Any sensible reviewer would be context aware, notice that this >> is a contrib patch, and focus on behavioral changes, notice the >> mistake I made, and point that *one* of the changes was changing the >> beh

Re: "git grep" parallelism question

Linus Torvalds writes: > Wouldn't it be lovely if it was slightly smarter (something more akin > to the index preloading that takes number of files into account) or at > least allowed people to set the parallelism explicitly with a command > line switch? Yeah, a reasonable starting point for aut

Re: [PATCH] t9501: Do not use export X=Y

On Fri, Apr 26, 2013 at 09:46:09AM -0700, Junio C Hamano wrote: > Torsten Bögershausen writes: > > > On 2013-04-25 22.46, Junio C Hamano wrote: > >> Torsten Bögershausen writes: > >> > >>> Spilt lines like export X=Y into 2 lines: > >>> X=Y > >>> export X > > > > Side questions: > > Which shell

Re: [PATCH 1/9] remote-bzr: trivial cleanups

On Fri, Apr 26, 2013 at 4:32 AM, Ramkumar Ramachandra wrote: > Felipe Contreras wrote: >> I am helping my fellow developers by replying to the comments they >> make when I send the patches for review. Unfortunately, the only >> developer other than you that has made any comment at all, Ramkumar >>

Re: [PATCH] t5801: properly test the test shell

Michael J Gruber writes: >> It is a separate issue to port git-remote-testgit to POSIX (J6t >> already has a two part draft), move it to git-remote-testgit.sh, and >> get its shebang line preprocessed like all other shell scripts. I >> think it is worth doing. >> >> Takers? By the way, this hi

Re: Zile as git core editor?

Junio C Hamano writes: > Thorsten Jolitz writes: > >> ... I think what I really would like to >> have it that, when I use GNU Emacs Magit and enter a git command >> >> ,- >> | Run git like this: >> `- >> >> that calls an editor (e.g. co

[PATCH] t/Makefile: remove smoke test targets

Commit d24fbca (Remove Git's support for smoke testing - 2011-12-23) removed the smoke test support from the test suite but it was re-added by commit 342e9ef (Introduce a performance testing framework - 2012-02-17). This appears to be the result of a mis-merge, since re-adding the smoke testing in

Re: Itches with the current rev spec

Johannes Sixt writes: > Allow alternative spelling of > >git rebase -i master topic > > like this: > >git rebase -i master..topic > > (as always, the default for topic is HEAD). I actually made this typo a few times in the past. In a single-strand-of-pearls history, what rebase operates

"git grep" parallelism question

Since I reboot fairly regularly to test new kernels, I don't *always* have the kernel source tree in my caches, so I still care about some cold-cache performance. And "git grep" tends to be the most noticeable one. Now, I have a SSD, and even the cold-cache case takes just five seconds or so, but

Re: Possible bug report

Pierre-François CLEMENT writes: > As you can see, the --cumulative lines seem to be duplicated, though > the computed stats aren't exactly the same... It appears when you > combine the --cumulative option with either --stat, --numstat or > --shortstat (but not --dirstat) ... Thanks for a report.

Re: [PATCH] clean: confirm before cleaning files and directories

Matthieu Moy writes: > The nice thing with the confirmation dialog is that it shows the list > before asking (and unlike 'rm -i', it asks only once). I wouldn't object to having "clean -i", which automatically defeats the requireforce option. As to a huge single list you have to approve or reje

Re: Zile as git core editor?

Thorsten Jolitz writes: > ... I think what I really would like to > have it that, when I use GNU Emacs Magit and enter a git command > > ,- > | Run git like this: > `- > > that calls an editor (e.g. commit --amend), the running Emacs ins

Re: [PATCH 00/20] remote-bzr: massive changes

Felipe Contreras writes: > On Thu, Apr 25, 2013 at 8:07 PM, Felipe Contreras > wrote: > > I forgot to mention; these apply on top of the previous 'fixes and cleanups'. Then I should probably wait for v2 6/9 of that series is rerolled. There could be ones that you may want to reroll other than

Re: [PATCH] t9501: Do not use export X=Y

Torsten Bögershausen writes: > On 2013-04-25 22.46, Junio C Hamano wrote: >> Torsten Bögershausen writes: >> >>> Spilt lines like export X=Y into 2 lines: >>> X=Y >>> export X >> >> That can be read from the patch text. >> >> If you are going to spend three lines, please describe why it has t

Re: [PATCH] clean: confirm before cleaning files and directories

Junio C Hamano writes: > "git clean" without -n/f errors out, hinting the availablilty of -n > while mentioning -f; that is the safety, isn't it? Once the user > decides to give -f, the user _wants_ to remove cruft, and it is a > hinderance to require any further confirmation. This is only half

Re: [PATCH] clean: confirm before cleaning files and directories

Jiang Xin writes: > I don't know how many programmers had been bitten by runing `git clean -fdx`, > but I bet there were some. I think safety should be put to the 1st place. "git clean" without -n/f errors out, hinting the availablilty of -n while mentioning -f; that is the safety, isn't it? On

Re: Zile as git core editor?

Matthieu Moy writes: > Thorsten Jolitz writes: > >> BTW - would 'git config --global core.editor zile' or 'git config >> --global core.editor /usr/bin/zile' the right way to set it (both did >> not work)? I can start Zile simply with 'zile' on the command line. > > What do you mean by "did not

Re: [PATCH] inotify to minimize stat() calls

On Thu, Apr 25, 2013 at 4:20 PM, Duy Nguyen wrote: > On Fri, Apr 26, 2013 at 2:44 AM, Robert Zeh > wrote: >>> Can you just replace lstat/stat with cached_lstat/stat inside >>> git-compat-util.h and not touch all files at once? I think you may >>> need to deal with paths outside working directory

Re: [PATCHv2 7/7] git grep: honor textconv by default

Michael J Gruber writes: > BTW, textconv does not have to be slow - just use textconv-cache. Right, thanks for reminding me about this, I had forgotten its existance ;-). > I'm still looking for a way to at least treat "git grep" and "git show > blob" the same way. I agree they should be treat

Re: [BUG] Highly inconsistent diff UI

On Thu, Apr 25, 2013 at 3:54 AM, Ramkumar Ramachandra wrote: > On a related note- In my opinion, :/ is broken, because it blocks > composition completely. I would've really liked {:/quuxery}~3. For composition, you should be able to combine a ref set with @{} syntax, so you can choose to apply @

Re: Itches with the current rev spec

Johannes Sixt wrote: >git rebase -i master..topic >git rebase -i master...topic We absolutely don't want to go down the inconsistent diff UI route. See [1]. [1]: http://thread.gmane.org/gmane.comp.version-control.git/48 -- To unsubscribe from this list: send the line "unsubscribe git

Re: [PATCH 1/9] remote-bzr: trivial cleanups

Felipe Contreras wrote: > Any sensible reviewer would be context aware, notice that this > is a contrib patch, and focus on behavioral changes, notice the > mistake I made, and point that *one* of the changes was changing the > behavior, at which point I would agree and reroll either without that >

Re: [PATCHv2 7/7] git grep: honor textconv by default

Junio C Hamano venit, vidit, dixit 24.04.2013 20:55: > Matthieu Moy writes: > >> Grepping through the binary, on the other hand, can very well make >> sense, like: >> >> $ git grep foo >> file.txt: some instance of foo >> binary file bar.bin matches BTW, textconv does not have to be slow - just

Re: [BUG] Highly inconsistent diff UI

Ramkumar Ramachandra wrote: > Think of it as a time-truncated version of git log pu: it has > nothing to do with reachability. Er, scratch that out. I don't like talking in vague terms, and this feature has nothing to do with git log --since (which is what time-truncated is). -- To unsubscribe fr

Re: [BUG] Highly inconsistent diff UI

Ramkumar Ramachandra wrote: > The range version of $(git merge-base A B) B is B ^$(git merge-base A > B), and not B --not $(git merge-base --all A B) [which is equivalent > to B ^A or A..B]. Let me make this easier for you, and everyone else. In git.git, checkout master and merge 9915605c^2 (rr/s

Re: [PATCH] clean: confirm before cleaning files and directories

2013/4/26 Matthieu Moy : > Jiang Xin writes: > >> Maybe we can do like this: >> >> 1. Set the default value of 'clean.requireForce' to false. >> 2. Show a error message and do nothing, if there is not 'clean.requireForce' >> setting, but the user called with a '--force' flag. >> ( like a t

Re: [PATCH] t5801: properly test the test shell

Junio C Hamano venit, vidit, dixit 25.04.2013 19:12: > Junio C Hamano writes: > >> Michael J Gruber writes: >> >>> fc407f9 (Add new simplified git-remote-testgit, 2012-11-28) introduced a >>> test which was meant to skip the test unless the test shell is bash. >>> Unfortunately, it tests for the

Re: [PATCH 1/9] remote-bzr: trivial cleanups

Felipe Contreras wrote: > I am helping my fellow developers by replying to the comments they > make when I send the patches for review. Unfortunately, the only > developer other than you that has made any comment at all, Ramkumar > Ramachandra, did so in a bellicose tone, but I replied to all his >

Re: [PATCH] t9501: Do not use export X=Y

On 2013-04-25 22.46, Junio C Hamano wrote: > Torsten Bögershausen writes: > >> Spilt lines like export X=Y into 2 lines: >> X=Y >> export X > > That can be read from the patch text. > > If you are going to spend three lines, please describe why it has to > be split; that would help educate deve

[PATCH 5/5] t7409: do not use export X=Y

The shell syntax "export X=Y A=B" is not understood by all shells. Split the non portable line into separate lines like this: A=B X=Y export A X Signed-off-by: Torsten Bögershausen --- t/t7409-submodule-detached-worktree.sh | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) d

[PATCH 1/5] t9020: do not use export X=Y

The shell syntax "export X=Y" is not understood by all shells. Split the non portable line into separate lines like this: X=Y export X Signed-off-by: Torsten Bögershausen --- t/t9020-remote-svn.sh | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/t/t9020-remote-svn.sh b/t/t90

[PATCH 2/5] t9501: do not use export X=Y

The shell syntax "export X=Y" is not understood by all shells. Split the non portable line into separate lines like this: X=Y export X Signed-off-by: Torsten Bögershausen --- t/t9501-gitweb-standalone-http-status.sh | 15 ++- 1 file changed, 10 insertions(+), 5 deletions(-) diff --g

  1   2   >