* 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
* Re: Git push over git protocol for corporate environment
From: David Brown @ 2009-09-30 23:23 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git@vger.kernel.org
In-Reply-To: <76c5b8580909301613m283c4bfdne8de449ca0fd0987@mail.gmail.com>
On Wed, Sep 30, 2009 at 04:13:23PM -0700, Eugene Sajine wrote:
> 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?
You can pass --enable=receive-pack but it probably isn't what you
want. Anybody can write anything, anywhere with that, and more
importantly, anybody can delete anything.
When we started with git, we had a single machine that housed the
repos. It ran a read-only git server, and people used ssh to
push to it. It doesn't require accounts on the machine, but you
can use git-shell to restrict access. This is probably a good
way to start out.
Eventually, it's possible to realize that there doesn't need to
be _the_ central server. There can be several, and different
people in charge of different parts. Here at least, people never
really adapted to this model.
We're now primarily using Gerrit, but that's a larger step from
process change from CVS.
David Brown
^ 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-09-30 23:16 UTC (permalink / raw)
To: Mark Struberg; +Cc: Shawn O. Pearce, Jonas Fonseca, Robin Rosenberg, git
In-Reply-To: <949779.47404.qm@web27804.mail.ukl.yahoo.com>
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
----------------------------------------------------------
^ permalink raw reply
* Git push over git protocol for corporate environment
From: Eugene Sajine @ 2009-09-30 23:13 UTC (permalink / raw)
To: git
First of all thanks to everybody for an amazing tool! I’m a big fan of
it, so I’m trying to get rid of CVS in my company and migrate to Git.
We are working in, I would say, standard corporate environment, so all
development is in internal network. We have multiple offices in
different countries. Currently as I said we are using CVS (don’t
ask!;))
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?
I would appreciate any recommendation about such set up and any links
to corresponding docs.
Thank you,
Eugene
^ 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-09-30 23:13 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Jonas Fonseca, Robin Rosenberg, git, Jason van Zyl
In-Reply-To: <20090930211646.GM14660@spearce.org>
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.
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
>
^ permalink raw reply
* Re: [PATCH] Documentation - pt-BR.
From: Thiago Farina @ 2009-09-30 22:18 UTC (permalink / raw)
To: git
In-Reply-To: <1253730339-11146-1-git-send-email-tfransosi@gmail.com>
Ping
^ permalink raw reply
* Re: Deciding between Git/Mercurial
From: Daniel Barkalow @ 2009-09-30 22:05 UTC (permalink / raw)
To: Matthias Andree; +Cc: newsgroups, git
In-Reply-To: <4AC33C56.8060202@gmx.de>
On Wed, 30 Sep 2009, Matthias Andree wrote:
> Anteru schrieb:
>
> > First of all, what's the matter with git and Windows, is there some
> > long-term commitment to make git work on Windows as well as on Linux?
> > I'm using msysgit on Windows, and personally I'm happy with it, but my
> > co-workers constantly nag that Mercurial has superior portability ...
>
> That tale is told all over, but that doesn't make it truer. I've never had
> issues getting a Cygwin version of git to work properly (haven't tried the
> msysgit or jgit variants, never felt the need), and integration went smooth.
Git works fine under Windows for people who use Cygwin. Portability to
Windows is more about working for users who don't use a shell of any sort
or the "Run..." dialog. I don't know how Mercurial does on that metric,
anyway, but it's a lot more meaningful that the question of whether the
software works in your POSIX environment when the underlying kernel is not
very suitable.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: git svn's performance on cloning mono's branches/tags...
From: Hin-Tak Leung @ 2009-09-30 22:04 UTC (permalink / raw)
To: Eric Wong; +Cc: Andreas Ericsson, git
In-Reply-To: <20090702081615.GB11119@dcvr.yhbt.net>
On Thu, Jul 2, 2009 at 9:16 AM, Eric Wong <normalperson@yhbt.net> wrote:
> Hin-Tak Leung <hintak.leung@gmail.com> wrote:
>> On Sat, Jun 27, 2009 at 2:17 AM, Hin-Tak Leung<hintak.leung@gmail.com> wrote:
>>
>> > the tags, branches, url entries are effectively the same, I think - so
>> > the main difference is using trunk instead of fetch.
>> > Why does it make any difference? The example at the bottom of
>> > git-svn's man page uses the trunk notation. Maybe it should be
>> > changed?
>>
>> To answer my question - I think the man page should be updated.
>
> Somebody actually fixed it a while back:
>
> commit 0e5e69a355b7bdd1af6ca33ac7ee35299bda368e
> Author: Wesley J. Landaker <wjl@icecavern.net>
> Date: Wed Apr 1 16:05:01 2009 -0600
>
> Documentation: git-svn: fix trunk/fetch svn-remote key typo
>
>
> As far as performance goes, SVN's flexibility of tagging and having
> multiple subprojects interacts quite badly with git svn's --stdlayout
> behavior.
>
> With --stdoulayout, git svn supports tags/branches that are directly
> descended from the top-level of trunk:
>
> svn cp $root/trunk $root/tags/0.1.0
>
> However, it looks like mono does things like this:
>
> svn cp $root/trunk/mono $root/tags/mono-0.1.0
>
> And when git svn sees that $root/tags/mono-0.1.0's parent is
> $root/trunk/mono and not $root/trunk (which it's actually following),
> it will try to fetch the complete history of $root/trunk/mono
> ($root/trunk may not contain all the history $root/trunk/mono contained,
> either).
>
> --
> Eric Wong
>
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?)
^ 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: Shawn O. Pearce @ 2009-09-30 21:16 UTC (permalink / raw)
To: Mark Struberg; +Cc: Jonas Fonseca, Robin Rosenberg, git, Jason van Zyl
In-Reply-To: <287437.36328.qm@web27806.mail.ukl.yahoo.com>
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.
^ permalink raw reply
* Redundant merges?
From: skillzero @ 2009-09-30 21:15 UTC (permalink / raw)
To: git
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.
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?
^ permalink raw reply
* Re: How can I download a git commit as a diff patch?
From: Lennart Sorensen @ 2009-09-30 21:07 UTC (permalink / raw)
To: Jakub Narebski
Cc: Alejandro Riveira Fernández, Randy Dunlap, Andy,
linux-kernel, git
In-Reply-To: <200909302240.17729.jnareb@gmail.com>
On Wed, Sep 30, 2009 at 10:40:16PM +0200, Jakub Narebski wrote:
> You can specify parent explicitely: "git diff <rev>^1 <rev>" for diff
> to first parent, e.g. "git diff HEAD^ HEAD".
>
> Just so you know that this single diff is not enough to redo a merge.
> It is only partial information.
Yes certainly in some cases. Often you can pick specific patches and
a few patches they depend on to try and fix something, but for bigger
changes it doesn't work. I am actually surprised it has been this long
before I ever saw one of these combined diff's. I must have been lucky
so far.
> BTW. there is also "git diff-tree -m <rev>") to show diff to *all*
> parents at once:
>
> -m By default, `git-diff-tree --stdin` does not show differences for
> merge commits. With this flag, it shows differences to that commit
> from all of its parents. See also `-c`.
I will have to try that one out.
--
Len Sorensen
^ permalink raw reply
* Re: [PATCH v2] send-email: fix mutt regex for grouped aliases
From: Eric Wong @ 2009-09-30 20:55 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Junio C Hamano, Jeff King
In-Reply-To: <1254322176-4561-1-git-send-email-felipe.contreras@gmail.com>
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>
> ---
> git-send-email.perl | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/git-send-email.perl b/git-send-email.perl
> index 0700d80..93b7ed2 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -401,7 +401,7 @@ my %aliases;
> my %parse_alias = (
> # multiline formats can be supported in the future
> mutt => sub { my $fh = shift; while (<$fh>) {
> - if (/^\s*alias\s+(\S+)\s+(.*)$/) {
> + if (/^\s*alias\s+(?:-group\s+\S+\s+)*(\S+)\s+(.*)$/) {
> my ($alias, $addr) = ($1, $2);
> $addr =~ s/#.*$//; # mutt allows # comments
> # commas delimit multiple addresses
> --
^ permalink raw reply
* Re: How can I download a git commit as a diff patch?
From: Jakub Narebski @ 2009-09-30 20:40 UTC (permalink / raw)
To: Lennart Sorensen
Cc: Alejandro Riveira Fernández, Randy Dunlap, Andy,
linux-kernel, git
In-Reply-To: <20090930202527.GB22159@csclub.uwaterloo.ca>
On Wed, 30 Sep 2009, Lennart Sorensen wrote:
> On Wed, Sep 30, 2009 at 01:10:51PM -0700, Jakub Narebski wrote:
> > Or better yet, if given installation of gitweb supports it, on the
> > 'patch' link just on the right of 'raw' view. Such patch can be
> > applied better by git-am (but both should work for GNU patch or
> > git-apply).
> >
> > Yes, by default for merges the 'commitdiff' view (and the 'raw'
> > version, i.e. 'commitdiff_plain' view) shows **combined** diff of
> > changes brought by merge (see git-diff manpage for details on this
> > format).
> >
> > For merge commit you have to choose which of parents you want to have
> > diff from. Go to 'commit' view, there in the header would be two or
> > more parents. Click on the 'diff' link beside chosen parent, check if
> > it is the diff you want to get, and then click on 'patch' (or 'raw')
> > link.
>
> Is there a git command to show me a diff I can use with patch if I want to
> select a given patch as long as I can tell it which tree I want to follow?
> I don't care to use gitweb if I can do it with the command line git.
You can specify parent explicitely: "git diff <rev>^1 <rev>" for diff
to first parent, e.g. "git diff HEAD^ HEAD".
>
> git show obviously shows the git combined diff format, at least by default.
>
> Or is the idea of trying to use the diff from the merge commit just
> silly in the first place?
Just so you know that this single diff is not enough to redo a merge.
It is only partial information.
BTW. there is also "git diff-tree -m <rev>") to show diff to *all*
parents at once:
-m By default, `git-diff-tree --stdin` does not show differences for
merge commits. With this flag, it shows differences to that commit
from all of its parents. See also `-c`.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: How can I download a git commit as a diff patch?
From: Lennart Sorensen @ 2009-09-30 20:25 UTC (permalink / raw)
To: Jakub Narebski
Cc: Alejandro Riveira Fernández, Randy Dunlap, Andy,
linux-kernel, git
In-Reply-To: <m3tyyk9ost.fsf@localhost.localdomain>
On Wed, Sep 30, 2009 at 01:10:51PM -0700, Jakub Narebski wrote:
> Or better yet, if given installation of gitweb supports it, on the
> 'patch' link just on the right of 'raw' view. Such patch can be
> applied better by git-am (but both should work for GNU patch or
> git-apply).
>
> Yes, by default for merges the 'commitdiff' view (and the 'raw'
> version, i.e. 'commitdiff_plain' view) shows **combined** diff of
> changes brought by merge (see git-diff manpage for details on this
> format).
>
> For merge commit you have to choose which of parents you want to have
> diff from. Go to 'commit' view, there in the header would be two or
> more parents. Click on the 'diff' link beside chosen parent, check if
> it is the diff you want to get, and then click on 'patch' (or 'raw')
> link.
Is there a git command to show me a diff I can use with patch if I want to
select a given patch as long as I can tell it which tree I want to follow?
I don't care to use gitweb if I can do it with the command line git.
git show obviously shows the git combined diff format, at least by default.
Or is the idea of trying to use the diff from the merge commit just
silly in the first place?
--
Len Sorensen
^ permalink raw reply
* [PATCH] gitweb: Do not show 'patch' link in 'commit' view for merges
From: Jakub Narebski @ 2009-09-30 20:21 UTC (permalink / raw)
To: git
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.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Just noticed this issue, thanks indirectly to
"Re: How can I download a git commit as a diff patch?"
thread.
This is conservative change: perhaps we could extend 'patch' view to
work also for root commit...
gitweb/gitweb.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 24b2193..fb045a1 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -5328,7 +5328,7 @@ sub git_commit {
} @$parents ) .
')';
}
- if (gitweb_check_feature('patches')) {
+ if (gitweb_check_feature('patches') && @$parents == 1) {
$formats_nav .= " | " .
$cgi->a({-href => href(action=>"patch", -replay=>1)},
"patch");
^ permalink raw reply related
* Re: How can I download a git commit as a diff patch?
From: Jakub Narebski @ 2009-09-30 20:10 UTC (permalink / raw)
To: Alejandro Riveira Fernández
Cc: Lennart Sorensen, Randy Dunlap, Andy, linux-kernel, git
In-Reply-To: <20090930213809.71c2a8e8@varda>
Alejandro Riveira Fernández <ariveira@gmail.com> writes:
> El Wed, 30 Sep 2009 15:00:14 -0400
>
> CCing git@vger.kernel.org ??
>
> lsorense@csclub.uwaterloo.ca (Lennart Sorensen) escribió:
>
>> On Wed, Sep 30, 2009 at 08:55:00AM -0700, Randy Dunlap wrote:
>>> On Wed, 30 Sep 2009 10:44:10 -0500 Andy wrote:
>>>
>>>> I just want to down a particular git commit as a patch, not a git commit or
>>>> anything. Yes, I can see the diffs on the web, but unless I am missing
>>>> something all are in unless html formats for me. And cut and past from the
>>>> web page does not help either because some lines get mangled. Is there some
>>>> site, or git itself, that would allow be to get the git commit as a simple
>>>> patch?
>>>
>>> Look at the commitdiff using the web interface, then click on "raw" near
>>> the upper left corner.
Or better yet, if given installation of gitweb supports it, on the
'patch' link just on the right of 'raw' view. Such patch can be
applied better by git-am (but both should work for GNU patch or
git-apply).
>>
>> Of course some git diff's are not in a format that patch will like as
>> far as I can tell.
>>
>> For example commit 6cdee2f96a97f6da26bd3759c3f8823332fbb438 which has
>> stuff like:
>> diff --cc drivers/net/ixp2000/ixpdev.c
>> index 588b44d,92fb823..1272434
>> --- a/drivers/net/ixp2000/ixpdev.c
>> +++ b/drivers/net/ixp2000/ixpdev.c
>> @@@ -67,9 -68,9 +68,9 @@@ static int ixpdev_xmit(struct sk_buff *
>> ip->tx_queue_entries++;
>> if (ip->tx_queue_entries == TX_BUF_COUNT_PER_CHAN)
>> netif_stop_queue(dev);
>> - local_irq_enable();
>> + local_irq_restore(flags);
>>
>> - return 0;
>> + return NETDEV_TX_OK;
>> }
>>
>>
>>
>> Ehm, what does that mean? patch doesn't like it.
>>
>> Do git merges cause weird diffs?
Yes, by default for merges the 'commitdiff' view (and the 'raw'
version, i.e. 'commitdiff_plain' view) shows **combined** diff of
changes brought by merge (see git-diff manpage for details on this
format).
For merge commit you have to choose which of parents you want to have
diff from. Go to 'commit' view, there in the header would be two or
more parents. Click on the 'diff' link beside chosen parent, check if
it is the diff you want to get, and then click on 'patch' (or 'raw')
link.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ 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-09-30 19:51 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Robin Rosenberg, git, spearce, Jason van Zyl
In-Reply-To: <2c6b72b30909280546l62a6ef9cm21112ca071cdef4c@mail.gmail.com>
Hi Jonas!
answers inside
LieGrue,
strub
--- On Mon, 9/28/09, Jonas Fonseca <jonas.fonseca@gmail.com> wrote:
> From: Jonas Fonseca <jonas.fonseca@gmail.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: "Robin Rosenberg" <robin.rosenberg.lists@dewire.com>, git@vger.kernel.org, spearce@spearce.org, "Jason van Zyl" <jvanzyl@sonatype.com>
> Date: Monday, September 28, 2009, 2:46 PM
> On Sat, Sep 26, 2009 at 15:50, Mark
> Struberg <struberg@yahoo.de>
> wrote:
> > Hi Robin!
> >
> > a) Actually git-format-patch only created 0001-0009 so
> there is no 0/9.
>
> For larger patch series, it is good practice (at least on
> git@vger) to
> provide a "cover letter" (see git-format-patch
> --cover-letter) to give
> reviewers of the patch series an idea of what code is
> touched and for
> you to give additional information, such as the state of
> the patch
> series.
txs 4 pointing this out.
>
> > b) 2/9 is the actual directory structure moving. I
> received it, but since it is pretty large (330k already with
> -M -l0) it might got filtered out?
> > If so then may I ask you to please fetch it from http://github.com/sonatype/JGit branch 'mavenize'? It
> has the same content I sent to the list.
>
> Some general notes on the patch series. First, I am glad
> you posted it
> to have something to discuss and as I have stated in a
> private mail I
> am glad you are doing this. However, I also think it needs
> a lot more
> polish before being integrated.
>
> While I understand that you want to credit Jason for doing
> the initial
> probe into fully mavenizing JGit, I now think it is wrong
> to base the
> patch series on his patch. My first impression is that it
> 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?
> 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.
> After this comespatches
> which only touch pom.xml files. For example, move
> jgit-maven/jgit/pom.xml to the top-level pom.xml, extract
> relevant
> pieces to org.spearce.jgit/pom.xml and
> org.spearce.jgit.test/pom.xml,
> improving the pom.xml`s by adding checkstyle/<scm>
> integration, and
> mavenizing org.spearce.jgit.pgm/. The final and most
> invasive parts
> (renaming/(re)moving code/eclipse files etc) should come
> last!
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.
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.
> Taking this approach Robin and Spearce can start
> integrating initial
> patces and we can all start testing the "mavenization"
> sooner rather
> than after deciding how to rename things and whether or not
> to remove
> certain files.
>
> The above is a proposal and if you and other agree that it
> is the
> right approach _and_ you do not feel you have the time
> necessary to
> realize it, I am willing to work on it.
Any help is always welcome :)
^ 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