* Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case
From: Sverre Rabbelier @ 2009-09-04 17:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, Johannes Schindelin, git
In-Reply-To: <7vy6ouk4io.fsf@alter.siamese.dyndns.org>
Heya,
On Fri, Sep 4, 2009 at 19:23, Junio C Hamano<gitster@pobox.com> wrote:
> In short, from where I sit, I do not see much disagreement in the
> semantics and in the future direction between what Dscho is saying (unless
> I again misunderstood what he said) and what this round wants to bring.
I think Dscho's main worry matches what I asked about earlier, will we
be able to say "hg://example.org" or not.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case
From: Johannes Schindelin @ 2009-09-04 18:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, Sverre Rabbelier, git
In-Reply-To: <7vy6ouk4io.fsf@alter.siamese.dyndns.org>
Hi,
On Fri, 4 Sep 2009, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > It turns out that the method used to form URLs that use a helper
> > doesn't generalize well to other cases, because it interferes with the
> > ssh-style locations. Instead, some different mechanism needs to be
> > made up to handle arbitrary handlers that git doesn't know about.
> > Since we want to keep supporting "http://something", that'll have to
> > be a special case anyway, and so we might as well handle it by having
> > git know what helpers to use for things that we've always supported,
> > and use a single descriptive name for the helper that handles that
> > collection of URLs.
> >
> > As of this version, the idea is that there will be three ways helpers
> > get selected:
> >
> > - git selects a helper based on the URL being something traditionally
> > supported internally; that is, git recognizes the URL and knows
> > what to run, if possible, to handle it
> >
> > - git uses the "vcs" option if it is set
> >
> > - something with the URL that we don't understand well enough yet to
> > design, but which doesn't seem to be possible to fit in as a single
> > rule with the first item.
>
> Thanks for a clear description.
>
> I do not see that there is much difference between the above description
> and what Dscho is advocating, and I do not see anything to get excited
> about as Dscho seems to do.
I mainly take exception at complicating things with a "vcs" config
variable.
The way you describe it, I like it, as I do not see any mention of said
config variable there.
If you allow "git clone <URL>" for foreign vcs URLs, you do not need the
"vcs" variable. If you require that variable, you cannot allow an easy
clone, and you will earn my opposition.
Ciao,
Dscho
^ permalink raw reply
* Re: Commit to wrong branch. How to fix?
From: Howard Miller @ 2009-09-04 18:01 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git@vger.kernel.org
In-Reply-To: <4AA13DF4.4050604@drmicha.warpmail.net>
Hi Michael,
Thanks for your help.
I had modified a few files and then done a 'git commit -a'. It was
only after this that I did a status and realised that I had switched
to a different branch (and forgotten). Unfortunately the branch I
switched to tracks a remote that is my stable release so I'm a bit
precious about it. If I forget again and push it, I'm in trouble :-)
Yes, I have done that before!!
Howard
2009/9/4 Michael J Gruber <git@drmicha.warpmail.net>:
> Howard Miller venit, vidit, dixit 04.09.2009 17:54:
>> I commited to the wrong branch and I can't figure out what to do. To
>> make matters worse I then did 'git reset HEAD^' which has made things
>> much worse. It didn't remove the commit and now I can't change
>> branches. I'm utterly confused. Any help much appreciated!
>>
>> Moral - use git status liberally and read it carefully before doing
>> anything. A 'git undo" command would be great is someone is feeling
>> generous :-)
>
> Whatever happens, don't panic ;)
>
> Let's say "geesh" is the branch on which you committed by mistake, and
> which you have reset.
>
> git reflog geesh
>
> which show you what has happened to that branch lately. In particular,
> it will list the "lost" commit. (Most probably it is the same as geesh@{1}.)
>
> git tag sigh sha1ofthatcommit
>
> will assign the tag "sigh", so that it won't get lost by doing "git gc"
> or such. Now you can lean back!
>
> Next step is committing "sigh" to the right branch. Depends on how you
> arrived at that commit. Did you commit the complete tree you wanted, or
> did you apply a change to geesh which you rather had wanted applied to
> some other branch?
>
> Michael
>
^ permalink raw reply
* Re: Commit to wrong branch. How to fix?
From: Howard Miller @ 2009-09-04 18:03 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git@vger.kernel.org
In-Reply-To: <4AA13DF4.4050604@drmicha.warpmail.net>
Sorry... meant to add. When I do a 'git log' on the current (wrong
branch) the commit I made is still at the top of the list. I must
admit I don't understand what 'reflog' is (more reading) - not heard
of that before. I did ONE commit and ONE reset and then decided not to
touch it again :-)
Howard
2009/9/4 Michael J Gruber <git@drmicha.warpmail.net>:
> Howard Miller venit, vidit, dixit 04.09.2009 17:54:
>> I commited to the wrong branch and I can't figure out what to do. To
>> make matters worse I then did 'git reset HEAD^' which has made things
>> much worse. It didn't remove the commit and now I can't change
>> branches. I'm utterly confused. Any help much appreciated!
>>
>> Moral - use git status liberally and read it carefully before doing
>> anything. A 'git undo" command would be great is someone is feeling
>> generous :-)
>
> Whatever happens, don't panic ;)
>
> Let's say "geesh" is the branch on which you committed by mistake, and
> which you have reset.
>
> git reflog geesh
>
> which show you what has happened to that branch lately. In particular,
> it will list the "lost" commit. (Most probably it is the same as geesh@{1}.)
>
> git tag sigh sha1ofthatcommit
>
> will assign the tag "sigh", so that it won't get lost by doing "git gc"
> or such. Now you can lean back!
>
> Next step is committing "sigh" to the right branch. Depends on how you
> arrived at that commit. Did you commit the complete tree you wanted, or
> did you apply a change to geesh which you rather had wanted applied to
> some other branch?
>
> Michael
>
^ permalink raw reply
* Re: tracking branch for a rebase
From: Jeff King @ 2009-09-04 18:18 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Pete Wyckoff, git
In-Reply-To: <4AA124DD.1030208@drmicha.warpmail.net>
On Fri, Sep 04, 2009 at 04:31:57PM +0200, Michael J Gruber wrote:
> Making [rebase against upstream] the default for rebase without
> arguments may meet some objections (oh no, I didn't mean to rebase),
> but I guess it's worth trying.
FWIW, that has been a patch I have been meaning to do for a while. I
don't see it as any more error-prone than "git pull" without arguments.
In either case, you can always recover with a reset from the reflog.
The biggest question is whether it should respect branch.*.merge, or
just branch.*.rebase (I never use the latter simply because I never use
"git pull", but I think it is probably reasonable to restrict it to
cases where you said you are interested in rebasing in general).
-Peff
^ permalink raw reply
* Re: [JGIT] Request for help
From: Jonas Fonseca @ 2009-09-04 18:50 UTC (permalink / raw)
To: Mark Struberg; +Cc: Douglas Campos, git, Gabe McArthur
In-Reply-To: <658028.86274.qm@web27804.mail.ukl.yahoo.com>
On Fri, Sep 4, 2009 at 13:28, Mark Struberg<struberg@yahoo.de> wrote:
> Hi!
>
> Work has been done at
>
> http://github.com/sonatype/JGit/tree/mavenize
>
> Please feel free to pull/fork and share your changes! I'd be happy to pull it in.
IMO, there are a lot of things that can be squashed together and
cleaned up. I know that you advocated for incremental introduction,
but it seems wrong to for example add a file and then completely
reformat it a few commits later. The same thing with the .gitignore
fixes in step 5.
Some comments ... Some of them I initially entered in github's
codereview, but I ended up writing it all here.
Commit: "mavenizing step 1: moved over the initial poms from Jasons branch"
* Please always add an empty line between the subject and the body
of the commit message. Like this:
mavenizing step 1: moved over the initial poms from Jasons branch
Signed-off-by: Mark Struberg >struberg@yahoo.de>
* The .gitignore pattern could be further limited to "target/" ...
but you seem to change this to /target later.
In org.spearce.jgit/pom.xml:
* The use of maven-surefire-plugin should be removed. This module
does not have any tests.
* Shouldn't we retain the original ${groupId}:${artifactId} naming
convention, being org.spearce:jgit?
In org.spearce.jgit.test/pom.xml:
* Dependency on jsch is unecessary since it is derived from
org.spearce.jgit.
* Maybe name as org.spearce:jgit-test?
In org.spearce.jgit.pgm/pom.xml:
* Maybe name as org.spearce:jgit-pgm?
Commit: "mavenizing step 2: move the core libs from src to src/main/java"
* Please also add an empty line to this commit message.
* You might as well squash the whitespace fixes into the first commit.
Commit: "mavenizing step 3: moving all core tests into the core module"
* The commit message wrongly states:
org.spearce.jgit.test/tst/ -> org.spearce.jgit/src/test/java/tst/
Should be:
org.spearce.jgit.test/tst/ -> org.spearce.jgit/src/test/java/
Commit: "mavenizing step 4: moving some license files and META-INF"
* Shouldn't the commit message rather say "remove JSch"?
Then the moving of META-INF can be put in its own commit.
* The new NOTICE file has a few typos and the info could fit into the README
Then I got a bit lost in a huge reformatting.
--
Jonas Fonseca
^ permalink raw reply
* Re: Commit to wrong branch. How to fix?
From: Jakub Narebski @ 2009-09-04 18:51 UTC (permalink / raw)
To: Howard Miller; +Cc: Michael J Gruber, git@vger.kernel.org
In-Reply-To: <26ae428a0909041103p4ecba8efvff6223f902e14f1a@mail.gmail.com>
Howard Miller <howardsmiller@googlemail.com> writes:
> I must admit I don't understand what 'reflog' is (more reading) - not heard
> of that before.
I'll try to explain it with some ASCII-art.
Let's say that you had the following situation:
...---A---B---C <-- foo <--- HEAD
Current branch is named 'foo', and three last commits on it are named
A, B, C.
Now you create new commit (I assume that you comitted unwanted
changes; the recipe would be different (much simpler) if you have
realized that you are on wrong branch[1] before committing)
[1] git aware shell prompt, countaing branch name, could help there
...---A---B---C---X <-- foo <--- HEAD
Reflog records that commit in 'foo' reflog and in HEAD reflog
foo@{0}: X
You have realized that you are on wrong branch, and you did
"git reset --hard HEAD^" (too early)
...---A---B---C <-- foo <--- HEAD
\
\-X
Reflog records that fact (it records where tip of branch was)
foo@{0}: C
foo@{1}: X
Then if you want to create new branch 'bar' with X, you would do
$ git checkout -b bar foo@{1}
If you wanted to have this commit on some other existing branch, let's
call it 'baz', you would do instead (I think):
$ git checkout baz
$ git cherry-pick foo@{1}
HTH (hope that helps).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [JGIT] Request for help
From: Mark Struberg @ 2009-09-04 18:54 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Douglas Campos, git, Gabe McArthur
In-Reply-To: <2c6b72b30909041150g6374be2ci4d36bd8ab0824a8d@mail.gmail.com>
doing a rebase -i with new stuff atm... ;)
LieGrue,
strub
--- On Fri, 9/4/09, Jonas Fonseca <jonas.fonseca@gmail.com> wrote:
> From: Jonas Fonseca <jonas.fonseca@gmail.com>
> Subject: Re: [JGIT] Request for help
> To: "Mark Struberg" <struberg@yahoo.de>
> Cc: "Douglas Campos" <douglas@theros.info>, git@vger.kernel.org, "Gabe McArthur" <gabriel.mcarthur@gmail.com>
> Date: Friday, September 4, 2009, 8:50 PM
> On Fri, Sep 4, 2009 at 13:28, Mark
> Struberg<struberg@yahoo.de>
> wrote:
> > Hi!
> >
> > Work has been done at
> >
> > http://github.com/sonatype/JGit/tree/mavenize
> >
> > Please feel free to pull/fork and share your changes!
> I'd be happy to pull it in.
>
> IMO, there are a lot of things that can be squashed
> together and
> cleaned up. I know that you advocated for incremental
> introduction,
> but it seems wrong to for example add a file and then
> completely
> reformat it a few commits later. The same thing with the
> .gitignore
> fixes in step 5.
>
> Some comments ... Some of them I initially entered in
> github's
> codereview, but I ended up writing it all here.
>
> Commit: "mavenizing step 1: moved over the initial poms
> from Jasons branch"
>
> * Please always add an empty line between the subject and
> the body
> of the commit message. Like this:
>
> mavenizing step 1: moved over the initial poms from
> Jasons branch
>
> Signed-off-by: Mark Struberg >struberg@yahoo.de>
>
> * The .gitignore pattern could be further limited to
> "target/" ...
> but you seem to change this to /target later.
>
> In org.spearce.jgit/pom.xml:
>
> * The use of maven-surefire-plugin should be
> removed. This module
> does not have any tests.
>
> * Shouldn't we retain the original
> ${groupId}:${artifactId} naming
> convention, being org.spearce:jgit?
>
> In org.spearce.jgit.test/pom.xml:
>
> * Dependency on jsch is unecessary since it
> is derived from
> org.spearce.jgit.
>
> * Maybe name as org.spearce:jgit-test?
>
> In org.spearce.jgit.pgm/pom.xml:
>
> * Maybe name as org.spearce:jgit-pgm?
>
> Commit: "mavenizing step 2: move the core libs from src to
> src/main/java"
>
> * Please also add an empty line to this commit message.
>
> * You might as well squash the whitespace fixes into the
> first commit.
>
> Commit: "mavenizing step 3: moving all core tests into the
> core module"
>
> * The commit message wrongly states:
> org.spearce.jgit.test/tst/ ->
> org.spearce.jgit/src/test/java/tst/
> Should be:
> org.spearce.jgit.test/tst/ ->
> org.spearce.jgit/src/test/java/
>
> Commit: "mavenizing step 4: moving some license files and
> META-INF"
>
> * Shouldn't the commit message rather say "remove JSch"?
> Then the moving of META-INF can be put in
> its own commit.
>
> * The new NOTICE file has a few typos and the info could
> fit into the README
>
> Then I got a bit lost in a huge reformatting.
>
> --
> Jonas Fonseca
>
^ permalink raw reply
* Re: tracking branch for a rebase
From: Björn Steinbrink @ 2009-09-04 18:59 UTC (permalink / raw)
To: Jeff King; +Cc: Michael J Gruber, Pete Wyckoff, git
In-Reply-To: <20090904181846.GC19093@coredump.intra.peff.net>
On 2009.09.04 14:18:46 -0400, Jeff King wrote:
> On Fri, Sep 04, 2009 at 04:31:57PM +0200, Michael J Gruber wrote:
>
> > Making [rebase against upstream] the default for rebase without
> > arguments may meet some objections (oh no, I didn't mean to rebase),
> > but I guess it's worth trying.
>
> FWIW, that has been a patch I have been meaning to do for a while. I
> don't see it as any more error-prone than "git pull" without arguments.
> In either case, you can always recover with a reset from the reflog.
Note that with:
branch.foo.remote = origin
branch.foo.merge = refs/heads/foo
"git pull --rebase" is not the same as:
"git fetch origin && git rebase origin/foo", but:
git fetch origin && git rebase --onto origin/foo $reflog_merge_base
Where $reflog_merge_base is the first merge base is found between the
current branch head, and the reflog entries for origin/foo.
Same deal for "git pull --rebase origin bla", which is not:
"git fetch origin bla && git rebase FETCH_HEAD", but:
git fetch origin && git rebase --onto FETCH_HEAD $reflog_merge_base
Where again $reflog_merge_base is found by looking at the reflog for
origin/foo.
It does that to try to automatically handle cases where upstream has
been rebased. I'm not completely sure whether I like or hate that.
Especially the "git pull --rebase <remote> <refspec>" case seems very
weird to me. And if "rebase" is to pickup the same default as "pull", I
guess it should also show the same behaviour, but just skips the "fetch"
part?
> The biggest question is whether it should respect branch.*.merge, or
> just branch.*.rebase (I never use the latter simply because I never use
> "git pull", but I think it is probably reasonable to restrict it to
> cases where you said you are interested in rebasing in general).
Hm, you'll probably want "git merge" to pickup the default as well then,
right? And that should only do so if branch.*.rebase is not set. So
effectively, you still have to use the right command, but can skip the
argument. Having to deal a lot with git-svn, I also regulary use its
"git svn rebase --local", which means "just rebase, don't fetch".
Now, basically "git svn rebase" is pretty much git-svn's "pull". Maybe
its idea could be taken, so we get "git pull --local" to just skip the
fetch part, but keep "git rebase" and "git merge" 'dumb', requiring
explicit arguments.
(In the past, I once argued for deprecating "pull", and having
merge/rebase doing the fetch as well, with a --local argument that stops
them from doing so. That was probably mostly due to the fact that I ran
into too many people that simply didn't understood that "git pull" is
not "svn up". I still kind of like the idea, but seeing just how often I
use rebase/merge with already fetched stuff, I can see how having to use
a --local flag with them all the time would be quite a PITA, but now,
having the --local flag for "pull" seems to make sense to me.)
Björn
^ permalink raw reply
* Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case
From: Daniel Barkalow @ 2009-09-04 19:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Sverre Rabbelier, git
In-Reply-To: <alpine.DEB.1.00.0909041930450.8306@pacific.mpi-cbg.de>
On Fri, 4 Sep 2009, Johannes Schindelin wrote:
> Hi,
>
> On Fri, 4 Sep 2009, Junio C Hamano wrote:
>
> > Daniel Barkalow <barkalow@iabervon.org> writes:
> >
> > > It turns out that the method used to form URLs that use a helper
> > > doesn't generalize well to other cases, because it interferes with the
> > > ssh-style locations. Instead, some different mechanism needs to be
> > > made up to handle arbitrary handlers that git doesn't know about.
> > > Since we want to keep supporting "http://something", that'll have to
> > > be a special case anyway, and so we might as well handle it by having
> > > git know what helpers to use for things that we've always supported,
> > > and use a single descriptive name for the helper that handles that
> > > collection of URLs.
> > >
> > > As of this version, the idea is that there will be three ways helpers
> > > get selected:
> > >
> > > - git selects a helper based on the URL being something traditionally
> > > supported internally; that is, git recognizes the URL and knows
> > > what to run, if possible, to handle it
> > >
> > > - git uses the "vcs" option if it is set
> > >
> > > - something with the URL that we don't understand well enough yet to
> > > design, but which doesn't seem to be possible to fit in as a single
> > > rule with the first item.
> >
> > Thanks for a clear description.
> >
> > I do not see that there is much difference between the above description
> > and what Dscho is advocating, and I do not see anything to get excited
> > about as Dscho seems to do.
>
> I mainly take exception at complicating things with a "vcs" config
> variable.
>
> The way you describe it, I like it, as I do not see any mention of said
> config variable there.
>
> If you allow "git clone <URL>" for foreign vcs URLs, you do not need the
> "vcs" variable. If you require that variable, you cannot allow an easy
> clone, and you will earn my opposition.
Some foreign vcses, including the only one I ever personally use, do not
have URLs, and require a bunch of options and paths to specify a
repository. I don't want to have to use:
url = p4://rsh:ssh+-q+-a+-x+-l+p4ssh+-q+-x+perforce+%2Fbin%2Ftrue//projects/foo/bar-1.0/...,//projects/foo/bar-1.1/...
(actually, I don't even know what the normal thing is for a URL for
something that's split between multiple locations, or how URLs handle
"servers" that are arbitrary commands including options which make a
connection to the server)
For cases where the foreign vcs has something to put in the "url" spot,
you don't need to set "vcs". In fact, you are only allowed to set one or
the other of "vcs" and "url" with my current version. What you're
interested in is explicitly left for later, when we have a prototype
helper for such a foreign vcs and can try it out with potential users.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case
From: Sverre Rabbelier @ 2009-09-04 19:35 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <alpine.LNX.2.00.0909041429540.28290@iabervon.org>
Heya,
On Fri, Sep 4, 2009 at 21:05, Daniel Barkalow<barkalow@iabervon.org> wrote:
> Some foreign vcses, including the only one I ever personally use, do not
> have URLs, and require a bunch of options and paths to specify a
> repository. I don't want to have to use:
>
> url = p4://rsh:ssh+-q+-a+-x+-l+p4ssh+-q+-x+perforce+%2Fbin%2Ftrue//projects/foo/bar-1.0/...,//projects/foo/bar-1.1/...
Btw, doesn't p4 have these config files that you can download that
contain the configuration? In that case
'p4://example.org/p4/main-development.configfile' would be very
convenient.
Regardless, I do think there should be some way to specify all this
outside of the url, but to me that's secondary. I think the primary
usecase is/should be cloning from some url in the form of
'hg://example.org/foo', rather than 'http://example.org/some-hg-repo'
or 'p4://.......', since those are both exceptions (the former being
an ambiguous url, and the latter being a non-url). Now I do understand
if you don't want to spend your time on implementing the specialized
url support since it doesn't scratch your itch, but at least your
series shouldn't impend supporting that in the near future.
> For cases where the foreign vcs has something to put in the "url" spot,
> you don't need to set "vcs". In fact, you are only allowed to set one or
> the other of "vcs" and "url" with my current version. What you're
> interested in is explicitly left for later, when we have a prototype
> helper for such a foreign vcs and can try it out with potential users.
I need to hurry up and get working on that hg implementation then :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [JGIT] Request for help
From: Mark Struberg @ 2009-09-04 19:51 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Douglas Campos, git, Gabe McArthur
In-Reply-To: <2c6b72b30909041150g6374be2ci4d36bd8ab0824a8d@mail.gmail.com>
Thanks Jonas!
I now squashed a lot of commits together where possible and republished the rebased branch.
Next steps:
* mavenizing org.spearce.jgit.pgm
LieGrue,
strub
--- On Fri, 9/4/09, Jonas Fonseca <jonas.fonseca@gmail.com> wrote:
> From: Jonas Fonseca <jonas.fonseca@gmail.com>
> Subject: Re: [JGIT] Request for help
> To: "Mark Struberg" <struberg@yahoo.de>
> Cc: "Douglas Campos" <douglas@theros.info>, git@vger.kernel.org, "Gabe McArthur" <gabriel.mcarthur@gmail.com>
> Date: Friday, September 4, 2009, 8:50 PM
> On Fri, Sep 4, 2009 at 13:28, Mark
> Struberg<struberg@yahoo.de>
> wrote:
> > Hi!
> >
> > Work has been done at
> >
> > http://github.com/sonatype/JGit/tree/mavenize
> >
> > Please feel free to pull/fork and share your changes!
> I'd be happy to pull it in.
>
> IMO, there are a lot of things that can be squashed
> together and
> cleaned up. I know that you advocated for incremental
> introduction,
> but it seems wrong to for example add a file and then
> completely
> reformat it a few commits later. The same thing with the
> .gitignore
> fixes in step 5.
>
> Some comments ... Some of them I initially entered in
> github's
> codereview, but I ended up writing it all here.
>
> Commit: "mavenizing step 1: moved over the initial poms
> from Jasons branch"
>
> * Please always add an empty line between the subject and
> the body
> of the commit message. Like this:
>
> mavenizing step 1: moved over the initial poms from
> Jasons branch
>
> Signed-off-by: Mark Struberg >struberg@yahoo.de>
>
> * The .gitignore pattern could be further limited to
> "target/" ...
> but you seem to change this to /target later.
>
> In org.spearce.jgit/pom.xml:
>
> * The use of maven-surefire-plugin should be
> removed. This module
> does not have any tests.
>
> * Shouldn't we retain the original
> ${groupId}:${artifactId} naming
> convention, being org.spearce:jgit?
>
> In org.spearce.jgit.test/pom.xml:
>
> * Dependency on jsch is unecessary since it
> is derived from
> org.spearce.jgit.
>
> * Maybe name as org.spearce:jgit-test?
>
> In org.spearce.jgit.pgm/pom.xml:
>
> * Maybe name as org.spearce:jgit-pgm?
>
> Commit: "mavenizing step 2: move the core libs from src to
> src/main/java"
>
> * Please also add an empty line to this commit message.
>
> * You might as well squash the whitespace fixes into the
> first commit.
>
> Commit: "mavenizing step 3: moving all core tests into the
> core module"
>
> * The commit message wrongly states:
> org.spearce.jgit.test/tst/ ->
> org.spearce.jgit/src/test/java/tst/
> Should be:
> org.spearce.jgit.test/tst/ ->
> org.spearce.jgit/src/test/java/
>
> Commit: "mavenizing step 4: moving some license files and
> META-INF"
>
> * Shouldn't the commit message rather say "remove JSch"?
> Then the moving of META-INF can be put in
> its own commit.
>
> * The new NOTICE file has a few typos and the info could
> fit into the README
>
> Then I got a bit lost in a huge reformatting.
>
> --
> Jonas Fonseca
> --
> 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
* .git and retrieving full source tree for own project(s)
From: armencho @ 2009-09-04 19:52 UTC (permalink / raw)
To: git
Hi all,
I just started with git and suprisingly or unsurprisingly everything
works, and I love it. I had been working on a software project, and i
ran "git init" in its source tree, which created the ".git". I added
all files with "git add ." and first-time committed them all using
"git commit -a -m "Imported project files". I also did couple three
commits after that and well, everything works.
What I am wondering about is, what is gits identity for a repository?
I don't share or publish the source directory anywhere, and just for
testing I removed everything but the ".git" directory and tried "git
checkout" and "git checkout master". To my surprise, the files in
repository did NOT reappear, contrary to what I thought. Doesn't
checkout update/recreate the project file tree according to the
"trunk" snapshot?
Now, I did all this just out of curiosity, but to my understanding
everything that is needed for working with the project is stored in
".git", right? Even if all project files mysteriously disappear, "git
checkout" should bring the copy of master branch back, no? If not,
what is the way to tell git I want full copy of a snapshot?
^ permalink raw reply
* Re: .git and retrieving full source tree for own project(s)
From: Junio C Hamano @ 2009-09-04 20:04 UTC (permalink / raw)
To: armencho@gmail.com; +Cc: git
In-Reply-To: <981b72360909041252i29551a5chb8b3a2a5c6444ee3@mail.gmail.com>
"armencho@gmail.com" <armencho@gmail.com> writes:
> What I am wondering about is, what is gits identity for a repository?
> I don't share or publish the source directory anywhere, and just for
> testing I removed everything but the ".git" directory and tried "git
> checkout" and "git checkout master".
"git checkout" is a short-hand for "git checkout HEAD" which is to request
"switch to the branch denoted by HEAD, i.e. the current branch, while
keeping my local changes to the work tree and the index".
"git checkout master" is a request to "switch to the master branch, while
keeping my local changes to the work tree and the index".
In this case, your "delete everything" is your local change, and git did
its best to preserve it while switching branches.
If you want to "copy this and that files and directories out of the
commit at the tip of the current branch and deposit them in my work tree
and index", you would say
$ git checkout HEAD this that
so a request for checking everything out would be a natural extension of
the above that would be:
$ git checkout HEAD .
If you want to "copy this and that files and directories out of the index
and deposit them in my work tree", you would say
$ git checkout this that
^ permalink raw reply
* Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case
From: Daniel Barkalow @ 2009-09-04 20:10 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <fabb9a1e0909041235x74a3b9b4gf65e650ca0d00831@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2258 bytes --]
On Fri, 4 Sep 2009, Sverre Rabbelier wrote:
> Heya,
>
> On Fri, Sep 4, 2009 at 21:05, Daniel Barkalow<barkalow@iabervon.org> wrote:
> > Some foreign vcses, including the only one I ever personally use, do not
> > have URLs, and require a bunch of options and paths to specify a
> > repository. I don't want to have to use:
> >
> > url = p4://rsh:ssh+-q+-a+-x+-l+p4ssh+-q+-x+perforce+%2Fbin%2Ftrue//projects/foo/bar-1.0/...,//projects/foo/bar-1.1/...
>
> Btw, doesn't p4 have these config files that you can download that
> contain the configuration? In that case
> 'p4://example.org/p4/main-development.configfile' would be very
> convenient.
The only thing I know of which you might be thinking of is "client
specifications", which are like git superprojects. They're almost certain
to only specify one of the multiple locations that you want to have in the
same repository; the multiple locations are the paths you want to treat
as branches, and the client picks one branch of each project and places
it in some non-branch-specific location relative to other projects. (Of
course, someday I might want to support importing a client specification
as a git project with submodules, but it's got the same issues as
svn::externals without revision specifications seems to).
In any case, p4 doesn't have any easy generic way to specify how to
contact the server, and doesn't have anything client-side.
> Regardless, I do think there should be some way to specify all this
> outside of the url, but to me that's secondary. I think the primary
> usecase is/should be cloning from some url in the form of
> 'hg://example.org/foo', rather than 'http://example.org/some-hg-repo'
> or 'p4://.......', since those are both exceptions (the former being
> an ambiguous url, and the latter being a non-url). Now I do understand
> if you don't want to spend your time on implementing the specialized
> url support since it doesn't scratch your itch, but at least your
> series shouldn't impend supporting that in the near future.
I'm pretty sure that this series makes your primary usecase slightly
simpler to support, because it no longer is expected to handle the
ambiguous "http://" class of URLs.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: .git and retrieving full source tree for own project(s)
From: armencho @ 2009-09-04 20:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7viqfyfpdc.fsf@alter.siamese.dyndns.org>
On Fri, Sep 4, 2009 at 22:04, Junio C Hamano<gitster@pobox.com> wrote:
> In this case, your "delete everything" is your local change, and git did
> its best to preserve it while switching branches.
>
> If you want to "copy this and that files and directories out of the
> commit at the tip of the current branch and deposit them in my work tree
> and index", you would say
>
> $ git checkout HEAD this that
>
> so a request for checking everything out would be a natural extension of
> the above that would be:
>
> $ git checkout HEAD .
>
> If you want to "copy this and that files and directories out of the index
> and deposit them in my work tree", you would say
>
> $ git checkout this that
>
>
This makes sense now. I have tested this and it all functions as you
said. Thanks for your help!
^ permalink raw reply
* Strange merge failure (would be overwritten by merge / cannot merge)
From: Christoph Haas @ 2009-09-04 20:28 UTC (permalink / raw)
To: git
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dear list,
I'm struggling with a pretty simple Git repository where I maintain one
of my Debian packages. It has two branches:
- upstream (contains the unaltered original software unpacked from
a .tar.gz)
- master (derived from upstream plus Debian specific changes)
Now I imported a new upstream version into the upstream branch. And then
tried to merge the 'upstream' branch into the 'master' branch to work on
it. And suddenly I get this error:
error: Entry 'cream-abbr-eng.vim' would be overwritten by merge.
Cannot merge.
So it looks like the 'cream-abbr-eng.vim' file has been altered. And it
contains some non-ASCII characters (it's a VIM script file) so perhaps
automatic merging fails. But can't I just tell Git to screw my file in
the 'master' branch and just overwrite my file? No merge strategy helped
me accomplish that.
To reproduce my problem:
$> git clone git://git.workaround.org/cream
$> cd cream
$> git merge origin/upstream
error: Entry 'cream-abbr-eng.vim' would be overwritten by merge.
Cannot merge.
fatal: merging of trees 70008c82f82a7985531aa2d039c03fdf944ea267 and
78d3a35e300434d6369424dd873bb587beacfaa4 failed
Help welcome. I'm no Git guru and totally at a loss here. As a last
resort I would start from scratch losing all of my Git history.
Kindly
Christoph
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkqheHQACgkQCV53xXnMZYZSaQCdF4JovwKUx1FIOq82+joGUIlq
a7UAoIoC2mm2L6Pv7MvZGzOIRNgktb2B
=pklM
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case
From: Johannes Schindelin @ 2009-09-04 21:08 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Daniel Barkalow, Junio C Hamano, git
In-Reply-To: <fabb9a1e0909041235x74a3b9b4gf65e650ca0d00831@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1650 bytes --]
Hi,
On Fri, 4 Sep 2009, Sverre Rabbelier wrote:
> On Fri, Sep 4, 2009 at 21:05, Daniel Barkalow<barkalow@iabervon.org>
> wrote:
> > Some foreign vcses, including the only one I ever personally use, do
> > not have URLs, and require a bunch of options and paths to specify a
> > repository. I don't want to have to use:
> >
> > url = p4://rsh:ssh+-q+-a+-x+-l+p4ssh+-q+-x+perforce+%2Fbin%2Ftrue//projects/foo/bar-1.0/...,//projects/foo/bar-1.1/...
>
> Btw, doesn't p4 have these config files that you can download that
> contain the configuration? In that case
> 'p4://example.org/p4/main-development.configfile' would be very
> convenient.
If that's how p4 users initialize their working directories, then that is
the way to go.
And I cannot start to believe that the complicated way you described is
the common way to initialize p4 working directories, as that would tempt
the intelligence/enthusiasm of the average programmer.
> > For cases where the foreign vcs has something to put in the "url"
> > spot, you don't need to set "vcs". In fact, you are only allowed to
> > set one or the other of "vcs" and "url" with my current version. What
> > you're interested in is explicitly left for later, when we have a
> > prototype helper for such a foreign vcs and can try it out with
> > potential users.
>
> I need to hurry up and get working on that hg implementation then :).
Indeed you do. If only to prove that _this_ and the likes are something
to optimize for, not some obscure vcs config variable that only introduces
a little-exercized code path that's _prone_ to break and does not help
anybody.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case
From: Daniel Barkalow @ 2009-09-04 22:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Sverre Rabbelier, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0909042305390.8306@pacific.mpi-cbg.de>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2765 bytes --]
On Fri, 4 Sep 2009, Johannes Schindelin wrote:
> Hi,
>
> On Fri, 4 Sep 2009, Sverre Rabbelier wrote:
>
> > On Fri, Sep 4, 2009 at 21:05, Daniel Barkalow<barkalow@iabervon.org>
> > wrote:
> > > Some foreign vcses, including the only one I ever personally use, do
> > > not have URLs, and require a bunch of options and paths to specify a
> > > repository. I don't want to have to use:
> > >
> > > url = p4://rsh:ssh+-q+-a+-x+-l+p4ssh+-q+-x+perforce+%2Fbin%2Ftrue//projects/foo/bar-1.0/...,//projects/foo/bar-1.1/...
> >
> > Btw, doesn't p4 have these config files that you can download that
> > contain the configuration? In that case
> > 'p4://example.org/p4/main-development.configfile' would be very
> > convenient.
>
> If that's how p4 users initialize their working directories, then that is
> the way to go.
>
> And I cannot start to believe that the complicated way you described is
> the common way to initialize p4 working directories, as that would tempt
> the intelligence/enthusiasm of the average programmer.
Perforce is probably the single most popular system for git to import from
because it is such a monumental pain to use for anything at all that it's
easier to learn git, write a git importer, and use your git importer than
it is to actually use Perforce directly.
Of course, it's not really beyond the average programmer to get a p4
working directory, because whoever is running the server will have
provided a file to copy and instructions on setting an environment
variable. They don't know what the magic formula means; they just use it.
And they only work on one branch until that branch is done with,
and then they throw away that working directory, get a new working
directory, and never look at the other branch's history again (and
certainly never track anything across branches). Also, they have p4
experts who deal with merging branches so that stuff doesn't get lost when
moving to a new branch. And the experts have scripts built into the
release process that attempt to insure that things don't get lost. The
reason that my helper can't have a single location for a repository is
that the branches of a single project are strewn randomly about the
namespace, and a proper git import needs to know what to stitch into a
single repository.
For the matter of where the server is, Perforce supports just having a
"server:port" value, but if the organization uses this, there's no
authentication of users possible. Instead, organizations set up an ad hoc
collection of ssh proxies and give people a string which is the command to
go through those proxies, because Perforce only knows how to use rsh or a
command you provide that acts like rsh.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case
From: Johannes Schindelin @ 2009-09-04 22:36 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Sverre Rabbelier, Junio C Hamano, git
In-Reply-To: <alpine.LNX.2.00.0909041750390.28290@iabervon.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 4508 bytes --]
Hi,
On Fri, 4 Sep 2009, Daniel Barkalow wrote:
> On Fri, 4 Sep 2009, Johannes Schindelin wrote:
>
> > Hi,
> >
> > On Fri, 4 Sep 2009, Sverre Rabbelier wrote:
> >
> > > On Fri, Sep 4, 2009 at 21:05, Daniel Barkalow<barkalow@iabervon.org>
> > > wrote:
> > > > Some foreign vcses, including the only one I ever personally use, do
> > > > not have URLs, and require a bunch of options and paths to specify a
> > > > repository. I don't want to have to use:
> > > >
> > > > url = p4://rsh:ssh+-q+-a+-x+-l+p4ssh+-q+-x+perforce+%2Fbin%2Ftrue//projects/foo/bar-1.0/...,//projects/foo/bar-1.1/...
> > >
> > > Btw, doesn't p4 have these config files that you can download that
> > > contain the configuration? In that case
> > > 'p4://example.org/p4/main-development.configfile' would be very
> > > convenient.
> >
> > If that's how p4 users initialize their working directories, then that is
> > the way to go.
> >
> > And I cannot start to believe that the complicated way you described is
> > the common way to initialize p4 working directories, as that would tempt
> > the intelligence/enthusiasm of the average programmer.
>
> Perforce is probably the single most popular system for git to import
> from because it is such a monumental pain to use for anything at all
> that it's easier to learn git, write a git importer, and use your git
> importer than it is to actually use Perforce directly.
>
> Of course, it's not really beyond the average programmer to get a p4
> working directory, because whoever is running the server will have >
> provided a file to copy and instructions on setting an environment
> variable.
That is what we need to optimize for, then.
> They don't know what the magic formula means; they just use it. And they
> only work on one branch until that branch is done with, and then they
> throw away that working directory, get a new working directory, and
> never look at the other branch's history again (and certainly never
> track anything across branches). Also, they have p4 experts who deal
> with merging branches so that stuff doesn't get lost when moving to a
> new branch. And the experts have scripts built into the release process
> that attempt to insure that things don't get lost. The reason that my
> helper can't have a single location for a repository is that the
> branches of a single project are strewn randomly about the namespace,
> and a proper git import needs to know what to stitch into a single
> repository.
And why not having the different branches which are strewn randomly about
the namespace as separate remotes for a Git repository? After all, the
average p4 user will be wanting to work on _one_ branch, as you so aptly
described.
> For the matter of where the server is, Perforce supports just having a
> "server:port" value, but if the organization uses this, there's no
> authentication of users possible. Instead, organizations set up an ad
> hoc collection of ssh proxies and give people a string which is the
> command to go through those proxies, because Perforce only knows how to
> use rsh or a command you provide that acts like rsh.
That explains a tiny part of the long path you provided, but certainly not
all (I am especially curious what /bin/true thinks it's doing in that
URL).
If what you said about ssh is true, then it should be the same type of
invocation everywhere, and it should certainly be very easy to provide a
shortcut for that URL; no need for the _user_ (who could not care less how
ssh happens to be called) to remember.
Something like "git clone p4::ssh://p4ssh@projects/foo/bar-1.0/..." should
become a very easy and intuitive way for the average programmer to clone a
p4 branch into a Git repository.
Should the developer ever need to work with another branch of the same
project, very easy:
$ git remote add -f bar-1.1 p4::ssh://p4ssh@projects/foo/bar-1.1/...
$ git checkout -b my-1.1 bar-1.1/master
Now, I am not married to having more than one remote for multiple
branches, but there is _no_ reason why this has to be done at clone time,
if the average p4 user does not do that either. You can always teach
git-remote-p4 to behave sensibly and ask the user to
$ git config --add remote.origin.fetch \
+/foo/bar-1.1:refs/remotes/origin/bar-1.1
Note, these are two alternative suggestions. I am not trying to decide
what is better here, but I am convinced that both options are more
intuitive than the "vcs" variable.
Ciao,
Dscho
^ permalink raw reply
* Re: [JGIT] Request for help
From: Gabe @ 2009-09-04 23:47 UTC (permalink / raw)
To: Mark Struberg; +Cc: Douglas Campos, Jonas Fonseca, git
In-Reply-To: <658028.86274.qm@web27804.mail.ukl.yahoo.com>
On Fri, Sep 4, 2009 at 10:28 AM, Mark Struberg<struberg@yahoo.de> wrote:
> Hi!
>
> Work has been done at
>
> http://github.com/sonatype/JGit/tree/mavenize
>
> Please feel free to pull/fork and share your changes! I'd be happy to pull it in.
>
> @Gabe: your patch seems to got filtered by the list, I think sharing such big things is easier by using github. Would be cool if you could help us!
Ok, I'll fork and send a patch request shortly. I was thinking about
it earlier, and I may add a couple of features that all OS projects
should follow (e.g. License in the jar, etc.).
As to a few questions that have been raised:
1) I pick the 'sources' folder because it's good metadata management.
Everything in the root folder should be about or related to managing
the project. No direct source folders, as it clutters the layout.
Best to be perfectly clear where all the action is happening. It's a
simple convention I wished more projects followed.
2) I haven't worked with the find-bugs plugin. I looked it up, but it
seems to only generate documents in the 'site'/reporting profile.
Thus it wouldn't necessarily affect the building of the software. It
would really only be useful if you had something like a Hudson CI
infrastructure or site generation going on to build a website and show
the reports. I could certainly add that, though, if you like.
3) The LICENSE file can be at the top level. Not really an issue for
me one way or another. Just a personal preference on how I have
structured all of my previous Maven projects.
-Gabe
>
> LieGrue,
> strub
>
> --- On Fri, 9/4/09, Mark Struberg <struberg@yahoo.de> wrote:
>
>> From: Mark Struberg <struberg@yahoo.de>
>> Subject: Re: [JGIT] Request for help
>> To: "Douglas Campos" <douglas@theros.info>
>> Cc: "Jonas Fonseca" <jonas.fonseca@gmail.com>, git@vger.kernel.org, "Gabe McArthur" <gabriel.mcarthur@gmail.com>
>> Date: Friday, September 4, 2009, 4:49 PM
>> Hi Douglas!
>>
>> http://github.com/sonatype/JGit
>>
>> The branch will be called mavenizing or so.
>>
>> Will post this after I got the tests running.
>>
>> LieGrue,
>> strub
>>
>> --- On Fri, 9/4/09, Douglas Campos <douglas@theros.info>
>> wrote:
>>
>> > From: Douglas Campos <douglas@theros.info>
>> > Subject: Re: [JGIT] Request for help
>> > To: "Mark Struberg" <struberg@yahoo.de>
>> > Cc: "Jonas Fonseca" <jonas.fonseca@gmail.com>,
>> git@vger.kernel.org,
>> "Gabe McArthur" <gabriel.mcarthur@gmail.com>
>> > Date: Friday, September 4, 2009, 4:44 PM
>> > On Fri, Sep 4, 2009
>> > at 9:47 AM, Mark Struberg <struberg@yahoo.de>
>> > wrote:
>> >
>> >
>> > as an old saying tells us: how to climb a mountain?
>> step
>> > after step! ;)
>> >
>> >
>> >
>> > I suggest we create a fresh branch based on the
>> Shawns
>> > current version and add all the features
>> incrementally.
>> >
>> >
>> >
>> > please point out where this branch will happen, I want
>> to
>> > give some help too.
>> >
>> >
>>
>>
>>
>> --
>> 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: Strange merge failure (would be overwritten by merge / cannot merge)
From: David Aguilar @ 2009-09-04 23:45 UTC (permalink / raw)
To: Christoph Haas; +Cc: git
In-Reply-To: <4AA17874.7090905@debian.org>
On Fri, Sep 04, 2009 at 10:28:36PM +0200, Christoph Haas wrote:
>
> Now I imported a new upstream version into the upstream branch. And then
> tried to merge the 'upstream' branch into the 'master' branch to work on
> it. And suddenly I get this error:
>
> error: Entry 'cream-abbr-eng.vim' would be overwritten by merge.
> Cannot merge.
>
> To reproduce my problem:
>
> $> git clone git://git.workaround.org/cream
> $> cd cream
> $> git merge origin/upstream
> error: Entry 'cream-abbr-eng.vim' would be overwritten by merge.
> Cannot merge.
> fatal: merging of trees 70008c82f82a7985531aa2d039c03fdf944ea267 and
> 78d3a35e300434d6369424dd873bb587beacfaa4 failed
Very odd indeed!
$ git version
git version 1.6.4.2.264.g79b4f
I was able to workaround it:
$ rm *
$ git add -u
$ git merge origin/upstream
I've never run into this before.
I think it has to do with all the renamed files.
It looks like you're running into ain unfortunate edge case.
The merge-base of both branches (the initial commit) has all
files underneath a cream/ directory.
Both descendants (upstream and master) moved files up to the
root. So when you go to merge those histories the merge driver
gets confused.
What happened in master? cream/A -> A
What happened in upstream? cream/A -> A
That seems like an edge case that might need some attention.
Anyways, once you do the workaround merge it'll settle
itself out and won't happen to you again since the merge will
resolve it for all your future commits (future merges will
have a new, rename-safe merge base).
Does anyone else on the list have any insights?
--
David
^ permalink raw reply
* Re: [JGIT] Request for help
From: Douglas Campos @ 2009-09-05 0:06 UTC (permalink / raw)
To: Gabe; +Cc: Mark Struberg, Jonas Fonseca, git
In-Reply-To: <524457d10909041647u562601d5q69142eefe894ac5b@mail.gmail.com>
> Ok, I'll fork and send a patch request shortly. I was thinking about
> it earlier, and I may add a couple of features that all OS projects
> should follow (e.g. License in the jar, etc.).
Gabe, is there some task that you want to share with me? I have a
short timeframe of 4hours to invest on mavenization.
Cheers
Douglas Campos (qmx)
^ permalink raw reply
* Re: [JGIT] Request for help
From: Gabe McArthur @ 2009-09-05 1:29 UTC (permalink / raw)
To: Douglas Campos; +Cc: Mark Struberg, Jonas Fonseca, git@vger.kernel.org
In-Reply-To: <ed88cb980909041706n26e50107m2343d4d922788459@mail.gmail.com>
I'll post the pull request to github within 3-4 hours. Is that what
you mean by invest? My patch will contain everything I submitted
before plus a bit more. That patch set should contain everything
necessary to build, plus any refinements to whatever is already in the
'mavenize' branch.
-Gabe
On Sep 4, 2009, at 5:06 PM, Douglas Campos <douglas@theros.info> wrote:
>> Ok, I'll fork and send a patch request shortly. I was thinking about
>> it earlier, and I may add a couple of features that all OS projects
>> should follow (e.g. License in the jar, etc.).
>
> Gabe, is there some task that you want to share with me? I have a
> short timeframe of 4hours to invest on mavenization.
>
> Cheers
> Douglas Campos (qmx)
^ permalink raw reply
* Re: Error with git svn show-ignore: forbidden access
From: Eric Wong @ 2009-09-05 5:57 UTC (permalink / raw)
To: Yann Simon; +Cc: git
In-Reply-To: <551f769b0909010246u524599bcoc5b227f4a6279259@mail.gmail.com>
Yann Simon <yann.simon.fr@gmail.com> wrote:
> Hi,
>
> with git version 1.6.4:
>
> $ git svn show-ignore > .gitignore
> RA layer request failed: Server sent unexpected return value (403
> Forbidden) in response to PROPFIND request for
> '/repos/XXX/YYY/ZZZ/trunk/aaa' at /usr/lib/git-core/git-svn line 2243
>
> Is git svn show-ignore making request to the svn server?
Hi Yann,
Yes, git svn has to read the svn:ignore property remotely since it
doesn't do anything with it when it fetches. Do you have read
permissions to /repos/XXX/YYY/ZZZ/trunk/aaa on that repo?
> I tried also with the --no-minimize-url option but get as answer:
> $ git svn --no-minimize-url show-ignore
> Unknown option: no-minimize-url
>
> Thanks for the help
For everything besides initialization/clone, git svn reads the url in
your $GIT_CONFIG. --minimize-url is only used for the initial setup.
You can edit it to move the URL down/up a level if you edit your
corresponding fetch/branches/tags lines:
before:
[svn-remote "svn"]
url = http://example.com/
fetch = project/trunk:refs/remotes/trunk
branches = project/branches/*:refs/remotes/*
tags = project/tags/*:refs/remotes/tags/*
after:
[svn-remote "svn"]
url = http://example.com/project
fetch = trunk:refs/remotes/trunk
branches = branches/*:refs/remotes/*
tags = tags/*:refs/remotes/tags/*
--
Eric Wong
^ 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