* Re: Please pull mergetool.git
From: Theodore Tso @ 2007-06-10 21:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7v1wgj8tzy.fsf@assigned-by-dhcp.cox.net>
On Sun, Jun 10, 2007 at 12:55:13PM -0700, Junio C Hamano wrote:
> But I hope you would not be offended if I said I do not want to.
>
> This is not such a strong objection, but I really wish that you
> did not mix in the .gitignore change; it does not belong to this
> "series".
OK, no problem. It was something I noticed while I was preparing the
series, and I thought it was non-controverisal enough to just throw it
in. It's at the tail of the series, so it's easy enough for me to do a
git reset --hard HEAD^
on the mergetool branch.... OK, done. If you pull from
git://repo.or.cz/git/mergetool.git mergetool
You'll only get the first two changes to git-mergetool, and the
.gitignore change has been dropped.
Regards,
- Ted
^ permalink raw reply
* Re: [PATCH] git-svn: use git-log rather than rev-list | xargs cat-file
From: Eric Wong @ 2007-06-10 21:24 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <20070610091259.48F8D13A4F8@magnus.utsl.gen.nz>
Sam Vilain <sam@vilain.net> wrote:
> This saves a bit of time when rebuilding the git-svn index.
Does git-log still have the 16k buffer limit? If so then we can't use
it because commit messages over 16k will be truncated and the git-svn-id
line will not show up. Also, if that limit is removed I'd prefer to
just add --pretty=raw to rev-list because git-log is stil porcelain and
more likely to change.
> Signed-off-by: Sam Vilain <sam@vilain.net>
> ---
> git-svn.perl | 30 +++++++++++++++++++-----------
> 1 files changed, 19 insertions(+), 11 deletions(-)
>
> diff --git a/git-svn.perl b/git-svn.perl
> index e350061..610563c 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -802,10 +802,15 @@ sub cmt_metadata {
>
> sub working_head_info {
> my ($head, $refs) = @_;
> - my ($fh, $ctx) = command_output_pipe('rev-list', $head);
> - while (my $hash = <$fh>) {
> - chomp($hash);
> - my ($url, $rev, $uuid) = cmt_metadata($hash);
> + my ($fh, $ctx) = command_output_pipe('log', $head);
> + my $hash;
> + while (<$fh>) {
> + if ( m{^commit ($::sha1)$} ) {
> + $hash = $1;
> + next;
> + }
> + next unless s{^\s+(git-svn-id:)}{$1};
> + my ($url, $rev, $uuid) = extract_metadata($_);
> if (defined $url && defined $rev) {
> if (my $gs = Git::SVN->find_by_url($url)) {
> my $c = $gs->rev_db_get($rev);
> @@ -1964,16 +1969,19 @@ sub rebuild {
> return;
> }
> print "Rebuilding $db_path ...\n";
> - my ($rev_list, $ctx) = command_output_pipe("rev-list", $self->refname);
> + my ($log, $ctx) = command_output_pipe("log", $self->refname);
> my $latest;
> my $full_url = $self->full_url;
> remove_username($full_url);
> my $svn_uuid;
> - while (<$rev_list>) {
> - chomp;
> - my $c = $_;
> - die "Non-SHA1: $c\n" unless $c =~ /^$::sha1$/o;
> - my ($url, $rev, $uuid) = ::cmt_metadata($c);
> + my $c;
> + while (<$log>) {
> + if ( m{^commit ($::sha1)$} ) {
> + $c = $1;
> + next;
> + }
> + next unless s{^\s*(git-svn-id:)}{$1};
> + my ($url, $rev, $uuid) = ::extract_metadata($_);
> remove_username($url);
>
> # ignore merges (from set-tree)
> @@ -1991,7 +1999,7 @@ sub rebuild {
> $self->rev_db_set($rev, $c);
> print "r$rev = $c\n";
> }
> - command_close_pipe($rev_list, $ctx);
> + command_close_pipe($log, $ctx);
> print "Done rebuilding $db_path\n";
> }
>
> --
> 1.5.0.4.210.gf8a7c-dirty
>
--
Eric Wong
^ permalink raw reply
* git-svn - creating a tag in a cloned SVN repository
From: Adam Piatyszek @ 2007-06-10 20:42 UTC (permalink / raw)
To: git
Hi!
I recently switched to git for my projects, even for these which are
tracked in remote SVN repositories (thanks to git-svn tool).
However, I did not find anywhere an answer to one question:
Is it possible to create a subversion-like tag in the remote SVN
repository using git-svn?
In more detail: is it possible to emulate the following SVN command:
svn copy http://svn.project.server/project/trunk \
http://svn.project.server/project/tags/release-1.0
using git-svn?
SVN branches and tags are properly imported into separate remote git
branches (by using -T -t and -b switches).
Thanks for your help!
BR,
/ediap
--
.:. Adam Piatyszek - "ediap" .:. JID: ediap(at)jabber.org .:.
.:. ediap(at)users.sourceforge.net .:. PGP key ID: 0x1F115CCB .:.
^ permalink raw reply
* Re: [PATCH 2/3] Add gitmodules(5)
From: Lars Hjemli @ 2007-06-10 21:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: skimo, Frank Lichtenheld, Johannes Schindelin, git
In-Reply-To: <7vzm377cjk.fsf@assigned-by-dhcp.cox.net>
On 6/10/07, Junio C Hamano <gitster@pobox.com> wrote:
> "Lars Hjemli" <hjemli@gmail.com> writes:
>
> > Hmm, maybe I should just rename [module] to [submodule] right now? It
> > would be better forward compatible with the proposed extension, it
> > would 'harmonize' the section names used in .gitmodules and
> > .git/config, and it would offer a clean break from what's currently
> > supported in 'master'.
>
> Yes, the difference between '[submodule]' vs '[module]' in
> .git/config and .gitmodules confused me while looking at your
> latest patch series. I am in favor of unifying them. We would
> not be breaking any released version if we harmonize them now.
>
Good, then I'll do it that way. And I'll drop the "unless otherwise
noted, name=path" behaviour. If we later decide it would be useful we
can always "re-add" it.
--
larsh
^ permalink raw reply
* Re: [PATCH 2/3] Add gitmodules(5)
From: Junio C Hamano @ 2007-06-10 20:57 UTC (permalink / raw)
To: Lars Hjemli; +Cc: skimo, Frank Lichtenheld, Johannes Schindelin, git
In-Reply-To: <8c5c35580706100530g256de4a4yb12f4647dae06500@mail.gmail.com>
"Lars Hjemli" <hjemli@gmail.com> writes:
> Hmm, maybe I should just rename [module] to [submodule] right now? It
> would be better forward compatible with the proposed extension, it
> would 'harmonize' the section names used in .gitmodules and
> .git/config, and it would offer a clean break from what's currently
> supported in 'master'.
Yes, the difference between '[submodule]' vs '[module]' in
.git/config and .gitmodules confused me while looking at your
latest patch series. I am in favor of unifying them. We would
not be breaking any released version if we harmonize them now.
^ permalink raw reply
* Documentation updates
From: J. Bruce Fields @ 2007-06-10 20:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
There are some minor user-manual and tutorial updates available in the
maint branch at:
git://linux-nfs.org/~bfields/git.git maint
Gerrit Pape (1):
Fix typo in remote branch example in git user manual
J. Bruce Fields (4):
user-manual: quick-start updates
user-manual: add a missing section ID
Documentation: user-manual todo
tutorial: use "project history" instead of "changelog" in header
Documentation/tutorial.txt | 4 ++--
Documentation/user-manual.txt | 17 +++++++++++------
2 files changed, 13 insertions(+), 8 deletions(-)
--b.
^ permalink raw reply
* Adding empty directory gives bogus error message
From: Jonas Fonseca @ 2007-06-10 20:46 UTC (permalink / raw)
To: git
Hello,
During a talk with madduck on #git today, we stumbled upon this
confusing error message:
$ mkdir repo
$ cd repo/
$ git init
Initialized empty Git repository in .git/
$ mkdir empty
$ git add empty/
The following paths are ignored by one of your .gitignore files:
empty/ (directory)
Use -f if you really want to add them.
$ git add -f empty/
fatal: unable to index file empty/
First, it misleads the user by assuming that something was added to
.gitignore or another exclude file, and the second error message is not
very helpful.
Looking at the code, I am not sure how this can be fixed. Simply
printing a warning when finding "some" empty directory might do, but it
is not the best way to help somebody new to git. Refusing to add
anything when finding an empty directory deep in some hierarchy is not a
good option either.
Git 1.4 silently did nothing, so 1.5 at least tries to be more clueful.
Anyway, I thought I would mention it and see what happens. ;)
--
Jonas Fonseca
^ permalink raw reply
* Re: [PATCH] Introduce light weight commit annotations
From: Johannes Schindelin @ 2007-06-10 19:53 UTC (permalink / raw)
To: Johan Herland; +Cc: git, gitster
In-Reply-To: <200706102120.55758.johan@herland.net>
Hi,
On Sun, 10 Jun 2007, Johan Herland wrote:
> On Sunday 10 June 2007, Johannes Schindelin wrote:
> > On Sun, 10 Jun 2007, Johan Herland wrote:
> > > Small typo here. "core.showannotaions" should be "core.showannotations",
> > > I guess.
> >
> > Yep. I tested it with "core.shownotes", but decided before sending the
> > patch that the name would be inconsistent with the rest of the code.
> >
> > However, as I suggested later, I could imagine that an even better way
> > could be to have "core.annotationsRef", overrideable by
> > GIT_ANNOTATIONS_REF, which could possibly even be a list of refs.
> >
> > BTW I am not married to calling it "annotations". If you like "notes"
> > better, I'm fine with it.
>
> No problem. Actually I really wanted to call my first
> proof-of-concept "annotations", and not "notes", but I
> figured it would be confused with the "annotate-as-in-blame"
> concept. Besides there is already a git-annotate command...
Not to forget that note is shorter to type.
Ciao,
Dscho
^ permalink raw reply
* Re: Please pull mergetool.git
From: Junio C Hamano @ 2007-06-10 19:55 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: Git Mailing List
In-Reply-To: <E1HxPt7-0007jV-6V@candygram.thunk.org>
"Theodore Ts'o" <tytso@mit.edu> writes:
> Please pull from the "mergetool" branch at:
> git://repo.or.cz/git/mergetool.git mergetool
>
> It adds support for vimdiff/gvimdiff as a mergetool program, as well
> Josh's suggestion of making the default merge-tool selection more
> intelligent, although I've rewritten it somewhat take into account the
> comments made by you and others on the git mailing list.
>
> (Note that as of this writing, meld is a pretty sad/dificient tool, and
> even GNOME users may very well prefer kdiff3 over meld --- which is my
> default. Still, it seems reasonable to default to using KDE tools in an
> KDE login session, and GNOME tools in a GNOME login session, and people
> who care differently should set their own preferences in ~/.gitconfig.)
Thanks for keeping track of the mergetool.
I do not see problems in the mergetool part, other than that I
mildly suspect that opendiff -- actually FileMerge -- might want
to be in the test -n "$DISPLAY" section, but that is inherited
from the previous iteration so in that sense leaving outside is
a sane thing to do.
> Dan McGee (1):
> git-mergetool: Allow gvimdiff to be used as a mergetool
>
> Theodore Ts'o (2):
> git-mergetool: Make default selection of merge-tool more intelligent
> Add git-applymbox, git-applypatch, and *~ to .gitignore
But I hope you would not be offended if I said I do not want to.
This is not such a strong objection, but I really wish that you
did not mix in the .gitignore change; it does not belong to this
"series".
If it were an obvious and universally nondisagreeable fix, I
would not mind you mixing it in this mergetool updates, but I am
of two minds about the .gitignore change, and actually slightly
in favor of not adding git-applymbox and git-applypatch back.
About git-applymbox and git-applypatch, it helps people when
they switch branches and/or bisect to keep potential build
products from older/different revisions listed in .gitignore.
That would however imply we would end up carrying old entries
forever in it. We do not keep clean rule in Makefile to remove
build products from older/different revisions when remove build
targets, so why should we keep them in .gitignore?
Also I deliberately have kept *~ out of .gitignore for a reason.
I do have that entry in .git/info/exclude, but the choice of
Emacs over vi is personal to me.
^ permalink raw reply
* Re: Refactoring the tag object; Introducing soft references (softrefs); Git 'notes' (take 2)
From: Steven Grimm @ 2007-06-10 19:42 UTC (permalink / raw)
To: Johan Herland; +Cc: Pierre Habouzit, git, Junio C Hamano
In-Reply-To: <200706101631.27600.johan@herland.net>
Johan Herland wrote:
> Interesting. But I'm not sure I want to give up the fixed-length softref
> records as I imagine it makes the lookup and processing _much_ faster.
>
The token (really a namespace identifier) could be defined as a string
with a fixed, probably small, maximum size. Or, better IMO, it could be
an integer with a bunch of enumerated values for internal git uses and a
range reserved for unofficial / experimental use. I agree that
fixed-length records seem like a win here, assuming this is the general
storage layout we end up with when all is said and done.
-Steve
^ permalink raw reply
* Re: [PATCH] Introduce light weight commit annotations
From: Johan Herland @ 2007-06-10 19:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <Pine.LNX.4.64.0706101952180.4059@racer.site>
On Sunday 10 June 2007, Johannes Schindelin wrote:
> On Sun, 10 Jun 2007, Johan Herland wrote:
> > Small typo here. "core.showannotaions" should be "core.showannotations",
> > I guess.
>
> Yep. I tested it with "core.shownotes", but decided before sending the
> patch that the name would be inconsistent with the rest of the code.
>
> However, as I suggested later, I could imagine that an even better way
> could be to have "core.annotationsRef", overrideable by
> GIT_ANNOTATIONS_REF, which could possibly even be a list of refs.
>
> BTW I am not married to calling it "annotations". If you like "notes"
> better, I'm fine with it.
No problem. Actually I really wanted to call my first
proof-of-concept "annotations", and not "notes", but I
figured it would be confused with the "annotate-as-in-blame"
concept. Besides there is already a git-annotate command...
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH] Silence error messages unless 'thorough_verify' is set
From: Johan Herland @ 2007-06-10 19:16 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0706101943350.4059@racer.site>
On Sunday 10 June 2007, Johannes Schindelin wrote:
> On Sun, 10 Jun 2007, Johan Herland wrote:
> > On Sunday 10 June 2007, Johannes Schindelin wrote:
> > > As for the general direction of implementing notes as tags: If you
> > > want to make them fetchable, you have to deal with conflicts. If you
> > > want to be able to amend notes, _especially_ when they should be
> > > fetchable, you want a history on them.
> >
> > I'm not sure what kind of notes you're talking about here. If you're
> > talking about my git-note concept, I designed notes to be immutable
> > (thus not amendable) and there is therefore _no_ merging or potential
> > for conflicts between notes.
>
> Okay, that is one way you can go about implementing notes.
>
> > The only resolution needed is to figure out which order the notes for a
> > given object should be presented. The default here is chronological
> > sorting.
>
> There are several problems with that approach I'd like to point out:
>
> - In distributed environments, you can not rely on timestamps. Ever.
Not really, but that doesn't stop many programs from trying anyway...
(e.g. email clients). And still, it's not like the date (or sorting)
is crucial to the 'notes' concept or implementation.
> - If a note is deleted, you will fetch it again as long as the other side
> did not delete it.
Yep. This was considered an acceptable tradeoff in the design. But I
understand that some people won't like it.
> - You cannot undo a typo (since the notes are immutable, you would see
> both versions), once the typoed note was fetched.
Yep. Also a tradeoff in the design. Also going to piss off some
people, I guess.
> Basically, everything I see as a problem here suggests that note writing
> is very much like working on a branch. That's why I suggest to treat it
> exactly like a branch to begin with.
I see you point.
BTW, I have some patches implementing the 'notes' concept on top
of the softrefs patches. They're just lying around now waiting
to be cleaned up and sent to the list, but I'm not sure it's worth
it, since they don't add anything that's not in your lightweight
annotation patch...
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH 2/4] Introduce optional "keywords" on tag objects
From: Johan Herland @ 2007-06-10 19:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0706101937250.4059@racer.site>
On Sunday 10 June 2007, Johannes Schindelin wrote:
> Hi,
>
> On Sun, 10 Jun 2007, Johan Herland wrote:
>
> > + /* Verify the keywords: disallow ctrl chars, spaces and double commas */
>
> What about Junio's suggestion, making it really strict at first, and only
> loosening it if we need to? IIRC it was alnum + '_', maybe even '-'.
For now, I couldn't find a good reason why the set of allowed characters
for keywords should be smaller than for the tag name.
Feel free to tighten the set of characters before this makes it into a
release. However, if you do, the same tightening should be considered
for the tag name as well, I guess. Can't see any good reasons for why
one should be tighter than the other.
> And please accept my apologies for my language. Reading some of it, I have
> to admit that it sounded as harsh as Junio suggested it to be. My only
> excuse is that I had an unplanned stay at the Paris airport for more than
> 9 hours (after a night in the plane where I could hardly sleep), so I
> should really have stayed away from writing emails. But since you
> addressed your emails to me, I wanted to reply to you as soon as I had the
> chance to.
Apology accepted. I'm sorry my patch-series-from-hell came at such an
inconvenient time for you.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH] Introduce light weight commit annotations
From: Johannes Schindelin @ 2007-06-10 18:56 UTC (permalink / raw)
To: Johan Herland; +Cc: git, gitster
In-Reply-To: <200706101514.14954.johan@herland.net>
Hi,
On Sun, 10 Jun 2007, Johan Herland wrote:
> On Saturday 09 June 2007, Johannes Schindelin wrote:
>
> > With the provided script, edit-commit-annotations, you can add
> > after-the-fact annotations to commits, which will be shown by the log
> > if the config variable core.showannotations is set.
> >
> > The annotations are tracked in a new ref, refs/annotations/commits, in
> > the same fan-out style as .git/objects/??/*, only that they only exist
> > in the object database now.
>
> Very interesting. I have to say that after having played around with
> it a couple of minutes, I really like it. Needs some polishing here
> and there (i.e. cleaning up the COMMIT_ANNOTATION.NNNN* files), but
> it is a very good proof-of-concept.
Thanks. I composed it in a hurry, since I wanted it to go out before I
took my flight home.
> > I have the hunch that this will be relatively fast and scalable,
> > since the tree objects are sorted by name (the name being the
> > object name of the to-be-annotated commit).
>
> I think I agree with your hunch, although I initially thought that your
> solution was a bit heavy on the number of objects created. But, hey, git
> is _designed_ to handle massive amounts of objects. :)
Besides, these tree objects should delta really well, being almost as
efficient as having only one tree object to begin with.
> > diff --git a/config.c b/config.c
> > index 58d3ed5..34db9b2 100644
> > --- a/config.c
> > +++ b/config.c
> > @@ -356,6 +356,11 @@ int git_default_config(const char *var, const char *value)
> > return 0;
> > }
> >
> > + if (!strcmp(var, "core.showannotaions")) {
> > + show_commit_annotations = git_config_bool(var, value);
> > + return 0;
> > + }
> > +
>
> Small typo here. "core.showannotaions" should be "core.showannotations",
> I guess.
Yep. I tested it with "core.shownotes", but decided before sending the
patch that the name would be inconsistent with the rest of the code.
However, as I suggested later, I could imagine that an even better way
could be to have "core.annotationsRef", overrideable by
GIT_ANNOTATIONS_REF, which could possibly even be a list of refs.
BTW I am not married to calling it "annotations". If you like "notes"
better, I'm fine with it.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Silence error messages unless 'thorough_verify' is set
From: Johannes Schindelin @ 2007-06-10 18:51 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Junio C Hamano
In-Reply-To: <200706101410.17771.johan@herland.net>
Hi,
On Sun, 10 Jun 2007, Johan Herland wrote:
> On Sunday 10 June 2007, Johannes Schindelin wrote:
>
> > As for the general direction of implementing notes as tags: If you
> > want to make them fetchable, you have to deal with conflicts. If you
> > want to be able to amend notes, _especially_ when they should be
> > fetchable, you want a history on them.
>
> I'm not sure what kind of notes you're talking about here. If you're
> talking about my git-note concept, I designed notes to be immutable
> (thus not amendable) and there is therefore _no_ merging or potential
> for conflicts between notes.
Okay, that is one way you can go about implementing notes.
> The only resolution needed is to figure out which order the notes for a
> given object should be presented. The default here is chronological
> sorting.
There are several problems with that approach I'd like to point out:
- In distributed environments, you can not rely on timestamps. Ever.
- If a note is deleted, you will fetch it again as long as the other side
did not delete it.
- You cannot undo a typo (since the notes are immutable, you would see
both versions), once the typoed note was fetched.
Basically, everything I see as a problem here suggests that note writing
is very much like working on a branch. That's why I suggest to treat it
exactly like a branch to begin with.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/4] Introduce optional "keywords" on tag objects
From: Johannes Schindelin @ 2007-06-10 18:42 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Junio C Hamano
In-Reply-To: <200706101350.00271.johan@herland.net>
Hi,
On Sun, 10 Jun 2007, Johan Herland wrote:
> + /* Verify the keywords: disallow ctrl chars, spaces and double commas */
What about Junio's suggestion, making it really strict at first, and only
loosening it if we need to? IIRC it was alnum + '_', maybe even '-'.
Other than that, looks good to me. I trust that the test cases are
exhaustive enough to support the patch from the practical side.
BTW this patch is exactly what I meant by conceptually closed. Thank you.
And please accept my apologies for my language. Reading some of it, I have
to admit that it sounded as harsh as Junio suggested it to be. My only
excuse is that I had an unplanned stay at the Paris airport for more than
9 hours (after a night in the plane where I could hardly sleep), so I
should really have stayed away from writing emails. But since you
addressed your emails to me, I wanted to reply to you as soon as I had the
chance to.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 0/4] Restructure the tag object
From: Johannes Schindelin @ 2007-06-10 18:35 UTC (permalink / raw)
To: Johan Herland; +Cc: Junio C Hamano, git
In-Reply-To: <200706101347.57023.johan@herland.net>
Hi,
On Sun, 10 Jun 2007, Johan Herland wrote:
> Johan Herland (4):
> Make tag names (i.e. the tag object's "tag" line) optional
> Introduce optional "keywords" on tag objects
> Documentation/git-mktag: Document the changes in tag object structure
> git-mktag tests: Expand on mktag selftests according to the new tag object structure
Much nicer, thank you.
Ciao,
Dscho
^ permalink raw reply
* Re: [ANNOUNCE] qgit-2.0rc1
From: Ismail Dönmez @ 2007-06-10 18:10 UTC (permalink / raw)
To: Jan Hudec; +Cc: Marco Costalba, Git Mailing List, Pavel Roskin, Andy Parkins
In-Reply-To: <20070610175628.GI4084@efreet.light.src>
[-- Attachment #1: Type: text/plain, Size: 1309 bytes --]
On Sunday 10 June 2007 20:56:28 Jan Hudec wrote:
> On Sun, Jun 10, 2007 at 19:33:31 +0300, Ismail Dönmez wrote:
> > On Sunday 10 June 2007 17:36:42 you wrote:
> > > On 6/10/07, Ismail Dönmez <ismail@pardus.org.tr> wrote:
> > > > Uploaded to
> > > > http://cekirdek.pardus.org.tr/~ismail/tmp/qgit4-report.txt .
> > >
> > > Ok. You seem to miss all the debug libraries _and_ the whole
> > > libQtUiTools library.
> >
> > Nope not a Qt problem. Removing -frepo from CXXFLAGS fixes the issue. Gcc
> > 4.2.0 doesn't seem to like it for some reason.
>
> I did a brief STFW and found problems with -frepo to be rather common. From
> what I understood, it works by trying to link, parsing the errors,
> instantiating the missing bits and compiling again. And the whole thing is
> rather fragile.
>
> What could be interesting for you is debian bug
> http://lists.debian.org/debian-gcc/2007/05/msg00374.html
>
> It says that -frepo only works with C locale, but it would actually be in
> any locale where ld messages are not localized. On my system it has message
> catalog in da, es, fr, ga, sv, tr, vi, zh_CN and zh_TW. Don't you have
> tr_TR for LC_MESSAGES?
My LC_ALL is tr_TR.UTF-8. Btw LC_ALL=C make gives the same problem.
Regards,
ismail
--
Perfect is the enemy of good
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]
^ permalink raw reply
* Re: [ANNOUNCE] qgit-2.0rc1
From: Jan Hudec @ 2007-06-10 17:56 UTC (permalink / raw)
To: Ismail Dönmez
Cc: Marco Costalba, Git Mailing List, Pavel Roskin, Andy Parkins
In-Reply-To: <200706101933.36760.ismail@pardus.org.tr>
[-- Attachment #1: Type: text/plain, Size: 1211 bytes --]
On Sun, Jun 10, 2007 at 19:33:31 +0300, Ismail Dönmez wrote:
> On Sunday 10 June 2007 17:36:42 you wrote:
> > On 6/10/07, Ismail Dönmez <ismail@pardus.org.tr> wrote:
> > > Uploaded to http://cekirdek.pardus.org.tr/~ismail/tmp/qgit4-report.txt .
> >
> > Ok. You seem to miss all the debug libraries _and_ the whole
> > libQtUiTools library.
>
> Nope not a Qt problem. Removing -frepo from CXXFLAGS fixes the issue. Gcc
> 4.2.0 doesn't seem to like it for some reason.
I did a brief STFW and found problems with -frepo to be rather common. From
what I understood, it works by trying to link, parsing the errors,
instantiating the missing bits and compiling again. And the whole thing is
rather fragile.
What could be interesting for you is debian bug
http://lists.debian.org/debian-gcc/2007/05/msg00374.html
It says that -frepo only works with C locale, but it would actually be in any
locale where ld messages are not localized. On my system it has message
catalog in da, es, fr, ga, sv, tr, vi, zh_CN and zh_TW. Don't you have tr_TR
for LC_MESSAGES?
On another side, is there a measurable compilation time improvement with -frepo?
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git-svn set-tree bug
From: Joakim Tjernlund @ 2007-06-10 17:27 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <1181496086.30670.115.camel@gentoo-jocke.transmode.se>
On Sun, 2007-06-10 at 19:21 +0200, Joakim Tjernlund wrote:
> On Sat, 2007-06-09 at 18:47 -0700, Eric Wong wrote:
> > Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> > > trying to do git-svn set-tree remotes/trunk..svn
> > > in my new git-svn repo I get:
> > > config --get svn-remote.svn.fetch :refs/remotes/git-svn$: command returned error: 1
> >
> > You need to specify "-i trunk" in the command-line
> >
> > git-svn set-tree -i trunk remotes/trunk..svn
> >
>
> Thanks
[SNIP script]
forgot:
git version 1.5.2.1
subversion version 1.4.3
Jocke
^ permalink raw reply
* Re: git-svn set-tree bug
From: Joakim Tjernlund @ 2007-06-10 17:21 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20070610014734.GA542@muzzle>
On Sat, 2007-06-09 at 18:47 -0700, Eric Wong wrote:
> Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> > trying to do git-svn set-tree remotes/trunk..svn
> > in my new git-svn repo I get:
> > config --get svn-remote.svn.fetch :refs/remotes/git-svn$: command returned error: 1
>
> You need to specify "-i trunk" in the command-line
>
> git-svn set-tree -i trunk remotes/trunk..svn
>
Thanks
I have found a bug or two. Run this script and
see what happens ant the end.
rm -rf mygitsvn
rm -rf mysvnrepo
rm -rf mysvnwork
mkdir mysvnrepo
cd mysvnrepo
svnadmin create .
cd ..
svn checkout file:///$PWD/mysvnrepo mysvnwork
mkdir -p mysvnwork/trunk
cd mysvnwork/
cat << EOF > trunk/README
#
# (C) Copyright 2000 - 2005
# Wolfgang Denk, DENX Software Engineering, wd@denx.de.
#
# See file CREDITS for list of people who contributed to this
# project.
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License as
# published by the Free Software Foundation; either version 2 of
# the License, or (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
# MA 02111-1307 USA
#
EOF
svn add trunk
svn ci -m "first commit" trunk
cd ..
git-svn clone file:///$PWD/mysvnrepo -t tags -T trunk -b branches
mygitsvn
cd mygitsvn
git checkout --track -b svn remotes/trunk
git checkout -b merge
echo new file > new_file
git add new_file
git commit -a -m "New file"
echo hello >> README
git commit -a -m "hello"
echo add some stuff >> new_file
git commit -a -m "add some stuff"
git checkout svn
mv -f README tmp
echo friend > README
cat tmp >> README
git commit -a -m "friend"
git pull . merge
git svn dcommit # this fails
git svn rebase
# this fails too, mismerges the last commit and remove the merge commit
^ permalink raw reply
* Re: [ANNOUNCE] qgit-2.0rc1
From: Ismail Dönmez @ 2007-06-10 16:33 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List, Pavel Roskin, Andy Parkins
In-Reply-To: <e5bfff550706100736v110055acn8ecca19f5c3f5cff@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 458 bytes --]
On Sunday 10 June 2007 17:36:42 you wrote:
> On 6/10/07, Ismail Dönmez <ismail@pardus.org.tr> wrote:
> > Uploaded to http://cekirdek.pardus.org.tr/~ismail/tmp/qgit4-report.txt .
>
> Ok. You seem to miss all the debug libraries _and_ the whole
> libQtUiTools library.
Nope not a Qt problem. Removing -frepo from CXXFLAGS fixes the issue. Gcc
4.2.0 doesn't seem to like it for some reason.
Regards,
ismail
--
Perfect is the enemy of good
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]
^ permalink raw reply
* Please pull mergetool.git
From: Theodore Ts'o @ 2007-06-10 16:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
Hi Junio,
Please pull from the "mergetool" branch at:
git://repo.or.cz/git/mergetool.git mergetool
It adds support for vimdiff/gvimdiff as a mergetool program, as well
Josh's suggestion of making the default merge-tool selection more
intelligent, although I've rewritten it somewhat take into account the
comments made by you and others on the git mailing list.
(Note that as of this writing, meld is a pretty sad/dificient tool, and
even GNOME users may very well prefer kdiff3 over meld --- which is my
default. Still, it seems reasonable to default to using KDE tools in an
KDE login session, and GNOME tools in a GNOME login session, and people
who care differently should set their own preferences in ~/.gitconfig.)
- Ted
Dan McGee (1):
git-mergetool: Allow gvimdiff to be used as a mergetool
Theodore Ts'o (2):
git-mergetool: Make default selection of merge-tool more intelligent
Add git-applymbox, git-applypatch, and *~ to .gitignore
b/.gitignore | 3 ++
b/Documentation/config.txt | 2 -
b/Documentation/git-mergetool.txt | 2 -
b/git-mergetool.sh | 46 +++++++++++++++++++++++---------------
git-mergetool.sh | 12 ++++++++-
5 files changed, 44 insertions(+), 21 deletions(-)
diff --git a/.gitignore b/.gitignore
index 27e5aeb..70a4a68 100644
--- a/.gitignore
+++ b/.gitignore
@@ -7,6 +7,8 @@ git-add--interactive
git-am
git-annotate
git-apply
+git-applymbox
+git-applypatch
git-archimport
git-archive
git-bisect
@@ -161,6 +163,7 @@ git-core.spec
*.exe
*.[ao]
*.py[co]
+*~
config.mak
autom4te.cache
config.cache
diff --git a/Documentation/config.txt b/Documentation/config.txt
index de408b6..a2057d9 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -531,7 +531,7 @@ merge.summary::
merge.tool::
Controls which merge resolution program is used by
gitlink:git-mergetool[l]. Valid values are: "kdiff3", "tkdiff",
- "meld", "xxdiff", "emerge", "vimdiff", and "opendiff"
+ "meld", "xxdiff", "emerge", "vimdiff", "gvimdiff", and "opendiff".
merge.verbosity::
Controls the amount of output shown by the recursive merge
diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt
index b89c51c..6c32c6d 100644
--- a/Documentation/git-mergetool.txt
+++ b/Documentation/git-mergetool.txt
@@ -25,7 +25,7 @@ OPTIONS
-t or --tool=<tool>::
Use the merge resolution program specified by <tool>.
Valid merge tools are:
- kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, and opendiff
+ kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, and opendiff
+
If a merge resolution program is not specified, 'git mergetool'
will use the configuration variable merge.tool. If the
diff --git a/git-mergetool.sh b/git-mergetool.sh
index bb21b03..7b66309 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -215,6 +215,12 @@ merge_file () {
check_unchanged
save_backup
;;
+ gvimdiff)
+ touch "$BACKUP"
+ gvimdiff -f -- "$LOCAL" "$path" "$REMOTE"
+ check_unchanged
+ save_backup
+ ;;
xxdiff)
touch "$BACKUP"
if base_present ; then
@@ -293,7 +299,7 @@ done
if test -z "$merge_tool"; then
merge_tool=`git-config merge.tool`
case "$merge_tool" in
- kdiff3 | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | "")
+ kdiff3 | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | gvimdiff | "")
;; # happy
*)
echo >&2 "git config option merge.tool set to unknown tool: $merge_tool"
@@ -304,28 +310,42 @@ if test -z "$merge_tool"; then
fi
if test -z "$merge_tool" ; then
- if type kdiff3 >/dev/null 2>&1 && test -n "$DISPLAY"; then
- merge_tool="kdiff3";
- elif type tkdiff >/dev/null 2>&1 && test -n "$DISPLAY"; then
- merge_tool=tkdiff
- elif type xxdiff >/dev/null 2>&1 && test -n "$DISPLAY"; then
- merge_tool=xxdiff
- elif type meld >/dev/null 2>&1 && test -n "$DISPLAY"; then
- merge_tool=meld
- elif type opendiff >/dev/null 2>&1; then
- merge_tool=opendiff
- elif type emacs >/dev/null 2>&1; then
- merge_tool=emerge
- elif type vimdiff >/dev/null 2>&1; then
- merge_tool=vimdiff
- else
+ if test -n "$DISPLAY"; then
+ merge_tool_candidates="kdiff3 tkdiff xxdiff meld gvimdiff"
+ if test -n "$GNOME_DESKTOP_SESSION_ID" ; then
+ merge_tool_candidates="meld $merge_tool_candidates"
+ fi
+ if test "$KDE_FULL_SESSION" = "true"; then
+ merge_tool_candidates="kdiff3 $merge_tool_candidates"
+ fi
+ fi
+ if echo "${VISUAL:-$EDITOR}" | grep 'emacs' > /dev/null 2>&1; then
+ merge_tool_candidates="$merge_tool_candidates emerge"
+ fi
+ if echo "${VISUAL:-$EDITOR}" | grep 'vim' > /dev/null 2>&1; then
+ merge_tool_candidates="$merge_tool_candidates vimdiff"
+ fi
+ merge_tool_candidates="$merge_tool_candidates opendiff emerge vimdiff"
+ echo "merge tool candidates: $merge_tool_candidates"
+ for i in $merge_tool_candidates; do
+ if test $i = emerge ; then
+ cmd=emacs
+ else
+ cmd=$i
+ fi
+ if type $cmd > /dev/null 2>&1; then
+ merge_tool=$i
+ break
+ fi
+ done
+ if test -z "$merge_tool" ; then
echo "No available merge resolution programs available."
exit 1
fi
fi
case "$merge_tool" in
- kdiff3|tkdiff|meld|xxdiff|vimdiff|opendiff)
+ kdiff3|tkdiff|meld|xxdiff|vimdiff|gvimdiff|opendiff)
if ! type "$merge_tool" > /dev/null 2>&1; then
echo "The merge tool $merge_tool is not available"
exit 1
^ permalink raw reply related
* Re: Comment on weak refs
From: Jakub Narebski @ 2007-06-10 15:26 UTC (permalink / raw)
To: git
In-Reply-To: <7vk5ucd6of.fsf_-_@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Semantics
> ---------
>
> Not all "softref" relationship is equal. "This object is
> referred to by these tags" is one obvious application, and only
> because we already try to follow tags when git-fetch happens
> anyway, it looks natural to make everybody follow such a softref
> relationship.
Or "this onject is referred to by these _notes_", where notes differ
from tags on what is more important: name or comment (message). For
tags most important is the name, for notes most important is the
comment (which might be bug message, but might be correction to
commit message, or additional acked-by).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [ANNOUNCE] qgit-2.0rc1
From: Ismail Dönmez @ 2007-06-10 14:49 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List, Pavel Roskin, Andy Parkins
In-Reply-To: <e5bfff550706100736v110055acn8ecca19f5c3f5cff@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1034 bytes --]
On Sunday 10 June 2007 17:36:42 Marco Costalba wrote:
> On 6/10/07, Ismail Dönmez <ismail@pardus.org.tr> wrote:
> > Uploaded to http://cekirdek.pardus.org.tr/~ismail/tmp/qgit4-report.txt .
>
> Ok. You seem to miss all the debug libraries _and_ the whole
> libQtUiTools library.
>
> I've just upgraded to Qt4.3, and rebuilt everything without problems.
>
> So I think your Qt4.3 installation is broken, i.e. misses some stuff.
> I suggest to reinstall from your distribution (mine is Mandriva) or
> rebuild with missing pieces; debug (not mandatory but useful) and
> libQtUiTools.
You will be happy to know I am the qt4 packager for Pardus Linux *g* , I'll
check how Mandriva builds Qt4 but we don't apply any patch that would mess
with QtUiTools but its interesting its built as static only here.
> Below you can see my Qt lib directory after upgrade to Qt4.3 from
> distributor site.
Thanks.
> Let me know how it goes....
I'll let you know.
Regards,
ismail
--
Perfect is the enemy of good
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]
^ 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