* Re: [PATCH] gitweb: Do not show 'patch' link in 'commit' view for merges
From: Jakub Narebski @ 2009-10-01 7:36 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20091001031140.GA30094@coredump.intra.peff.net>
Dnia czwartek 1. października 2009 05:11, Jeff King napisał:
> On Wed, Sep 30, 2009 at 10:21:53PM +0200, Jakub Narebski wrote:
>
> > Show 'patch' link in the 'commit' view only for commits which have
> > exactly one parent, otherwise call to git-format-patch would fail for
> > the hyperlinked 'patch' action.
>
> Fail in what way? From my cursory reading of the code, it looks like the
> 'patch' action calls into git_commitdiff, which handles the multi-parent
> case.
>
> I assume I'm reading wrong, since you obviously know gitweb much better
> than I do. :) But can you expand a little on the nature of the problem
> in the commit message?
Well, from the point of view of behavior, 'patch' link in 'commit' view
for a merge commit, e.g.
gitweb.cgi/git.git/commit/833423ae071ffedb7fbca39789f14f9a45a3d1c4
leads to the 'patch' view
git.git/patch/833423ae071ffedb7fbca39789f14f9a45a3d1c4
which leads to 'text/plain' output with the following contents:
Reading git-format-patch failed
From the point of view of code, 'patch' view is handled by git_patch()
subroutine, which in turn calls git_commitdiff(-format => 'patch', -single=> 1);
git_commitdiff checks if 'patch' view is enabled feature, and then
composes and calls the following command (I have skipped --git-dir=...):
git format-patch --encoding=utf8 --stdout -1 --root <commit-id>
And git-format-patch produces no output for merge commit. Then
git_commitdiff dumps output of git-format-patch
local $/ = undef;
print <$fd>;
and somehow fails on closing filehandle
close $fd
or print "Reading git-format-patch failed\n";
Even if 'patch' view didn't fail, it is not a good idea to have link
to an empty page (or page with only error message). Though probably
git_commitdiff could check if it is used for a merge commit...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] gitweb: Do not show 'patch' link in 'commit' view for merges
From: Jeff King @ 2009-10-01 7:55 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200910010936.24789.jnareb@gmail.com>
On Thu, Oct 01, 2009 at 09:36:23AM +0200, Jakub Narebski wrote:
> From the point of view of code, 'patch' view is handled by git_patch()
> subroutine, which in turn calls git_commitdiff(-format => 'patch', -single=> 1);
> git_commitdiff checks if 'patch' view is enabled feature, and then
> composes and calls the following command (I have skipped --git-dir=...):
>
> git format-patch --encoding=utf8 --stdout -1 --root <commit-id>
>
> And git-format-patch produces no output for merge commit. Then
> git_commitdiff dumps output of git-format-patch
Ah, OK, I see the code path you are talking about now. My first thought
was "shouldn't it be handling the merge case?" but that really doesn't
make any sense. The "patch" view is just about something that can be
given to "git am", and it doesn't understand merges anyway. And the
"commitdiff" and "html" formats already handle it appropriately.
So I think your patch is the right thing to do. Thanks for the
explanation.
-Peff
^ permalink raw reply
* Re: [PATCH] Documentation - pt-BR.
From: Jeff King @ 2009-10-01 8:02 UTC (permalink / raw)
To: Thiago Farina; +Cc: Shawn O. Pearce, git
In-Reply-To: <a4c8a6d00909301518v43784d7ah6364be0134a6e7d@mail.gmail.com>
On Wed, Sep 30, 2009 at 07:18:26PM -0300, Thiago Farina wrote:
> Ping
I think the original just got overlooked. My Portuguese is bad enough
that I will have to take your word on the correctness of the fixes.
Shawn, this can probably go straight onto master (tr/doc-pt-br in my
tree).
-Peff
^ permalink raw reply
* Re: [PATCH v5 1/2] gitweb: check given hash before trying to create snapshot
From: Jakub Narebski @ 2009-10-01 8:13 UTC (permalink / raw)
To: Mark Rada; +Cc: Junio C Hamano, git
In-Reply-To: <4ABE5360.8090204@mailservices.uwaterloo.ca>
On Sat, 26 Sep 2009, Mark Rada wrote:
> Makes things nicer in cases when you hand craft the snapshot URL but
> make a typo in defining the hash variable (e.g. netx instead of next);
> you will now get an error message instead of a broken tarball.
>
> Tests for t9501 are included to demonstrate added functionality.
>
> Signed-off-by: Mark Rada <marada@uwaterloo.ca>
> ---
Very nice, and I think robust solution.
Acked-by: Jakub Narebski <jnareb@gmail.com>
[...]
> diff --git a/t/t9501-gitweb-standalone-http-status.sh b/t/t9501-gitweb-standalone-http-status.sh
> index d0ff21d..0688a57 100644
> --- a/t/t9501-gitweb-standalone-http-status.sh
> +++ b/t/t9501-gitweb-standalone-http-status.sh
BTW. the rest of test scripts are executable, but not this one? Why?
(But correcting this should be done, if needed, in separate commit).
> @@ -75,4 +75,43 @@ test_expect_success \
> test_debug 'cat gitweb.output'
>
>
> +# ----------------------------------------------------------------------
> +# snapshot hash ids
> +
> +test_expect_success 'snapshots: good tree-ish id' '
> + gitweb_run "p=.git;a=snapshot;h=master;sf=tgz" &&
> + grep "Status: 200 OK" gitweb.output
> +'
> +test_debug 'cat gitweb.output'
> +
What *could* be improved (but don't *need to*) is to check also HTTP
status and not only formatted error message:
> +test_expect_success 'snapshots: bad tree-ish id' '
> + gitweb_run "p=.git;a=snapshot;h=frizzumFrazzum;sf=tgz" &&
+ grep "Status: 404 Not Found" gitweb.output &&
> + grep "404 - Object does not exist" gitweb.output
> +'
> +test_debug 'cat gitweb.output'
And similarly in other cases. But it is not something required.
I think what it is now is good enough.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Documentation - pt-BR.
From: Jeff King @ 2009-10-01 8:16 UTC (permalink / raw)
To: Thiago Farina; +Cc: Shawn O. Pearce, git
In-Reply-To: <20091001080206.GB13436@coredump.intra.peff.net>
On Thu, Oct 01, 2009 at 04:02:06AM -0400, Jeff King wrote:
> Shawn, this can probably go straight onto master (tr/doc-pt-br in my
> tree).
Er, that should be "tf/doc-pt-br" of course.
-Peff
^ permalink raw reply
* Re: [PATCH 2/2] add NORETURN_PTR for function pointers
From: Jeff King @ 2009-10-01 8:17 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: Shawn O. Pearce, git, msysgit, gitster, Erik Faye-Lund
In-Reply-To: <1254333950-2440-2-git-send-email-kusmabite@gmail.com>
On Wed, Sep 30, 2009 at 06:05:50PM +0000, Erik Faye-Lund wrote:
> Some compilers (including at least MSVC and ARM RVDS) supports
> NORETURN on function declarations, but not on function pointers.
>
> This patch makes it possible to define NORETURN for these compilers,
> by splitting the NORETURN macro into two - one for function
> declarations and one for function pointers.
Thanks, this version and (your 1/2) both look sane to me. The only thing
missing are some Makefile knobs to tweak this, but I will assume that
will come as part of a later MSVC-compatibility series.
Shawn, this can go straight to 'next', if not 'master'. The changes
should be a no-op for most platforms. The only danger would be if there
is some platform that doesn't like their NORETURN magic at the front of
the function declaration. But we only define it by default for __GNUC__,
so I suspect we're safe.
In my tree as ef/msvc-noreturn.
-Peff
^ permalink raw reply
* Re: [PATCH] gitweb: Do not show 'patch' link in 'commit' view for merges
From: Jakub Narebski @ 2009-10-01 9:18 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20091001075540.GA13436@coredump.intra.peff.net>
Dnia czwartek 1. października 2009 09:55, Jeff King napisał:
> On Thu, Oct 01, 2009 at 09:36:23AM +0200, Jakub Narebski wrote:
>
> > From the point of view of code, 'patch' view is handled by git_patch()
> > subroutine, which in turn calls git_commitdiff(-format => 'patch', -single=> 1);
> > git_commitdiff checks if 'patch' view is enabled feature, and then
> > composes and calls the following command (I have skipped --git-dir=...):
> >
> > git format-patch --encoding=utf8 --stdout -1 --root <commit-id>
> >
> > And git-format-patch produces no output for merge commit. Then
> > git_commitdiff dumps output of git-format-patch
>
> Ah, OK, I see the code path you are talking about now. My first thought
> was "shouldn't it be handling the merge case?" but that really doesn't
> make any sense. The "patch" view is just about something that can be
> given to "git am", and it doesn't understand merges anyway. And the
> "commitdiff" and "html" formats already handle it appropriately.
>
> So I think your patch is the right thing to do. Thanks for the
> explanation.
I'll enhance commit message to talk about issues touched here (that
'patch' is for git-am and doesn't make sense for merges, regardless
of possible bug in 'patch' view when used for merge commits), and
check if this correction isn't needed also elsewhere.
I'll send v2 of this patch in a bit.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [JGIT PATCH 1/9] mavenizing step 1: moved over the initial poms from Jasons branch Signed-off-by: Mark Struberg <struberg@yahoo.de>
From: Mark Struberg @ 2009-10-01 11:15 UTC (permalink / raw)
To: Jason van Zyl; +Cc: Shawn O. Pearce, Jonas Fonseca, Robin Rosenberg, git
In-Reply-To: <7BE83B1E-200A-4E19-979D-7A53CE582468@sonatype.com>
Can you please create an EGit repo on github.com/sonatype and push the JGit changes to a fresh branch in sonatype/JGit ?
txs,
strub
--- On Thu, 10/1/09, Jason van Zyl <jason@sonatype.com> wrote:
> From: Jason van Zyl <jason@sonatype.com>
> Subject: Re: [JGIT PATCH 1/9] mavenizing step 1: moved over the initial poms from Jasons branch Signed-off-by: Mark Struberg <struberg@yahoo.de>
> To: "Mark Struberg" <struberg@yahoo.de>
> Cc: "Shawn O. Pearce" <spearce@spearce.org>, "Jonas Fonseca" <jonas.fonseca@gmail.com>, "Robin Rosenberg" <robin.rosenberg.lists@dewire.com>, git@vger.kernel.org
> Date: Thursday, October 1, 2009, 1:16 AM
>
> On 2009-09-30, at 4:13 PM, Mark Struberg wrote:
>
> > Hi!
> >
> > I now squashed all my changes into 2 commits and
> omitted the eclipse parts. They are available at
> >
> > http://github.com/sonatype/JGit/commits/mavenize2
> >
> > As Shawn pointed out on IRC, the next step would be to
> migrate this patch over to the eclipe.org-post branch which
> I will do tomorrow evening.
> >
>
> I also have a Tycho build for the EGIT part, and I have
> bundle creation working for the JGIT part. I've already
> integrated these two builds into our product so it all
> works. I can put it somewhere as you're ready to absorb it
> if you want it.
>
> > LieGrue,
> > strub
> >
> > --- On Wed, 9/30/09, Shawn O. Pearce <spearce@spearce.org>
> wrote:
> >
> >> From: Shawn O. Pearce <spearce@spearce.org>
> >> Subject: Re: [JGIT PATCH 1/9] mavenizing step 1:
> moved over the initial poms from Jasons branch
> Signed-off-by: Mark Struberg <struberg@yahoo..de>
> >> To: "Mark Struberg" <struberg@yahoo.de>
> >> Cc: "Jonas Fonseca" <jonas.fonseca@gmail.com>,
> "Robin Rosenberg" <robin.rosenberg.lists@dewire.com>,
> git@vger.kernel.org,
> "Jason van Zyl" <jvanzyl@sonatype.com>
> >> Date: Wednesday, September 30, 2009, 11:16 PM
> >> Mark Struberg <struberg@yahoo.de>
> >> wrote:
> >>>> From: Jonas Fonseca <jonas.fonseca@gmail.com>
> >>>> actually
> >>>> removes features (by not keeping the JGit
> >> specific
> >>>> settings), which
> >>>> you then try to amend later in the patch
> series.
> >>>
> >>> I'm not sure what JGit specific settings you
> speak
> >> about?
> >>
> >> I think he's talking about the Eclipse settings
> >> files? Or is it
> >> something else?
> >>
> >>>> In terms of making the patch series more
> >> manageable for
> >>>> you, I think
> >>>> the best approach is to start with the
> patches
> >> not relevant
> >>>> to the
> >>>> mavenizing (renaming PathSuffixTestCase).
> >>>
> >>> In fact the fix of the PathSuffixTestCase came
> a few
> >> days later
> >>> after I found the reason why I miss a few
> tests. This
> >> should be
> >>> fixed in the current master anyway and has not
> so much
> >> todo with
> >>> the mavenization itself.
> >>
> >> But it should be earlier in the series because its
> easier
> >> to apply.
> >> Use rebase -i to swap the order of the patches.
> >>
> >>> I had the following in mind: every single
> commit
> >> should be
> >>> compileable and working. So
> it's not easily
> >> manageable to move the
> >>> directory structure in one patch and apply all
> the
> >> changes into
> >>> the poms in another commit.
> >>
> >> Well, you need to edit the pom to change the
> source
> >> directory and do
> >> the move in one commit, and then edit the pom
> further in
> >> another,
> >> possibly removing the source directory directories
> once it
> >> is the
> >> standard maven layout.
> >>
> >>> We could for sure squash the later few
> commits, but I
> >> didn't
> >>> liked to rebase and push since there have been
> a few
> >> forks of the
> >>> mavenize branch and I hoped I could pull back
> a few
> >> commits from
> >>> others and later do a rebase -i.
> >>
> >> True.
> >>
> >> At this point we need to rebase the patches on the
> new
> >> history in
> >> the eclipse.org-post branch, which contains a
> massive
> >> rename of
> >> org.spearce to org.eclipse. That may make
> the tree
> >> reorg patch in
> >> your Maven series harder to bring over to the new
> history,
> >> sorry.
> >>
> >> Worse, we now have to start following the Eclipse
> IP
> >> process[1]
> >> for submissions to JGit...
> >>
> >> [1] http://www.eclipse.org/projects/dev_process/ip-process-in-cartoons.php
> >>
> >> --Shawn.
> >> --
> >> To unsubscribe from this list: send the line
> "unsubscribe
> >> git" in
> >> the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >>
> >
> >
> >
> >
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ----------------------------------------------------------
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] Documentation - pt-BR.
From: Carlos R. Mafra @ 2009-10-01 11:58 UTC (permalink / raw)
To: Jeff King; +Cc: Thiago Farina, Shawn O. Pearce, git
In-Reply-To: <20091001080206.GB13436@coredump.intra.peff.net>
On Thu 1.Oct'09 at 4:02:06 -0400, Jeff King wrote:
> On Wed, Sep 30, 2009 at 07:18:26PM -0300, Thiago Farina wrote:
>
> > Ping
>
> I think the original just got overlooked. My Portuguese is bad enough
> that I will have to take your word on the correctness of the fixes.
I read the patch. The changes are correct and improve the quality
of the text.
^ permalink raw reply
* gitignore: how to exclude a directory tree from being ignored
From: Peter @ 2009-10-01 11:07 UTC (permalink / raw)
To: git
Hi
I want to exclude binaries except in a dir tree that I do not control.
In .gitignore I have:
!vendor/
*.exe
*.o
I would expect that all *.exe and *.o are ignored except those somewhere
in the vendor dir tree.
However, the *.exe and *.o in the vendor dir tree are also ignored.
What is wrong ?
Thanks for you help
P
^ permalink raw reply
* Re: [PATCH] Documentation - pt-BR.
From: Carlos R. Mafra @ 2009-10-01 12:07 UTC (permalink / raw)
To: Jeff King; +Cc: Thiago Farina, Shawn O. Pearce, git
In-Reply-To: <20091001115846.GA5583@Pilar.aei.mpg.de>
On Thu 1.Oct'09 at 13:58:46 +0200, Carlos R. Mafra wrote:
> I read the patch. The changes are correct and improve the quality
> of the text.
From the Portuguese point of view the change below is
correct,
-cabeçalho Subject: e o resto no corpo.
+cabeçalho "Assunto:", e o resto no corpo.
but I don't know if "Subject:" should be translated in
this context. Does git-am accept "Assunto:" instead
of "Subject:" if one is using a Portuguese locale?
^ permalink raw reply
* Re: [PATCH] Documentation - pt-BR.
From: Jeff King @ 2009-10-01 12:22 UTC (permalink / raw)
To: Carlos R. Mafra; +Cc: Thiago Farina, Shawn O. Pearce, git
In-Reply-To: <20091001120711.GB5583@Pilar.aei.mpg.de>
On Thu, Oct 01, 2009 at 02:07:11PM +0200, Carlos R. Mafra wrote:
> On Thu 1.Oct'09 at 13:58:46 +0200, Carlos R. Mafra wrote:
> > I read the patch. The changes are correct and improve the quality
> > of the text.
>
> From the Portuguese point of view the change below is
> correct,
>
> -cabeçalho Subject: e o resto no corpo.
> +cabeçalho "Assunto:", e o resto no corpo.
>
> but I don't know if "Subject:" should be translated in
> this context. Does git-am accept "Assunto:" instead
> of "Subject:" if one is using a Portuguese locale?
No, it doesn't. It must be in English as it is an rfc2822 header. It is
probably best for it to remain in English here, then, as we are
specifically referring to the literal "Subject" mail header, as opposed
to the more abstract concept of a subject. I think putting it in quotes
makes sense, though, to indicate clearly that it is a literal technical
term. I.e.:
-cabeçalho Subject: e o resto no corpo.
+cabeçalho "Subject:" e o resto no corpo.
The patch in my tree has been updated in this way.
Thanks, Carlos, for the review.
-Peff
^ permalink raw reply
* Re: gitignore: how to exclude a directory tree from being ignored
From: Johannes Sixt @ 2009-10-01 12:39 UTC (permalink / raw)
To: Peter; +Cc: git
In-Reply-To: <4AC48D5F.6060401@mycircuit.org>
Peter schrieb:
> Hi
> I want to exclude binaries except in a dir tree that I do not control.
>
> In .gitignore I have:
>
>
> I would expect that all *.exe and *.o are ignored except those somewhere
> in the vendor dir tree.
> However, the *.exe and *.o in the vendor dir tree are also ignored.
This works for me:
*.exe
*.o
!vendor/*.exe
!vendor/*.o
Note that git-status does not descend into directories from which no files
are tracked. Therefore, this will work only after you have git-added at
least one file from vendor/.
git ls-files -o --exclude-standard does descend into the directory.
Furthermore, the !vendor/*.exe patterns are not recursive. Perhaps it is
easier for you to have a separate vendor/.gitignore that has:
!*.exe
!*.o
These _are_ recursive.
-- Hannes
^ permalink raw reply
* Re: gitignore: how to exclude a directory tree from being ignored
From: Johannes Sixt @ 2009-10-01 13:22 UTC (permalink / raw)
To: Peter; +Cc: git
In-Reply-To: <4AC4A7EF.9030002@mycircuit.org>
Peter schrieb:
> Johannes Sixt wrote:
>> Peter schrieb:
>>
>>> Hi
>>> I want to exclude binaries except in a dir tree that I do not control.
>>>
>>> In .gitignore I have:
>>>
>>>
>>> I would expect that all *.exe and *.o are ignored except those somewhere
>>> in the vendor dir tree.
>>> However, the *.exe and *.o in the vendor dir tree are also ignored.
>>>
>>
>> This works for me:
>>
>> *.exe
>> *.o
>> !vendor/*.exe
>> !vendor/*.o
>>
>> Note that git-status does not descend into directories from which no
>> files
>> are tracked. Therefore, this will work only after you have git-added at
>> least one file from vendor/.
>>
>> git ls-files -o --exclude-standard does descend into the directory.
>>
>> Furthermore, the !vendor/*.exe patterns are not recursive. Perhaps it is
>> easier for you to have a separate vendor/.gitignore that has:
>>
>> !*.exe
>> !*.o
>>
>> These _are_ recursive.
>
> 1) I can't have just one .gitignore file in the root dir, if I want to
> _recursively_ inverse the exclude pattern for a sub dir tree.
No, it's not the inversion of the pattern, but the slash (if it is not at
the end) that makes the pattern non-recursive.
> In this case, I have to put individual .gitignore files in the sub trees
> I want to re-include.
If you have only the directory vendor/ with no further interesting
subdirectories, then you can use my first suggestion. But if you have your
*.exe and *.o distributed over several directories of different depths
below vendor/, then it might be easier to have a separate
vendor/.gitignore with recursive patterns (i.e. that do not contain a slash).
> 2) In order to see what will be staged, I have to use the :
> git ls-files -o --exclude-standard
> instead of :
> git ls-files -o -i --exclude-from=.gitignore
> because the latter won't consider .gitignore patterns in subtree
After reading the documentation, I don't know, and I won't try now ;-)
-- Hannes
^ permalink raw reply
* Re: [JGIT PATCH 1/9] mavenizing step 1: moved over the initial poms from Jasons branch Signed-off-by: Mark Struberg <struberg@yahoo.de>
From: Jason van Zyl @ 2009-10-01 13:55 UTC (permalink / raw)
To: Mark Struberg; +Cc: Shawn O. Pearce, Jonas Fonseca, Robin Rosenberg, git
In-Reply-To: <138076.57408.qm@web27806.mail.ukl.yahoo.com>
Sorry, what do you want?
A fork of the EGit repository with the EGit specific changes we have
made to use Tycho to build EGit?
Or do you want a fork of the JGit repo with the Maven build (i.e. not
Tycho) changes?
On 2009-10-01, at 4:15 AM, Mark Struberg wrote:
> Can you please create an EGit repo on github.com/sonatype and push
> the JGit changes to a fresh branch in sonatype/JGit ?
>
> txs,
> strub
>
> --- On Thu, 10/1/09, Jason van Zyl <jason@sonatype.com> wrote:
>
>> From: Jason van Zyl <jason@sonatype.com>
>> Subject: Re: [JGIT PATCH 1/9] mavenizing step 1: moved over the
>> initial poms from Jasons branch Signed-off-by: Mark Struberg <struberg@yahoo.de
>> >
>> To: "Mark Struberg" <struberg@yahoo.de>
>> Cc: "Shawn O. Pearce" <spearce@spearce.org>, "Jonas Fonseca" <jonas.fonseca@gmail.com
>> >, "Robin Rosenberg" <robin.rosenberg.lists@dewire.com>, git@vger.kernel.org
>> Date: Thursday, October 1, 2009, 1:16 AM
>>
>> On 2009-09-30, at 4:13 PM, Mark Struberg wrote:
>>
>>> Hi!
>>>
>>> I now squashed all my changes into 2 commits and
>> omitted the eclipse parts. They are available at
>>>
>>> http://github.com/sonatype/JGit/commits/mavenize2
>>>
>>> As Shawn pointed out on IRC, the next step would be to
>> migrate this patch over to the eclipe.org-post branch which
>> I will do tomorrow evening.
>>>
>>
>> I also have a Tycho build for the EGIT part, and I have
>> bundle creation working for the JGIT part. I've already
>> integrated these two builds into our product so it all
>> works. I can put it somewhere as you're ready to absorb it
>> if you want it.
>>
>>> LieGrue,
>>> strub
>>>
>>> --- On Wed, 9/30/09, Shawn O. Pearce <spearce@spearce.org>
>> wrote:
>>>
>>>> From: Shawn O. Pearce <spearce@spearce.org>
>>>> Subject: Re: [JGIT PATCH 1/9] mavenizing step 1:
>> moved over the initial poms from Jasons branch
>> Signed-off-by: Mark Struberg <struberg@yahoo..de>
>>>> To: "Mark Struberg" <struberg@yahoo.de>
>>>> Cc: "Jonas Fonseca" <jonas.fonseca@gmail.com>,
>> "Robin Rosenberg" <robin.rosenberg.lists@dewire.com>,
>> git@vger.kernel.org,
>> "Jason van Zyl" <jvanzyl@sonatype.com>
>>>> Date: Wednesday, September 30, 2009, 11:16 PM
>>>> Mark Struberg <struberg@yahoo.de>
>>>> wrote:
>>>>>> From: Jonas Fonseca <jonas.fonseca@gmail.com>
>>>>>> actually
>>>>>> removes features (by not keeping the JGit
>>>> specific
>>>>>> settings), which
>>>>>> you then try to amend later in the patch
>> series.
>>>>>
>>>>> I'm not sure what JGit specific settings you
>> speak
>>>> about?
>>>>
>>>> I think he's talking about the Eclipse settings
>>>> files? Or is it
>>>> something else?
>>>>
>>>>>> In terms of making the patch series more
>>>> manageable for
>>>>>> you, I think
>>>>>> the best approach is to start with the
>> patches
>>>> not relevant
>>>>>> to the
>>>>>> mavenizing (renaming PathSuffixTestCase).
>>>>>
>>>>> In fact the fix of the PathSuffixTestCase came
>> a few
>>>> days later
>>>>> after I found the reason why I miss a few
>> tests. This
>>>> should be
>>>>> fixed in the current master anyway and has not
>> so much
>>>> todo with
>>>>> the mavenization itself.
>>>>
>>>> But it should be earlier in the series because its
>> easier
>>>> to apply.
>>>> Use rebase -i to swap the order of the patches.
>>>>
>>>>> I had the following in mind: every single
>> commit
>>>> should be
>>>>> compileable and working. So
>> it's not easily
>>>> manageable to move the
>>>>> directory structure in one patch and apply all
>> the
>>>> changes into
>>>>> the poms in another commit.
>>>>
>>>> Well, you need to edit the pom to change the
>> source
>>>> directory and do
>>>> the move in one commit, and then edit the pom
>> further in
>>>> another,
>>>> possibly removing the source directory directories
>> once it
>>>> is the
>>>> standard maven layout.
>>>>
>>>>> We could for sure squash the later few
>> commits, but I
>>>> didn't
>>>>> liked to rebase and push since there have been
>> a few
>>>> forks of the
>>>>> mavenize branch and I hoped I could pull back
>> a few
>>>> commits from
>>>>> others and later do a rebase -i.
>>>>
>>>> True.
>>>>
>>>> At this point we need to rebase the patches on the
>> new
>>>> history in
>>>> the eclipse.org-post branch, which contains a
>> massive
>>>> rename of
>>>> org.spearce to org.eclipse. That may make
>> the tree
>>>> reorg patch in
>>>> your Maven series harder to bring over to the new
>> history,
>>>> sorry.
>>>>
>>>> Worse, we now have to start following the Eclipse
>> IP
>>>> process[1]
>>>> for submissions to JGit...
>>>>
>>>> [1] http://www.eclipse.org/projects/dev_process/ip-process-in-cartoons.php
>>>>
>>>> --Shawn.
>>>> --
>>>> To unsubscribe from this list: send the line
>> "unsubscribe
>>>> git" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>
>>>
>>>
>>>
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> ----------------------------------------------------------
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>> git" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
>
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
^ permalink raw reply
* Re: gitignore: how to exclude a directory tree from being ignored
From: Peter @ 2009-10-01 13:00 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4AC4A310.8000507@viscovery.net>
Johannes Sixt wrote:
> Peter schrieb:
>
>> Hi
>> I want to exclude binaries except in a dir tree that I do not control.
>>
>> In .gitignore I have:
>>
>>
>> I would expect that all *.exe and *.o are ignored except those somewhere
>> in the vendor dir tree.
>> However, the *.exe and *.o in the vendor dir tree are also ignored.
>>
>
> This works for me:
>
> *.exe
> *.o
> !vendor/*.exe
> !vendor/*.o
>
> Note that git-status does not descend into directories from which no files
> are tracked. Therefore, this will work only after you have git-added at
> least one file from vendor/.
>
> git ls-files -o --exclude-standard does descend into the directory.
>
> Furthermore, the !vendor/*.exe patterns are not recursive. Perhaps it is
> easier for you to have a separate vendor/.gitignore that has:
>
> !*.exe
> !*.o
>
> These _are_ recursive.
>
> -- Hannes
>
Thanks a lot, that clarifies the problem for me. As far as I understand now:
1) I can't have just one .gitignore file in the root dir, if I want to
_recursively_ inverse the exclude pattern for a sub dir tree.
In this case, I have to put individual .gitignore files in the sub trees
I want to re-include.
2) In order to see what will be staged, I have to use the :
git ls-files -o --exclude-standard
instead of :
git ls-files -o -i --exclude-from=.gitignore
because the latter won't consider .gitignore patterns in subtree
Peter
^ permalink raw reply
* [JGIT PATCH] Add support for logAllRefUpdates configuration parameter
From: Christian Halstrick @ 2009-10-01 14:13 UTC (permalink / raw)
To: Shawn O. Pearce, Robin Rosenberg; +Cc: git, Christian Halstrick, Matthias Sohn
From: Christian Halstrick <christian.halstrick@sap.com>
Honor the configuration parameter core.logAllRefUpdates when writing reflogs.
Instead of writing reflog entries always only write reflogs if this parameter
is set to true or if the corresponding file in the <git-dir>/logs directory
already exists. In other words: if you are updating a ref and this parameter is
set to false and there is no file corresponding to your ref in the
<git-dir>/logs folder then no reflog will be written.
This is a fix for the issue http://code.google.com/p/egit/issues/detail?id=4
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
---
.../tst/org/eclipse/jgit/lib/ReflogConfigTest.java | 116 ++++++++++++++++++++
.../src/org/eclipse/jgit/lib/CoreConfig.java | 10 ++
.../src/org/eclipse/jgit/lib/RefLogWriter.java | 18 ++--
.../src/org/eclipse/jgit/lib/Repository.java | 1 +
4 files changed, 137 insertions(+), 8 deletions(-)
create mode 100644 org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/ReflogConfigTest.java
diff --git a/org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/ReflogConfigTest.java b/org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/ReflogConfigTest.java
new file mode 100644
index 0000000..6021050
--- /dev/null
+++ b/org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/ReflogConfigTest.java
@@ -0,0 +1,116 @@
+/*
+ * Copyright (C) 2009, Christian Halstrick, Matthias Sohn, SAP AG
+ *
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * - Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above
+ * copyright notice, this list of conditions and the following
+ * disclaimer in the documentation and/or other materials provided
+ * with the distribution.
+ *
+ * - Neither the name of the Eclipse Foundation, Inc. nor the
+ * names of its contributors may be used to endorse or promote
+ * products derived from this software without specific prior
+ * written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ * CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+ * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+ * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
+ * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+package org.eclipse.jgit.lib;
+
+import java.io.IOException;
+
+public class ReflogConfigTest extends RepositoryTestCase {
+ public void testlogAllRefUpdates() throws Exception {
+ long commitTime = 1154236443000L;
+ int tz = -4 * 60;
+ int nrOfReflogs;
+
+ // check how many entries exist in the reflog and turn off writing
+ // reflogs
+ assertTrue(db.getConfig().getCore().isLogAllRefUpdates());
+ nrOfReflogs = db.getReflogReader(Constants.HEAD).getReverseEntries()
+ .size();
+ db.getConfig().setBoolean("core", null, "logAllRefUpdates", false);
+
+ // do one commit and check that reflog size is 0: no reflogs should be
+ // written
+ final Tree t = new Tree(db);
+ addFileToTree(t, "i-am-a-file", "and this is the data in me\n");
+ commit(t, "A Commit\n", new PersonIdent(jauthor, commitTime, tz),
+ new PersonIdent(jcommitter, commitTime, tz));
+ commitTime += 100;
+ assertTrue(
+ "Reflog for HEAD should contain one entry",
+ db.getReflogReader(Constants.HEAD).getReverseEntries().size() == nrOfReflogs);
+
+ // set the logAllRefUpdates parameter to true and check it
+ db.getConfig().setBoolean("core", null, "logAllRefUpdates", true);
+ assertTrue(db.getConfig().getCore().isLogAllRefUpdates());
+
+ // do one commit and check that reflog size is increased
+ addFileToTree(t, "i-am-another-file", "and this is other data in me\n");
+ commit(t, "A Commit\n", new PersonIdent(jauthor, commitTime, tz),
+ new PersonIdent(jcommitter, commitTime, tz));
+ commitTime += 100;
+ assertTrue(
+ "Reflog for HEAD should contain one additional entry",
+ db.getReflogReader(Constants.HEAD).getReverseEntries().size() == nrOfReflogs + 1);
+
+ // set the logAllRefUpdates parameter to false and check it
+ db.getConfig().setBoolean("core", null, "logAllRefUpdates", false);
+ assertFalse(db.getConfig().getCore().isLogAllRefUpdates());
+
+ // do one commit and check that reflog size is 2
+ addFileToTree(t, "i-am-anotheranother-file",
+ "and this is other other data in me\n");
+ commit(t, "A Commit\n", new PersonIdent(jauthor, commitTime, tz),
+ new PersonIdent(jcommitter, commitTime, tz));
+ assertTrue(
+ "Reflog for HEAD should contain two additional entries",
+ db.getReflogReader(Constants.HEAD).getReverseEntries().size() == nrOfReflogs + 2);
+ }
+
+ private void addFileToTree(final Tree t, String filename, String content)
+ throws IOException {
+ FileTreeEntry f = t.addFile(filename);
+ writeTrashFile(f.getName(), content);
+ t.accept(new WriteTree(trash, db), TreeEntry.MODIFIED_ONLY);
+ }
+
+ private void commit(final Tree t, String commitMsg, PersonIdent author,
+ PersonIdent committer) throws IOException {
+ final Commit commit = new Commit(db);
+ commit.setAuthor(author);
+ commit.setCommitter(committer);
+ commit.setMessage(commitMsg);
+ commit.setTree(t);
+ ObjectWriter writer = new ObjectWriter(db);
+ commit.setCommitId(writer.writeCommit(commit));
+
+ int nl = commitMsg.indexOf('\n');
+ final RefUpdate ru = db.updateRef(Constants.HEAD);
+ ru.setNewObjectId(commit.getCommitId());
+ ru.setRefLogMessage("commit : "
+ + ((nl == -1) ? commitMsg : commitMsg.substring(0, nl)), false);
+ ru.forceUpdate();
+ }
+}
diff --git a/org.eclipse.jgit/src/org/eclipse/jgit/lib/CoreConfig.java b/org.eclipse.jgit/src/org/eclipse/jgit/lib/CoreConfig.java
index d44120a..a945894 100644
--- a/org.eclipse.jgit/src/org/eclipse/jgit/lib/CoreConfig.java
+++ b/org.eclipse.jgit/src/org/eclipse/jgit/lib/CoreConfig.java
@@ -57,9 +57,12 @@ public CoreConfig parse(final Config cfg) {
private final int packIndexVersion;
+ private final boolean logAllRefUpdates;
+
private CoreConfig(final Config rc) {
compression = rc.getInt("core", "compression", DEFAULT_COMPRESSION);
packIndexVersion = rc.getInt("pack", "indexversion", 2);
+ logAllRefUpdates = rc.getBoolean("core", "logAllRefUpdates", true);
}
/**
@@ -77,4 +80,11 @@ public int getCompression() {
public int getPackIndexVersion() {
return packIndexVersion;
}
+
+ /**
+ * @return whether to log all refUpdates
+ */
+ public boolean isLogAllRefUpdates() {
+ return logAllRefUpdates;
+ }
}
diff --git a/org.eclipse.jgit/src/org/eclipse/jgit/lib/RefLogWriter.java b/org.eclipse.jgit/src/org/eclipse/jgit/lib/RefLogWriter.java
index 4141a13..a473c42 100644
--- a/org.eclipse.jgit/src/org/eclipse/jgit/lib/RefLogWriter.java
+++ b/org.eclipse.jgit/src/org/eclipse/jgit/lib/RefLogWriter.java
@@ -112,16 +112,18 @@ private static void appendOneRecord(final ObjectId oldId,
final byte[] rec = Constants.encode(r.toString());
final File logdir = new File(db.getDirectory(), Constants.LOGS);
final File reflog = new File(logdir, refName);
- final File refdir = reflog.getParentFile();
+ if (reflog.exists() || db.getConfig().getCore().isLogAllRefUpdates()) {
+ final File refdir = reflog.getParentFile();
- if (!refdir.exists() && !refdir.mkdirs())
- throw new IOException("Cannot create directory " + refdir);
+ if (!refdir.exists() && !refdir.mkdirs())
+ throw new IOException("Cannot create directory " + refdir);
- final FileOutputStream out = new FileOutputStream(reflog, true);
- try {
- out.write(rec);
- } finally {
- out.close();
+ final FileOutputStream out = new FileOutputStream(reflog, true);
+ try {
+ out.write(rec);
+ } finally {
+ out.close();
+ }
}
}
diff --git a/org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java b/org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java
index f2451d4..1eb5895 100644
--- a/org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java
+++ b/org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java
@@ -187,6 +187,7 @@ public void create(boolean bare) throws IOException {
cfg.setBoolean("core", null, "filemode", true);
if (bare)
cfg.setBoolean("core", null, "bare", true);
+ cfg.setBoolean("core", null, "logAllRefupdates", !bare);
cfg.save();
}
--
1.6.4.msysgit.0
^ permalink raw reply related
* Re: gitignore: how to exclude a directory tree from being ignored
From: Peter @ 2009-10-01 14:48 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4AC4AD25.5010708@viscovery.net>
>> 1) I can't have just one .gitignore file in the root dir, if I want to
>> _recursively_ inverse the exclude pattern for a sub dir tree.
>>
>
> No, it's not the inversion of the pattern, but the slash (if it is not at
> the end) that makes the pattern non-recursive.
>
>
from the gitignore manpage:
>> If the pattern ends with a slash, it is removed for the purpose of
the following description, but it would only find a match with a
directory. In other words, foo/ will match a directory foo and paths
underneath it, but will not match a regular file or a symbolic link foo
(this is consistent with the way how pathspec works in general in git). <<
Doesn't this mean, that if I say:
vendor/
matches the directory and ( recursively ) the paths underneath it.?
And, consequently:
!vendor/
inverse the exclusion for vendor ( that is: include ) and everything
that is contained in it ? ( This is obviously not the case, but this is
what I would expect )
>> In this case, I have to put individual .gitignore files in the sub trees
>> I want to re-include.
>>
>
> If you have only the directory vendor/ with no further interesting
> subdirectories, then you can use my first suggestion. But if you have your
> *.exe and *.o distributed over several directories of different depths
> below vendor/, then it might be easier to have a separate
> vendor/.gitignore with recursive patterns (i.e. that do not contain a slash).
>
>
This works for me ( I have indeed distributed them over several dirs )
>> 2) In order to see what will be staged, I have to use the :
>> git ls-files -o --exclude-standard
>> instead of :
>> git ls-files -o -i --exclude-from=.gitignore
>> because the latter won't consider .gitignore patterns in subtree
>>
>
> After reading the documentation, I don't know, and I won't try now ;-)
>
>
At least it seams to work here ..
> -- Hannes
>
Thanks !
^ permalink raw reply
* Re: Alles wird Git, Berlin, Oct 3rd, 2009
From: Johannes Schindelin @ 2009-10-01 15:20 UTC (permalink / raw)
To: Heiko Voigt; +Cc: git
In-Reply-To: <20090930190809.GF567@book.hvoigt.net>
Hi,
On Wed, 30 Sep 2009, Heiko Voigt wrote:
> On Fri, Sep 25, 2009 at 08:19:44AM +0200, Johannes Schindelin wrote:
> > as some of you already know, I will be unable to Git Together with
> > other Gits in California this year. So the only version of such a Git
> > Together I will have this year is the Berlin one.
>
> Just announcing that Jens Lehmann and me will also come. Just added us
> to the wiki page. What about important stuff like coffee during the day?
> Is there access to such things nearby or is it better to bring
> everything needed?
Steffen said that he'll take care of the coffee, I'll make sure there is
some beer.
Feel free to bring whatever you feel is missing, but beware: this Saturday
is a German holiday ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: gitignore: how to exclude a directory tree from being ignored
From: Johannes Sixt @ 2009-10-01 15:25 UTC (permalink / raw)
To: Peter; +Cc: git
In-Reply-To: <4AC4C125.10609@mycircuit.org>
Peter schrieb:
>>> 1) I can't have just one .gitignore file in the root dir, if I want to
>>> _recursively_ inverse the exclude pattern for a sub dir tree.
>>>
>>
>> No, it's not the inversion of the pattern, but the slash (if it is not at
>> the end) that makes the pattern non-recursive.
>>
>>
> from the gitignore manpage:
>>> If the pattern ends with a slash, it is removed for the purpose of
> the following description, but it would only find a match with a
> directory. In other words, foo/ will match a directory foo and paths
> underneath it, but will not match a regular file or a symbolic link foo
> (this is consistent with the way how pathspec works in general in git). <<
>
> Doesn't this mean, that if I say:
> vendor/
> matches the directory and ( recursively ) the paths underneath it.?
The paragraph you are citing is talking about *what* the pattern matches,
but it says nothing about *where* the pattern matches.
When I was saying "recursively", then I was refering to the "where"
aspect, not the "what" aspect.
If you have directories
src/bar/vendor/
src/foo/bar/vendor/
src/vendor/
and you have the file src/.gitignore with the single pattern
vendor/
then it applies to recursively ("where") these directories:
src/bar/vendor/
src/foo/bar/vendor/
src/vendor/
and everything ("what") below them.
But if the same src/.gitignore has only this pattern:
bar/vendor/
then it will not match ("where") recursively and only apply to
src/bar/vendor/
and everything ("what") below it, but will not apply to
src/foo/bar/vendor/
> And, consequently:
> !vendor/
> inverse the exclusion for vendor ( that is: include ) and everything
> that is contained in it ? ( This is obviously not the case, but this is
> what I would expect )
You should update your expectations. ;-)
You think that git starts with the .gitignore files, and somehow applies
the rules that it finds to all files (perhaps recursively).
But it does not work like this; rather it is in the oppsite direction: git
starts with a file name, and then checks the rules in the .gitignore files
that it has available.
For example, take the path "src/vendor/foo.exe". git finds the file
src/.gitignore and there it sees the pattern "*.exe". The pattern matches,
and so git obeys the rule (ignores the file). But the pattern "!vendor/"
does not match (because the path ends with "foo.exe", not "vendor").
Before git had seen the path "src/vendor/foo.exe", it had already seen
"src/vendor". This time the pattern "!vendor/" did match (because the name
is identical *and* it is a directory, as per the cited paragraph) and git
obeyed the rule (which was not to ignore the directory).
-- Hannes
^ permalink raw reply
* Re: gitignore: how to exclude a directory tree from being ignored
From: Peter @ 2009-10-01 16:26 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4AC4C9DB.2090907@viscovery.net>
Johannes Sixt wrote:
> Peter schrieb:
>
>>>> 1) I can't have just one .gitignore file in the root dir, if I want to
>>>> _recursively_ inverse the exclude pattern for a sub dir tree.
>>>>
>>>>
>>> No, it's not the inversion of the pattern, but the slash (if it is not at
>>> the end) that makes the pattern non-recursive.
>>>
>>>
>>>
>> from the gitignore manpage:
>>
>>>> If the pattern ends with a slash, it is removed for the purpose of
>>>>
>> the following description, but it would only find a match with a
>> directory. In other words, foo/ will match a directory foo and paths
>> underneath it, but will not match a regular file or a symbolic link foo
>> (this is consistent with the way how pathspec works in general in git). <<
>>
>> Doesn't this mean, that if I say:
>> vendor/
>> matches the directory and ( recursively ) the paths underneath it.?
>>
>
> The paragraph you are citing is talking about *what* the pattern matches,
> but it says nothing about *where* the pattern matches.
>
> When I was saying "recursively", then I was refering to the "where"
> aspect, not the "what" aspect.
>
> If you have directories
>
> src/bar/vendor/
> src/foo/bar/vendor/
> src/vendor/
>
> and you have the file src/.gitignore with the single pattern
>
> vendor/
>
> then it applies to recursively ("where") these directories:
>
> src/bar/vendor/
> src/foo/bar/vendor/
> src/vendor/
>
> and everything ("what") below them.
>
> But if the same src/.gitignore has only this pattern:
>
> bar/vendor/
>
> then it will not match ("where") recursively and only apply to
>
> src/bar/vendor/
>
> and everything ("what") below it, but will not apply to
>
> src/foo/bar/vendor/
>
>
>> And, consequently:
>> !vendor/
>> inverse the exclusion for vendor ( that is: include ) and everything
>> that is contained in it ? ( This is obviously not the case, but this is
>> what I would expect )
>>
>
> You should update your expectations. ;-)
>
> You think that git starts with the .gitignore files, and somehow applies
> the rules that it finds to all files (perhaps recursively).
>
> But it does not work like this; rather it is in the oppsite direction: git
> starts with a file name, and then checks the rules in the .gitignore files
> that it has available.
>
> For example, take the path "src/vendor/foo.exe". git finds the file
> src/.gitignore and there it sees the pattern "*.exe". The pattern matches,
> and so git obeys the rule (ignores the file). But the pattern "!vendor/"
> does not match (because the path ends with "foo.exe", not "vendor").
>
> Before git had seen the path "src/vendor/foo.exe", it had already seen
> "src/vendor". This time the pattern "!vendor/" did match (because the name
> is identical *and* it is a directory, as per the cited paragraph) and git
> obeyed the rule (which was not to ignore the directory).
>
> -- Hannes
>
Ok, In fact, my problem therefore derives from the fact that I can't
specify *what* and *where* for one item in the same .gitignore file. (
all *.o files - what - underneath vendor - where )
*.o
!vendor/
The *.o refers to the *what* and !vendor/ to the *where* and this does
not work. And this seems to be the reasons why we need to split the
rules over different .gitignore files:
in the root .gitignore:
*.o
and in the vendor/.gitignore:
!*.o
does exactly what I want.
To me , the *where* aspect relates indeed to recursion but the *what*
aspect perhaps more to pattern matching...
You should update your expectations. ;-)
Done !
At revision 1238945761623511 :-(
Thanks a lot !
Peter
^ permalink raw reply
* Trying to split repository
From: Josef Wolf @ 2009-10-01 16:03 UTC (permalink / raw)
To: git
Hello,
One of my repositories has grown a subdirectory that I'd like to split off,
so other can use it as a subproject. With the help of google, I found this
solution:
# first extract the library from the original repository
#
git clone --no-hardlinks repository library.tmp
(
cd library.tmp
git filter-branch --subdirectory-filter CF -- --all
git reset --hard
git gc --aggressive
git prune
git gc
git clone --bare . ../library
)
rm -rf library.tmp
# Now remove the library from the original repository, so it can be
# included as a subproject
#
git clone --no-hardlinks repository repository.new.tmp
(
cd repository.new.tmp
git filter-branch \
--index-filter "git rm -r -f --cached --ignore-unmatch CF" \
-- --all
git reset --hard
git gc --aggressive
git prune
git gc
git clone --bare . ../repository.new
)
rm -rf repository.new.tmp
This works fine. But there's one problem, though. "gitk --all" in the new
repository still shows all the history of the removed library. The patch
show no modifications, but the log entry is still there.
Any hints how to get rid of those log entries?
^ permalink raw reply
* Re: Trying to split repository
From: Adam Brewster @ 2009-10-01 16:49 UTC (permalink / raw)
To: Josef Wolf, git
In-Reply-To: <20091001160335.GA26068@raven.wolf.lan>
>
> Any hints how to get rid of those log entries?
git-filter-branch accepts a --prune-empty option that does what I
think you're looking for.
Adam
^ permalink raw reply
* Re: Trying to split repository
From: Tomas Carnecky @ 2009-10-01 16:49 UTC (permalink / raw)
To: Josef Wolf; +Cc: git
In-Reply-To: <20091001160335.GA26068@raven.wolf.lan>
On Oct 1, 2009, at 6:03 PM, Josef Wolf wrote:
> Hello,
>
> One of my repositories has grown a subdirectory that I'd like to
> split off,
> so other can use it as a subproject. With the help of google, I
> found this
> solution:
Take a look at git-subtree (http://github.com/apenwarr/git-subtree).
tom
^ permalink raw reply
* Re: [PATCH 2/2] add NORETURN_PTR for function pointers
From: Erik Faye-Lund @ 2009-10-01 16:57 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn O. Pearce, git, msysgit, gitster, Erik Faye-Lund
In-Reply-To: <20091001081710.GC13436@coredump.intra.peff.net>
On Thu, Oct 1, 2009 at 1:17 AM, Jeff King <peff@peff.net> wrote:
> Thanks, this version and (your 1/2) both look sane to me. The only thing
> missing are some Makefile knobs to tweak this, but I will assume that
> will come as part of a later MSVC-compatibility series.
Thanks for reviewing :)
I sent an additional patch to the msysgit mailing-list that defines
NORETURN for MSVC, but I think it's better to keep it out of git.git
for a little while. There's no Makefile-knobs, it checks for _MSC_VER
(similar to what's done for GCC).
--
Erik "kusma" Faye-Lund
kusmabite@gmail.com
(+47) 986 59 656
^ 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