* 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
* 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
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