Célestin Matte writes:
> Subject: [PATCH 01/18] Follow perlcritic's recommendations - level 5 and 4
It would be better to prefix commit messages with "git-remote-mediawiki: ".
> Fix warnings from perlcritic's level 5 and 4.
It would be cool to have a "make perlcritic" target in the Makefile so
Célestin Matte writes:
> Subject: [PATCH 08/18] Explicitely assign local variable as undef and make a
> proper one-instruction-by- line indentation
Try to keep short subject lines. We usually consider that 80 character
is a strict maximum, and to have e.g. "git log --oneline"'s output fit
on 80
Célestin Matte writes:
> use URI::Escape;
> -use IPC::Open2;
> use Readonly;
This should have belonged to bp/mediawiki-credential, but it's already
in next so it's OK to fix it here.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe
Hi all,
Problem (scenario):
1. A file `file.xyz` has been added and commited
2. Some time after, let's say `*.xyz` is added to `.gitignore`
(probably by another contributor)
Nobody notices that `file.xyz` is already tracked by git because
the file is not modified.
3. Another person accidental
On Thu, Jun 6, 2013 at 8:34 AM, Johannes Sixt wrote:
> From: Johannes Sixt
>
> The test case depends on that test-sigchain can commit suicide by a call
> to raise(SIGTERM) in a way that run-command.c::wait_or_whine() can detect
> as death through a signal. There are no POSIX signals on Windows, a
On Fri, Jun 7, 2013 at 12:01 PM, Erik Faye-Lund wrote:
> On Thu, Jun 6, 2013 at 8:34 AM, Johannes Sixt wrote:
>> From: Johannes Sixt
>>
>> The test case depends on that test-sigchain can commit suicide by a call
>> to raise(SIGTERM) in a way that run-command.c::wait_or_whine() can detect
>> as d
On Thu, Jun 6, 2013 at 7:40 PM, Jeff King wrote:
> On Thu, Jun 06, 2013 at 10:21:47AM -0700, Junio C Hamano wrote:
>
>> > The particular deficiency is that when a signal is raise()d whose SIG_DFL
>> > action will cause process death (SIGTERM in this case), the
>> > implementation of raise() just c
Am 6/7/2013 12:12, schrieb Erik Faye-Lund:
> On Thu, Jun 6, 2013 at 7:40 PM, Jeff King wrote:
>> On Thu, Jun 06, 2013 at 10:21:47AM -0700, Junio C Hamano wrote:
>>
The particular deficiency is that when a signal is raise()d whose SIG_DFL
action will cause process death (SIGTERM in this c
Célestin Matte:
- Use {}{} instead of /// when slashes or used inside the regexp so as not to
escape it.
I guess that should read "...when slashes *are* used inside..."?
--
\\// Peter - http://www.softwolves.pp.se/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body
Currently, the paragraph corresponding to the --tags option in
git-fetch(1) looks like:
-t, --tags
This is a short-hand for giving "refs/tags/:refs/tags/" refspec
^^^
this is in bold
On Fri, Jun 7, 2013 at 12:24 PM, Johannes Sixt wrote:
> Am 6/7/2013 12:12, schrieb Erik Faye-Lund:
>> On Thu, Jun 6, 2013 at 7:40 PM, Jeff King wrote:
>>> On Thu, Jun 06, 2013 at 10:21:47AM -0700, Junio C Hamano wrote:
>>>
> The particular deficiency is that when a signal is raise()d whose SI
Le 07/06/2013 10:10, Matthieu Moy a écrit :
> It would be cool to have a "make perlcritic" target in the Makefile so
> that future developers can easily re-run it and avoid repeating the same
> mistakes. As much as possible, "make perlcritic" should produce no
> output at the end of your patch seri
Am 6/7/2013 14:00, schrieb Erik Faye-Lund:
> On Fri, Jun 7, 2013 at 12:24 PM, Johannes Sixt wrote:
>> Am 6/7/2013 12:12, schrieb Erik Faye-Lund:
>>> On Thu, Jun 6, 2013 at 7:40 PM, Jeff King wrote:
On Thu, Jun 06, 2013 at 10:21:47AM -0700, Junio C Hamano wrote:
>> The particular def
Hi, I tried to use the new Git feature to push by default to a different
remote you normally pull but I had some problems. I asked in the #git
IRC channel and been told it looks like a bug and to report it here.
I have 2 remotes, origin and upstream. origin is my private fork (and I
can push to it
On Fri, Jun 7, 2013 at 2:19 PM, Johannes Sixt wrote:
> Am 6/7/2013 14:00, schrieb Erik Faye-Lund:
>> On Fri, Jun 7, 2013 at 12:24 PM, Johannes Sixt wrote:
>>> Am 6/7/2013 12:12, schrieb Erik Faye-Lund:
On Thu, Jun 6, 2013 at 7:40 PM, Jeff King wrote:
> On Thu, Jun 06, 2013 at 10:21:47AM
On Thursday, June 06, 2013 at 23:16 EDT,
Robert Martin wrote:
> I want to work on a visualization program for git. I was hoping there
> was a library that would allow me to monitor a git repo for changes.
> Consider it like inotify, but for a git repository (in fact, I think
> it would proba
Am 6/7/2013 14:46, schrieb Erik Faye-Lund:
> On Fri, Jun 7, 2013 at 2:19 PM, Johannes Sixt wrote:
>> Am 6/7/2013 14:00, schrieb Erik Faye-Lund:
>>> On Fri, Jun 7, 2013 at 12:24 PM, Johannes Sixt wrote:
Am 6/7/2013 12:12, schrieb Erik Faye-Lund:
> diff --git a/compat/mingw.c b/compat/ming
[+CC: jc, jk]
Leandro Lucarella wrote:
> I changed branch.master.remote to upstream and set
> branch.master.pushremote to origin, but when I do I git push I get an
> error:
>
> $ git push --dry-run --verbose
> fatal: You are pushing to remote 'origin', which is not the upstream of
> your current b
On Fri, Jun 7, 2013 at 3:07 PM, Johannes Sixt wrote:
> Am 6/7/2013 14:46, schrieb Erik Faye-Lund:
>> On Fri, Jun 7, 2013 at 2:19 PM, Johannes Sixt wrote:
>>> Am 6/7/2013 14:00, schrieb Erik Faye-Lund:
On Fri, Jun 7, 2013 at 12:24 PM, Johannes Sixt
wrote:
> Am 6/7/2013 12:12, schri
David Lang wrote:
> Well, Felipe is saying that Perl is dieing and we should re-write everything
> that exists in Perl to Ruby.
I don't agree with that opinion. More generally, I think the entire
discussion on what _should_ or _should not_ be done is rubbish. What
_will_ and _will not_ happen de
Pat Thoyts writes:
> The following changes since commit b5c26758639cd934780620d4dd16854c8fdf8c34:
>
> Sync with maint (2013-06-03 13:00:09 -0700)
>
> are available in the git repository at:
>
>
> http://github.com/msysgit/git tags/post183-for-junio
>
> for you to fetch changes up to 65db04437
Ramkumar Ramachandra writes:
> Currently, the paragraph corresponding to the --tags option in
> git-fetch(1) looks like:
>
> -t, --tags
> This is a short-hand for giving "refs/tags/:refs/tags/" refspec
> ^^^
>
Junio C Hamano writes:
> Ramkumar Ramachandra writes:
>
>> Currently, the paragraph corresponding to the --tags option in
>> git-fetch(1) looks like:
>>
>> -t, --tags
>> This is a short-hand for giving "refs/tags/:refs/tags/" refspec
>> ^^
Junio C Hamano wrote:
> How about this?
Looks good, 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
Ramkumar Ramachandra writes:
> I think Felipe is using the argument that perl is declining to answer
> the question "why didn't you write git-related in perl instead?";
> that's it.
A question which nobody asked, I presume?
I think we heard enough from packaging folks that a new dependency
is u
Johannes Schindelin wrote:
> On Fri, 7 Jun 2013, Ramkumar Ramachandra wrote:
>> Johannes Schindelin wrote:
>> > My initial reaction, too. It was hard enough to get Perl included with Git
>> > for Windows (because of that pesky Subversion dependency).
>>
>> Nevertheless, we had to do it, and we did
Junio C Hamano wrote:
> So at least for now, the conclusion is to take approach #1, i.e.
> somebody who finds "related" a good addition rewrites it in Perl to
> promote it out of contrib/ once the design issues settle (of course
> it is still a possibility that no such volunteer appears).
We'll th
Ramkumar Ramachandra wrote:
> Add support for completing 'git rev-parse'. List only the options that
> are likely to be used on the command-line, as opposed to scripts.
Can we get this patch? I use git rev-list quite a lot, and want completion.
--
To unsubscribe from this list: send the line "un
Ramkumar Ramachandra writes:
> [+CC: jc, jk]
>
> Leandro Lucarella wrote:
>> I changed branch.master.remote to upstream and set
>> branch.master.pushremote to origin, but when I do I git push I get an
>> error:
>>
>> $ git push --dry-run --verbose
>> fatal: You are pushing to remote 'origin', whi
Forgot to cc; sorry about that.
Junio C Hamano writes:
> SZEDER Gábor writes:
>
>> On Thu, Jun 06, 2013 at 03:41:08PM -0700, Junio C Hamano wrote:
>>> * rr/complete-difftool (2013-06-03) 2 commits
>>> (merged to 'next' on 2013-06-04 at 01c7611)
>>> + completion: clarify ls-tree, archive, sho
On Thu, Jun 6, 2013 at 6:17 PM, Junio C Hamano wrote:
> Célestin Matte writes:
>
> But for a two-endpoint diff Porcelain (not the plumbing diff-files,
> diff-index and diff-tree), I do not think it is particularly a bad
> idea to add such a "typo-detection" feature.
I was wondering if this feat
On Fri, Jun 07, 2013 at 08:47:59AM -0700, Junio C Hamano wrote:
> When branch.$name.push mechanism is introduced and the user uses it,
> then "upstream", "simple", or any other setting for that matter
> would be ignored. With
>
> [branch "master"]
> remote = upstream
>
Matthieu Moy writes:
> * Ask the user to build external programs with
>
> make GIT_ROOT=where/git/lives/
>
> * or, ask users to checkout the external program as a subdirectory of
> git.git to build it (for example, clang's build installation ask you
> to put clang as a subdirectory of LLVM'
Martin von Zweigbergk writes:
> Changes since v5:
>
> * Improved test_linear_range
> * Changed TODOs to be about consistency, not --topo-order
Thanks, looked sensible.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More m
Junio C Hamano wrote:
> This shows the "triangular" support in 1.8.3 is only half-finished;
> the other half was discussed a few weeks ago ($gmane/224604)
I intentionally omitted that detail, because it is not directly
related to this bug. We have to fix the existing simple and upstream,
whether
Leandro Lucarella wrote:
> Thanks for the detailed explanations, I think this would cover my use
> case. Just for clarification, here are some more details on this use
> case, which I think is becoming very popular among github users.
> We have a "blessed" repository (upstream in my case) and only
Le 07/06/2013 06:12, Eric Sunshine a écrit :
> On Thu, Jun 6, 2013 at 3:34 PM, Célestin Matte
> wrote:
>> Signed-off-by: Célestin Matte
>> Signed-off-by: Matthieu Moy
>> ---
>> contrib/mw-to-git/git-remote-mediawiki.perl |8
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>>
On 6 June 2013 23:33, Fredrik Gustafsson wrote:
> On Thu, Jun 06, 2013 at 06:35:43PM -0700, Constantine A. Murenin wrote:
>> I'm interested in running a web interface to this and other similar
>> git repositories (FreeBSD and NetBSD git repositories are even much,
>> much bigger).
>>
>> Software-w
On Fri, Jun 07, 2013 at 10:27:58PM +0530, Ramkumar Ramachandra wrote:
> Leandro Lucarella wrote:
> > Thanks for the detailed explanations, I think this would cover my use
> > case. Just for clarification, here are some more details on this use
> > case, which I think is becoming very popular among
SZEDER Gábor wrote:
> Well, people out there might have completion scriplets for their
> aliases or custom git commands which use __git_complete_file().
> Removing this function would break those scripts.
What is the advantage of using __git_complete_file() over
__git_complete_revlist_file()? Isn
SZEDER Gábor wrote:
> the one at the top because
> of the reasons given in $gmane/226272
Sorry about the delay: I went to sleep for a couple of days :P
> the one at the bottom because
> of the misleading commit message (__git_complete_file() always
> completed refs first as part of the ref:file n
Leandro Lucarella wrote:
> I might try to just switch to current, I feel more comfortable with
> simple because I feel is safer to explicitly set the upstream branch,
> but is true that most of the time is not necessary.
Be more experimental! Use the lesser-known features, and tell us
about break
Célestin Matte writes:
> The problem is that I took some policies into account for some parts of
> the code, but not for all of it. For instance, in commit [15/18], I put
> some numeric values in constants, but not all of them, as I think having
> "arg[3]" in the code does make sense. Ignoring th
On Fri, Jun 07, 2013 at 10:05:37AM -0700, Constantine A. Murenin wrote:
> On 6 June 2013 23:33, Fredrik Gustafsson wrote:
> > On Thu, Jun 06, 2013 at 06:35:43PM -0700, Constantine A. Murenin wrote:
> >> I'm interested in running a web interface to this and other similar
> >> git repositories (Free
Ramkumar Ramachandra writes:
> Johannes Schindelin wrote:
>> On Fri, 7 Jun 2013, Ramkumar Ramachandra wrote:
>>> Johannes Schindelin wrote:
>>> > My initial reaction, too. It was hard enough to get Perl included with Git
>>> > for Windows (because of that pesky Subversion dependency).
>>>
>>> Nev
Matthieu Moy wrote:
> Reading Git for Windows's FAQ
> ( https://github.com/msysgit/msysgit/wiki/Frequently-Asked-Questions ),
> it seems rather clear that the TODO-list is already long to have a
> correct Perl support (I'm quite admirative of the work done already).
> The POSIX guys shouldn't move
Matthieu Moy wrote:
> I think it should be "the Git for Windows community", and my feeling is
> that the community developing Git for POSIX systems is far more active
> than the one making it work for Windows (although we may now have more
> windows users than unix users).
If I can be excused for
Matthieu Moy writes:
> The POSIX guys shouldn't move faster than the Windows guys can follow.
That is a very good summary.
It does not mean everybody must always crawl at the same pace as the
slowest people. But it is one of the important things we should
consider, when we have choices to make
Ramkumar Ramachandra writes:
> I think he way forward on Windows is an implementation like libgit2 or
> git# with some sort of gui/ide integration. I never understood why
> users on Windows want to use something as POSIX'y as git.git.
Whether it's based on POSIX is an implementation detail for
Ramkumar Ramachandra wrote:
> I think he way forward on Windows is
Why is there only one way forward? Why do you get to pick it, given
that you've said you're not interested in working on it?
[...]
> I never understood why
> users on Windows want to
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> This shows the "triangular" support in 1.8.3 is only half-finished;
>> the other half was discussed a few weeks ago ($gmane/224604)
>
> I intentionally omitted that detail, because it is not directly
> related to this bug. We have to fix th
Ramkumar Ramachandra writes:
> SZEDER Gábor wrote:
>> Well, people out there might have completion scriplets for their
>> aliases or custom git commands which use __git_complete_file().
>> Removing this function would break those scripts.
>
> What is the advantage of using __git_complete_file() o
Ramkumar Ramachandra writes:
> SZEDER Gábor wrote:
>> the one at the top because
>> of the reasons given in $gmane/226272
>
> Sorry about the delay: I went to sleep for a couple of days :P
>
>> the one at the bottom because
>> of the misleading commit message (__git_complete_file() always
>> comp
On Fri, Jun 07, 2013 at 10:51:53PM +0530, Ramkumar Ramachandra wrote:
> SZEDER Gábor wrote:
> > Well, people out there might have completion scriplets for their
> > aliases or custom git commands which use __git_complete_file().
> > Removing this function would break those scripts.
>
> What is the
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 save. This
> seems similar to what "git cherry-pick" does.
Sounds senslbe.
Matthieu Moy wrote:
> Visual Studio now has official Git support from MS (based on libgit2 if
> I understood correctly). That's cool, but not a reason to kill msysgit
> IMHO ;-).
Oh, I'm not interested in killing anything. If people want msysgit,
they will work on it: I'm nobody to say otherwise.
Jonathan Nieder wrote:
Ramkumar Ramachandra wrote:
I think he way forward on Windows is
Why is there only one way forward? Why do you get to pick it, given
that you've said you're not interested in working on it?
[...]
I never understood why
use
On Fri, Jun 07, 2013 at 11:00:14PM +0530, Ramkumar Ramachandra wrote:
> SZEDER Gábor wrote:
> > the one at the top because
> > of the reasons given in $gmane/226272
>
> Sorry about the delay: I went to sleep for a couple of days :P
>
> > the one at the bottom because
> > of the misleading commit
Ramkumar Ramachandra writes:
>> Whether it's based on POSIX is an implementation detail for the user.
>> The real question is more command-line Vs GUI than POSIX/Win32. Some
>> Linux users like GUI, some windows users use command-line. I tried IDE
>> integration with EGIT, and quite frankly I end
Junio C Hamano wrote:
> "git log -Gcomplete_file -p contrib/completion" found this one:
>
> Now I do not recall suggesting it, and you (and I today after 2
> years) may disagree with the rationale, but at least we can read
> what was the "intended" meaning, I think.
Having spent so much time docum
On 7 June 2013 10:57, Fredrik Gustafsson wrote:
> On Fri, Jun 07, 2013 at 10:05:37AM -0700, Constantine A. Murenin wrote:
>> On 6 June 2013 23:33, Fredrik Gustafsson wrote:
>> > On Thu, Jun 06, 2013 at 06:35:43PM -0700, Constantine A. Murenin wrote:
>> >> I'm interested in running a web interface
On Fri, Jun 7, 2013 at 10:20 AM, Junio C Hamano wrote:
> Ramkumar Ramachandra writes:
>
>> I think Felipe is using the argument that perl is declining to answer
>> the question "why didn't you write git-related in perl instead?";
>> that's it.
>
> A question which nobody asked, I presume?
>
> I t
On Fri, Jun 7, 2013 at 2:00 PM, Matthieu Moy
wrote:
> Ramkumar Ramachandra writes:
>
>>> Whether it's based on POSIX is an implementation detail for the user.
>>> The real question is more command-line Vs GUI than POSIX/Win32. Some
>>> Linux users like GUI, some windows users use command-line. I
77c130 (completion: clarify ls-tree, archive, show completion,
2013-06-02) removed __git_complete_file () because it had no callers
left in the file. However, to avoid breaking user scripts that may
depend on this, add it back as a deprecated alias.
Signed-off-by: Ramkumar Ramachandra
---
Based
On Thu, Jun 6, 2013 at 10:25 PM, Johannes Schindelin
wrote:
> On Fri, 7 Jun 2013, Ramkumar Ramachandra wrote:
>
>> Johannes Schindelin wrote:
>> > My initial reaction, too. It was hard enough to get Perl included with Git
>> > for Windows (because of that pesky Subversion dependency).
>>
>> Nevert
On Fri, Jun 07, 2013 at 11:41:07AM -0700, Junio C Hamano wrote:
> "git log -Gcomplete_file -p contrib/completion" found this one:
>
> commit 1d66ec587e7d903afdf12a81718772a9eadc15a1
> Author: SZEDER Gábor
> Date: Thu Mar 10 19:12:29 2011 +0100
>
> bash: complete 'git diff ...branc'
(snip)
On Thu, Jun 6, 2013 at 3:19 PM, David Lang wrote:
> On Fri, 7 Jun 2013, Ramkumar Ramachandra wrote:
>
>> David Lang wrote:
>>>
>>> Perl use may or may not be declining (depending on how you measure it),
>>> but
>>> are you really willing to take on the task of re-writing everything
>>> that's
>>>
On Fri, Jun 7, 2013 at 2:09 PM, Ramkumar Ramachandra wrote:
> 77c130 (completion: clarify ls-tree, archive, show completion,
> 2013-06-02) removed __git_complete_file () because it had no callers
> left in the file. However, to avoid breaking user scripts that may
> depend on this, add it back as
Felipe Contreras wrote:
>> Also we heard from no regular/high-value reviewers
>> that they feel comfortable reviewing additions in Ruby.
>
> Correction; *current* regular/high-value reviewers.
Correct. The opinions of inactive community members and
non-contributors are less useful.
> We could ch
On Thu, Jun 6, 2013 at 4:31 PM, Jonathan Nieder wrote:
> Ramkumar Ramachandra wrote:
>
>> Git is probably the _last_ thing
>> to be complaining about when it comes to packaging.
>
> It would be nice if contrib/ files supported the usual "make; make
> install; m
Felipe Contreras wrote:
> This is fine by me, but at some point we need to decide how we should
> prefix the functions that are supposed to be used by external scripts.
Yeah, I thought __ meant "internal" :/
> Also, maybe we should start adding '# TODO remove in v2.0' so we
> remember to do that
On Fri, Jun 7, 2013 at 2:29 PM, Ramkumar Ramachandra wrote:
> Felipe Contreras wrote:
>> This is fine by me, but at some point we need to decide how we should
>> prefix the functions that are supposed to be used by external scripts.
>
> Yeah, I thought __ meant "internal" :/
>
>> Also, maybe we sh
On Thu, Jun 06, 2013 at 06:05:44PM -0700, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
> > On Thu, Jun 06, 2013 at 03:41:08PM -0700, Junio C Hamano wrote:
> >> * rr/complete-difftool (2013-06-03) 2 commits
> >> (merged to 'next' on 2013-06-04 at 01c7611)
> >> + completion: clarify ls-tree, a
Am 07.06.2013 08:11, schrieb Martin von Zweigbergk:
> Changes since v5:
>
> * Improved test_linear_range
> * Changed TODOs to be about consistency, not --topo-order
>
> Martin von Zweigbergk (7):
> add simple tests of consistency across rebase types
> add tests for rebasing with patch-equiv
Felipe Contreras wrote:
> While at it, why not re-evaluate the whole msysgit approach? I bet we
> don't need a whole separate project just to create a Windows
> installer. I've written Windows installers before, it's very easy to
> do from Linux.
Yeah, taking the pain out of msysgit packaging woul
SZEDER Gábor writes:
>> Now I do not recall suggesting it, and you (and I today after 2
>> years) may disagree with the rationale, but at least we can read
>> what was the "intended" meaning, I think.
>
> See
>
> http://thread.gmane.org/gmane.comp.version-control.git/167728/focus=168838
>
> I s
Ramkumar Ramachandra wrote:
> commit a lot of good ruby code to contrib*
Oh, by the way: I have a project idea. There's this really popular
project called hub[1] that has an implementation of the GitHub API in
ruby. Unfortunately, it's a terrible piece of software because it
creates an extra lay
SZEDER Gábor wrote:
> because nowadays __git_complete_file() is a wrapper around
> __git_complete_revlist_file().
What? It was never anything different from a poorly-named alias for
__git_complete_revlist_file(). You have already agreed that
__git_complete_file() is a horrible name, so why not d
Felipe Contreras writes:
>> I think we heard enough from packaging folks that a new dependency
>> is unwelcome.
>
> What are you talking about? Which are these "packaging folks" we heard from?
Dscho is one of the primary people behind msysgit effort, and I
consulted with others from the circle w
On Sat, Jun 08, 2013 at 01:17:28AM +0530, Ramkumar Ramachandra wrote:
> SZEDER Gábor wrote:
> > because nowadays __git_complete_file() is a wrapper around
> > __git_complete_revlist_file().
>
> What? It was never anything different from a poorly-named alias for
> __git_complete_revlist_file().
A
On 06/07/2013 01:02 PM, Constantine A. Murenin wrote:
>> That's a one-time penalty. Why would that be a problem? And why is wget
>> even mentioned? Did we misunderstood eachother?
>
> `wget` or `curl --head` would be used to trigger the caching.
>
> I don't understand how it's a one-time penalty.
On 7 June 2013 13:13, Charles McGarvey wrote:
> On 06/07/2013 01:02 PM, Constantine A. Murenin wrote:
>>> That's a one-time penalty. Why would that be a problem? And why is wget
>>> even mentioned? Did we misunderstood eachother?
>>
>> `wget` or `curl --head` would be used to trigger the caching.
On Fri, Jun 7, 2013 at 2:55 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>>> I think we heard enough from packaging folks that a new dependency
>>> is unwelcome.
>>
>> What are you talking about? Which are these "packaging folks" we heard from?
>
> Dscho is one of the primary people beh
On Fri, Jun 7, 2013 at 1:04 PM, Célestin Matte
wrote:
> Le 07/06/2013 06:12, Eric Sunshine a écrit :
>> On Thu, Jun 6, 2013 at 3:34 PM, Célestin Matte
>> wrote:
>>> } elsif ($cmd[0] eq "import") {
>>> - die("Invalid arguments for import\n") unless
>>> ($cmd[
On Thu, Jun 6, 2013 at 2:21 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> On Thu, Jun 6, 2013 at 1:30 PM, Junio C Hamano wrote:
>>> Felipe Contreras writes:
>>>
Pretty much what it says on the tin.
>>>
>>> And a bit more, isn't it?
>>>
>>> The --keep-redundant-commits option im
Le 07/06/2013 22:25, Eric Sunshine a écrit :
> If you do choose to be more precise, it should be done as a separate
> patch. Each conceptually distinct change should have its own patch.
> Doing so makes changes easier to review and (generally) easier to
> cherry-pick. For example, in this particula
Felipe Contreras (3):
sequencer: trivial fix
test: improve rebase -q test
submodule: remove unnecessary check
sequencer.c | 7 +--
submodule.c | 5 ++---
t/t3400-rebase.sh | 1 +
3 files changed, 8 insertions(+), 5 deletions(-)
--
1.8.3.698.g079b096
--
To unsubscribe from
read_cache() already does that check.
Signed-off-by: Felipe Contreras
---
submodule.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/submodule.c b/submodule.c
index ad476ce..8685424 100644
--- a/submodule.c
+++ b/submodule.c
@@ -603,9 +603,8 @@ int fetch_populated_submo
We should free objects before leaving.
Signed-off-by: Felipe Contreras
---
sequencer.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/sequencer.c b/sequencer.c
index ab6f8a7..7eeae2f 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -626,12 +626,15 @@ static int do_pick_c
Let's show the output so it's clear why it failed.
Signed-off-by: Felipe Contreras
---
t/t3400-rebase.sh | 1 +
1 file changed, 1 insertion(+)
diff --git a/t/t3400-rebase.sh b/t/t3400-rebase.sh
index b58fa1a..fb39531 100755
--- a/t/t3400-rebase.sh
+++ b/t/t3400-rebase.sh
@@ -185,6 +185,7 @@ tes
Ramkumar Ramachandra writes:
> 77c130 (completion: clarify ls-tree, archive, show completion,
> 2013-06-02) removed __git_complete_file () because it had no callers
> left in the file. However, to avoid breaking user scripts that may
> depend on this, add it back as a deprecated alias.
>
> Signe
On Wed, Jun 5, 2013 at 9:17 PM, Junio C Hamano wrote:
> Charles McGarvey writes:
>
>> The bug is manifest when running gitweb in a persistent process (e.g.
>> FastCGI, PSGI), and it's easy to reproduce. If a gitweb request
>> includes the searchtext parameter (i.e. s), subsequent requests using
On Fri, Jun 07, 2013 at 12:46:25PM -0700, Junio C Hamano wrote:
> Thanks for a pointer. I think what I was suggesting was slightly
> different in that I was hoping to see a single helper that knows to
> complete to object names (possibly including trees/blobs with the
> treeish:path notation), ran
MinGW's bash does not recognize an exit code -1 as failure. See also
47e3de0e (MinGW: truncate exit()'s argument to lowest 8 bits) and 2488df84
(builtin run_command: do not exit with -1). Exit code 1 is good enough.
Signed-off-by: Johannes Sixt
---
test-chmtime.c | 8
1 file changed, 4
In particular:
- move test preparations inside test_expect_success
- place test description on the test_expect_success line
- indent with a tab
Signed-off-by: Johannes Sixt
---
t/t3010-ls-files-killed-modified.sh | 123 ++--
1 file changed, 61 insertions(+), 62
The test cases include many corner-cases of merge-recursive's behavior,
some of them involve type changes and symbolic links. All cases, including
those that are protected by SYMLINKS check only whether the result of
merge-recursive is correctly stored in the database and the index; the
file system
In t4023 and t4114, we have to remove the entries using 'git rm' because
otherwise the entries that must turn from symbolic links to regular files
would stay symbolic links in the index. For the same reason, we have to
use 'git mv' instead of plain 'mv' in t3509.
Signed-off-by: Johannes Sixt
---
Many tests that involve symbolic links actually check only whether our
algorithms are correct by investigating the contents of the object
database and the index. Only some of them check the filesystem.
This series introduces a function test_ln_s_add that inserts a symbolic
link in the index even i
Add a new function that creates a symbolic link and adds it to the index
to be used in cases where a symbolic link is not required on the file
system. We will use it to remove many SYMLINKS prerequisites from test
cases.
Signed-off-by: Johannes Sixt
---
t/README| 14 +
All tests in t6035 are protected by SYMLINKS. But that is not necessary,
because a lot of the functionality can be tested provided symbolic link
entries enter the index and object data base. Use test_ln_s_add for this
purpose.
Some test cases do test the presence of symbolic links on the file syst
1 - 100 of 173 matches
Mail list logo
