* [PATCH] gitk - Update fontsize in patch / tree list
From: Mark Levedahl @ 2007-06-26 2:43 UTC (permalink / raw)
To: gitster, paulus; +Cc: git, Mark Levedahl
In-Reply-To: <1182825801300-git-send-email-mdl123@verizon.net>
When adjusting fontsize (using ctrl+/-), all panes except the lower right
were updated. This fixes that.
Signed-off-by: Mark Levedahl <mdl123@verizon.net>
---
gitk | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/gitk b/gitk
index cd9456e..62eefd9 100755
--- a/gitk
+++ b/gitk
@@ -4695,13 +4695,14 @@ proc redisplay {} {
}
proc incrfont {inc} {
- global mainfont textfont ctext canv phase
+ global mainfont textfont ctext canv phase cflist
global stopped entries
unmarkmatches
set mainfont [lreplace $mainfont 1 1 [expr {[lindex $mainfont 1] + $inc}]]
set textfont [lreplace $textfont 1 1 [expr {[lindex $textfont 1] + $inc}]]
setcoords
$ctext conf -font $textfont
+ $cflist conf -font $textfont
$ctext tag conf filesep -font [concat $textfont bold]
foreach e $entries {
$e conf -font $mainfont
--
1.5.2.2.282.g9826
^ permalink raw reply related
* [PATCH] gitk - Allow specifying tabstop as other than default 8 characters.
From: Mark Levedahl @ 2007-06-26 2:43 UTC (permalink / raw)
To: gitster, paulus; +Cc: git, Mark Levedahl
In-Reply-To: <11828258013248-git-send-email-mdl123@verizon.net>
Not all projects use the convention that one tabstop = 8 characters, and
a common convention is to use one tabstop = on level of indent. For such
projects, using 8 characters per tabstop often shows too much whitespace
per indent. This allows the user to configure the number of characters
to use per tabstop.
Signed-off-by: Mark Levedahl <mdl123@verizon.net>
---
gitk | 17 +++++++++++++----
1 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/gitk b/gitk
index 62eefd9..06df3bb 100755
--- a/gitk
+++ b/gitk
@@ -395,7 +395,7 @@ proc confirm_popup msg {
proc makewindow {} {
global canv canv2 canv3 linespc charspc ctext cflist
- global textfont mainfont uifont
+ global textfont mainfont uifont tabstop
global findtype findtypemenu findloc findstring fstring geometry
global entries sha1entry sha1string sha1but
global maincursor textcursor curtextcursor
@@ -615,6 +615,7 @@ proc makewindow {} {
pack .bleft.mid.diff .bleft.mid.old .bleft.mid.new -side left
set ctext .bleft.ctext
text $ctext -background $bgcolor -foreground $fgcolor \
+ -tabs "[expr {$tabstop * $charspc}]" \
-state disabled -font $textfont \
-yscrollcommand scrolltext -wrap none
scrollbar .bleft.sb -command "$ctext yview"
@@ -824,7 +825,7 @@ proc click {w} {
}
proc savestuff {w} {
- global canv canv2 canv3 ctext cflist mainfont textfont uifont
+ global canv canv2 canv3 ctext cflist mainfont textfont uifont tabstop
global stuffsaved findmergefiles maxgraphpct
global maxwidth showneartags
global viewname viewfiles viewargs viewperm nextviewnum
@@ -838,6 +839,7 @@ proc savestuff {w} {
puts $f [list set mainfont $mainfont]
puts $f [list set textfont $textfont]
puts $f [list set uifont $uifont]
+ puts $f [list set tabstop $tabstop]
puts $f [list set findmergefiles $findmergefiles]
puts $f [list set maxgraphpct $maxgraphpct]
puts $f [list set maxwidth $maxwidth]
@@ -4696,12 +4698,13 @@ proc redisplay {} {
proc incrfont {inc} {
global mainfont textfont ctext canv phase cflist
+ global charspc tabstop
global stopped entries
unmarkmatches
set mainfont [lreplace $mainfont 1 1 [expr {[lindex $mainfont 1] + $inc}]]
set textfont [lreplace $textfont 1 1 [expr {[lindex $textfont 1] + $inc}]]
setcoords
- $ctext conf -font $textfont
+ $ctext conf -font $textfont -tabs "[expr {$tabstop * $charspc}]"
$cflist conf -font $textfont
$ctext tag conf filesep -font [concat $textfont bold]
foreach e $entries {
@@ -5852,7 +5855,7 @@ proc doprefs {} {
global maxwidth maxgraphpct diffopts
global oldprefs prefstop showneartags
global bgcolor fgcolor ctext diffcolors selectbgcolor
- global uifont
+ global uifont tabstop
set top .gitkprefs
set prefstop $top
@@ -5890,6 +5893,9 @@ proc doprefs {} {
checkbutton $top.ntag.b -variable showneartags
pack $top.ntag.b $top.ntag.l -side left
grid x $top.ntag -sticky w
+ label $top.tabstopl -text "tabstop" -font optionfont
+ spinbox $top.tabstop -from 1 -to 20 -width 4 -textvariable tabstop
+ grid x $top.tabstopl $top.tabstop -sticky w
label $top.cdisp -text "Colors: press to choose"
$top.cdisp configure -font $uifont
@@ -5988,9 +5994,11 @@ proc prefscan {} {
proc prefsok {} {
global maxwidth maxgraphpct
global oldprefs prefstop showneartags
+ global charspc ctext tabstop
catch {destroy $prefstop}
unset prefstop
+ $ctext configure -tabs "[expr {$tabstop * $charspc}]"
if {$maxwidth != $oldprefs(maxwidth)
|| $maxgraphpct != $oldprefs(maxgraphpct)} {
redisplay
@@ -6296,6 +6304,7 @@ if {$tclencoding == {}} {
set mainfont {Helvetica 9}
set textfont {Courier 9}
set uifont {Helvetica 9 bold}
+set tabstop 8
set findmergefiles 0
set maxgraphpct 50
set maxwidth 16
--
1.5.2.2.282.g9826
^ permalink raw reply related
* [PATCH] git-merge-ff: fast-forward only merge
From: Sam Vilain @ 2007-06-26 4:01 UTC (permalink / raw)
To: git; +Cc: Sam Vilain
This is primarily so that there is an easy switch to 'git-pull' to
be sure to fast forward only.
---
Documentation/merge-strategies.txt | 5 +++++
Makefile | 2 +-
git-merge-ff.sh | 8 ++++++++
3 files changed, 14 insertions(+), 1 deletions(-)
create mode 100644 git-merge-ff.sh
diff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt
index 7df0266..00739bc 100644
--- a/Documentation/merge-strategies.txt
+++ b/Documentation/merge-strategies.txt
@@ -33,3 +33,8 @@ ours::
merge is always the current branch head. It is meant to
be used to supersede old development history of side
branches.
+
+ff::
+ This is a degenerate merge strategy that always fails, which
+ means that the only time the target branch will change is if
+ there was no merge ("fast-forward" merge only).
diff --git a/Makefile b/Makefile
index 29243c6..6311eb5 100644
--- a/Makefile
+++ b/Makefile
@@ -208,7 +208,7 @@ SCRIPT_SH = \
git-tag.sh git-verify-tag.sh \
git-applymbox.sh git-applypatch.sh git-am.sh \
git-merge.sh git-merge-stupid.sh git-merge-octopus.sh \
- git-merge-resolve.sh git-merge-ours.sh \
+ git-merge-resolve.sh git-merge-ours.sh git-merge-ff.sh \
git-lost-found.sh git-quiltimport.sh
SCRIPT_PERL = \
diff --git a/git-merge-ff.sh b/git-merge-ff.sh
new file mode 100644
index 0000000..b0e0f85
--- /dev/null
+++ b/git-merge-ff.sh
@@ -0,0 +1,8 @@
+#!/bin/sh
+#
+# Copyright (c) 2007 Sam Vilain
+#
+# A degenerate merge strategy that only allows fast-forwarding.
+#
+
+exit 1;
--
1.5.2.1.1131.g3b90
^ permalink raw reply related
* Re: Mark Levedahl's gitk patches
From: Paul Mackerras @ 2007-06-26 4:02 UTC (permalink / raw)
To: Mark Levedahl; +Cc: Johannes Sixt, Junio C Hamano, git
In-Reply-To: <46807CEF.2010109@verizon.net>
Mark Levedahl writes:
> I found a bug in the highlight patch (the color picker updated the wrong
> panel in the chooser but did set the correct color), and updated the
> tab-stop patch to use a spin control to enforce entry of small integers
> only. As there is possible interest, I am sending the amended series.
Ah. I just pushed out a pile of patches to gitk.git including your
three. Could you do an incremental patch on top of that for me?
Thanks,
Paul.
^ permalink raw reply
* Re: git for subversion users
From: Sam Vilain @ 2007-06-26 4:33 UTC (permalink / raw)
To: Patrick Doyle; +Cc: git
In-Reply-To: <e2a1d0aa0706251248j1b8da150xbe19826bec15eed6@mail.gmail.com>
Patrick Doyle wrote:
> Hello all,
> I've read http://utsl.gen.nz/talks/git-svn/intro.html, "An
> introduction to git-svn for Subversion/SVK users and deserters" and, I
> guess I'm looking for a little more information.
[...]
> svn://host/wpd/{project1,project2,project3}. Since it's my own
> personal playground, I don't need branches, and tend to remember tags
> just be commit number.
There's your first issue - misunderstanding branching :) You should end
up realising that every little idea or feature forms a code branch in
the direction of its implementation, the choice is whether to let the
branches twist and grow together or train them in clear directions.
> Here's where I get stuck...
> 1) How can I remind myself of what I changed relative to what was in
> the Subversion repository the last time I sync'd to it? Under my
> current model of operation, I come in after a weekend/night away, do
> "svn status" and "svn diff" to remind myself what's changed, and
> commit those changes with appropriate log messages. I am hoping that
> I can make the changes locally, commiting them with nice log messages
> as I make the changes, and then "push" them to the subversion server
> when convenient.
use git-branch -a to show you the name that the remote subversion branch
is set up on.
then you can use "git-diff svn/trunk" (say, if it listed it as
"svn/trunk") to show you the files changed between your working copy and
the last subversion commit you did.
I can see that this point isn't very clear from the tutorial if you go
straight in at "How to ... commit back to Subversion". That section
needs a bit of an overall introduction I think. The idea is that first,
you make the changes in your local branch. (see
http://utsl.gen.nz/talks/git-svn/intro.html#local-commit). Then you use
dcommit to save it to Subversion. Using this you can stage multiple
commits, and if you don't like them you can go back and review them
before they are set in SVN forever.
That mode of operation is already natural for SVK users which the
tutorial was primarily targeted at - so they were probably already
looking for information on how to create a local branch, make local
changes and then push back.
> 2) This is going to have some obvious problems when I work on other
> projects shared with other developers. We know how to address this
> with Subversion (good communication, updating the working copy prior
> to a commit, resolving the minor conflicts, etc...) what can I expect
> when my local repository is git?
If svn is still the master there should be no difference to the way you
normally collaborate development using Subversion. The central server
is still the publishing point for trunk, however many release
engineering branches you use, and feature branches. It's only if you
want to start mixing groups of people, some working with subversion, and
other people using git-svn and merging between each other at the git
level, that you can start getting confused. They can safely operate at
the patch trading level though.
> 3) If I try to commit my change with:
>
> $ git-svn dcommit
>
> I get an error
> Commit 0e3e....
> has no parent commit, and therefore nothing to diff against.
> You should be working from a repository originally created by git-svn
>
> and that's where I get confused. Is this a bug/feature of 1.5.0.2
> that will disappear if I switched to 1.5.2.2?
>
> Are there any other tips/resources for mixed mode operation
> (centralized Subversion server, distributed git client(s))?
Almost certainly because you haven't committed locally yet.
Sam.
>
> Thanks for any pointers.
>
> --wpd
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: git for subversion users
From: Steven Grimm @ 2007-06-26 5:25 UTC (permalink / raw)
To: Patrick Doyle; +Cc: Sam Vilain, git
In-Reply-To: <46809733.2060200@vilain.net>
Sam Vilain wrote:
> If svn is still the master there should be no difference to the way you
> normally collaborate development using Subversion. The central server
> is still the publishing point for trunk, however many release
> engineering branches you use, and feature branches. It's only if you
> want to start mixing groups of people, some working with subversion, and
> other people using git-svn and merging between each other at the git
> level, that you can start getting confused. They can safely operate at
> the patch trading level though.
>
I can vouch for all of that as well. On some of my repositories I use
git solely as a fancy Subversion client, no interaction with any other
git repositories. And hardly anyone at my company even knows about it;
as far as they are concerned I just check stuff into the svn repository
like any other engineer.
But on a few of my repositories I do things like use git to keep a copy
of my work in progress synced up between my laptop and my development
server, or (rarely) share my work with another git-aware developer. In
those cases I do have to be kind of careful what I do, mostly around
making sure all the repositories are in agreement about which branches
come from where and about when I use rebase vs. merge vs. squash merge.
I will say, though, that the upcoming addition to git-svn to allow
merges to be directly committed to the svn repository will make some of
those kinds of scenarios a lot less brittle than they are now. It's
still a work in progress but it looks very promising so far. (Search the
list for "[PATCH] git-svn: allow dcommit to retain local merge
information" if you want to see what I'm talking about.)
-Steve
^ permalink raw reply
* Re: gitweb bug?
From: J.H. @ 2007-06-26 5:14 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Tarmigan Casebolt, Junio C Hamano, git
In-Reply-To: <200706260205.49337.jnareb@gmail.com>
I'm not seeing anything horrible per se in what it's doing - If you can
provide a list of the files it should be listing I'd be appreciative.
For instance on a $random machine with a 2.6.9 tree open on it that I
have at work I'm seeing:
[netlink]$ ls
af_netlink.c af_netlink.o built-in.o Makefile netlink_dev.c
netlink_dev.o
[netlink]$ pwd
..../linux-2.6.9/net/netlink
[netlink]$
So yeah - some further information on the problem your seeing would be
helpful as I don't have a tree checked out either right now.
- John 'Warthog9' Hawley
On Tue, 2007-06-26 at 02:05 +0200, Jakub Narebski wrote:
> On Mon, 25 June 2007, Tarmigan Casebolt wrote:
> >
> > I was looking through the kernel source and noticed a difference
> > between the git version and the gitweb version here:
> > http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=net/netlink
> > on gitweb, I only see 4 files, but in git locally on linux I see 71.
> >
> > This might be because there are files that differ only in case? (I'm
> > using OSX, which has problems with case, and in particular that
> > directory of the kernel source.)
> >
> > Am I missing something, or is this a bug?
>
> First of all, this question should be asked IMVHO on git mailing list,
> with Cc: sent to Kernel.Org admins or John 'Warthog9' Hawley, author of
> the gitweb modification (caching gitweb) used at kernel.org
>
> I cannot help you what the contents of net/netlink should look like,
> because I don't have clone of the linux kernel repository. By "in git
> locally on linux" you mean in the working area? Or perhaps result of
> "git ls-tree HEAD:net/netlink"? You should have provided command used
> to get those 71 files, and perhaps even those 71 files list.
>
^ permalink raw reply
* Re: git for subversion users
From: Sam Vilain @ 2007-06-26 5:54 UTC (permalink / raw)
To: Steven Grimm; +Cc: git
In-Reply-To: <4680A341.5000208@midwinter.com>
Steven Grimm wrote:
> I will say, though, that the upcoming addition to git-svn to allow
> merges to be directly committed to the svn repository will make some of
> those kinds of scenarios a lot less brittle than they are now. It's
> still a work in progress but it looks very promising so far. (Search the
> list for "[PATCH] git-svn: allow dcommit to retain local merge
> information" if you want to see what I'm talking about.)
Yes. On that. It would be nice if git-svn could also fake setting
remote merge properties, too.
Some beginnings at:
http://git.catalyst.net.nz/gw?p=git.git;a=shortlog;h=svk-merge
(pull from git://git.catalyst.net.nz/git.git#svk-merge)
What it needs to do;
0. preserve the notion that commits tagged with "git-svn-id:" should
not vary depending on who synced them.
1. on commit, if we're committing a merge, make sure that the other
parent has the same revision somewhere in the repo, and then set
the "svk:merge" and "svnmerge-integrated" tags to accurately record
which parent SVN revisions are used
2. when fetching revisions, spot these tickets and set parents
appropriately. In the case of SVK, the merge tickets may
correspond to revisions in (inaccessible) svk local depots. It may
be possible to infer these extra parents in some limited
situations using the extra information svk puts in commit messages
by default, but I doubt that is a useful endeavour!
I'll take a look at what you've been working on and see if that's not
what you're already trying...
Sam.
^ permalink raw reply
* Re: git for subversion users
From: Alexander Litvinov @ 2007-06-26 6:02 UTC (permalink / raw)
To: Sam Vilain; +Cc: Patrick Doyle, git
In-Reply-To: <46809733.2060200@vilain.net>
В сообщении от 26 июня 2007 11:33 Sam Vilain написал(a):
> There's your first issue - misunderstanding branching :) You should end
> up realising that every little idea or feature forms a code branch in
> the direction of its implementation, the choice is whether to let the
> branches twist and grow together or train them in clear directions.
git-svn has one major trouble with branch handling: merge two branches that
are different branches at svn. Or simply start from different point from svn
branch.
git-svn dcommit operation tries to figure out where to commit at svn side and
fail at these conditions. It seems to me this happend becuse it uses special
line at git's commit comment and in case of such merge it does not know there
to commit. I did not found how to deal with this situation.
So, git-svn just a offline-capable version of svn client with linear history.
Sure. you can fork your own branch and then merge it into svn branch again
but you should really careful about this.
I even does not know the way to solve this problem.
---
Alexander Litvinov.
^ permalink raw reply
* Re: git for subversion users
From: Sam Vilain @ 2007-06-26 7:29 UTC (permalink / raw)
To: Eric Wong; +Cc: Steven Grimm, git
In-Reply-To: <4680AA15.6040501@vilain.net>
Sam Vilain wrote:
> It would be nice if git-svn could also fake setting
> remote merge properties, too.
>
> Some beginnings at:
>
> http://git.catalyst.net.nz/gw?p=git.git;a=shortlog;h=svk-merge
> (pull from git://git.catalyst.net.nz/git.git#svk-merge)
>
> What it needs to do;
>
> 0. preserve the notion that commits tagged with "git-svn-id:" should
> not vary depending on who synced them.
>
> 1. on commit, if we're committing a merge, make sure that the other
> parent has the same revision somewhere in the repo, and then set
> the "svk:merge" and "svnmerge-integrated" tags to accurately record
> which parent SVN revisions are used
>
> 2. when fetching revisions, spot these tickets and set parents
> appropriately.
Proof of concept for #2 at:
http://git.catalyst.net.nz/gw?p=git.git;a=commitdiff;h=816e2ef
Sam.
^ permalink raw reply
* subversion and merging [was: Re: git for subversion users]
From: Sam Vilain @ 2007-06-26 7:48 UTC (permalink / raw)
To: Alexander Litvinov; +Cc: Patrick Doyle, git
In-Reply-To: <200706261302.10056.litvinov2004@gmail.com>
Alexander Litvinov wrote:
> So, git-svn just a offline-capable version of svn client with linear history.
> Sure. you can fork your own branch and then merge it into svn branch again
> but you should really careful about this.
>
> I even does not know the way to solve this problem.
The problem is the SVN model. Only now that people have woken up en
masse to the fact that tracking merges is actually really important are
they adding it to the core.
Their system¹ is of course completely incompatible with the predominant
tool for this SVK (no complaints there). Thankfully it looks based on
the other major solution out there, svnmerge, so hopefully only minor
incompatibilities can be expected.
My first analysis of the solution is that they have approached this on
two levels: commit merge ancestry and file merge ancestry.
File merge ancestry, while central to tools like Perforce, is a pretty
alien concept to git and almost certainly can be derived (probably more
reliably in practice) using git-cherry-type algorithms. I describe this
as the "smash patches to pieces" development model on my git-svn tutorial.
Commit merge ancestry is however a basic feature in git. They are even
going further than that and allowing cherry picks to be tracked as well.
This information is currently derived in git using git-cherry.
Sam.
¹ http://subversion.tigris.org/merge-tracking/design.html
^ permalink raw reply
* git-gui and untracked files
From: Guilhem Bonnefille @ 2007-06-26 8:02 UTC (permalink / raw)
To: Git List
Hi,
On my repos, I have lot of untracked files. In the same time, adding a
file is a really occasional action.
So, most of the time, I'm confused by the git-gui which shows me lot
and lot of files, where only on or two are interesting for me.
Is it possible to hide untracked files in git-gui? (for example an
option available with a right click on the "Changed but not updated"
frame)
Thanks for any tips.
--
Guilhem BONNEFILLE
-=- #UIN: 15146515 JID: guyou@im.apinc.org MSN: guilhem_bonnefille@hotmail.com
-=- mailto:guilhem.bonnefille@gmail.com
-=- http://nathguil.free.fr/
^ permalink raw reply
* Re: git-gui and untracked files
From: Johannes Sixt @ 2007-06-26 8:51 UTC (permalink / raw)
To: git
In-Reply-To: <8b65902a0706260102i25f79375r5e5b419107f6e587@mail.gmail.com>
Guilhem Bonnefille wrote:
> Is it possible to hide untracked files in git-gui? (for example an
> option available with a right click on the "Changed but not updated"
> frame)
Sure. Add the files to .gitignore (which you itself put under version
control) or to .git/info/exclude.
man 5 gitignore
-- Hannes
^ permalink raw reply
* Re: [PATCH] git-rev-list: give better diagnostic for failed write
From: Jeff King @ 2007-06-26 9:06 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jim Meyering, git
In-Reply-To: <alpine.LFD.0.98.0706251536240.8675@woody.linux-foundation.org>
On Mon, Jun 25, 2007 at 03:56:11PM -0700, Linus Torvalds wrote:
> --- a/log-tree.c
> +++ b/log-tree.c
> @@ -408,5 +408,6 @@ int log_tree_commit(struct rev_info *opt, struct commit *commit)
> shown = 1;
> }
> opt->loginfo = NULL;
> + flush_or_die(stdout, "stdout");
> return shown;
> }
I think flushing here is a good change regardless of the error checking.
Sometimes, when you are severely limiting commits, the whole output is
smaller than the buffer, and you end up waiting a long time for any
output even though your answer may have been found immediately.
For example, 'git-whatchanged -Sfoo' when 'foo' was introduced in the
last couple of commits (but wasn't referenced before) will have to
calculate diffs on all of history before producing output. Flushing
after every commit restores the illusion that git provides your answer
instaneously. :)
-Peff
^ permalink raw reply
* Re: [PATCH 3/3] config: Add --null/-z option for null-delimted output
From: Frank Lichtenheld @ 2007-06-26 10:47 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <200706260129.47518.jnareb@gmail.com>
On Tue, Jun 26, 2007 at 01:29:46AM +0200, Jakub Narebski wrote:
> Frank Lichtenheld wrote:
> > else
> > - printf("%s", key_);
> > + printf("%s",key_);
> > }
>
> That is a mistake, I think?
Indeed. I remember I saw and fixed that before sending. Must've
been a halluzination ;)
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* git-svn dcommit fails if the URL has spaces in it
From: Rogan Dawes @ 2007-06-26 11:24 UTC (permalink / raw)
To: Git Mailing List
Hi folks,
I used git-svn to clone the webgoat repository at GoogleCode. As
mentioned at the time, for some bizarre reason, I ended up getting a
directory with a space character in it.
See http://article.gmane.org/gmane.comp.version-control.git/49179
In order to get a checkout that looks the same as the SVN checkout, I
had to use a command line like:
git-svn clone -T "trunk/ webgoat" https://webgoat.googlecode.com/svn/
Unfortunately, this results in git-svn-id metadata entries in the
commits that look like:
git-svn-id: https://webgoat.googlecode.com/svn/trunk/ webgoat@2
4033779f-a91e-0410-96ef-6bf7bf53c507
(Should be all on one line). As you can see, the space has made it
through into the git-svn-id. Which then breaks this pattern match in
git-svn:extract_metadata:
my ($url, $rev, $uuid) = ($id =~ /^git-svn-id:\s(\S+?)\@(\d+)
\s([a-f\d\-]+)$/x);
Unfortunately, hacking it to ignore the space doesn't help either, as I
then get:
[rdawes@lucas webgoat]$ git-svn --username=rogan.dawes dcommit
ID = git-svn-id: https://webgoat.googlecode.com/svn/trunk/ webgoat@125
4033779f-a91e-0410-96ef-6bf7bf53c507
ID = git-svn-id: https://webgoat.googlecode.com/svn/trunk/ webgoat@125
4033779f-a91e-0410-96ef-6bf7bf53c507
RA layer request failed: PROPFIND request failed on '/svn/trunk/
webgoat': PROPFIND of '/svn/trunk/ webgoat': 400 Bad Request
(https://webgoat.googlecode.com) at /home/rdawes/bin/git-svn line 406
Which is entirely unsurprising, since I suspect that the URL was not
being quoted/escaped correctly, and we were sending something like:
PROPFIND /svn/trunk/ webgoat/ HTTP/1.0
Which is clearly illegal, having an additional field.
However, I tried encoding the space to %20, and got back to my original
problem, i.e.
Unable to determine upstream SVN information from HEAD history
If I run "git-svn -n dcommit", however, it does print out a list of
"diff-tree <sha>~1 <sha>" entries.
At this point, I am pretty well stuck. Any suggestions would be much
appreciated.
Regards,
Rogan Dawes
^ permalink raw reply
* Re: git for subversion users
From: Patrick Doyle @ 2007-06-26 13:19 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <4680C057.5070202@vilain.net>
Thank you all for the tips and pointers, especially to Sam, who has
given me something to digest, and to Steven, whose mode of operation,
"I can vouch for all of that as well. On some of my repositories I use
git solely as a fancy Subversion client, no interaction with any other
git repositories. And hardly anyone at my company even knows about
it"; precisely matches what I am trying to do.
It seems that a large part of my original problem was with the fact
that FC6 only has git-1.5.0.2 on it. When I installed 1.5.2.2, things
started working much more smoothly for me.
I still have one issue... say I start a project in git and later want
to publish it to the subversion server, history and all... how do I do
that?
Right now, I do the following:
$ svn mkdir url://to/svn/repo/newproject -m "made directory"
$ git-svn clone url://to/svn/repo/newproject
$ cd newproject
$ git pull url://from/project/started/in/git
$ git log
-- shows the history of my git based project, along with the "made
directory" log message
$ git-svn dcommit
-- commits only a single change to the svn repository with a log
message that reads something like "merged
url://from/project/started/in/git"
$ git-log
-- no longer shows the history of my git based project, it just shows
the subversion history
Is this related to the follow-on discussion regarding handling merges properly?
Is there some other way to "export" a git repository to a subversion
repository, maintaining the history along the way?
Once again, thanks for your help.
--wpd
^ permalink raw reply
* Re: [PATCH 2/2] Check for IO errors after running a command
From: Matthias Lederhofer @ 2007-06-26 13:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy7i8xtap.fsf@assigned-by-dhcp.pobox.com>
Junio C Hamano <gitster@pobox.com> wrote:
> The changes to git.c (run_command) conflicted with GIT_WORK_TREE
> changes in a minor way. Matthias, could you sanity check the
> result once I push it out to 'next', please?
The changes look fine, the tests pass and my own short manual test
passed.
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Matthias Lederhofer @ 2007-06-26 13:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v645cz7vm.fsf@assigned-by-dhcp.pobox.com>
Junio C Hamano <gitster@pobox.com> wrote:
> * ml/worktree (Fri Jun 8 22:57:55 2007 +0200) 9 commits
> + make git barf when an alias changes environment variables
> + setup_git_directory: fix segfault if repository is found in cwd
> + test GIT_WORK_TREE
> + extend rev-parse test for --is-inside-work-tree
> + Use new semantics of is_bare/inside_git_dir/inside_work_tree
> + introduce GIT_WORK_TREE to specify the work tree
> + test git rev-parse
> + rev-parse: introduce --is-bare-repository
> + rev-parse: document --is-inside-git-dir
> * ei/worktree+filter (Wed Jun 6 09:16:56 2007 +0200) 9 commits
> + filter-branch: always export GIT_DIR if it is set
>
> I've been resisting these due to the size of the series, but I
> think the definition of is-bare is a bit saner than what we have
> in 'master', and I think it is the right direction in the longer
> term. HOWEVER, I am not sure about the implementation and
> corner cases, e.g. what should it do in receive-pack? You
> cannot rely on user setting GIT_WORK_TREE environment -- rather,
> receive-pack is responsible for setting up a sane environment
> for other commands to work in.
Thanks. I'll have a look at receive-pack this week. Is there
anything in receive-pack yet which helps to use a working tree in the
hooks? Or is this something for which the behaviour of git still has
to be defined?
^ permalink raw reply
* git-svn: libsvn-perl_1.4.4 and do_switch()
From: Gerrit Pape @ 2007-06-26 13:37 UTC (permalink / raw)
To: git
Hi, on Debian unstable the current version of libsvn-perl is 1.4.4dfsg1.
With this version git-svn uses do_switch instead of do_update, which
seems to not work properly, please see
http://bugs.debian.org/430091
on how to reproduce the problem. The following also is showing a
problem, as it blocks in read() after do_switch
git svn clone -T trunk -b branches -t tags \
svn://bruce-guenter.dyndns.org/bglibs
I'm not sure whether this is a git-svn or a subversion problem, thanks
for your input.
Regards, Gerrit.
^ permalink raw reply
* [PATCH] ignore git-rebase--interactive
From: Matthias Lederhofer @ 2007-06-26 13:38 UTC (permalink / raw)
To: git
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
---
.gitignore | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/.gitignore b/.gitignore
index e8b060c..a2a617d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -96,6 +96,7 @@ git-push
git-quiltimport
git-read-tree
git-rebase
+git-rebase--interactive
git-receive-pack
git-reflog
git-relink
--
1.5.2.2.1345.gbf4a0
^ permalink raw reply related
* Problem with Linus's git repository?
From: walt @ 2007-06-26 14:45 UTC (permalink / raw)
To: git
For two days I've been unable to pull from Linus's kernel
git repository. The reason seems to be that HEAD is a
symlink to refs/heads/master, which appears to be missing.
I'm wondering if Linus's personal version of git is broken ;o)
^ permalink raw reply
* Re: Problem with Linus's git repository?
From: Linus Torvalds @ 2007-06-26 16:43 UTC (permalink / raw)
To: walt; +Cc: git
In-Reply-To: <f5r8q5$pbr$1@sea.gmane.org>
On Tue, 26 Jun 2007, walt wrote:
>
> For two days I've been unable to pull from Linus's kernel
> git repository. The reason seems to be that HEAD is a
> symlink to refs/heads/master, which appears to be missing.
It's not missing, it's packed. I tend to re-pack after I make a release,
and this time I did it after -rc6.
I assume you're using http, and probably not a very recent version.
> I'm wondering if Linus's personal version of git is broken ;o)
http fetching has always been the ugly step-child of the other protocols.
I personally dislike it a lot. But it _should_ work even with packed refs,
at least if recent enough.
I just tested, it seems to work for me (I didn't wait for the clone to
succeed, but it certainly got started).
Linus
^ permalink raw reply
* Re: [PATCH] git-rev-list: give better diagnostic for failed write
From: Theodore Tso @ 2007-06-26 17:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jim Meyering, git
In-Reply-To: <alpine.LFD.0.98.0706251607000.8675@woody.linux-foundation.org>
On Mon, Jun 25, 2007 at 04:16:56PM -0700, Linus Torvalds wrote:
> Again, this is something that a non-stdio-based buffering library would
> easily handle. You could just test the file descriptor _once_ at the
> beginning, to see if it's a regular file or not. And then you could have
> the error handling where it belongs (when the IO is actually done, and the
> error actually happens) rather than in the callers using a bad interface
> that sometimes loses 'errno'.
Is there something obviously wrong with doing something like this?
if ((fstat(fileno(stdout), &st) < 0) &&
!S_ISREG(st.st_mode))
setbuf(stdout, NULL);
This would change stdout to use completely unbuffered I/O we're not
sending the output to a file.
- Ted
^ permalink raw reply
* Re: [PATCH] git-rev-list: give better diagnostic for failed write
From: Linus Torvalds @ 2007-06-26 17:12 UTC (permalink / raw)
To: Jeff King; +Cc: Jim Meyering, git
In-Reply-To: <20070626090605.GA4349@coredump.intra.peff.net>
On Tue, 26 Jun 2007, Jeff King wrote:
>
> I think flushing here is a good change regardless of the error checking.
> Sometimes, when you are severely limiting commits, the whole output is
> smaller than the buffer, and you end up waiting a long time for any
> output even though your answer may have been found immediately.
Exactly. That's why it was done in git-rev-list, and why it's good to do
in "git log" too.
The slowdown worries me a bit, but it's only noticeable with *lots* of
output - ie no path limiting (and no diffs - the diff generation becomes
the bottleneck if you do diffs). So the flushing slows down a case that we
do ridiculously well right now, so I doubt anybody will really care.
It's more a benchmarking issue: "we can show the whole log of the kernel
in under two seconds", and it didn't slow down *that* much.
> For example, 'git-whatchanged -Sfoo' when 'foo' was introduced in the
> last couple of commits (but wasn't referenced before) will have to
> calculate diffs on all of history before producing output. Flushing
> after every commit restores the illusion that git provides your answer
> instaneously. :)
On that note, it should probably also do it for the incremental output of
git blame.
Linus
---
diff --git a/builtin-blame.c b/builtin-blame.c
index f7e2c13..86ab6c7 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -1459,6 +1459,7 @@ static void found_guilty_entry(struct blame_entry *ent)
printf("boundary\n");
}
write_filename_info(suspect->path);
+ flush_or_die(stdout, "stdout");
}
}
^ permalink raw reply related
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