* 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
* Re: [PATCH] Improve bash prompt to detect various states like an unfinished merge
From: Robin Rosenberg @ 2007-10-01 18:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, johannes.sixt, spearce
In-Reply-To: <7vabr3tfmq.fsf@gitster.siamese.dyndns.org>
måndag 01 oktober 2007 skrev Junio C Hamano:
> Robin Rosenberg <robin.rosenberg@dewire.com> writes:
>
> > This patch makes the git prompt (when enabled) show if a merge or a
> > rebase is unfinished. It also detects if a bisect is being done as
> > well as detached checkouts.
>
> Since you show the name of the branch anyway, I have to wonder
> why you should say BISECT.
You can wonder around different branches while bisecting. The BISECT
part is there to remind you that you are already doing bisecting, especially
when being away from the prompt for a while. I did some mistakes without it.
> Also if you know you normally get branch name, lack of branch
> name would indicate detached HEAD, I would presume.
Yes, sure, but I like it better this way.
> But other state information may be helpful.
This is an example script, so I'd say it's better to have a little too much
and let people remve stuff they don't like in their personal copies.
-- robin
^ permalink raw reply
* Re: [PATCH 1/4] Add a simple option parser for use by builtin-commit.c.
From: Johannes Schindelin @ 2007-10-01 18:13 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: Jonas Fonseca, gitster, git
In-Reply-To: <1191255975.25093.26.camel@hinata.boston.redhat.com>
Hi,
On Mon, 1 Oct 2007, Kristian H?gsberg wrote:
> On Sun, 2007-09-30 at 15:11 +0200, Jonas Fonseca wrote:
>
> > One of the last things I miss from Cogito is the nice abbreviated help
> > messages that was available via '-h'. I don't know if it would be
> > acceptable (at least for the main porcelain commands) to put this
> > functionality into the option parser by adding a "description" member
> > to struct option and have parse_options print a nice:
> >
> > <error message if any>
> > <usage string>
> > <option summary>
> >
> > on failure, or, if that is regarded as too verbose, simply when -h is
> > detected.
>
> Yeah, that might be nice. We can add it in a follow-on patch, if the
> list agrees that it's a good thing, I guess.
That's a good idea; I would put the usage string there, too.
> > > +
> > > +/* Parse the given options against the list of known options. The
> > > + * order of the option structs matters, in that ambiguous
> > > + * abbreviations (eg, --in could be short for --include or
> > > + * --interactive) are matched by the first option that share the
> > > + * prefix.
> > > + */
> >
> > This prefix aware option parsing has not been ported over to the other
> > builtins when they were lifted from shell code. It might be nice to
> > have of course. Is it really needed?
>
> I don't ever use it myself and I think it's more confusing than helpful.
> I only added it to avoid introducing behavior changes in the port. I
> don't have strong feelings either way.
It might be convenient, but I think that it is really more confusing than
helpful, especially with options that share a prefix. Besides, we have
good completion for bash now (and I hear that this "zsh" thing also has
quite good completion), I recommend <TAB> over prefix DWIMery.
> > > +
> > > +extern int parse_options(const char ***argv,
> > > + struct option *options, int count,
> > > + const char *usage_string);
> >
> > I think the interface could be improved a bit. For example, it doesn't
> > need to count argument since the last entry in the options array is
> > OPTION_LAST and thus the size can be detected that way.
>
> Hehe, yeah, that's how I did it first. I don't have a strong preference
> for terminator elements vs. ARRAY_SIZE(), but Junio prefers the
> ARRAY_SIZE() approach, I guess. At this point I'm just trying the get
> the patches upstream...
FWIW I like the ARRAY_SIZE() approach better, too, since it is less error
prone.
Ciao,
Dscho
^ permalink raw reply
* Re: what's a useful definition of full text index on a repository?
From: Jon Smirl @ 2007-10-01 17:25 UTC (permalink / raw)
To: David Tweed; +Cc: Git Mailing List
In-Reply-To: <e1dab3980710010933u6a7324f0wa8230d67ee0846e2@mail.gmail.com>
On 10/1/07, David Tweed <david.tweed@gmail.com> wrote:
> Basically a "blue sky" question about full-text indexing git repositories.
>
> A while back, whilst talking about overall git structure
> (see
>
> http://marc.info/?l=git&m=118891945402778&w=2
>
> ), Jon Smirl raised the question of putting a full-text index on a
> repository. I doubt I full text index is of much use on a code
> repository because the question tends to be focussed around either
> released versions or immediate git-blame stuff. However, for
> repositories of things like evolving documents/presentations/notes
> where content is deleted because it doesn't fit the context rather
> than being superceded by better stuff, it might be more natural to
> search for "where's that paragraph I wrote on 'human' 'vision' and
> 'kinematic' 'feedback' ?". So I got to thinking about experimenting
> with a full text index and even started writing some code. However, I
> then realised that it's not obvious what the most useful definition of
> a full text index is on evolving files. (To be clear, I'm _not_
> thinking about changing the database fundamentals as discussed in the
> referenced thread and indeed would put the full-text index into a
> different file that just references the existing git db stuff
> precisely because I doubt the text index will be of use to most
> people.)
This is what full text is used for with code:
http://lxr.mozilla.org/
It makes grep instant.
For source code you can take the full text concept further and store
parse trees. This lets you instantly find the callers of a function,
or all users of a variable.
Once you have parse trees in the database you can offer refactoring
too. I have used powerful proprietary system that used parse trees to
make complicated refactoring quite easy.
Note that a parse tree database doesn't have to be generated for all
the old revisions, it is mainly usefully for the current HEAD. Same
for the full text index. When you generate this data you end up with
lots of tiny files that need to be kept in sync with the current HEAD.
git is good for holding those files.
You want all this analysis coordinated with git so that when you
commit a change the right parts get regenerated. Linux seems to be
missing good, automated refactoring assistance. Instead the kernel
janitorial work is being done manually.
An example I noticed today. Use of pr_debug() is chaotic in the kernel
source. Many drivers have #if DEBUG their own versions of pr_debug().
Fixing everything to have consistent use of pr_debug is a refactoring
that could probably be mostly automated.
Mozilla is undergoing some massive automated rewrites.
http://blog.mozilla.com/tglek/category/decomtamination/
Full text indexing can also achieve high levels of compression as
stated in the earlier threads. It is full scale dictionary
compression. When it is being used for compression you want to apply
it to all revisions.
> A "classical" full-text index seems inappropriate because, if I've got
> a long text document that in a blob in commit n1 uses word 'x' in one
> section and the corresponding file in descendant commit n2 has the
> same text using word 'x' but has changes to a different section of the
> document, there's probably no point showing me both documents (and I
> can always track through the history once I've got one (commit-id,file
> pair)). So in the case of a single word, a "useful" definition would
> be the entry for word w in the full-text index should consist of those
> (commit-id,file) pairs whose diff with their parent contains an
> addition of text containing word w. (This will catch the creation of
> the text containing w and then precisely those files which are close
> modifications of it but ignore changes to other areas.) This seems to
> make sense for a single word. Let's call this the "appearance diff"
> definition of a full text index.
You would full text index the expanded source text for each revision,
not the delta. There are forms of full text indexes that record the
words position in the document. They let you search for "vision NEAR
feedback"
A good feature of this is finding when a variable or function was first added.
>
> However, things become unclear if you consider a query with multiple
> words. Consider the simplest case of a linear history where commit n0
> adds word "vision" to file p1.tex (with respect to its single parent),
> there are some intermediate commits and then commit n7 adds word
> "feedback" to p1.tex. Then there's no commit whose diff with its
> single parent contains both words "vision" and "feedback". In the
> linear history case you could imagine trying to find the first commit
> which is a child of _all_ the commits under the "appearance diff"
> definition. However, that clearly doesn't "obviously" extend to
> general full DAG histories, and in any case it's probably not fully
> correct even in the linear case. So maybe a different definition would
> be better. So I'm just throwing the question out to the list in case
> anyone has any better ideas for what a full-text index on an evolving
> set of files ought to be.
>
> (One question is "why do you want to build a table rather than
> actively search the full git repo for each query (ie, combination of
> words) as you make it?" My primary motivation is that I might in the
> future like to do queries on some sort of low processor power
> UMPC-type thing, having built the file containing a "full text index"
> data structure for the index on a quite beefy desktop. The other point
> is that searching natural language text based on a fallible memory
> you're more likely to try different combinations of search terms
> iteratively to try and hit the right one, so there might be some point
> in trying to build an index.)
I do admit that these indexes are used to make functions that can be
done with brute force faster. As computers get faster the need for
these decrease. Right now the size of the kernel repo is not growing
faster than the progress of hardware. If you went back are tried to do
these things on a 386 you'd be shouting for indexes tomorrow.
>
> Anyway, it's currently an idle speculation,
>
> --
> cheers, dave tweed__________________________
> david.tweed@gmail.com
> Rm 124, School of Systems Engineering, University of Reading.
> "we had no idea that when we added templates we were adding a Turing-
> complete compile-time language." -- C++ standardisation committee
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: metastore (was: Track /etc directory using Git)
From: David Härdeman @ 2007-09-19 19:16 UTC (permalink / raw)
To: martin f krafft
Cc: git, Daniel Barkalow, Johannes Schindelin, Thomas Harning Jr.,
Francis Moreau, Nicolas Vilz
In-Reply-To: <20070916060859.GB24124@piper.oerlikon.madduck.net>
On Sun, Sep 16, 2007 at 08:08:59AM +0200, martin f krafft wrote:
>also sprach Daniel Barkalow <barkalow@iabervon.org> [2007.09.15.2156 +0200]:
>> Configuration options only apply to the local aspects of the repository.
>> That is, when you clone a repository, you don't get the configuration
>> options from it, in general. And changing configuration options on a
>> repository does not have any effect on the content it contains. So
>> configuration options aren't appropriate.
>
>Sure they are. Just like git-commit figures out your email address
>if user.email is missing from git-config, or core.sharedRepository
>or core.umask deal with permissions only when you tell them to,
>you'd have to enable core.track or else git would just do what it
>does right now.
>
>> Git doesn't have any way to represent owners or groups, and they
>> would need to be represented carefully in order to make sense
>> across multiple computers. If you're adding support for
>> metadata-as-content (for more than "is this a script?"), you
>> should be able to cover all of the common cases of extended stuff,
>> like AFS-style ACLs.
>
>Ideally, git should be able to store an open-ended number of
>properties for each object, yes.
I haven't followed the discussion at all I must admit (I wrote metastore
as a quick hack to store some extended metadata and it works for my
purposes as long as I don't do anything fancy). But I agree, if any
changes were made to git, I'd advocate adding arbitrary attributes to
files (much like xattrs) in name=value pairs, then any extended metadata
could be stored in those attributes and external scripts/tools could use
them in some way that makes sense...and also make sure to only update
them when it makes sense.
--
David Härdeman
^ permalink raw reply
* what's a useful definition of full text index on a repository?
From: David Tweed @ 2007-10-01 16:33 UTC (permalink / raw)
To: Git Mailing List, Jon Smirl
Basically a "blue sky" question about full-text indexing git repositories.
A while back, whilst talking about overall git structure
(see
http://marc.info/?l=git&m=118891945402778&w=2
), Jon Smirl raised the question of putting a full-text index on a
repository. I doubt I full text index is of much use on a code
repository because the question tends to be focussed around either
released versions or immediate git-blame stuff. However, for
repositories of things like evolving documents/presentations/notes
where content is deleted because it doesn't fit the context rather
than being superceded by better stuff, it might be more natural to
search for "where's that paragraph I wrote on 'human' 'vision' and
'kinematic' 'feedback' ?". So I got to thinking about experimenting
with a full text index and even started writing some code. However, I
then realised that it's not obvious what the most useful definition of
a full text index is on evolving files. (To be clear, I'm _not_
thinking about changing the database fundamentals as discussed in the
referenced thread and indeed would put the full-text index into a
different file that just references the existing git db stuff
precisely because I doubt the text index will be of use to most
people.)
A "classical" full-text index seems inappropriate because, if I've got
a long text document that in a blob in commit n1 uses word 'x' in one
section and the corresponding file in descendant commit n2 has the
same text using word 'x' but has changes to a different section of the
document, there's probably no point showing me both documents (and I
can always track through the history once I've got one (commit-id,file
pair)). So in the case of a single word, a "useful" definition would
be the entry for word w in the full-text index should consist of those
(commit-id,file) pairs whose diff with their parent contains an
addition of text containing word w. (This will catch the creation of
the text containing w and then precisely those files which are close
modifications of it but ignore changes to other areas.) This seems to
make sense for a single word. Let's call this the "appearance diff"
definition of a full text index.
However, things become unclear if you consider a query with multiple
words. Consider the simplest case of a linear history where commit n0
adds word "vision" to file p1.tex (with respect to its single parent),
there are some intermediate commits and then commit n7 adds word
"feedback" to p1.tex. Then there's no commit whose diff with its
single parent contains both words "vision" and "feedback". In the
linear history case you could imagine trying to find the first commit
which is a child of _all_ the commits under the "appearance diff"
definition. However, that clearly doesn't "obviously" extend to
general full DAG histories, and in any case it's probably not fully
correct even in the linear case. So maybe a different definition would
be better. So I'm just throwing the question out to the list in case
anyone has any better ideas for what a full-text index on an evolving
set of files ought to be.
(One question is "why do you want to build a table rather than
actively search the full git repo for each query (ie, combination of
words) as you make it?" My primary motivation is that I might in the
future like to do queries on some sort of low processor power
UMPC-type thing, having built the file containing a "full text index"
data structure for the index on a quite beefy desktop. The other point
is that searching natural language text based on a fallible memory
you're more likely to try different combinations of search terms
iteratively to try and hit the right one, so there might be some point
in trying to build an index.)
Anyway, it's currently an idle speculation,
--
cheers, dave tweed__________________________
david.tweed@gmail.com
Rm 124, School of Systems Engineering, University of Reading.
"we had no idea that when we added templates we were adding a Turing-
complete compile-time language." -- C++ standardisation committee
^ permalink raw reply
* Re: [PATCH 1/4] Add a simple option parser for use by builtin-commit.c.
From: Kristian Høgsberg @ 2007-10-01 16:26 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: gitster, git
In-Reply-To: <20070930131133.GA11209@diku.dk>
On Sun, 2007-09-30 at 15:11 +0200, Jonas Fonseca wrote:
> Hello Kristian,
>
> I have some comments on your patch. Some of the "improvement" might have
> to wait until after your builtin-commit changes hits git.git. However,
> if we could agree on some of the general changes, I could start porting
> other of the main porcelain commands to use the option parser without
> depending on the state of the remaining builtin-commit series.
Hi Jonas,
That's sounds like a good plan. In fact, in you want to update the
patch with your changes (they all sound good) and start porting over
some of the other builtins feel free. I don't have much time follow up
on these comments right now, but I will get to it eventually - unless
you beat me to it of course ;) I will update builtin-commit.c to work
with whatever changes you introduce once I get around to updating that
patch.
> Kristian Høgsberg <krh@redhat.com> wrote Thu, Sep 27, 2007:
> > Signed-off-by: Kristian Høgsberg <krh@redhat.com>
> > ---
> > Makefile | 2 +-
> > parse-options.c | 74 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > parse-options.h | 29 +++++++++++++++++++++
> > 3 files changed, 104 insertions(+), 1 deletions(-)
> > create mode 100644 parse-options.c
> > create mode 100644 parse-options.h
> >
> > diff --git a/Makefile b/Makefile
> > index 62bdac6..d90e959 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -310,7 +310,7 @@ LIB_OBJS = \
> > alloc.o merge-file.o path-list.o help.o unpack-trees.o $(DIFF_OBJS) \
> > color.o wt-status.o archive-zip.o archive-tar.o shallow.o utf8.o \
> > convert.o attr.o decorate.o progress.o mailmap.o symlinks.o remote.o \
> > - transport.o bundle.o
> > + transport.o bundle.o parse-options.o
> >
> > BUILTIN_OBJS = \
> > builtin-add.o \
> > diff --git a/parse-options.c b/parse-options.c
> > new file mode 100644
> > index 0000000..2fb30cd
> > --- /dev/null
> > +++ b/parse-options.c
> > @@ -0,0 +1,74 @@
> > +#include "git-compat-util.h"
> > +#include "parse-options.h"
> > +
> > +int parse_options(const char ***argv,
> > + struct option *options, int count,
> > + const char *usage_string)
> > +{
> > + const char *value, *eq;
> > + int i;
> > +
> > + if (**argv == NULL)
> > + return 0;
> > + if ((**argv)[0] != '-')
> > + return 0;
> > + if (!strcmp(**argv, "--"))
> > + return 0;
>
> I don't know if this is a bug, but you do not remove "--" from argv,
> which is later (in the patch that adds builtin-commit.c) passed to
> add_files_to_cache and then get_pathspec where it is not removed or
> detected either.
That's an oversight, good catch.
> > +
> > + value = NULL;
> > + for (i = 0; i < count; i++) {
> > + if ((**argv)[1] == '-') {
> > + if (!prefixcmp(options[i].long_name, **argv + 2)) {
> > + if (options[i].type != OPTION_BOOLEAN)
> > + value = *++(*argv);
> > + goto match;
> > + }
> > +
> > + eq = strchr(**argv + 2, '=');
> > + if (eq && options[i].type != OPTION_BOOLEAN &&
> > + !strncmp(**argv + 2,
> > + options[i].long_name, eq - **argv - 2)) {
> > + value = eq + 1;
> > + goto match;
> > + }
> > + }
> > +
> > + if ((**argv)[1] == options[i].short_name) {
> > + if ((**argv)[2] == '\0') {
> > + if (options[i].type != OPTION_BOOLEAN)
> > + value = *++(*argv);
> > + goto match;
> > + }
> > +
> > + if (options[i].type != OPTION_BOOLEAN) {
> > + value = **argv + 2;
> > + goto match;
> > + }
> > + }
> > + }
> > +
> > + usage(usage_string);
> > +
> > + match:
>
> I think the goto can be avoided by simply breaking out of the above loop
> when an option has been found and add ...
>
> > + switch (options[i].type) {
> case OPTION_LAST
> usage(usage_string);
> break;
>
> > + case OPTION_BOOLEAN:
> > + *(int *)options[i].value = 1;
> > + break;
Yeah, that looks nicer. I think the goto structure is a leftover from
when there was more logic between the loop and the switch. It's good to
get some fresh eyes on this code. Junio didn't like the OPTION_LAST
terminator, so I changed the interface to take a count. We can do
if (i == count)
usage();
else switch (options[i].type) {
...
}
of course.
> I've been looking at builtin-blame.c which IMO has some of the most
> obscure option parsing and maybe this can be changed to increment in
> order to support stuff like changing the meaning by passing the same arg
> multiple times (e.g. "-C -C -C") better.
That would be fine, yes.
> Blame option parsing also sports (enum) flags being masked together,
> this can of course be rewritten to a boolean option followed by
> masking when parse_options is done (to keep it sane).
Yup.
> > + case OPTION_STRING:
> > + if (value == NULL)
> > + die("option %s requires a value.", (*argv)[-1]);
>
> Maybe change this ...
>
> > + *(const char **)options[i].value = value;
> > + break;
> > + case OPTION_INTEGER:
> > + if (value == NULL)
> > + die("option %s requires a value.", (*argv)[-1]);
>
> ... and this to:
>
> if (!value) {
> error("option %s requires a value.", (*argv)[-1]);
> usage(usage_string);
> }
Sure, that's friendlier.
> > + *(int *)options[i].value = atoi(value);
> > + break;
> > + default:
> > + assert(0);
> > + }
> > +
> > + (*argv)++;
> > +
> > + return 1;
> > +}
> > diff --git a/parse-options.h b/parse-options.h
> > new file mode 100644
> > index 0000000..39399c3
> > --- /dev/null
> > +++ b/parse-options.h
> > @@ -0,0 +1,29 @@
> > +#ifndef PARSE_OPTIONS_H
> > +#define PARSE_OPTIONS_H
> > +
> > +enum option_type {
> > + OPTION_BOOLEAN,
> > + OPTION_STRING,
> > + OPTION_INTEGER,
> > + OPTION_LAST,
> > +};
> > +
> > +struct option {
> > + enum option_type type;
> > + const char *long_name;
> > + char short_name;
> > + void *value;
> > +};
>
> Space vs tab indentation.
>
> One of the last things I miss from Cogito is the nice abbreviated help
> messages that was available via '-h'. I don't know if it would be
> acceptable (at least for the main porcelain commands) to put this
> functionality into the option parser by adding a "description" member to
> struct option and have parse_options print a nice:
>
> <error message if any>
> <usage string>
> <option summary>
>
> on failure, or, if that is regarded as too verbose, simply when -h is
> detected.
Yeah, that might be nice. We can add it in a follow-on patch, if the
list agrees that it's a good thing, I guess.
> > +
> > +/* Parse the given options against the list of known options. The
> > + * order of the option structs matters, in that ambiguous
> > + * abbreviations (eg, --in could be short for --include or
> > + * --interactive) are matched by the first option that share the
> > + * prefix.
> > + */
>
> This prefix aware option parsing has not been ported over to the other
> builtins when they were lifted from shell code. It might be nice to have
> of course. Is it really needed?
I don't ever use it myself and I think it's more confusing than helpful.
I only added it to avoid introducing behavior changes in the port. I
don't have strong feelings either way.
> > +
> > +extern int parse_options(const char ***argv,
> > + struct option *options, int count,
> > + const char *usage_string);
>
> I think the interface could be improved a bit. For example, it doesn't
> need to count argument since the last entry in the options array is
> OPTION_LAST and thus the size can be detected that way.
Hehe, yeah, that's how I did it first. I don't have a strong preference
for terminator elements vs. ARRAY_SIZE(), but Junio prefers the
ARRAY_SIZE() approach, I guess. At this point I'm just trying the get
the patches upstream...
> Also, I think for this to be more usable for other built-in programs it
> shouldn't modify argv, but instead take both argc and argv (so we don't
> need to have code like "*++(*argv)" ;), parse _all_ options in one go,
> and return the index (of argv) for any remaining options.
>
> Then the following:
>
> while (parse_options(argv, commit_options, ARRAY_SIZE(commit_options),
> builtin_commit_usage))
> ;
>
> becomes:
>
> int i;
> ...
> i = parse_options(argc, argv, commit_options, builtin_commit_usage);
>
> This fits better with how option parsing is currently done. Take
> builtin-add for example:
>
> for (i = 1 ; i < argc ; i++) {
> const char *arg = argv[i];
> /* ... */
> }
> if (argc <= i)
> usage(builtin_rm_usage);
No objections, I think that looks better too.
> [ BTW, blame option parsing actually wants to know if "--" has been seen,
> but I think that can be worked around by simply checking argv[i - 1]
> after calling the option parser. ]
>
> > +
> > +#endif
>
> OK, I will stop these ramblings here. I hope the fact that I read your
> patch both back and forth and added comments in the process didn't make
> it too confusing.
Heh, that's what I do myself :)
thanks for the comments,
Kristian
^ permalink raw reply
* Re: git-http-push / webDAV
From: Eygene Ryabinkin @ 2007-10-01 15:54 UTC (permalink / raw)
To: Thomas Pasch; +Cc: git
In-Reply-To: <4700F6BC.2070701@jentro.com>
Thomas, good day.
Mon, Oct 01, 2007 at 03:31:40PM +0200, Thomas Pasch wrote:
> trying to set up a webDAV enabled http push
> git server (1.5.3.3) like it is described in
>
> http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt
>
> Tested the apache2 (2.2.6) DAV setup with
> cadaver (and tried the browser as well).
> With cadaver I could lock files, download
> and upload content.
>
> However,
>
> > git push -v upload master
> Pushing to http://test@x.x.x.x/git/DepTrack.git/
> Fetching remote heads...
> refs/
> refs/heads/
> refs/tags/
> updating 'refs/heads/master'
> from 0000000000000000000000000000000000000000
> to d75dce3fe0e9ec5915feda5574f214bd432ccb14
> sending 89 objects
> done
> Updating remote server info
> UNLOCK HTTP error 400
And how is your Apache configuration looks like? I used to
make 2.2.4 work flawlessly with git. Perhaps I will get it
a shot with the 2.2.6.
--
Eygene
^ permalink raw reply
* Re: [PATCH] Adding rebase merge strategy
From: Johannes Schindelin @ 2007-10-01 15:50 UTC (permalink / raw)
To: Tom Clarke; +Cc: gitster, git
In-Reply-To: <11912513203420-git-send-email-tom@u2i.com>
Hi,
On Mon, 1 Oct 2007, Tom Clarke wrote:
> Incorporated comments from Johannes Schindlen.
Thanks.
> +# Give up if we are given two or more remotes -- not handling octopus.
> +test $# = 1 || exit 2
I think the user wants to know in this case, too. How about
test $# = 1 || {
echo "Cannot handle octopus." >&2
exit 2
}
> diff --git a/t/t3031-merge-rebase.sh b/t/t3031-merge-rebase.sh
> new file mode 100755
> index 0000000..daa03b1
> --- /dev/null
> +++ b/t/t3031-merge-rebase.sh
>
> [...]
>
> + ( git log --pretty=oneline ) >actual &&
Please lose the parentheses here.
> + (
> + echo "4db7a5a013e67aa623d1fd294e8d46e89b3ace8f onbranch"
> + echo "893371811dbd13e85c098b72d1ab42bcfd24c2db update"
> + echo "0e960b10429bf3f1e168ee2cc7d531ac7c622580 initial"
> + ) >expected &&
Why not do it as is done elsewhere in the test suit: use a "cat << EOF"
before "test_expect_success"?
> + (
> + echo "warning: Message is not used for rebase merge strategy"
> + ) >expected &&
Same here.
Other than that, I like it.
Ciao,
Dscho
^ 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