* bidirectional hg <-> git syncing
From: Ondrej Certik @ 2008-11-05 12:48 UTC (permalink / raw)
To: Git Mailing List
Hi,
I wanted to share how we sync hg and git repo and I am interested if
anyone has any comments to it.
In our project [0], we used Mercurial, but recently several of the
core developers including me switched to git, but because we already
wrote docs and taught our users to use mercurial (see for example
[1]), we want to support both. So currently our main repo is still
mercurial and we automatically convert to git using
Our /home/hg/repos/sympy/.hg/hgrc contains:
[hooks]
#update the git repo
changegroup = /home/git/update-sympy.sh
where /home/git/update-sympy.sh is:
-----------
#!/bin/bash
cd /home/git/repos/sympy
sudo /bin/su git -c "../fast-export/hg-fast-export.sh -r /home/hg/repos/sympy"
cd /home/git/repos/
sudo /bin/su git -c "rm -rf sympy.git"
sudo /bin/su git -c "git clone --bare sympy/.git/ sympy.git"
sudo /bin/su git -c "echo 'main SymPy repository' > sympy.git/description"
sudo /bin/su git -c "touch sympy.git/git-daemon-export-ok"
---------
Which uses hg-fast-export to update the git repo.
Before pushing any patches in, we need to convert them to mercurial.
So if the user uses mercurial, nothing changes. If the user (like me)
uses git, I need to convert the patches to mercurial first, so that I
can push it in. So I do the following sequence, starting off my master
branch:
git checkout -b fix
# do some commits
./hgconvert
where the ./hgconvert script is:
-----
#! /bin/bash
work=`mktemp -t -d sym.XXX`
git format-patch -k -p -o $work master..HEAD
# add a new line after the subject line so that Mercurial imports it fine.
sed -i '4a\\' $work/*
cd ~/repos/sympy.hg/
hg import $work/*
rm -r $work
---------
This takes all patches commited after the master and commits them to
my hg repo at ~/repos/sympy.hg/. I'll then push them in, both our hg
and git repo updates and then I do in my local git repository:
git checkout master
git pull # this pulls the changes, essentially the same as in the
"fix" branch, only from our official git repo
git branch -D fix
This works nicely as long as I do not do any merges in my local git
repo. Is there some way to also convert the branches and merges? As I
understood it, there are tools that only convert the whole repo, but
since we already convert the whole repo from hg to git, I need to only
convert the latest commits from git back to hg.
One solution is to fully switch to git and convert to hg automatically
on our server -- and that's what we'll do soon probably. Then we'll be
able to push nonlinear history in git, but only linear in mercurial.
Thanks,
Ondrej
[0] http://code.google.com/p/sympy/
[1] http://docs.sympy.org/sympy-patches-tutorial.html
Ondrej
^ permalink raw reply
* let git-diff allow patch to delete empty files?
From: Sam Liddicott @ 2008-11-05 12:22 UTC (permalink / raw)
To: git
In some cases "patch" cannot apply diff's generated using git-diff, I've
had a "git diff" output look like this when an empty file was removed as
the only change:
diff --git a/source3/include/dcerpc.h b/source3/include/dcerpc.h
deleted file mode 100644
index e69de29..0000000
which patch rejected, saying:
patch: **** Only garbage was found in the patch input.
There is a ghastly diff notation recognized by patch, using the magic
date 1970-01-01 01:00:00.000000000 to signify deletion which git-diff
properly uses for non-empty files.
Empty files are a different matter because there is no unified diff that
can represent deletion of an empty file because patch doesn't like
unified diff's with no context.
However this equivalent pair works by making the file non-empty and then
deleting it.
diff -Nru 1/here 2/here
--- 1/here 2008-11-05 09:43:55.000000000 +0000
+++ 2/here 2008-11-05 09:43:58.000000000 +0000
@@ -0,0 +1 @@
+
diff -Nru 1/here 2/here
--- 1/here 2008-11-05 09:37:23.000000000 +0000
+++ 2/here 1970-01-01 01:00:00.000000000 +0100
@@ -1 +0,0 @@
-
In considering this filthy hack we should recognize that currently :
* patch will choke on certain "git diff" output. If patch's exit code is
checked as part of a loop of patches, then the patch procedure will
fail. This happened to me
* if delete-empty-file is one action in a larger patch file it will do
nothing - which can be worse if the "existence" of a file affects the
build system.
This filthy hack fixes both problems.
Sam
^ permalink raw reply
* Re: [PATCH 2/5] git send-email: interpret unknown files as revision lists
From: Pierre Habouzit @ 2008-11-05 10:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King
In-Reply-To: <7v1vxroxn1.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 3730 bytes --]
On Tue, Nov 04, 2008 at 11:54:26PM +0000, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
> > @@ -363,10 +366,22 @@ if (@alias_files and $aliasfiletype and defined $parse_alias{$aliasfiletype}) {
> >
> > ($sender) = expand_aliases($sender) if defined $sender;
> >
> > +sub check_file_rev_conflict($) {
> > + my $f = shift;
> > + if ($repo->command('rev-parse', '--verify', '--quiet', $f)) {
> > + die("revision/filename conflict on `$f'");
>
> Perhaps wording this a bit more to the point? This is triggered when
> '$f' can be both a filename or a revision, so...
>
> File '$f' exists but it could also be the range of commits
> to produce patches for. Please disambiguate by...
>
> * Saying "./$f" if you mean a file; or
> * Giving -F option if you mean a range.
>
> Earlier I suggested that "origin^0" is a way for the user to disambiguate
> favouring a rev, but such a filename can exist, so we cannot blindly
> suggest to say "$f^0" here. I think adding -F (or --format-patch) option
> to send-email to explicitly disable file/directory interpretation would be
> a cleaner solution for this (and it would allow you to drive this from a
> script without worrying about what garbage files you happen to have in the
> working tree).
Okay, still having --[no-]format-patch is probably a good idea indeed
for scripts. Will do.
On Tue, Nov 04, 2008 at 11:54:39PM +0000, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
>
> > + print C <<EOT;
> > +From $tpl_sender # This line is ignored.
> > +GIT: Lines beginning in "GIT: " will be removed.
> > +GIT: Consider including an overall diffstat or table of contents
> > +GIT: for the patch you are writing.
> > +GIT:
> > +GIT: Clear the body content if you don't wish to send a summary.
> > +From: $tpl_sender
> > +Subject: $tpl_subject
> > +In-Reply-To: $tpl_reply_to
> > +
>
> Somebody already suggested this but I really think GIT: lines should be at
> the end and use '# ' prefix instead.
This will break previous editor syntax hilighting stuff even more, and
has the drawback that you can't put shell sniplets in here. I think it's
why GIT: was chosen. But maybe we just don't care.
> With the ability to give --cover-letter option to underlying format-patch
> do you still need this?
>
> > + my $editor = $ENV{GIT_EDITOR} || Git::config(@repo, "core.editor") || $ENV{VISUAL} || $ENV{EDITOR} || "vi";
> > +
> > + if ($annotate) {
> > + do_edit($compose_filename, @files);
> > + } else {
> > + do_edit($compose_filename);
> > + }
>
> Don't we want to abort the whole process when the user kills the editor
> instead of normal exit (iow, do_edit() which is system() reports that the
> editor was killed)?
Probably, I kept what was done as is, but we probably want do_edit() to
die() if the user killed it.
On mer, nov 05, 2008 at 07:03:42 +0000, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
> > On Tue, Nov 04, 2008 at 03:54:54PM -0800, Junio C Hamano wrote:
> Yeah, if send-email did not have --compose to begin with, we could just
> say "don't use --compose; use --cover-letter when you use send-email to
> front-end format-patch instead", but some people perhaps are used to run
> format-patch separately without --cover-letter and then create the cover
> letter from scratch with --compose (which seems a bit more work to me,
> though).
>
> So I am not opposed to a sendemail.foo configuration option.
Will do
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* git-svn: Having a "rare" structure
From: Marc Fargas @ 2008-11-05 10:04 UTC (permalink / raw)
To: git
Hi all,
First of all, please CC responses to me as I'm not subscribed to this list ;)
On the subject, I use git-svn to for most of my stuff and also to
"interact" with some SVN projects out there, there's one that is
driving me mad.
The Django project has a (somehow) rare SVN structure that I almost
managet to make git-svn understand, but a recent "rarity" to the
structure broke it again and I haven't succeeded in making git-svn
understand it, so I'm trying to get some guidance on how to make
git-svn understand the structure.
Right know the Django SVN repo is like that:
browse: http://code.djangoproject.com/browser/django
svn url: http://code.djangoproject.com/svn/django
trunk/
tags/notable_moments/
tags/releases/
branches/*
branches/features/
branches/releases/
Until now, the last two didn't exist and git-svn was working nicely,
but now "features" and "releases" were created, and git-svn is taking
them as if they were branches, while they arent (branches are in
subdirectories of those two).
My git repo was done like that until now:
git svn init --prefix svn/
http://code.djangoproject.com/svn/django -T trunk -b branches -t
'tags/*/*'
git svn fetch
With that, git-svn understood that tags were in the subdirectories of
tags/{notable_moments,releases}/ but I can't do that with the branches
as there are branches also in the top branches/ directory.
I do not really care about those branches on the top directory as
those are old, so I really only need git-svn to understand the
{features,releases}/* thing. So:
How can I do something like "-b branches/{features,releases}/*" making
git-svn ignore the other top-level branches? Or, can I make it
understand both, the top-level ones and the ones inside those two
subdirectories?
Note that I just gueesed the "-b branches/{features,releases}/*"
thing; I didn't try it, tryiing takes lots of time and bandwidth ;\\
Thanks for all,
Marc
--
http://www.marcfargas.com - will be finished someday.
^ permalink raw reply
* Re: git pull regression?
From: Carlos R. Mafra @ 2008-11-05 9:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20081105083810.GA22318@localhost.aei.mpg.de>
On Wed 5.Nov'08 at 9:38:10 +0100, Carlos R. Mafra wrote:
> On Tue 4.Nov'08 at 15:37:03 -0800, Junio C Hamano wrote:
> > "Carlos R. Mafra" <crmafra2@gmail.com> writes:
> >
> > > It looks like a regression to me. I can finish
> > > the bisection if people in the list say that
> > > I am not making a mistake somewhere :-)
> >
> > Interesting, and _sounds_ like a regression, but I do not think anybody
> > can tell if it is without looking at what .git/config and exact command
> > sequence you are using for this "git pull" and where you are starting
> > from.
Hm...that what I feared most has just happened.
I tried to bisect my problem when I realized that it wasn't
goint to take 2 hours and a lot of reboots like with the kernel :-)
And I soon realized that something was wrong when I was
running 'make install'. I had two terminals open, one with
the regular user with which I was compiling git, and the
other with the root user where I run 'make install'.
After compiling with the regular user and running
'make install' with the root user from the other terminal
the whole compilation was happening again and strangely
it was installing things in the prefix /root instead of
/usr/local
I simply don't know why this happened nor how. But
somehow my git installation was screwed.
I have just compiled the latest git and it is ok now.
I am really sorry for all the noise, but I was
sincerely fooled by the symptoms (as you can see
in the previous email).
^ permalink raw reply
* Slow "git rev-list origin/master --not --all" or "git fetch" slow when downloading nothing
From: Santi Béjar @ 2008-11-05 9:38 UTC (permalink / raw)
To: Git Mailing List
Hi *,
In cold cache "git rev-list origin/master --not --all" is slow
reading many files:
cold cache:
$ /usr/bin/time git rev-list origin/master --not --all
0.03user 0.02system 0:04.57elapsed 1%CPU (0avgtext+0avgdata 0maxresident)k
77848inputs+0outputs (410major+1798minor)pagefaults 0swaps
hot cache:
$ /usr/bin/time git rev-list origin/master --not --all
0.01user 0.00system 0:00.06elapsed 31%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+2207minor)pagefaults 0swaps
I think that, in this particular case (when the arguments are the tips
of some of the branches), this should not read that many files.
Moreover, this is used in "git fetch" (git rev-list --quiet --objects
<list_of_remote_sha1> --not --all) to detect if all the objects are
reachable from the local repository. When nothing has changed in the
remote repository (so refs/<remote>/* has all the remote refs) the
"git fetch" could be almost instantaneous (even in coldcache), but
currently it is not because of the above.
Thanks,
Santi
^ permalink raw reply
* Re: git pull regression?
From: Carlos R. Mafra @ 2008-11-05 8:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtzanoyg0.fsf@gitster.siamese.dyndns.org>
On Tue 4.Nov'08 at 15:37:03 -0800, Junio C Hamano wrote:
> "Carlos R. Mafra" <crmafra2@gmail.com> writes:
>
> > It looks like a regression to me. I can finish
> > the bisection if people in the list say that
> > I am not making a mistake somewhere :-)
>
> Interesting, and _sounds_ like a regression, but I do not think anybody
> can tell if it is without looking at what .git/config and exact command
> sequence you are using for this "git pull" and where you are starting
> from.
Ok, I am sorry for the lack of details, which I provide now.
It happened again with the git repo itself (Linus hasn't
updated his yet).
[mafra@localhost:git]$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = git://git.kernel.org/pub/scm/git/git.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
And the commands were these (ok, I made a mistake that
I pulled without being first in the master branch,
but the problem I am describing here also happened
before, when I was already in the master branch)
[mafra@localhost:git]$ git --version
git version 1.6.0.3
[mafra@localhost:git]$ git log
[mafra@localhost:git]$ git pull
remote: Counting objects: 245, done.
remote: Compressing objects: 100% (49/49), done.
remote: Total 131 (delta 100), reused 109 (delta 82)
Receiving objects: 100% (131/131), 33.91 KiB, done.
Resolving deltas: 100% (100/100), completed with 43 local objects.
From git://git.kernel.org/pub/scm/git/git
aa17c7c..826ea6f html -> origin/html
a5a323f..16088d8 maint -> origin/maint
1655dcb..1e98488 man -> origin/man
9f8f132..5508064 master -> origin/master
58edc95..494ccbd next -> origin/next
+ fe6aa64...a5f8d19 pu -> origin/pu (forced update)
You asked me to pull without telling me which branch you
want to merge with, and 'branch..merge' in
your configuration file does not tell me either. Please
name which branch you want to merge on the command line and
try again (e.g. 'git pull <repository> <refspec>').
See git-pull(1) for details on the refspec.
If you often merge with the same branch, you may want to
configure the following variables in your configuration
file:
branch..remote = <nickname>
branch..merge = <remote-ref>
remote.<nickname>.url = <url>
remote.<nickname>.fetch = <refspec>
See git-config(1) for details.
[mafra@localhost:git]$ git branch
* (no branch)
master
[mafra@localhost:git]$ git checkout master
Previous HEAD position was 031e6c8... GIT 1.6.0.3
Switched to branch "master"
Your branch is behind 'origin/master' by 5 commits, and can be fast-forwarded.
[mafra@localhost:git]$ git pull
[mafra@localhost:git]$ git status
# On branch master
# Your branch is behind 'origin/master' by 5 commits, and can be fast-forwarded.
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# git-help--browse
# git-merge-stupid
# test-absolute-path
nothing added to commit but untracked files present (use "git add" to track)
[mafra@localhost:git]$ git pull
[mafra@localhost:git]$
Notice how "git pull" doesn't say "Already up-to-date" anymore.
And now 'git log' shows me the last commit being
9f8f132621faedd instead of the really last one 550806439402
These are the same issues that I described in the first email
when I updated Linus' tree, so they are not due to the mistake
of not being in master branch.
And now if I go back to v1.6.0 I get this
[mafra@localhost:git]$ git checkout master
Switched to branch "master"
Your branch is behind 'origin/master' by 5 commits, and can be fast-forwarded.
[mafra@localhost:git]$ git pull
Updating 9f8f132..5508064
Fast forward
Documentation/Makefile | 8 ++++-
Documentation/git-format-patch.txt | 3 +-
INSTALL | 5 ++-
Makefile | 6 ++++
contrib/hooks/post-receive-email | 57 ++++++++++++++++++++++++++++++------
5 files changed, 65 insertions(+), 14 deletions(-)
[mafra@localhost:git]$
and everything is ok again.
Anything else I can do to help or is bisection the last resort? :-)
Thanks,
Carlos
^ permalink raw reply
* Re: [PATCH 5/5] git send-email: turn --compose on when more than one patch.
From: Junio C Hamano @ 2008-11-05 7:03 UTC (permalink / raw)
To: Jeff King; +Cc: Pierre Habouzit, git
In-Reply-To: <20081105033151.GB24886@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Nov 04, 2008 at 03:54:54PM -0800, Junio C Hamano wrote:
>
>> Pierre Habouzit <madcoder@debian.org> writes:
>>
>> > Automatically turn --compose on when there is more than one patch, and
>> > that the output is a tty.
>>
>> I do not think this is a good idea. I suspect I am not the only person
>> who uses "format-patch --cover-letter", edit the files to review and
>> prepare, and runs send-email to fire them off.
>
> Maybe a config option to turn this behavior on? It seems specific to
> different workflows (i.e., whether or not you are using "git send-email
> $REVS" or using format-patch first).
Yeah, if send-email did not have --compose to begin with, we could just
say "don't use --compose; use --cover-letter when you use send-email to
front-end format-patch instead", but some people perhaps are used to run
format-patch separately without --cover-letter and then create the cover
letter from scratch with --compose (which seems a bit more work to me,
though).
So I am not opposed to a sendemail.foo configuration option.
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Junio C Hamano @ 2008-11-05 6:40 UTC (permalink / raw)
To: Jeff King
Cc: Sam Vilain, Dmitry Potapov, Sam Vilain, git, Johannes Schindelin,
Scott Chacon, Tom Preston-Werner, J.H., Christian Couder,
Kai Blin
In-Reply-To: <20081105030525.GC20907@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> So why not take one step back in the behavior change? We can set up the
> "push just this branch" refspec during clone, which will leave existing
> repositories untouched.
That is not good enough.
People who (think) know what an unconfigured "git push" would do would
suddenly see "git push" start misbehaving in their new repositories.
Here is a patch to do what I suggested earlier. It
* Adds "--matching" option; if we ever change the default to "current
branch only", then "git push $there :" forces people to type $there.
"git push --matching" allows us to honor "branch.<name>.remote".
* Issues a deprecation warning when "git push" and "git push $there" is
used to trigger the "matching" behaviour, without configuration or
explicit command line refspec ":".
Whoever wants to change the default to "current branch only" can change
the part that calls push_deprecation_warning().
I'll leave it up to people who want to change the default to implement the
same for non native transports and document the transition plan, as I am
not very keen on changing the default myself.
---
builtin-push.c | 11 +++++++----
builtin-send-pack.c | 2 ++
remote.c | 8 ++++++++
remote.h | 1 +
send-pack.h | 1 +
transport.c | 1 +
transport.h | 1 +
7 files changed, 21 insertions(+), 4 deletions(-)
diff --git c/builtin-push.c w/builtin-push.c
index 122fdcf..21418ab 100644
--- c/builtin-push.c
+++ w/builtin-push.c
@@ -10,7 +10,7 @@
#include "parse-options.h"
static const char * const push_usage[] = {
- "git push [--all | --mirror] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>] [--repo=<repository>] [-f | --force] [-v] [<repository> <refspec>...]",
+ "git push [--all | --mirror] [--dry-run] [--matching] [--tags] [--receive-pack=<git-receive-pack>] [--repo=<repository>] [-f | --force] [-v] [<repository> <refspec>...]",
NULL,
};
@@ -71,9 +71,11 @@ static int do_push(const char *repo, int flags)
return error("--mirror can't be combined with refspecs");
}
- if ((flags & (TRANSPORT_PUSH_ALL|TRANSPORT_PUSH_MIRROR)) ==
- (TRANSPORT_PUSH_ALL|TRANSPORT_PUSH_MIRROR)) {
- return error("--all and --mirror are incompatible");
+ if (HAS_MULTI_BITS(flags &
+ (TRANSPORT_PUSH_ALL|
+ TRANSPORT_PUSH_MIRROR|
+ TRANSPORT_PUSH_MATCHING))) {
+ return error("--all, --mirror, --matching are incompatible");
}
if (!refspec
@@ -123,6 +125,7 @@ int cmd_push(int argc, const char **argv, const char *prefix)
OPT_BOOLEAN( 0 , "tags", &tags, "push tags"),
OPT_BIT( 0 , "dry-run", &flags, "dry run", TRANSPORT_PUSH_DRY_RUN),
OPT_BIT('f', "force", &flags, "force updates", TRANSPORT_PUSH_FORCE),
+ OPT_BIT( 0 , "matching", &flags, "push matching", TRANSPORT_PUSH_MATCHING),
OPT_BOOLEAN( 0 , "thin", &thin, "use thin pack"),
OPT_STRING( 0 , "receive-pack", &receivepack, "receive-pack", "receive pack program"),
OPT_STRING( 0 , "exec", &receivepack, "receive-pack", "receive pack program"),
diff --git c/builtin-send-pack.c w/builtin-send-pack.c
index d68ce2d..f5dda88 100644
--- c/builtin-send-pack.c
+++ w/builtin-send-pack.c
@@ -402,6 +402,8 @@ static int do_send_pack(int in, int out, struct remote *remote, const char *dest
flags |= MATCH_REFS_ALL;
if (args.send_mirror)
flags |= MATCH_REFS_MIRROR;
+ if (args.send_matching)
+ flags |= MATCH_REFS_MATCHING;
/* No funny business with the matcher */
remote_tail = get_remote_heads(in, &remote_refs, 0, NULL, REF_NORMAL,
diff --git c/remote.c w/remote.c
index e530a21..ce4f54c 100644
--- c/remote.c
+++ w/remote.c
@@ -1017,6 +1017,12 @@ static const struct refspec *check_pattern_match(const struct refspec *rs,
return NULL;
}
+static void push_deprecation_warning(void)
+{
+ warning("'git push [$remote]' will stop pushing 'matching refs' in a future release");
+ warning("please train your fingers to say 'git push --matching' instead.");
+}
+
/*
* Note. This is used only by "push"; refspec matching rules for
* push and fetch are subtly different, so do not try to reuse it
@@ -1031,6 +1037,8 @@ int match_refs(struct ref *src, struct ref *dst, struct ref ***dst_tail,
static const char *default_refspec[] = { ":", 0 };
if (!nr_refspec) {
+ if (!(flags & MATCH_REFS_MATCHING))
+ push_deprecation_warning();
nr_refspec = 1;
refspec = default_refspec;
}
diff --git c/remote.h w/remote.h
index d2e170c..2a702cb 100644
--- c/remote.h
+++ w/remote.h
@@ -124,6 +124,7 @@ enum match_refs_flags {
MATCH_REFS_NONE = 0,
MATCH_REFS_ALL = (1 << 0),
MATCH_REFS_MIRROR = (1 << 1),
+ MATCH_REFS_MATCHING = (1 << 2),
};
/* Reporting of tracking info */
diff --git c/send-pack.h w/send-pack.h
index 8ff1dc3..133cb67 100644
--- c/send-pack.h
+++ w/send-pack.h
@@ -6,6 +6,7 @@ struct send_pack_args {
unsigned verbose:1,
send_all:1,
send_mirror:1,
+ send_matching:1,
force_update:1,
use_thin_pack:1,
dry_run:1;
diff --git c/transport.c w/transport.c
index 56831c5..4057d27 100644
--- c/transport.c
+++ w/transport.c
@@ -680,6 +680,7 @@ static int git_transport_push(struct transport *transport, int refspec_nr, const
args.receivepack = data->receivepack;
args.send_all = !!(flags & TRANSPORT_PUSH_ALL);
args.send_mirror = !!(flags & TRANSPORT_PUSH_MIRROR);
+ args.send_matching = !!(flags & TRANSPORT_PUSH_MATCHING);
args.force_update = !!(flags & TRANSPORT_PUSH_FORCE);
args.use_thin_pack = data->thin;
args.verbose = !!(flags & TRANSPORT_PUSH_VERBOSE);
diff --git c/transport.h w/transport.h
index 6bbc1a8..fb98128 100644
--- c/transport.h
+++ w/transport.h
@@ -34,6 +34,7 @@ struct transport {
#define TRANSPORT_PUSH_DRY_RUN 4
#define TRANSPORT_PUSH_MIRROR 8
#define TRANSPORT_PUSH_VERBOSE 16
+#define TRANSPORT_PUSH_MATCHING 32
/* Returns a transport suitable for the url */
struct transport *transport_get(struct remote *, const char *);
^ permalink raw reply related
* Re: [PATCH/RFC v2] git-add--interactive.perl: Answer questions with a single keypress
From: Suraj N. Kurapati @ 2008-11-05 6:31 UTC (permalink / raw)
To: git
In-Reply-To: <200811042215.31147.sunaku@gmail.com>
Allows the user to answer 'Stage this hunk' questions with a
single keypress, just like in Darcs. Previously, the user was
forced to press the Return key after every choice they made.
This quickly becomes tiring, burdensome work for the fingers.
Signed-off-by: Suraj N. Kurapati <sunaku@gmail.com>
---
git-add--interactive.perl | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index b0223c3..a824984 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -877,6 +877,8 @@ sub patch_update_file {
$num = scalar @hunk;
$ix = 0;
+ require Term::ReadKey;
+ Term::ReadKey::ReadMode('raw');
while (1) {
my ($prev, $next, $other, $undecided, $i);
$other = '';
@@ -920,7 +922,7 @@ sub patch_update_file {
print;
}
print colored $prompt_color, "Stage this hunk [y/n/a/d$other/?]? ";
- my $line = <STDIN>;
+ my $line = Term::ReadKey::ReadKey(0);
if ($line) {
if ($line =~ /^y/i) {
$hunk[$ix]{USE} = 1;
@@ -998,6 +1000,7 @@ sub patch_update_file {
}
}
}
+ Term::ReadKey::ReadMode('restore');
my $n_lofs = 0;
my @result = ();
--
1.6.0.3
\0
^ permalink raw reply related
* [PATCH/RFC] git-add--interactive.perl: Answer questions with a single keypress
From: Suraj N. Kurapati @ 2008-11-05 6:15 UTC (permalink / raw)
To: git
From aef6df163b90b9485da1f97a14ffab6d8de9b047 Mon Sep 17 00:00:00 2001
From: Suraj N. Kurapati <sunaku@gmail.com>
Date: Tue, 4 Nov 2008 20:32:34 -0800
Subject: [PATCH] git-add--interactive.perl: Answer questions with a single keypress
Allows the user to answer 'Stage this hunk' questions with a
single keypress, just like in Darcs. Previously, the user
was forced to press the Return key after every choice, which
quickly becomes tiring and burdensome work for the fingers.
Signed-off-by: Suraj N. Kurapati <sunaku@gmail.com>
---
git-add--interactive.perl | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index b0223c3..1a22968 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -877,6 +877,7 @@ sub patch_update_file {
$num = scalar @hunk;
$ix = 0;
+ require Term::ReadKey;
while (1) {
my ($prev, $next, $other, $undecided, $i);
$other = '';
@@ -920,7 +921,10 @@ sub patch_update_file {
print;
}
print colored $prompt_color, "Stage this hunk [y/n/a/d$other/?]? ";
- my $line = <STDIN>;
+
+ Term::ReadKey::ReadMode('raw');
+ my $line = Term::ReadKey::ReadKey(0);
+ Term::ReadKey::ReadMode('restore');
if ($line) {
if ($line =~ /^y/i) {
$hunk[$ix]{USE} = 1;
--
1.6.0.3
\0
^ permalink raw reply related
* Re: Repo corrupted somehow?
From: Daniel Barkalow @ 2008-11-05 5:56 UTC (permalink / raw)
To: Andrew Arnott; +Cc: git
In-Reply-To: <216e54900811042127id69b61fqbd9d001b8bc17a6a@mail.gmail.com>
On Tue, 4 Nov 2008, Andrew Arnott wrote:
> It was the CRLF conversion. When I played around with
> git config --global core.autocrlf true/false
> I got the problem to eventually go away.
>
> Thanks for all your responses.
It's still worth debugging further, because git should know that it wrote
the files differently and not see that as changes. It's not too helpful to
have autocrlf if it causes this problem.
Are you using something (like .gitattributes) to mark files as text or as
non-text? Is this under Cygwin? It might be fixed in a newer version,
also.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Repo corrupted somehow?
From: Andrew Arnott @ 2008-11-05 5:40 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <216e54900811042127id69b61fqbd9d001b8bc17a6a@mail.gmail.com>
It was the CRLF conversion. When I played around with
git config --global core.autocrlf true/false
I got the problem to eventually go away.
Thanks for all your responses.
>
> On Tue, Nov 4, 2008 at 8:21 PM, Daniel Barkalow <barkalow@iabervon.org> wrote:
>>
>> On Mon, 3 Nov 2008, Andrew Arnott wrote:
>>
>> > I was just git commit'ing, and then I was doing a git rebase to squash
>> > several commits into one when the rebase failed. I then did a
>> > git checkout -f master
>> > git reset --hard
>> > but no matter what I do, git thinks that several files have changed.
>> > The diff shows all the lines in these several files removed and then
>> > added, yet without any changes made to them.
>>
>> That sounds like some failure of CRLF conversion, like it's converting all
>> of the line endings somehow when writing to the working tree and then not
>> expecting them to be different. Do you have some sort of interesting
>> configuration for those? I wonder if you've got a .gitattributes that
>> matches the names that git uses for the files, but are on a
>> case-insensitive filesystem which lists those files in a way where their
>> names don't match (or vice versa).
>>
>> -Daniel
>> *This .sig left intentionally blank*
>
^ permalink raw reply
* Re: Repo corrupted somehow?
From: Daniel Barkalow @ 2008-11-05 4:21 UTC (permalink / raw)
To: Andrew Arnott; +Cc: git
In-Reply-To: <216e54900811032309s51c8cb1fr64054ff18c450b1d@mail.gmail.com>
On Mon, 3 Nov 2008, Andrew Arnott wrote:
> I was just git commit'ing, and then I was doing a git rebase to squash
> several commits into one when the rebase failed. I then did a
> git checkout -f master
> git reset --hard
> but no matter what I do, git thinks that several files have changed.
> The diff shows all the lines in these several files removed and then
> added, yet without any changes made to them.
That sounds like some failure of CRLF conversion, like it's converting all
of the line endings somehow when writing to the working tree and then not
expecting them to be different. Do you have some sort of interesting
configuration for those? I wonder if you've got a .gitattributes that
matches the names that git uses for the files, but are on a
case-insensitive filesystem which lists those files in a way where their
names don't match (or vice versa).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: exporting the last N days of a repository
From: Geoff Russell @ 2008-11-05 3:54 UTC (permalink / raw)
To: Bob Hiestand; +Cc: git, Johannes Schindelin
In-Reply-To: <cc29171c0811041618jfbcb293l42a19805f06803a0@mail.gmail.com>
On Wed, Nov 5, 2008 at 10:48 AM, Bob Hiestand <bob.hiestand@gmail.com> wrote:
> On Tue, Nov 4, 2008 at 4:49 PM, Geoff Russell
> <geoffrey.russell@gmail.com> wrote:
>> Apologies to Johannes and Bob who have tried to help
>> but I'm still having difficulties, here is my current non-working script:
>>
>> ------------------------------------------------------------------
>> #!/bin/sh
>> DIR=/tmp/gitdemo
>> # for testing just arbitrarily
>> # select the 15th most recent commit as our new origin
>> NEWORIGIN=$(git rev-list master@{15} | head -1)
>> echo $NEWORIGIN
>> # checkout earlist point we are interested in
>> # we want to drop any history before this point
>> git checkout $NEWORIGIN
>> # now make a new directory, initialise with new origin
>> # and apply all commits after that point
>> mkdir $DIR && (cd $DIR ; git init) && \
>> rsync -aHv --exclude=.git ./ $DIR && \
>> (cd $DIR ; git add . ; git commit -m "starting point" </dev/null ) && \
>> git fast-export $NEWORIGIN..master | (cd $DIR ; git fast-import )
>>
>> ----------------- end of script
>>
>> The fast-import gives me a message I don't understand and doesn't
>> do the import.
>
> If I understood your requirement (I know nothing about fast-export),
> it would look like this:
>
> #!/bin/sh
> DIR=/tmp/gitdemo
> ORIGDIR=$PWD
> git checkout -b shorthistory
> NEWORIGIN=$(git rev-list --since='5 months ago' --reverse HEAD| head -1)
> echo $NEWORIGIN
> git filter-branch --parent-filter '
> test $GIT_COMMIT = '$NEWORIGIN' &&
> echo || cat' \
> --tag-name-filter cat $NEWORIGIN^..
> mkdir $DIR
> cd $DIR
> git init
> git fetch $ORIGDIR shorthistory:master
Thanks Bob but when I ran your version (using master@{15} instead of
--since =...) it
effectively dropped the recent history, not the old history. Imagine a sequence
of 30 commits, no branches. I want to keep, for example, 15 through
30 and dump 1
to 15. So I need to have the working directory as at commit 15 and
then all the changes
to bring it up to 30.
... 11--12--13--14--15 ... 28--29--30
... Dump 1 to 15 keep 15 to 30.
Your script kept 1 to 15 and dumped the rest.
Cheers,
Geoff.
>
>
> Thank you,
>
> bob
>
--
6 Fifth Ave,
St Morris, S.A. 5068
Australia
Ph: 041 8805 184 / 08 8332 5069
^ permalink raw reply
* Re: [PATCH 5/5] git send-email: turn --compose on when more than one patch.
From: Jeff King @ 2008-11-05 3:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pierre Habouzit, git
In-Reply-To: <7vprlbnj1t.fsf@gitster.siamese.dyndns.org>
On Tue, Nov 04, 2008 at 03:54:54PM -0800, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
>
> > Automatically turn --compose on when there is more than one patch, and
> > that the output is a tty.
>
> I do not think this is a good idea. I suspect I am not the only person
> who uses "format-patch --cover-letter", edit the files to review and
> prepare, and runs send-email to fire them off.
Maybe a config option to turn this behavior on? It seems specific to
different workflows (i.e., whether or not you are using "git send-email
$REVS" or using format-patch first).
-Peff
^ permalink raw reply
* Re: Repo corrupted somehow?
From: Jeff King @ 2008-11-05 3:29 UTC (permalink / raw)
To: Andrew Arnott; +Cc: git
In-Reply-To: <216e54900811040712k51db6fbfu44c59d9f90f1eabd@mail.gmail.com>
On Tue, Nov 04, 2008 at 07:12:40AM -0800, Andrew Arnott wrote:
> Nah, that wasn't a false alarm after all. It's happening again, only
> this time for dozens of files, and
> git rebase --abort
> git reset --hard
>
> is not helping.
This is certainly unusual. Can you provide a tarball of your repo
(including .git and working tree)? I don't know that a clone will be
sufficient if there is something funny going on in your local git index.
-Peff
^ permalink raw reply
* Re: Intensive rename detection
From: Jeff King @ 2008-11-05 3:22 UTC (permalink / raw)
To: Andrew Arnott; +Cc: Junio C Hamano, Linus Torvalds, git
In-Reply-To: <216e54900811032236l5ae4bde5v16ab6519962e428f@mail.gmail.com>
On Mon, Nov 03, 2008 at 10:36:42PM -0800, Andrew Arnott wrote:
> Yes, on git status. I'm afraid I don't know how to look up the
> reference you gave.
Sorry, gmane is back up, so the link is:
http://article.gmane.org/gmane.comp.version-control.git/99147
With that patch, and this one on top, "git status" should respect your
rename limits (though I haven't tested it).
---
diff --git a/wt-status.c b/wt-status.c
index c3a9cab..0b92ac3 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -214,7 +214,6 @@ static void wt_status_print_updated(struct wt_status *s)
rev.diffopt.format_callback = wt_status_print_updated_cb;
rev.diffopt.format_callback_data = s;
rev.diffopt.detect_rename = 1;
- rev.diffopt.rename_limit = 200;
rev.diffopt.break_opt = 0;
run_diff_index(&rev, 1);
}
-Peff
^ permalink raw reply related
* Re: CRLF support bugs (was: Re: .gitattributes glob matchingbroken)
From: Jeff King @ 2008-11-05 3:07 UTC (permalink / raw)
To: Kelly F. Hickel; +Cc: Hannu Koivisto, git
In-Reply-To: <63BEA5E623E09F4D92233FB12A9F79430296676E@emailmn.mqsoftware.com>
On Tue, Nov 04, 2008 at 06:37:27AM -0600, Kelly F. Hickel wrote:
> From my point of view, the factoid that a particular file should be
> subjected to having its line endings munged is a _project_ decision.
> Whether or not to munge them on any given platform is a _local_
> decision.
Now that you spell it out, I am reminded that that is the argument I
remember having seen in past discussions. And of course, that argues for
.gitattributes being carried by the project, but the core.autocrlf
_config_ being a local decision.
Which, perhaps not coincidentally, is how it is currently implemented. :)
-Peff
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Jeff King @ 2008-11-05 3:05 UTC (permalink / raw)
To: Junio C Hamano
Cc: Sam Vilain, Dmitry Potapov, Sam Vilain, git, Johannes Schindelin,
Scott Chacon, Tom Preston-Werner, J.H., Christian Couder,
Kai Blin
In-Reply-To: <7vr65rqnoj.fsf@gitster.siamese.dyndns.org>
On Tue, Nov 04, 2008 at 11:46:36AM -0800, Junio C Hamano wrote:
> These days, people who would want the maching behaviour can explicitly ask
> for it, so there is one less reason to resist changing the default
> (i.e. earlier explicitly askinf for "matching" was impossible, but now we
> can). The remaining reason of resistance is pure inertia (i.e. not
> changing the behaviour of the command only because you upgraded your git),
> and the only way to address it is to start issuing the warning when "git
> push" or "git push $there" is used and the matching behaviour was chosen
> without configuration (i.e. no "remote.<there>.push = :"), and keep it
> that way for two release cycles, and finally change the default.
Hmm. It really seems to me that there are two desires for push behavior,
based on particular workflows. I.e., some people seem to want the
matching behavior by default, and others want to push the current
branch.
And we already can control that via configuration of the refspec. So any
argument that "git push should do the same thing even on somebody else's
setup" is already wrong. But I do think Junio has a good point, which is
that there is going to be confusion if upgrading git suddenly causes
"git push" to do something else.
So why not take one step back in the behavior change? We can set up the
"push just this branch" refspec during clone, which will leave existing
repositories untouched. And to make things even gentler, we can start
with opt-in to the clone feature, notify users via the release notes
(which, as we have established, EVERYONE reads), and then decide if and
when to switch the option on by default.
So something like a "remote.push" config option, the value of which gets
added to newly created remotes (including those created on clone). It
would default to ":", but you could easily set "git config remote.push
HEAD" to get the other behavior.
No, this doesn't get rid of the eventual need to choose whether to
switch the default. But I think it eases us into it a little more. And I
think such an option is a lot more generally applicable than a "default
push to matching versus HEAD" option.
-Peff
^ permalink raw reply
* Re: [PATCH v2] push: fix local refs update if already up-to-date
From: Jeff King @ 2008-11-05 2:51 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: Junio C Hamano, git
In-Reply-To: <20081104205743.GA26788@localhost>
On Tue, Nov 04, 2008 at 09:57:43PM +0100, Clemens Buchacher wrote:
> On Mon, Nov 03, 2008 at 11:26:44PM -0500, Jeff King wrote:
> > Nit: Just reading the test, it is hard to see what is interesting about
> > it (though obviously I can blame it back to your commit :) ). Maybe a
> > more descriptive title like 'push updates uptodate local refs' would
> > make sense.
>
> That is all I changed in this update. Pending an Ack/Nack from Jeff I feel
> that I'm done.
I have to NAK, because the extra written ref is still a problem (see my
other mail). But with that fix (and I hope you both will agree with the
style fixup on removing new_sha1, too), I think it should be good.
-Peff
^ permalink raw reply
* Re: [PATCH] push: fix local refs update if already up-to-date
From: Jeff King @ 2008-11-05 2:49 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: git, Junio C Hamano
In-Reply-To: <20081104085630.GA22530@localhost>
On Tue, Nov 04, 2008 at 09:56:30AM +0100, Clemens Buchacher wrote:
> The other status flags are REF_STATUS_REJECT_NODELETE and
> REF_STATUS_REJECT_NONFASTFORWARD. So in these cases the "new sha1" is going
> to be the "old sha1". The default for new_sha1 is the null sha1. So while
> the sha1 we're trying to push may not be more valid than the null sha1, it's
> not less valid either, is it? And it even makes sense if you interpret
> new_sha1 as the sha1 the client attempts to push.
I have to admit I did not exhaustively look at all of the status cases
when I reviewed earlier, and there are fewer than I realized. So I think
your change is reasonable.
However, I would like to make one additional request. Since you are
killing off all usage of new_sha1 initial assignment, I think it makes
sense to just get rid of the variable entirely, so it cannot create
confusion later. Like this (on top of your patch):
diff --git a/builtin-send-pack.c b/builtin-send-pack.c
index 4c17f48..d139eba 100644
--- a/builtin-send-pack.c
+++ b/builtin-send-pack.c
@@ -435,16 +435,13 @@ static int do_send_pack(int in, int out, struct remote *remote, const char *dest
*/
new_refs = 0;
for (ref = remote_refs; ref; ref = ref->next) {
- const unsigned char *new_sha1;
-
if (!ref->peer_ref) {
if (!args.send_mirror)
continue;
- new_sha1 = null_sha1;
+ hashcpy(ref->new_sha1, null_sha1);
}
else
- new_sha1 = ref->peer_ref->new_sha1;
- hashcpy(ref->new_sha1, new_sha1);
+ hashcpy(ref->new_sha1, ref->peer_ref->new_sha1);
ref->deletion = is_null_sha1(ref->new_sha1);
if (ref->deletion && !allow_deleting_refs) {
> > Hmm. I was hoping to see more in update_tracking_ref. With your patch,
> > we end up calling update_ref for _every_ uptodate ref, which results in
> > writing a new unpacked ref file for each one. And that _is_ a
> > performance problem for people with large numbers of refs.
> [...]
> I think update_ref already takes care of that. See this check in
> write_ref_sha1:
>
> if (!lock->force_write && !hashcmp(lock->old_sha1, sha1)) {
> unlock_ref(lock);
> return 0;
> }
Nope. That check is a concurrency safeguard. It checks that when we are
moving the ref from "A" to "B", that the ref still _is_ "A" when we lock
it.
But more importantly, it is easy to demonstrate the problem with your
patch:
mkdir parent &&
(cd parent &&
git init && touch file && git add file && git commit -m one) &&
git clone parent child &&
(cd child &&
echo BEFORE: && ls -l .git/refs/remotes/origin &&
git push &&
echo AFTER: && ls -l .git/refs/remotes/origin)
I get:
BEFORE:
-rw-r--r-- 1 peff peff 32 2008-11-04 21:43 HEAD
Everything up-to-date
AFTER:
-rw-r--r-- 1 peff peff 32 2008-11-04 21:43 HEAD
-rw-r--r-- 1 peff peff 41 2008-11-04 21:43 master
Oops. With the patch snippet I posted in my previous message, the
'master' ref is not created by the uptodate push.
> > Though I am not happy that we have to look up the tracking ref for every
> > uptodate ref. I think it shouldn't be a big performance problem with
> > packed refs, though, since they are cached (i.e., we pay only to compare
> > the hashes, not touch the filesystem for each ref).
>
> I don't think we can avoid that, though.
No, you can't avoid it (without totally giving up on your patch's goal,
which I think is a good one). So I think it is worth it, and I was just
being paranoid about hurting performance. Even with packed refs, I think
we do still end up stat()ing for each ref, but we will have to live with
it. I was thinking we might be able to do something clever with values
we had already read for the push, but it is impossible: we have read the
refs we are going to _push_, but we have not looked at the remote
tracking branches, which are what contain the interesting information.
-Peff
^ permalink raw reply related
* Re: git log -S doesn't find some commits
From: Junio C Hamano @ 2008-11-05 1:30 UTC (permalink / raw)
To: Bernt Hansen; +Cc: Johannes Schindelin, git
In-Reply-To: <877i7jrp67.fsf@gollum.intra.norang.ca>
Bernt Hansen <bernt@norang.ca> writes:
> Junio C Hamano <gitster@pobox.com> writes:
> ...
>> There seems to be a misconception on what -S<foo> does. It does *NOT*
>> grep for string <foo> in the patch text. It counts number of <foo> in
>> preimage and postimage and decides that the commit is worth showing iff
>> they differ.
>>
>> If you look at, for example (B):
>>
>> http://repo.or.cz/w/org-mode.git?a=commitdiff;h=837c81ce51
>>
>> You can see that in org-publish.el, org-publish-validate-link appears once
>> as removed and once as added, so the total number of the appearance of the
>> symbol in preimage and postimage are the same.
>
> Now I get it :)
>
> Thanks both of you!
By the way, I would not be opposed to a new feature, perhaps triggered
with -G<foo>, that acts as if it is grepping inside the patch text.
The reason behind -S<foo>'s behaviour is because it was designed as a part
ofa "incremetal digging" tool before the current "git-blame" that allows
to track even line-movements.
That is, you could write a tool to help the following interactively:
(1) get interested in a block of text in a recent version;
(2) feed that to 'git log' like this:
git log -1 -p -S"$potentially_multi_line_text" $rev
this will find an old rev R whose parent R^ did not have the lines
in the exact form you fed with -S.
(3) inspect the output, and decide what to do next:
(3-a) you may want to adjust the text you look for, taking into
account how the neighbouring lines used to look like in R^, and run
another "git log -S" starting at R^; and/or
(3-b) you may want to run "git grep" for the text in the entire
tree in R^, to see if this was a code refactoring that consolidates
multiple copies of the same thing into a single place.
and go back to step (2).
cf. http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217
^ permalink raw reply
* [EGIT PATCH] Respect background when drawing history in SWT.
From: Robin Rosenberg @ 2008-11-05 0:40 UTC (permalink / raw)
To: spearce; +Cc: git, Robin Rosenberg
Use transparent text background for drawing text to make the history
look nice when there is a background pattern or effects like alternating
background colors for each row.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
.../egit/ui/internal/history/CommitGraphTable.java | 2 +-
.../egit/ui/internal/history/SWTPlotRenderer.java | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/CommitGraphTable.java b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/CommitGraphTable.java
index a28e3c4..2bccf99 100644
--- a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/CommitGraphTable.java
+++ b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/CommitGraphTable.java
@@ -224,7 +224,7 @@ void doPaint(final Event event) {
final Point textsz = event.gc.textExtent(txt);
final int texty = (event.height - textsz.y) / 2;
- event.gc.drawString(txt, event.x, event.y + texty);
+ event.gc.drawString(txt, event.x, event.y + texty, true);
}
/**
diff --git a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/SWTPlotRenderer.java b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/SWTPlotRenderer.java
index 23ec255..c4ee282 100644
--- a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/SWTPlotRenderer.java
+++ b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/SWTPlotRenderer.java
@@ -89,7 +89,7 @@ protected void drawText(final String msg, final int x, final int y) {
final int texty = (y * 2 - textsz.y) / 2;
g.setForeground(cellFG);
g.setBackground(cellBG);
- g.drawString(msg, cellX + x, cellY + texty);
+ g.drawString(msg, cellX + x, cellY + texty, true);
}
protected Color laneColor(final SWTLane myLane) {
--
1.6.0.3.578.g6a50
^ permalink raw reply related
* Re: Git SVN Rebranching Issue
From: Avery Pennarun @ 2008-11-05 0:40 UTC (permalink / raw)
To: Eric Wong; +Cc: Dmitry Potapov, Matt Kern, git
In-Reply-To: <20081105003318.GA5666@hand.yhbt.net>
On Tue, Nov 4, 2008 at 7:33 PM, Eric Wong <normalperson@yhbt.net> wrote:
> Dmitry Potapov <dpotapov@gmail.com> wrote:
>> On Tue, Nov 04, 2008 at 12:41:11AM -0800, Eric Wong wrote:
>> >
>> > Short answer: you can use grafts to remove parents.
>>
>> Using grafts requires some cautious, especially when it is used to make
>> some commits unreachable, because git gc can remove unreachable commits.
>> Also, a repository with grafts cannot be cloned. So using grafts looks
>> like more as workaround rather a real solution.
>
> I don't think extra history is harmful at all, so the grafts could even
> be temporary. AFAIK, the extra history is only an aesthetic issue in
> visualizers (and I actually like to see it myself).
But it's *lying* history in this case; it doesn't reflect what really
happened in svn *or* in real life. I'd say lying history is most
often harmful. "git blame" and "git log" will lie in this case, for
example.
>> Would it not be better to save the old branch using "@SVN-NUMBER" as
>> suffix? Thus, those do not need the old branch can easily delete it.
>
> That would require renaming _existing_ branches to their "@SVN-NUMBER"
> name; which would break mechanisms for tracking branches based on
> refname.
Well, you wouldn't have to rename the existing branch. You would
simply create the new @SVN-NUMBER branch when it became clear that
that commit is no longer reachable from the undecorated branch ref.
Isn't that why the @SVN-NUMBER branches are needed in the first place?
As for tracking branches based on refname, it seems like the current
behaviour of pretending to merge histories together wouldn't work too
well anyway. For someone pulling from the messed-up branch, they
really *will* need to rewind and re-pull, since that's exactly what
happened in svn. I don't think git has any chance of doing this
automatically just because of a new commit with two parents.
Disclaimer: I haven't run into any of this myself since I don't
recycle branch names in svn :)
Have fun,
Avery
^ 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