* 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
* .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: [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
* 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: [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: 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: [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: 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: 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: 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: 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: 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: [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: [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: [JGIT] Request for help
From: Mark Struberg @ 2009-09-04 17:28 UTC (permalink / raw)
To: Douglas Campos; +Cc: Jonas Fonseca, git, Gabe McArthur
In-Reply-To: <585278.66341.qm@web27802.mail.ukl.yahoo.com>
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!
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: [PATCH 1/8] Make the "traditionally-supported" URLs a special case
From: Junio C Hamano @ 2009-09-04 17:23 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Johannes Schindelin, Sverre Rabbelier, Junio C Hamano, git
In-Reply-To: <alpine.LNX.2.00.0909041114440.28290@iabervon.org>
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. In his world, hg:// or any URL that begins
with <unknown>:// wants to be a short-hand to name the helper, and the
third rule whose detail is unspecified in the above list could be
something like:
- With an explicit <prefix-separator>, i.e.
<helper-name> <prefix-separator> <any-string>
tells the named helper git-remote-<helper-name> to interact with
repository that it can find using <any-string>. We do not interpret,
nor guess from, what <any-string> is, in this case.
- When all else fails, and the URL looks like <unknown>://<any-string>,
we see if git-remote-<unknown> is available and give it the whole
string (including the <unknown>::// part).
which means that what Dscho wants is already a subset of the future
direction planned for this series.
As to the "curl" indirection, if you consider the possiblity of someday
adding the transparently backward compatible cgi based server with updated
clients Gitney talked about, I am reasonably sure that we would want to
have a new helper, say http-cgi, and have interested people invoke it
using the "more explicit" escape hatch:
$ git clone http-cgi::http://repo.or.cz/w/alt-git.git/
while others can continue using the walker via a plain http://repo.or.cz/
URL. When http-cgi helper proves to be successful and everybody's server
upgrades, we might choose to swap the default, say in git 1.10.0 release,
while leaving the door open for people to choose the old helper via an
explicit curl::http://repo.or.cz/ URL.
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.
The only slight difference is that having an explicit excape hatch as the
foundation, that usually does not have to be spelled out but does allow
you to, keeps the concept cleaner, while keeping the usability of the end
result.
^ permalink raw reply
* Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case
From: Sverre Rabbelier @ 2009-09-04 17:14 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LNX.2.00.0909041114440.28290@iabervon.org>
Heya,
On Fri, Sep 4, 2009 at 17:40, Daniel Barkalow<barkalow@iabervon.org> wrote:
> As of this version, the idea is that there will be three ways helpers get
> selected:
How does this interact with wanting to support
"hg://example.org/example" by adding 'git-remote-hg' to you path? Does
it make that harder, or is it just not part of this series? I really
do think we should support that, and only resort to "svn::" or such if
the url is ambiguous (e.g., with a 'https://' prefix, etc).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Commit to wrong branch. How to fix?
From: Erik Faye-Lund @ 2009-09-04 17:11 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Howard Miller, git@vger.kernel.org
In-Reply-To: <4AA13DF4.4050604@drmicha.warpmail.net>
On Fri, Sep 4, 2009 at 6:19 PM, Michael J
Gruber<git@drmicha.warpmail.net> wrote:
> Let's say "geesh" is the branch on which you committed by mistake, and
> which you have reset.
>
> git reflog geesh
That should be "git reflog show geesh", no?
--
Erik "kusma" Faye-Lund
kusmabite@gmail.com
(+47) 986 59 656
^ permalink raw reply
* Re: [PATCH 0/8] VCS helpers
From: Junio C Hamano @ 2009-09-04 17:03 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git, Johan Herland
In-Reply-To: <alpine.LNX.2.00.0909041141020.28290@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> On Fri, 4 Sep 2009, Junio C Hamano wrote:
>
>> Because the theme of the topic does not have anything to do with fixing
>> the deepening of shallow clones nor giving an extended error message from
>> non-fast-forward git-push, I queued the series after reverse-rebasing onto
>> old db/vcs-helper~8, in order to keep the topic branch pure, instead of
>> merging unrelated topics from maint, master or next into it. The result
>> merged in 'pu' obviously has to match what you expected by applying the
>> patches on top of 'next', and I am reasonably sure it does.
>
> I'd thought that topics in pu were carried as based on next, particularly
> once they depend on something (e.g., the beginning of the series) in next.
> I suppose there's better options, but what do you do to find them? (Feel
> free to refer me to the "note from the maintainer" if it's there, but I
> don't remember that detail)
Oh, I was *not* complaining that you gave a patch based on 'next'. I was
merely explaining what I did to your patch, in case somebody wonders why
the output of "log -p -8 db/vcs-helper" looks different from what you
posted on the list. I also wanted you to verify the result.
> FWIW, there was a semantic mismerge in the original basing of this series
> on 07a4a3b496, which I finally fixed in this version; the code to handle
> NULL urls in builtin-fetch was after a new conversion of the url.
>
> In any case, I think both the reverse-rebase and merge are correct.
Thanks. Actually, the fact your patch was based on 'next' did help me
verify the result of the rebase and the merge.
It is a good discipline to spend some extra effort to keep a topic pure if
and only if the other topics that the topic textually depends on were of
more dubious quality than the topioc itself. In such a case, there is no
guarantee that they graduate ever, and the topic will be blocked without
major effort later.
It does not matter in practice when we are reasonably sure that other
topics that the topic depends on are likely to be already in when the
topic is completed. In this particular case, many of the changes the
reverse rebase needed to remove are in fact already in master and some are
even in maint, and in retrospect, there was not much point doing this only
to risk mistakes.
In fact, I originally merged the commits whose changes overlapped and were
already in master (Nico's "deepening shallow", Matthieu's "give better
warning to non-fast-forward push", to name a few) on top of the part of
db/vcs-helper that was already in 'next', and then applied your patches on
top of the result, as a middle ground solution. The topic would not have
been as pure as the result I pushed out, but it would still have been much
better than merging the whole master before applying the series.
The principle of keeping the topic branch pure in this case may fall into
my OCD ;-).
^ permalink raw reply
* Re: [PATCH 4/8] Allow fetch to modify refs
From: Daniel Barkalow @ 2009-09-04 16:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0909041243420.4605@intel-tinevez-2-302>
On Fri, 4 Sep 2009, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 3 Sep 2009, Daniel Barkalow wrote:
>
> > + /**
> > + * Fetch the objects for the given refs. Note that this gets
> > + * an array, and should ignore the list structure.
>
> This is not clear at all. You should rather say "[...] and should not
> look at, or set, the 'next' member of the refs".
That is a better wording, yes.
> > + *
> > + * If the transport did not get hashes for refs in
> > + * get_refs_list(), it should set the old_sha1 fields in the
> > + * provided refs now.
>
> Not the "new_sha1"?
No, because get_refs_list() sets the old_sha1, and this isn't indicating
anything different. The old/new thing is to indicate that the ref is
changing value. What's happening here is that the ref isn't changing value
but we didn't know what value it always (effectively) had until now.
> > + **/
> > + int (*fetch)(struct transport *transport, int refs_nr, struct ref **refs);
> > +
> > [...]
> > + /** get_refs_list(), fetch(), and push_refs() can keep
>
> The "/**" wants to have a line to itself.
Good point, thanks.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH 2/9] apply --whitespace=fix: detect new blank lines at eof correctly
From: Junio C Hamano @ 2009-09-04 16:26 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
In-Reply-To: <4AA101BB.7010206@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> After reading this explanation, I was worried that added blank lines that
> are at the end of a patch but apply in the middle of a file would be
> mis-attributed as blank lines at EOF.
The codepath this patch is about checks "does the hunk result in more
blank at the end of the place it applies to?". There is a separate logic
that checks "does the hunk applies at the end of the file", which is the
topic of the codepath that is fixed by Patch #1.
^ permalink raw reply
* [JGIT PATCH v2 2/3] Work around Sun javac compiler bug in RefUpdate
From: Shawn O. Pearce @ 2009-09-04 16:22 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git, Shawn O. Pearce
In-Reply-To: <1252081365-2335-1-git-send-email-spearce@spearce.org>
Sun's javac, version 1.5.0_06 and also a Google internal fork of
OpenJDK 1.6.0 both apparently miscompile the for loop which is
looking for a conflicting ref name in the existing set of refs for
this repository.
Debugging this code showed the control flow to return LOCK_FAILURE
when startsWith returned false, which is highly illogical and the
exact opposite of what we have written here.
OpenJDK 1.6.0's javap tool was unable to disassemble the compiled
method. Instead it simply failed to produce anything about
updateImpl. So my remark about the code being compiled wrong
is only a guess based on how I observed the behavior, and not by
actually studying the resulting instructions.
Eclipse 3.4.2's JDT appears to have compiled the updateImpl method
correctly, and produces a working executable. But this is a much
less common compiler to build Java libraries with.
Robin was able to successfully compile the ancestor version of this
code with both javac 1.5.0_19 and also 1.6.0_16, but not everyone
building JGit has these versions installed.
This refactoring to extract the name conflicting test out into its
own method appears to work around the Sun javac bug I observed above,
and the resulting class works correctly with any compiler tested.
The code is also more clear, so its a gain either way.
Signed-off-by: Shawn O. Pearce <sop@google.com>
---
.../src/org/spearce/jgit/lib/RefUpdate.java | 26 +++++++++++++-------
1 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/RefUpdate.java b/org.spearce.jgit/src/org/spearce/jgit/lib/RefUpdate.java
index 8dffed2..8226e10 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/RefUpdate.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/RefUpdate.java
@@ -449,15 +449,8 @@ private Result updateImpl(final RevWalk walk, final Store store)
RevObject newObj;
RevObject oldObj;
- int lastSlash = getName().lastIndexOf('/');
- if (lastSlash > 0)
- if (db.getRepository().getRef(getName().substring(0, lastSlash)) != null)
- return Result.LOCK_FAILURE;
- String rName = getName() + "/";
- for (Ref r : db.getAllRefs().values()) {
- if (r.getName().startsWith(rName))
- return Result.LOCK_FAILURE;
- }
+ if (isNameConflicting())
+ return Result.LOCK_FAILURE;
lock = new LockFile(looseFile);
if (!lock.lock())
return Result.LOCK_FAILURE;
@@ -490,6 +483,21 @@ private Result updateImpl(final RevWalk walk, final Store store)
}
}
+ private boolean isNameConflicting() throws IOException {
+ final String myName = getName();
+ final int lastSlash = myName.lastIndexOf('/');
+ if (lastSlash > 0)
+ if (db.getRepository().getRef(myName.substring(0, lastSlash)) != null)
+ return true;
+
+ final String rName = myName + "/";
+ for (Ref r : db.getAllRefs().values()) {
+ if (r.getName().startsWith(rName))
+ return true;
+ }
+ return false;
+ }
+
private static RevObject safeParse(final RevWalk rw, final AnyObjectId id)
throws IOException {
try {
--
1.6.4.2.395.ge3d52
^ permalink raw reply related
* [JGIT PATCH v2 3/3] Fix DirCache.findEntry to work on an empty cache
From: Shawn O. Pearce @ 2009-09-04 16:22 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git, Shawn O. Pearce
In-Reply-To: <1252081365-2335-2-git-send-email-spearce@spearce.org>
If the cache has no entries, we want to return -1 rather than throw
ArrayIndexOutOfBoundsException. This binary search loop was stolen
from some other code which contained a test before the loop to see if
the collection was empty or not, but we failed to include that here.
Flipping the loop around to a standard while loop ensures we test
the condition properly first.
Signed-off-by: Shawn O. Pearce <sop@google.com>
---
.../spearce/jgit/dircache/DirCacheBasicTest.java | 6 ++++++
.../src/org/spearce/jgit/dircache/DirCache.java | 6 ++----
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/dircache/DirCacheBasicTest.java b/org.spearce.jgit.test/tst/org/spearce/jgit/dircache/DirCacheBasicTest.java
index b3097ac..4d737c0 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/dircache/DirCacheBasicTest.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/dircache/DirCacheBasicTest.java
@@ -39,6 +39,7 @@
import java.io.File;
+import org.spearce.jgit.lib.Constants;
import org.spearce.jgit.lib.RepositoryTestCase;
public class DirCacheBasicTest extends RepositoryTestCase {
@@ -182,4 +183,9 @@ public void testBuildThenClear() throws Exception {
assertEquals(0, dc.getEntryCount());
}
+ public void testFindOnEmpty() throws Exception {
+ final DirCache dc = DirCache.newInCore();
+ final byte[] path = Constants.encode("a");
+ assertEquals(-1, dc.findEntry(path, path.length));
+ }
}
diff --git a/org.spearce.jgit/src/org/spearce/jgit/dircache/DirCache.java b/org.spearce.jgit/src/org/spearce/jgit/dircache/DirCache.java
index bfb7925..9f0810a 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/dircache/DirCache.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/dircache/DirCache.java
@@ -583,8 +583,6 @@ public void unlock() {
* information. If < 0 the entry does not exist in the index.
*/
public int findEntry(final String path) {
- if (entryCnt == 0)
- return -1;
final byte[] p = Constants.encode(path);
return findEntry(p, p.length);
}
@@ -592,7 +590,7 @@ public int findEntry(final String path) {
int findEntry(final byte[] p, final int pLen) {
int low = 0;
int high = entryCnt;
- do {
+ while (low < high) {
int mid = (low + high) >>> 1;
final int cmp = cmp(p, pLen, sortedEntries[mid]);
if (cmp < 0)
@@ -603,7 +601,7 @@ else if (cmp == 0) {
return mid;
} else
low = mid + 1;
- } while (low < high);
+ }
return -(low + 1);
}
--
1.6.4.2.395.ge3d52
^ permalink raw reply related
* [JGIT PATCH v2 1/3] Allow RefUpdate.setExpectedOldObjectId to accept RevCommit
From: Shawn O. Pearce @ 2009-09-04 16:22 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git, Shawn O. Pearce
RevCommit overrides .equals() such that it only implements a
reference equality test. If the expected old ObjectId was set
by the application to a RevCommit instance, it would always fail,
resulting in LOCK_FAILURE. Instead use AnyObject.equals() to compare
the value, ignoring the possibly overloaded equals in RevCommit.
Signed-off-by: Shawn O. Pearce <sop@google.com>
---
.../tst/org/spearce/jgit/lib/RefUpdateTest.java | 52 ++++++++++++++++++++
.../src/org/spearce/jgit/lib/RefUpdate.java | 2 +-
2 files changed, 53 insertions(+), 1 deletions(-)
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RefUpdateTest.java b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RefUpdateTest.java
index 800c0a4..a8ccf43 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RefUpdateTest.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RefUpdateTest.java
@@ -45,6 +45,7 @@
import org.spearce.jgit.lib.RefUpdate.Result;
import org.spearce.jgit.revwalk.RevCommit;
+import org.spearce.jgit.revwalk.RevWalk;
public class RefUpdateTest extends RepositoryTestCase {
@@ -397,6 +398,57 @@ public void testUpdateRefLockFailureWrongOldValue() throws IOException {
}
/**
+ * Try modify a ref forward, fast forward, checking old value first
+ *
+ * @throws IOException
+ */
+ public void testUpdateRefForwardWithCheck1() throws IOException {
+ ObjectId ppid = db.resolve("refs/heads/master^");
+ ObjectId pid = db.resolve("refs/heads/master");
+
+ RefUpdate updateRef = db.updateRef("refs/heads/master");
+ updateRef.setNewObjectId(ppid);
+ updateRef.setForceUpdate(true);
+ Result update = updateRef.update();
+ assertEquals(Result.FORCED, update);
+ assertEquals(ppid, db.resolve("refs/heads/master"));
+
+ // real test
+ RefUpdate updateRef2 = db.updateRef("refs/heads/master");
+ updateRef2.setExpectedOldObjectId(ppid);
+ updateRef2.setNewObjectId(pid);
+ Result update2 = updateRef2.update();
+ assertEquals(Result.FAST_FORWARD, update2);
+ assertEquals(pid, db.resolve("refs/heads/master"));
+ }
+
+ /**
+ * Try modify a ref forward, fast forward, checking old commit first
+ *
+ * @throws IOException
+ */
+ public void testUpdateRefForwardWithCheck2() throws IOException {
+ ObjectId ppid = db.resolve("refs/heads/master^");
+ ObjectId pid = db.resolve("refs/heads/master");
+
+ RefUpdate updateRef = db.updateRef("refs/heads/master");
+ updateRef.setNewObjectId(ppid);
+ updateRef.setForceUpdate(true);
+ Result update = updateRef.update();
+ assertEquals(Result.FORCED, update);
+ assertEquals(ppid, db.resolve("refs/heads/master"));
+
+ // real test
+ RevCommit old = new RevWalk(db).parseCommit(ppid);
+ RefUpdate updateRef2 = db.updateRef("refs/heads/master");
+ updateRef2.setExpectedOldObjectId(old);
+ updateRef2.setNewObjectId(pid);
+ Result update2 = updateRef2.update();
+ assertEquals(Result.FAST_FORWARD, update2);
+ assertEquals(pid, db.resolve("refs/heads/master"));
+ }
+
+ /**
* Try modify a ref that is locked
*
* @throws IOException
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/RefUpdate.java b/org.spearce.jgit/src/org/spearce/jgit/lib/RefUpdate.java
index 69399ec..8dffed2 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/RefUpdate.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/RefUpdate.java
@@ -466,7 +466,7 @@ private Result updateImpl(final RevWalk walk, final Store store)
if (expValue != null) {
final ObjectId o;
o = oldValue != null ? oldValue : ObjectId.zeroId();
- if (!expValue.equals(o))
+ if (!AnyObjectId.equals(expValue, o))
return Result.LOCK_FAILURE;
}
if (oldValue == null)
--
1.6.4.2.395.ge3d52
^ permalink raw reply related
* Re: [PATCH 0/8] VCS helpers
From: Daniel Barkalow @ 2009-09-04 16:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johan Herland
In-Reply-To: <7v63bz198j.fsf@alter.siamese.dyndns.org>
On Fri, 4 Sep 2009, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > This is the next version of the db/vcs-helper series in pu.
>
> Thanks.
>
> > The first patch is new, a rework of the remote-curl build to produce
> > "remote-curl" and call it as a special case for the sorts of URLs that
> > we accept as indicating something that it now handled by this helper.
> >
> > The series is rebased onto current next, with some conflicts resolved.
>
> Because the theme of the topic does not have anything to do with fixing
> the deepening of shallow clones nor giving an extended error message from
> non-fast-forward git-push, I queued the series after reverse-rebasing onto
> old db/vcs-helper~8, in order to keep the topic branch pure, instead of
> merging unrelated topics from maint, master or next into it. The result
> merged in 'pu' obviously has to match what you expected by applying the
> patches on top of 'next', and I am reasonably sure it does.
I'd thought that topics in pu were carried as based on next, particularly
once they depend on something (e.g., the beginning of the series) in next.
I suppose there's better options, but what do you do to find them? (Feel
free to refer me to the "note from the maintainer" if it's there, but I
don't remember that detail)
FWIW, there was a semantic mismerge in the original basing of this series
on 07a4a3b496, which I finally fixed in this version; the code to handle
NULL urls in builtin-fetch was after a new conversion of the url.
In any case, I think both the reverse-rebase and merge are correct.
> > Two patches have been dropped: a memory leak fix for code that was
> > removed entirely by the first patch, and the "mark" helper capability,
> > which is not needed (I believe) due to the "option" fast-import command.
>
> Johan's cvs-helper series were depending on the previous iteration of this
> series, but I thought it is being rerolled, so I'd drop it from pu for now.
You could probably stick the "mark" patch into the start of the cvs-helper
series until it gets rerolled if you want to keep that series in pu
meanwhile; it was at the end of the series, and doesn't have subtle
interactions or interact with anything that's changed.
-Daniel
*This .sig left intentionally blank*
^ 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