Signed-off-by: John Keeping
---
git-submodule.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 79bfaac..bdb438b 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -485,7 +485,7 @@ c
explicitly block relative URLs
in "git submodule add" when not at the top level of the working tree.
Signed-off-by: John Keeping
---
git-submodule.sh | 135 ---
t/t7400-submodule-basic.sh | 80 +
t/t7401-submod
w uses the
relative path and matches the "sm_path" variable.
* I audited the code again and fixed a few more cases that weren't
printing relative paths (notably "submodule init" and "submodule
foreach").
* More tests.
John Keeping (6):
t7401: make ind
Change the indentation to use tabs consistently and start content on the
line after the paren opening a subshell.
Also don't put a space in ">file" and remove ":" from ": >file" to be
consistent with the majority of tests elsewhere.
Signed-off-by: Joh
Only leading whitespace is changed in this patch.
Signed-off-by: John Keeping
---
t/t7401-submodule-summary.sh | 80 ++--
1 file changed, 40 insertions(+), 40 deletions(-)
diff --git a/t/t7401-submodule-summary.sh b/t/t7401-submodule-summary.sh
index
On Sat, Jun 15, 2013 at 06:18:46PM +0200, Thomas Koch wrote:
> I'm using vcsh[1] to have my dotfiles in GIT. With that I use a .gitignore
> file
> referenced by core.excludesfile that looks like this:
>
> # ignore everything by default
> *
>
> # but do not ignore emacs stuff
> !.emacs.d/
>
> #
On Fri, Jun 14, 2013 at 06:45:19PM +0530, Ramkumar Ramachandra wrote:
> John Keeping wrote:
> > I don't think this is the correct behaviour. I can think of cases where
> > I would want to output multiple things into the same directory.
>
> format.cleanOutputDirectory =
On Fri, Jun 14, 2013 at 06:13:33PM +0530, Ramkumar Ramachandra wrote:
> The following command
>
> $ git format-patch -o outgoing master
>
> does not ensure that the output-directory outgoing doesn't already
> exist. As a result, it's possible for patches from two different series
> to get mixe
On Fri, Jun 14, 2013 at 08:12:56AM -0400, Phil Hord wrote:
> On Fri, Jun 14, 2013 at 4:56 AM, Ramkumar Ramachandra
> wrote:
> > If a rebasing pull is requested, pull unconditionally runs
> > require_clean_worktree() resulting in:
> >
> > # dirty worktree or index
> > $ git pull
> > Cannot pu
On Fri, Jun 07, 2013 at 11:47:07AM -0700, Junio C Hamano wrote:
> Scott McPeak writes:
>
> > I suggest that this problem could easily have been avoided if "git
> > stash" refused to run with a pending merge (present MERGE_HEAD file),
> > since this is crucial repository state that it does not sav
uot; or "git
checkout" (all of which can call git-add--interactive). If a user want
to override the value on the command line they can use:
git -c diff.algorithm=$ALGO ...
Signed-off-by: John Keeping
---
On Mon, Jun 10, 2013 at 05:56:56PM -0400, Jeff King wrote:
> On
On Wed, Jun 12, 2013 at 04:56:27PM +0530, Ramkumar Ramachandra wrote:
> John Keeping wrote:
> >> Either way, I'm not interested in problems that have no solutions.
> >> The only "solution" I see here is to suffocate every contributor until
> >> they a
On Wed, Jun 12, 2013 at 02:41:25PM +0200, Matthieu Moy wrote:
> Mathieu Liénard--Mayor writes:
>
> > $ git status
> > # HEAD detached from ecb9f3e
> > # You are currently editing a832578... my_commit_message [3/5] while
> > rebasing.
>
> Showing the commit message here is too much IMHO. With a t
On Wed, Jun 12, 2013 at 12:16:28AM +0530, Ramkumar Ramachandra wrote:
> John Keeping wrote:
> > Ugh, why this roundabout-passive-past tone? Use imperative tone
> > like this:
> >
> > ...
> >
> > vs.
> >
> > We normally
On Tue, Jun 11, 2013 at 08:52:05PM +0200, Michael Haggerty wrote:
> That's a very good point (and a good illustration, too). How do you
> like the new second and third sentences below?
>
> * When reviewing other peoples' code, be tactful and constructive.
> Remember that submitting patches for pu
On Tue, Jun 11, 2013 at 10:00:56AM -0700, Junio C Hamano wrote:
> Michael Haggerty writes:
> > * When reviewing other peoples' code, be tactful and constructive. Set
> > high expectations, but do what you can to help the submitter achieve
> > them. Don't demand changes based only on your persona
On Tue, Jun 11, 2013 at 02:35:29PM +0200, Mathieu Liénard--Mayor wrote:
> (Got the idea from:
> https://git.wiki.kernel.org/index.php/SmallProjectsIdeas#git_rebase_--status)
>
> When in the middle of a rebase, users can be easily confused about
> what to do, or where they are in the rebase process
On Mon, Jun 10, 2013 at 05:11:41PM -0400, Jeff King wrote:
> On Mon, Jun 10, 2013 at 12:28:55PM -0700, Junio C Hamano wrote:
> > John Keeping writes:
> >
> > > I think the first thing to do is read the "diff.algorithm" setting in
> > > git-add--inter
I've just been trying to use "add -p" to stage some changes which happen
to be textually entangled with other changes that I do not want to
stage.
It turns out that "git diff --patience" does a really good job
splitting this into exactly the hunks I want, but "add --interactive"
doesn't let me cha
On Mon, Jun 10, 2013 at 09:53:24AM +0300, Michael S. Tsirkin wrote:
> I vaguely remember there was some way to say
> "head of the remote I am tracking" - but I could not find it.
> Where are all the tricks like foo^{} documented?
gitrevisions(7) is what you're looking for here.
In this case I thi
On Sun, Jun 09, 2013 at 12:53:38PM -0500, Felipe Contreras wrote:
> On Sun, Jun 9, 2013 at 12:37 PM, John Keeping wrote:
> > On Sun, Jun 09, 2013 at 07:33:42PM +0200, SZEDER Gábor wrote:
> >> On Sun, Jun 09, 2013 at 12:23:01PM -0500, Felipe Contreras wrote:
> >> > O
On Sun, Jun 09, 2013 at 07:33:42PM +0200, SZEDER Gábor wrote:
> On Sun, Jun 09, 2013 at 12:23:01PM -0500, Felipe Contreras wrote:
> > On Sun, Jun 9, 2013 at 12:18 PM, SZEDER Gábor wrote:
> > > On Sun, Jun 09, 2013 at 11:40:22AM -0500, Felipe Contreras wrote:
> > >> We should free objects before le
On Sun, Jun 09, 2013 at 12:13:41PM -0500, Felipe Contreras wrote:
> On Sun, Jun 9, 2013 at 12:03 PM, Ramkumar Ramachandra
> wrote:
> > John Keeping wrote:
> >> Calling across from one builtin/*.c file to another is just as wrong as
> >> calling into a builtin/*.c
On Sun, Jun 09, 2013 at 11:22:06AM -0500, Felipe Contreras wrote:
> On Sun, Jun 9, 2013 at 11:02 AM, John Keeping wrote:
> > But we make a distinction between things that are specific to one
> > command (especially argument parsing and user interaction) and more
> > gene
On Sun, Jun 09, 2013 at 10:40:32AM -0500, Felipe Contreras wrote:
> On Sun, Jun 9, 2013 at 10:12 AM, John Keeping wrote:
> > On Sun, Jun 09, 2013 at 08:26:32PM +0530, Ramkumar Ramachandra wrote:
> >> Felipe Contreras wrote:
> >> > The plan is simple; make libgit.a
On Sun, Jun 09, 2013 at 08:26:32PM +0530, Ramkumar Ramachandra wrote:
> Felipe Contreras wrote:
> > The plan is simple; make libgit.a a proper library, starting by
> > clarifying what goes into libgit.a, and what doesn't. If there's any
> > hopes of ever having a public library, it's clear what cod
On Tue, Jun 04, 2013 at 06:57:34PM -0400, Phil Hord wrote:
> On Tue, Jun 4, 2013 at 8:48 AM, John Keeping wrote:
> > The problem is that sometimes you do want to adjust the path and
> > sometimes you don't. Reading git-submodule(1), it says:
> >
> > This m
On Tue, Jun 04, 2013 at 11:39:25PM +0200, Jens Lehmann wrote:
> Am 04.06.2013 14:48, schrieb John Keeping:
> > The problem is that sometimes you do want to adjust the path and
> > sometimes you don't. Reading git-submodule(1), it says:
> >
> > This may be e
On Tue, Jun 04, 2013 at 09:17:17PM +1000, Heiko Voigt wrote:
> On Tue, Jun 04, 2013 at 09:10:45AM +0100, John Keeping wrote:
> > On Tue, Jun 04, 2013 at 03:29:51PM +1000, Heiko Voigt wrote:
> > > On Mon, Jun 03, 2013 at 11:23:41PM +0100, John Keeping wrote:
> > > > &g
On Tue, Jun 04, 2013 at 03:29:51PM +1000, Heiko Voigt wrote:
> On Mon, Jun 03, 2013 at 11:23:41PM +0100, John Keeping wrote:
> > > Sorry, I should have been more specific here. I saw that you did some
> > > changes to make "submodule add" do the right thing wit
On Mon, Jun 03, 2013 at 11:47:23PM +0200, Jens Lehmann wrote:
> Am 31.05.2013 21:40, schrieb John Keeping:
> > The current version does make '$sm_path' relative in "submodule
> > foreach", although it's hard to spot because we have to leave doing so
> &g
On Fri, May 31, 2013 at 08:40:51PM +0100, John Keeping wrote:
> On Thu, May 30, 2013 at 09:23:40PM +0200, Jens Lehmann wrote:
> > Am 30.05.2013 01:58, schrieb Junio C Hamano:
> > > * jk/submodule-subdirectory-ok (2013-04-24) 3 commits
> > > (merged to
On Fri, May 31, 2013 at 04:22:37PM -0400, Roland Schulz wrote:
> Hi,
>
> the gitignore rules work so that if a directory is ignored, all files
> in that directory are ignored. While that behavior isn't clearly
> documented in gitignore, this behavior is consistent across all git
> tools (status, l
On Thu, May 30, 2013 at 09:23:40PM +0200, Jens Lehmann wrote:
> Am 30.05.2013 01:58, schrieb Junio C Hamano:
> > * jk/submodule-subdirectory-ok (2013-04-24) 3 commits
> > (merged to 'next' on 2013-04-24 at 6306b29)
> > + submodule: fix quoting in relative_path()
> > (merged to 'next' on 2013-0
On Fri, May 31, 2013 at 09:49:57AM +0100, Alex Bennée wrote:
> On 31 May 2013 09:32, John Keeping wrote:
> > Thomas is suggesting that you might have a tag that does not point at a
> > commit but instead points to a blob object.
>
> It's looking like I just have some ve
On Fri, May 31, 2013 at 09:14:49AM +0100, Alex Bennée wrote:
> On 30 May 2013 20:30, John Keeping wrote:
> > On Thu, May 30, 2013 at 06:21:55PM +0200, Thomas Rast wrote:
> >> Alex Bennée writes:
> >>
> >> > On 30 May 2013 16:33, Thomas Rast wrote:
> &
On Thu, May 30, 2013 at 06:21:55PM +0200, Thomas Rast wrote:
> Alex Bennée writes:
>
> > On 30 May 2013 16:33, Thomas Rast wrote:
> >> Alex Bennée writes:
> >>
> >>> 41.58% git libcrypto.so.1.0.0 [.] sha1_block_data_order_ssse3
> >>> 33.62% git libz.so.1.2.3.4 [.] inflate_fast
> >>
On Thu, May 30, 2013 at 10:38:59PM +0530, Ramkumar Ramachandra wrote:
> Matthieu Moy wrote:
> > I find it a bit weird that Git sets the configuration for external
> > commands, but it may make sense. No strong opinion here.
>
> I don't mean a setenv() kind of thing: how would we unset it after
> t
s email address. It was
> working back in October, and his username still seems to be active over
> at SourceForge... let's see if this email reaches him.
>
> Here's a link for his reference just in case he missed your original email:
> http://thread.gmane.org/gmane.comp.vers
On Thu, May 30, 2013 at 11:38:32AM +0100, Alex Bennée wrote:
> One factor might be the size of my repo (.git is around 2.4G). Could
> this just be due to computational cost of searching through large
> packs to walk the commit chain? Is there any way to make this easier
> for git to do?
What does
On Wed, May 29, 2013 at 11:48:53AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Wed, May 29, 2013 at 11:08:46AM -0700, Junio C Hamano wrote:
> >
> >> This has rather interesting ramifications on cherry-pick and rebase,
> >> though. Both command can handle changes that come from an o
On Tue, May 28, 2013 at 11:57:08AM -0700, Junio C Hamano wrote:
> John Keeping writes:
>
> > Yeah, the commit message is still quite focused on the end effect of
> > copying files back. But that's not what's being changed here.
> >
> > In my suggested
On Tue, May 28, 2013 at 11:06:13AM -0700, Junio C Hamano wrote:
> Kenichi Saita writes:
>
> > When deciding whether or not we should link a working tree file into
> > the temporary right-hand directory for a directory diff, we
> > currently behave differently in the --symlink and --no-symlink
> >
On Tue, May 28, 2013 at 01:40:20AM +0200, Jason A. Donenfeld wrote:
> My commit author name is "Jason A. Donenfeld". Because this has a dot,
> SMTP handling likes to put it in quotes.
>
> git-send-email has this line:
> if (defined $author and $author ne $sender) {
>
> With my name, t
occurs.
Fix this by setting the "missing_ok" flag when calling get_fetch_map.
Test-added-by: Jeff King
Signed-off-by: John Keeping
Acked-by: Jeff King
---
On Mon, May 27, 2013 at 12:19:34PM -0400, Jeff King wrote:
> On Mon, May 27, 2013 at 05:01:29PM +0100, John Keeping wrote:
>
&g
On Mon, May 27, 2013 at 11:42:52AM -0400, Jeff King wrote:
> On Mon, May 27, 2013 at 12:40:25PM +0100, John Keeping wrote:
>
> > Since commit f269048 (fetch: opportunistically update tracking refs,
> > 2013-05-11) we update tracking refs opportunistically when fetching
&
setting the "missing_ok" flag when calling get_fetch_map.
Signed-off-by: John Keeping
---
builtin/fetch.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/fetch.c b/builtin/fetch.c
index e41cc0d..d15a734 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
On Sun, May 26, 2013 at 08:21:45PM +0200, Gioele Barabucci wrote:
> Il 26/05/2013 20:14, John Keeping ha scritto:
> > On Sun, May 26, 2013 at 08:09:56PM +0200, Gioele Barabucci wrote:
> >> Il 26/05/2013 20:00, Andreas Schwab ha scritto:
> >>>> Simple, I keep all m
On Sun, May 26, 2013 at 08:09:56PM +0200, Gioele Barabucci wrote:
> Il 26/05/2013 20:00, Andreas Schwab ha scritto:
> >> Simple, I keep all my projects on the same server, so I would like to
> >> refer to that server + path using 'remote-repo'.
> >>
> >> "git+ssh://git.example.org//users/gioele/pro
On Mon, May 27, 2013 at 12:00:46AM +0900, Kenichi Saita wrote:
> After running the user's diff tool, "git difftool --dir-dif --no-symlink"
> currently copied back a temporary file to working tree only when a file
> contains unstaged changes in the working tree.
>
> Change this behavior so that tem
On Sat, May 25, 2013 at 05:20:29PM +0530, Ramkumar Ramachandra wrote:
> Antoine Pelisse wrote:
> > Is it not possible for "color" to be used uninitialized here ?
>
> My compiler didn't complain; what am I missing? Doesn't the
> declaration char color[COLOR_MAXLEN]; initialize an empty string?
Wh
On Fri, May 24, 2013 at 02:15:55PM -0700, Junio C Hamano wrote:
> * jk/submodule-subdirectory-ok (2013-04-24) 3 commits
> (merged to 'next' on 2013-04-24 at 6306b29)
> + submodule: fix quoting in relative_path()
> (merged to 'next' on 2013-04-22 at f211e25)
> + submodule: drop the top-level r
On Fri, May 24, 2013 at 03:42:37PM +, Jim Greenleaf wrote:
> John Keeping keeping.me.uk> writes:
>
> > I wonder if this would be better as a file rather than another option to
> > git-update-index. We already have .git/info/exclude so we could add
> > .git/inf
On Fri, May 24, 2013 at 03:34:26PM +, Jim Greenleaf wrote:
> Phil Hord gmail.com> writes:
>
> > The wording of --ignore-changes suffers the same lack of clarity that
> > --assume-unchanged does.
> > What's better? --sequester is probably too obscure. Maybe --hold.
> > Or --silence. Or --sh
On Fri, May 24, 2013 at 01:03:22PM +0200, Petr Baudis wrote:
> On Fri, May 24, 2013 at 11:40:18AM +0100, John Keeping wrote:
> > So that it continues to Just Work for people using buildroot but you can
> > create Makefile.config to override those defaults.
>
> Indeed, th
On Fri, May 24, 2013 at 12:14:16PM +0200, Petr Baudis wrote:
> On Fri, May 24, 2013 at 11:06:12AM +0100, John Keeping wrote:
> > I don't see anything wrong with having a template file documenting the
> > parameters, but I think it's important that there are sensible defau
On Fri, May 24, 2013 at 11:40:07AM +0200, Petr Baudis wrote:
> On Fri, May 24, 2013 at 09:22:53AM +0100, John Keeping wrote:
> > On Fri, May 24, 2013 at 01:57:12AM +0200, Petr Baudis wrote:
> > > Just to clear up on what the best practice is, I'd imagine the setup
>
On Thu, May 23, 2013 at 06:53:36PM -0500, Felipe Contreras wrote:
> The alternatives are these:
>
> a) you annoy the vast majority of the user-base by making 'git pull' a
> dangerous operation that should be avoided, and replaced with 'git
> fetch'+'git rebase'.
>
> b) you annoy a minority of the
On Fri, May 24, 2013 at 01:57:12AM +0200, Petr Baudis wrote:
> Just to clear up on what the best practice is, I'd imagine the setup
> to be something like:
>
> (a) Makefile contains inclusion of Makefile.include.
>
> (b) There is a file like Makefile.include.template containing
>
On Thu, May 23, 2013 at 02:01:39PM -0700, Junio C Hamano wrote:
> John Keeping writes:
>
> > I have to wonder how often "git pull" with no arguments actually does
> > what users really want (even if they don't know it!) when it doesn't
> > res
On Thu, May 23, 2013 at 09:01:15AM -0700, Junio C Hamano wrote:
> John Keeping writes:
>
> > I've been annoyed by this at $DAYJOB recently. A lot of people seem to
> > blindly "git pull" without much thought about how the history is ending
> > up and what
On Thu, May 23, 2013 at 12:29:59PM +0200, Andreas Krey wrote:
> On Thu, 23 May 2013 05:48:38 +, John Szakmeister wrote:
> ...
> > This is a feature of `git pull` that I really despise. I really wish
> > `git pull` treated the remote as the first parent in its merge
> > operation.
>
> I'd actu
I'm guessing Kirill meant to send this to the list and not just to me.
It looks to me like the segfault is in MSys's mkdir.exe and not a Git
process.
- Forwarded message from Kirill Berezin -
From: Kirill Berezin
To: John Keeping
Date: Wed, 22 May 2013 09:54:47 +0400
On Tue, May 21, 2013 at 10:59:17AM +1000, Quilkey, Tony wrote:
> I am looking at formulating and then documenting our vcs workflow
> using Git at work. I have an idea of how I want things to work, but am
> a little hazy on some of the details.
>
> Our basic workflow will be based around:
> http://
On Mon, May 20, 2013 at 03:36:58PM -0700, Junio C Hamano wrote:
> Dmitry Marakasov writes:
>
> > Use /bin/sh interpreter instead of /bin/bash for contrib/git-subtree:
> > it's required for systems which don't use bash by default (for example,
> > FreeBSD), while there seem to be no bashisms in th
On Mon, May 20, 2013 at 09:32:21AM +0400, Kirill Berezin wrote:
> When you trying to add submodule, that already has submodule, it craches.
> For example you could try: git clone --recursive
> http://github.com/Exsul/al_server
Which version of Git were you using? I was not able to reproduce this
On Sun, May 19, 2013 at 11:36:23PM -0700, Jonathan Nieder wrote:
> I don't know what it should mean to try to use --cherry without
> --no-merges or --first-parent, so I guess this is harmless.
Currently --no-merges doesn't actually get passed down this far. We do
the patch ID calculations without
On Sun, May 19, 2013 at 12:36:12PM -0700, Jonathan Nieder wrote:
> John Keeping wrote:
>
> > In this case, it is likely that only a small number of paths are touched
> > by the commits on the smaller side of the range and by storing these we
> > can ignore many commits
g --cherry next...pu >/dev/null
real0m0.661s
user0m0.617s
sys 0m0.044s
After:
$ time git log --cherry next...pu >/dev/null
real0m0.509s
user0m0.478s
sys 0m0.030s
Signed-off-by: John Keeping
---
patch-ids.c | 142 +
On Mon, May 13, 2013 at 04:45:43PM +0200, Michael J Gruber wrote:
> Kevin Bracey venit, vidit, dixit 13.05.2013 16:26:
> > On 13/05/2013 01:22, Junio C Hamano wrote:
> >> Kevin Bracey writes:
> >>
> >>> git log --ancestry-path --left-right E...F --not $(git merge-base
> >>> --all E F)
> >>>
>
On Sat, May 18, 2013 at 08:43:57PM +0200, Peter Lauri wrote:
> But I just don't want to see that darn file. It is a config file that
> I have changed, and I don't want to need to stash it for each "git
> svn" action I want to perform... Any solution for that?
Read about --assume-unchanged in git-u
On Sat, May 18, 2013 at 08:36:42PM +0200, Peter Lauri wrote:
> Shouldn't this be valid? I would expect to NOT see the
> core/inc/config.inc.php in the "git status" output...
>
> Peters-MacBook-Air:dt-git plauri$ cat .gitignore
> .buildpath
> .project
> .settings/
> web/pjotr.php
> core/inc/config.
Signed-off-by: John Keeping
---
On Fri, May 17, 2013 at 11:10:40AM -0700, Junio C Hamano wrote:
> John Keeping writes:
>
> > Commit 02c5631 (difftool --dir-diff: symlink all files matching the
> > working tree, 2013-03-14) does not handle the case where a file that is
> >
Signed-off-by: John Keeping
---
This fixes a regression in 1.8.3-rc0.
git-difftool.perl | 9 -
t/t7800-difftool.sh | 7 +++
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/git-difftool.perl b/git-difftool.perl
index 6780292..0a1cb0a 100755
--- a/git-difftool.perl
On Fri, May 17, 2013 at 03:24:26PM +0100, Mike Crowe wrote:
> Only consider the first parent commit when walking the commit history. This
> is useful if you only wish to match tags on your branch after a merge.
For consistency with "git log" should this be called "--first-parent"?
In "git log" --
On Fri, May 17, 2013 at 11:10:03AM +0200, Michael Haggerty wrote:
> On 05/15/2013 08:03 PM, Eugene Sajine wrote:
> > My primary goal was to understand better what are the real problems
> > that we might have with the way we use git cvsimport, so I was not
> > asking about the guarantee of the cvsim
On Wed, May 15, 2013 at 08:42:39AM -0700, Junio C Hamano wrote:
> Matthieu Moy writes:
>
> > Many tutorials tell the users to set color.ui=auto as a very first step.
> > These tutorials would benefit from skiping this step and starting the
> > real Git manipualtions earlier. Other beginners do no
On Wed, May 15, 2013 at 11:34:41AM +0200, Matthieu Moy wrote:
> Antoine's answer is correct. In addition, I'd say that you may want to
> enable color in the output to make it clearer (the @@ ... @@ part would
> be colored, but not the function name):
>
> git config --global color.ui auto
I wond
On Mon, May 13, 2013 at 08:45:21AM -0700, Junio C Hamano wrote:
> John Keeping writes:
>
> > This has the advantage that you get the benefit of the cache if you run
> > "git log --cherry-mark" with the same paths more than once. In my
> > testing the cache is
On Mon, May 13, 2013 at 07:46:09AM -0700, Junio C Hamano wrote:
> John Keeping writes:
>
> > On Mon, May 13, 2013 at 06:53:29AM -0700, Junio C Hamano wrote:
> >> John Keeping writes:
> >>
> >> > The caching layer could also introduce false positives
On Mon, May 13, 2013 at 06:53:29AM -0700, Junio C Hamano wrote:
> John Keeping writes:
>
> > The caching layer could also introduce false positives though, which is
> > more serious. If you cache patch IDs with a pathspec restriction ...
>
> What? What business
On Sun, May 12, 2013 at 03:19:49PM -0700, Junio C Hamano wrote:
> John Keeping writes:
>
> >> But it is not a big problem. Either 3-way merge notices that there
> >> is nothing new, or you get a conflict and have chance to inspect
> >> what is going on.
>
On Sun, May 12, 2013 at 10:02:39PM -0700, Junio C Hamano wrote:
> Kevin Bracey writes:
>
> > On 12/05/2013 19:58, John Keeping wrote:
> >>
> >> With the patch below, the --ancestry-path version drops to under 2
> >> seconds.
> >>
> >> I&#
On Sun, May 12, 2013 at 05:28:24PM +0100, John Keeping wrote:
> However, this doesn't seem to make a difference to the time taken when I
> add in --cherry-mark (which is why I was partially correct in the
> parallel thread - it doesn't have the effect on cherry-mark
On Sun, May 12, 2013 at 05:28:24PM +0100, John Keeping wrote:
> On Sun, May 12, 2013 at 06:44:30PM +0300, Kevin Bracey wrote:
> > On 11/05/2013 15:23, John Keeping wrote:
> > > This is helpful when examining branches with disjoint roots, for example
> > > because one is
On Sun, May 12, 2013 at 06:44:30PM +0300, Kevin Bracey wrote:
> On 11/05/2013 15:23, John Keeping wrote:
> > This is helpful when examining branches with disjoint roots, for example
> > because one is periodically merged into a subtree of the other.
> >
> >
> >
&g
On Sun, May 12, 2013 at 12:41:31PM +0100, John Keeping wrote:
> diff --git a/t/t6007-rev-list-cherry-pick-file.sh
> b/t/t6007-rev-list-cherry-pick-file.sh
> index 28d4f6b..378cf3e 100755
> --- a/t/t6007-rev-list-cherry-pick-file.sh
> +++ b/t/t6007-rev-list-cherry-pick-file.sh
>
now the bottleneck).
Signed-off-by: John Keeping
---
On Sun, May 12, 2013 at 10:08:51AM +0100, John Keeping wrote:
> On Sat, May 11, 2013 at 06:57:02PM -0500, Johannes Schindelin wrote:
> > On Sat, 11 May 2013, Linus Torvalds wrote:
> >
> > > [...] I really think ca
On Sat, May 11, 2013 at 06:57:02PM -0500, Johannes Schindelin wrote:
> On Sat, 11 May 2013, Linus Torvalds wrote:
>
> > [...] I really think caching patch ID's should be something people
> > should be aware of is fundamentally wrong, even if it might work.
>
> Given the incredible performance win
On Sat, May 11, 2013 at 08:00:44PM -0700, Junio C Hamano wrote:
> Linus Torvalds writes:
>
> > On Sat, May 11, 2013 at 2:49 PM, John Keeping wrote:
> >>
> >> Hmm... I hadn't realised that. Looking a bit closer, it looks like
> >> init_patch_ids set
On Sat, May 11, 2013 at 02:10:01PM -0700, Linus Torvalds wrote:
> On Sat, May 11, 2013 at 12:54 PM, John Keeping wrote:
> > This adds a new configuration variable "patchid.cacheRef" which controls
> > whether (and where) patch IDs will be cached in a notes tree.
>
&g
log --cherry \
master...git-gui/master >/dev/null
real0m33.860s
user0m32.832s
sys 0m0.986s
With all patch IDs cached:
$ time git -c patchid.cacheref=patchids log --cherry \
master...git-gui/master >/dev/null
real0m1.041s
user0m0.679s
sys 0m0.363s
Signed-o
On Sat, May 11, 2013 at 10:54:12AM -0700, Junio C Hamano wrote:
> John Keeping writes:
>
> > This is helpful when examining branches with disjoint roots, for example
> > because one is periodically merged into a subtree of the other.
> >
> > With the --merge-child
On Sat, May 11, 2013 at 04:29:36PM +0400, Andrey Borzenkov wrote:
> I noticed that using git-remote-bzr, but as far as I can tell this is
> generic for all transport helpers using fast-export.
>
>
>
> What happened was "git push" failed due to merge conflict. So far so
> good - but from now on g
>/dev/null
real0m2.296s
user0m2.193s
sys 0m0.092s
Signed-off-by: John Keeping
---
Documentation/git-merge-base.txt | 6
builtin/merge-base.c | 61 ++--
t/t6010-merge-base.sh| 25 +++
This is the same as the in_commit_list function already in builtin/tag.c
so we also replace that by the new commit_list_contains function.
Signed-off-by: John Keeping
---
builtin/tag.c | 10 +-
commit.c | 8
commit.h | 1 +
3 files changed, 10 insertions(+), 9
27;m not convinced that '--merge-child' is the right name for this but I
think the functionality itself is useful.
John Keeping (2):
commit: add commit_list_contains function
merge-base: add --merge-child option
Documentation/git-merge-base.
I use my own integration branch manager[1] to manage my WIP changes to
various projects, including git.git and one of the features of this is a
--status option that shows whether anything that I'm tracking has been
merged to the base branch I'm building on top of. Since the commit IDs
will be diff
On Thu, May 09, 2013 at 09:10:51AM -0700, Junio C Hamano wrote:
> David Aguilar writes:
>
> > Marked "RFC" because I am kinda against adding more configuration
> > variables.
>
> Just like "git merge" has -X escape hatch to allow us to
> pass backend-specific options, perhaps you can add a mecha
On Thu, May 09, 2013 at 02:13:30AM -0700, David Aguilar wrote:
> Mac OS X Mountain Lion prints warnings when building git:
>
> warning: 'SHA1_Init' is deprecated
> (declared at /usr/include/openssl/sha.h:121)
>
> Silence the warnings by disabling OpenSSH in favor of BLK_SHA1.
>
> Sig
401 - 500 of 893 matches
Mail list logo
