* Re: commiting while the current version is in conflict
From: Richard Hartmann @ 2008-10-16 23:31 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Miklos Vajna, git
In-Reply-To: <20081016232332.GD9877@spearce.org>
On Fri, Oct 17, 2008 at 01:23, Shawn O. Pearce <spearce@spearce.org> wrote:
> Yes, in the index. But it erases it when you stage the file with
> "git add".
>
> Go look at my prior message about how "git commit -a" is staging
> the files prior to commit. That makes git commit think everything
> has been resolved, because you've told git, everything is resolved.
This makes a good part of my latest email obsolete. Asynchronous
communication ftw ;)
Richard
^ permalink raw reply
* Re: commiting while the current version is in conflict
From: Richard Hartmann @ 2008-10-16 23:26 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Miklos Vajna, git
In-Reply-To: <20081016230035.GC9877@spearce.org>
On Fri, Oct 17, 2008 at 01:00, Shawn O. Pearce <spearce@spearce.org> wrote:
> The sample pre-commit hook checks for these. Its really hande to
> have enabled.
Thanks.
> and merge conflicts are "resolved" by you running "git add $path"
> after you have finished fixing that path.
True, git add is an implicit resolving, I did not think about it this way.
Personally, I think that git should break at this point, but that's
just me.
The obvious fix would be a pre-add hook. Does anyone else think
this would make sense?
Judging from the code in the pre-commit script, git does not
keep conflict information in its metadata cache, but tries to guess
conflicts from the file's contents/ This seems to be a strange
thing to do, imo. What's the reason for this?
Richard
^ permalink raw reply
* Re: commiting while the current version is in conflict
From: Shawn O. Pearce @ 2008-10-16 23:23 UTC (permalink / raw)
To: Richard Hartmann; +Cc: Miklos Vajna, git
In-Reply-To: <2d460de70810161607n470e9479h8f7885040cbf5428@mail.gmail.com>
Richard Hartmann <richih.mailinglist@gmail.com> wrote:
> On Fri, Oct 17, 2008 at 00:48, Miklos Vajna <vmiklos@frugalware.org> wrote:
>
> > Not sure, but in general blocking conflict markers by default would be a
> > bad idea IMHO, several markup language (asciidoc, for example) makes use
> > of the >>>, === and such character sequences.
>
> Doesn't git keep metadata about conflicts, as well?
Yes, in the index. But it erases it when you stage the file with
"git add".
Go look at my prior message about how "git commit -a" is staging
the files prior to commit. That makes git commit think everything
has been resolved, because you've told git, everything is resolved.
--
Shawn.
^ permalink raw reply
* Re: commiting while the current version is in conflict
From: Richard Hartmann @ 2008-10-16 23:07 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20081016224808.GO536@genesis.frugalware.org>
On Fri, Oct 17, 2008 at 00:48, Miklos Vajna <vmiklos@frugalware.org> wrote:
> Not sure, but in general blocking conflict markers by default would be a
> bad idea IMHO, several markup language (asciidoc, for example) makes use
> of the >>>, === and such character sequences.
Doesn't git keep metadata about conflicts, as well?
Richard
^ permalink raw reply
* Re: commiting while the current version is in conflict
From: Shawn O. Pearce @ 2008-10-16 23:00 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Richard Hartmann, git
In-Reply-To: <20081016224808.GO536@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> wrote:
> On Fri, Oct 17, 2008 at 12:10:55AM +0200, Richard Hartmann <richih.mailinglist@gmail.com> wrote:
> > all changes were submitted. Of course, I now have a
> > file with the conflict markers inlined in my repository. Not
> > a good thing, imo. Is there a way to make git block all
> > conflicting versions?
>
> Write a pre-commit hook that checks for conflict markers?
The sample pre-commit hook checks for these. Its really hande to
have enabled.
> > Also, I would be interested in the design decissions
> > behind the current behaviour. Any pointers?
>
> Not sure, but in general blocking conflict markers by default would be a
> bad idea IMHO, several markup language (asciidoc, for example) makes use
> of the >>>, === and such character sequences.
Not only that, but "git commit -a" did exactly what you asked it to do:
git add -u
git commit
and git add -u is basically a faster way to do something like this pseudo-shell:
for path in $(git status | grep modified:)
do
git add $path
done
and merge conflicts are "resolved" by you running "git add $path"
after you have finished fixing that path.
Moral of the story is, don't use "git commit -a". Use only "git commit"
and stage files individually. That way when you are in a merge conflict
you won't be in the habit of writing "git commit -a" and staging everything
from the working tree implicitly.
--
Shawn.
^ permalink raw reply
* Re: commiting while the current version is in conflict
From: Miklos Vajna @ 2008-10-16 22:48 UTC (permalink / raw)
To: Richard Hartmann; +Cc: git
In-Reply-To: <2d460de70810161510ha220593g4615a55b2c3e3b25@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 650 bytes --]
On Fri, Oct 17, 2008 at 12:10:55AM +0200, Richard Hartmann <richih.mailinglist@gmail.com> wrote:
> all changes were submitted. Of course, I now have a
> file with the conflict markers inlined in my repository. Not
> a good thing, imo. Is there a way to make git block all
> conflicting versions?
Write a pre-commit hook that checks for conflict markers?
> Also, I would be interested in the design decissions
> behind the current behaviour. Any pointers?
Not sure, but in general blocking conflict markers by default would be a
bad idea IMHO, several markup language (asciidoc, for example) makes use
of the >>>, === and such character sequences.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* commiting while the current version is in conflict
From: Richard Hartmann @ 2008-10-16 22:10 UTC (permalink / raw)
To: git
Hi all,
I fooled around with git a liitle bit and noticed something
rather strange. I merged two branches, creating a conflict
on purpose. When I then did a
git commit -a
all changes were submitted. Of course, I now have a
file with the conflict markers inlined in my repository. Not
a good thing, imo. Is there a way to make git block all
conflicting versions?
Also, I would be interested in the design decissions
behind the current behaviour. Any pointers?
Thanks,
Richard
^ permalink raw reply
* Re: Working with remotes; cloning remote references
From: Marc Branchaud @ 2008-10-16 22:09 UTC (permalink / raw)
To: Peter Harris; +Cc: git
In-Reply-To: <eaa105840810161345r69c9f05j66bb850085f561e7@mail.gmail.com>
Peter Harris wrote:
>
> Ah. I believe I misunderstood what you wanted. Perhaps you want "git
> remote add", then? Unfortunately, you have to know what your remotes
> are outside of git for this. Perhaps a script in the root of your
> repository you can run to set this up after the initial clone?
I think we're converging onto the same track.
Yes, I do want to use "git remote add". My point is basically that,
having done various git-remote-adds in the main repository, I'd like to
avoid having to redo them in a clone of that repository.
A script would work, sure, but to me this seems like something git
should handle for me. If I have to re-establish my connections to the
remotes whenever I want to pull in updates, then I don't see much point
in keeping the remotes defined in any git repo.
> I seem to recall some discussion of allowing a .gitconfig to be in
> repositories (similar to .gitignore), but the idea was shot down for
> security reasons.
I think I can understand why that would be undesirable, but I don't know
if something like that would be necessary for what I'm talking about.
Marc
^ permalink raw reply
* Re: [PATCH 1/7] gitk: Enhance UI popup and accelerator handling.
From: Alexander Gavrilov @ 2008-10-16 22:08 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <18679.47194.852924.385301@cargo.ozlabs.ibm.com>
On Fri, Oct 17, 2008 at 1:55 AM, Paul Mackerras <paulus@samba.org> wrote:
> Alexander Gavrilov writes:
>> - Popups are supposed to be marked transient, otherwise
>> the WM creates them in strange places. Besides, at
>> least under kwin, transients are automatically kept
>> above their parent.
>
> I agree with most of the places where you add wm transient commands,
> but in the case of the list of references (showrefs), I think of that
> as a long-lived window that one would normally place beside the main
> window. (In fact, it should be a pane in the main window, but I
> couldn't think of a place for it. Maybe I should split the
> bottom-right pane in two.)
>
> So I don't think the wm transient in showrefs is what we want.
> Comments?
On the other hand, wm transient makes it always stay on top of the
main window. If the main window is maximized, it is useful.
Btw, gitk probably should not save its geometry if the window is
maximized, because when it is started again the window is too large.
Alexander
^ permalink raw reply
* Re: [PATCH 1/7] gitk: Enhance UI popup and accelerator handling.
From: Paul Mackerras @ 2008-10-16 21:55 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git
In-Reply-To: <1223449540-20457-2-git-send-email-angavrilov@gmail.com>
Alexander Gavrilov writes:
> - Popups are supposed to be marked transient, otherwise
> the WM creates them in strange places. Besides, at
> least under kwin, transients are automatically kept
> above their parent.
I agree with most of the places where you add wm transient commands,
but in the case of the list of references (showrefs), I think of that
as a long-lived window that one would normally place beside the main
window. (In fact, it should be a pane in the main window, but I
couldn't think of a place for it. Maybe I should split the
bottom-right pane in two.)
So I don't think the wm transient in showrefs is what we want.
Comments?
Paul.
^ permalink raw reply
* Re: Rebasing Multiple branches at once...
From: Miklos Vajna @ 2008-10-16 21:00 UTC (permalink / raw)
To: Rick Moynihan; +Cc: git
In-Reply-To: <48F7542B.1050909@calicojack.co.uk>
[-- Attachment #1: Type: text/plain, Size: 602 bytes --]
On Thu, Oct 16, 2008 at 03:48:11PM +0100, Rick Moynihan <rick@calicojack.co.uk> wrote:
> Yes, but my understanding is that it's only harmful if you publish the
> branch (or dependent branches) which are being rebased.
>
> So rebasing is very bad in these circumstances, but I fail to see why it's
> bad if these branches are kept private.
Ah, I thought you publish your branches.
One reason may be that if you use merge, no history is lost, if you use
rebase, history is in the reflogs, so it'll be lost after some time. But
if you know what you are doing, then this is not a problem.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Detached checkout will clobber branch head when using symlink HEAD
From: Nicolas Pitre @ 2008-10-16 20:47 UTC (permalink / raw)
To: Matt Draisey; +Cc: Jeff King, Junio C Hamano, git
In-Reply-To: <1224188939.2796.22.camel@localhost>
On Thu, 16 Oct 2008, Matt Draisey wrote:
> On Thu, 2008-10-16 at 16:20 -0400, Nicolas Pitre wrote:
> > A symlink HEAD and detached checkouts are simply incompatible.
>
> Not necessarily. The symlinking code will unlink the original inode
> each time it creates a new symlink anyway. It is simply a matter of
> creating a new file in its place.
True. I didn't think it all through initially.
Nicolas
^ permalink raw reply
* Re: Working with remotes; cloning remote references
From: Peter Harris @ 2008-10-16 20:45 UTC (permalink / raw)
To: Marc Branchaud; +Cc: git
In-Reply-To: <48F7A42E.70200@xiplink.com>
On Thu, Oct 16, 2008 at 4:29 PM, Marc Branchaud wrote:
> Peter Harris wrote:
>>
>> "git clone" doesn't have this option, but you can turn it on
>> immediately after with something similar to:
>> git config --add remote.origin.fetch +refs/remotes/*:refs/remotes/*
>> (which I use for fanning-out my git-svn repos)
>
> Thanks for the pointer (and the quick reply).
>
> That doesn't seem to be what I'm looking for, though -- perhaps I'm missing
> something? The above puts the remotes in the .git/refs/remotes directory,
> but the .git/config file doesn't have them.
Ah. I believe I misunderstood what you wanted. Perhaps you want "git
remote add", then? Unfortunately, you have to know what your remotes
are outside of git for this. Perhaps a script in the root of your
repository you can run to set this up after the initial clone?
I seem to recall some discussion of allowing a .gitconfig to be in
repositories (similar to .gitignore), but the idea was shot down for
security reasons.
> (As an aside, the above "git config --add" incantation causes problems if
> run inside a clone of a clone:
>
> You did say "something similar" in your reply -- am I not seeing something
> obvious?
I said "something similar" because you probably actually want
git config --add remote.$remote.fetch +refs/remotes/*:refs/remotes/$remote/*
(or other names of your own choosing) so that multiple remote remotes
don't stomp on each other.
Unless you want to be able to address the remotes by name, in which
case you want "git remote add" instead (see above).
Peter Harris
^ permalink raw reply
* Re: Rebasing Multiple branches at once...
From: Toby Allsopp @ 2008-10-16 20:27 UTC (permalink / raw)
To: git; +Cc: Rick Moynihan
In-Reply-To: <48F730D0.9040008@calicojack.co.uk>
[-- Attachment #1: Type: text/plain, Size: 1017 bytes --]
On Fri, Oct 17 2008, Rick Moynihan wrote:
> Hi,
>
> I have a master branch, a dev branch and a number of feature branches
> from dev. And I was wondering if there was an easy way to rebase dev
> and all of it's sub-branches onto master.
>
> I know I can run this as a series of commands, and use --onto to do
> this, but was wondering if there was an easier way. As running:
>
> git rebase master
>
> when on the dev branch only rebases dev and not it's dependent
> branches.
I have a Perl script I use to rebase a number of topic branches as the
remote tracking branches they're based on move. It handles the case of
topic based on other topics. It is designed specifically for my
workflow, which is tracking a central Subversion repository using
git-svn, but I don't think it relies on using git-svn. Anyway, you
might find it useful for inspiration.
The script outputs a sequence of commands and leaves the running of them
up to you because you may need to resolve conflicts at any point.
Regards,
Toby.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: git-rebase-branches --]
[-- Type: text/x-perl, Size: 2748 bytes --]
#!/usr/bin/perl
# Rebases master and everything based on master to the new trunk. Use
# after a git-svn-fetch.
use strict;
use warnings;
use Getopt::Long;
use List::Util qw(first);
use Git;
my $dry_run;
GetOptions("dry-run|n" => \$dry_run)
or die "usage error";
sub ref2branch {
my $ref = shift;
$ref =~ s,^refs/heads/,,
or die "Not a branch: '$ref'";
return $ref;
}
my $repo = Git->repository();
my %remotes_by_name;
my %remotes_by_hash;
my %remote_revs;
for ($repo->command('for-each-ref', 'refs/remotes')) {
my ($hash, undef, $ref) = split;
$remotes_by_name{$ref} = $hash;
$remotes_by_hash{$hash} = $ref;
$remote_revs{$ref} = [$repo->command('rev-list', $ref)];
}
my %heads_by_name;
my %heads_by_hash;
for ($repo->command('for-each-ref', 'refs/heads')) {
my ($hash, undef, $ref) = split;
$heads_by_name{$ref} = $hash;
$heads_by_hash{$hash} = $ref;
}
my %roots;
my %heads_by_parent;
for my $head (sort keys %heads_by_name) {
#print STDERR "Considering $head\n";
my $parent;
my $last_rev;
for my $rev ($repo->command('rev-list', $head, '--not', keys %remotes_by_name)) {
my $maybe_parent = $heads_by_hash{$rev};
if ($maybe_parent && $maybe_parent ne $head) {
#print STDERR " found parent $maybe_parent\n";
$parent = $maybe_parent;
last;
}
$last_rev = $rev;
}
if ($parent) {
push @{$heads_by_parent{$parent}}, $head;
} elsif ($last_rev) {
my $remote_base = $repo->command_oneline('rev-parse', "$last_rev^");
my @remotes;
#print STDERR " last rev $last_rev $remote_base\n";
for my $remote_name (sort keys %remotes_by_name) {
my $remote = first { $_ eq $remote_base } @{$remote_revs{$remote_name}};
if (defined($remote) && $remote eq $remote_base) {
#print STDERR " found remote $remote_name\n";
push @remotes, $remote_name;
}
}
if (@remotes == 1) {
$roots{$head} = $remotes[0];
} else {
print STDERR "WARNING: Not exactly one candidate remote for $head: ",
join(' ', @remotes), "\n";
}
}
}
for my $root (sort keys %roots) {
my $remote = $roots{$root};
my $short_root = ref2branch($root);
$remote =~ s,^refs/,,;
print "git rebase $remote $short_root\n";
rebase_tree($root);
}
sub rebase_tree {
my ($parent) = @_;
for my $head (@{$heads_by_parent{$parent}}) {
my $short_parent = ref2branch($parent);
my $short_head = ref2branch($head);
print "git rebase --onto $short_parent $heads_by_name{$parent} $short_head\n";
rebase_tree($head);
}
}
^ permalink raw reply
* Re: Detached checkout will clobber branch head when using symlink HEAD
From: Jeff King @ 2008-10-16 20:39 UTC (permalink / raw)
To: Matt Draisey; +Cc: Junio C Hamano, git
In-Reply-To: <1224187863.2796.15.camel@localhost>
On Thu, Oct 16, 2008 at 04:11:03PM -0400, Matt Draisey wrote:
> I am using the following system defaults:
>
> core.prefersymlinkrefs=true
> gc.packrefs=false
>
> so almost all my git repositories are still using a symlink HEAD.
> I have some old scripts That I use occasionally and still depend on it.
> Using detached checkout is the only problem I've had.
In your position I would consider updating my scripts. But I guess you
could also try to work up a patch that makes detached HEAD work
(replacing the symlink with a file, then bringing back the symlink when
you're on a branch). In the meantime, here is a cleaned-up version of my
patch, with a proper commit message and a test.
-- >8 --
do not clobber symlinked ref with detached HEAD
The default configuration for git uses a symref for HEAD.
When we detach the HEAD, we can simply write the detached
commit sha1 into the HEAD file.
It is still possible to use symlinks for HEAD (either by
setting it up manually, or by using core.prefersymlinkrefs).
In that case, moving to a detached HEAD is impossible, since
we have nowhere to store the sha1.
However, the current code doesn't realize this and actually
writes into the HEAD file anyway, meaning that it overwrites
the value of the currently checked out branch.
Instead, let's detect in the locking mechanism that we have
a symlink but the caller requested that we lock the original
ref name instead of its linked destination. This has two
advantages:
- we don't have to add an extra stat call, since we
discover the symlink during normal ref resolution
- any code to update a ref should lock it, meaning that we
should catch any other similar instances
Signed-off-by: Jeff King <peff@peff.net>
---
refs.c | 9 ++++++++-
refs.h | 1 +
t/t7202-checkout-symlink.sh | 19 +++++++++++++++++++
3 files changed, 28 insertions(+), 1 deletions(-)
create mode 100755 t/t7202-checkout-symlink.sh
diff --git a/refs.c b/refs.c
index b680750..b4b3865 100644
--- a/refs.c
+++ b/refs.c
@@ -446,8 +446,11 @@ const char *resolve_ref(const char *ref, unsigned char *sha1, int reading, int *
buffer[len] = 0;
strcpy(ref_buffer, buffer);
ref = ref_buffer;
- if (flag)
+ if (flag) {
+ if (!(*flag & REF_ISSYMREF))
+ *flag |= REF_OUTER_IS_SYMLINK;
*flag |= REF_ISSYMREF;
+ }
continue;
}
}
@@ -817,6 +820,10 @@ static struct ref_lock *lock_ref_sha1_basic(const char *ref, const unsigned char
}
ref = resolve_ref(orig_ref, lock->old_sha1, mustexist, &type);
}
+ if (type & REF_OUTER_IS_SYMLINK && flags & REF_NODEREF) {
+ error("unable to directly lock symbolic link '%s'", orig_ref);
+ goto error_return;
+ }
if (type_p)
*type_p = type;
if (!ref) {
diff --git a/refs.h b/refs.h
index 06ad260..9b0dcd9 100644
--- a/refs.h
+++ b/refs.h
@@ -12,6 +12,7 @@ struct ref_lock {
#define REF_ISSYMREF 01
#define REF_ISPACKED 02
+#define REF_OUTER_IS_SYMLINK 04
/*
* Calls the specified function for each ref file until it returns nonzero,
diff --git a/t/t7202-checkout-symlink.sh b/t/t7202-checkout-symlink.sh
new file mode 100755
index 0000000..cf09f5f
--- /dev/null
+++ b/t/t7202-checkout-symlink.sh
@@ -0,0 +1,19 @@
+#!/bin/sh
+
+test_description='checkout with symlinked HEAD'
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+ echo one > file && git add file && git commit -m one &&
+ echo two > file && git add file && git commit -m two &&
+ ln -sf refs/heads/master .git/HEAD
+'
+
+test_expect_success 'checkout detached HEAD does not clobber ref' '
+ test_must_fail git checkout HEAD^ &&
+ echo two >expect &&
+ git log -1 --pretty=tformat:%s >actual
+ test_cmp actual expect
+'
+
+test_done
--
1.6.0.2.711.gf1ba4.dirty
^ permalink raw reply related
* Re: Feedback outside of the user survey
From: Christian Jaeger @ 2008-10-16 20:32 UTC (permalink / raw)
To: Richard Hartmann; +Cc: Garry Dolley, git
In-Reply-To: <2d460de70810160618u1803375aj913145a5060e5308@mail.gmail.com>
Richard Hartmann wrote:
> On Thu, Oct 16, 2008 at 13:56, Garry Dolley <gdolley@arpnetworks.com> wrote:
>
>
>> I know from an external point of view, it seems pulling a subdir
>> wouldn't be a big deal; but if you look at git internals, you start
>> to realize why it's an option that isn't on the table.
>>
Hm, I don't see a fundamental technical problem which would prevent one
from implementing the ability to checkout only a subdirectory into the
working directory (i.e. to add options to Git to make it reflect the
working directory as being a subdirectory of what is in Git's database).
At this level I don't see anything inherently different from SVN--except
maybe for directory renames: if someone else is renaming the directory
you've checked out, what should happend with your checkout? Git's
filebased rename tracking would just lead to everything vanishing from
your checkout. I don't know what happens in SVN, maybe it keeps track of
the directory rename and still sends you the changes of the directory
you've checked out even if it has now a different name on the server?
Anyway, an unavoidable difference is that you have to always clone the
whole Git *database*. With SVN the database stays on the server, with
Git it is being cloned. Just as I expect SVN to need the whole database
to be able to work (tracking renames across directories etc.), Git needs
the whole database too. So implementing subdirectory workingdir
checkouts wouldn't help reduce the bandwidth and storage necessary for
getting at the database.
>
> That's my understanding as well. And you can simply branch
> out a subdir when you want to work on it.
>
I guess what you are referring to is
$ git clone git://foo.com/bar.git
$ cd bar
$ rm -rf *
$ git checkout somesubdir
Now you've got only somesubdir/ below bar/. This solves the rename
problem insofar, as somesubdir will just be renamed if someone else
commits a "git mv somesubdir somethingelse" and you pull that change.
But there's also another caveat: "git status" will of course report the
other files as deleted, which is an accident waiting to happen when you
next run "git commit -a".
(In any case, this is just thinking louder than I deserve, as there's no
code at all in Git written by me.)
Christian.
^ permalink raw reply
* Re: Detached checkout will clobber branch head when using symlink HEAD
From: Nicolas Pitre @ 2008-10-16 20:30 UTC (permalink / raw)
To: Jeff King; +Cc: Matt Draisey, Junio C Hamano, git
In-Reply-To: <20081016202202.GA9487@coredump.intra.peff.net>
On Thu, 16 Oct 2008, Jeff King wrote:
> On Thu, Oct 16, 2008 at 04:20:32PM -0400, Nicolas Pitre wrote:
>
> > > so almost all my git repositories are still using a symlink HEAD.
> > > I have some old scripts That I use occasionally and still depend on it.
> > > Using detached checkout is the only problem I've had.
> >
> > A symlink HEAD and detached checkouts are simply incompatible.
>
> Agreed, but I think the complaint is not that it doesn't work, but that
> it silently clobbers the current branch when you try it.
That is unacceptable indeed.
Nicolas
^ permalink raw reply
* Re: Working with remotes; cloning remote references
From: Marc Branchaud @ 2008-10-16 20:29 UTC (permalink / raw)
To: git; +Cc: git
In-Reply-To: <eaa105840810161220k26eebd48q8de606597f2be055@mail.gmail.com>
Peter Harris wrote:
>
> "git clone" doesn't have this option, but you can turn it on
> immediately after with something similar to:
> git config --add remote.origin.fetch +refs/remotes/*:refs/remotes/*
> (which I use for fanning-out my git-svn repos)
Thanks for the pointer (and the quick reply).
That doesn't seem to be what I'm looking for, though -- perhaps I'm
missing something? The above puts the remotes in the .git/refs/remotes
directory, but the .git/config file doesn't have them.
More specifically, if I clone the main repository and run the above and
then fetch, then AFAICT I'm still not linked to the external mirrors in
the clone. In particular, I can't refer to an external project in the
subtree pull:
$ git pull -s subtree external2 master
fatal: 'external2': unable to chdir or not a git archive
(Where 'external2' is the name of the remote in the main repo.) Also,
the only remote in the config file is still just the origin.
(As an aside, the above "git config --add" incantation causes problems
if run inside a clone of a clone:
$ git clone main clone-of-main
$ git clone clone-of-main clone-of-clone-of-main
$ cd clone-of-clone-of-main
$ git config --add remote.origin.fetch \
+refs/remotes/*:refs/remotes/*
$ git pull
fatal: refs/remotes/origin/master tracks both
refs/remotes/origin/master and refs/heads/master
)
You did say "something similar" in your reply -- am I not seeing
something obvious?
Marc
^ permalink raw reply
* Re: Detached checkout will clobber branch head when using symlink HEAD
From: Matt Draisey @ 2008-10-16 20:28 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jeff King, Junio C Hamano, git
In-Reply-To: <alpine.LFD.2.00.0810161619330.26244@xanadu.home>
On Thu, 2008-10-16 at 16:20 -0400, Nicolas Pitre wrote:
> A symlink HEAD and detached checkouts are simply incompatible.
Not necessarily. The symlinking code will unlink the original inode
each time it creates a new symlink anyway. It is simply a matter of
creating a new file in its place.
^ permalink raw reply
* [PATCHv6 5/5] gitweb: generate parent..current URLs
From: Giuseppe Bilotta @ 2008-10-16 20:27 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1224188831-17767-5-git-send-email-giuseppe.bilotta@gmail.com>
If use_pathinfo is enabled, href now creates links that contain paths in
the form $project/$action/oldhash:/oldname..newhash:/newname for actions
that use hash_parent etc.
If any of the filename contains two consecutive dots, it's kept as a CGI
parameter since the resulting path would otherwise be ambiguous.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 30 +++++++++++++++++++++++++-----
1 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 1a7b0b9..f4642e7 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -759,7 +759,8 @@ sub href (%) {
# try to put as many parameters as possible in PATH_INFO:
# - project name
# - action
- # - hash or hash_base:/filename
+ # - hash_parent or hash_parent_base:/file_parent
+ # - hash or hash_base:/file_name
# When the script is the root DirectoryIndex for the domain,
# $href here would be something like http://gitweb.example.com/
@@ -778,17 +779,36 @@ sub href (%) {
delete $params{'action'};
}
- # Finally, we put either hash_base:/file_name or hash
+ # Next, we put hash_parent_base:/file_parent..hash_base:/file_name,
+ # stripping nonexistent or useless pieces
+ $href .= "/" if ($params{'hash_base'} || $params{'hash_parent_base'}
+ || $params{'hash_parent'} || $params{'hash'});
if (defined $params{'hash_base'}) {
- $href .= "/".esc_url($params{'hash_base'});
- if (defined $params{'file_name'}) {
+ if (defined $params{'hash_parent_base'}) {
+ $href .= esc_url($params{'hash_parent_base'});
+ # skip the file_parent if it's the same as the file_name
+ delete $params{'file_parent'} if $params{'file_parent'} eq $params{'file_name'};
+ if (defined $params{'file_parent'} && $params{'file_parent'} !~ /\.\./) {
+ $href .= ":/".esc_url($params{'file_parent'});
+ delete $params{'file_parent'};
+ }
+ $href .= "..";
+ delete $params{'hash_parent'};
+ delete $params{'hash_parent_base'};
+ } elsif (defined $params{'hash_parent'}) {
+ $href .= esc_url($params{'hash_parent'}). "..";
+ delete $params{'hash_parent'};
+ }
+
+ $href .= esc_url($params{'hash_base'});
+ if (defined $params{'file_name'} && $params{'file_name'} !~ /\.\./) {
$href .= ":/".esc_url($params{'file_name'});
delete $params{'file_name'};
}
delete $params{'hash'};
delete $params{'hash_base'};
} elsif (defined $params{'hash'}) {
- $href .= "/".esc_url($params{'hash'});
+ $href .= esc_url($params{'hash'});
delete $params{'hash'};
}
}
--
1.5.6.5
^ permalink raw reply related
* [PATCHv6 4/5] gitweb: parse parent..current syntax from PATH_INFO
From: Giuseppe Bilotta @ 2008-10-16 20:27 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1224188831-17767-4-git-send-email-giuseppe.bilotta@gmail.com>
This patch makes it possible to use an URL such as
$project/somebranch..otherbranch:/filename to get a diff between
different version of a file. Paths like
$project/$action/somebranch:/somefile..otherbranch:/otherfile are parsed
as well.
All '*diff' actions and in general actions that use $hash_parent[_base]
and $file_parent can now get all of their parameters from PATH_INFO
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 36 ++++++++++++++++++++++++++++++++++--
1 files changed, 34 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 49730f3..1a7b0b9 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -548,7 +548,12 @@ sub evaluate_path_info {
'history',
);
- my ($refname, $pathname) = split(/:/, $path_info, 2);
+ # horrible regexp to catch
+ # [$hash_parent_base[:$file_parent]..]$hash_parent[:$file_name]
+ my ($parentrefname, $parentpathname, $refname, $pathname) =
+ ($path_info =~ /^(?:(.+?)(?::(.+))?\.\.)?(.+?)(?::(.+))?$/);
+
+ # first, analyze the 'current' part
if (defined $pathname) {
# we got "branch:filename" or "branch:dir/"
# we could use git_get_type(branch:pathname), but it needs $git_dir
@@ -557,7 +562,13 @@ sub evaluate_path_info {
$input_params{'action'} ||= "tree";
$pathname =~ s,/$,,;
} else {
- $input_params{'action'} ||= "blob_plain";
+ # the default action depends on whether we had parent info
+ # or not
+ if ($parentrefname) {
+ $input_params{'action'} ||= "blobdiff_plain";
+ } else {
+ $input_params{'action'} ||= "blob_plain";
+ }
}
$input_params{'hash_base'} ||= $refname;
$input_params{'file_name'} ||= $pathname;
@@ -577,6 +588,27 @@ sub evaluate_path_info {
$input_params{'hash'} ||= $refname;
}
}
+
+ # next, handle the 'parent' part, if present
+ if (defined $parentrefname) {
+ # a missing pathspec defaults to the 'current' filename, allowing e.g.
+ # someproject/blobdiff/oldrev..newrev:/filename
+ if ($parentpathname) {
+ $parentpathname =~ s,^/+,,;
+ $parentpathname =~ s,/$,,;
+ $input_params{'file_parent'} ||= $parentpathname;
+ } else {
+ $input_params{'file_parent'} ||= $input_params{'file_name'};
+ }
+ # we assume that hash_parent_base is wanted if a path was specified,
+ # or if the action wants hash_base instead of hash
+ if (defined $input_params{'file_parent'} ||
+ grep {$input_params{'action'} eq $_} @wants_base) {
+ $input_params{'hash_parent_base'} ||= $parentrefname;
+ } else {
+ $input_params{'hash_parent'} ||= $parentrefname;
+ }
+ }
}
evaluate_path_info();
--
1.5.6.5
^ permalink raw reply related
* [PATCHv6 3/5] gitweb: use_pathinfo filenames start with /
From: Giuseppe Bilotta @ 2008-10-16 20:27 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1224188831-17767-3-git-send-email-giuseppe.bilotta@gmail.com>
When using path info, make filenames start with a / (right after the :
that separates them from the hash base). This minimal change allows
relative navigation to work properly when viewing HTML files in raw
('blob_plain') mode.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 5337d40..49730f3 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -727,7 +727,7 @@ sub href (%) {
# try to put as many parameters as possible in PATH_INFO:
# - project name
# - action
- # - hash or hash_base:filename
+ # - hash or hash_base:/filename
# When the script is the root DirectoryIndex for the domain,
# $href here would be something like http://gitweb.example.com/
@@ -746,11 +746,11 @@ sub href (%) {
delete $params{'action'};
}
- # Finally, we put either hash_base:file_name or hash
+ # Finally, we put either hash_base:/file_name or hash
if (defined $params{'hash_base'}) {
$href .= "/".esc_url($params{'hash_base'});
if (defined $params{'file_name'}) {
- $href .= ":".esc_url($params{'file_name'});
+ $href .= ":/".esc_url($params{'file_name'});
delete $params{'file_name'};
}
delete $params{'hash'};
--
1.5.6.5
^ permalink raw reply related
* [PATCHv6 2/5] gitweb: generate project/action/hash URLs
From: Giuseppe Bilotta @ 2008-10-16 20:27 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1224188831-17767-2-git-send-email-giuseppe.bilotta@gmail.com>
When generating path info URLs, reduce the number of CGI parameters by
embedding action and hash_parent:filename or hash in the path.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 33 ++++++++++++++++++++++++++++++---
1 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 6d0dc26..5337d40 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -724,14 +724,41 @@ sub href (%) {
my ($use_pathinfo) = gitweb_check_feature('pathinfo');
if ($use_pathinfo) {
- # use PATH_INFO for project name
+ # try to put as many parameters as possible in PATH_INFO:
+ # - project name
+ # - action
+ # - hash or hash_base:filename
+
+ # When the script is the root DirectoryIndex for the domain,
+ # $href here would be something like http://gitweb.example.com/
+ # Thus, we strip any trailing / from $href, to spare us double
+ # slashes in the final URL
+ $href =~ s,/$,,;
+
+ # Then add the project name, if present
$href .= "/".esc_url($params{'project'}) if defined $params{'project'};
delete $params{'project'};
- # Summary just uses the project path URL
- if (defined $params{'action'} && $params{'action'} eq 'summary') {
+ # Summary just uses the project path URL, any other action is
+ # added to the URL
+ if (defined $params{'action'}) {
+ $href .= "/".esc_url($params{'action'}) unless $params{'action'} eq 'summary';
delete $params{'action'};
}
+
+ # Finally, we put either hash_base:file_name or hash
+ if (defined $params{'hash_base'}) {
+ $href .= "/".esc_url($params{'hash_base'});
+ if (defined $params{'file_name'}) {
+ $href .= ":".esc_url($params{'file_name'});
+ delete $params{'file_name'};
+ }
+ delete $params{'hash'};
+ delete $params{'hash_base'};
+ } elsif (defined $params{'hash'}) {
+ $href .= "/".esc_url($params{'hash'});
+ delete $params{'hash'};
+ }
}
# now encode the parameters explicitly
--
1.5.6.5
^ permalink raw reply related
* [PATCHv6 1/5] gitweb: parse project/action/hash_base:filename PATH_INFO
From: Giuseppe Bilotta @ 2008-10-16 20:27 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1224188831-17767-1-git-send-email-giuseppe.bilotta@gmail.com>
This patch enables gitweb to parse URLs with more information embedded
in PATH_INFO, reducing the need for CGI parameters. The typical gitweb
path is now $project/$action/$hash_base:$file_name or
$project/$action/$hash
This is mostly backwards compatible with the old-style gitweb paths,
$project/$branch[:$filename], except when it was used to access a branch
whose name matches a gitweb action.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 37 +++++++++++++++++++++++++++++++------
1 files changed, 31 insertions(+), 6 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index c5254af..6d0dc26 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -534,23 +534,48 @@ sub evaluate_path_info {
return if $input_params{'action'};
$path_info =~ s,^\Q$project\E/*,,;
+ # next, check if we have an action
+ my $action = $path_info;
+ $action =~ s,/.*$,,;
+ if (exists $actions{$action}) {
+ $path_info =~ s,^$action/*,,;
+ $input_params{'action'} = $action;
+ }
+
+ # list of actions that want hash_base instead of hash
+ my @wants_base = (
+ 'tree',
+ 'history',
+ );
+
my ($refname, $pathname) = split(/:/, $path_info, 2);
if (defined $pathname) {
- # we got "project.git/branch:filename" or "project.git/branch:dir/"
+ # we got "branch:filename" or "branch:dir/"
# we could use git_get_type(branch:pathname), but it needs $git_dir
$pathname =~ s,^/+,,;
if (!$pathname || substr($pathname, -1) eq "/") {
- $input_params{'action'} = "tree";
+ $input_params{'action'} ||= "tree";
$pathname =~ s,/$,,;
} else {
- $input_params{'action'} = "blob_plain";
+ $input_params{'action'} ||= "blob_plain";
}
$input_params{'hash_base'} ||= $refname;
$input_params{'file_name'} ||= $pathname;
} elsif (defined $refname) {
- # we got "project.git/branch"
- $input_params{'action'} = "shortlog";
- $input_params{'hash'} ||= $refname;
+ # we got "branch". in this case we have to choose if we have to
+ # set hash or hash_base.
+ #
+ # Most of the actions without a pathname only want hash to be
+ # set, except for the ones specified in @wants_base that want
+ # hash_base instead. It should also be noted that hand-crafted
+ # links having 'history' as an action and no pathname or hash
+ # set will fail, but that happens regardless of PATH_INFO.
+ $input_params{'action'} ||= "shortlog";
+ if (grep {$input_params{'action'} eq $_} @wants_base) {
+ $input_params{'hash_base'} ||= $refname;
+ } else {
+ $input_params{'hash'} ||= $refname;
+ }
}
}
evaluate_path_info();
--
1.5.6.5
^ permalink raw reply related
* [PATCHv6 0/5] gitweb: PATH_INFO enhancement
From: Giuseppe Bilotta @ 2008-10-16 20:27 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
Sixth attempt for my gitweb PATH_INFO patchset, whose purpose is to
reduce the use of CGI parameters by embedding as many parameters as
possible in the URL path itself, provided the pathinfo feature is
enabled.
The new typical gitweb URL is therefore in the form
$project/$action/$parent:$file..$hash:$file
(with useless parts stripped). Backwards compatibility for old-style
$project/$hash[:$file] URLs is kept, as long as $hash is not a refname
whose name happens to match a git action.
The main implementation is provided by paired patches (#1#2, #4#5)
that implement parsing and generation of the new style URLs.
Patch #3 is a minor improvement to the URL syntax that allows web
sites to be properly browsable in raw mode.
The patchset depends on my previous input parameter handling patch
currently waiting in 'next'. This resend fixes a couple of problems
I found in v5.
Giuseppe Bilotta (5):
gitweb: parse project/action/hash_base:filename PATH_INFO
gitweb: generate project/action/hash URLs
gitweb: use_pathinfo filenames start with /
gitweb: parse parent..current syntax from PATH_INFO
gitweb: generate parent..current URLs
gitweb/gitweb.perl | 124 +++++++++++++++++++++++++++++++++++++++++++++++----
1 files changed, 114 insertions(+), 10 deletions(-)
^ 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