* Re: [PATCH v2 3/4] fast-export: don't handle uninteresting refs
From: Johannes Schindelin @ 2012-10-30 19:41 UTC (permalink / raw)
To: Felipe Contreras
Cc: Jonathan Nieder, Jeff King, Junio C Hamano, Sverre Rabbelier,
Elijah Newren, git
In-Reply-To: <CAMP44s1W4mwK+cNwBqu2S0=Aw04XX9KBan8w4ghyzqbODdmiLQ@mail.gmail.com>
Hi Felipe,
On Tue, 30 Oct 2012, Felipe Contreras wrote:
> On Tue, Oct 30, 2012 at 8:01 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> > Felipe Contreras wrote:
> >> On Tue, Oct 30, 2012 at 7:47 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> >
> >>> and in the examples listed in the patch
> >>> description the changed behavior does not look like an improvement.
> >>
> >> I disagree.
> >>
> >> % git log master ^master
> >>
> >> What do you expect? Nothing.
> >
> > Yep.
> >
> >> % git fast-export master ^master
> >>
> >> What do you expect? Nothing.
> >
> > Nope.
>
> That's _your_ opinion. I would like to see what others think.
If you wanted to prove that you can work with others without offending
them, I think that failed.
Ciao,
Johannes
^ permalink raw reply
* Re: [PATCH v4 00/13] New remote-hg helper
From: Felipe Contreras @ 2012-10-30 20:15 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jeff King, git, Junio C Hamano, Sverre Rabbelier, Ilari Liusvaara,
Daniel Barkalow, Michael J Gruber
In-Reply-To: <alpine.DEB.1.00.1210302027410.7256@s15462909.onlinehome-server.info>
Hi,
On Tue, Oct 30, 2012 at 8:33 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> 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 why I should worry about testing this
>> series of patches.
>
> It has been mentioned before that the communication style including all
> these snarky and nasty comments is not helpful.
Snarky and nasty comments? How about this?
---
> As to the functionality you seek: git-remote-hg found in
> git://github.com/msysgit/git works. It has the following advantages
> over every other solution, including the one proposed in this thread:
>
> - it works
>
> - no really, it works
>
> - it supports pushes, too
>
> - it matured over a long time
>
> - there are tests
>
> - whenever we fixed bugs, we also added tests for the bug fixes
>
> - it is rock solid
>
> - it is in constant use
>
> Without push support, remote-hg is useless to me. Without regression
> tests proving that it is rock solid, I will not use remote-hg. And I
> will not indulge in efforts to duplicate work.
---
How many times does somebody has to say "it works" before it becomes a
snarky comment?
Or this?
---
> FTR, the reason that it's crashing is because you're lying. You're
> saying you already have master (by means of ^master), but you don't.
---
Or this?
---
> It seems unlikely to me that this never worked, surely no reviewer
> would accept a patch that doesn't actually implement the feature?
> What's the history here?
---
So what did I say?
> But you mentioned something about cooperation,
That's a fact.
Johannes:
---
> > It would be better to work together, but to me the code-styles are way
> > too different, the difference between night and day.
>
> Aha. Well, okay, it was an offer to collaborate.
---
> and I've yet to see how is it that you are planning to cooperate.
This is also a fact. You haven't provided a branch, you haven't reviewed
my implementation, you haven't tried it. You mentioned something about
testing the performance, but then retracted from it.
So, if you were planning to collaborate, now it would be a good time to
mention how.
> 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'm just clarifying how I'm planning to spend my time, specifically if
you are not going to collaborate.
What is snarky and nasty about any of these comments? I'm simply asking
you if you are going to collaborate and how, because I don't see it,
and what I'm going to do.
You think that's snarkier than the comments above? Well, I disagree.
But I don't blame you when you are snarky, nor do I think I should.
> It is hardly the first time that your mails have been insulting, as
> can be researched easily from in the public mailing list archives.
Those who want to be insulted would get insulted. I asked
a simple question "are you going to collaborate?", if you find that
offensive, that's your right.
> In light of the indignation when advised to keep the tone down a little,
> it is probable that the mails were never put through the "would I be
> insulted or hurt if I was the recipient of this?" test, as in "do you want
> me to throw away my work?" when you literally asked us to throw away our
> work.
How did I ask you to throw away your work? I have asked multiple times
now for you to provide a branch so that we can take a look and try it.
I don't know of a better way to throw away code than to refuse to
provide it, which is what you have been doing. So, if anybody can be
blamed of trying to throw away code, it shouldn't be me.
I know you will find the previous statement offensive, but it happens to
be true. It is sad that you will concentrate on the statement, rather
than the fact, and instead of providing the branch (which will help
to avoid throwing away the code), and thus nullify the statement, you
choose to be offended and complain about how offended you are.
Well, I'm offended at how much you refuse to collaborate, and at how
much disdain you throw at my code, but I'm not going to complain about
me being offended; people get offended about all sorts of things. Why
is why there's no law against offending people.
Instead, I choose to do something positive about it and improve my code
with your criticism (e.g. lack of tests), even if that criticism is rude
and unwarranted. But that seems to mean nothing to you.
> So unlike others, I do not ask you to change your tone, nor your
> willingness to work with others. Instead, I prefer to do other things
> instead.
I guess that answers the question; you are not going to collaborate. Got
it.
I will not ask you again for a branch with the remote-hg code.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* change symlink
From: shawn wilson @ 2012-10-30 21:07 UTC (permalink / raw)
To: git
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 t2
git add t2
git commit t2 -m "symlink"
rm t2
mkdir -p t2/one
ln -s test t2/one/test
this then shows up as:
% git status
# On branch master
# Changes not staged for commit:
# (use "git add/rm <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# deleted: t2
#
no changes added to commit (use "git add" and/or "git commit -a")
% git --no-pager diff
diff --git a/t2 b/t2
deleted file mode 120000
index 30d74d2..0000000
--- a/t2
+++ /dev/null
@@ -1 +0,0 @@
-test
\\ No newline at end of file
^ permalink raw reply related
* Re: Can't understand the behaviour of git-diff --submodule
From: Jens Lehmann @ 2012-10-30 21:17 UTC (permalink / raw)
To: Francis Moreau; +Cc: git
In-Reply-To: <508C6823.5060800@web.de>
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 <Jens.Lehmann@web.de> wrote:
>> [...]
>>>
>>> That is weird, "git diff --submodule" should show that too. Is there
>>> anything unusual about your setup? (The only explanation I can come
>>> up with after checking the code is that your submodule has neither a
>>> .git directory nor a gitfile or the objects directory in there doesn't
>>> contain these commits)
>>
>> Oh now you're asking, I think the submodule has been added by using
>> the --reference option of git-submodule-add.
>>
>> $ cd configs
>> $ cat .git
>> gitdir: ../.git/modules/configs
>
> Thanks, I suspect the --reference option makes the difference here,
> I'll check that as soon as I find some time.
Since 1.7.11 and 1.7.10.3 git does handle submodules with alternates
(which is what --reference uses) correctly. What version are you
seeing this problem with?
^ permalink raw reply
* Re: [PATCH v2 4/4] fast-export: make sure refs are updated properly
From: Sverre Rabbelier @ 2012-10-30 21:17 UTC (permalink / raw)
To: Felipe Contreras
Cc: >, Jeff King, Junio C Hamano, Jonathan Nieder,
Johannes Schindelin, Elijah Newren
In-Reply-To: <CAMP44s3MHrG_XeZEodnxemrW-V18+NHnFvi7koyx9mH8XuHc6w@mail.gmail.com>
On Tue, Oct 30, 2012 at 11:47 AM, Felipe Contreras
<felipe.contreras@gmail.com> 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 case to make sure it works as expected?
Something along the lines of the scenario I described in my previous
email?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: change symlink
From: Andreas Schwab @ 2012-10-30 21:19 UTC (permalink / raw)
To: shawn wilson; +Cc: git
In-Reply-To: <CAH_OBie-irmpBrJG6KB3W8bgYjQdyVYiUR-SvJPnx1FXUya0uA@mail.gmail.com>
shawn wilson <ag4ve.us@gmail.com> 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 t2
> git add t2
> git commit t2 -m "symlink"
>
> rm t2
> mkdir -p t2/one
> ln -s test t2/one/test
git add t2/one/test
> this then shows up as:
>
> % git status
> # On branch master
> # Changes not staged for commit:
> # (use "git add/rm <file>..." to update what will be committed)
> # (use "git checkout -- <file>..." to discard changes in working directory)
> #
> # deleted: t2
> #
> no changes added to commit (use "git add" and/or "git commit -a")
I'd expected t2/one/test be reported as untracked.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: change symlink
From: shawn wilson @ 2012-10-30 21:24 UTC (permalink / raw)
To: Andreas Schwab; +Cc: git
In-Reply-To: <m2mwz3odys.fsf@igel.home>
On Tue, Oct 30, 2012 at 9:19 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> shawn wilson <ag4ve.us@gmail.com> writes:
>> % git status
>> # On branch master
>> # Changes not staged for commit:
>> # (use "git add/rm <file>..." to update what will be committed)
>> # (use "git checkout -- <file>..." to discard changes in working directory)
>> #
>> # deleted: t2
>> #
>> no changes added to commit (use "git add" and/or "git commit -a")
>
> I'd expected t2/one/test be reported as untracked.
>
that's fine - i can do 'git list-files --others' but should t2 be
reported as 'deleted'?
^ permalink raw reply
* Re: [PATCH 4/5] diff: introduce diff.submoduleFormat configuration variable
From: Jens Lehmann @ 2012-10-30 21:26 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Git List
In-Reply-To: <CALkWK0nPJ-8UvyYN800-Tj+mLQtv-vF3SJScb1O8EEiY238Z6w@mail.gmail.com>
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 'git diff'.
>>>
>>> Nice. Maybe a better name would be "diff.submodule", as this sets the
>>> default for the "--submodule" option of diff?
>>>
>>> And I think you should also test in t4041 that "--submodule=short"
>>> overrides the config setting.
>>
>> We also need tests which show that setting that config to "log" does
>> not break one of the many users of "git diff" ("stash", "rebase" and
>> "format-patch" come to mind, most probably I missed some others). I
>> suspect we'll have to add "--submodule=short" options to some call
>> sites to keep them working with submodule changes.
>
> Um, why would "stash", "rebase" or "format-patch" be affected by this
> setting? They don't operate on submodules at all. To be sure, I ran
> all the tests with the following diff and nothing broke.
They do operate on the submodule commits too (while they don't touch
submodule work trees) and IIRC rebase applies diffs, so that could
break when the output of diff changes due to the new config option.
But it looks like your test did prove that nothing goes wrong there,
I assume they they use plumbing diff commands which aren't affected
by the new option.
^ permalink raw reply
* Re: [PATCH 2/2] completion: simplify __gitcomp test helper
From: SZEDER Gábor @ 2012-10-30 21:27 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Junio C Hamano, Jeff King
In-Reply-To: <1350869941-22485-3-git-send-email-felipe.contreras@gmail.com>
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 <felipe.contreras@gmail.com>
> ---
> t/t9902-completion.sh | 13 +++++--------
> 1 file changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
> index 1c6952a..2e7fc06 100755
> --- a/t/t9902-completion.sh
> +++ b/t/t9902-completion.sh
> @@ -74,15 +74,12 @@ newline=$'\n'
This $newline variable was only used to set IFS to a newline inside SQ
blocks. AFAICS after this change there are no such places left,
because print_comp() takes care of IFS, so $newline is not necessary
anymore.
> test_gitcomp ()
> {
> + local -a COMPREPLY &&
> sed -e 's/Z$//' > expected &&
> - (
> - local -a COMPREPLY &&
> - cur="$1" &&
> - shift &&
> - __gitcomp "$@" &&
> - IFS="$newline" &&
> - echo "${COMPREPLY[*]}" > out
> - ) &&
> + cur="$1" &&
> + shift &&
> + __gitcomp "$@" &&
> + print_comp &&
> test_cmp expected out
> }
>
> --
> 1.8.0
>
^ permalink raw reply
* Re: [PATCH] Teach rm to remove submodules when given with a trailing '/'
From: Jens Lehmann @ 2012-10-30 21:28 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List, Jeff King
In-Reply-To: <508E2C05.9010109@viscovery.net>
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_directory(argv[i]) && (argv[i][pathlen - 1] == '/'))
>> + argv[i] = xmemdupz(argv[i], pathlen - 1);
>> + }
>> +
>> pathspec = get_pathspec(prefix, argv);
>> refresh_index(&the_index, REFRESH_QUIET, pathspec, NULL, NULL);
>
> That's wrong: Either move the check below get_pathspec() (which normalizes
> backslashes to forward-slashes on Windows) or use is_dir_sep().
Thanks for bringing this up.
> But isn't it somewhat dangerous to check pathspec for existance in the
> worktree without interpreting them? Think of magic pathspec syntax (that
> we do not have yet, but which may materialize sometime in the future).
I have to admit I'm not aware of magic pathspec syntax. Do you happen to
have any pointers where I could look at code doing similar things right?
^ permalink raw reply
* Re: change symlink
From: Andreas Schwab @ 2012-10-30 21:35 UTC (permalink / raw)
To: shawn wilson; +Cc: git
In-Reply-To: <CAH_OBidWxkhG3o4C4OPP4OxyQQfw_fF_h4C9KR9AnoOZ27=9TQ@mail.gmail.com>
shawn wilson <ag4ve.us@gmail.com> writes:
> but should t2 be reported as 'deleted'?
Sure, that's what you did.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH v2 4/4] fast-export: make sure refs are updated properly
From: Felipe Contreras @ 2012-10-30 21:35 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: >, Jeff King, Junio C Hamano, Jonathan Nieder,
Johannes Schindelin, Elijah Newren
In-Reply-To: <CAGdFq_jJwZMLq=3co13hs7gas6y9kZRTKwcT+CP=n6-24Uv5Og@mail.gmail.com>
On Tue, Oct 30, 2012 at 10:17 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> On Tue, Oct 30, 2012 at 11:47 AM, Felipe Contreras
> <felipe.contreras@gmail.com> 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?
Oh, you meant using marks?
It doesn't matter anyway, because get_tags_and_duplicates() would get
'one' on the first run, and 'two' on the second.
If you meant something like this:
% 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, but
there's nothing fatal about it, and your patch series had the same
result.
> Perhaps you
> could add a simple test case to make sure it works as expected?
> Something along the lines of the scenario I described in my previous
> email?
I'm not sure what that test should be doing.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH v2 4/4] fast-export: make sure refs are updated properly
From: Jonathan Nieder @ 2012-10-30 21:38 UTC (permalink / raw)
To: Felipe Contreras
Cc: Sverre Rabbelier, >, Jeff King, Junio C Hamano,
Johannes Schindelin, Elijah Newren
In-Reply-To: <CAMP44s2QwdZKqJq0BZ5HOtZYiCMxCxycui9EmxxfL+Sa6M_6+g@mail.gmail.com>
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 confusion.
Thanks,
Jonathan
^ permalink raw reply
* Re: [PATCH v2 3/4] fast-export: don't handle uninteresting refs
From: Felipe Contreras @ 2012-10-30 21:40 UTC (permalink / raw)
To: Jonathan Nieder
Cc: git, Jeff King, Junio C Hamano, Sverre Rabbelier,
Johannes Schindelin, Elijah Newren
In-Reply-To: <CAMP44s3LP65XOYFg-tBe_rzT1+gXp=714C-u14mkwxY26r4b=g@mail.gmail.com>
On Tue, Oct 30, 2012 at 8:01 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Felipe Contreras wrote:
>> On Tue, Oct 30, 2012 at 7:47 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>
>>> and in the examples listed in the patch
>>> description the changed behavior does not look like an improvement.
>>
>> I disagree.
>>
>> % git log master ^master
>>
>> What do you expect? Nothing.
>
> Yep.
>
>> % git fast-export master ^master
>>
>> What do you expect? Nothing.
So you think what we have now is the correct behavior:
% git fast-export master ^master
reset refs/heads/master
from :0
That of course would crash fast-import. But hey, it's your opinion.
Would be interesting to see if other people think the above is correct.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH v2 4/4] fast-export: make sure refs are updated properly
From: Felipe Contreras @ 2012-10-30 21:41 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Sverre Rabbelier, >, Jeff King, Junio C Hamano,
Johannes Schindelin, Elijah Newren
In-Reply-To: <20121030213827.GM15167@elie.Belkin>
On Tue, Oct 30, 2012 at 10:38 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> 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 confusion.
It is mentioned in the commit message.
--
Felipe Contreras
^ permalink raw reply
* Re: change symlink
From: shawn wilson @ 2012-10-30 21:42 UTC (permalink / raw)
To: Andreas Schwab; +Cc: git
In-Reply-To: <m2fw4vod81.fsf@igel.home>
On Tue, Oct 30, 2012 at 9:35 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> shawn wilson <ag4ve.us@gmail.com> 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 branch master
# Changes not staged for commit:
# (use "git add/rm <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# deleted: t2
# typechange: test
#
no changes added to commit (use "git add" and/or "git commit -a")
why is this different?
^ permalink raw reply
* Re: [PATCH 2/2] completion: simplify __gitcomp test helper
From: Felipe Contreras @ 2012-10-30 21:43 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: git, Junio C Hamano, Jeff King
In-Reply-To: <20121030212725.GA15709@goldbirke>
On Tue, Oct 30, 2012 at 10:27 PM, SZEDER Gábor <szeder@ira.uka.de> 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 <felipe.contreras@gmail.com>
>> ---
>> t/t9902-completion.sh | 13 +++++--------
>> 1 file changed, 5 insertions(+), 8 deletions(-)
>>
>> diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
>> index 1c6952a..2e7fc06 100755
>> --- a/t/t9902-completion.sh
>> +++ b/t/t9902-completion.sh
>> @@ -74,15 +74,12 @@ newline=$'\n'
>
> This $newline variable was only used to set IFS to a newline inside SQ
> blocks. AFAICS after this change there are no such places left,
> because print_comp() takes care of IFS, so $newline is not necessary
> anymore.
Right, I thought I did that =/
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH v2 3/4] fast-export: don't handle uninteresting refs
From: Jonathan Nieder @ 2012-10-30 21:45 UTC (permalink / raw)
To: Felipe Contreras
Cc: git, Jeff King, Junio C Hamano, Sverre Rabbelier,
Johannes Schindelin, Elijah Newren
In-Reply-To: <CAMP44s1tFhh3Xqe9tqoDAdtwnGc=kFT6OmAreeP1nbTstweaQQ@mail.gmail.com>
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
^ permalink raw reply
* Re: change symlink
From: Andreas Schwab @ 2012-10-30 21:50 UTC (permalink / raw)
To: shawn wilson; +Cc: git
In-Reply-To: <CAH_OBifch3uuXYHQ1R9vS6xFu8LuY3mUfiPsHcs3F=HMvnBzyg@mail.gmail.com>
shawn wilson <ag4ve.us@gmail.com> 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, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH v2 4/4] fast-export: make sure refs are updated properly
From: Sverre Rabbelier @ 2012-10-30 21:59 UTC (permalink / raw)
To: Felipe Contreras
Cc: >, Jeff King, Junio C Hamano, Jonathan Nieder,
Johannes Schindelin, Elijah Newren
In-Reply-To: <CAMP44s2QwdZKqJq0BZ5HOtZYiCMxCxycui9EmxxfL+Sa6M_6+g@mail.gmail.com>
On Tue, Oct 30, 2012 at 2:35 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Tue, Oct 30, 2012 at 10:17 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
>> On Tue, Oct 30, 2012 at 11:47 AM, Felipe Contreras
>> <felipe.contreras@gmail.com> 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?
>
> Oh, you meant using marks?
No, I meant the 'SHOWN' flag, doesn't it get added per commit, not per
ref? That is, commit->object.flags & SHOWN refers to the object
underlying the ref. So I suspect this scenario doesn't pass the tests:
git init &&
echo first > content &&
git add content &&
git commit -m "first" &&
git branch first &&
echo two > content &&
git commit -m "second" &&
git branch second &&
git fast-export first > actual &&
test_cmp actual expected_first &&
git fast-export second > actual &&
test_cmp actual expected_second
With expected_first being something like:
<fast-export stream with the first commit>
<reset command to set first to the right commit>
And expected_second being something like
<fast export stream with the first and second command>
<reset command to set first and second to their respective branches>
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH v2 3/4] fast-export: don't handle uninteresting refs
From: Felipe Contreras @ 2012-10-30 22:01 UTC (permalink / raw)
To: Jonathan Nieder
Cc: git, Jeff King, Junio C Hamano, Sverre Rabbelier,
Johannes Schindelin, Elijah Newren
In-Reply-To: <20121030214531.GN15167@elie.Belkin>
On Tue, Oct 30, 2012 at 10:45 PM, Jonathan Nieder <jrnieder@gmail.com> 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 want to preserve this "feature"
(aka bug), right?
And I still haven't why this is "unsafe", and what are those "examples
not listed".
--
Felipe Contreras
^ permalink raw reply
* Re: change symlink
From: shawn wilson @ 2012-10-30 22:03 UTC (permalink / raw)
To: Andreas Schwab; +Cc: git
In-Reply-To: <m27gq7ochp.fsf@igel.home>
On Tue, Oct 30, 2012 at 9:50 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> shawn wilson <ag4ve.us@gmail.com> writes:
>
>> why is this different?
>
> You didn't tell git about t2/one/test. You need to add it first to make
> it known.
>
and once it's added, status says:
# renamed: t2 -> t2/one/test
that's not exactly true, but...
i guess the point is to only track files? if this is the case, i still
disagree with what status is reporting but i suppose it's fine (from a
bug point of view).
^ permalink raw reply
* Re: [PATCH v2 3/4] fast-export: don't handle uninteresting refs
From: Jonathan Nieder @ 2012-10-30 22:07 UTC (permalink / raw)
To: Felipe Contreras
Cc: git, Jeff King, Junio C Hamano, Sverre Rabbelier,
Johannes Schindelin, Elijah Newren
In-Reply-To: <CAMP44s1b+E8a0kdSgREbGzRTFy+nCw4VcjHadd3soQAXRkNzZw@mail.gmail.com>
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 the proposed behavior is wrong.
I don't think there's much benefit to be gained from continuing to
discuss this. Consider it a single data point: I would be deeply
worried if this patch were applied without at least a clearer
description of the change in behavior. Maybe I'm the only one!
Hope that helps,
Jonathan
^ permalink raw reply
* Re: change symlink
From: Andreas Schwab @ 2012-10-30 22:09 UTC (permalink / raw)
To: shawn wilson; +Cc: git
In-Reply-To: <CAH_OBif=Zr-3GO3CE4D6O3wJJZysB6=vvmA37K6ujTHTr-un7w@mail.gmail.com>
shawn wilson <ag4ve.us@gmail.com> 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, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH] test-lib: avoid full path to store test results
From: Elia Pinto @ 2012-10-30 22:17 UTC (permalink / raw)
To: Jonathan Nieder, Felipe Contreras, git, Junio C Hamano, Jeff King,
Ævar Arnfjörð, Johannes Sixt
In-Reply-To: <20121030070152.GA13324@elie.Belkin>
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
2012/10/30, Jonathan Nieder <jrnieder@gmail.com>:
> 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.
>
> Thanks for looking the patch over.
> Jonathan
>
--
Inviato dal mio dispositivo mobile
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox