Hi Konstantin,
thanks for the reply.
The versions of git are:
- on remote: 1.5.6.5
- on windows build machine: 1.7.11.msysgit.1
- on mac build machine: 1.7.3.4
I will try to install latest git version on my remote server and get
back to you.
thanks again
Kevin
On 10/29/12 6:18 PM, Konstantin
Elia Pinto wrote:
> The shell word splitting done in base is a bashism, iow not portable.
No, ${varname##glob} is in POSIX and we already use it here and there.
See Documentation/CodingGuidelines:
- We use ${parameter#word} and its [#%] siblings, and their
doubled "longest matching" form
Any follow-up on this?
On Tue, Oct 23, 2012 at 7:11 AM, Scott Chacon wrote:
>
> So, this is due to the major AWS outage today. git-scm.com is hosted
> on Heroku and thus on AWS. Heroku is continuing to bring up their
> database systems in the wake of the massive AWS outage. Once that is
> back
Not seen any recently. I'm guessing the dev is in the path of
hurricane Sandy? (Not sarcasm, btw.)
On Tue, Oct 30, 2012 at 1:04 AM, Kevin wrote:
> Any follow-up on this?
>
> On Tue, Oct 23, 2012 at 7:11 AM, Scott Chacon wrote:
>>
>> So, this is due to the major AWS outage today. git-scm.com is
> From: Jeff King [mailto:p...@peff.net]
> Sent: Monday, October 29, 2012 8:07 AM
> To: Joachim Schmitz
> Cc: git@vger.kernel.org
> Subject: Re: [PATCH v2] fix 'make test' for HP NonStop
>
> On Thu, Oct 25, 2012 at 12:57:10PM +0200, Joachim Schmitz wrote:
>
> > diff --git a/Makefile b/Makefile
>
On Thu, Aug 30, 2012 at 3:34 PM, Orgad and Raizel Shaneh
wrote:
>
> On Thu, Aug 30, 2012 at 4:22 PM, Nguyen Thai Ngoc Duy
> wrote:
> > On Thu, Aug 30, 2012 at 8:12 PM, Orgad and Raizel Shaneh
> > wrote:
> >>> Could be path normalization. What does "git rev-parse --git-dir" say?
> >>> Try to run
patch.diff
Description: Binary data
'update-index --refresh' and 'diff-index' (without --cached) don't honor
the core.preloadindex setting yet. Porcelain commands using these (such as
git [svn] rebase) suffer from this, especially on Windows.
Use read_cache_preload to improve performance.
Additionally, in builtin/diff.c, don't prel
On Tue, Oct 30, 2012 at 10:50 AM, wrote:
> 'update-index --refresh' and 'diff-index' (without --cached) don't honor
> the core.preloadindex setting yet. Porcelain commands using these (such as
> git [svn] rebase) suffer from this, especially on Windows.
>
> Use read_cache_preload to improve perfo
Hi. I routinely work with projects in both hg and git, so I'm really
interested in this. Thanks for working on it! I grabbed the latest version
from
https://github.com/felipec/git/blob/fc-remote-hg/contrib/remote-hg/git-remote-hg
and have been trying it out. For the most part, it seems to work
Chris Webb writes:
> The first is really a symptom of a general difference between hg and git: an
> hg
> repository can have multiple heads, whereas a git repo has exactly one head.
By this I mean an hg repository without bookmarks or branches can still have
multiple heads, whereas a git branch
Hi,
(I am a French student, sorry for my English.)
So, i want import my perforce projet on my server git.
perforce my project tree :
depot
dev_data
mainline
release_1.0
release_1.0.0
my command is :
git-p4 clone -v --detect-branches //depot@all /home/user/projets/deport
The problem :
Am 30.10.2012 09:07, schrieb Mike Norman:
Not seen any recently. I'm guessing the dev is in the path of
hurricane Sandy? (Not sarcasm, btw.)
Do you still see failures? I checked out the website just now and it
seemed to work flawlessly (at least the links I tried, could not find
any Sharing o
Hi,
I'm using git-commit with the --template option. The template I'm
given is self sufficient for my purpose but as stated in the
documentation, git-commit wants the template to be edited otherwise it
aborts the operation.
Is it possible to change this ?
Thanks
--
Francis
--
To unsubscribe fro
On Tue, 30 Oct 2012 11:53:08 +0100, Francis Moreau
wrote:
> Hi,
>
> I'm using git-commit with the --template option. The template I'm
> given is self sufficient for my purpose but as stated in the
> documentation, git-commit wants the template to be edited otherwise it
> aborts the operation.
>
On Tue, Oct 30, 2012 at 10:21:40AM +0100, Joachim Schmitz wrote:
> This fixes the vast majority of test failures on HP NonStop.
> Some test don't work with /bin/diff, some fail with /bin/tar,
> so let's put /usr/local/bin in PATH first.
> Some tests fail with /bin/sh (link to /bin/ksh) so use bas
Am 10/30/2012 11:53, schrieb Francis Moreau:
> I'm using git-commit with the --template option. The template I'm
> given is self sufficient for my purpose but as stated in the
> documentation, git-commit wants the template to be edited otherwise it
> aborts the operation.
>
> Is it possible to cha
On Mon, Oct 29, 2012 at 06:47:05PM -0400, Jeff King wrote:
> On Mon, Oct 29, 2012 at 06:35:21PM -0400, Jeff King wrote:
>
> > The patch below fixes it, but it's terribly inefficient (it just detects
> > the situation and reallocates). It would be much better to disable the
> > reuse_worktree_file
(1) sounds attractive for more than one reason. In addition to avoidance of
this issue, it would bring bug-to-bug compatibility across platforms.
(4), if we can run grep on streaming data (tweak interface we have for checking
out a large blob to the working tree), would let us work on dataset la
On Tue, Oct 30, 2012 at 09:46:01PM +0900, Junio C Hamano wrote:
> (1) sounds attractive for more than one reason. In addition to
> avoidance of this issue, it would bring bug-to-bug compatibility
> across platforms.
Yeah. I mentioned breaking the build for people who would now need to
turn on NO_
Sorry for reacting so late, I didn't read the list carefully in the last weeks
and my gmail filter somehow didn't trigger on that.
On Tuesday 02 October 2012 16:20:22 Junio C Hamano wrote:
> * fa/remote-svn (2012-09-19) 16 commits
> - Add a test script for remote-svn
> - remote-svn: add marks-f
Hi,
On Tue, Oct 30, 2012 at 12:09 PM, Tomas Carnecky
wrote:
> On Tue, 30 Oct 2012 11:53:08 +0100, Francis Moreau
> wrote:
>> Hi,
>>
>> I'm using git-commit with the --template option. The template I'm
>> given is self sufficient for my purpose but as stated in the
>> documentation, git-commit w
I tried to install git 1.8 on the remote server and get exactly the same
problem :(.
Kevin
On 10/29/12 6:18 PM, Konstantin Khomoutov wrote:
On Mon, 29 Oct 2012 09:52:54 -0700 (PDT)
Kevin Molcard wrote:
I have a problem with my build system.
I have a remote server with a relatively large re
On Tue, Oct 30, 2012 at 11:25 AM, Chris Webb wrote:
> Hi. I routinely work with projects in both hg and git, so I'm really
> interested in this. Thanks for working on it! I grabbed the latest version
> from
>
>
> https://github.com/felipec/git/blob/fc-remote-hg/contrib/remote-hg/git-remote-hg
>
Hi,
On Mon, Oct 22, 2012 at 3:45 AM, Felipe Contreras
wrote:
> Here's a bit of reorganition. I'm introducing a new __gitcompadd helper that
> is
> useful to wrapp all changes to COMPREPLY, but first, lets get rid of
> unnecessary assignments as SZEDER suggested.
>
> The zsh wrapper is now very v
On Mon, Oct 29, 2012 at 4:35 PM, Jeff King wrote:
> On Mon, Oct 29, 2012 at 06:23:30PM +0100, Kacper Kornet wrote:
>
>> > That patch just blocks non-forced updates to refs/tags/. I think a saner
>> > start would be to disallow updating non-commit objects without a force.
>> > We already do so for
On Mon, Oct 29, 2012 at 11:06 PM, Jeff King wrote:
> On Mon, Oct 29, 2012 at 11:02:31PM +0100, Felipe Contreras wrote:
>
>> > If remote-hg is going to live in contrib, it probably makes sense to
>> > have its tests live there, too, like subtree.
>>
>> Probably, I'll check that option.
>>
>> But ev
Hi all,
On Mon, 29 Oct 2012, Jeff King wrote:
> On Mon, Oct 29, 2012 at 10:47:04PM +0100, Felipe Contreras wrote:
>
> > >> Yeah, the test script is not ready for merging, it needs to check
> > >> for python, hg, and hg-git.
> > >>
> > >> Do you have hg-git installed?
> > >
> > > No. But it's imp
Hi Chris,
On Tue, 30 Oct 2012, Chris Webb wrote:
> I routinely work with projects in both hg and git, so I'm really
> interested in this. Thanks for working on it! I grabbed the latest
> version from
>
>
> https://github.com/felipec/git/blob/fc-remote-hg/contrib/remote-hg/git-remote-hg
>
> a
Felipe Contreras writes:
> Yes, it seems this is an API issue; repo.branchtip doesn't exist in
> python 2.2.
Hi. Presumably this is a problem with old mercurial not a problem with old
python as mentioned in the commit?
> Both issues should be fixed now :)
They are indeed, and it now works nice
The --jobs parameter may be used to set the degree of per-submodule
parallel execution.
Signed-off-by: Stefan Zager
---
Documentation/git-submodule.txt |8 ++-
git-submodule.sh| 40 ++-
2 files changed, 46 insertions(+), 2 deletions(-
The --jobs parameter may be used to set the degree of per-submodule
parallel execution.
Signed-off-by: Stefan Zager
---
Documentation/git-submodule.txt |8 ++-
git-submodule.sh| 40 ++-
2 files changed, 46 insertions(+), 2 deletions(-
On Tue, Oct 30, 2012 at 6:20 PM, Johannes Schindelin
wrote:
> P.S.: I would still recommend to have a detailed look at the 'devel'
> branch, in particular the commits starting with "fast-export: do not refer
> to non-existing marks" and ending with "t5801: skip without hg". My
> understanding is
This is a refresh of a conversation from a couple of months ago.
I didn't try to implement all the desired features (e.g., smart logic
for passing a -j parameter to recursive submodule invocations), but I
did address the one issue that Junio insisted on: the code makes a
best effort to detect whet
On Tue, Oct 30, 2012 at 10:11 AM, Felipe Contreras
wrote:
> When an object has already been exported (and thus is in the marks) it
> is flagged as SHOWN, so it will not be exported again, even if this time
> it's exported through a different ref.
>
> We don't need the object to be exported again,
Chris Webb writes:
> A common idiom when working with hg bookmarks is to completely ignore the
> (not very useful) hg branches (i.e. all commits are on the default hg
> branch) and have a bookmark for each line of development used exactly as a
> git branch would be.
>
> On such a repository, at
Michael Haggerty wrote:
> Move the responsibility for normalizing prefixes from
> longest_ancestor_length() to its callers. Use slightly different
> normalizations at the two callers:
>
> In setup_git_directory_gently_1(), use the old normalization, which
> ignores paths that are not usable. In t
On Tue, Oct 30, 2012 at 7:00 PM, Chris Webb wrote:
> Felipe Contreras writes:
>
>> Yes, it seems this is an API issue; repo.branchtip doesn't exist in
>> python 2.2.
>
> Hi. Presumably this is a problem with old mercurial not a problem with old
> python as mentioned in the commit?
>
>> Both issue
Michael Haggerty alum.mit.edu> writes:
...
> -static int parse_dirstat_params(struct diff_options *options, const char ...
> +static int parse_dirstat_params(struct diff_options *options, const char ...
> struct strbuf *errmsg)
> {
> - const char *p = params;
> -
On Tue, Oct 30, 2012 at 7:12 PM, Sverre Rabbelier wrote:
> On Tue, Oct 30, 2012 at 10:11 AM, Felipe Contreras
> wrote:
>> When an object has already been exported (and thus is in the marks) it
>> is flagged as SHOWN, so it will not be exported again, even if this time
>> it's exported through a d
Felipe Contreras wrote:
> Setting commit to commit is a no-op.
Wrong description. This should say:
The code uses the idiom of assigning commit to itself to quench a
"may be used uninitialized" warning. Luckily at least modern
versions of gcc do not produce that warning
(actually cc-ing the git list this time. Sorry for the noise, all.)
Felipe Contreras wrote:
> [Subject: [PATCH v2 2/4] fast-export: fix comparisson in tests]
>
> First the expected, then the actual, otherwise the diff would be the
> opposite of what we want.
Spelling: s/comparisson/comparison/.
Felipe Contreras wrote:
> They have been marked as UNINTERESTING for a reason, lets respect that.
This patch looks unsafe, and in the examples listed in the patch
description the changed behavior does not look like an improvement.
Worse, the description lists a few examples but gives no convincin
Hi,
Note: sorry for the noise, the first try (v2) was silently eaten by the mailing
list handler.
First patches are general cleanups and fixes, the last patch fixes a real issue
that affects remote helpers.
Changes since v2:
* Actually send it to the ml
Changes since v1:
* Improved commit m
Setting commit to commit is a no-op. It might have been there to avoid a
compiler warning, but if so, it was the compiler to blame.
Signed-off-by: Felipe Contreras
---
builtin/fast-export.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/fast-export.c b/builtin/fast-e
First the expected, then the actual, otherwise the diff would be the
opposite of what we want.
Signed-off-by: Felipe Contreras
---
t/t9350-fast-export.sh | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/t/t9350-fast-export.sh b/t/t9350-fast-export.sh
index 3e821f9..49bdb
They have been marked as UNINTERESTING for a reason, lets respect that.
Currently the first ref is handled properly, but not the rest, so:
% git fast-export master ^master
Would currently throw a reset for master (2nd ref), which is not what we
want.
% git fast-export master ^foo ^bar ^roo
%
When an object has already been exported (and thus is in the marks) it
is flagged as SHOWN, so it will not be exported again, even if this time
it's exported through a different ref.
We don't need the object to be exported again, but we want the ref
updated, which doesn't happen.
Since we can't k
On Tue, Oct 30, 2012 at 1:34 PM, Angelo Borsotti
wrote:
> Hi Cris,
>
> I think a key in the config file of the remote repo is better than an
> option on git-push for what concerns security: it allows the owner of
> the remote repo to enforce the policy not to overwrite tags, which
> would not be p
(again to the mailing list)
On Tue, Oct 30, 2012 at 7:59 PM, Jonathan Nieder wrote:
> Felipe Contreras wrote:
>
>> They have been marked as UNINTERESTING for a reason, lets respect that.
That doesn't say anything.
> and in the examples listed in the patch
> description the changed behavior does
Hi Felipe,
On Tue, 30 Oct 2012, Felipe Contreras wrote:
> But you mentioned something about cooperation, and I've yet to see how
> is it that you are planning to cooperate. If you say you don't have time
> to spend on this, I don't see why I should worry about testing this
> series of patches.
I
Hi Felipe,
On Tue, 30 Oct 2012, Felipe Contreras wrote:
> On Tue, Oct 30, 2012 at 8:01 PM, Jonathan Nieder wrote:
> > Felipe Contreras wrote:
> >> On Tue, Oct 30, 2012 at 7:47 PM, Jonathan Nieder
> >> wrote:
> >
> >>> and in the examples listed in the patch
> >>> description the changed behavi
Hi,
On Tue, Oct 30, 2012 at 8:33 PM, Johannes Schindelin
wrote:
> On Tue, 30 Oct 2012, Felipe Contreras wrote:
>
>> But you mentioned something about cooperation, and I've yet to see how
>> is it that you are planning to cooperate. If you say you don't have time
>> to spend on this, I don't see w
Am 28.10.2012 01:02, schrieb Jens Lehmann:
> Am 26.10.2012 22:43, schrieb Francis Moreau:
>> On Fri, Oct 26, 2012 at 10:05 PM, Jens Lehmann wrote:
>> [...]
>>>
>>> That is weird, "git diff --submodule" should show that too. Is there
>>> anything unusual about your setup? (The only explanation I ca
On Tue, Oct 30, 2012 at 11:47 AM, Felipe Contreras
wrote:
> Why would it? We are not changing the way objects are exported, the
> only difference is what happens at the end
> (handle_tags_and_duplicates()).
Because the marking is per-commit, not per-ref, right? Perhaps you
could add a simple test
shawn wilson writes:
> i'm curious why this is being reported as deleted in status and diff
> and not modified? this was tested on a build of the master branch of
> the current git repo (1.8.0).
>
> mkdir t cd t; git --init
>
> touch test
> git add test
> git commit test -m "test"
>
> ln -s test
On Tue, Oct 30, 2012 at 9:19 PM, Andreas Schwab wrote:
> shawn wilson writes:
>> % git status
>> # On branch master
>> # Changes not staged for commit:
>> # (use "git add/rm ..." to update what will be committed)
>> # (use "git checkout -- ..." to discard changes in working directory)
>> #
Am 29.10.2012 11:30, schrieb Ramkumar Ramachandra:
> Jens Lehmann wrote:
>> Am 02.10.2012 21:44, schrieb Jens Lehmann:
>>> Am 02.10.2012 18:51, schrieb Ramkumar Ramachandra:
Introduce a diff.submoduleFormat configuration variable corresponding
to the '--submodule' command-line option of '
On Mon, Oct 22, 2012 at 03:39:01AM +0200, Felipe Contreras wrote:
> By using print_comp as suggested by SZEDER Gábor.
>
> Signed-off-by: Felipe Contreras
> ---
> t/t9902-completion.sh | 13 +
> 1 file changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/t/t9902-completion.sh b/
Am 29.10.2012 08:11, schrieb Johannes Sixt:
> Am 10/29/2012 0:28, schrieb Jens Lehmann:
>> +/* Remove trailing '/' from directories to find submodules in the index
>> */
>> +for (i = 0; i < argc; i++) {
>> +size_t pathlen = strlen(argv[i]);
>> +if (pathlen && is_dir
shawn wilson writes:
> but should t2 be reported as 'deleted'?
Sure, that's what you did.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
--
To unsubscribe from this list:
Felipe Contreras wrote:
> % git fast-export $marks_args one
> % git fast-export $marks_args one two
>
> Then yeah, 'one' will be updated once again in the second command,
That's probably worth a mention in the commit message and tests
(test_expect_failure), to save future readers from some confus
On Tue, Oct 30, 2012 at 8:01 PM, Jonathan Nieder wrote:
> Felipe Contreras wrote:
>> On Tue, Oct 30, 2012 at 7:47 PM, Jonathan Nieder wrote:
>
>>> and in the examples listed in the patch
>>> description the changed behavior does not look like an improvement.
>>
>> I disagree.
>>
>> % git log mast
On Tue, Oct 30, 2012 at 10:27 PM, SZEDER Gábor wrote:
> On Mon, Oct 22, 2012 at 03:39:01AM +0200, Felipe Contreras wrote:
>> By using print_comp as suggested by SZEDER Gábor.
>>
>> Signed-off-by: Felipe Contreras
>> ---
>> t/t9902-completion.sh | 13 +
>> 1 file changed, 5 insertions
On Tue, Oct 30, 2012 at 9:35 PM, Andreas Schwab wrote:
> shawn wilson writes:
>
>> but should t2 be reported as 'deleted'?
>
> Sure, that's what you did.
>
if i do the same to a file (same repo):
touch test2
git add test2
git commit test2 -m "test2"
rm test
ln -s test2 test
git status
# On b
Felipe Contreras wrote:
> So you think what we have now is the correct behavior:
>
> % git fast-export master ^master
> reset refs/heads/master
> from :0
No, I don't think that, either.
Hope that helps,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a m
shawn wilson writes:
> why is this different?
You didn't tell git about t2/one/test. You need to add it first to make
it known.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely differe
On Tue, Oct 30, 2012 at 2:35 PM, Felipe Contreras
wrote:
> On Tue, Oct 30, 2012 at 10:17 PM, Sverre Rabbelier
> wrote:
>> On Tue, Oct 30, 2012 at 11:47 AM, Felipe Contreras
>> wrote:
>>> Why would it? We are not changing the way objects are exported, the
>>> only difference is what happens at t
On Tue, Oct 30, 2012 at 10:45 PM, Jonathan Nieder wrote:
> Felipe Contreras wrote:
>
>> So you think what we have now is the correct behavior:
>>
>> % git fast-export master ^master
>> reset refs/heads/master
>> from :0
>
> No, I don't think that, either.
Well, that's what we have now, and you wa
Felipe Contreras wrote:
> Well, that's what we have now, and you want to preserve this "feature"
> (aka bug), right?
Nope. I just don't want regressions, and found a patch description
that did nothing to explain to the reader how it avoids regressions
more than a little disturbing.
I also think
shawn wilson writes:
> and once it's added, status says:
> # renamed:t2 -> t2/one/test
>
> that's not exactly true, but...
What's wrong with it? Both files have the same contents, which is the
link target for symlinks.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key finge
Thanks. I know that posix support these usages, but exists some
traditional shell that not support it. These are described in the
autoconf manual, last time i have checked. As the construct ; export
var = x should be portable, but it is not. If this is important these
days i don't know.
Best
201
On Tue, Oct 30, 2012 at 10:59 PM, Sverre Rabbelier wrote:
> On Tue, Oct 30, 2012 at 2:35 PM, Felipe Contreras
> wrote:
>> On Tue, Oct 30, 2012 at 10:17 PM, Sverre Rabbelier
>> wrote:
>>> On Tue, Oct 30, 2012 at 11:47 AM, Felipe Contreras
>>> wrote:
Why would it? We are not changing the wa
On Tue, Oct 30, 2012 at 10:09 PM, Andreas Schwab wrote:
> shawn wilson writes:
>
>> and once it's added, status says:
>> # renamed:t2 -> t2/one/test
>>
>> that's not exactly true, but...
>
> What's wrong with it? Both files have the same contents, which is the
> link target for symlink
On Tue, Oct 30, 2012 at 11:07 PM, Jonathan Nieder wrote:
> Felipe Contreras wrote:
>
>> Well, that's what we have now, and you want to preserve this "feature"
>> (aka bug), right?
>
> Nope. I just don't want regressions, and found a patch description
> that did nothing to explain to the reader ho
On Tue, Oct 30, 2012 at 3:18 PM, Felipe Contreras
wrote:
> Which is expected and correct; the branch already points to the right
> commit, no need for an extra reset.
I think you're correct. Thanks for confirming.
--
Cheers,
Sverre Rabbelier
--
To unsubscribe from this list: send the line "uns
On Mon, Oct 22, 2012 at 03:39:00AM +0200, Felipe Contreras wrote:
> Lots of duplicated code!
>
> No functional changes.
I'm not sure.
I'm all for removing duplicated application code, but I'm usually more
conservative when it comes to test code. The more logic, the more
possibility for bugs in t
On Tue, Oct 30, 2012 at 11:35 PM, Sverre Rabbelier wrote:
> On Tue, Oct 30, 2012 at 3:18 PM, Felipe Contreras
> wrote:
>> Which is expected and correct; the branch already points to the right
>> commit, no need for an extra reset.
>
> I think you're correct. Thanks for confirming.
Thanks for rev
On Mon, Oct 22, 2012 at 03:45:41AM +0200, Felipe Contreras wrote:
> The idea is to never touch the COMPREPLY variable directly.
>
> This allows other completion systems override __gitcompadd, and do
> something different instead.
>
> Also, this allows the simplification of the completion tests (s
On Tue, Oct 30, 2012 at 11:45 PM, SZEDER Gábor wrote:
> On Mon, Oct 22, 2012 at 03:39:00AM +0200, Felipe Contreras wrote:
>> Lots of duplicated code!
>>
>> No functional changes.
>
> I'm not sure.
> I'm all for removing duplicated application code, but I'm usually more
> conservative when it comes
On Tue, Oct 30, 2012 at 11:58 PM, SZEDER Gábor wrote:
> On Mon, Oct 22, 2012 at 03:45:41AM +0200, Felipe Contreras wrote:
>> The idea is to never touch the COMPREPLY variable directly.
>>
>> This allows other completion systems override __gitcompadd, and do
>> something different instead.
>>
>> Al
On Mon, Oct 22, 2012 at 02:41:21AM +0200, Felipe Contreras wrote:
> On Wed, Oct 17, 2012 at 7:28 PM, SZEDER Gábor wrote:
> > On Sun, Oct 14, 2012 at 05:52:49PM +0200, Felipe Contreras wrote:
>
> >> diff --git a/contrib/completion/git-completion.bash
> >> b/contrib/completion/git-completion.bash
I just checked and the issue seems to be fixed! Clicked around on a
bunch of previously broken links and they work!
On Tue, Oct 30, 2012 at 3:38 AM, Holger Hellmuth (IKS)
wrote:
> Am 30.10.2012 09:07, schrieb Mike Norman:
>
>> Not seen any recently. I'm guessing the dev is in the path of
>> hurri
Felipe Contreras wrote:
> On Tue, Oct 30, 2012 at 11:07 PM, Jonathan Nieder wrote:
>> Nope. I just don't want regressions, and found a patch description
>> that did nothing to explain to the reader how it avoids regressions
>> more than a little disturbing.
>
> I see, so you don't have any speci
(cc-ing the git list)
Felipe Contreras wrote:
> When an object has already been exported (and thus is in the marks) it
> is flagged as SHOWN, so it will not be exported again, even if this time
> it's exported through a different ref.
>
> We don't need the object to be exported again, but we want
Felipe Contreras wrote:
> --- a/builtin/fast-export.c
> +++ b/builtin/fast-export.c
> @@ -523,11 +523,16 @@ static void get_tags_and_duplicates(struct object_array
> *pending,
> typename(e->item->type));
> continue;
> }
> -
Hi again,
Felipe Contreras wrote:
> They have been marked as UNINTERESTING for a reason, lets respect that.
So, the above description conveyed zero information, as you mentioned.
A clearer explanation would be the following:
fast-export: don't emit "reset" command for negative refs
On Wed, Oct 31, 2012 at 12:55 AM, Jonathan Nieder wrote:
> Felipe Contreras wrote:
>> On Tue, Oct 30, 2012 at 11:07 PM, Jonathan Nieder wrote:
>
>>> Nope. I just don't want regressions, and found a patch description
>>> that did nothing to explain to the reader how it avoids regressions
>>> more
Felipe Contreras wrote:
> I don't think it's my job to explain to you how 'git fast-export'
> works.
Actually, if you are submitting a patch for inclusion, it is your job
to explain to future readers what the patch does. Yes, the reader
might not be deeply familiar with the part of fast-export y
Hi,
On Wed, Oct 31, 2012 at 1:57 AM, Jonathan Nieder wrote:
> Felipe Contreras wrote:
>
>> They have been marked as UNINTERESTING for a reason, lets respect that.
>
> So, the above description conveyed zero information, as you mentioned.
I meant, this, of course:
>> They have been marked as UNIN
Felipe Contreras wrote:
> On Tue, Oct 30, 2012 at 5:46 AM, Jonathan Nieder wrote:
> > Felipe Contreras wrote:
>>> No reason to use the full path in case this is used externally.
>>>
>>> Signed-off-by: Felipe Contreras
>>
>> "No reason not to" is not a reason to do anything. What symptoms does
>
On Tue, Oct 30, 2012 at 5:37 PM, Jonathan Nieder wrote:
> Felipe Contreras wrote:
>
>> --- a/builtin/fast-export.c
>> +++ b/builtin/fast-export.c
>> @@ -523,11 +523,16 @@ static void get_tags_and_duplicates(struct
>> object_array *pending,
>> typename(e->item->type))
Felipe Contreras wrote:
> This might help you, or other people involved in the problem, but not
> anybody else.
Ok, I give up. Bye.
Sometimes the author of some code and the right person to interact
with the development community by submitting and maintaining it are
not the same person. Hopefu
On Wed, Oct 31, 2012 at 2:08 AM, Jonathan Nieder wrote:
> Felipe Contreras wrote:
>
>> I don't think it's my job to explain to you how 'git fast-export'
>> works.
>
> Actually, if you are submitting a patch for inclusion, it is your job
> to explain to future readers what the patch does.
That's a
Felipe Contreras wrote:
>It's not my job to
> explain to you that 'git fast-export' doesn't work this way, you have
> a command line to type those commands and see for yourself if they do
> what you think they do with a vanilla version of git. Th
On Wed, Oct 31, 2012 at 2:27 AM, Jonathan Nieder wrote:
> Felipe Contreras wrote:
>> On Tue, Oct 30, 2012 at 5:46 AM, Jonathan Nieder wrote:
>> > Felipe Contreras wrote:
>
No reason to use the full path in case this is used externally.
Signed-off-by: Felipe Contreras
>>>
>>> "No r
On Wed, Oct 31, 2012 at 1:11 AM, Jonathan Nieder wrote:
> (cc-ing the git list)
> Felipe Contreras wrote:
>
>> When an object has already been exported (and thus is in the marks) it
>> is flagged as SHOWN, so it will not be exported again, even if this time
>> it's exported through a different ref
On Wed, Oct 31, 2012 at 1:37 AM, Jonathan Nieder wrote:
> Felipe Contreras wrote:
>
>> --- a/builtin/fast-export.c
>> +++ b/builtin/fast-export.c
>> @@ -523,11 +523,16 @@ static void get_tags_and_duplicates(struct
>> object_array *pending,
>> typename(e->item->type))
Felipe Contreras wrote:
> It's all fun and games to write explanations for things, but it's not
> that easy when you want those explanations to be actually true, and
> corrent--you have to spend time to make sure of that.
That's why it's useful for the patch submitter to write them, asking
for he
On Wed, Oct 31, 2012 at 2:51 AM, Jonathan Nieder wrote:
> Felipe Contreras wrote:
>
>>It's not my job to
>> explain to you that 'git fast-export' doesn't work this way, you have
>> a command line to type those commands and see for yourself if the
1 - 100 of 107 matches
Mail list logo
