* 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: 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: 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: [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: [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
* 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 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
* 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] 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: [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] 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 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: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] 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] 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: git svn's performance on cloning mono's branches/tags...
From: Eric Wong @ 2009-10-01 7:17 UTC (permalink / raw)
To: Hin-Tak Leung; +Cc: Andreas Ericsson, git
In-Reply-To: <3ace41890909301504w633323b9ybec1f42c1c169225@mail.gmail.com>
Hin-Tak Leung <hintak.leung@gmail.com> wrote:
> Hmm, I am having another problem with git-svn going back and download
> everything over and over with this:
>
> git svn clone -s https://ndiswrapper.svn.sourceforge.net/svnroot/ndiswrapper
>
> I am going to do two-step init -s then fetch --all now to see if it helps.
>
> (it is probably not entirely standard layout with the extra CVSROOT?)
Hi,
The ndiswrapper layout looks to be *almost* standard, the CVSROOT can
probably safely be ignored, and you should be able to _mostly_ track it
with the following config:
[svn-remote "svn"]
url = https://ndiswrapper.svn.sourceforge.net/svnroot/ndiswrapper
fetch = trunk/ndiswrapper:refs/remotes/trunk
branches = branches/*/ndiswrapper:refs/remotes/*
tags = tags/*/ndiswrapper:refs/remotes/tags/*
Notice how the glob can appear in the middle of the branches and tags
configs on the remote side: foo/*/bar
Unfortunately, some of the tags seem to be inconsistently tagged and
some had tags/TAGNAME/README whereas others had
tags/TAGNAME/ndiswrapper/README (I'm using "README" to designate where
the logical top-level working directory would be).
"svn log -v https://ndiswrapper.svn.sourceforge.net/svnroot/ndiswrapper/tags"
should help find the ones that are tagged at the wrong depth:
VERSION_1_24 for example:
fetch = tags/VERSION_1_24:refs/remotes/tags/VERSION_1_24
--
Eric Wong
^ permalink raw reply
* Re: Git push over git protocol for corporate environment
From: Marius Storm-Olsen @ 2009-10-01 6:29 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Michael Poole, Eugene Sajine, git
In-Reply-To: <20091001000620.GN14660@spearce.org>
Shawn O. Pearce said the following on 01.10.2009 02:06:
> Michael Poole <mdpoole@troilus.org> wrote:
>> (Others have mentioned Gerrit. I use that at work, and my only
>> major wish is that it had per-branch rather than per-project
>> access controls. It is a vast improvement over the Subversion
>> system we had before.)
>
> You'll be happy to hear _everyone_ is demanding per-branch
> controls, I have to do it before the end of the year, maybe even
> before the end of the month...
Ugh, any pointers on this one? Does this mean that you're planning to
add this sort of control in git itself, or just some way to facilitate
the setting of owner/group on individual ref files? What about packed
refs?
--
.marius
^ permalink raw reply
* Re: Redundant merges?
From: Jeff King @ 2009-10-01 3:34 UTC (permalink / raw)
To: skillzero; +Cc: git
In-Reply-To: <2729632a0909301415p7fe0da44l9453fca70bd523ca@mail.gmail.com>
On Wed, Sep 30, 2009 at 02:15:50PM -0700, skillzero@gmail.com wrote:
> Is there a way to avoid redundant merges when merging maint to master
> if both maint and master have already merged in the same topic
> branches? For example, assuming the git.git repository:
>
> 1. A bug was found and a topic branch (with a merge-base at or before
> maint) is created with the fix.
> 2. The fix looks good so it's merged into master.
> 3. maint is already past the freeze date so the fix isn't merged into
> maint (bug is not super critical).
> 4. maint is delayed for some reason and is accepting fixes.
> 5. Topic branch from step 1 is merged into maint.
> 6. maint is merged into master.
Not without losing the shape of history (which is immutable in git).
We can suppress the merge if you do it in this order:
1. maint merges topic
2. master merges maint
3. master merges topic
In step (3), we see that we already have everything from topic. It works
because the merges happened linearly along a line of history.
But you are merging in a non-linear way:
1. maint merges topic
2. master merges topic
3. master merges maint
So the merging of the topic branches happened "simultaneously" with
respect to the history topology. Any attempt to _not_ have a merge
commit between master and maint in step (3) would have to rewrite one of
the merges from (1) or (2), which would change history.
> What I see is two merge commits that merge the same topic. I think I
> understand why it's doing this (the merge commit is just another
> commit so it merges it). But could it look at what the merge did and
> realize that it already has the commit that the merge commit merged
> and do nothing in this case?
But there isn't nothing to do. You don't have to merge the topic
branch, but you do have to merge the current state of 'maint'. In
addition to keeping the history information (the fact that the topic was
merged, by whom, and when), we also need to record the state of any
conflict resolution that occurred. And when we merge it into master, we
need to resolve any conflicts introduced by the different ways in which
master and maint incorporated the changes from the topic.
For an example, try setting up the repo described by the script below,
checking "gitk --all", and then doing the merges in the two orders I
specified above. In the second case, you will get conflicts that need
resolving for all three merges, whereas in the first, there can be no
conflict for the step (3).
-- >8 --
#!/bin/sh
rm -rf repo
mkdir repo && cd repo && git init
commit() {
echo $1 >>file && git add file && git commit -m "$1"
}
commit base
git checkout -b maint
commit maint
git checkout master
commit master
git checkout -b topic maint^
commit topic
^ permalink raw reply
* Re: [PATCH] gitweb: Do not show 'patch' link in 'commit' view for merges
From: Jeff King @ 2009-10-01 3:11 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <20090930201953.22301.73887.stgit@localhost.localdomain>
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?
-Peff
^ 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: Douglas Campos @ 2009-10-01 2:05 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Mark Struberg, Jonas Fonseca, Robin Rosenberg, git, Jason van Zyl
In-Reply-To: <20090930211646.GM14660@spearce.org>
> 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
>
How we'll handle this? Are the acks/signoffs that we use with mail
patches enough for this?
Painful process, BTW
--
Douglas Campos (qmx)
+55 11 7626 5959
^ 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: Jonas Fonseca @ 2009-10-01 1:33 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Mark Struberg, Robin Rosenberg, git, Jason van Zyl
In-Reply-To: <20090930211646.GM14660@spearce.org>
On Wed, Sep 30, 2009 at 17:16, Shawn O. Pearce <spearce@spearce.org> wrote:
> 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?
Sorry for the confusion, I meant the tweaks in the current pom.xml for
matching tests such as T000* ..
--
Jonas Fonseca
^ permalink raw reply
* Re: [PATCH v2] send-email: fix mutt regex for grouped aliases
From: Jeff King @ 2009-10-01 0:22 UTC (permalink / raw)
To: Eric Wong; +Cc: Felipe Contreras, git, Junio C Hamano
In-Reply-To: <20090930205501.GA30910@dcvr.yhbt.net>
On Wed, Sep 30, 2009 at 01:55:01PM -0700, Eric Wong wrote:
> Felipe Contreras <felipe.contreras@gmail.com> wrote:
> > For example:
> > alias -group friends foo Foo Bar <foo@bar.com>
> >
> > Comments by Jeff King.
> >
> > Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
>
> Interesting, I didn't know about this feature in mutt before.
>
> Acked(-and-tested)-by: Eric Wong <normalperson@yhbt.net>
Nor did I, which is why I was reading the docs. :) The v2 patch looks
good to me, as well.
-Peff
^ permalink raw reply
* Re: Git push over git protocol for corporate environment
From: Shawn O. Pearce @ 2009-10-01 0:06 UTC (permalink / raw)
To: Michael Poole; +Cc: Eugene Sajine, git
In-Reply-To: <873a64gfa6.fsf@sanosuke.troilus.org>
Michael Poole <mdpoole@troilus.org> wrote:
> (Others have mentioned Gerrit. I use that at work, and my only major
> wish is that it had per-branch rather than per-project access
> controls. It is a vast improvement over the Subversion system we had
> before.)
You'll be happy to hear _everyone_ is demanding per-branch controls,
I have to do it before the end of the year, maybe even before the
end of the month...
--
Shawn.
^ permalink raw reply
* Re: Git push over git protocol for corporate environment
From: Michael Poole @ 2009-09-30 23:54 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git
In-Reply-To: <76c5b8580909301613m283c4bfdne8de449ca0fd0987@mail.gmail.com>
Eugene Sajine writes:
[snip]
> My problem is that I need the simplest, easiest and fastest solution
> from setup and maintenance point of view in a situation when we have a
> huge CVS repo with hundreds of modules (projects) in it. My current
> understanding is that we are going to pull out project by project from
> CVS and create corresponding git repos.
> So, this brings us to hundreds of git repos and over 200 hundred
> committers. In this circumstances we don’t want to manage each repo
> separately as well as we don’t want to manage each person write access
> rights to each repo.
> As I understand the best solution here is git protocol (one port only
> on dedicated server and no security as we are in trusted network) with
> read and write access configured for all repos on a dedicated server.
> What do you think I should do? How to enable push over git protocol?
How do you manage permissions now? How would you like to manage
rights under the new system?
I am a git amateur, but I would suggest using git+ssh (git over ssh)
and use group or ACL permissions based on the SSH user account. The
standard git-daemon does not provide authentication or authorization,
so you would have to roll your own -- but git+ssh lets you leverage
the operating system's built-in access controls.
For example, some developers might belong to group A, and others
developers belong to group B. With standard Unix permissions, you
could grant global read but only group-A commit rights to any number
of permissions (by appropriate use of git init --shared).
I have not tried using POSIX ACLs to grant more complicated access
rights for git repositories, but setting default ACL entries on the
directory before running "git init" *should* give good results.
(Others have mentioned Gerrit. I use that at work, and my only major
wish is that it had per-branch rather than per-project access
controls. It is a vast improvement over the Subversion system we had
before.)
Michael Poole
^ permalink raw reply
* Re: Git push over git protocol for corporate environment
From: Jakub Narebski @ 2009-09-30 23:43 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git
In-Reply-To: <76c5b8580909301613m283c4bfdne8de449ca0fd0987@mail.gmail.com>
Eugene Sajine <euguess@gmail.com> writes:
> My problem is that I need the simplest, easiest and fastest solution
> from setup and maintenance point of view in a situation when we have a
> huge CVS repo with hundreds of modules (projects) in it. My current
> understanding is that we are going to pull out project by project from
> CVS and create corresponding git repos.
>
> So, this brings us to hundreds of git repos and over 200 hundred
> committers. In this circumstances we don’t want to manage each repo
> separately as well as we don’t want to manage each person write access
> rights to each repo.
>
> As I understand the best solution here is git protocol (one port only
> on dedicated server and no security as we are in trusted network) with
> read and write access configured for all repos on a dedicated server.
> What do you think I should do? How to enable push over git protocol?
No, I don't think it is a good solution, as git protocol is by design
anonymous and unauthenticated.
To enable push via git protocol, you have to enable 'receive-pack'
service for git-daemon (the --enable=<service> option).
>
> I would appreciate any recommendation about such set up and any links
> to corresponding docs.
You would probably want to use some tool to manage git repositories,
like
* Gitosis (in Python, requires setuptools),
* Gitolite (in Perl),
* SCuMD (in Java),
or even
* ssh_acl
I think Gitosis is most commonly used tool, see links in
http://git.or.cz/gitwiki/InterfacesFrontendsAndTools and
http://git.or.cz/gitwiki/BlogPosts pages on git wiki.
There are also full-fledged git hosting solutions, usually with web
interface to git repositories administration:
* GitHub:FI (proprietary, non-free)
* Gitorious (Ruby on Rails)
* InDefero (PHP, clone of Google Code)
* Girocco (Perl + bash, used by http://repo.or.cz)
There are also tools such as repo and Gerrit from Android project
(Gerrit is a review board).
Also, depending on workflow used, you might not need for anyone beside
project maintainer to have push access to public repository;
maintainer would process pull requests from co-developers, from their
per-developer forks.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ 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