* Re: git over webdav: what can I do for improving http-push ?
From: Grégoire Barbier @ 2008-01-03 23:29 UTC (permalink / raw)
To: git
In-Reply-To: <200801032247.02323.jnareb@gmail.com>
Jakub Narebski a écrit :
> Perhaps we could use AJAX (XMLHttpRequest for communication, plain HTTP or
> IFRAMES for sending data) or something like this for git protocol tunneling?
>
well... I think I may manage to avoid javascript... ;-)
more seriously, I was thinking of using http in an automated,
un-human-browsable manner, not a full html user interface.
--
Grégoire Barbier - gb à gbarbier.org - +33 6 21 35 73 49
^ permalink raw reply
* Re: [PATCH ugit] Allow user to choose history browser tool
From: Jeff King @ 2008-01-03 22:39 UTC (permalink / raw)
To: Marco Costalba; +Cc: davvid, Git Mailing List
In-Reply-To: <e5bfff550801030408w1512e458x136f6be0371c13c2@mail.gmail.com>
On Thu, Jan 03, 2008 at 01:08:17PM +0100, Marco Costalba wrote:
> Instead of hard linking gitk let the user set
> the preferred history visualization tool in settings dialog.
This is the exact situation that the 'git view' builtin alias was
designed for. If every porcelain which spawned a viewer used 'git view',
then the user would only need to configure one place (but note that 'git
view' has never even made it out of next, so I am not recommending it
instead of your patch, but just making a note).
-Peff
^ permalink raw reply
* Re: [PATCH 3/2] attribute "coding": specify blob encoding
From: Junio C Hamano @ 2008-01-03 21:54 UTC (permalink / raw)
To: しらいしななこ
Cc: Tsugikazu Shibata, git
In-Reply-To: <200801032128.m03LSIn2022902@mi0.bluebottle.com>
しらいしななこ <nanako3@bluebottle.com> writes:
> Quoting Junio C Hamano <gitster@pobox.com>:
>
>> This teaches "diff hunk header" function about custom character
>> encoding per path via gitattributes(5) so that it can sensibly
>> chomp a line without truncating a character in the middle.
>>
>> Signed-off-by: Junio C Hamano <gitster@pobox.com>
>> ---
>>
>> * This is not intended for serious inclusion, but was done more
>> as a demonstration of the concept, hence [3/2].
>
> Why not? It looks a useful addition for us Japanese people.
(offtopic) I was once told that "us Japanese people" is a
bad thing to say in public because it sets an unfriendly
tone by creating a psychological divide between "us" and
"others". After all I am one of you ;-)
The reason I do not like the patch as-is is because I have
doubts about the way "coding" acts in the patch.
There already is clean/smudge filter mechanism. Even if your
work tree has files in euc-jp or Shift_JIS, you could choose to
internally use UTF-8 at git object level. Then the part that
deals with diff hunk headers (the topic of the patch we are
discussing) would have to work only on UTF-8 data.
Side note: when getting the data from a file in the work
tree, we convert into internal representation before
running diff (see diff.c::diff_populate_filespec()), but
we do not convert it back to external representation by
running the smudge filter on the diff output. We might
optionally want to but if somebody is going to do this,
the patch accepting side also needs to be modified to
reverse the conversion.
The solution with clean/smudge is not applicable to everybody.
It needs to be agreed upon project-wide what encoding is used as
the canonical encoding for the project, and when the project
chooses to use UTF-8, the above would become a cleaner and
workable approach.
If the project, on the other hand, chooses to use a non UTF-8
encoding (e.g. euc-jp) as the canonical representation,
something like my patch may be necessary.
Between these two ways to skin the cat, I do not want to close
the door for either one of them too early, although I am
somewhat partial to "internally everything is UTF-8" approach.
Maybe we would want to use "coding" (short, sweet and nice name
for an attribute) to mean a canned smudge/clean filter pair that
runs to/from UTF-8 iconv, making the "internally, everything is
UTF-8" approach a more officially supported option. If we
choose to go that route, the way "coding" attribute was used in
the patch directly conflicts with that design, as the world view
my "coding" patch takes is "whatever coding project chooses is
used internally, and the attribute is used to teach coding
specific actions to the underlying logic".
>> +static struct {
>> + const char *coding;
>> + sane_truncate_fn fn;
>> +} builtin_truncate_fn[] = {
>> + { "euc-jp", truncate_euc_jp },
>> + { "utf-8", NULL },
>> +};
>
>Can you also do JIS and Shift JIS? I ask because many of my
>old notes are in Shift JIS and I think it is the same for many
>other people.
I guess somebody else could (hint, hint,...). Shift_JIS should
be more or less straightforward to add.
With the current code structure, however, ISO-2022 (you said
"JIS" -- Japanese often use that word to mean 7-bit ISO-2022 and
so did you in this context) is a bit cumbersome to handle, as
you cannot just truncate but also have to add a few escape bytes
to go back to ASCII at the end of line.
^ permalink raw reply
* Re: git over webdav: what can I do for improving http-push ?
From: Jakub Narebski @ 2008-01-03 21:47 UTC (permalink / raw)
To: Jan Hudec; +Cc: Grégoire Barbier, git
In-Reply-To: <20080103211521.GA4225@efreet.light.src>
Jan Hudec wrote:
> On Thu, Jan 03, 2008 at 20:14:09 +0100, Grégoire Barbier wrote:
>
> > I had a quick look on bzr and hg, and it seems that bzr use the easy way
> > (walker, no optimizations)
>
> That's not quite true -- bzr has both dumb (walker over plain HTTP) and smart
> (CGI) methods. But their CGI is really just tunelling their custom protocol
> over HTTP and that protocol will not be anywhere near what we want for git
> because of vastly different design of the storage.
Perhaps we could also simply tunnel git protocol over HTTP / HTTPS?
> > and hg a cgi (therefore, maybe optimizations).
> > By quick look I mean that I sniff the HTTP queries on the network during a
> > clone. I need to look harder...
>
> Yes, mercurial uses a CGI. But I am not sure how similar their approach is to
> anything that would make sense for git, so looking at the details might or
> might not be useful.
>
> > BTW I never looked at the git:// protocol. Do you think that by tunneling
> > the git protocol in a cgi (hg uses URLs of the form
> > "/mycgi?cmd=mycommand&...", therefore I think "tunnel" is not a bad
> > word...) the performance would be good?
>
> It would be pretty hard to tunnel it and it would loose all it's nice
> properties. The git protocol, for pull, basically works like this:
>
> - server sends a list of it's refs
> - client tells server which ones it wants
> - client starts listing revisions it has, newest to oldest
> - server tells client whenever it finds common ancestor with one of the
> heads desired
> - client restarts the listing from next ref
> - server starts sending the data when client runs out of refs to list
>
> The main point about the protocol is, that the client is listing the refs, as
> fast as it can and server will stop it when it sees a revision it knows.
> Therefore there will only be one round-trip to discover each common ancestor.
>
> However, you can't do this over HTTP, because response won't be started until
> the request is received. You could be sending a lot of smallish requests and
> quick, often empty, responses to them. However, that will waste a lot of
> bandwidth (because of the HTTP overhead) and loose much of the speed anyway.
> Also the HTTP protocol is stateless, but this is inherently stateful, so you
> would have to work that around somehow too. Therefore a different approach is
> preferable on HTTP.
Perhaps we could use AJAX (XMLHttpRequest for communication, plain HTTP or
IFRAMES for sending data) or something like this for git protocol tunneling?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: git over webdav: what can I do for improving http-push ?
From: Linus Torvalds @ 2008-01-03 21:43 UTC (permalink / raw)
To: Jan Hudec; +Cc: Grégoire Barbier, Jakub Narebski, git
In-Reply-To: <20080103211521.GA4225@efreet.light.src>
On Thu, 3 Jan 2008, Jan Hudec wrote:
>
> That's not quite true -- bzr has both dumb (walker over plain HTTP) and smart
> (CGI) methods. But their CGI is really just tunelling their custom protocol
> over HTTP and that protocol will not be anywhere near what we want for git
> because of vastly different design of the storage.
Well, tunnelling the native git protocol is *exactly* what you'd want to
do with some git CGI thing. So no, I don't think the actual stuff you
tunnel would have any relationship, but the actual code to set up a tunnel
and making it all look like some fake html sequence might be something
that can be used as a base.
Linus
^ permalink raw reply
* Re: [PATCH] receive-pack: reject invalid refnames
From: Junio C Hamano @ 2008-01-03 21:40 UTC (permalink / raw)
To: Martin Koegler; +Cc: git
In-Reply-To: <1199310726946-git-send-email-mkoegler@auto.tuwien.ac.at>
Martin Koegler <mkoegler@auto.tuwien.ac.at> writes:
> Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
> ---
> receive-pack.c | 7 +++++--
> 1 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/receive-pack.c b/receive-pack.c
> index d0a563d..a038a40 100644
> --- a/receive-pack.c
> +++ b/receive-pack.c
> @@ -165,7 +165,9 @@ static const char *update(struct command *cmd)
> unsigned char *new_sha1 = cmd->new_sha1;
> struct ref_lock *lock;
>
> - if (!prefixcmp(name, "refs/") && check_ref_format(name + 5)) {
> + /* only HEAD and refs/... are allowed */
> + if (strcmp(name, "HEAD") &&
> + (prefixcmp(name, "refs/") || check_ref_format(name + 5))) {
> error("refusing to create funny ref '%s' remotely", name);
> return "funny refname";
> }
> @@ -177,7 +179,8 @@ static const char *update(struct command *cmd)
> }
> if (deny_non_fast_forwards && !is_null_sha1(new_sha1) &&
> !is_null_sha1(old_sha1) &&
> - !prefixcmp(name, "refs/heads/")) {
> + (!prefixcmp(name, "refs/heads/") ||
> + !strcmp(name, "HEAD"))) {
> struct object *old_object, *new_object;
> struct commit *old_commit, *new_commit;
> struct commit_list *bases, *ent;
Yuck. What I was smoking.
Normal client "git push" does not even allow "git push victim
foo:HEAD". So if name is "HEAD" that has to be a malicious
crafted push.
I think
if (prefixcmp(name, "refs/") || check_ref_format(name + 5))
error();
is enough and correct.
Sorry for my earlier thinko.
^ permalink raw reply
* Re: [bug] Working files created in bare repository when pushing to a rewound bare repository
From: Junio C Hamano @ 2008-01-03 21:29 UTC (permalink / raw)
To: Jeff King; +Cc: Ping Yin, Git Mailing List
In-Reply-To: <20071231072632.GA11451@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> And then on top of this (plus one-liner fix I posted), as Ping Yin
> suggested, we can do:
>
> -- >8 --
> git-reset: default to --soft in a bare repo
>
> --mixed doesn't make sense, since we don't generally have an
> index.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> This is a bit more contentious. There's no reason you can't have an
> index in a bare repo, and this is changing the behavior of those who do.
> They can always explicitly specify --mixed (since we haven't disallowed
> that), but it might break some scripts.
I'd prefer to error out if something does not make sense rather
than defaulting differently depending on the bareness of the
repository, but that is probably the matter of taste.
Please re-raise the issue post 1.5.4
^ permalink raw reply
* Re: [PATCH] git-filter-branch could be confused by similar names
From: Junio C Hamano @ 2008-01-03 21:27 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: git, Johannes Schindelin
In-Reply-To: <1199040667-31850-1-git-send-email-dpotapov@gmail.com>
Dmitry Potapov <dpotapov@gmail.com> writes:
> 'git-filter-branch branch' could fail producing the error:
> "Which ref do you want to rewrite?" if existed another branch
> or tag, which name was 'branch-something' or 'something/branch'.
>
> Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
> ---
>
> I have corrected my previous patch to allow "heads" or "tags"
> in the name of a branch or tag, i.e. to write it like this:
> git filter-branch heads/master
>
> git-filter-branch.sh | 2 +-
> t/t7003-filter-branch.sh | 10 ++++++++++
> 2 files changed, 11 insertions(+), 1 deletions(-)
>
> diff --git a/git-filter-branch.sh b/git-filter-branch.sh
> index dbab1a9..5de8b12 100755
> --- a/git-filter-branch.sh
> +++ b/git-filter-branch.sh
> @@ -219,7 +219,7 @@ do
> ;;
> *)
> ref="$(git for-each-ref --format='%(refname)' |
> - grep /"$ref")"
> + grep '^refs/\([^/]\+/\)\?'"$ref"'$')"
> esac
Do we assume everybody's grep groks ERE these days? I had an
impression that we try to stick to a subset of BRE (namely, no
\{m,n\}, [::], [==], nor [..]).
Also as a general rule when dealing with refname, we use
fileglob not regex.
What's the goal here? Is it to make sure given refname is
unambiguous by being a unique suffix of tags or heads, as in
test $(git show-ref "$ref" | wc -l) = 1
or is there anything more going on?
Ah, it also wants the full name of the ref. How about...
ref=$(git show-ref "$ref" | sed -e 's/^.* //')
and have the "git check-ref-format" that comes later to issue an
error message?
A better error message would be obtained with perhaps doing
LF='
'
at the beginning and then doing:
candidate=$(git show-ref "$ref" | sed -e 's/^.* //')
case "$candidate" in
'')
die "should not happen -- $ref did not match?"
;;
?*"$LF"?*)
die "$ref is ambiguous, which one of: $canidate?"
;;
esac
ref=$candidate
^ permalink raw reply
* Re: [PATCH 3/2] attribute "coding": specify blob encoding
From: しらいしななこ @ 2008-01-03 21:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Tsugikazu Shibata, git
In-Reply-To: <7vsl1gy2si.fsf@gitster.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>:
> This teaches "diff hunk header" function about custom character
> encoding per path via gitattributes(5) so that it can sensibly
> chomp a line without truncating a character in the middle.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>
> * This is not intended for serious inclusion, but was done more
> as a demonstration of the concept, hence [3/2].
Why not? It looks a useful addition for us Japanese people.
> +static struct {
> + const char *coding;
> + sane_truncate_fn fn;
> +} builtin_truncate_fn[] = {
> + { "euc-jp", truncate_euc_jp },
> + { "utf-8", NULL },
> +};
Can you also do JIS and Shift JIS? I ask because many of my old notes are in Shift JIS and I think it is the same for many other people.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
----------------------------------------------------------------------
Get a free email account with anti spam protection.
http://www.bluebottle.com/tag/2
^ permalink raw reply
* Re: git over webdav: what can I do for improving http-push ?
From: Jan Hudec @ 2008-01-03 21:15 UTC (permalink / raw)
To: Grégoire Barbier; +Cc: Jakub Narebski, git
In-Reply-To: <477D3401.2010005@gbarbier.org>
On Thu, Jan 03, 2008 at 20:14:09 +0100, Grégoire Barbier wrote:
> Jan Hudec a écrit :
[...]
>> It is what bzr and mercurial do and I think it would be quite good way to go
>> for cases like this.
> Ok, I will have to look at bzr and mercurial...
Bzr is quite far, design-wise, I fear. The mercurial might be a little more
interesting to study, but being in python and internally somewhat
file-oriented, I wouldn't think it is of much use.
You should start with upload, leaving the download direction to the dumb
machinery git currently uses.
[...]
>> I have also thought about optimizing download using CGI, but than I thought,
>> that maybe there is a way to statically generate packs so, that if the client
>> wants n revisions, the number of revisions it downloads is O(n) and the
>> number of packs it gets them from (and thus number of round-trips) is
>> O(log(n)). Assuming the client always wants everything up to the tip, of
>> course. Now this is trivial with linear history (pack first half, than half
>> of what's left, etc., gives logarithmic number of packs and you always
>> download at most twice as much as you need), but it would be nice if somebody
>> found a way (even one that satisfies the conditions on average only) to do
>> this with non-linear history, it would be very nice improvement to the http
>> download -- native git server optimizes amount of data transfered very well,
>> but at the cost of quite heavy CPU load on the server.
>>
> Well... frankly I don't think I'm able of such things.
> Writing a walker over webdav or a simple cgi is a thing I can do (I
> think), but I'm not tought enough (or not ready to take the time needed)
> to have a look on the internals of packing revisions (whereas I can imagine
> it would means that "my" walker would be suitable only for small projects
> in terms of code amount and commit frequency).
Well, it does not depend on the walker -- the walker is quite simple and
already written anyway.
> I had a quick look on bzr and hg, and it seems that bzr use the easy way
> (walker, no optimizations)
That's not quite true -- bzr has both dumb (walker over plain HTTP) and smart
(CGI) methods. But their CGI is really just tunelling their custom protocol
over HTTP and that protocol will not be anywhere near what we want for git
because of vastly different design of the storage.
> and hg a cgi (therefore, maybe optimizations).
> By quick look I mean that I sniff the HTTP queries on the network during a
> clone. I need to look harder...
Yes, mercurial uses a CGI. But I am not sure how similar their approach is to
anything that would make sense for git, so looking at the details might or
might not be useful.
> BTW I never looked at the git:// protocol. Do you think that by tunneling
> the git protocol in a cgi (hg uses URLs of the form
> "/mycgi?cmd=mycommand&...", therefore I think "tunnel" is not a bad
> word...) the performance would be good?
It would be pretty hard to tunnel it and it would loose all it's nice
properties. The git protocol, for pull, basically works like this:
- server sends a list of it's refs
- client tells server which ones it wants
- client starts listing revisions it has, newest to oldest
- server tells client whenever it finds common ancestor with one of the
heads desired
- client restarts the listing from next ref
- server starts sending the data when client runs out of refs to list
The main point about the protocol is, that the client is listing the refs, as
fast as it can and server will stop it when it sees a revision it knows.
Therefore there will only be one round-trip to discover each common ancestor.
However, you can't do this over HTTP, because response won't be started until
the request is received. You could be sending a lot of smallish requests and
quick, often empty, responses to them. However, that will waste a lot of
bandwidth (because of the HTTP overhead) and loose much of the speed anyway.
Also the HTTP protocol is stateless, but this is inherently stateful, so you
would have to work that around somehow too. Therefore a different approach is
preferable on HTTP.
Now to keep it stateless, I thought that:
- client would first ask for list of refs
- client would than ask for pack containing the first ref
- server would respond with pack containing just that commit plus all
objects that are not referenced by any of it's parents
- if client does not have it's parent, it would ask for pack containing that
- since it's second request, server would pack 2 revisions (with necessary
objects) this time
- if client still does not have all parents, it would again ask for a pack,
receiving 4 revisions this time (next 8, 16, etc...)
This would guarantee, that when you want n revisions, you make at most
log2(n) requests and get at most 2*n revisions (well, the requests are for
each ref separately, so it's more like m*log2(n) where m is number of refs,
but still). Additionally, it would be stateless, because the client would
simply say 'I want commit abcdef01 and this is my 3rd request' and server
would provide that commit and 7 it's parents (ie. 2^3 commits).
Now generating the packs takes it's CPU. The servers like git.kernel.org have
quite high CPU load. But in this schema, all clients would most of the time
get the same packs (unlike native git protocol, where the client always gets
single pack with exactly what it needs). So the idea struck me, that they
could simply be statically generated and fetched via the existing dumb
protocol. It would get the efficiency and save a lot of CPU power, which
is allows one to serve quite busy git repository from a limited (and
therefore cheap) virtual machine or even (yes, I saw such idea on the list)
serving any repository from NSLU2.
Now to create a packing policy to create such packs, you don't actually need
to touch any C -- because git-repack is still in shell -- and you don't
really need to touch any internals, because you only need to change how the
pack-objects command will be called and leave all the dirty details to that
command.
I would personally not re-split the already generated packs. Only find some
algorithm for choosing when packs are deep enough in history so they should
be merged together. It would also might not make sense to ever pack unpacked
objects to more than one pack -- a dumb-HTTP-served might have a requirement
of running this kind of repack after every push and clients will rarely have
part of single push to the server.
> Maybe it's not that hard to write a performant HTTP/CGI protocol for Git if
> it's based upon existing code such as the git protocol.
For push it might, or might not be easy. But in the worst case you should be
able to calculate a pack to upload locally (fetching from the server
beforehead if necessary), upload that pack (or bundle) and update all the
refs.
For pull it certainly won't be. You might be able to reimplement the common
ref discovery using some kind of gradually increasing ref list and then
generate a bundle for the server, but optimizing the dumb protocol seems more
useful to me. As I said, generating the packs only requires devising a way of
selecting which objects should go together and git pack-objects will take
care of the dirty details of generating the packs and git update-server-info
will take care of the dirty details of presenting the list of packs to
client.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
^ permalink raw reply
* Re: [PATCH] Documentation: rename gitlink macro to linkgit
From: Junio C Hamano @ 2008-01-03 21:01 UTC (permalink / raw)
To: Dan McGee; +Cc: srackham, Eric Hanchrow, Miklos Vajna, git, asciidoc-discuss
In-Reply-To: <47767710.7040405@gmail.com>
Dan McGee <dpmcgee@gmail.com> writes:
>>From 68bf426e810e732ff3f9f75ffcd69f777b538685 Mon Sep 17 00:00:00 2001
> From: Dan McGee <dpmcgee@gmail.com>
> Date: Sat, 29 Dec 2007 00:20:38 -0600
> Subject: [PATCH] Documentation: rename gitlink macro to linkgit
>
> Between AsciiDoc 8.2.2 and 8.2.3, the following change was made to the stock
> Asciidoc configuration:
>
> @@ -149,7 +153,10 @@
> # Inline macros.
> # Backslash prefix required for escape processing.
> # (?s) re flag for line spanning.
> -(?su)[\\]?(?P<name>\w(\w|-)*?):(?P<target>\S*?)(\[(?P<attrlist>.*?)\])=
> +
> +# Explicit so they can be nested.
> +(?su)[\\]?(?P<name>(http|https|ftp|file|mailto|callto|image|link)):(?P<target>\S*?)(\[(?P<attrlist>.*?)\])=
> +
> # Anchor: [[[id]]]. Bibliographic anchor.
> (?su)[\\]?\[\[\[(?P<attrlist>[\w][\w-]*?)\]\]\]=anchor3
> # Anchor: [[id,xreflabel]]
>
> This default regex now matches explicit values, and unfortunately in this
> case gitlink was being matched by just 'link', causing the wrong inline
> macro template to be applied. By renaming the macro, we can avoid being
> matched by the wrong regex.
What's already tagged, released to the wild and picked up by
distros cannot be taken back, so I'd most likely have to apply
your patch anyway, but I have to say I am not very amused. I'd
call this a regression on AsciiDoc's part.
I would have expected some courtesy to make sure that updates to
AsciiDoc would not to break existing users, especially the ones
that they use as the top advertising material in the "Projects
using AsciiDoc" list at http://www.methods.co.nz/asciidoc/ ;-)
Stuart, is there anything we can help you to set up some
automated tests to catch AsciiDoc regression, so we do not have
to suffer like this again?
^ permalink raw reply
* Re: git xinet service setup questions
From: Junio C Hamano @ 2008-01-03 20:35 UTC (permalink / raw)
To: Scott L Baker; +Cc: git, torvalds
In-Reply-To: <827742.53287.qm@web56014.mail.re3.yahoo.com>
Scott L Baker <freecycler23@yahoo.com> writes:
> This is probably a simple mistake on my part.. so apologies in advance..
>
> I am trying to setup a git server and I have a few questions.
> My sys-admin (I do not have root access) setup an xinet service, e.g.
Addressing individuals for this kind of help requests is an
inefficient way to resolve problems. I've tried to spawn
git-daemon from inetd just as a test to make sure it works in
the past, but I personally never have run xinetd.
You would have better luck finding somebody who have used xinetd
to run git-daemon if you asked git@vger.kernel.org mailing list,
which you can send mails to without subscribing yourself.
Having said that...
>>> cat /etc/xinetd.d/git-daemon
>
> # default: off
> # description: The git server offers access to git repositories service git
> service git
> {
> disable = no
> type = UNLISTED
> port = 9418
> socket_type = stream
> wait = no
> user = nobody
> server = /usr/intel/bin/git-daemon
> server_args = --inetd --syslog --export-all --base-path=/git
> log_on_failure += USERID
> }
>
> I then created a repo in /git/myrepo and tried to clone it..
>
>>> git clone git://plxc1214.pdx/git/myrepo
>
> Initialized empty Git repository in /users/myuser/junk/myrepo/.git/
> fatal: The remote end hung up unexpectedly
> fetch-pack from 'git://plxc1214.pdx/git/myrepo' failed.
>
> Is the xinet service setup correctly?
> What is the correct syntax for cloning from the local xinet service?
>
> Thanks,
> Scott L Baker
The first thing you would want to try is to see if it is xinetd
or git-daemon that is misconfigured. Try running the daemon
without xinetd involved and see if you can access the
repository. I think there is something in Documentation/howto/*
on running the daemon.
The --base-path is used to hide the (often unsightly) leading
prefix from the general public. If you are trying to fetch from
git://plxc1214.pdx/git/myrepo, the --base-path I see in your
configuration would mean the repository is at /git/git/myrepo
directory on the filesystem. Is it the case? Does it help to
try cloning from git://plxc1214.pdx/myrepo instead?
^ permalink raw reply
* Re: git weird pulling issue
From: Cyrill Gorcunov @ 2008-01-03 20:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT-LIST
In-Reply-To: <7vprwiptmx.fsf@gitster.siamese.dyndns.org>
[Junio C Hamano - Thu, Jan 03, 2008 at 11:59:50AM -0800]
| Cyrill Gorcunov <gorcunov@gmail.com> writes:
|
| > so i hold only Linus's and Ingo's changes in repo not mine.
|
| Thanks. I think I know exactly what is going on.
|
| BTW, do not drop git@vger.kernel.org from the CC: list without a
| good reason, please. Otherwise I'd be spending my time *solely*
| to help you, in which case I have to charge you for my time ;-)
|
oops ;) actually it wouldn't be a problem if (1) i've a well-paid
work and (2) wouldn't live in Russia (from where is no simple way to
pass a bit of charge to anyone from a regular men ;) So i prefer
to keep git@ then ;)
| If you find this message useful, you may forward it back to the
| list along with your message I am responding to.
|
| Here is what is happening.
|
| (0) Ingo has this:
|
| A---B (== I)
| /
| ----o---o---o---L
|
| where L is the tip of Linus at some point, I is his changes
| for x86. You pull and get the same thing. Your local x86
| tip points at commit B.
|
| (1) Then Linus advances and Ingo rebases. Updated Linus's tip
| is at L' and Ingo has old patches rebased (A' and B') while
| he added more changes (C and D). His tip is at I'.
|
| A---B (==I) A'--B'--C---D (==I')
| / /
| ----o---o---o---L---o---o---L'
|
| (2) You pull. What is involved is:
|
| * git-pull is just "git fetch" followed by "git merge", and
| in your repository "git fetch" can be configured to use a
| remote tracking branch to keep track of Ingo's progress
| (but I suspect you don't). Your "git branch" output
| shows your local branches, and "git branch -r" would show
| these remote tracking branches.
|
| * The remote tracking is typically configured in
| .git/config and would look like this:
|
| [remote "mingo"]
| url = git://git.kernel.org/pub/...
| fetch = refs/heads/*:refs/remotes/mingo/*
|
| Although I _suspect_ you do not have it (your $ipull
| script pulls with explicit URL without using configured
| information).
|
| The above (for normal people who have the tracking set up)
| fetches the branch tip's from Ingo, and store them in
| corresponding places in .git/refs/remotes/mingo/; his 'mm'
| branch will be stored in .git/refs/remotes/mingo/mm.
|
| But remote.mingo.fetch configuration above does not start
| with '+' (e.g. "+refs/heads/*:refs/remotes/mingo/*", which
| means "do allow non-fast-forward"). For people with such
| configuration, "git pull" from him will fail because
| remotes/mingo/mm points at commit B before you initiated
| the fetch and now it points at D which is _NOT_ a
| descendant of B.
|
| His recommendation about --force applies _ONLY_ to override
| this, and allow your remote tracking branch that used to
| point at B to be replaced to point at D. I suspect it does
| not even apply to you as I do not think you are using
| remote tracking branch at all.
|
| In any case, once "git fetch" completes, "git merge"
| happens. --force does not affect this step at all.
|
| What's merged?
|
| Your 'x86' branch is still at B and you try to merge D into
| it.
|
| .-------------------*
| / /
| A---B A'--B'--C---D
| / /
| ----o---o---o---L---o---o---L'
|
| Because Ingo's tree was rebased, the resulting merge wants
| to have both versions of A and B (the original and the
| rebased). As corresponding patches (say A and A') would
| want to touch same parts of the code, and Ingo may have
| improved the latter while all of this has been happening
| (i.e. A and A' may not be literal rebase but can do things
| differently), it will inevitably conflict with each other.
|
| Even though the conflict resolution would be trivial (you would
| basically want to pick what's from A' over A), this is not what
| you would typically want to happen. When dealing with a
| rebasing upstream, you often do not want to merge but instead
| rebase yourself.
|
| So backing up a bit, here is how people would follow rebasing
| upstream:
|
| (0) Ingo has this:
|
| A---B (== I)
| /
| ----o---o---o---L
|
| where L is the tip of Linus at some point, I is his changes
| for x86. You pull and get the same thing. Your local x86
| tip points at commit B.
|
| (1) You develop on top of Ingo (although you hinted in your
| description that you are strictly following, that is just a
| degenerated case of this where (X,Y,Z) is empty in this
| picture):
|
| X---Y---Z
| /
| A---B (== I)
| /
| ----o---o---o---L
|
| (2) Then Linus advances and Ingo rebases. Updated Linus's tip
| is at L' and Ingo has old patches rebased (A' and B') while
| he added more changes (C and D). His tip is at I'.
|
| A---B (==I) A'--B'--C---D (==I')
| / /
| ----o---o---o---L---o---o---L'
|
| (3) You do not pull but instead fetch from Ingo to get what
| happened outside your tree.
|
| X---Y---Z
| /
| A---B (==I) A'--B'--C---D (==I')
| / /
| ----o---o---o---L---o---o---L'
|
| Note that your 'x86' is at Z and Ingo's tip is now at D.
|
| (4) You rebase on top of Ingo's updated tip.
|
| X'--Y'--Z'
| /
| A---B (==I) A'--B'--C---D (==I')
| / /
| ----o---o---o---L---o---o---L'
|
|
| I was told that our user manual is very good these days covering
| both workflows based on merges and workflows based on rebases.
| You may want to check it and also git-rebase(1).
|
thanks Junio, and sorry for git@ list being dropped from CC.
(didn't read this message in details) so i'll write you/git-list ASAP.
Thanks a lot!
- Cyrill -
^ permalink raw reply
* Re: git over webdav: what can I do for improving http-push ?
From: Grégoire Barbier @ 2008-01-03 19:14 UTC (permalink / raw)
To: Jan Hudec, Jakub Narebski; +Cc: git
In-Reply-To: <20080101202352.GA4295@efreet.light.src>
Jan Hudec a écrit :
> On Tue, Jan 01, 2008 at 10:12:28 -0800, Jakub Narebski wrote:
>
>> Grégoire Barbier <gb@gbarbier.org> writes:
>>
>>
>>> I think that real HTTP support is better than all workarounds we
>>> will be able to find to get through firewalls (when CONNECT is not
>>> available, some awful VPNs that send Etherne over HTTP may work
>>> ;-)). That's why I'm ok to work several hours on git code to
>>> enhance real HTTP(S) support.
>>>
>> There was also an idea to create a CGI program, or enhance gitweb
>> to use for pushing. I don't know if it would be better way to pursue
>> to work around corporate firewalls, or not...
>>
I subscribe to this point of view.
I will look at the list archive to search for what has been said before
about this.
>
> It is what bzr and mercurial do and I think it would be quite good way to go
> for cases like this.
Ok, I will have to look at bzr and mercurial...
> Eg. while our corporate firewall does allow anything
> through connect on 443 (so I can use ssh that way), it does *not* support
> web-dav in non-ssl mode. So I eg. can't even get from public subversion
> repositories at work.
>
> I have also thought about optimizing download using CGI, but than I thought,
> that maybe there is a way to statically generate packs so, that if the client
> wants n revisions, the number of revisions it downloads is O(n) and the
> number of packs it gets them from (and thus number of round-trips) is
> O(log(n)). Assuming the client always wants everything up to the tip, of
> course. Now this is trivial with linear history (pack first half, than half
> of what's left, etc., gives logarithmic number of packs and you always
> download at most twice as much as you need), but it would be nice if somebody
> found a way (even one that satisfies the conditions on average only) to do
> this with non-linear history, it would be very nice improvement to the http
> download -- native git server optimizes amount of data transfered very well,
> but at the cost of quite heavy CPU load on the server.
>
Well... frankly I don't think I'm able of such things.
Writing a walker over webdav or a simple cgi is a thing I can do (I
think), but I'm not tought enough (or not ready to take the time
needed) to have a look on the internals of packing revisions (whereas I
can imagine it would means that "my" walker would be suitable only for
small projects in terms of code amount and commit frequency).
I had a quick look on bzr and hg, and it seems that bzr use the easy way
(walker, no optimizations) and hg a cgi (therefore, maybe
optimizations). By quick look I mean that I sniff the HTTP queries on
the network during a clone. I need to look harder...
BTW I never looked at the git:// protocol. Do you think that by
tunneling the git protocol in a cgi (hg uses URLs of the form
"/mycgi?cmd=mycommand&...", therefore I think "tunnel" is not a bad
word...) the performance would be good?
Maybe it's not that hard to write a performant HTTP/CGI protocol for Git
if it's based upon existing code such as the git protocol.
--
Grégoire Barbier - gb à gbarbier.org - +33 6 21 35 73 49
^ permalink raw reply
* Re: git weird pulling issue
From: Junio C Hamano @ 2008-01-03 17:51 UTC (permalink / raw)
To: Cyrill Gorcunov; +Cc: git
In-Reply-To: <20080103121114.GE8046@cvg>
Cyrill Gorcunov <gorcunov@gmail.com> writes:
> Hi git-list,
>
> i've a weird problem with pulling remote tree. look i've linus's tree
> as a base repo. then i've created x86 branch to which i pulled
> ingo's x86 tree. So all further pulling is made over this branch.
> And even having '--force' option at moment of pulling changes from
> Ingo's tree i've got something like that:
>
> ---
> cyrill@cvg linux-2.6-x86.git $ ./git-update.sh
> Updating "x86"
> remote: Generating pack...
> remote: Done counting 15 objects.
> Result has 9 objects.
> remote: Deltifying 9 objects...
> remote: /9) done/9) done
> remote: Total 9 (delta 7), reused 3 (delta 1)
> Unpacking 9 objects...
> 100% (9/9) done
> Auto-merged include/asm-x86/msr.h
> CONFLICT (content): Merge conflict in include/asm-x86/msr.h
> Auto-merged include/linux/ptrace.h
> Auto-merged kernel/ptrace.c
> Automatic merge failed; fix conflicts and then commit the result.
To your readers, "./git-update.sh" is a mystery script; nobody
knows what you are doing in there.
A handful points that might help anybody who wants to be
helpful.
* The state your repository is in is a bit vague. Let me try
to rephrase your introductory part and see if I understood
your history.
* It started as a clone from Linus's
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
* You say you created x86 branch (local) to which you pull
Ingo's (I do not see any tree other than scheduler ones
under git/mingo/), but it is unclear what this branch's
history looks like.
Was it done by
git checkout -b x86
git pull git://.../mingo/x86/ master
If so, (1) was the initial x86 before the first pull
pristine Linus tree? (2) was the initial x86 pull
fast-forward?
* I am suspecting that git-update.sh is a wrapper around
git-pull that does something like:
git checkout x86 &&
git pull git://.../mingo/x86/ master
Do you have remote tracking information for Ingo's
repository? If so how does it look like?
Do you have your own changes in your x86 branch? Do they
conflict with Ingo's change, IOW, is the conflict above just
a normal thing to expect? What makes you think there should
not be any conflict?
There are a few reasons I can think of that can cause conflicts.
- (obvious) you have your own changes that the tree you are
pulling from have colliding changes;
* the tree you are pulling from has rebased;
The --force is about allowing git-fetch to update the remote
tracking branches (if you use them) even when the tracking
information is not fast-forward. Without --force, the fetch
would refuse to operate (and because git-pull is git-fetch
followed by git-merge, the entire operation would fail and the
merge won't even happen --- hence you would not even see
conflicts). But the option does not change the fact that what
you are going to merge has conflicting changes with the changes
in your current branch. It merely allows git-fetch to forcibly
update the remote tracking information and git-pull to proceed
with the merges.
I am suspecting that (1) you have remote tracking information
(perhaps set up with "git remote add"); and (2) Ingo's tree
rebased between the time your last pull and this time. If you
do not have any local commits on the branch, resetting to the
remote tracking branch you use to track Ingo's progress is an
option. If you do, then fetching and rebasing instead of
pulling may make further development easier. But I cannot
really tell.
^ permalink raw reply
* Re: Stitching together private svn repo and public git repo
From: Junio C Hamano @ 2008-01-03 17:24 UTC (permalink / raw)
To: Gregory Jefferis; +Cc: Charles Bailey, Dmitry Potapov, git
In-Reply-To: <C3A2A4FD.1089D%jefferis@gmail.com>
I suspect your message was linewrapped by your MUA and ...
Gregory Jefferis <jefferis@gmail.com> writes:
> ...
> # set up the grafts
> cat > .git/info/grafts <<EOF
> # connect r2 of git-svn to v1.86 of nm-ucl
> # r1 (which was an identical initial import) will now be detached (and
> forgotten)
> 52b1933421ef524811407fa4c240da58ceec5749
> eca3db14fcf25744fdf585456f03599a9db2af96
> #
> # Make fake merge with Neuromatic v1.91b
> # svn-manualmerge1 svn-manualmerge1~1 public-v1.91b
> 120282ee5275027312dde386c8995218f361cf35
> 0962cb27f7ad92f44def04630e8e6a22b86e0699
> 6735057f53dd57248c7ec23f6ae9f22085d98fba
> EOF
>
> # running git-status seems to stop git thinking that the working dir is
> dirty
> git-status
> ...
... your grafts file look as if you are marking five commits as
root commits, which is not what you wanted ;-).
The reason I mention this is because I think with a bit more
polishing and some background description your message is a good
material to add to Documentation/howto/.
^ permalink raw reply
* Re: Stitching together private svn repo and public git repo
From: Gregory Jefferis @ 2008-01-03 14:43 UTC (permalink / raw)
To: Charles Bailey, Dmitry Potapov; +Cc: git
In-Reply-To: <20080102224611.GA14984@hashpling.org>
Many thanks to both for your replies. Starting from your comments and
consulting:
http://www.kernel.org/pub/software/scm/git/docs/repository-layout.html
for (fairly scant) details of .git/info/grafts and
http://www.kernel.org/pub/software/scm/git/docs/git-filter-branch.html
I think I have now been able to do the necessary. Since I found this a
trivial operation (in the true mathematical sense of quasi-impossible until
someone helps you to figure it out and simple once you have) and I tripped
over a couple of times, I thought I would share my final shell script below.
One point that I missed initially. The graft file format is unforgiving.
You are allowed comments but each regular line is:
Commit-SHA-1 Parent1-SHA-1 Parent2-SHA-1\n
If you put e.g. more than a single space between your SHA-1s you will get
"bad graft data:" - I missed one in the fake merge line and ran round in
circles for a bit thinking it was something to do with the state of my
trees.
Anyway, boy did it feel great when I was able to git-pull the latest public
release into my private repository:
34 files changed, 11563 insertions, 8399 deletions
and only 2 simple conflicts to fix with git-mergetool. That was not a merge
I wanted to do by hand!
Best wishes and thanks again,
Greg.
--
#!/usr/bin/env bash
# makemygitbygraft.sh
# merge my private repo (converted from svn) with a public git repo
# retains history of both and will allow 3 way merges etc in future
# work on a copy of my svn imported repo just in case
cd ~/dev/Physiology
rm -rf ~/dev/Physiology/nm-graft
cp -R nm-git-svn2 nm-graft
cd nm-graft
# Now get to work, bring in public repo as a remote
git remote add nm-ucl ../nm-ucl
git fetch nm-ucl
# set up the grafts
cat > .git/info/grafts <<EOF
# connect r2 of git-svn to v1.86 of nm-ucl
# r1 (which was an identical initial import) will now be detached (and
forgotten)
52b1933421ef524811407fa4c240da58ceec5749
eca3db14fcf25744fdf585456f03599a9db2af96
#
# Make fake merge with Neuromatic v1.91b
# svn-manualmerge1 svn-manualmerge1~1 public-v1.91b
120282ee5275027312dde386c8995218f361cf35
0962cb27f7ad92f44def04630e8e6a22b86e0699
6735057f53dd57248c7ec23f6ae9f22085d98fba
EOF
# running git-status seems to stop git thinking that the working dir is
dirty
git-status
# run git-filter-branch to instantiate the new parents
# just use cat so that parent names are untouched by the process
# but will be fed by .git/grafts/info as appropriate
git-filter-branch --parent-filter cat HEAD
Nicely formatted snippet also at
http://pastie.textmate.org/private/pv1n1nbmcmtxnxbq4zd7w
On 2/1/08 22:46, "Charles Bailey" <charles@hashpling.org> wrote:
> On Thu, Jan 03, 2008 at 01:13:54AM +0300, Dmitry Potapov wrote:
>> I believe there is a much easier way to do that using .git/info/grafts
>> The first step is to create .git/info/grafts, which specifies commit-id
>> and its parents for each commit that you want to change. Then you
>> can check the result using gitk, and if you are satisfied with what
>> you see then you run git filter-branch on it to convert 'fake' parents
>> into real ones.
>>
>> Dmitry
>>
>
> Oh yes, this is much easier. Unless I'm missing something, the
> documentation on grafts is fairly sparse, though. They are mentioned
> (almost in passing) in git help filter-branch but the file format is
> only documented in repository-layout.txt which seems more developer
> than user oriented.
>
> Charles.
--
Gregory Jefferis, PhD
Division of Neurobiology
MRC Laboratory of Molecular Biology,
Hills Road,
Cambridge, CB2 0QH, UK.
http://www2.mrc-lmb.cam.ac.uk/NB/jefferis_g
http://www.neuroscience.cam.ac.uk/directory/profile.php?gsxej2
http://flybrain.stanford.edu
^ permalink raw reply
* [PATCH] Fix grammar nits in documentation and in code comments.
From: Jim Meyering @ 2008-01-03 14:18 UTC (permalink / raw)
To: git list
Signed-off-by: Jim Meyering <meyering@redhat.com>
---
Documentation/i18n.txt | 2 +-
builtin-blame.c | 2 +-
ident.c | 2 +-
merge-recursive.c | 2 +-
setup.c | 2 +-
sha1_file.c | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/i18n.txt b/Documentation/i18n.txt
index b95f99b..1e188e6 100644
--- a/Documentation/i18n.txt
+++ b/Documentation/i18n.txt
@@ -22,7 +22,7 @@ does not forbid it. However, there are a few things to keep in
mind.
. `git-commit-tree` (hence, `git-commit` which uses it) issues
- an warning if the commit log message given to it does not look
+ a warning if the commit log message given to it does not look
like a valid UTF-8 string, unless you explicitly say your
project uses a legacy encoding. The way to say this is to
have i18n.commitencoding in `.git/config` file, like this:
diff --git a/builtin-blame.c b/builtin-blame.c
index d98caaf..9b4c02e 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -606,7 +606,7 @@ static void add_blame_entry(struct scoreboard *sb, struct blame_entry *e)
/*
* src typically is on-stack; we want to copy the information in it to
- * an malloced blame_entry that is already on the linked list of the
+ * a malloced blame_entry that is already on the linked list of the
* scoreboard. The origin of dst loses a refcnt while the origin of src
* gains one.
*/
diff --git a/ident.c b/ident.c
index 892d77a..b839dcf 100644
--- a/ident.c
+++ b/ident.c
@@ -152,7 +152,7 @@ static int copy(char *buf, size_t size, int offset, const char *src)
/*
* Copy the rest to the buffer, but avoid the special
* characters '\n' '<' and '>' that act as delimiters on
- * a identification line
+ * an identification line
*/
for (i = 0; i < len; i++) {
c = *src++;
diff --git a/merge-recursive.c b/merge-recursive.c
index 33ccc40..b34177d 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -289,7 +289,7 @@ static int get_files_dirs(struct tree *tree)
}
/*
- * Returns a index_entry instance which doesn't have to correspond to
+ * Returns an index_entry instance which doesn't have to correspond to
* a real cache entry in Git's index.
*/
static struct stage_data *insert_stage_data(const char *path,
diff --git a/setup.c b/setup.c
index b59dbe7..adede16 100644
--- a/setup.c
+++ b/setup.c
@@ -140,7 +140,7 @@ const char **get_pathspec(const char *prefix, const char **pathspec)
* Test if it looks like we're at a git directory.
* We want to see:
*
- * - either a objects/ directory _or_ the proper
+ * - either an objects/ directory _or_ the proper
* GIT_OBJECT_DIRECTORY environment variable
* - a refs/ directory
* - either a HEAD symlink or a HEAD file that is formatted as
diff --git a/sha1_file.c b/sha1_file.c
index b0c2435..6583797 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -148,7 +148,7 @@ static void fill_sha1_path(char *pathbuf, const unsigned char *sha1)
/*
* NOTE! This returns a statically allocated buffer, so you have to be
- * careful about using it. Do a "xstrdup()" if you need to save the
+ * careful about using it. Do an "xstrdup()" if you need to save the
* filename.
*
* Also note that this returns the location for creating. Reading
--
1.5.4.rc2.7.gcb27
^ permalink raw reply related
* Re: [PATCH ugit] Allow user to choose history browser tool
From: David @ 2008-01-03 12:35 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List
In-Reply-To: <e5bfff550801030408w1512e458x136f6be0371c13c2@mail.gmail.com>
On Jan 3, 2008 4:08 AM, Marco Costalba <mcostalba@gmail.com> wrote:
> Instead of hard linking gitk let the user set
> the preferred history visualization tool in settings dialog.
>
> Signed-off by: Marco Costalba <mcostalba@gmail.com>
> ---
>
Very nice, thank you!
I've applied this and fixed it so that the setting shows up on restart.
-David
^ permalink raw reply
* git weird pulling issue
From: Cyrill Gorcunov @ 2008-01-03 12:11 UTC (permalink / raw)
To: git
Hi git-list,
i've a weird problem with pulling remote tree. look i've linus's tree
as a base repo. then i've created x86 branch to which i pulled
ingo's x86 tree. So all further pulling is made over this branch.
And even having '--force' option at moment of pulling changes from
Ingo's tree i've got something like that:
---
cyrill@cvg linux-2.6-x86.git $ ./git-update.sh
Updating "x86"
remote: Generating pack...
remote: Done counting 15 objects.
Result has 9 objects.
remote: Deltifying 9 objects...
remote: /9) done/9) done
remote: Total 9 (delta 7), reused 3 (delta 1)
Unpacking 9 objects...
100% (9/9) done
Auto-merged include/asm-x86/msr.h
CONFLICT (content): Merge conflict in include/asm-x86/msr.h
Auto-merged include/linux/ptrace.h
Auto-merged kernel/ptrace.c
Automatic merge failed; fix conflicts and then commit the result.
---
I would really appreciate if someone helps me to resolve this
problem. If you need an additional info - just mail me.
Please Cc me 'case i'm not subscribed to the list.
Thanks in advance,
- Cyrill -
^ permalink raw reply
* [PATCH ugit] Allow user to choose history browser tool
From: Marco Costalba @ 2008-01-03 12:08 UTC (permalink / raw)
To: davvid; +Cc: Git Mailing List
Instead of hard linking gitk let the user set
the preferred history visualization tool in settings dialog.
Signed-off by: Marco Costalba <mcostalba@gmail.com>
---
A thing I was not able to figure out is how to save the settings
so that at restart of ugit the saved setting is found
again (instead of selecting the default 'gitk')
Anyhow a really nice tool this ugit thing, you managed to
playing catch-up with git-gui really fast.
ugitlibs/controllers.py | 6 ++++--
ugitlibs/models.py | 6 +++++-
ugitlibs/utilcontroller.py | 5 ++++-
ui/optionsgui.ui | 39 +++++++++++++++++++++++++++------------
4 files changed, 40 insertions(+), 16 deletions(-)
diff --git a/ugitlibs/controllers.py b/ugitlibs/controllers.py
index 411f1c1..6ad7b43 100644
--- a/ugitlibs/controllers.py
+++ b/ugitlibs/controllers.py
@@ -441,11 +441,13 @@ class Controller(QObserver):
def viz_all(self):
'''Visualizes the entire git history using gitk.'''
- utils.fork('gitk','--all')
+ browser = self.model.get_history_browser()
+ utils.fork(browser,'--all')
def viz_current(self):
'''Visualizes the current branch's history using gitk.'''
- utils.fork('gitk', self.model.get_branch())
+ browser = self.model.get_history_browser()
+ utils.fork(browser, self.model.get_branch())
# These actions monitor window resizes, splitter changes, etc.
def move_event(self, event):
diff --git a/ugitlibs/models.py b/ugitlibs/models.py
index 3c7ec9b..fe71362 100644
--- a/ugitlibs/models.py
+++ b/ugitlibs/models.py
@@ -117,6 +117,7 @@ class Model(model.Model):
'ugit.fontui.size':12,
'ugit.fontdiff': '',
'ugit.fontdiff.size':12,
+ 'ugit.history_browser_line': 'gitk',
}
default_dict = self.__config_defaults
@@ -251,7 +252,10 @@ class Model(model.Model):
self.subtree_types.append(self.types[idx])
self.subtree_sha1s.append(self.sha1s[idx])
self.subtree_names.append(name)
-
+
+ def get_history_browser(self):
+ return self.get_param('global.ugit.history_browser_line')
+
def get_tree_node(self, idx):
return (self.get_types()[idx],
self.get_sha1s()[idx],
diff --git a/ugitlibs/utilcontroller.py b/ugitlibs/utilcontroller.py
index 12a7399..c6f87a7 100644
--- a/ugitlibs/utilcontroller.py
+++ b/ugitlibs/utilcontroller.py
@@ -108,12 +108,15 @@ class OptionsController(QObserver):
'global.ugit.fontui.size': 'main_font_spinbox',
'global.ugit.fontui': 'main_font_combo',
+
+ 'global.ugit.history_browser_line': 'history_browser_line',
}
for m,v in model_to_view.iteritems():
self.model_to_view(m,v)
self.add_signals('textChanged(const QString&)',
+ view.history_browser_line,
view.local_name_line,
view.global_name_line,
view.local_email_line,
@@ -132,7 +135,7 @@ class OptionsController(QObserver):
view.global_diffcontext_spinbox,
view.local_verbosity_spinbox,
view.global_verbosity_spinbox)
-
+
self.add_signals('currentFontChanged(const QFont&)',
view.main_font_combo,
view.diff_font_combo)
diff --git a/ui/optionsgui.ui b/ui/optionsgui.ui
index 31bff84..a6fc1cf 100644
--- a/ui/optionsgui.ui
+++ b/ui/optionsgui.ui
@@ -8,8 +8,8 @@
<rect>
<x>0</x>
<y>0</y>
- <width>543</width>
- <height>313</height>
+ <width>598</width>
+ <height>399</height>
</rect>
</property>
<property name="windowTitle" >
@@ -23,7 +23,7 @@
</property>
</widget>
</item>
- <item row="0" column="1" >
+ <item row="0" column="1" colspan="2" >
<widget class="QSpinBox" name="main_font_spinbox" >
<property name="minimum" >
<number>8</number>
@@ -33,7 +33,7 @@
</property>
</widget>
</item>
- <item row="0" column="2" colspan="4" >
+ <item row="0" column="3" colspan="4" >
<widget class="QFontComboBox" name="main_font_combo" >
<property name="currentFont" >
<font>
@@ -49,7 +49,7 @@
</property>
</widget>
</item>
- <item row="1" column="1" >
+ <item row="1" column="1" colspan="2" >
<widget class="QSpinBox" name="diff_font_spinbox" >
<property name="minimum" >
<number>8</number>
@@ -59,19 +59,33 @@
</property>
</widget>
</item>
- <item row="1" column="2" colspan="4" >
+ <item row="1" column="3" colspan="4" >
<widget class="QFontComboBox" name="diff_font_combo" >
<property name="fontFilters" >
<set>QFontComboBox::MonospacedFonts</set>
</property>
<property name="currentFont" >
<font>
- <family>Courier</family>
+ <family>Liberation Mono</family>
</font>
</property>
</widget>
</item>
- <item row="2" column="0" colspan="3" >
+ <item row="2" column="0" >
+ <widget class="QLabel" name="label_11" >
+ <property name="text" >
+ <string>History browser</string>
+ </property>
+ </widget>
+ </item>
+ <item row="2" column="1" colspan="6" >
+ <widget class="QLineEdit" name="history_browser_line" >
+ <property name="text" >
+ <string/>
+ </property>
+ </widget>
+ </item>
+ <item row="3" column="0" colspan="4" >
<widget class="QGroupBox" name="local_groupbox" >
<property name="title" >
<string>Local Repository</string>
@@ -151,7 +165,7 @@
</layout>
</widget>
</item>
- <item row="2" column="3" colspan="3" >
+ <item row="3" column="4" colspan="3" >
<widget class="QGroupBox" name="globalGroupBox" >
<property name="title" >
<string>Global (All Repositories)</string>
@@ -231,7 +245,7 @@
</layout>
</widget>
</item>
- <item row="3" column="0" colspan="4" >
+ <item row="4" column="0" colspan="5" >
<spacer>
<property name="orientation" >
<enum>Qt::Horizontal</enum>
@@ -244,7 +258,7 @@
</property>
</spacer>
</item>
- <item row="3" column="4" >
+ <item row="4" column="5" >
<widget class="QPushButton" name="save_button" >
<property name="text" >
<string>Save</string>
@@ -254,7 +268,7 @@
</property>
</widget>
</item>
- <item row="3" column="5" >
+ <item row="4" column="6" >
<widget class="QPushButton" name="cancel_button" >
<property name="text" >
<string>Cancel</string>
@@ -264,4 +278,5 @@
</layout>
</widget>
<resources/>
+ <connections/>
</ui>
--
1.5.4.rc2.14.geab82
^ permalink raw reply related
* Re: [PATCH] Avoid a useless prefix lookup in strbuf_expand()
From: Marco Costalba @ 2008-01-03 10:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: René Scharfe, Git Mailing List, Johannes Schindelin
In-Reply-To: <7vr6gztgwn.fsf@gitster.siamese.dyndns.org>
On Jan 3, 2008 10:08 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
>
> I'll let Marco bench it and hopefully Ack with an updated
> (final) commit log message.
>
I will bench today and post the results.
Marco
^ permalink raw reply
* Re: [RFH] On a script for submodules
From: Imran M Yousuf @ 2008-01-03 9:52 UTC (permalink / raw)
To: git
In-Reply-To: <7vsl1fs0xa.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1975 bytes --]
Hi all,
Sorry for referring to the blog. I am writing the details here again
and also attached the script in the email.
I am fairly a new git user; I started working around with GIT on
Framework development project and I noticed that GIT commands executed
on the parent module is not propagated to the child modules. In some
use cases it would be extremely useful (at least for me) to be able to
be propagate a command from the master module to all its child at all
depth. I wrote the bash shell script (in the attachment) to simply
propagate commands from parent to its child. To use this script one
can simply do the following (I am assuming that the file will have the
name git-modules and will be an executable in $PATH):
for: git-pull
do: git-modules pull
for: git-status
do: git-modules status
for: git-commit -a -m "This is a test commit"
do: git-modules commit -a -m "This is a test commit"
for: git-checkout master
do: git-modules checkout master
Basically any git-X command can be simply be done as "git-modules X
args-as-usual".
It is mainly different from the git-submodule command in its usage. I
mainly wrote it to propagate commands. It could be extended for
further usage as well.
I would really appreciate and welcome criticism, feedback and addition
to the script.
Thank you,
On Jan 3, 2008 3:39 PM, Junio C Hamano <gitster@pobox.com> wrote:
> "Imran M Yousuf" <imyousuf@gmail.com> writes:
>
> > ... I would really appreciate if someone would take their time to
> > suggest me improvements. I would also like to get some feedbacks as
> > what else could be added here. A brief description can be found in the
> > following posting.
>
> Around here, it is customary to have discussion on-list, not
> pointing at external web pages and repositories. I would
> suggest starting by stating what the overall design is and how
> it meshes with existing git-submodule command and its design.
>
>
>
--
Imran M Yousuf
[-- Attachment #2: git-modules --]
[-- Type: application/octet-stream, Size: 1238 bytes --]
#!/bin/bash
ARGS=1
if [ $# -lt "$ARGS" ]; then
echo Not enough arguments.
echo Example \"\<this script\> status\" for \"git-status\" - git-modules status
exit 65;
fi
function traverseModule() {
current_dir=`pwd`
dir_path="$current_dir:$dir_path"
cd $1
eval $2
if [ -f .gitmodules ]; then
for mod_path in `grep "path =" .gitmodules | awk '{print $3}'`; do
traverseModule $mod_path $2
done
fi
old_dir=$(echo $dir_path | cut -d':' -f1-1)
cd $old_dir
dir_path=${dir_path:$(echo "${#old_dir}+1" | bc)}
}
project_home=`pwd`
echo Project Home: $project_home
if [ -d $project_home/.git/ ]; then
git_command=$1
shift
command_arguments=""
for arg in "$@"; do
if [ `expr index "$arg" ' '` -gt 0 ]; then
arg="\"$arg\""
fi
command_arguments="$command_arguments $arg"
done
echo GIT Command git-$git_command with arguments\($#\) "$command_arguments"
main_command="git-$git_command $command_arguments"
eval $main_command
if [ -f .gitmodules ]; then
for mod_path in `grep "path =" .gitmodules | awk '{print $3}'`; do
traverseModule $mod_path "$main_command"
done
fi
else
echo $project_home not a git repo thus exiting
exit
fi
^ permalink raw reply
* Re: [RFH] On a script for submodules
From: Junio C Hamano @ 2008-01-03 9:39 UTC (permalink / raw)
To: Imran M Yousuf; +Cc: git
In-Reply-To: <7bfdc29a0801030107t54ca45dbq167666b337f59a01@mail.gmail.com>
"Imran M Yousuf" <imyousuf@gmail.com> writes:
> ... I would really appreciate if someone would take their time to
> suggest me improvements. I would also like to get some feedbacks as
> what else could be added here. A brief description can be found in the
> following posting.
Around here, it is customary to have discussion on-list, not
pointing at external web pages and repositories. I would
suggest starting by stating what the overall design is and how
it meshes with existing git-submodule command and its design.
^ permalink raw reply
* Re: Git and securing a repository
From: Junio C Hamano @ 2008-01-03 9:36 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Shawn O. Pearce, git
In-Reply-To: <200801031011.29050.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Shawn O. Pearce wrote:
>> Jakub Narebski <jnareb@gmail.com> wrote:
>
>> > AFAIK both update and pre-receive hooks are invoked also on fetch...
>> > but I might be mistaken.
>>
>> No, they are *not* invoked on fetch. Currently no hooks execute
>> during fetch; either on the server *or* on the client side of
>> the connection.
>
> Errr... I think at least post-update hook (the one with
> git-update-server-info by default) is invoked on fetch.
Please don't think then. Instead check your facts before
posting to avoid wasting bandwidth and people's time. The
post-update hook is run on the remote end when you push into it.
I do not particularly like hooks that act after an operation is
initiated locally and act solely on local data. This is maybe
because I still consider git tools building blocks suitable for
higher level scripting more than other people do.
There are five valid reasons you might want a hook to a git
operation:
(1) A hook that countermands the normal decision made by the
underlying command. Examples of this class are the update
hook and the pre-commit hook.
(2) A hook that operates on data generated after the command
starts to run. The ability to munge the commit log message
by the commit-msg hook is an example.
(3) A hook that operates on the remote end of the connection
that you may not otherwise have access to other than over
the git protocol. An example is the post-update hook.
(4) A hook that runs under a lock that is acquired by the
command for mutual exclusion. Currently there is no
example, but if we allowed the update hook to modify the
commit that was pushed through send-pack => receive-pack
pair, which was discussed on the list a while ago, it would
be a good example of this.
(5) A hook that is run differently depending on the outcome of
the command. The post-merge hook conditionally run by
git-pull is an example of this (it is not even run if no
merge takes place). Another example is the post-checkout
hook that gets information that is otherwise harder to get
(namely, if it was a branch checkout or file checkout --
you can figure it out by examining the command line but
that already is part of the processing git-checkout does
anyway, so no need to force duplicating that code in the
userland).
You cannot do an equivalent operation from outside the git
command for the above classes of operations. You need hooks
for them.
On the other hand, if you want to always cause an action after
running a git opeation locally, you do not have to have a hook.
You can just run them yourself, or have "git myfetch" wrapper
that does whatever you want after running "git fetch". Only
when the combination of the underlying command and something
else is widely useful, _and_ that something else needs
flexibility, a hook is warranted (if that something else is
always the same thing, it is better to fold that into the
underlying command).
^ 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