* Re: [PATCH] Provide configurable UI font for gitk
From: Junio C Hamano @ 2006-04-02 10:57 UTC (permalink / raw)
To: Keith Packard; +Cc: git, Paul Mackerras
In-Reply-To: <1143969814.2303.71.camel@neko.keithp.com>
Keith Packard <keithp@keithp.com> writes:
> This makes the font used in the UI elements of gitk configurable in the
> same way the other fonts are. The default fonts used in the Xft build of
> tk8.5 are particularily horrific, making this change more important
> there.
>
> Signed-off-by: Keith Packard <keithp@neko.keithp.com>
Thanks for the patch. I haven't run it, but a quick eyeballing
suggests what you did is sane. However,..
> proc makewindow {rargs} {
> - global canv canv2 canv3 linespc charspc ctext cflist textfont
> + global canv canv2 canv3 linespc charspc ctext cflist textfont
> mainfont uifont
Your MUA seems to be line-wrapping the patch here and there...
> @@ -345,16 +345,20 @@ proc makewindow {rargs} {
>
> menu .bar
> .bar add cascade -label "File" -menu .bar.file
> + .bar configure -font $uifont
> menu .bar.file
> .bar.file add command -label "Update" -command [list updatecommits
> $rargs]
> .bar.file add command -label "Reread references" -command
> rereadrefs
>...
so the patch does not apply X-<.
Also, I prefer changes to gitk to be fed via Paul Mackerras
tree. If you send changes to gitk to me, I will forward patches
with my Acked-by: to him and wait for him to bounce the change
back to me through his tree, so it is not a big deal for me, and
the changes will _not_ be lost anyway, but I'd still appreciate
gitk patches to be sent to Paul first if possible.
^ permalink raw reply
* Solaris cloning woes partly diagnosed
From: Junio C Hamano @ 2006-04-02 10:41 UTC (permalink / raw)
To: git
This is just an interim report, but people might have heard that
OpenSolaris team are in the process of choosing a free DSCM and
we are one of the candidates. They initially wanted to try
1.2.4 but had trouble using it for local cloning, and the
evaluation is being done with 1.2.2.
I was on #git tonight with Oejet, and managed to reproduce this
problem. The local clone problem seems to disappear if we
disable the progress bar in pack-objects.
We do two funky things when we have progress bar. We play games
with timer signal (setitimer(ITIMER_REAL) and signal(SIGALRM)),
and we spit out messages to stderr.
It's too late tonight for me to continue digging this, but if
somebody with access to a Solaris box is so inclined, I'd really
appreciate help on this one.
^ permalink raw reply
* Re: parsecvs tool now creates git repositories
From: Jan-Benedict Glaw @ 2006-04-02 9:39 UTC (permalink / raw)
To: Keith Packard; +Cc: Git Mailing List
In-Reply-To: <1143956188.2303.39.camel@neko.keithp.com>
[-- Attachment #1: Type: text/plain, Size: 876 bytes --]
On Sat, 2006-04-01 21:36:28 -0800, Keith Packard <keithp@keithp.com> wrote:
> The UI is a total disaster, sufficient for testing. You must create an
> Authors file in the current directory which looks like the git-cvsimport
> authors file. You must also have a edit-change-log program in your path
> which edits the commit message in place. /bin/true will work if you
> don't need to edit the messages.
Well, at least this sounds quite promising. I'll give it a run once
I've arrived back home on the Binutils repository.
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] Provide configurable UI font for gitk
From: Keith Packard @ 2006-04-02 9:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 4839 bytes --]
This makes the font used in the UI elements of gitk configurable in the
same way the other fonts are. The default fonts used in the Xft build of
tk8.5 are particularily horrific, making this change more important
there.
Signed-off-by: Keith Packard <keithp@neko.keithp.com>
---
gitk | 23 +++++++++++++++++------
1 files changed, 17 insertions(+), 6 deletions(-)
0ec97bb373389b5a55b0579168679b59bede1868
diff --git a/gitk b/gitk
index 03cd475..6319709 100755
--- a/gitk
+++ b/gitk
@@ -337,7 +337,7 @@ proc error_popup msg {
}
proc makewindow {rargs} {
- global canv canv2 canv3 linespc charspc ctext cflist textfont
+ global canv canv2 canv3 linespc charspc ctext cflist textfont
mainfont uifont
global findtype findtypemenu findloc findstring fstring geometry
global entries sha1entry sha1string sha1but
global maincursor textcursor curtextcursor
@@ -345,16 +345,20 @@ proc makewindow {rargs} {
menu .bar
.bar add cascade -label "File" -menu .bar.file
+ .bar configure -font $uifont
menu .bar.file
.bar.file add command -label "Update" -command [list updatecommits
$rargs]
.bar.file add command -label "Reread references" -command
rereadrefs
.bar.file add command -label "Quit" -command doquit
+ .bar.file configure -font $uifont
menu .bar.edit
.bar add cascade -label "Edit" -menu .bar.edit
.bar.edit add command -label "Preferences" -command doprefs
+ .bar.edit configure -font $uifont
menu .bar.help
.bar add cascade -label "Help" -menu .bar.help
.bar.help add command -label "About gitk" -command about
+ .bar.help configure -font $uifont
. configure -menu .bar
if {![info exists geometry(canv1)]} {
@@ -401,7 +405,7 @@ proc makewindow {rargs} {
set entries $sha1entry
set sha1but .ctop.top.bar.sha1label
button $sha1but -text "SHA1 ID: " -state disabled -relief flat \
- -command gotocommit -width 8
+ -command gotocommit -width 8 -font $uifont
$sha1but conf -disabledforeground [$sha1but cget -foreground]
pack .ctop.top.bar.sha1label -side left
entry $sha1entry -width 40 -font $textfont -textvariable sha1string
@@ -431,19 +435,24 @@ proc makewindow {rargs} {
-state disabled -width 26
pack .ctop.top.bar.rightbut -side left -fill y
- button .ctop.top.bar.findbut -text "Find" -command dofind
+ button .ctop.top.bar.findbut -text "Find" -command dofind -font
$uifont
pack .ctop.top.bar.findbut -side left
set findstring {}
set fstring .ctop.top.bar.findstring
lappend entries $fstring
- entry $fstring -width 30 -font $textfont -textvariable findstring
+ entry $fstring -width 30 -font $textfont -textvariable findstring
-font $textfont
pack $fstring -side left -expand 1 -fill x
set findtype Exact
set findtypemenu [tk_optionMenu .ctop.top.bar.findtype \
findtype Exact IgnCase Regexp]
+ .ctop.top.bar.findtype configure -font $uifont
+ .ctop.top.bar.findtype.menu configure -font $uifont
set findloc "All fields"
tk_optionMenu .ctop.top.bar.findloc findloc "All fields" Headline \
Comments Author Committer Files Pickaxe
+ .ctop.top.bar.findloc configure -font $uifont
+ .ctop.top.bar.findloc.menu configure -font $uifont
+
pack .ctop.top.bar.findloc -side right
pack .ctop.top.bar.findtype -side right
# for making sure type==Exact whenever loc==Pickaxe
@@ -490,7 +499,7 @@ proc makewindow {rargs} {
frame .ctop.cdet.right
set cflist .ctop.cdet.right.cfiles
listbox $cflist -bg white -selectmode extended -width
$geometry(cflistw) \
- -yscrollcommand ".ctop.cdet.right.sb set"
+ -yscrollcommand ".ctop.cdet.right.sb set" -font $mainfont
scrollbar .ctop.cdet.right.sb -command "$cflist yview"
pack .ctop.cdet.right.sb -side right -fill y
pack $cflist -side left -fill both -expand 1
@@ -590,7 +599,7 @@ proc click {w} {
}
proc savestuff {w} {
- global canv canv2 canv3 ctext cflist mainfont textfont
+ global canv canv2 canv3 ctext cflist mainfont textfont uifont
global stuffsaved findmergefiles maxgraphpct
global maxwidth
@@ -600,6 +609,7 @@ proc savestuff {w} {
set f [open "~/.gitk-new" w]
puts $f [list set mainfont $mainfont]
puts $f [list set textfont $textfont]
+ puts $f [list set uifont $uifont]
puts $f [list set findmergefiles $findmergefiles]
puts $f [list set maxgraphpct $maxgraphpct]
puts $f [list set maxwidth $maxwidth]
@@ -3738,6 +3748,7 @@ if {$tclencoding == {}} {
set mainfont {Helvetica 9}
set textfont {Courier 9}
+set uifont {Helvetica 9 bold}
set findmergefiles 0
set maxgraphpct 50
set maxwidth 16
--
1.3.0.rc1.g9590
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply related
* [RFH] xdiff shows trivially redundant diff.
From: Junio C Hamano @ 2006-04-02 9:15 UTC (permalink / raw)
To: git; +Cc: Davide Libenzi, Linus Torvalds
$ git diff-tree -p 52e8a6^2 52d8a6 -- git-fetch.sh
shows a change that trivially is redundant, like this:
diff --git a/git-fetch.sh b/git-fetch.sh
index b4325d9..de4f011 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -320,7 +320,7 @@ fetch_main () {
( : subshell because we muck with IFS
IFS=" $LF"
(
- git-fetch-pack $exec $keep "$remo...
+ git-fetch-pack $exec $keep --thin...
) |
while read sha1 remote_name
do
@@ -367,21 +367,26 @@ fetch_main "$reflist"
# automated tag following
case "$no_tags$tags" in
-'')
- taglist=$(IFS=" " &&
- git-ls-remote $upload_pack --tags "$remote" |
...
- done)
+'')
+ case "$reflist" in
+ *:refs/*)
...
Notice the first '-' and '+' lines of second hunk are identical?
There is another interesting thing. This is running diff
between 52e8a6^2 and 52d8a6 blobs, but if I change them slightly
so that the first hunk is not different, then this anomaly
disappears.
^ permalink raw reply
* Re: Multi-headed branches (hydra? :)) for basic patch calculus
From: Jakub Narebski @ 2006-04-02 6:49 UTC (permalink / raw)
To: git
In-Reply-To: <1143950852.21233.23.camel@localhost.localdomain>
Sam Vilain wrote:
> From a discussion on #git, the idea was raised of "multi-headed
> branches"
[...]
> If somebody adds a commit (5) that changes "foo.c" again, the darcs
> history would change to:
>
> 1 -> 3 -> 5
> 2 -> 4
>
> To represent this in git you could just roll back the head merge commit,
> push commit 5 on that branch, then make a new head:
>
> 1 -> 3 -> 5 \
> >- head
> 2 -> 4 -----/
>
> However, if there was support for "hydra", or heads that are multiple
> commit IDs (and necessarily, no blobs in corresponding paths in their
> trees that are not identical), then you would not need to destroy and
> recreate this dummy merge head commit to model your patch history in
> this manner.
[...]
I'm not sure if "hydras", i.e. multi-commit 'heads' are what would make
GIT able to use some of Darcs patches calculus ideas. If I understand
correctly in GIT 'head' (and 'tag') not only identifies commit (commits
in hydra[1]) but also tree (in hydra it is result of trivial (?) merge).
Wouldn't it be better to somehow represent rather partial ordering between
commits in history, to have something from Darcs in GIT? Although I'm not
sure about efficiency, and if we should do detect commits dependency -- or
in other words partial ordering of commits/patches -- at commit or at
merge. And if we should remember (or cache) partial ordering/dependency
info...
[1] I've detected some confusion in this terminology. "Hydra" is
multi-headed moster, yet in your ptoposal it is one head that has multiple
bodies... and "octopus" is taken. I guess the terminology should be
switched (octopus <-> hydra).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* parsecvs tool now creates git repositories
From: Keith Packard @ 2006-04-02 5:36 UTC (permalink / raw)
To: Git Mailing List; +Cc: keithp
[-- Attachment #1: Type: text/plain, Size: 956 bytes --]
I've hacked in cheesy system(3) calls to invoke various git tools to
create a git repository from a parsed cvs repository. It's about the
same speed as git-cvsimport now.
The UI is a total disaster, sufficient for testing. You must create an
Authors file in the current directory which looks like the git-cvsimport
authors file. You must also have a edit-change-log program in your path
which edits the commit message in place. /bin/true will work if you
don't need to edit the messages.
I should clearly steal the existing git-cvsimport command line arguments
and use those.
This tool successfully, and usefully, imports the X.org xserver CVS
repository, along with correctly importing several other repositories
I've tried. It doesn't quite manage to compute correct branch points for
the postgresql CVS repository, so there is clearly work remaining to be
done.
CVS - your code's worst nightmare.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Multi-headed branches (hydra? :)) for basic patch calculus
From: Sam Vilain @ 2006-04-02 4:07 UTC (permalink / raw)
To: git
>From a discussion on #git, the idea was raised of "multi-headed
branches"
Say you've got a sequence of changes like this:
1. add foo.c
2. add bar.c
3. modify foo.c
4. modify bar.c
The darcs-like operation of this would be to have two sequences of
ordered patches that combine to a final result. ie:
1 -> 3
2 -> 4
Unless you jump through hoops, git will represent it as:
1 -> 2 -> 3 -> 4.
However, you *could* represent it as:
1 -> 3 \
>- head
2 -> 4 /
Where "head" is a merge commit that just combines the trees of 3 and 4.
If somebody adds a commit (5) that changes "foo.c" again, the darcs
history would change to:
1 -> 3 -> 5
2 -> 4
To represent this in git you could just roll back the head merge commit,
push commit 5 on that branch, then make a new head:
1 -> 3 -> 5 \
>- head
2 -> 4 -----/
However, if there was support for "hydra", or heads that are multiple
commit IDs (and necessarily, no blobs in corresponding paths in their
trees that are not identical), then you would not need to destroy and
recreate this dummy merge head commit to model your patch history in
this manner.
If the plumbing or a porcelain could be smart enough to automatically
create hydra when patches are not dependent, then many of the benefits
of patch calculus might come for free, without having to create these
complicated sounding entities manually.
Of course this doesn't give you the symbolic labelling of patches that
can allow darcs to detect already applied, but "mutated" patches, but
that might not matter in practice.
Sam.
^ permalink raw reply
* [PATCH] revision: --max-age alone does not need limit_list() anymore.
From: Junio C Hamano @ 2006-04-02 3:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604011628500.3684@g5.osdl.org>
This makes git log --since=7.days to be streamable.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
revision.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
bbbc8c3a8d455e1f5d15c3764eba70250b5479e9
diff --git a/revision.c b/revision.c
index cdd29c5..728b6d1 100644
--- a/revision.c
+++ b/revision.c
@@ -699,7 +699,7 @@ int setup_revisions(int argc, const char
add_one_commit(commit, revs);
}
- if ((revs->max_age != -1) || revs->topo_order || revs->unpacked)
+ if (revs->topo_order || revs->unpacked)
revs->limited = 1;
if (revs->prune_data) {
--
1.3.0.rc1.gf385
^ permalink raw reply related
* [PATCH] revision: simplify argument parsing.
From: Junio C Hamano @ 2006-04-02 3:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604011628500.3684@g5.osdl.org>
This just moves code around to consolidate the part that sets
revs->limited to one place based on various flags.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* Just the preparation for the next step...
revision.c | 20 +++++++-------------
1 files changed, 7 insertions(+), 13 deletions(-)
53069686601d156dea3787a100ffc4e35c78040f
diff --git a/revision.c b/revision.c
index 07cc86f..cdd29c5 100644
--- a/revision.c
+++ b/revision.c
@@ -552,32 +552,26 @@ int setup_revisions(int argc, const char
}
if (!strncmp(arg, "--max-age=", 10)) {
revs->max_age = atoi(arg + 10);
- revs->limited = 1;
continue;
}
- if (!strncmp(arg, "--min-age=", 10)) {
- revs->min_age = atoi(arg + 10);
- revs->limited = 1;
- continue;
- }
if (!strncmp(arg, "--since=", 8)) {
revs->max_age = approxidate(arg + 8);
- revs->limited = 1;
continue;
}
if (!strncmp(arg, "--after=", 8)) {
revs->max_age = approxidate(arg + 8);
- revs->limited = 1;
continue;
}
+ if (!strncmp(arg, "--min-age=", 10)) {
+ revs->min_age = atoi(arg + 10);
+ continue;
+ }
if (!strncmp(arg, "--before=", 9)) {
revs->min_age = approxidate(arg + 9);
- revs->limited = 1;
continue;
}
if (!strncmp(arg, "--until=", 8)) {
revs->min_age = approxidate(arg + 8);
- revs->limited = 1;
continue;
}
if (!strcmp(arg, "--all")) {
@@ -596,13 +590,11 @@ int setup_revisions(int argc, const char
}
if (!strcmp(arg, "--topo-order")) {
revs->topo_order = 1;
- revs->limited = 1;
continue;
}
if (!strcmp(arg, "--date-order")) {
revs->lifo = 0;
revs->topo_order = 1;
- revs->limited = 1;
continue;
}
if (!strcmp(arg, "--parents")) {
@@ -644,7 +636,6 @@ int setup_revisions(int argc, const char
}
if (!strcmp(arg, "--unpacked")) {
revs->unpacked = 1;
- revs->limited = 1;
continue;
}
*unrecognized++ = arg;
@@ -707,6 +698,9 @@ int setup_revisions(int argc, const char
commit = get_commit_reference(revs, def, sha1, 0);
add_one_commit(commit, revs);
}
+
+ if ((revs->max_age != -1) || revs->topo_order || revs->unpacked)
+ revs->limited = 1;
if (revs->prune_data) {
diff_tree_setup_paths(revs->prune_data);
--
1.3.0.rc1.gf385
^ permalink raw reply related
* Re: [PATCH/RFC 2/2] Make path-limiting be incremental when possible.
From: Junio C Hamano @ 2006-04-02 3:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604011628500.3684@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> What ends up not working very well at all is the combination of
> "--topo-order" and the output filter in get_revision. It will return NULL
> when we see the first commit out of date-order, even if we have other
> commits coming.
>
> So we really should do the "past the date order" thing in get_revision()
> only if we have _not_ done it already in limit_list().
Right now --max-age causes "limited" so there should not be a
difference, if I am not mistaken. But I've been meaning to
change that, so the patch makes sense. Similarly,...
-- >8 --
[PATCH] revision: --topo-order and --unpacked
Now, using --unpacked without limit_list() does not make much
sense, but this is parallel to the earlier --max-age fix.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
revision.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
22c31bf183bff576c7807f9d67abfc11ee8e1fa4
diff --git a/revision.c b/revision.c
index 558ed01..07cc86f 100644
--- a/revision.c
+++ b/revision.c
@@ -787,7 +787,10 @@ struct commit *get_revision(struct rev_i
* that we'd otherwise have done in limit_list().
*/
if (!revs->limited) {
- if (revs->max_age != -1 && (commit->date < revs->max_age))
+ if ((revs->unpacked &&
+ has_sha1_pack(commit->object.sha1)) ||
+ (revs->max_age != -1 &&
+ (commit->date < revs->max_age)))
continue;
add_parents_to_list(revs, commit, &revs->commits);
}
--
1.3.0.rc1.gf385
^ permalink raw reply related
* [PATCH] contrib/git-svn: accept configuration via repo-config
From: Eric Wong @ 2006-04-02 2:25 UTC (permalink / raw)
To: junkio, git; +Cc: Eric Wong
repo-config keys are any of the long option names minus the '-'
characters
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
contrib/git-svn/git-svn.perl | 17 +++++++++++++++++
1 files changed, 17 insertions(+), 0 deletions(-)
2eb11880066977d65ed7e51b04c2bfa97d217752
diff --git a/contrib/git-svn/git-svn.perl b/contrib/git-svn/git-svn.perl
index 59dd504..edfb19c 100755
--- a/contrib/git-svn/git-svn.perl
+++ b/contrib/git-svn/git-svn.perl
@@ -67,6 +67,23 @@ for (my $i = 0; $i < @ARGV; $i++) {
my %opts = %{$cmd{$cmd}->[2]} if (defined $cmd);
+# convert GetOpt::Long specs for use by git-repo-config
+foreach my $o (keys %opts) {
+ my $v = $opts{$o};
+ my ($key) = ($o =~ /^([a-z\-]+)/);
+ $key =~ s/-//g;
+ my $arg = 'git-repo-config';
+ $arg .= ' --int' if ($o =~ /=i$/);
+ $arg .= ' --bool' if ($o !~ /=[sfi]$/);
+ $arg .= " svn.$key"; # $key only matches [a-z\-], always shell-safe
+ if (ref $v eq 'ARRAY') {
+ chomp(@$v = `$arg`);
+ } else {
+ chomp($$v = `$arg`);
+ $$v = 0 if $$v eq 'false';
+ }
+}
+
GetOptions(%opts, 'help|H|h' => \$_help,
'version|V' => \$_version,
'id|i=s' => \$GIT_SVN) or exit 1;
--
1.3.0.rc1.g709a5
^ permalink raw reply related
* [PATCH] contrib/git-svn: documentation updates
From: Eric Wong @ 2006-04-02 2:25 UTC (permalink / raw)
To: junkio, git; +Cc: Eric Wong
In-Reply-To: <11439447031422-git-send-email-normalperson@yhbt.net>
contrib/git-svn/git-svn.txt:
added git-repo-config key names for options
fixed quoting of "git-svn-HEAD" in the manpage
use preformatted text for examples
contrib/git-svn/Makefile:
add target to generate HTML:
http://git-svn.yhbt.net/git-svn.html
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
contrib/git-svn/Makefile | 3 +++
contrib/git-svn/git-svn.txt | 41 ++++++++++++++++++++++++++++-------------
2 files changed, 31 insertions(+), 13 deletions(-)
f8198e0b9da68024f7194067eb120bbf256a6111
diff --git a/contrib/git-svn/Makefile b/contrib/git-svn/Makefile
index a330c61..d7f1643 100644
--- a/contrib/git-svn/Makefile
+++ b/contrib/git-svn/Makefile
@@ -25,6 +25,9 @@ git-svn.1 : git-svn.xml
git-svn.xml : git-svn.txt
asciidoc -b docbook -d manpage \
-f ../../Documentation/asciidoc.conf $<
+git-svn.html : git-svn.txt
+ asciidoc -b xhtml11 -d manpage \
+ -f ../../Documentation/asciidoc.conf $<
test:
cd t && $(SHELL) ./t0000-contrib-git-svn.sh
diff --git a/contrib/git-svn/git-svn.txt b/contrib/git-svn/git-svn.txt
index 7a6e0c4..e18fcaf 100644
--- a/contrib/git-svn/git-svn.txt
+++ b/contrib/git-svn/git-svn.txt
@@ -101,6 +101,8 @@ OPTIONS
cannot version empty directories. Enabling this flag will make
the commit to SVN act like git.
+ repo-config key: svn.rmdir
+
-e::
--edit::
Only used with the 'commit' command.
@@ -108,6 +110,8 @@ OPTIONS
Edit the commit message before committing to SVN. This is off by
default for objects that are commits, and forced on when committing
tree objects.
+
+ repo-config key: svn.edit
-l<num>::
--find-copies-harder::
@@ -115,6 +119,9 @@ OPTIONS
They are both passed directly to git-diff-tree see
git-diff-tree(1) for more information.
+
+ repo-config key: svn.l
+ repo-config key: svn.findcopiesharder
ADVANCED OPTIONS
----------------
@@ -133,6 +140,8 @@ ADVANCED OPTIONS
This option may be specified multiple times, once for each
branch.
+ repo-config key: svn.branch
+
-i<GIT_SVN_ID>::
--id <GIT_SVN_ID>::
This sets GIT_SVN_ID (instead of using the environment). See
@@ -145,7 +154,7 @@ COMPATIBILITY OPTIONS
Only used with the 'rebuild' command.
Run this if you used an old version of git-svn that used
- 'git-svn-HEAD' instead of 'remotes/git-svn' as the branch
+ "git-svn-HEAD" instead of "remotes/git-svn" as the branch
for tracking the remote.
--no-ignore-externals::
@@ -161,26 +170,30 @@ COMPATIBILITY OPTIONS
Otherwise, do not enable this flag unless you know what you're
doing.
+
+ repo-config key: svn.noignoreexternals
Basic Examples
~~~~~~~~~~~~~~
Tracking and contributing to an Subversion managed-project:
-# Initialize a tree (like git init-db)::
+------------------------------------------------------------------------
+# Initialize a tree (like git init-db):
git-svn init http://svn.foo.org/project/trunk
-# Fetch remote revisions::
+# Fetch remote revisions:
git-svn fetch
-# Create your own branch to hack on::
+# Create your own branch to hack on:
git checkout -b my-branch remotes/git-svn
-# Commit only the git commits you want to SVN::
+# Commit only the git commits you want to SVN:
git-svn commit <tree-ish> [<tree-ish_2> ...]
-# Commit all the git commits from my-branch that don't exist in SVN::
+# Commit all the git commits from my-branch that don't exist in SVN:
git-svn commit remotes/git-svn..my-branch
-# Something is committed to SVN, pull the latest into your branch::
+# Something is committed to SVN, pull the latest into your branch:
git-svn fetch && git pull . remotes/git-svn
-# Append svn:ignore settings to the default git exclude file::
+# Append svn:ignore settings to the default git exclude file:
git-svn show-ignore >> .git/info/exclude
+------------------------------------------------------------------------
DESIGN PHILOSOPHY
-----------------
@@ -219,7 +232,7 @@ git commits with the following syntax:
This allows you to tie unfetched SVN revision 375 to your current HEAD::
- git-svn fetch 375=$(git-rev-parse HEAD)
+ `git-svn fetch 375=$(git-rev-parse HEAD)`
Advanced Example: Tracking a Reorganized Repository
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -232,22 +245,24 @@ This is how Yann Dirson tracked the trun
the /trunk directory of his repository was moved to /ufoai/trunk and
he needed to continue tracking /ufoai/trunk where /trunk left off.
- # This log message shows when the repository was reorganized::
+------------------------------------------------------------------------
+ # This log message shows when the repository was reorganized:
r166 | ydirson | 2006-03-02 01:36:55 +0100 (Thu, 02 Mar 2006) | 1 line
Changed paths:
D /trunk
A /ufoai/trunk (from /trunk:165)
- # First we start tracking the old revisions::
+ # First we start tracking the old revisions:
GIT_SVN_ID=git-oldsvn git-svn init \
- https://svn.sourceforge.net/svnroot/ufoai/trunk
+ https://svn.sourceforge.net/svnroot/ufoai/trunk
GIT_SVN_ID=git-oldsvn git-svn fetch -r1:165
- # And now, we continue tracking the new revisions::
+ # And now, we continue tracking the new revisions:
GIT_SVN_ID=git-newsvn git-svn init \
https://svn.sourceforge.net/svnroot/ufoai/ufoai/trunk
GIT_SVN_ID=git-newsvn git-svn fetch \
166=`git-rev-parse refs/remotes/git-oldsvn`
+------------------------------------------------------------------------
BUGS
----
--
1.3.0.rc1.g709a5
^ permalink raw reply related
* Re: [PATCH/RFC 2/2] Make path-limiting be incremental when possible.
From: Linus Torvalds @ 2006-04-02 0:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr74jw0zj.fsf@assigned-by-dhcp.cox.net>
On Thu, 30 Mar 2006, Junio C Hamano wrote:
>
> OK, so let's say I agree with you that --unpacked and --since
> are "stop early" rules. I fully agree with that from usability
> and implementation point of view, but I now wonder if the
> "output filter" in get_revision() and "stop early" in limit_list()
> would do the same thing.
They don't.
What ends up not working very well at all is the combination of
"--topo-order" and the output filter in get_revision. It will return NULL
when we see the first commit out of date-order, even if we have other
commits coming.
So we really should do the "past the date order" thing in get_revision()
only if we have _not_ done it already in limit_list().
Something like this.
The easiest way to test this is with just
gitk --since=3.days.ago
on the kernel tree. Without this patch, it tends to be pretty obviously
broken.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Linus
---
diff --git a/revision.c b/revision.c
index a8a54b6..558ed01 100644
--- a/revision.c
+++ b/revision.c
@@ -783,10 +783,14 @@ struct commit *get_revision(struct rev_i
/*
* If we haven't done the list limiting, we need to look at
- * the parents here
+ * the parents here. We also need to do the date-based limiting
+ * that we'd otherwise have done in limit_list().
*/
- if (!revs->limited)
+ if (!revs->limited) {
+ if (revs->max_age != -1 && (commit->date < revs->max_age))
+ continue;
add_parents_to_list(revs, commit, &revs->commits);
+ }
if (commit->object.flags & SHOWN)
continue;
if (!(commit->object.flags & BOUNDARY) &&
@@ -794,8 +798,6 @@ struct commit *get_revision(struct rev_i
continue;
if (revs->min_age != -1 && (commit->date > revs->min_age))
continue;
- if (revs->max_age != -1 && (commit->date < revs->max_age))
- return NULL;
if (revs->no_merges &&
commit->parents && commit->parents->next)
continue;
^ permalink raw reply related
* [Patch] Key help for gitk
From: Paul Schulz @ 2006-04-02 0:21 UTC (permalink / raw)
To: paulus; +Cc: git
In-Reply-To: <cc9bf44d0604011616w18b9a7c3nc55a393f30a2b55a@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 283 bytes --]
Greetings,
gitk has a few more key options than I was aware (font
increase/decrease for example). The following patch adds some details
to the 'About' dialog.
(These need to be reviewed for sanity, as I can't work out how the
search keys are ment to work.)
Paul Schulz
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: patch-gitk-20060402.diff --]
[-- Type: text/x-patch; name=patch-gitk-20060402.diff; charset=ANSI_X3.4-1968, Size: 1121 bytes --]
diff --git a/gitk b/gitk
index fa1e83c..85d70d9 100755
--- a/gitk
+++ b/gitk
@@ -722,7 +722,41 @@ Gitk - a commit viewer for git
Copyright © 2005-2006 Paul Mackerras
-Use and redistribute under the terms of the GNU General Public License} \
+Use and redistribute under the terms of the GNU General Public License
+
+Keys
+----
+<Down> - Move down a line
+<Up> - Move up a line
+<Right> -
+<Left> -
+<Delete> -
+<BackSpace> -
+<Space> - Scroll Diff
+p - Previous commit
+n - Next commit
+z - Go back (?)
+x - Go forward (?)
+i - Previuos line
+k - Next line
+j - Go back
+l - Go forward
+b - ?
+d - ?
+u - ?
+/ - Next find result (?)
+<Return> - Find result
+? - Previous find result
+f - Next file
+<Ctl-q> - Quit
+<Ctl-f> - Find
+<Ctl-g> - Find next
+<Ctl-r> - Find previous
+<Ctl-equal> - Incrument font size
+<Ctl-KP_Add> - Incrument font size
+<Ctl-minus> - Decrement font size
+<Ctl-KP_Subtract> - Decrement font size
+} \
-justify center -aspect 400
pack $w.m -side top -fill x -padx 20 -pady 20
button $w.ok -text Close -command "destroy $w"
^ permalink raw reply related
* Re: Moving a file back to an earlier revision.
From: Petr Baudis @ 2006-04-01 23:01 UTC (permalink / raw)
To: David Ho; +Cc: git
In-Reply-To: <4dd15d180603311332p60fa1867nc303bd92d515b4e0@mail.gmail.com>
Dear diary, on Fri, Mar 31, 2006 at 11:32:16PM CEST, I got a letter
where David Ho <davidkwho@gmail.com> said that...
> Sorry I might already have found it.
>
> File revisions
>
> +----+----+
> 1 2 3
>
> git diff commit(3)..commit(1) filename | git-apply
Note that it might be more convenient to just say "restore the file to
the contents as of commit X" - in pure Git this would involve dances
with git-ls-tree and git-cat-file, I'm not sure if the core Git
porcelain has an interface for doing this easily.
In Cogito, you can just do:
cg-restore -f -r commitid filename
--
Petr "Pasky on a dialup" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Re: Default remote branch for local branch
From: Jakub Narebski @ 2006-04-01 19:57 UTC (permalink / raw)
To: git
In-Reply-To: <e0l3l0$v4e$1@sea.gmane.org>
> You might want to read "Efficient cloning" thread where
> --use-separate-remote and --reference options were introduced:
> http://marc.theaimsgroup.com/?l=git&m=114280442802681&w=2
> http://www.gelato.unsw.edu.au/archives/git/0603/18113.html
> http://thread.gmane.org/gmane.comp.version-control.git/17724
> and which had discussion on similar subjects (somewhere).
See also
Message-ID: <200603011814.43573.Josef.Weidendorfer@gmx.de>
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: Moving to BK
From: Jakub Narebski @ 2006-04-01 7:13 UTC (permalink / raw)
To: git; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.64.0603312030060.27203@g5.osdl.org>
Linus Torvalds wrote:
> On Fri, 31 Mar 2006, David S. Miller wrote:
>>
>> April 1st is upon us again.
>
> I really like the new slashdot look. "OMG!!! Ponies!!!"
>
> I hope they keep it after Apr 1st.
Apr 1st begins at Mar 31st (some of Fool's Day articles on slashdot are from
Mar 31st localtime), and for some it would continue at lest to Apr 2nd ;-)
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: Moving to BK
From: Randy.Dunlap @ 2006-04-01 6:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: davem, pasky, junio, linux-kernel, git
In-Reply-To: <Pine.LNX.4.64.0603312030060.27203@g5.osdl.org>
On Fri, 31 Mar 2006 20:30:40 -0800 (PST) Linus Torvalds wrote:
>
>
> On Fri, 31 Mar 2006, David S. Miller wrote:
> >
> > April 1st is upon us again.
>
> I really like the new slashdot look. "OMG!!! Ponies!!!"
Goes with the sandals and pony tails.
> I hope they keep it after Apr 1st.
---
~Randy
^ permalink raw reply
* Re: Default remote branch for local branch
From: Jakub Narebski @ 2006-04-01 5:38 UTC (permalink / raw)
To: git
In-Reply-To: <1143856098.3555.48.camel@dv>
Pavel Roskin wrote:
> I'm sorry, reading this mailing list is beyond my capabilities, so
> certain overlaps with other postings may be expected, unless I'm
> suggesting something totally off-base :-)
You might want to read "Efficient cloning" thread where
--use-separate-remote and --reference options were introduced:
http://marc.theaimsgroup.com/?l=git&m=114280442802681&w=2
http://www.gelato.unsw.edu.au/archives/git/0603/18113.html
http://thread.gmane.org/gmane.comp.version-control.git/17724
and which had discussion on similar subjects (somewhere).
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: Moving to BK
From: Linus Torvalds @ 2006-04-01 4:30 UTC (permalink / raw)
To: David S. Miller; +Cc: pasky, junio, linux-kernel, git
In-Reply-To: <20060331.191416.108058500.davem@davemloft.net>
On Fri, 31 Mar 2006, David S. Miller wrote:
>
> April 1st is upon us again.
I really like the new slashdot look. "OMG!!! Ponies!!!"
I hope they keep it after Apr 1st.
Linus
^ permalink raw reply
* Re: Default remote branch for local branch
From: Pavel Roskin @ 2006-04-01 4:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vodzmngfp.fsf@assigned-by-dhcp.cox.net>
Hello, Junio!
On Fri, 2006-03-31 at 19:05 -0800, Junio C Hamano wrote:
> - Multiple subsystem maintainer trees tracked in the same local
> repository. Most generally, two local branches per each
> remote head can be used (one tracking branch to fetch into,
> another to build your changes based on it). Alternatively,
> you can use one local branch per each remote head without
> using any tracking branch.
>
> Your proposal to give default branch to pull from per the local
> branch would help only the last case.
Exactly. I tried to track the main Linus repository and Jeff Garzik's
netdev in one place. Then I discovered that my repository if full of
unintended merges made by "stg pull".
> The first one you do not
> switch between local branches at all and pull from many
> different places; the second is to merge from different topic
> branches from time to time and does not benefit from fixed
> configuration; the third does not even need configuration.
>
> Maybe you would want something like this.
>
> In $GIT_DIR/config:
>
> [pull]
> origin = linus for master
> origin = irq-pio of libata for ata-irq-pio
> origin = pata-drivers of libata for ata-pata
First of all, using "origin" on every line carries to little
information.
Secondly, I think the relationship should be between a local development
branch and a local tracking branch. After all, all remote data is
placed on a local tracking branch first. It's better not to jump over
layers of abstraction. Suppose I want to update "masterB". I tell git
to sync "originB" first. git already has rules what to do if it should
sync "originB". Let's not supersede those rules.
I would write the config like this:
[branch-upstream]
master = linus
ata-irq-pio = irq-pio
ata-pata = pata-drivers
> While we are on the topic, it _might_ be worthwhile to think
> about revamping the syntax of $GIT_DIR/remotes file, maybe even
> breaking backward compatibility. The Pull: lines can be
> independently specified which gives flexibility, but I suspect
> local tracking branches from the same remote tend to live in the
> same place; IOW, you would probably not do something like:
>
> URL: git://git.kernel.org/.../jgarzik/libata-dev.git
> Pull: refs/heads/irq-pio:refs/remotes/libata/irq-pio
> Pull: refs/heads/pata-drivers:refs/heads/pata-drivers
>
> in practice.
Sorry, I don't understand this part.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: Moving to BK
From: Alexander Litvinov @ 2006-04-01 3:17 UTC (permalink / raw)
To: David S. Miller; +Cc: pasky, junio, linux-kernel, git
In-Reply-To: <20060331.191416.108058500.davem@davemloft.net>
> April 1st is upon us again.
Damn, I have forgot about this. Good joke !
^ permalink raw reply
* Re: Moving to BK
From: David S. Miller @ 2006-04-01 3:14 UTC (permalink / raw)
To: pasky, junio; +Cc: linux-kernel, git
In-Reply-To: <200604010311.k313BYeS026266@hera.kernel.org>
April 1st is upon us again.
^ permalink raw reply
* Moving to BK
From: Petr Baudis, Junio C Hamano @ 2006-04-01 0:00 UTC (permalink / raw)
To: linux-kernel; +Cc: git
We are pleased to announce that both of us will be working for
BitMover Inc., starting this month.
Petr, the author of the popular Cogito front-end for git, will
be modifying Cogito so that it natively works on BK
repositories. The superior Cogito user interface will
extensively increase added business value of BK by enabling a
variety of innovative workflows for smooth and economical
developer cooperation.
Junio, the current maintainer of git "stupid content tracker",
will first be working on a gateway to import development
histories stored in git into BK. This move adds value to BK by
freeing the data so far locked in git repositories and making
them available to the BK users. He may later work on
reimplementing some parts of the git for BK, but it is expected
that there aren't that many. For example, the "rename
detection" part is not necessary -- BK natively supports rename
tracking, which is a far superiour approach.
There currently is no plan for either of us to be working on the
conversion from BK to git. There is no technical reason to do
so, and it does not make business sense for BitMover Inc.
either.
- 30 -
^ 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