* Re: What's cooking in git.git (topics)
From: Jeff King @ 2007-10-02 4:16 UTC (permalink / raw)
To: git
In-Reply-To: <20070927023633.GA28902@coredump.intra.peff.net>
On Wed, Sep 26, 2007 at 10:36:33PM -0400, Jeff King wrote:
> > * jk/diff-rename (Tue Sep 25 15:29:42 2007 -0400) 1 commit
> > + diffcore-rename: cache file deltas
> >
> > Parked in 'next' for now but is 'master' material.
>
> My tests after this patch show that spanhash_find is responsible for
> a large portion of the processing time in large renames, so I am going
> to look into speeding that up.
Just to update, I tried using a non-colliding hash for this (at the
expense of much memory), and I wasn't able to get things much faster
(and certainly not worth the explosion in memory), short of reducing the
size of the hash (which is going to reduce the quality of the output).
So I am giving up for the time being, but if others are interested in
trying to speed things up, I would be happy to discuss ideas.
-Peff
^ permalink raw reply
* Re: latest git manual pages have some problems
From: Eric Blake @ 2007-10-02 2:26 UTC (permalink / raw)
To: cygwin, git
In-Reply-To: <224419.55330.qm@web59112.mail.re1.yahoo.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
According to Cary R. on 10/1/2007 2:22 PM:
> The latest update to git (1.5.3.1) changed how the manual pages are
> displayed.
And that change would probably be the upgrade from asciidoc 8.2.2 to 8.2.3.
> Specifically references to other git manual pages are no longer
> shown by name. Instead a reference number with a cross reference at the
> end of the file is given. From a usability standpoint this is a real
> inconvenience. I am hoping that something changed in the programs used to
> generate the manual pages and a new flag/etc. is required to get the
> original behavior.
I've noticed it, and I hate it too. But don't know enough about asciidoc
or the git documentation process to know how to go about fixing it, so I'm
adding the git list on this mail for advice.
- --
Don't work too hard, make some time for fun as well!
Eric Blake ebb9@byu.net
volunteer cygwin git packager
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHAaxj84KuGfSFAYARAh1LAKDFEURDhGU25xC8Djdxc12Y1Dz6VQCgz++c
WD09VOPGyWeVySdjOau8a3c=
=X91K
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH 1/2] Change "refs/" references to symbolic constants
From: Jeff King @ 2007-10-02 1:16 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200710012141.44459.andyparkins@gmail.com>
On Mon, Oct 01, 2007 at 09:41:43PM +0100, Andy Parkins wrote:
> Please hold off on applying this. I'm getting this when running the tests:
>
> *** t5516-fetch-push.sh ***
> * ok 1: setup
> * ok 2: fetch without wildcard
> * ok 3: fetch with wildcard
> * ok 4: push without wildcard
> * ok 5: push with wildcard
> * ok 6: push with matching heads
> * ok 7: push with no ambiguity (1)
> * ok 8: push with no ambiguity (2)
> * ok 9: push with weak ambiguity (1)
> * ok 10: push with weak ambiguity (2)
> * ok 11: push with ambiguity (1)
> * FAIL 12: push with ambiguity (2)
>
> I'm having trouble seeing where the fault is at the moment though.
>From your patch:
- patlen != namelen - 5 &&
- prefixcmp(name, "refs/heads/") &&
- prefixcmp(name, "refs/tags/")) {
+ patlen != namelen - STRLEN_PATH_REFS_HEADS &&
+ prefixcmp(name, PATH_REFS_HEADS) &&
+ prefixcmp(name, PATH_REFS_HEADS)) {
This is totally bogus. You meant STRLEN_PATH_REFS, and the second path
should be PATH_REFS_TAGS. With those changes, t5516 passes.
I haven't combed through your patch in detail, so there might be similar
problems lurking. I did notice one or two spots where you call
strlen(PATH_REFS_*), which should of course also be changed to
STRLEN_PATH_REFS_*.
And as a final comment, your patch doesn't apply to next at all because
of the reorganization of the fetching API (e.g., fetch-pack.c doesn't
exist at all anymore). You should probably prepare a parallel patch for
next.
-Peff
^ permalink raw reply
* Re: Problems setting up bare repository (git 1.5.3.3)
From: Carl Worth @ 2007-10-01 23:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Barry Fishman, git
In-Reply-To: <7v641qquzq.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 670 bytes --]
On Mon, 01 Oct 2007 16:24:09 -0700, Junio C Hamano wrote:
> I think Daniel's rewrite of remote ref matching code that has
> been cooking in 'next' changes the match semantics of the remote
> side in subtle way to make it easier to favor branches when
> pushing branches, but I juggle many topics and I have to go back
> to the code to make sure. Since you are interested, and more
> importantly since I know you are capable to do the digging
> yourself, I won't be doing the digging myself immediately,
> though.
Great. I'll go looking for that.
And if I don't find what I'm thinking of there, I'll see if I can't
cook up something else myself.
Thanks again,
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Problems setting up bare repository (git 1.5.3.3)
From: Shawn O. Pearce @ 2007-10-01 23:35 UTC (permalink / raw)
To: Carl Worth; +Cc: Junio C Hamano, Barry Fishman, git
In-Reply-To: <87bqbisae6.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> wrote:
> $ git push /pub/git/foo.git master
>
> Is there any reason that that shouldn't be interpreted as
> "master:master" and that that would in turn be interpreted as "create
> a remote refs/heads/master" ?
This is actually read more as:
1) Expand "master" to "refs/heads/master"
2) Expand "refs/heads/master" to "refs/heads/master:refs/heads/master"
We first try to expand the local name to an "absolute" local name,
then if the remote name is missing default it to the same as the
(now expanded) local name. So "push origin master" is not read as
"push origin refs/haeds/master:master".
> PS. As someone who has written some new-user documentation for git,
> there are a few low-level git notions that I would like to avoid in
> that documentation. For example, one is FETCH_HEAD. In my first
> attempt at porting hgbook-chapter2 to git I found myself using
> FETCH_HEAD to simulate "hg incoming". Thankfully, I was able to
> rewrite it by taking advantage of remotes and using "master..origin"
> instead.
How about:
git config alias.incoming 'log ..FETCH_HEAD'
? Or do we need --reverse in there too to simulate "hg incoming"?
The thing is, FETCH_HEAD is a lot more powerful than a tracking
branch. It can contain objects randomly pulled from another
repository (e.g. one shot pulls).
> Another example is "refs/heads". I avoided this partially by inly
> documenting how to push all branches with "--all", but I'd much rather
> be able to say that the user could git push URL branch
> another-branch..." or "git push URL --all" for convenience. Finally,
> git-push itself spews quite a bit of output with "refs/heads" in it
> that I don't think is useful at all. For talking with the user, git
> should say "branch master" not "refs/heads/master".
Agreed. We do that in fetch. We should do that in push. We should
only mention "refs/*" if the user is pushing something funny, e.g.
pushing into the remote tracking branch space. Or the stash. Etc.
Tags and normal branches should be denoted as such.
--
Shawn.
^ permalink raw reply
* Re: git clone questions relating to cpio
From: Junio C Hamano @ 2007-10-01 23:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Reece Dunn, Git
In-Reply-To: <Pine.LNX.4.64.0710020022470.28395@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Mon, 1 Oct 2007, Reece Dunn wrote:
>
>> I am running a Linux From Scratch 6.2 system that does not have cpio
>> installed on it. This means that I can't clone a local repository
>> unless I install cpio.
>
> You might be interested in the workaround Hannes did in mingw.git; he made
> a wrapper script called 'cpio' using 'tar'.
I think that may be good enough as workaround, but I do not
think you would get the space saving from hardlinks that way.
^ permalink raw reply
* Re: git clone questions relating to cpio
From: Johannes Schindelin @ 2007-10-01 23:23 UTC (permalink / raw)
To: Reece Dunn; +Cc: Git
In-Reply-To: <3f4fd2640710011228w61ce34b5ve47ea529eed384fd@mail.gmail.com>
Hi,
On Mon, 1 Oct 2007, Reece Dunn wrote:
> I am running a Linux From Scratch 6.2 system that does not have cpio
> installed on it. This means that I can't clone a local repository
> unless I install cpio.
You might be interested in the workaround Hannes did in mingw.git; he made
a wrapper script called 'cpio' using 'tar'.
Ciao,
Dscho
^ permalink raw reply
* Re: Problems setting up bare repository (git 1.5.3.3)
From: Junio C Hamano @ 2007-10-01 23:24 UTC (permalink / raw)
To: Carl Worth; +Cc: Barry Fishman, git
In-Reply-To: <87bqbisae6.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> writes:
> On Mon, 01 Oct 2007 15:32:58 -0700, Junio C Hamano wrote:
>> "master:master") does not exist there, and we do not create it
>> unless you give a full refname that begins with refs/ (so that
>> push can tell if you want to create a tag or a branch).
>
> And why is that?
I think Daniel's rewrite of remote ref matching code that has
been cooking in 'next' changes the match semantics of the remote
side in subtle way to make it easier to favor branches when
pushing branches, but I juggle many topics and I have to go back
to the code to make sure. Since you are interested, and more
importantly since I know you are capable to do the digging
yourself, I won't be doing the digging myself immediately,
though.
^ permalink raw reply
* Re: Problems setting up bare repository (git 1.5.3.3)
From: J. Bruce Fields @ 2007-10-01 23:17 UTC (permalink / raw)
To: Carl Worth; +Cc: Junio C Hamano, Barry Fishman, git
In-Reply-To: <87bqbisae6.wl%cworth@cworth.org>
On Mon, Oct 01, 2007 at 04:06:09PM -0700, Carl Worth wrote:
> Another example is "refs/heads". I avoided this partially by inly
> documenting how to push all branches with "--all", but I'd much rather
> be able to say that the user could git push URL branch
> another-branch..." or "git push URL --all" for convenience. Finally,
> git-push itself spews quite a bit of output with "refs/heads" in it
> that I don't think is useful at all. For talking with the user, git
> should say "branch master" not "refs/heads/master".
I'd be nervous about skipping discussion of the refs/ namespace. Sure,
introduce branch heads and tags on their own first, but you've got to
mention the rest pretty early on. Eventually anyone can find themselves
with a tags, heads, and remotes with the same names, and then it's easy
to get stuck if you don't have a way to disambiguate.
And, really, it doesn't take that much space to explain this stuff.
--b.
^ permalink raw reply
* Re: [PATCH] Adding rebase merge strategy
From: Junio C Hamano @ 2007-10-01 23:11 UTC (permalink / raw)
To: Carl Worth; +Cc: Shawn O. Pearce, Tom Clarke, Johannes.Schindelin, git
In-Reply-To: <87d4vysayq.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> writes:
> Though actually I'd like it even more if there was some way to mark a
> commit as having been "published" and the rebase strategy would refuse
> to rebase published commits.
That is not "though actually", but an independent topic.
The need is indeed so real that there is a hook git-rebase pays
attention to in order to help you with that. I use it to
prevent myself from accidentally rebasing the topic branches
that I already merged to 'next'.
Unsurprisingly, it is called pre-rebase hook.
^ permalink raw reply
* Re: [PATCH] Adding rebase merge strategy
From: J. Bruce Fields @ 2007-10-01 23:09 UTC (permalink / raw)
To: Carl Worth; +Cc: Tom Clarke, Junio C Hamano, Johannes.Schindelin, git
In-Reply-To: <87ejgescnb.wl%cworth@cworth.org>
On Mon, Oct 01, 2007 at 03:17:28PM -0700, Carl Worth wrote:
> What I think I've always wanted is something like the following
> behavior for "git pull":
>
> * Fast forward if possible
>
> * Otherwise, rebase, but only if there are no conflicts at all
>
> * Otherwise, do the merge as normal, (leave conflict markers in
> place allowing the user to fix them up and then commit).
>
> Would it be straightforward to turn your rebase merge strategy into
> something like the above? And if so, would that address the primary
> concerns that Junio raised?
Surely the job of a merge strategy is to take two heads and produce a
single merge commit?
If it's worth automating the steps you describe above, I think it'd be
better to choose an entirely different name for the command.
--b.
^ permalink raw reply
* Re: Problems setting up bare repository (git 1.5.3.3)
From: Carl Worth @ 2007-10-01 23:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Barry Fishman, git
In-Reply-To: <7vejgeqxd1.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1748 bytes --]
On Mon, 01 Oct 2007 15:32:58 -0700, Junio C Hamano wrote:
> "master:master") does not exist there, and we do not create it
> unless you give a full refname that begins with refs/ (so that
> push can tell if you want to create a tag or a branch).
And why is that?
Why isn't pushing a branch interpreted as wanting to create a branch
and pushing a tag interpreted as wanting to create a tag unless git is
told differently?
> $ git push /pub/git/foo.git master:refs/heads/master
I mean, it's nice that the advanced user can get all specific and
invoke the low-level refs/heads/ thing here. But what I'd really like
to have instead is just:
$ git push /pub/git/foo.git master
Is there any reason that that shouldn't be interpreted as
"master:master" and that that would in turn be interpreted as "create
a remote refs/heads/master" ?
That would really be much kinder for new users.
-Carl
PS. As someone who has written some new-user documentation for git,
there are a few low-level git notions that I would like to avoid in
that documentation. For example, one is FETCH_HEAD. In my first
attempt at porting hgbook-chapter2 to git I found myself using
FETCH_HEAD to simulate "hg incoming". Thankfully, I was able to
rewrite it by taking advantage of remotes and using "master..origin"
instead.
Another example is "refs/heads". I avoided this partially by inly
documenting how to push all branches with "--all", but I'd much rather
be able to say that the user could git push URL branch
another-branch..." or "git push URL --all" for convenience. Finally,
git-push itself spews quite a bit of output with "refs/heads" in it
that I don't think is useful at all. For talking with the user, git
should say "branch master" not "refs/heads/master".
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Adding rebase merge strategy
From: Carl Worth @ 2007-10-01 22:53 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Tom Clarke, Junio C Hamano, Johannes.Schindelin, git
In-Reply-To: <20071001223050.GE2137@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 2754 bytes --]
On Mon, 1 Oct 2007 18:30:50 -0400, "Shawn O. Pearce" wrote:
> `git pull -s <name>` takes any merge strategy that git-merge will
> accept for its -s option. There is also the config option of
> pull.twohead that indicates what the default merge/pull strategy
> should be for a two head merge. Most people don't set this,
> letting the code default to 'recursive'.
Ah, "pull.twohead". I don't think I ever would have guessed that. (And
I was just about to ask if there was a nice place to find all these
options, but then found it myself on my first guess with "man
git-config". Thanks everyone for writing that!).
> But I have to agree with (was it Junio who said this?) doing a rebase
> in a merge strategy doesn't make sense when conflicts come into play.
Sure. Rebase alone isn't useful as a complete merge strategy. But a
rebase strategy that simply fails in the face of a conflict,
(deferring to a subsequent merge strategy), could be very useful.
> It gets confusing fast for the end-user as the conflict resolution
> process is different than for a merge. A long time ago I wrote a
> git-merge-rebase strategy and gave up on it for basically the same
> reason. I posted it to the mailing list and I think Linus said
> "Why?!". That was the end of that thread as I wound up agreeing
> with him.
Yes, I thought I recalled seeing a rebase strategy go by in the past,
but I had never gotten around to trying it out. I'll try to do better
on this try.
> Multiple merge strategies can be given (and attempted). A rebase
> strategy could be attempted before recursive, and if the rebase
> fails but the recursive succeeds then you get (roughly) what is
> being described above by Carl. But that still requires a rebase
> merge strategy. :-\
Yes, this sounds exactly like what I want. So, I put "rebase
recursive" in place as the value for the pull.twohead configuration?
An then make sure that the rebase strategy aborts as "failed" instead
of "conflicted and left for user to resolve"? I saw Junio talking
about return values up above in the thread but didn't pay attention to
details, (2 vs. 1 or something)?
Has anyone tried this rebase then recursive strategy yet? I'm
definitely interested in trying it out, as I think I'd
find it quite nice as a default for pull in my usage.
Though actually I'd like it even more if there was some way to mark a
commit as having been "published" and the rebase strategy would refuse
to rebase published commits. Maybe that's a per-branch
"last-published" reference? I think I'd even like git-push to update
the last-published reference for each pushed branch by default, but
then perhaps have an option to mark a particular remote so that
pushing to that remote doesn't count as publishing.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Problems setting up bare repository (git 1.5.3.3)
From: Junio C Hamano @ 2007-10-01 22:32 UTC (permalink / raw)
To: Barry Fishman; +Cc: git
In-Reply-To: <m3fy0u7bk3.fsf@barry_fishman.acm.org>
Barry Fishman <barry_fishman@acm.org> writes:
> $ git push --force /pub/git/foo.git master:master
> error: dst refspec master does not match any existing ref on the remote and does not start with refs/.
> fatal: The remote end hung up unexpectedly
> error: failed to push to '/pub/git/foo.git'
Read BOTH OF the error messages. Especially the first one.
This error message is telling you that the dst side of the
refspec you supplied (that's the second 'master' in
"master:master") does not exist there, and we do not create it
unless you give a full refname that begins with refs/ (so that
push can tell if you want to create a tag or a branch).
$ git push /pub/git/foo.git master:refs/heads/master
would have worked, without --force.
^ permalink raw reply
* Re: [PATCH] Adding rebase merge strategy
From: Shawn O. Pearce @ 2007-10-01 22:30 UTC (permalink / raw)
To: Tom Clarke; +Cc: Carl Worth, Junio C Hamano, Johannes.Schindelin, git
In-Reply-To: <550f9510710011521s126ca747v956a6f80182444bb@mail.gmail.com>
Tom Clarke <tom@u2i.com> wrote:
> On 10/2/07, Carl Worth <cworth@cworth.org> wrote:
> > What I think I've always wanted is something like the following
> > behavior for "git pull":
> >
> > * Fast forward if possible
> >
> > * Otherwise, rebase, but only if there are no conflicts at all
> >
> > * Otherwise, do the merge as normal, (leave conflict markers in
> > place allowing the user to fix them up and then commit).
> >
> > Would it be straightforward to turn your rebase merge strategy into
> > something like the above? And if so, would that address the primary
> > concerns that Junio raised?
>
> Maybe we need a 'pull' strategy' - merge, rebase or <insert name for
> strategy you describe above>.
`git pull -s <name>` takes any merge strategy that git-merge will
accept for its -s option. There is also the config option of
pull.twohead that indicates what the default merge/pull strategy
should be for a two head merge. Most people don't set this,
letting the code default to 'recursive'.
But I have to agree with (was it Junio who said this?) doing a rebase
in a merge strategy doesn't make sense when conflicts come into play.
It gets confusing fast for the end-user as the conflict resolution
process is different than for a merge. A long time ago I wrote a
git-merge-rebase strategy and gave up on it for basically the same
reason. I posted it to the mailing list and I think Linus said
"Why?!". That was the end of that thread as I wound up agreeing
with him.
Multiple merge strategies can be given (and attempted). A rebase
strategy could be attempted before recursive, and if the rebase
fails but the recursive succeeds then you get (roughly) what is
being described above by Carl. But that still requires a rebase
merge strategy. :-\
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Adding rebase merge strategy
From: Junio C Hamano @ 2007-10-01 22:28 UTC (permalink / raw)
To: Tom Clarke; +Cc: Johannes.Schindelin, git
In-Reply-To: <550f9510710011441t1eb50352ofc8db77f79d794d5@mail.gmail.com>
"Tom Clarke" <tom@u2i.com> writes:
> I'm happy to try to address the issues you raised, but I wonder if we
> would do better to look back at my original proposal which was to add
> a --rebase option to git-pull. git-pull is the main place there I see
> need for using a rebase instead of a merge, as anywhere where you
> might use git-merge directly, if what you really want is a rebase, you
> can just run git-rebase.
Yeah, we have taught "git-pull == git-fetch + git-merge" to our
users, and "-s strategy" has been a way to specify _how_ the
merge is done, and not about doing something that is not a
merge.
As you say, rebase is not doing a merge. But neither is "squash".
"git-pull --rebase == git-fetch + git-rebase" might be simpler
for end users to understand. I dunno.
^ permalink raw reply
* Re: [PATCH] Adding rebase merge strategy
From: Tom Clarke @ 2007-10-01 22:21 UTC (permalink / raw)
To: Carl Worth; +Cc: Junio C Hamano, Johannes.Schindelin, git
In-Reply-To: <87ejgescnb.wl%cworth@cworth.org>
On 10/2/07, Carl Worth <cworth@cworth.org> wrote:
> What I think I've always wanted is something like the following
> behavior for "git pull":
>
> * Fast forward if possible
>
> * Otherwise, rebase, but only if there are no conflicts at all
>
> * Otherwise, do the merge as normal, (leave conflict markers in
> place allowing the user to fix them up and then commit).
>
> Would it be straightforward to turn your rebase merge strategy into
> something like the above? And if so, would that address the primary
> concerns that Junio raised?
Maybe we need a 'pull' strategy' - merge, rebase or <insert name for
strategy you describe above>.
-Tom
^ permalink raw reply
* Re: [PATCH] Adding rebase merge strategy
From: Carl Worth @ 2007-10-01 22:17 UTC (permalink / raw)
To: Tom Clarke; +Cc: Junio C Hamano, Johannes.Schindelin, git
In-Reply-To: <550f9510710011441t1eb50352ofc8db77f79d794d5@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 874 bytes --]
On Mon, 1 Oct 2007 23:41:56 +0200, "Tom Clarke" wrote:
> Thanks for the ample feedback, you raise a number of interesting
> issues. I am wondering now if making rebase a merge strategy is really
> a good idea. Rebasing is not merging, a difference that could perhaps
> be overlooked in the no-conflict scenario, but as you point out, is
> glaringly obvious as soon as you have conflicts.
What I think I've always wanted is something like the following
behavior for "git pull":
* Fast forward if possible
* Otherwise, rebase, but only if there are no conflicts at all
* Otherwise, do the merge as normal, (leave conflict markers in
place allowing the user to fix them up and then commit).
Would it be straightforward to turn your rebase merge strategy into
something like the above? And if so, would that address the primary
concerns that Junio raised?
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Support tags in uncommit - use git_id instead of rev_parse
From: Catalin Marinas @ 2007-10-01 22:00 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <20070930172647.18972.49369.stgit@tt.roinet.com>
On 30/09/2007, Pavel Roskin <proski@gnu.org> wrote:
> Signed-off-by: Pavel Roskin <proski@gnu.org>
With this patch, uncommit can take patch names (with modifiers) as the
--to argument. When would this be needed?
To allow tags, maybe just pass something like
"git.rev_parse(options.to + '^{commit}')" or just modify git.rev_parse
to do it (and git_id to avoid it).
--
Catalin
^ permalink raw reply
* Problems setting up bare repository (git 1.5.3.3)
From: Barry Fishman @ 2007-10-01 21:46 UTC (permalink / raw)
To: git
Using the 1.5.3.3 release:
$ cd /pub/git
$ mkdir foo.git
$ cd foo.git
$ git --bare init
Initialized empty Git repository in /pub/git/foo.git/
$ git --bare branch
Note that there is no master branch.
$ cd /some/git/workdir
$ git push /pub/git/foo.git master:master
error: dst refspec master does not match any existing ref on the remote and does not start with refs/.
fatal: The remote end hung up unexpectedly
error: failed to push to '/pub/git/foo.git'
$ git push --force /pub/git/foo.git master:master
error: dst refspec master does not match any existing ref on the remote and does not start with refs/.
fatal: The remote end hung up unexpectedly
error: failed to push to '/pub/git/foo.git'
$ git push --all /pub/git/foo.git
updating 'refs/heads/master'
from 0000000000000000000000000000000000000000
to e623fb5ba6fac345eb6af552b40412acdc447b31
Generating pack...
Done counting 61 objects.
Deltifying 61 objects...
100% (61/61) done
Writing 61 objects...
Unpacking 61 objects...
100% (61/61) done
Total 61 (delta 31), reused 50 (delta 25)
100% (61/61) done
refs/heads/master: 0000000000000000000000000000000000000000 -> e623fb5ba6fac345eb6af552b40412acdc447b31
But what if I have more branches and want to just push the master
branch? This worked when I tried it last (probably 1.5.2.2). This time
I had to "git push --all" and then delete all the unwanted branches.
--
Barry Fishman
^ permalink raw reply
* Re: git clone questions relating to cpio
From: Johan Herland @ 2007-10-01 21:42 UTC (permalink / raw)
To: git; +Cc: Reece Dunn
In-Reply-To: <3f4fd2640710011228w61ce34b5ve47ea529eed384fd@mail.gmail.com>
On Monday 01 October 2007, Reece Dunn wrote:
> Hi,
>
> I am running a Linux From Scratch 6.2 system that does not have cpio
> installed on it. This means that I can't clone a local repository
> unless I install cpio. Is it possible to use a fallback method if cpio
> is not present, as there is no NO_CPIO option on make like there is
> for OpenSSH, cURL and expat?
Using "file://" when specifying the source repo will force git-clone to use
the git protocol, instead of doing a copy/hardlink.
I.e. change "git clone foo bar" to "git clone file://foo bar" in order to
prevent git-clone from calling cpio.
However, grepping for cpio in the git source tree reveals a couple of uses
in git-merge, so you might bump into problems there...
> Also, I have an external USB hardrive that is mounted onto the virtual
> filesystem. Will clones from the USB harddrive (or a USB flash drive
> that is mounted) result in a copy being performed, not a hardlink?
Hardlinks are impossible across filesystems. If you're cloning to a
different filesystem git will _have_ to make a full copy.
> Ideally, the hard linking for local clones should be optional.
<quote src="git-clone(1)">
--local, -l
When the repository to clone from is on a local machine, this flag
bypasses normal "git aware" transport mechanism and clones the repository
by making a copy of HEAD and everything under objects and refs directories.
The files under .git/objects/ directory are hardlinked to save space when
possible. This is now the default when the source repository is specified
with /path/to/repo syntax, so it essentially is a no-op option. To force
copying instead of hardlinking (which may be desirable if you are trying to
make a back-up of your repository), but still avoid the usual "git aware"
transport mechanism, --no-hardlinks can be used.
--no-hardlinks
Optimize the cloning process from a repository on a local filesystem by
copying files under .git/objects directory.
</quote>
And as I said above, you can use "file://" to force the "git aware"
transport mechanism, which bypasses the whole local copy/hardlink issue
entirely.
> What if I want to move a repository because, for example, I have imported
> a CVS repository and now want to push it to a new bare repository?
Even if you were to use hardlinks, cloning a repo followed by deleting the
original will be safe (as long as you don't supply '--shared' to
git-clone). That's the beauty of hardlinks.
I also think it's fairly safe to just 'mv' the whole repository to its new
location.
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH] Adding rebase merge strategy
From: Tom Clarke @ 2007-10-01 21:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes.Schindelin, git
In-Reply-To: <7vr6ker1lf.fsf@gitster.siamese.dyndns.org>
On 10/1/07, Junio C Hamano <gitster@pobox.com> wrote:
> This would give a handier shortcut iff the rebase goes well, but
> the workflow after stopping would be entirely different from the
> normal "merge". I am a bit worried about it giving confusion to
> the end users.
Thanks for the ample feedback, you raise a number of interesting
issues. I am wondering now if making rebase a merge strategy is really
a good idea. Rebasing is not merging, a difference that could perhaps
be overlooked in the no-conflict scenario, but as you point out, is
glaringly obvious as soon as you have conflicts.
I'm happy to try to address the issues you raised, but I wonder if we
would do better to look back at my original proposal which was to add
a --rebase option to git-pull. git-pull is the main place there I see
need for using a rebase instead of a merge, as anywhere where you
might use git-merge directly, if what you really want is a rebase, you
can just run git-rebase.
-Tom
^ permalink raw reply
* Re: [PATCH] Adding rebase merge strategy
From: Junio C Hamano @ 2007-10-01 21:01 UTC (permalink / raw)
To: Tom Clarke; +Cc: Johannes.Schindelin, git
In-Reply-To: <11912513203420-git-send-email-tom@u2i.com>
Tom Clarke <tom@u2i.com> writes:
> diff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt
> index 7df0266..dff1909 100644
> --- a/Documentation/merge-strategies.txt
> +++ b/Documentation/merge-strategies.txt
> @@ -33,3 +33,9 @@ ours::
> merge is always the current branch head. It is meant to
> be used to supersede old development history of side
> branches.
> +
> +rebase::
> + This rebases the current branch based on a single head.
> + Commits are rewritten as with git-rebase. This doesn't
> + produce a merge. The procedure for dealing with conflicts
> + is the same as with git-rebase.
This would give a handier shortcut iff the rebase goes well, but
the workflow after stopping would be entirely different from the
normal "merge". I am a bit worried about it giving confusion to
the end users.
> diff --git a/git-merge-rebase.sh b/git-merge-rebase.sh
> new file mode 100755
> index 0000000..b75be3f
> --- /dev/null
> +++ b/git-merge-rebase.sh
> @@ -0,0 +1,17 @@
> +#!/bin/sh
> +#
> +# Copyright (c) 2007 Tom Clarke
> +#
> +# Resolve two trees with rebase
> +
> +# The first parameters up to -- are merge bases ignore them
> +while test $1 != "--"; do shift; done
> +shift
> +
> +# ignore the first head, it's not needed in a rebase merge
> +shift
> +
> +# Give up if we are given two or more remotes -- not handling octopus.
> +test $# = 1 || exit 2
> +
> +git rebase $1 || exit 2
This code makes rebase strategy to signal the caller that rebase
it punted by exit status 2 when it spots conflicting changes.
At that point, what is the state of the branch tip, the index
and the work tree?
When a merge strategy exits with 1 ("I cannot handle this fully
but here is a partial attempt"), it is expected to leave
something that can be resolved in the working tree to be
committed (iow, do some edit, update-index and the a single
"commit" will conclude the whole "git merge" business).
When the strategy exits with 2 ("I cannot deal with this at
all"), git-merge will rewind the branch, index and the work tree
by calling restorestate to the pristine state (in order to clear
whatever mess the strategy may have created), say "Merge with
strategy rebase failed.", and exits with 2.
And at that point, what can the user do?
The user then can initiate the rebase process again from the
command line (perhaps even with "-i"):
$ git rebase FETCH_HEAD
and deal manually with the incremental conflict resolution.
This needs to be documented a bit more clearly, I think, than
your change in the Documentation/merge-strategies.txt.
But more importantly, the above recovery is possible only if you
abort that failed rebase you did in your strategy module, isn't
it?
Although I haven't tried, I suspect that you need to change the
final "git rebase $1 || exit 2" in your script with something
like:
git rebase "$1" || {
git rebase --abort
exit 2
}
Have you tested conflicting cases to see how well it works and
what the user experience would look like?
> diff --git a/git-merge.sh b/git-merge.sh
> index 6c513dc..b58bee2 100755
> --- a/git-merge.sh
> +++ b/git-merge.sh
> ...
> @@ -81,11 +82,18 @@ finish () {
> echo "No merge message -- not updating HEAD"
> ;;
> *)
> - git update-ref -m "$rlogm" HEAD "$1" "$head" || exit 1
> + case " $wt_strategy " in
> + *" $no_update_ref "*)
> + ;;
> + *)
> + git update-ref -m "$rlogm" HEAD "$1" "$head" || exit 1
> + ;;
> + esac
Is this because a successful rebase strategy already updated the
ref? I would not object from the end user experience point of
view to allow "git merge -s rebase" command, but I suspect the
changes to the merge frontend could to be restructured a bit to
handle this easier to read.
> ;;
> esac
> ;;
> esac
> +
> case "$1" in
> '')
> ;;
Probably this is a good readability improvement.
> @@ -418,6 +426,16 @@ do
> ;;
> esac
>
> + # Check to see if there's a message in a merge type that won't produce a commit
> + if test $have_message = "t"
> + then
That quoting is backwards, isn't it?
Literal "t" is not empty and you know you do not need to quote;
you instead need to quote $have_message, because that could be
empty and will not even be given as a separate token to "test"
command without quoting when empty.
> + case " $strategy " in
> + *" $no_update_ref "*)
You have an unnecessary extra indentation here.
> + echo >&2 "warning: Message is not used for $strategy merge strategy"
> + ;;
> + esac
I had to spend 3 minutes thinking about this; if you had a
comment like "A strategy that updates the ref by itself (iow,
bypassing git-merge) does not give git-merge to record the merge
commit using the given message." here, I did not have to.
^ permalink raw reply
* Re: [PATCH 1/2] Change "refs/" references to symbolic constants
From: Andy Parkins @ 2007-10-01 20:41 UTC (permalink / raw)
To: git
In-Reply-To: <200709291359.59147.andyparkins@gmail.com>
On Saturday 2007, September 29, Andy Parkins wrote:
> Changed repeated use of the same constants for the ref paths to be
> symbolic constants. I've defined them in refs.h
Please hold off on applying this. I'm getting this when running the tests:
*** t5516-fetch-push.sh ***
* ok 1: setup
* ok 2: fetch without wildcard
* ok 3: fetch with wildcard
* ok 4: push without wildcard
* ok 5: push with wildcard
* ok 6: push with matching heads
* ok 7: push with no ambiguity (1)
* ok 8: push with no ambiguity (2)
* ok 9: push with weak ambiguity (1)
* ok 10: push with weak ambiguity (2)
* ok 11: push with ambiguity (1)
* FAIL 12: push with ambiguity (2)
I'm having trouble seeing where the fault is at the moment though.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* git clone questions relating to cpio
From: Reece Dunn @ 2007-10-01 19:28 UTC (permalink / raw)
To: Git
Hi,
I am running a Linux From Scratch 6.2 system that does not have cpio
installed on it. This means that I can't clone a local repository
unless I install cpio. Is it possible to use a fallback method if cpio
is not present, as there is no NO_CPIO option on make like there is
for OpenSSH, cURL and expat?
Also, I have an external USB hardrive that is mounted onto the virtual
filesystem. Will clones from the USB harddrive (or a USB flash drive
that is mounted) result in a copy being performed, not a hardlink?
Ideally, the hard linking for local clones should be optional. What if
I want to move a repository because, for example, I have imported a
CVS repository and now want to push it to a new bare repository?
- Reece
^ 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