* 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
* Re: How can I download a git commit as a diff patch?
From: Alejandro Riveira Fernández @ 2009-09-30 19:38 UTC (permalink / raw)
To: Lennart Sorensen; +Cc: Randy Dunlap, Andy, linux-kernel, git
In-Reply-To: <20090930190014.GA22161@csclub.uwaterloo.ca>
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.
>
> 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?
>
^ permalink raw reply
* Re: Alles wird Git, Berlin, Oct 3rd, 2009
From: Heiko Voigt @ 2009-09-30 19:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0909250810270.4985@pacific.mpi-cbg.de>
Hello,
On Fri, Sep 25, 2009 at 08:19:44AM +0200, Johannes Schindelin wrote:
> as some of you already know, I will be unable to Git Together with other
> Gits in California this year. So the only version of such a Git Together
> I will have this year is the Berlin one.
Just announcing that Jens Lehmann and me will also come. Just added
us to the wiki page. What about important stuff like coffee during the
day? Is there access to such things nearby or is it better to bring
everything needed?
cheers Heiko
^ permalink raw reply
* Re: Compact view of history in gitk
From: Dirk Süsserott @ 2009-09-30 18:41 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Johannes Sixt, Yakup Akbay, git
In-Reply-To: <46a038f90909290821g4bb9cecewace8c8a516b74c78@mail.gmail.com>
Am 29.09.2009 17:21 schrieb Martin Langhoff:
> On Tue, Sep 29, 2009 at 2:07 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
>> I think, --simplify-by-decoration comes close, even though it may not be
>> 100% what you describe.
>
> That is awesome.
>
> Awesomer would be teaching gitk to expand (un-simplify) parts of it.
> Probably a pig of a project to do though :-/
>
>
>
> m
I'm proud to tell that one might also use gitk's
dialog 'View -> Edit view... (F4)' and then activate
the 'Simple history' checkbox. :-)
Gitk knows about that since Git v1.6.4-rc0.
However, it doesn't do the awesomer part.
Dirk
^ permalink raw reply
* Re: [PATCH 2/2] remove NORETURN from function pointers
From: Erik Faye-Lund @ 2009-09-30 18:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Erik Faye-Lund, Jeff King, git, Johannes Sixt
In-Reply-To: <40aa078e0909250656j4b791a99naf632b5b8d8e1038@mail.gmail.com>
On Fri, Sep 25, 2009 at 3:56 PM, Erik Faye-Lund
<kusmabite@googlemail.com> wrote:
>> Anything happened to this series?
>
> No, I'm sorry for not updating. I'm currently on vacation, and I
> didn't get time to fix it up before going, due to my dayjob. I'll pick
> it up again as soon as I get back home, in a bit more than a week.
Alright, I fond time to fix this up a little earlier than I expected.
A new round had been sent to the mailing list.
--
Erik "kusma" Faye-Lund
kusmabite@gmail.com
(+47) 986 59 656
^ permalink raw reply
* [PATCH 2/2] add NORETURN_PTR for function pointers
From: Erik Faye-Lund @ 2009-09-30 18:05 UTC (permalink / raw)
To: git; +Cc: msysgit, gitster, Erik Faye-Lund
In-Reply-To: <1254333950-2440-1-git-send-email-kusmabite@gmail.com>
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.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
git-compat-util.h | 4 +++-
usage.c | 6 +++---
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index 33dd4f3..ac7cc66 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -169,8 +169,10 @@ extern char *gitbasename(char *);
#ifdef __GNUC__
#define NORETURN __attribute__((__noreturn__))
+#define NORETURN_PTR __attribute__((__noreturn__))
#else
#define NORETURN
+#define NORETURN_PTR
#ifndef __attribute__
#define __attribute__(x)
#endif
@@ -183,7 +185,7 @@ extern NORETURN void die_errno(const char *err, ...) __attribute__((format (prin
extern int error(const char *err, ...) __attribute__((format (printf, 1, 2)));
extern void warning(const char *err, ...) __attribute__((format (printf, 1, 2)));
-extern void set_die_routine(NORETURN void (*routine)(const char *err, va_list params));
+extern void set_die_routine(NORETURN_PTR void (*routine)(const char *err, va_list params));
extern int prefixcmp(const char *str, const char *prefix);
extern time_t tm_to_time_t(const struct tm *tm);
diff --git a/usage.c b/usage.c
index 0555ce6..c488f3a 100644
--- a/usage.c
+++ b/usage.c
@@ -36,12 +36,12 @@ static void warn_builtin(const char *warn, va_list params)
/* If we are in a dlopen()ed .so write to a global variable would segfault
* (ugh), so keep things static. */
-static NORETURN void (*usage_routine)(const char *err) = usage_builtin;
-static NORETURN void (*die_routine)(const char *err, va_list params) = die_builtin;
+static NORETURN_PTR void (*usage_routine)(const char *err) = usage_builtin;
+static NORETURN_PTR void (*die_routine)(const char *err, va_list params) = die_builtin;
static void (*error_routine)(const char *err, va_list params) = error_builtin;
static void (*warn_routine)(const char *err, va_list params) = warn_builtin;
-void set_die_routine(NORETURN void (*routine)(const char *err, va_list params))
+void set_die_routine(NORETURN_PTR void (*routine)(const char *err, va_list params))
{
die_routine = routine;
}
--
1.6.4.msysgit.0.17.g82372.dirty
^ permalink raw reply related
* [PATCH 1/2] increase portability of NORETURN declarations
From: Erik Faye-Lund @ 2009-09-30 18:05 UTC (permalink / raw)
To: git; +Cc: msysgit, gitster, Erik Faye-Lund
Some compilers (including at least MSVC) supports NORETURN
on function declarations, but only before the function-name.
This patch makes it possible to define NORETURN to something
meaningful for those compilers.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
git-compat-util.h | 8 ++++----
index-pack.c | 4 ++--
usage.c | 6 +++---
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index 9f941e4..33dd4f3 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -177,13 +177,13 @@ extern char *gitbasename(char *);
#endif
/* General helper functions */
-extern void usage(const char *err) NORETURN;
-extern void die(const char *err, ...) NORETURN __attribute__((format (printf, 1, 2)));
-extern void die_errno(const char *err, ...) NORETURN __attribute__((format (printf, 1, 2)));
+extern NORETURN void usage(const char *err);
+extern NORETURN void die(const char *err, ...) __attribute__((format (printf, 1, 2)));
+extern NORETURN void die_errno(const char *err, ...) __attribute__((format (printf, 1, 2)));
extern int error(const char *err, ...) __attribute__((format (printf, 1, 2)));
extern void warning(const char *err, ...) __attribute__((format (printf, 1, 2)));
-extern void set_die_routine(void (*routine)(const char *err, va_list params) NORETURN);
+extern void set_die_routine(NORETURN void (*routine)(const char *err, va_list params));
extern int prefixcmp(const char *str, const char *prefix);
extern time_t tm_to_time_t(const struct tm *tm);
diff --git a/index-pack.c b/index-pack.c
index 340074f..b4f8278 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -206,8 +206,8 @@ static void parse_pack_header(void)
use(sizeof(struct pack_header));
}
-static void bad_object(unsigned long offset, const char *format,
- ...) NORETURN __attribute__((format (printf, 2, 3)));
+static NORETURN void bad_object(unsigned long offset, const char *format,
+ ...) __attribute__((format (printf, 2, 3)));
static void bad_object(unsigned long offset, const char *format, ...)
{
diff --git a/usage.c b/usage.c
index b6aea45..0555ce6 100644
--- a/usage.c
+++ b/usage.c
@@ -36,12 +36,12 @@ static void warn_builtin(const char *warn, va_list params)
/* If we are in a dlopen()ed .so write to a global variable would segfault
* (ugh), so keep things static. */
-static void (*usage_routine)(const char *err) NORETURN = usage_builtin;
-static void (*die_routine)(const char *err, va_list params) NORETURN = die_builtin;
+static NORETURN void (*usage_routine)(const char *err) = usage_builtin;
+static NORETURN void (*die_routine)(const char *err, va_list params) = die_builtin;
static void (*error_routine)(const char *err, va_list params) = error_builtin;
static void (*warn_routine)(const char *err, va_list params) = warn_builtin;
-void set_die_routine(void (*routine)(const char *err, va_list params) NORETURN)
+void set_die_routine(NORETURN void (*routine)(const char *err, va_list params))
{
die_routine = routine;
}
--
1.6.4.msysgit.0.17.g82372.dirty
^ permalink raw reply related
* Re: [PATCH] send-email: fix mutt regex for grouped aliases
From: Felipe Contreras @ 2009-09-30 14:50 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano, Eric Wong
In-Reply-To: <20090930112833.GA4984@sigio.peff.net>
On Wed, Sep 30, 2009 at 2:28 PM, Jeff King <peff@peff.net> wrote:
> On Wed, Sep 30, 2009 at 03:08:43AM +0300, Felipe Contreras wrote:
>
>> For example:
>> alias -group friends foo Foo Bar <foo@bar.com>
>
> Hmm. If I am reading the mutt docs correctly, is it also legal to have:
>
> alias -group group1 -group group2 foo Foo Bar <foo@bar.com>
>
> ?
>
> Which would need just:
>
>> - if (/^\s*alias\s+(\S+)\s+(.*)$/) {
>> + if (/^\s*alias\s+(?:-group\s+\S+\s+)?(\S+)\s+(.*)$/) {
>
> (?:-group\s+\S+\s+)*
>
> I think.
Yeap, that is correct. Resent.
--
Felipe Contreras
^ permalink raw reply
* [PATCH v2] send-email: fix mutt regex for grouped aliases
From: Felipe Contreras @ 2009-09-30 14:49 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Eric Wong, Jeff King, Felipe Contreras
In-Reply-To: <20090930112833.GA4984@sigio.peff.net>
For example:
alias -group friends foo Foo Bar <foo@bar.com>
Comments by Jeff King.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
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
--
1.6.5.rc2.1.g9071
^ 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