* Re: [PATCH 5/5] Enable ref log creation in git checkout -b.
From: Junio C Hamano @ 2006-05-24 4:32 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060524035234.GA13329@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> Sure. I've been putting it off as I've been busy the past few days
> and have also been thinking about trying to rebuild reflog using a
> tag/annotation branch style, which might be more generally useful
> to others. So I've been debating about whether or not I should
> ask you to pop reflog out of pu indefinately.
Heh, too late for that -- it looked OK so now they are part of
"next" to get wider exposure.
^ permalink raw reply
* Re: [PATCH] Add a test-case for git-apply trying to add an ending line
From: Junio C Hamano @ 2006-05-24 4:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Catalin Marinas, git
In-Reply-To: <Pine.LNX.4.64.0605231905470.5623@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Tue, 23 May 2006, Junio C Hamano wrote:
>
>> The issue is if we can reliably tell if there is such an EOF
>> context by looking at the diff. Not having the same number of
>> lines that starts with ' ' in the hunk is not really a nice way
>> of doing so (you could make a unified diff that does not have
>> trailing context at all), and I do not offhand think of a good
>> way to do so.
>
> We can. Something like this should do it.
>
> (The same thing could be done for "match_beginning", perhaps).
But this is exactly what I said I had trouble with in the above.
In the extreme case, wouldn't this make git apply to refuse to
apply a self generated patch with 0-line context? IOW,
$ git checkout -- foo ;# reset to indexed version
$ edit foo
$ git diff -U0 >P.diff
$ git checkout -- foo ;# reset to indexed version
$ git apply <P.diff
would fail, even though it _should_ cleanly apply.
I'd admit that trying to apply a patch without context like the
above example _is_ insane, and I realize that I am making this
problem unsolvable by refusing the heuristics to consider that
the patch is anchored at the end when we do not see any trailing
context. But somehow it feels wrong...
^ permalink raw reply
* A few stgit bugfixes
From: Karl Hasselström @ 2006-05-24 6:05 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
Fixes for a few bugs recently introduced in stgit by yours truly.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [PATCH 1/3] Fix infinite recursion on absolute paths
From: Karl Hasselström @ 2006-05-24 6:06 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20060524060537.GA1173@diana.vm.bytemark.co.uk>
Calling create_dirs with an absolute path caused infinite recursion,
since os.path.dirname('/') == '/'. Fix this by exiting early if the
given path already is a directory.
---
stgit/utils.py | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/stgit/utils.py b/stgit/utils.py
index 68b8f58..ed6e43c 100644
--- a/stgit/utils.py
+++ b/stgit/utils.py
@@ -130,7 +130,7 @@ def remove_file_and_dirs(basedir, file):
def create_dirs(directory):
"""Create the given directory, if the path doesn't already exist."""
- if directory:
+ if directory and not os.path.isdir(directory):
create_dirs(os.path.dirname(directory))
try:
os.mkdir(directory)
^ permalink raw reply related
* [PATCH 2/3] Fix indexing error during "diff -r/"
From: Karl Hasselström @ 2006-05-24 6:06 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20060524060537.GA1173@diana.vm.bytemark.co.uk>
The string indexing when decoding the -r argument for diff made an
implicit assumption that the revision string was at least two
characters long, which broke on the simple invocation "diff -r/".
---
stgit/commands/diff.py | 8 ++++----
stgit/utils.py | 6 ++++++
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/stgit/commands/diff.py b/stgit/commands/diff.py
index d765784..caa3c5b 100644
--- a/stgit/commands/diff.py
+++ b/stgit/commands/diff.py
@@ -56,11 +56,11 @@ def func(parser, options, args):
rev_list_len = len(rev_list)
if rev_list_len == 1:
rev = rev_list[0]
- if rev[-1] == '/':
+ if rev.endswith('/'):
# the whole patch
- rev = rev[:-1]
- if rev[-1] == '/':
- rev = rev[:-1]
+ rev = strip_suffix('/', rev)
+ if rev.endswith('/'):
+ rev = strip_suffix('/', rev)
rev1 = rev + '//bottom'
rev2 = rev + '//top'
else:
diff --git a/stgit/utils.py b/stgit/utils.py
index ed6e43c..67431ec 100644
--- a/stgit/utils.py
+++ b/stgit/utils.py
@@ -109,6 +109,12 @@ def strip_prefix(prefix, string):
assert string.startswith(prefix)
return string[len(prefix):]
+def strip_suffix(suffix, string):
+ """Return string, without the suffix. Blow up if string doesn't
+ end with suffix."""
+ assert string.endswith(suffix)
+ return string[:-len(suffix)]
+
def remove_dirs(basedir, dirs):
"""Starting at join(basedir, dirs), remove the directory if empty,
and try the same with its parent, until we find a nonempty
^ permalink raw reply related
* [PATCH 3/3] Explicitly specify utf-8 coding in file
From: Karl Hasselström @ 2006-05-24 6:07 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20060524060537.GA1173@diana.vm.bytemark.co.uk>
uncommit.py has a non-ascii character in it (in my name in the
copyright line). Without this coding: comment, I get an error like the
following when I run stgit:
/home/kha/git/stgit/stgit/main.py:61: DeprecationWarning: Non-ASCII
character '\xc3' in file
/home/kha/git/stgit/stgit/commands/uncommit.py on line 3, but no
encoding declared; see http://www.python.org/peps/pep-0263.html for
details
---
stgit/commands/uncommit.py | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/stgit/commands/uncommit.py b/stgit/commands/uncommit.py
index e03d207..52ce5a8 100644
--- a/stgit/commands/uncommit.py
+++ b/stgit/commands/uncommit.py
@@ -1,3 +1,5 @@
+# -*- coding: utf-8 -*-
+
__copyright__ = """
Copyright (C) 2006, Karl Hasselström <kha@treskal.com>
^ permalink raw reply related
* Incremental cvsimports
From: Geoff Russell @ 2006-05-24 7:46 UTC (permalink / raw)
To: git
Dear Git,
I have a 3Gb repository (10 years of history) which I want to import into git.
I have tested little pieces of that and a 23Mb directory expands to 120Mb prior
to packing/pruning. Therefore I don't have a big enough disk to import the
whole repository at once. So I figure I could do it in pieces with a pack after
each piece.
So I tried something like:
1. $ git cvsimport -o austrics -v -d /cvsroot -C /GitRepo /cvsroot/A
followed by
2. $ git cvsimport -o austrics -v -d /cvsroot -C /GitRepo /cvsroot/B
After 1, /GitRepo/.git is set up but /GitRepo has the members of A,
not A itself.
After 2, /GitRepo also has members of B. This isn't quite what I wanted!
Is there a way to do this?
Cheers,
Geoff Russell
^ permalink raw reply
* [RFC][PATCH] Allow transfer of any valid sha1
From: Eric W. Biederman @ 2006-05-24 7:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
While working on git-quiltimport I decided to see if
I could transform Andrews patches where he imports git tress into
git-pull commands, which should result in better history and better
attribution.
To be accurate of his source Andrew records the sha1 of the commit
and the git tree he pulled from. Which looks like:
GIT b307e8548921c686d2eb948ca418ab2941876daa \
git+ssh://master.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
So I figured I would transform the above line into the obvious
git-pull command:
git-pull \
git+ssh://master.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git \
b307e8548921c686d2eb948ca418ab2941876daa
To my surprise that didn't work. There were a couple of little places
in the scripts where git-fetch and git-fetch-pack never expected to be
given a sha1 but that was easy to fix up, and had no real repercussions.
More problematic was the little bit in git-upload pack that only
allows you to a sha1 if it was on the list of sha1 generated from
looking at the heads. I'm not at all certain of the sense of
that check as you can get everything by just cloning the repository.
Can we fix the check in upload-pack.c something like my
patch below does? Are there any security implications for
doing that?
Could we just make the final check before dying if (!o) ?
/* We have sent all our refs already, and the other end
* should have chosen out of them; otherwise they are
* asking for nonsense.
*
* Hmph. We may later want to allow "want" line that
* asks for something like "master~10" (symbolic)...
* would it make sense? I don't know.
*/
diff --git a/upload-pack.c b/upload-pack.c
index 47560c9..0f2e544 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -207,7 +207,9 @@ static int receive_needs(void)
* would it make sense? I don't know.
*/
o = lookup_object(sha1_buf);
- if (!o || !(o->flags & OUR_REF))
+ if (!o)
+ o = parse_object(sha1_buf);
+ if (!o || ((o->type != commit_type) && (o->type != tag_type)))
die("git-upload-pack: not our ref %s", line+5);
if (!(o->flags & WANTED)) {
o->flags |= WANTED;
^ permalink raw reply related
* [PATCH] gitk: Replace "git-" commands with "git "
From: Timo Hirvonen @ 2006-05-24 7:57 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
git-* commands work only if gitexecdir is in PATH.
Signed-off-by: Timo Hirvonen <tihirvon@gmail.com>
---
NOTE: This is for the gitk repository.
cad90165494784f29aec40bca2c1e2bbc39e7a76
gitk | 52 ++++++++++++++++++++++++++--------------------------
1 files changed, 26 insertions(+), 26 deletions(-)
cad90165494784f29aec40bca2c1e2bbc39e7a76
diff --git a/gitk b/gitk
index bd8d4f1..7427856 100755
--- a/gitk
+++ b/gitk
@@ -34,10 +34,10 @@ proc start_rev_list {view} {
set order "--date-order"
}
if {[catch {
- set fd [open [concat | git-rev-list --header $order \
+ set fd [open [concat | git rev-list --header $order \
--parents --boundary --default HEAD $args] r]
} err]} {
- puts stderr "Error executing git-rev-list: $err"
+ puts stderr "Error executing git rev-list: $err"
exit 1
}
set commfd($view) $fd
@@ -94,10 +94,10 @@ proc getcommitlines {fd view} {
}
if {[string range $err 0 4] == "usage"} {
set err "Gitk: error reading commits$fv:\
- bad arguments to git-rev-list."
+ bad arguments to git rev-list."
if {$viewname($view) eq "Command line"} {
append err \
- " (Note: arguments to gitk are passed to git-rev-list\
+ " (Note: arguments to gitk are passed to git rev-list\
to allow selection of commits to be displayed.)"
}
} else {
@@ -148,7 +148,7 @@ proc getcommitlines {fd view} {
if {[string length $shortcmit] > 80} {
set shortcmit "[string range $shortcmit 0 80]..."
}
- error_popup "Can't parse git-rev-list output: {$shortcmit}"
+ error_popup "Can't parse git rev-list output: {$shortcmit}"
exit 1
}
set id [lindex $ids 0]
@@ -217,7 +217,7 @@ proc doupdate {} {
}
proc readcommit {id} {
- if {[catch {set contents [exec git-cat-file commit $id]}]} return
+ if {[catch {set contents [exec git cat-file commit $id]}]} return
parsecommit $id $contents 0
}
@@ -276,8 +276,8 @@ proc parsecommit {id contents listed} {
set headline $comment
}
if {!$listed} {
- # git-rev-list indents the comment by 4 spaces;
- # if we got this via git-cat-file, add the indentation
+ # git rev-list indents the comment by 4 spaces;
+ # if we got this via git cat-file, add the indentation
set newcomment {}
foreach line [split $comment "\n"] {
append newcomment " "
@@ -337,14 +337,14 @@ proc readrefs {} {
set type {}
set tag {}
catch {
- set commit [exec git-rev-parse "$id^0"]
+ set commit [exec git rev-parse "$id^0"]
if {"$commit" != "$id"} {
set tagids($name) $commit
lappend idtags($commit) $name
}
}
catch {
- set tagcontents($name) [exec git-cat-file tag "$id"]
+ set tagcontents($name) [exec git cat-file tag "$id"]
}
} elseif { $type == "heads" } {
set headids($name) $id
@@ -1287,7 +1287,7 @@ proc vieweditor {top n title} {
checkbutton $top.perm -text "Remember this view" -variable newviewperm($n)
grid $top.perm - -pady 5 -sticky w
message $top.al -aspect 1000 -font $uifont \
- -text "Commits to include (arguments to git-rev-list):"
+ -text "Commits to include (arguments to git rev-list):"
grid $top.al - -sticky w -pady 5
entry $top.args -width 50 -textvariable newviewargs($n) \
-background white
@@ -2941,7 +2941,7 @@ proc findpatches {} {
}
if {[catch {
- set f [open [list | git-diff-tree --stdin -s -r -S$findstring \
+ set f [open [list | git diff-tree --stdin -s -r -S$findstring \
<< $inputids] r]
} err]} {
error_popup "Error starting search process: $err"
@@ -2973,7 +2973,7 @@ proc readfindproc {} {
return
}
if {![regexp {^[0-9a-f]{40}} $line id]} {
- error_popup "Can't parse git-diff-tree output: $line"
+ error_popup "Can't parse git diff-tree output: $line"
stopfindproc
return
}
@@ -3038,10 +3038,10 @@ proc findfiles {} {
if {$l == $findstartline} break
}
- # start off a git-diff-tree process if needed
+ # start off a git diff-tree process if needed
if {$diffsneeded ne {}} {
if {[catch {
- set df [open [list | git-diff-tree -r --stdin << $diffsneeded] r]
+ set df [open [list | git diff-tree -r --stdin << $diffsneeded] r]
} err ]} {
error_popup "Error starting search process: $err"
return
@@ -3071,7 +3071,7 @@ proc readfilediffs {df} {
if {[catch {close $df} err]} {
stopfindproc
bell
- error_popup "Error in git-diff-tree: $err"
+ error_popup "Error in git diff-tree: $err"
} elseif {[info exists findid]} {
set id $findid
stopfindproc
@@ -3098,7 +3098,7 @@ proc donefilediff {} {
if {[info exists fdiffid]} {
while {[lindex $fdiffsneeded $fdiffpos] ne $fdiffid
&& $fdiffpos < [llength $fdiffsneeded]} {
- # git-diff-tree doesn't output anything for a commit
+ # git diff-tree doesn't output anything for a commit
# which doesn't change anything
set nullid [lindex $fdiffsneeded $fdiffpos]
set treediffs($nullid) {}
@@ -3526,7 +3526,7 @@ proc gettree {id} {
catch {unset diffmergeid}
if {![info exists treefilelist($id)]} {
if {![info exists treepending]} {
- if {[catch {set gtf [open [concat | git-ls-tree -r $id] r]}]} {
+ if {[catch {set gtf [open [concat | git ls-tree -r $id] r]}]} {
return
}
set treepending $id
@@ -3574,7 +3574,7 @@ proc showfile {f} {
return
}
set blob [lindex $treeidlist($diffids) $i]
- if {[catch {set bf [open [concat | git-cat-file blob $blob] r]} err]} {
+ if {[catch {set bf [open [concat | git cat-file blob $blob] r]} err]} {
puts "oops, error reading blob $blob: $err"
return
}
@@ -3616,7 +3616,7 @@ proc mergediff {id l} {
set diffids $id
# this doesn't seem to actually affect anything...
set env(GIT_DIFF_OPTS) $diffopts
- set cmd [concat | git-diff-tree --no-commit-id --cc $id]
+ set cmd [concat | git diff-tree --no-commit-id --cc $id]
if {[catch {set mdf [open $cmd r]} err]} {
error_popup "Error getting merge diffs: $err"
return
@@ -3728,7 +3728,7 @@ proc gettreediffs {ids} {
set treepending $ids
set treediff {}
if {[catch \
- {set gdtf [open [concat | git-diff-tree --no-commit-id -r $ids] r]} \
+ {set gdtf [open [concat | git diff-tree --no-commit-id -r $ids] r]} \
]} return
fconfigure $gdtf -blocking 0
fileevent $gdtf readable [list gettreediffline $gdtf $ids]
@@ -3764,7 +3764,7 @@ proc getblobdiffs {ids} {
global nextupdate diffinhdr treediffs
set env(GIT_DIFF_OPTS) $diffopts
- set cmd [concat | git-diff-tree --no-commit-id -r -p -C $ids]
+ set cmd [concat | git diff-tree --no-commit-id -r -p -C $ids]
if {[catch {set bdf [open $cmd r]} err]} {
puts "error getting diffs: $err"
return
@@ -4301,7 +4301,7 @@ proc mkpatchgo {} {
set oldid [$patchtop.fromsha1 get]
set newid [$patchtop.tosha1 get]
set fname [$patchtop.fname get]
- if {[catch {exec git-diff-tree -p $oldid $newid >$fname &} err]} {
+ if {[catch {exec git diff-tree -p $oldid $newid >$fname &} err]} {
error_popup "Error creating patch: $err"
}
catch {destroy $patchtop}
@@ -4868,11 +4868,11 @@ proc tcl_encoding {enc} {
# defaults...
set datemode 0
set diffopts "-U 5 -p"
-set wrcomcmd "git-diff-tree --stdin -p --pretty"
+set wrcomcmd "git diff-tree --stdin -p --pretty"
set gitencoding {}
catch {
- set gitencoding [exec git-repo-config --get i18n.commitencoding]
+ set gitencoding [exec git repo-config --get i18n.commitencoding]
}
if {$gitencoding == ""} {
set gitencoding "utf-8"
@@ -4928,7 +4928,7 @@ if {$i >= 0} {
set revtreeargs [lrange $revtreeargs 0 [expr {$i - 1}]]
} elseif {$revtreeargs ne {}} {
if {[catch {
- set f [eval exec git-rev-parse --no-revs --no-flags $revtreeargs]
+ set f [eval exec git rev-parse --no-revs --no-flags $revtreeargs]
set cmdline_files [split $f "\n"]
set n [llength $cmdline_files]
set revtreeargs [lrange $revtreeargs 0 end-$n]
--
1.3.3.g40505-dirty
^ permalink raw reply related
* Re: Incremental cvsimports
From: Martin Langhoff @ 2006-05-24 8:21 UTC (permalink / raw)
To: geoff; +Cc: git
In-Reply-To: <93c3eada0605240046t10e00119n4cfc39ec33fe1d92@mail.gmail.com>
On 5/24/06, Geoff Russell <geoffrey.russell@gmail.com> wrote:
> Dear Git,
Dear Geoff,
if you look at the list archive for the last couple of days, you'll
see there's been quite a bit of activity in tuning cvsimport so that
it scales better with large imports like yours. We have been playing
with a gentoo cvs repo with 300K commits / 1.6GB uncompressed.
Don't split up the tree... that'll lead to something rather ackward.
Instead, fetch and build git from Junio's 'master' branch which seems
to have collected most (all?) of the patches posted, including one
from Linus that will repack the repo every 1K commits -- keeping the
import size down.
You _will_ need a lot of memory though, as cvsps grows large (working
on a workaround now) and cvsimport grows a bit over time (where is
that last leak?!). And a fast machine -- specially fast IO. I've just
switched from an old test machine to an AMD64 with fast disks, and
it's importing around 10K commits per hour.
You will probably want to run cvsps by hand, and later use the -P flag.
cheers,
martin
^ permalink raw reply
* Re: Incremental cvsimports
From: Martin Langhoff @ 2006-05-24 8:25 UTC (permalink / raw)
To: geoff; +Cc: git
In-Reply-To: <46a038f90605240121o117fadb6vf3ce910a3ad3e90@mail.gmail.com>
On 5/24/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> You _will_ need a lot of memory though, as cvsps grows large (working
> on a workaround now)
While the workaround is worked around, you can create the cvsps file
using something like
CVSROOT=~/tmp/gentoorepo/ cvsps --norc -x -u -A gentoo-x86 >
gentoo.cvsps 2> gentoo.err
and then pass a -P gentoo.cvsps to cvsimport. s/gentoo/myproject/ ;-)
martin
^ permalink raw reply
* Re: [RFC][PATCH] Allow transfer of any valid sha1
From: Junio C Hamano @ 2006-05-24 9:07 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: git
In-Reply-To: <m164jvj1x3.fsf@ebiederm.dsl.xmission.com>
ebiederm@xmission.com (Eric W. Biederman) writes:
> Can we fix the check in upload-pack.c something like my
> patch below does? Are there any security implications for
> doing that?
> Could we just make the final check before dying if (!o) ?
The primary implication is about correctness, so I am reluctant
to break it without a careful alternative check in place.
The issue is that having a single object in the repository does
not guarantee that you have everything reachable from it, and we
need that guarantee. Reachability from the refs is what
guarantees that.
We are careful to update the ref at the very end of the transfer
(fetch/clone or push); so if an object is reachable from a ref,
then all the objects reachable from that object are available in
the repository.
Imagine http commit walker started fetching tip of upstream into
your repository and you interrupted the transfer. Objects near
the tip of the upstream history are available after such an
interrupted transfer. But a bit older history (but still later
than what we had before we started the transfer) are not.
We do not update the ref with the downloaded tip object, so that
we would not break the guarantee. This guarantee is needed for
feeding clients from the repository later. If you tell your
clients, after such an interrupted transfer, that you are
willing to serve the objects near the (new) tip, the clients may
rightfully request objects that are reachable from these
objects, some of them you do _not_ have!
So this "on demand SHA1" stuff needs to be solved by checking if
the given object is reachable from our refs in upload-pack,
instead of the current check to see if the given object is
pointed by our refs. When upload-pack can prove that the object
is reachable from one of the refs, it is OK to use it; otherwise
you should not.
Now, proving that a given SHA1 is the name of an object that
exists in the repository is cheap (has_sha1_file()), but proving
that the object is reachable from some of our refs can become
quite expensive. That gives this issue a security implication
as well -- you can easily DoS the git-daemon that way, for
example.
^ permalink raw reply
* Re: [PATCH 2/2] cvsimport: cleanup commit function
From: Jeff King @ 2006-05-24 9:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Morten Welinder, Martin Langhoff, Matthias Urlichs, git
In-Reply-To: <7vpsi41f82.fsf@assigned-by-dhcp.cox.net>
On Tue, May 23, 2006 at 04:41:33PM -0700, Junio C Hamano wrote:
> Are you two talking about running git-commit-tree via env is two
> fork-execs instead of just one? Does that have a measurable
> difference?
Yes, that's what I was talking about. No, probably not a huge
difference. I did some performance measurements of all of the recent
cvsimport changes on a small-ish personal repo (I don't have the gentoo
repo). The results were not significant (<= 1% improvement for each
change). I would expect some of the changes (index-info, fetchfile) to
have an impact on a repo with different characteristics (like the gentoo
one).
-Peff
^ permalink raw reply
* Re: file name case-sensitivity issues
From: Ben Clifford @ 2006-05-24 9:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5e4xkrh.fsf@assigned-by-dhcp.cox.net>
On Tue, 23 May 2006, Junio C Hamano wrote:
> That's interesting. I wonder how... Does this sequence remove FOO
> on that filesystem?
>
> $ date >FOO
> $ rm -f foo
> $ ls
yes.
$ ls
$ date >FOO
$ ls
FOO
$ rm -f foo
$ ls
> Also if you do the final "git pull" using resolve strategy, does
> it change the result (say "git pull -s resolve . side" instead)?
Different result:
$ mkdir case-sensitivity-test
$ cd case-sensitivity-test
$ git init-db
defaulting to local storage area
$ echo foo > foo
$ echo bar > bar
$ git add foo bar
$ git commit -m initial\ commit
Committing initial tree 89ff1a2aefcbff0f09197f0fd8beeb19a7b6e51c
$ git checkout -b side
$ echo bar-side >> bar
$ git commit -m side\ commit -o bar
$ git checkout master
$ rm foo
$ git update-index --remove foo
$ echo FOO > FOO
$ git add FOO
$ git commit -m case\ change
$ ls
FOO bar
$ git pull -s resolve . side
Trying really trivial in-index merge...
fatal: Merge requires file-level merging
Nope.
Trying simple merge.
Merge 06c11eeb08edefba8178b091287ec6d951d1ef1d, made by resolve.
bar | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
$ ls
FOO bar
$
--
^ permalink raw reply
* Re: [PATCH] gitk: Replace "git-" commands with "git "
From: Timo Hirvonen @ 2006-05-24 10:34 UTC (permalink / raw)
To: Alex Riesen; +Cc: paulus, git
In-Reply-To: <81b0412b0605240323q29b64949s80d4738cb54c22c8@mail.gmail.com>
"Alex Riesen" <raa.lkml@gmail.com> wrote:
> On 5/24/06, Timo Hirvonen <tihirvon@gmail.com> wrote:
> > git-* commands work only if gitexecdir is in PATH.
> >
>
> How about getting exec-path (git --exec-path) and prepend it
> to every git-<call> instead? You'll save a fork+exec a call in this case.
Many commands are already built-in so I don't think it's a problem
anymore.
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* [PATCH] Builtin git-cat-file
From: Timo Hirvonen @ 2006-05-24 11:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Timo Hirvonen <tihirvon@gmail.com>
---
Not huge disc space savings but avoids fork+exec.
95174d93a8fb39b907f4f7359a381b9ad5757e5d
Makefile | 6 +++---
cat-file.c => builtin-cat-file.c | 3 ++-
builtin.h | 1 +
git.c | 1 +
4 files changed, 7 insertions(+), 4 deletions(-)
rename cat-file.c => builtin-cat-file.c (98%)
95174d93a8fb39b907f4f7359a381b9ad5757e5d
diff --git a/Makefile b/Makefile
index 5423b7a..faab3f9 100644
--- a/Makefile
+++ b/Makefile
@@ -149,7 +149,7 @@ SIMPLE_PROGRAMS = \
# ... and all the rest that could be moved out of bindir to gitexecdir
PROGRAMS = \
- git-apply$X git-cat-file$X \
+ git-apply$X \
git-checkout-index$X git-clone-pack$X git-commit-tree$X \
git-convert-objects$X git-diff-files$X \
git-diff-index$X git-diff-stages$X \
@@ -171,7 +171,7 @@ PROGRAMS = \
BUILT_INS = git-log$X git-whatchanged$X git-show$X \
git-count-objects$X git-diff$X git-push$X \
git-grep$X git-rev-list$X git-check-ref-format$X \
- git-init-db$X
+ git-init-db$X git-cat-file$X
# what 'all' will build and 'install' will install, in gitexecdir
ALL_PROGRAMS = $(PROGRAMS) $(SIMPLE_PROGRAMS) $(SCRIPTS)
@@ -220,7 +220,7 @@ LIB_OBJS = \
BUILTIN_OBJS = \
builtin-log.o builtin-help.o builtin-count.o builtin-diff.o builtin-push.o \
builtin-grep.o builtin-rev-list.o builtin-check-ref-format.o \
- builtin-init-db.o
+ builtin-init-db.o builtin-cat-file.o
GITLIBS = $(LIB_FILE) $(XDIFF_LIB)
LIBS = $(GITLIBS) -lz
diff --git a/cat-file.c b/builtin-cat-file.c
similarity index 98%
rename from cat-file.c
rename to builtin-cat-file.c
index 7413fee..8ab136e 100644
--- a/cat-file.c
+++ b/builtin-cat-file.c
@@ -7,6 +7,7 @@ #include "cache.h"
#include "exec_cmd.h"
#include "tag.h"
#include "tree.h"
+#include "builtin.h"
static void flush_buffer(const char *buf, unsigned long size)
{
@@ -93,7 +94,7 @@ static int pprint_tag(const unsigned cha
return 0;
}
-int main(int argc, char **argv)
+int cmd_cat_file(int argc, const char **argv, char **envp)
{
unsigned char sha1[20];
char type[20];
diff --git a/builtin.h b/builtin.h
index 6054126..01f2eec 100644
--- a/builtin.h
+++ b/builtin.h
@@ -27,5 +27,6 @@ extern int cmd_grep(int argc, const char
extern int cmd_rev_list(int argc, const char **argv, char **envp);
extern int cmd_check_ref_format(int argc, const char **argv, char **envp);
extern int cmd_init_db(int argc, const char **argv, char **envp);
+extern int cmd_cat_file(int argc, const char **argv, char **envp);
#endif
diff --git a/git.c b/git.c
index 3216d31..6df0902 100644
--- a/git.c
+++ b/git.c
@@ -52,6 +52,7 @@ static void handle_internal_command(int
{ "grep", cmd_grep },
{ "rev-list", cmd_rev_list },
{ "init-db", cmd_init_db },
+ { "cat-file", cmd_cat_file },
{ "check-ref-format", cmd_check_ref_format }
};
int i;
--
1.3.3.g40505-dirty
^ permalink raw reply related
* Re: Incremental cvsimports
From: Geoff Russell @ 2006-05-24 11:19 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90605240121o117fadb6vf3ce910a3ad3e90@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1972 bytes --]
Dear Martin,
On 5/24/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> On 5/24/06, Geoff Russell <geoffrey.russell@gmail.com> wrote:
> > Dear Git,
>
> Dear Geoff,
>
> if you look at the list archive for the last couple of days, you'll
> see there's been quite a bit of activity in tuning cvsimport so that
> it scales better with large imports like yours. We have been playing
> with a gentoo cvs repo with 300K commits / 1.6GB uncompressed.
>
> Don't split up the tree... that'll lead to something rather ackward.
> Instead, fetch and build git from Junio's 'master' branch which seems
> to have collected most (all?) of the patches posted, including one
> from Linus that will repack the repo every 1K commits -- keeping the
> import size down.
I got the latest git and yes, the size is kept down. I've only tried with
a smaller repository but it looks promising. When I ran git-cvsimport without a
CVS-module name (wanting the entire repository), it gave me a Usage message
indicating that the CVS-module name was optional - but it isn't :)
I did have to change
2 lines in git-cvsimport to get it to run with my 5.8.0 perl (problems with
POSIX errno). I've attached a patch but my work around isn't as quick as
what it replaced.
Many thanks, I'll have a go with the big repository at work tomorrow!
Cheers,
Geoff Russell
P.S. I've just started to look with git. We have wanted a cvs replacement for
a while but have been too scared to change (until now).
>
> You _will_ need a lot of memory though, as cvsps grows large (working
> on a workaround now) and cvsimport grows a bit over time (where is
> that last leak?!). And a fast machine -- specially fast IO. I've just
> switched from an old test machine to an AMD64 with fast disks, and
> it's importing around 10K commits per hour.
I
>
> You will probably want to run cvsps by hand, and later use the -P flag.
>
> cheers,
>
>
> martin
>
>
[-- Attachment #2: 999 --]
[-- Type: application/octet-stream, Size: 903 bytes --]
*** git-cvsimport 2006-05-24 20:13:19.000000000 +0930
--- /usr/local/bin/git-cvsimport 2006-05-24 20:22:27.000000000 +0930
*************** use File::Basename qw(basename dirname);
*** 23,29 ****
use Time::Local;
use IO::Socket;
use IO::Pipe;
! use POSIX qw(strftime dup2 :errno_h);
use IPC::Open2;
$SIG{'PIPE'}="IGNORE";
--- 23,29 ----
use Time::Local;
use IO::Socket;
use IO::Pipe;
! use POSIX qw(strftime dup2);
use IPC::Open2;
$SIG{'PIPE'}="IGNORE";
*************** sub get_headref ($$) {
*** 446,452 ****
is_sha1($r) or die "Cannot get head id for $name ($r): $!";
return $r;
}
! die "unable to open $f: $!" unless $! == POSIX::ENOENT;
return undef;
}
--- 446,452 ----
is_sha1($r) or die "Cannot get head id for $name ($r): $!";
return $r;
}
! die "unable to open $f: $!" if -f $f;
return undef;
}
^ permalink raw reply
* Re: Incremental cvsimports
From: Jeff King @ 2006-05-24 12:22 UTC (permalink / raw)
To: geoff; +Cc: Martin Langhoff, git
In-Reply-To: <93c3eada0605240419o48891cdle6c100fc0ac870ff@mail.gmail.com>
On Wed, May 24, 2006 at 08:49:03PM +0930, Geoff Russell wrote:
> I did have to change 2 lines in git-cvsimport to get it to run with my
> 5.8.0 perl (problems with POSIX errno). I've attached a patch but my
> work around isn't as quick as what it replaced.
Can you describe your problem in more detail? The POSIX errno constants
have been available since long before 5.8.0, so we should be able to use
them.
(btw, the change was introduced in my commit() cleanups:
e73aefe4fdba0d161d9878642c69b40d83a0204c).
-Peff
^ permalink raw reply
* Re: Incremental cvsimports
From: Geoff Russell @ 2006-05-24 12:33 UTC (permalink / raw)
To: geoff, Martin Langhoff, git
In-Reply-To: <20060524122246.GA3997@coredump.intra.peff.net>
Dear Jeff,
See below.
On 5/24/06, Jeff King <peff@peff.net> wrote:
> On Wed, May 24, 2006 at 08:49:03PM +0930, Geoff Russell wrote:
>
> > I did have to change 2 lines in git-cvsimport to get it to run with my
> > 5.8.0 perl (problems with POSIX errno). I've attached a patch but my
> > work around isn't as quick as what it replaced.
>
> Can you describe your problem in more detail? The POSIX errno constants
> have been available since long before 5.8.0, so we should be able to use
> them.
$ ./git-cvsimport
":errno_h" is not exported by the POSIX module
Can't continue after import errors at
/usr/lib/perl5/5.8.0/i386-linux-thread-multi/POSIX.pm line 19
BEGIN failed--compilation aborted at ./git-cvsimport line 26.
When I deleted ":errno_h" I needed to patch the place it was used (as per patch
I attached in original post).
Cheers,
Geoff Russell
>
> (btw, the change was introduced in my commit() cleanups:
> e73aefe4fdba0d161d9878642c69b40d83a0204c).
>
> -Peff
> -
> 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
* Slow fetches of tags
From: Ralf Baechle @ 2006-05-24 13:10 UTC (permalink / raw)
To: git
I have a fairly large git tree (with a 320MB pack file containing some
700,000 objects). A small fetch like
git fetch git://www.kernel.org/pub/scm/linux/kernel/git/stable/\
linux-2.6.16.y.git master:v2.6.16-stable
which only fetches a handful of objects (v2.6.16.17 -> v2.6.16.18) will
take on the order of 4-5 minutes. Adding the "-n" option is will bring
the operation down to under a second, so it really is just the tags
that are slowing things down so much..
Ralf
^ permalink raw reply
* Re: Incremental cvsimports
From: Jeff King @ 2006-05-24 13:23 UTC (permalink / raw)
To: geoff; +Cc: Martin Langhoff, git
In-Reply-To: <93c3eada0605240533q4d1b5b81p128dc2b905aa9976@mail.gmail.com>
On Wed, May 24, 2006 at 10:03:44PM +0930, Geoff Russell wrote:
> ":errno_h" is not exported by the POSIX module
> Can't continue after import errors at
> /usr/lib/perl5/5.8.0/i386-linux-thread-multi/POSIX.pm line 19
> BEGIN failed--compilation aborted at ./git-cvsimport line 26.
Hmm. It looks like something is nonstandard in your setup. I just compiled
5.8.0 from source and the :errno_h tag works fine. What is your
platform? Can you try the following and let me know which work:
$ perl -e 'use POSIX qw(:errno_h)'
$ perl -e 'use POSIX qw(errno_h)'
$ perl -e 'use Errno'
-Peff
^ permalink raw reply
* Re: [PATCH] Add a test-case for git-apply trying to add an ending line
From: Catalin Marinas @ 2006-05-24 13:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7v8xosqaqm.fsf@assigned-by-dhcp.cox.net>
On 24/05/06, Junio C Hamano <junkio@cox.net> wrote:
> I'd admit that trying to apply a patch without context like the
> above example _is_ insane, and I realize that I am making this
> problem unsolvable by refusing the heuristics to consider that
> the patch is anchored at the end when we do not see any trailing
> context. But somehow it feels wrong...
The reason I sent you this test is that GNU patch fails to apply the
diff but git-apply succeeds (and I thought git-apply is more
restrictive).
When there are context lines either before or after the "+" line, it
should be OK to assume that the diff has context and therefore the EOF
should be considered.
If there are no context lines at all, the diff is either without
context or it is meant to patch an empty file. The latter is safer and
probably valid for most of the cases but if you have a patch without
context, you could explicitely pass the -C0 option to git-apply.
--
Catalin
^ permalink raw reply
* Re: Incremental cvsimports
From: Geoff Russell @ 2006-05-24 13:47 UTC (permalink / raw)
To: Martin Langhoff, git, Jeff King
In-Reply-To: <20060524132317.GA4594@coredump.intra.peff.net>
Hi Jeff,
On 5/24/06, Jeff King <peff@peff.net> wrote:
> On Wed, May 24, 2006 at 10:03:44PM +0930, Geoff Russell wrote:
>
> > ":errno_h" is not exported by the POSIX module
> > Can't continue after import errors at
> > /usr/lib/perl5/5.8.0/i386-linux-thread-multi/POSIX.pm line 19
> > BEGIN failed--compilation aborted at ./git-cvsimport line 26.
>
> Hmm. It looks like something is nonstandard in your setup. I just compiled
> 5.8.0 from source and the :errno_h tag works fine. What is your
> platform? Can you try the following and let me know which work:
I compiled perl from source on Mandrake 9.1.
> $ perl -e 'use POSIX qw(:errno_h)'
> $ perl -e 'use POSIX qw(errno_h)'
> $ perl -e 'use Errno'
All 3 work. But if I add a second tag before the ':errno_h", then I
get an error.
The "use" line that makes git-cvsimport compile for me is:
use POSIX qw(strftime dup2 ENOENT);
Which just imports the required symbol and not the full tag list.
Cheers,
Geoff.
>
> -Peff
> -
> 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: Incremental cvsimports
From: Jeff King @ 2006-05-24 13:58 UTC (permalink / raw)
To: junkio; +Cc: Martin Langhoff, git, geoff
In-Reply-To: <93c3eada0605240647i48db0588ja343e348f5feb08e@mail.gmail.com>
On Wed, May 24, 2006 at 11:17:32PM +0930, Geoff Russell wrote:
> All 3 work. But if I add a second tag before the ':errno_h", then I
> get an error.
>
> The "use" line that makes git-cvsimport compile for me is:
>
> use POSIX qw(strftime dup2 ENOENT);
Odd. It's either a bug with importing tags in older versions, or there's
some deep perl voodoo that I don't understand (either way, it is "fixed"
in more recent versions). Importing ENOENT directly is reasonable.
Junio, can you apply the following fix?
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index af331d9..76f6246 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -23,7 +23,7 @@ use File::Basename qw(basename dirname);
use Time::Local;
use IO::Socket;
use IO::Pipe;
-use POSIX qw(strftime dup2 :errno_h);
+use POSIX qw(strftime dup2 ENOENT);
use IPC::Open2;
$SIG{'PIPE'}="IGNORE";
^ permalink raw reply related
* Re: [osol-bugs] access() behaves strange when used as root
From: Stefan Pfetzing @ 2006-05-24 14:08 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <447460C1.6070305@sun.com>
Hi Alan,
2006/5/24, Alan Coopersmith <Alan.Coopersmith@sun.com>:
> Compilers also fall in the class of things I've never understood why
> people would ever run as root. Far too complex and completely unnecessary.
> "make all" as a normal user, and then if you absolutely must, "make install"
> as root. (After running "make -n install" first to see what it will do.)
Yes thats completely true, but it still leaves the point if you want
to manage some
of your config files with git.
bye
Stefan
--
http://www.dreamind.de/
Oroborus and Debian GNU/Linux Developer.
^ 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