Re: "git checkout" safety feature
Hi, > "git checkout " is a feature to overwrite local > changes. It is what you use when you make a mess editing the files > and want to go back to a known state. Why should that feature be > destroyed? Not destroyed, but optionally made finger-fumble-save – like "alias rm rm -i". -- -- Matthias Urlichs signature.asc Description: OpenPGP digital signature
"git checkout" obliterates not-yet-ignored files
Hi, the problem: suppose I decide that a local file should no longer be controlled by git. Thus I add it to .gitignore and then "git rm --cached" it. So far so good. However, if I subsequently modify that file and then go back to a commit that still contains it, my local changes will be obliterated. IMHO that's a bug – .gitignore should only be used for (not) adding non-version-controlled files. It does not tell git to ignore changes (in files that *are* under version control), and thus it should not allow any git command to simply overwrite a file. -- -- Matthias Urlichs signature.asc Description: OpenPGP digital signature
"git checkout" safety feature
Hi, A recent discussion on LWN https://lwn.net/Articles/770642/ noted that "git checkout " does not warn if one if the files has been modified locally, nor is there an option to do so. IMHO that should be fixed, preferably by somebody who knows git's internals well enough to do so in half an hour ;-) -- -- Matthias Urlichs signature.asc Description: OpenPGP digital signature
Re: Shallow clones with explicit history cutoff?
Hi, Duy Nguyen: On Thu, Aug 21, 2014 at 10:39 PM, Matthias Urlichs matth...@urlichs.de wrote: What I would like to have, instead, is a version of shallow cloning which cuts off not at a pre-determined depth, but at a given branch (or set of branches). In other words, given +-J--K (packaged) // +-F--G--HI(clean) / / A---B---C---D---E (upstream) a command git clone --shallow-until upstream $REPO (or however that would be named) would create a shallow git archive which contains branches packaged+clean, with commits FGHIJK. In contrast, with --single-branch and --depth 4 I would get CGHIJK, which isn't what I'd want. I would imagine a more generic mechanism git clone --shallow-rev=rev $REPO where you could pass anything that git rev-list can accept (maybe more restricted, and some verification required). --shallow-rev could be repeated. So in your case it could be git clone --shallow-rev=^A $REPO. Umm, no. ^E (or ^upstream) would do what I want. Hopefully. ;-) But you're right, that would fit far better into the existing git paradigms. As I have not spent too much time with the git sources lately (as in None at all), some pointers where to start implementing this would be appreciated, assuming (a) this has a reasonable chance of landing in git and (b) nobody beats me to it. ;-) I'd like to see this implemented. You are not the first one complaining about the (lack of) flexibility of --depth. If you have time, I may be able to support (I should not take on another topic given my many ongoing/unfinished topics). Welcome to the club. :-/ Thanks for the pointers. I'll see what I can do (and when). -- -- Matthias Urlichs -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Shallow clones with explicit history cutoff?
Hi, use case: I am packaging the FOO program for Debian. FOO is maintained in git but it has a bunch of problems (e.g. because somebody mistakenly checked in a huge blob which would give the ). The current workflow for this is to create a new branch, remove the offending bits if necessary, create a FOO-clean.tar.xz file, and ship that as original source. I find that to be suboptimal. What I would like to have, instead, is a version of shallow cloning which cuts off not at a pre-determined depth, but at a given branch (or set of branches). In other words, given +-J--K (packaged) // +-F--G--HI(clean) / / A---B---C---D---E (upstream) a command git clone --shallow-until upstream $REPO (or however that would be named) would create a shallow git archive which contains branches packaged+clean, with commits FGHIJK. In contrast, with --single-branch and --depth 4 I would get CGHIJK, which isn't what I'd want. As I have not spent too much time with the git sources lately (as in None at all), some pointers where to start implementing this would be appreciated, assuming (a) this has a reasonable chance of landing in git and (b) nobody beats me to it. ;-) -- -- Matthias Urlichs -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
SVN import issue
Hi,
I'm off to the beach for the next two weeks, so if somebody wants to
munge cvs2git into svn2git, here's the basics on how to pull from a
remote SVN repo:
#!/usr/bin/perl
use strict;
use warnings;
use SVN::Core;
use SVN::Ra;
my(@new,@del,@mod);
sub show_log {
my ($changed_paths, $revision, $author, $date, $message, $pool) = @_;
$author = 'unknown' unless defined $author;
@new = (); @del = (); @mod = ();
(my $pmessage = $message) =~ s/\n/\n/g;
print *** $revision: $author \@ $date:\n $pmessage\n;
print Files:\n;
while(my($path,$action) = each %$changed_paths) {
my $act = $action-action;
my $oldpath = $action-copyfrom_path;
my $oldrev = $action-copyfrom_rev;
$oldrev = undef if defined $oldrev and $oldrev = 0;
$oldpath = undef if defined $oldpath and ($oldpath eq or
$oldpath eq $path);
print $act $path;
print - if $oldpath or $oldrev;
print $oldpath if defined $oldpath;
print $oldrev if defined $oldrev;
print \n;
if($act eq A) {
push(@new,$path);
} elsif($act eq D) {
push(@del,$path);
} else {
push(@mod,$path);
}
}
}
my $ra = SVN::Ra-new(svn://cvs.gnupg.org/gnupg);
my $latest = $ra-get_latest_revnum();
my $n = 1;
while($n = $latest) {
$ra-get_log(/,$n,$n,$n,1,1,\show_log,);
foreach my $path(@new,@mod) {
print Reading $path, $n...\n;
open(F,/tmp/foo); # ( OK, so use tempfile() here ;-)
eval {
$ra-get_file($path,$n,\*F);
};
close(F);
if ($@) {
print ... not a file\n;
next;
}
my $sz = (stat(/tmp/foo))[7];
print ... done, $sz bytes\n.;
}
} continue {
$n++;
}
Paths in SVN are usually prefixed /trunk/ (main branch) or
/branches/foo/ (branch foo); tagging is done by creating /tags/bar,
with the trunk (or branch) revision it is pointing to as its parent.
So a branch point looks like this:
*** 350: unknown @ 1999-09-18T11:04:00.00Z:
This commit was manufactured by cvs2svn to create branch
'STABLE-BRANCH-1-0'.
Files:
A /branches/STABLE-BRANCH-1-0/cipher/rndw32.c - /trunk/cipher/rndw32.c 349
A /branches/STABLE-BRANCH-1-0 - /trunk 348
(and of *course* it may have changes from other revisions in it,
anything else would simply be too easy I guess...). Tags look like they
do, see tag 1-0-0 in the above repo; that seems to happen because their
CVS importer couldn't find a sane branchpoint. cvsps reports the same thing.
I haven't yet examined what a SVN merge looks like.
Nothing stops a SVN check-in from touching multiple branches at the same
time, though in practice that doesn't happen.
The mapping of SVN revision numbers to git SHA1s could get a bit
annoying because incremental imports need to work. Personally I'd use a
.svnmap file which has svnid sha1 lines inside. The last line
obviously would not have a sha1 because we can't know that before
checking in the file...
So, if I find a working SVN importer when I come back I'll be happy ;-)
(munging cvs2git shouldn't be particularly difficult), otherwise I'll do
it myself, in a month or so.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
I had been driving my car for 40 years when I fell asleep at the wheel and
had an accident.
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Looking at multiple ancestors in merge
Hi, Daniel Barkalow wrote:
My proposal is actually to detect when a merge is ambiguous. In order to
determine that, however, you have to evaluate multiple potential outcomes
and see if they are actually different. I'm working on an efficient way to
do that.
Good.
There's also a related problem which I've hit last month or so, where one
view has the same file (or at least one with the same name) added to both
sides of the branch, but the other view doesn't.
Unfortunately, that can happen to both branches independently, so you
really need to choose a merge base per file instead of globally. I suspect
that many of the problem cases simply go away when you do that.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Jones' Second Law:
The man who smiles when things go wrong has thought of someone
to blame it on.
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
SVN import
Quick note: I'm working on importing from SVN.
My current main problem is that SVN's Perl interface leaks server
connections (apparently nobody has used it for any real work yet),
which is of course *bad*, and kindof prevents me from finishing
the job today. :-/
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
I could certainly run a marvellous university here if only we didn't
have to have all these damn students underfoot all the time.
-- Terry Pratchett (Hogfather)
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git 1.0 Synopis (Draft v4)
Hi, Horst von Brand wrote:
And teach make(1) about checking out files from git... or just create a
co(1) command for git.
Ummm... why?
make's SCCS support depends on the presence of a SCCS/s.name file
for each name. We don't have that. Teaching make about git would be
equivalent to teaching it about parsing the index file.
Technically, that would require a stable libgit.so or so.
In reality, however, I don't know when I last had a tree which wasn't
fully populated, but it's been a while, and it's something that can be
readily fixed by git-checkout-cache -a.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
One possible reason that things aren't going according to plan
is that there never was a plan in the first place.
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Small team cogito/git setup
Hi, Martin Langhoff wrote:
Or are we forced to run an 'integration' repo so that we work with a
'star' arrangement? I am actually trying to avoid needing a central
repo if possible.
Personally, I like the idea of an integration repository. The main reason
is that it avoids duplicate work and shifting blame for broken software,
particularly if you have a test suite.
My workflow is develop, test, check-in, pull-and-merge, test-if-merged,
push. That tends to yield a saner change history, and requires less work,
than doing it for every co-worker.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Fundamentalists are like the fir trees in German forests: they cannot
stand alone, and are only stable when crowded together, branches locked
with those of their brothers. That is why we must always fear them,
because they will always hate us for our individualism.
[Brent Yaciw, with inspirational regards to Jack M. Bickham]
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Subject: [PATCH] Updates to glossary
Hi, Johannes Schindelin wrote:
Subject: Subject: [PATCH] Updates to glossary
Something is stuttering here -- one Subject: is quite sufficient.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Harris's Lament:
All the good ones are taken.
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gitk with hyperspace support
Hi, Paul Mackerras wrote:
http://ozlabs.org/~paulus/gitk/gitk.hs
Unfortunately, this fails on my git-plus-assorted-crap archive:
can't read mainlinearrow(c1a9ddb1e9f30029384bd687d90af5796a280283): no such
element in array
can't read mainlinearrow(c1a9ddb1e9f30029384bd687d90af5796a280283): no such
element in array
while executing
if {$mainlinearrow($id) ne none} {
set mainline($id) [trimdiagstart $mainline($id)]
}
(procedure drawcommitline line 44)
invoked from within
drawcommitline $dlevel
(procedure drawmore line 65)
invoked from within
drawmore 1
(procedure drawcommit line 33)
invoked from within
drawcommit $id
(procedure getcommitlines line 50)
invoked from within
getcommitlines file23
Another problem: when I click on a line, I get the parent and *all* its
children, not just the child(ren) on the other end of the segment I was
clicking on.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
There are some micro-organisms that exhibit characteristics of both plants
and animals. When exposed to light they undergo photosynthesis; and when
the lights go out, they turn into animals. But then again, don't we all?
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gitk with hyperspace support
Hi, Sean wrote:
The line flowing from this commit extends ~200 more commits downward
before it is finally terminated with an arrowhead. It would be nice if
this line could be made shorter, such that the arrowhead was drawn much
closer to commit in question.
Good point. The arrowheads tend to get lost otherwise; in my tree, the
problem is even worse since the downward-pointing arrow (drawn in grey) is
directly below a horizontal line connecting two unrelated changes -- which
is *also* grey. That makes the actual arrowhead perceptually invisible.
If the arrow appears directly below a node, you don't get that problem.
Another point I just noticed: The arrows should be directly below
each other, if at all possible; i.e. the one pointing up should be in the
same column as the corresponding arrow pointing down.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Money is the root of all evil, and man needs roots.
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add merge detection to git-cvsimport
Hi, Martin Langhoff wrote:
this one is the
most likely one to be from a bug in cvsps or the cvsimport logic.
That's not a bug in the import logic, just a failure of the CVS-merging
person to be consistent. (Which is hardly news. :-/ )
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Reason:
Bad, toxic entity, that foolish people use when they ought to use
their inner voice, or angels, or intuition, or a gut feeling, or
their hearts, or the I Ching.
-- Fashionable Dictionary (www.butterfliesandwheels.com)
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Switching heads and head vs branch after CVS import
Hi, Linus Torvalds wrote:
There may be some surprises in here! gitk --all shows at least one
branch opening and merging back into origin, and it has figured it out
correctly
Oh, wow. The new cvsimport is obviously being a hell of a lot smarter
than my original one was. Goodie.
Umm, actually, no, cvsimport doesn't do merges. Dunno where Martin got his
from, but it wasn't me. ;-)
Sven, Matthias, opinions? I've never used CVS keyword expansion, and
always felt it was pointless, but hey..
I have intentionally kept keyword expansion on when I wrote the code,
because matching up the files from CVS with files gathered from tarballs,
Debian repositories, and what-not, becomes a whole lot easier that way.
For me, that's a major use case, esp. with CVS getting confused about its
tags (as people haphazardly copy whole subtrees from one CVS repository
into a different one).
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
I hope you will find the courage to keep on living
despite the existence of this feature.
-- Richard Stallman
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH] Rewriting revs in place in push target repository
Hi, Chris Wedgwood wrote:
On Sat, Aug 13, 2005 at 11:47:25PM +0200, Petr Baudis wrote:
I think it does not in real setups, since thanks to O_RDWR the
file should be overwritten only when the write() happens.
Can a 41-byte write() be non-atomic in any real conditions?
if you journal metadata only you can see a file extended w/o having
the block flushed
??? but the file is *not* extended. Also, whether or not a block is
flushed should only matter if the machine crashes ..?
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
CONS [from LISP] 1. v. To add a new element to a list. 2. CONS UP:
v. To synthesize from smaller pieces: to cons up an example.
-- From the AI Hackers' Dictionary
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Debian packaging for 0.99.4
Hi,
Ryan Anderson:
#!/bin/sh
echo Don't get a git - use gt!
Ouch.
echo Don't get a git - use gt! 2
if at all.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
USENET would be a better laboratory if there were more labor and less oratory.
-- Elizabeth Haley
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Debian packaging for 0.99.4
Hi, Alan Chandler wrote:
Not sure I understand the proper use of dpkg-divert in Debian, but could
_this_ git-core package perhaps ask the user which set of the two
packages he wish to keep as git command and use dpkg-divert to change
the other to another name to some other name?
IIRC, that's against Policy too, because different users on the system
might have different expectations WRT which git is git.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
You have a strong appeal for members of the opposite sex.
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Debian packaging for 0.99.4
Hi,
David Lang:
after so many years of software development (and with the policy of never
having conflicting command names) what three letter combinations are still
avilable?
Lots.
I'm assuming that the much smaller pool of two letter commands was long
since exhausted, but if not what two letter commands are available?
Lots of them, I hope, but all of them obscure.
We even have 25 one-letter commands that are free. My /usr/bin/ only has
'w'. And if we run out, we could branch off into other alphabets;
unfortunately, not everybody has a quick way to type an ä. Or α. Or ૐ. ;-)
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
The hope that springs eternal
Springs right up your behind.
-- Ian Drury, This Is What We Find
signature.asc
Description: Digital signature
[PATCH] more Debian packaging fixes
git-tk should be architecture independent.
git-core forgot to depend on perl.
Signed-Off-By: Matthias Urlichs [EMAIL PROTECTED]
---
Hi,
Junio C Hamano:
Matthias Urlichs [EMAIL PROTECTED] writes:
- Split gitk off to its own package;
it needs tk installed, but nothing else does.
I just noticed from dpkg --info output that the generated
git-tk has Architecture: i386. Shouldn't it read all and
resulting package also named git-tk_${VERSION}_all.deb, instead
of whatever architecture I happened to build it?
True.
diff --git a/debian/changelog b/debian/changelog
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,6 +1,7 @@
git-core (0.99.5-0) unstable; urgency=low
* Split off gitk.
+- ... into an architecture-independent package.
-- Matthias Urlichs [EMAIL PROTECTED] Thu, 11 Aug 2005 01:43:24 +0200
diff --git a/debian/control b/debian/control
--- a/debian/control
+++ b/debian/control
@@ -7,7 +7,7 @@ Standards-Version: 3.6.1
Package: git-core
Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, patch, diff, rcs
+Depends: ${perl:Depends}, ${shlibs:Depends}, ${misc:Depends}, patch, diff, rcs
Recommends: rsync, curl, ssh, libmail-sendmail-perl, libemail-valid-perl
Conflicts: git
Description: The git content addressable filesystem
@@ -18,7 +18,7 @@ Description: The git content addressable
similar to other SCM tools.
Package: git-tk
-Architecture: any
+Architecture: all
Depends: ${shlibs:Depends}, ${misc:Depends}, git-core, tk8.4
Description: The git content addressable filesystem, GUI add-on
This package contains 'gitk', the git revision tree visualizer
diff --git a/debian/rules b/debian/rules
--- a/debian/rules
+++ b/debian/rules
@@ -65,33 +65,36 @@ install: build
dh_movefiles -p git-core
find debian/tmp -type d -o -print | sed -e 's/^/? /'
-binary: build install
+binary-arch: build install
dh_testdir
dh_testroot
- dh_installchangelogs
- dh_installdocs
- dh_installexamples
-# dh_installmenu
-# dh_installdebconf
-# dh_installlogrotate
-# dh_installemacsen
-# dh_installpam
-# dh_installmime
-# dh_installinit
-# dh_installcron
-# dh_installinfo
- dh_installman
- dh_link
- dh_strip
- dh_compress
- dh_fixperms
-# dh_perl
-# dh_python
- dh_makeshlibs
- dh_installdeb
- dh_shlibdeps
- dh_gencontrol
- dh_md5sums
- dh_builddeb
+ dh_installchangelogs -a
+ dh_installdocs -a
+ dh_strip -a
+ dh_compress -a
+ dh_fixperms -a
+ dh_perl -a
+ dh_makeshlibs -a
+ dh_installdeb -a
+ dh_shlibdeps -a
+ dh_gencontrol -a
+ dh_md5sums -a
+ dh_builddeb -a
+
+binary-indep: build install
+ dh_testdir
+ dh_testroot
+ dh_installchangelogs -i
+ dh_installdocs -i
+ dh_compress -i
+ dh_fixperms -i
+ dh_makeshlibs -i
+ dh_installdeb -i
+ dh_shlibdeps -i
+ dh_gencontrol -i
+ dh_md5sums -i
+ dh_builddeb -i
+
+binary: binary-arch binary-indep
.PHONY: build clean binary install clean debian-clean
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
GUBBISH [a portmanteau of garbage and rubbish?] n. Garbage; crap;
nonsense. What is all this gubbish?
-- From the AI Hackers' Dictionary
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] update Debian packaging for cogito
Cleaned up Debian files.
Conflict with cgvg instead of not installing cg.
Pass prefix=/usr to make install.
---
diff --git a/debian/changelog b/debian/changelog
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+cogito (0.13-1) stable; urgency=low
+
+ * New version.
+ * Cleaned up Debian files.
+ * Conflict with cgvg instead of not installing cg.
+ * Pass prefix=/usr to make install.
+
+ -- Matthias Urlichs [EMAIL PROTECTED] Thu, 11 Aug 2005 12:17:32 +0200
+
cogito (0.12.1-1) stable; urgency=low
* new version 0.12.1 (needed in order check out Linus' git trees).
diff --git a/debian/control b/debian/control
--- a/debian/control
+++ b/debian/control
@@ -9,7 +9,7 @@ Package: cogito
Architecture: any
Depends: git-core, ${shlibs:Depends}, patch, diff, rcs
Recommends: rsync, curl, wget, rsh-client
+Conflicts: cgvg
Description: version control system
Cogito is the user-friendly front-end to the GIT directory content
- manager. This package includes both the low-level GIT tools and the
- high-level Cogito programs.
+ manager. This package includes the high-level Cogito programs.
diff --git a/debian/copyright b/debian/copyright
--- a/debian/copyright
+++ b/debian/copyright
@@ -1,3 +1,24 @@
-License:
+This package was downloaded via git from
+master.kernel.org:/pub/scm/cogito/cogito.git.
+
+Upstream Author: Petr Baudis
+
+Copyright:
+
+ This package is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; version 2 dated June, 1991.
+
+ This package is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this package; if not, write to the Free Software
+ Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
+ 02111-1307, USA.
+
+On Debian GNU/Linux systems, the complete text of the GNU General
+Public License can be found in `/usr/share/common-licenses/GPL'.
-GPL v2 (see COPYING for details)
diff --git a/debian/docs b/debian/docs
--- a/debian/docs
+++ b/debian/docs
@@ -1,3 +1 @@
README
-COPYING
-
diff --git a/debian/rules b/debian/rules
--- a/debian/rules
+++ b/debian/rules
@@ -64,8 +64,8 @@ install: build
dh_testroot
dh_clean -k
dh_installdirs
- $(MAKE) install DESTDIR=$(CURDIR)/debian/cogito
- $(RM) $(DESTDIR)/usr/bin/cg
+ $(MAKE) install DESTDIR=$(CURDIR)/debian/cogito prefix=/usr
+ # $(RM) $(DESTDIR)/usr/bin/cg
install -m 0644 Documentation/*.html
$(DESTDIR)/usr/share/doc/cogito/html
install -m 0644 Documentation/cogito.txt
$(DESTDIR)/usr/share/doc/cogito/txt
install -m 0644 Documentation/*.7 $(DESTDIR)/usr/share/man/man7
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Wide flush the fields; the softening air is balm; Echo the mountains round;
the forest smiles; And every sense and every heart is joy.
-- Thomson
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Debian packaging for 0.99.4
Hi, Sebastian Kuzminsky wrote:
People still use GNU Interactive Tools. Not just crazy, stupid people,
and I bet not just Debian people.
Possibly. But the number of people running both git and git are, I'd bet,
smaller than those who will send annoying emails when they install git and
can't run all the git xxx commands we talk about here.
Same with cgvg, cogito, and cg.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
The girl who remembers her first kiss now has a daughter who can't even
remember her first husband.
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
gitk: integer overflow
Run gitk on the kernel archive, wait for it to finish reading commit
changesets, scroll to the middle, and watch all the pretty (NOT)
superfluous vertical lines appear and disappear pseudo-randomly.
Looks like something in there (TK or even X11, most likely) cuts off
screen coordinates after 16 bits ..?
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
You know things are bad when you're surrounded by four lawyers, and none of
them is yours.
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Debian packaging for 0.99.4
Hi,
Sam Ravnborg:
Anyway, enough of this. I understand the name will not change and I'm
ok with that. I'll deal with it on our (Debian's) end.
The easy fix is to kill the small git script that is not
mandatory anyway (as far as my quick grep told me).
I'd vote to keep the scripts in the default build, so that people
who like to compile their own package (i.e. everybody _except_ the
Debian packager ;-) get to keep their git and cg scripts.
A small Debian-specific patch to rename the offending scripts (and drop
the Conflicts: entries) is cheap.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Experience *that breathing.*
From books and words come fantasy,
and sometimes, from fantasy comes union. -- Rumi, tr. Coleman Barks
signature.asc
Description: Digital signature
Re: [PATCH] Debian packaging for 0.99.4
Hi,
Linus Torvalds:
Hands up people. Does anybody _use_ GNU interactive tools? None of this I
have a package crap.
You're preaching to the converted here.
The Debian-package-for-Debian could pop up a notice asking the user to
symlink /usr/local/bin/git = /usr/bin/gitscm (or whatever) if they
want to use the normal name... that's probably the only solution which
would work reasonably well without being too much hassle to implement.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
For the right person, the impossible is easy!
-- Dumbo
signature.asc
Description: Digital signature
Re: Request for help from binary packaging people.
Hi, Junio C Hamano wrote:
For Debian, we recommend lib*-*-perl packages. Do we need to recommend
perl itself as well, or is it the case that things that are covered with
the automatic dependency chain need not be listed?
No, yes. ;-)
What happens if the lib*-perl packages are not installed? If some scripts
break, that's a Bad Thing, and would require those packages to be moved to
Depends:.
Earlier I said that
the Debian side is reasonably accurate to the best of my knowledge, but I
would appreciate it if somebody ran lintian on it.
Will do.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
I say we take off; nuke the site from orbit. It's the only way to be sure.
- Corporal Hicks, in Aliens
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Debian packaging for 0.99.4
Debian packaging fixes for 0.99.4:
- Add a debian/changelog entry.
- Split gitk off to its own package;
it needs tk installed, but nothing else does.
- Refer to GPL properly, don't install COPYING.
- Fix maintainer.
- Use dh_movefiles instead of dh_install;
we don't want to list everything *except* gitk.
---
More Lintian warnings (not fixed by this patch):
W: git-core: binary-without-manpage git-LOTS
W: git-tk: binary-without-manpage gitk
Debian *really* dislikes exec tricks:
E: git-tk: shell-script-fails-syntax-check ./usr/bin/gitk
git-parse-remote is not an executable script and therefore
does *not* belong in /usr/bin:
W: git-core: executable-not-elf-or-script ./usr/bin/git-parse-remote
Do we need any newer features of diff? If not = drop from Depends:.
E: git-core: depends-on-essential-package-without-using-version depends: diff
---
diff --git a/debian/changelog b/debian/changelog
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+git-core (0.99.4-1) unstable; urgency=low
+
+ * Lots and lots of changes.
+
+ -- Matthias Urlichs [EMAIL PROTECTED] Wed, 10 Aug 2005 23:18:34 +0200
+
git-core (0.99-2) unstable; urgency=low
* Conflict with the GNU Interactive Tools package, which also installs
diff --git a/debian/control b/debian/control
--- a/debian/control
+++ b/debian/control
@@ -1,7 +1,7 @@
Source: git-core
Section: devel
Priority: optional
-Maintainer: Linus Torvalds [EMAIL PROTECTED]
+Maintainer: Junio C Hamano [EMAIL PROTECTED]
Build-Depends-Indep: libz-dev, libssl-dev, libcurl3-dev, asciidoc 6.0.3,
xmlto, debhelper (= 4.0.0)
Standards-Version: 3.6.1
@@ -15,5 +15,11 @@ Description: The git content addressable
and flexible filesystem-based database designed to store directory trees
with regard to their history. The top layer is a SCM-like tool which
enables human beings to work with the database in a manner to a degree
- similar to other SCM tools (like CVS, BitKeeper or Monotone).
+ similar to other SCM tools.
+
+Package: git-tk
+Architecture: any
+Depends: ${shlibs:Depends}, ${misc:Depends}, git-core, tk8.4
+Description: The git content addressable filesystem, GUI add-on
+ This package contains 'gitk', the git revision tree visualizer
diff --git a/debian/copyright b/debian/copyright
--- a/debian/copyright
+++ b/debian/copyright
@@ -1,3 +1,19 @@
-License:
+This package was downloaded from ftp.kernel.org:/INSERT_PATH_HERE
-GPL v2 (see COPYING for details)
+Upstream Author: Linus Torvalds and many others
+
+Copyright:
+
+ Copyright 2005, Linus Torvalds and others.
+
+ This file is free software; as a special exception the author gives
+ unlimited permission to copy and/or distribute it, with or without
+ modifications, as long as this notice is preserved.
+
+ This file is distributed in the hope that it will be useful, but
+ WITHOUT ANY WARRANTY, to the extent permitted by law; without even the
+ implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+
+This program is free-software released under the terms of the GNU Public
+License, version 2.0. Please check /usr/share/common-licenses/GPL for
+more information.
diff --git a/debian/docs b/debian/docs
--- a/debian/docs
+++ b/debian/docs
@@ -1,3 +1 @@
README
-COPYING
-
diff --git a/debian/git-core.files b/debian/git-core.files
new file mode 100644
--- /dev/null
+++ b/debian/git-core.files
@@ -0,0 +1 @@
+/usr
diff --git a/debian/git-core.install b/debian/git-core.install
deleted file mode 100644
--- a/debian/git-core.install
+++ /dev/null
@@ -1 +0,0 @@
-*
diff --git a/debian/git-tk.files b/debian/git-tk.files
new file mode 100644
--- /dev/null
+++ b/debian/git-tk.files
@@ -0,0 +1 @@
+/usr/bin/gitk
diff --git a/debian/rules b/debian/rules
--- a/debian/rules
+++ b/debian/rules
@@ -61,7 +61,9 @@ install: build
mkdir -p $(DOC_DESTDIR)
find $(DOC) '(' -name '*.txt' -o -name '*.html' ')' -exec install {}
$(DOC_DESTDIR) ';'
- dh_install --list-missing --sourcedir=$(DESTDIR)
+ dh_movefiles -p git-tk
+ dh_movefiles -p git-core
+ find debian/tmp -type d -o -print | sed -e 's/^/? /'
binary: build install
dh_testdir
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Any false value is gonna be fairly boring in Perl, mathematicians
notwithstanding.
-- Larry Wall in [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Debian packaging for 0.99.4
Hi,
Martin Langhoff:
On 8/11/05, Matthias Urlichs [EMAIL PROTECTED] wrote:
Debian packaging fixes for 0.99.4:
Is this anywhere in the archive?
Cogito 0.12.1 (which includes git) has been packaged by Sebastian
Kuzminsky [EMAIL PROTECTED]; it's in Debian Unstable. I assume
he'll do something about packaging the current version; I just filed a
wishlist bug in Debian.
The current cogito package in Debian renames both the git and cg
command line programs because there are already packages with conflicting
commands in Debian (git and cgvg). I consider that to be a mistake,
to be honest.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Coding is easy. All you do is sit staring at a terminal
until the drops of blood form on your forehead.
signature.asc
Description: Digital signature
Re: [PATCH 1/3] Add git-send-email-script - tool to send emails from git-format-patch-script
Hi, Ryan Anderson wrote:
Since these emails are sent *very* fast, delivery order tends to be the
dominating factor in how they sort in your inbox, as they will all have
the same time. So that's a trifle annoying.
That's trivially fixable: just generate your own Date: header and
add a second for each email.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Be careful whilst playing under the anvil tree.
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] Add git-send-email-script - tool to send emails from git-format-patch-script
Hi, Junio C Hamano wrote:
Also, I wonder if running lc() to downcase the local-part[*] is
safe/allowed/correct
mostly/no/no.
It's unlikely to be a real-life problem, but we still shouldn't do it.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Amusements to virtue are like breezes of air to the flame -- gentle ones will
fan it, but strong ones will put it out.
-- David Thomas
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] Add git-send-email-script - tool to send emails from git-format-patch-script
Hi, Ryan Anderson wrote:
And yes, I did generate this thread with this script - so I have proof
that it works nicely.
It might make sense to create a Patch 0/N with a short explanation, and
have the actual patches be replies to that -- or to patch 1/N if that's
not necessary.
As it is, patch N hangs off patch N-1 in my email threading view, which
gets slightly cumbersome if N10.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Nothing makes a person more productive than the last minute.
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Unify usage strings declaration
Hi, Junio C Hamano wrote:
I do not have preference either way, and I've already merged
them, but why char[] not char*?
A char* is a variable which points to the char[].
That's four (or eight) bytes we don't need. ;-)
C conflates the two concepts somewhat, which is one of the reasons
optimizing compiled C is somewhat more challenging than, say, FORTRAN.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Giving every man a vote has no more made men wise
and free than Christianity has made them good.
-- H.L. Mencken
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Teach parse_commit_buffer about grafting.
Hi, Junio C Hamano wrote:
Introduce a new file $GIT_DIR/info/grafts
Nice work.
Has anybody git-imported the old tarfile+patch history yet?
If not, I'll do it over the weekend.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Whatever occurs from love is always beyond good and evil.
-- Friedrich Nietzsche
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] extending git-ls-files --exclude.
Hi,
Petr Baudis:
Dear diary, on Thu, Jul 28, 2005 at 09:25:45PM CEST, I got a letter
where Matthias Urlichs [EMAIL PROTECTED] told me that...
Hi, A Large Angry SCM wrote:
So you're arguing for last match wins versus first match wins. I,
personally, find the former more natural and easier to debug by hand.
You know, up until five minutes ago, I thought so too.
So is the Large Angry SCM agreeing with me or not? I wrote long reply to
his mail, then reread what he wrote again, and decided that he is
_agreeing_ with me and you that last match wins is better. :-)
Bah, I misparsed his sentence (I read former as first wins), otherwise
my reply would have been worded slightly differently.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
All these black people are screwing up my democracy. - Ian Smith
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] document git-rev-list better
Document new (and not-so-new) flags of git-rev-list. Signed-off-By: Matthias Urlichs [EMAIL PROTECTED] --- diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt --- a/Documentation/git-rev-list.txt +++ b/Documentation/git-rev-list.txt @@ -9,14 +9,35 @@ git-rev-list - Lists commit objects in r SYNOPSIS -'git-rev-list' [ *--max-count*=number ] [ *--max-age*=timestamp ] [ *--min-age*=timestamp ] [ *--merge-order* [ *--show-breaks* ] ] commit +'git-rev-list' [ *--max-count*=number ] [ *--max-age*=timestamp ] [ *--min-age*=timestamp ] [ *--bisect* ] [ *--pretty* ] [ *--objects* ] [ *--merge-order* [ *--show-breaks* ] ] commit [ commit ...] [ ^commit ...] DESCRIPTION --- Lists commit objects in reverse chronological order starting at the -given commit, taking ancestry relationship into account. This is +given commit(s), taking ancestry relationship into account. This is useful to produce human-readable log output. +Commits which are stated with a preceding '^' cause listing to stop at +that point. Their parents are implied. git-rev-list foo bar ^baz thus +means list all the commits which are included in 'foo' and 'bar', but +not in 'baz'. + +If *--pretty* is specified, print the contents of the commit changesets +in human-readable form. + +The *--objects* flag causes 'git-rev-list' to print the object IDs of +any object referenced by the listed commits. 'git-rev-list --objects foo +^bar' thus means send me all object IDs which I need to download if +I have the commit object 'bar', but not 'foo'. + +The *--bisect* flag limits output to the one commit object which is +roughly halfway between the included and excluded commits. Thus, +if git-rev-list --bisect foo ^bar ^baz outputs 'midpoint', the output +of git-rev-list foo ^midpoint and git-rev-list midpoint ^bar ^baz +would be of roughly the same length. Finding the change which introduces +a regression is thus reduced to a binary search: repeatedly generate and +test new 'midpoint's until the commit chain is of length one. + If *--merge-order* is specified, the commit history is decomposed into a unique sequence of minimal, non-linear epochs and maximal, linear epochs. Non-linear epochs are then linearised by sorting them into merge order, which - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
Hi, Junio C Hamano wrote:
Porcelain can keep track of
mapping between b00:b24 for you,
Exactly.
but you still need to keep
track of b00:XYZ and b24:XYZ mapping in your head.
This is why I name my local branch XYZ. ;-)
XYZ may not be an appropriate name for the remote branch, or maybe the
remote repo is *not* under my direct control, e.g. a shared-master style
setup.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
:munch: vt. [often confused with {mung}, q.v.] To transform information
in a serial fashion, often requiring large amounts of computation. To
trace down a data structure. Related to {crunch} and nearly synonymous
with {grovel}, but connotes less pain.
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] Recursive Make considered harmful
Hi, Junio C Hamano wrote:
The Debian build is not affected because it does not produce
separate git-core and doc-git-core packages[*1*]; probably this
was the reason you did not notice this.
git-core-doc, actually.
Debian does that only if the documentation is substantial. Even then,
manpages may not be segregated into -doc.
However, I *would* segregate gitk into its own Debian package, because
it requires wish et al., which would pull a large chunk of X11 stuff,
which people may not want on their server.
Patch follows separately -- I'll have to pull it from my other mess
(which includes yet another Debian package for Cogito ;-).
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
A zealot's stones will break my bones, but gods will never hurt me.
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] extending git-ls-files --exclude.
Hi, A Large Angry SCM wrote:
So you're arguing for last match wins versus first match wins. I,
personally, find the former more natural and easier to debug by hand.
You know, up until five minutes ago, I thought so too.
However ... as a human being, I liik for meaning, not for processing
instructions. Thus, reading the list top-down, this
*.html
!f*.html
fo*.html
makes perfect sense to me. (Throw away the HTML files. Well, except for
those that start with 'f'. Well, *except* for foobar.html or whatever.)
The other way round, however, the sequence
fo*.html
!f*.html
*.html
is not immediately understandable in one pass, as the second line makes no
sense whatsoever without the third one. (Throw away foobar.html. Umm,
we're keeping everything anyway, so why ... oh, HTML files are junked, OK,
so ... now ... umm, what did I want to find out in the first place?)
It gets even more confusing when you're lazy and omit the .html suffix in
the second line.
YMMV, and all that.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
(It is an old Debian tradition to leave at least twice a year ...)
-- Sven Rudolph
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
Hi, Petr Baudis wrote:
If you fear making mistakes, better use something which attempts to do
some babysitting for you, like Cogito. ;-)
Some babysitting needs to be part of the core push protocol; anything else
would be prone to race conditions in a multiuser setting, esp. when people
use different porcelains.
At minimum, you'd send the old branch head with the new one, and let the
server not overwrite it if it changed in the meantime.
Then, you'd kill porcelain writers who don't verify that the old head is
a(n indirect) parent of the new one. ;-)
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Madness takes its toll. Please have exact change.
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problems Importing a CVS tree into FAUmachine
Hi,
Thomas Glanzmann:
Members:
lib/pattern-matcher/input/Pic0.ppm:INITIAL-1.1
lib/pattern-matcher/input/Pic1.ppm:INITIAL-1.1
lib/pattern-matcher/input/Pic2.ppm:INITIAL-1.1
lib/pattern-matcher/input/Pic3.ppm:INITIAL-1.1
If there's no lib/pattern-matcher/input/Pic0.ppm,v nor
lib/pattern-matcher/input/Attic/Pic0.ppm,v file ...
But I see the PatchSet if I run cvsps manually. Very strange.
... then, congratulations, you've found a bug in cvsps.
Please talk to its author.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
I believe that the moment is near when by a procedure of active paranoiac
thought, it will be possible to systematize confusion and contribute to the
total discrediting of the world of reality.
-- Salvador Dali
signature.asc
Description: Digital signature
Re: [PATCH] git-cvsimport-script: parse multidigit revisions
Hi,
Linus Torvalds:
In particular, they always end up being imported as zero-sized empty
files, and will be filled in only later if that file is ever touched
again. In other words, the resulting git tree ends up being bogus.
That's a problem with the bkcvs tree. Remember tht Bitkeeper does
exactly the same thing -- the 1.0 version of *any* file is empty, and
content appears only in version 1.1.
Well, the bkcvs export preserved that ... feature.
(Side question - why aren't you doing a direct bk2git import?)
Argument 28213 has collisions isn't numeric in addition (+) at
/home/torvalds/bin/git-cvsimport-script line 600, CVS line 1.
That's an output from cvsps that is not handled yet.
If you really need it I'll have to investigate.
Btw, looking at what the perl script _seems_ to do, it does seem to do
insane things for the local CVS archive case. As far as I can tell from
the spaghetti that is perl, it uses a CVS server to handle even the local
file case, which just _can't_ be right.
Sure it is, because ...
I realize you'd want to do that to
avoid connecting millions of times, but maybe it's better to use something
like cvsnup to download the whole thing, and then always use a local CVS
archive?
... I don't have a sensible RCS library for perl (the code that I could
find is just a command line front-end). Fork+exec of some cvs checkout
command per file is slower than just running a persistent CVS server.
I've tried other ideas, but they run into problems because some
idiots^Wpeople occasionally tag only parts of a CVS tree, or they do it
at different times, and cvsps has to rearrange stuff in a way the CVS
utilities don't understand, so any higher-level access than grab a
bunch of files by their revision number and stick them into a commit
don't work in real life.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Please try to limit the amount of this room doesn't have any bazingas
until you are told that those rooms are punched out. Once punched out,
we have a right to complain about atrocities, missing bazingas, and such.
-- N. Meyrowitz
signature.asc
Description: Digital signature
Re: git cvsimport with branches?
Hi, Wolfgang Denk wrote:
Is there a way to make git cvsimport create branches in git for any
branches it encounters in the CVS repository?
That's what it does.
All my imports so far show just a linear line of development, and CVS
branch information seems lost.
Umm, exactly what did you do to visualize that? gitk origin obvioously
shows only one branch, because CVS doesn't have merge infe. Use
gitk $(cat .git/revs/heads/*) to show everything.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Any body of men who believe in hell will
persecute whenever they have the power.
[Joseph McCabe, What Gods Cost Men]
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Patch to make README more newbie-friendly
Hi, Jerry Seutter wrote:
I'd also like to include stuff about branches, but I haven't gotten my
head wrapped around how they work yet. cg-branch-add expects a location
after the branch name and I'm not sure what to give it.
Cogito branch creation is based on the idea that you have a different
archive _somewhere_else_ that you pull from, so it wants to store the
source URL in .git/branches/name.
Git doesn't have that assumption; git checkout -b name simply
creates a new branch and switches to it. However, the git branch idea came
somewhat later, so there's a bit of a mismatch at the moment.
Simply switching branches isn't supposed to have any effect unless you
actually have changes in different branches. I tend to work along these
lines:
#!/bin/sh
cd /tmp
rm -rf test.$$
mkdir test.$$
cd test.$$
git-init-db
echo not-quite-empty testfile
cg-add testfile
echo Created test | cg-commit
git checkout -b one
echo foo testfile
echo added foo to testfile | cg-commit
git checkout -b two master
echo bar testfile
echo added bar to testfile | cg-commit
cg-diff -r one:two | cat
git checkout master
cg-merge one
cg-merge two
The first merge fast-forwards your master tree to one; the second
creates a conflict (lines were added at the same location) which you'll
have to resolve (edit the file).
vi testfile
echo Merged one and two | cg-commit
gitk
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Apollo, the God of light, of reason, of proportion, harmony, number --
Apollo blinds those who press too close in worship. Don't look straight
at the sun. Go into a dark bar and have a beer with Dionysos, every now
and then. -- Ursula K. LeGuin
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-diff-*: Allow --name-only -z as alias for --name-only-z
Hi,
Junio C Hamano:
I've considered it, but what happens if you give -z first and
then name-only?
Exactly the same thing as vice versa.
Or, even more exactly, my patch *makes* that happen. ;-)
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Isn't this a beautiful day! Just watch some bastard louse it up.
signature.asc
Description: Digital signature
Re: [PATCH] git-diff-*: Allow --name-only -z as alias for --name-only-z
Hi,
Junio C Hamano:
That said, I have been hating that diff options parsing for
quite a while, and I've been thinking about cleaning it up along
the lines I'll outline here, but have not done anything about
it. Care to help me out?
I saw the problem...
Hmm?
Sure -- assuming I find some time to actually do it over the next few days.
The problem is that this has been a problem lately. :-/
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Illiterate? Write today, for free help!
signature.asc
Description: Digital signature
Re: [RFC PATCH] cogito --- don't overwrite metadata files in place (breaks CoW use)
Hi, Chris Wedgwood wrote:
Symlink'd trees don't really make sense to me (they seem fragile and
somewhat pointless) but perhaps I'm missing something?
You are ;-) the tree itsels is no symlinked, but HEAD points to
refs/heads/branch by default.
Don't clobber that, please.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Though many hands make light work, too many cooks spoil the broth.
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Is cogito really this inefficient
Hi, Russell King wrote:
This says it all. 1min 22secs to generate a patch from a locally
modified but uncommitted file.
I only get that when the index is out-of-date WRT the file modification
dates, so cg-diff has to examine every file.
The good news is that the index is being updated as it finds that the
files are in sync, so expect this to be significantly faster the next time
around.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Praise the sea; on shore remain.
-- John Florio
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] cogito --- don't overwrite metadata files in place (breaks CoW use)
Hi,
Chris Wedgwood:
How about the following?
Ummm...
local NLINK=`readlink $DEST`
if [ ! -e $NLINK ] ; then
You lose if the link is relative and the symlink is not in the current
directory. You also lose on systems where the empty filename is
synonymous with the current directory.
You'd need to do something along the lines of
if [ -n $NLINK ] ; then
case $NLINK in
/*) ;;
*) NLINK=$(dirname $DEST)/$NLINK ;;
esac
fi
first.
# dangling link, just poke as-is
echo $1 $DEST
You should remove DEST first. Otherwise, under Linux, you'll magically
create the file the symlink points to, which may not be what you want to
do.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Custom does often reason overrule And only serves for reason to the fool.
-- John Wilmot, Earl of Rochester
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to get a directory filled with v2.6.11?
Hi, Marc Singer wrote:
v2.6.11, 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c
You can create your own parent-less commit for that tree.
(It's what I did...)
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
It was the most earnest ambition I ever hadNot that I ever
really wanted to be a preacher, but because it never occurred to
me that a preacher could be damned. It looked like a safe job.
[Mark Twain, a Biography]
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] git-gnu-progs-Makefile: git Makefile update
Hi, Linus Torvalds wrote:
I also don't see why, if OS-X already _does_ include the GNU tools, they
couldn't be under /opt/fsf/bin or something like that, and then you could
just do
PATH=/opt/fsf/bin:$PATH
We could prepend /usr/lib/git to $PATH, and symlink them with their real
names there.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Go directly to jail. Do not pass Go, do not collect $200.
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bootstrapping into git, commit gripes at me
Hi, Junio C Hamano wrote:
Having said that, I do like the concept of keeping track of
which development line are we on, and what's most recent in
it. The way I read your description of cg-seek, you currently
have that information is either in .git/head-name and
.git/refs/heads/head-name pair (when .git/head-name exists),
or .git/HEAD.
Personally, I'd rather have as few invariants as possible, so that various
Porcelains can agree on semantics.
What I would expect from a sane .git tree is that
* .git/HEAD contains the commit that is currently checked out.
* If HEAD is not a symlink, then switching to a branch HEAD is not a part
of should emit a warning.
(fsck to find the dangling commits is not an answer ;-)
Ideas like
* remember the branch to un-seek back to
or
* treat HEAD as read-only when there's a seek active
seem to be optional / Porcelain-specific.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
We'll strategically withdraw to previously prepared position.
Who prepared them?
we'll prepare them when we get there.
-- Terry Pratchett (Reaper Man)
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cvsimport: rewritten in Perl
Hi,
Sven Verdoolaege:
to get an idea of what the files may be. Looks like the new perl version
is leaking file descriptors..
Matthias?
That was my mistake, actually.
Thanks for spotting this.
Ouch. For me, the main danger of lots of Python programming is that
I tend not to see this kind of problem any more, because in Python it
Simply Doesn't Happen.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Conscience is the inner voice that warns us somebody is looking
-- H. L. Mencken
signature.asc
Description: Digital signature
Re: Tags
Hi, Junio C Hamano wrote:
I wanted to have something like this in the past for some reason
I do not exactly remember anymore, but basically it was to
record here is the list of related objects.
One use I'd have for that is regression testing -- collect all IDs in one
bag and then say gitk bad ^good.
OTOH, I dunno whether the core tools really need to understand that.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
If at first you don't succeed, you must be a programmer.
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Merging and parents
I just had this ugly merge situation:
M
|\
| \
A B
|\/|
|/\|
C D
| /
|/
E
Suppose both the EC and the ED branch add files (not with conflicting
filenames!) which then get modified somewhere between C/D and M.
No matter which node gets picked as the parent, some files will end
up as created on different branches because the chosen parent doesn't
have them, even though, strictly speaking, it ain't so.
So ... what to do? Generate a list of parents, and for each file pick the
one parent where it (a) exists and (b) has the smallest diff?
Or just ignore (umm... OK, document) the problem?
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
I'm thankful I didn't believe in God, because it
would have been another thing for me to conquer.
-- Kim Goldman
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cvsimport: rewritten in Perl
Hi,
Sven Verdoolaege:
Why not an explicit '-z' option as in the current git-cvsimport-script ?
Because my code doesn't support compressed cvs connections:
a -z that doesn't work except for the rlog part would be a lie.
Feel free to add that code. ;-)
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Confidence is simply that quiet, assured feeling you have before you
fall flat on your face.
signature.asc
Description: Digital signature
[PATCH] Add DEST Makefile variable
This patch changes the Makefile to add a DEST variable (still defaulting to ~/bin/) so that people (or scripts) can trivially install git Somewhere Else. Signed-Off-By: Matthias Urlichs [EMAIL PROTECTED] --- 42a073eb6b5bb397a3e8768a032463a7fa02e6b9/Makefile (mode:100644 sha1:1fef8e4ae93b2abae2ceb69c265c7c8176fe44c0) +++ 265515f9c4f089b1b61e9d2312c4b3babe189618/Makefile (mode:100644 sha1:af90bd4e1d53fa3b930c77a240b4681a0b2a886e) @@ -8,6 +8,7 @@ # break unless your underlying filesystem supports those sub-second times # (my ext3 doesn't). CFLAGS=-g -O3 -Wall +DEST=$(HOME)/bin CC=gcc AR=ar @@ -56,7 +57,7 @@ @chmod +x $@ install: $(PROG) $(GEN_SCRIPT) - install $(PROG) $(SCRIPT) $(GEN_SCRIPT) $(HOME)/bin/ + install $(PROG) $(SCRIPT) $(GEN_SCRIPT) $(DEST)/ clean: rm -f *.o $(PROG) $(GEN_SCRIPT) $(LIB_FILE) - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Missing linefeeds
This patch fixes die() and error() to print linefeeds after the message. Signed-Off-By: Matthias Urlichs [EMAIL PROTECTED] --- 42a073eb6b5bb397a3e8768a032463a7fa02e6b9/usage.c (mode:100644 sha1:e774d2ef32726af0707d817cdb63fc8751ddc9d8) +++ 265515f9c4f089b1b61e9d2312c4b3babe189618/usage.c (mode:100644 sha1:21715d88b1a82aa06a3914e3f0e69fb1b61cc442) @@ -26,6 +26,7 @@ va_start(params, err); report(fatal: , err, params); va_end(params); + fputs(\n, stderr); exit(1); } @@ -36,5 +37,6 @@ va_start(params, err); report(error: , err, params); va_end(params); + fputs(\n, stderr); return -1; } - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Missing quotes
gitXnormid.sh should quote its cat-file calls so that nonexisting ssha1 IDs don't result in shell errors. Signed-Off-By: Matthias Urlichs [EMAIL PROTECTED] --- 42a073eb6b5bb397a3e8768a032463a7fa02e6b9/gitXnormid.sh (mode:100755 sha1:c0d53afabe8662ebfc3c697faf08b0a2b43c93f7) +++ 265515f9c4f089b1b61e9d2312c4b3babe189618/gitXnormid.sh (mode:100644 sha1:94710a7a2ab945f1fbd5350cb0de15171ae3f582) @@ -41,11 +41,11 @@ exit 1 fi -if [ $type = tree ] [ $(cat-file -t $id) = commit ]; then +if [ $type = tree ] [ $(cat-file -t $id) = commit ]; then id=$(cat-file commit $id | egrep $TREE | cut -d ' ' -f 2) fi -if [ $(cat-file -t $id) != $type ]; then +if [ $(cat-file -t $id) != $type ]; then echo Invalid id: $id 2 exit 1 fi - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Add git push
This patch adds the ability to git push, as the obvious converse of
git pull.
Signed-Off-By: Matthias Urlichs [EMAIL PROTECTED]
Index: git
===
--- 42a073eb6b5bb397a3e8768a032463a7fa02e6b9/git (mode:100755
sha1:557122dfb05580e4af2c55767f3d6f92b9110edd)
+++ 265515f9c4f089b1b61e9d2312c4b3babe189618/git (mode:100644
sha1:c32ee037c4dd68f8fa6723cb115644d46810bc89)
@@ -42,6 +42,7 @@
merge [-c] [-b BASE_ID] FROM_ID
patch [COMMIT_ID]
pull[RNAME]
+ push[RNAME]
rm FILE...
seek[COMMIT_ID]
status
@@ -86,6 +87,7 @@
lsremote) gitlsremote.sh $@;;
merge) gitmerge.sh $@;;
pull) gitpull.sh $@;;
+push) gitpush.sh $@;;
patch) gitpatch.sh $@;;
rm) gitrm.sh $@;;
seek) gitseek.sh $@;;
--- /dev/null (tree:42a073eb6b5bb397a3e8768a032463a7fa02e6b9)
+++ 265515f9c4f089b1b61e9d2312c4b3babe189618/gitpush.sh (mode:100644
sha1:0a658141991c602ca327edb9ab982d7660d7c665)
@@ -0,0 +1,59 @@
+#!/bin/sh
+#
+# Pushes changes from the local GIT repository to remote.
+# Copyright (c) Matthias Urlichs, 2005
+#
+# Takes the remote's name.
+
+name=$1
+
+die () {
+ echo gitpush.sh: $@ 2
+ exit 1
+}
+
+
+[ $name ] || name=$(cat .git/tracking 2/dev/null)
+[ $name ] || die where to push to?
+uri=$(grep $(echo -e ^$name\t | sed 's/\./\\./g') .git/remotes | cut -f 2)
+[ $uri ] || die unknown remote
+
+
+tracking=
+[ -s .git/tracking ] tracking=$(cat .git/tracking)
+
+orig_head=
+if [ $tracking = $name ]; then
+ [ -s .git/HEAD.tracked ] orig_head=$(cat .git/HEAD.tracked)
+else
+ [ -s .git/heads/$name ] orig_head=$(cat .git/heads/$name)
+fi
+
+rsync $RSYNC_FLAGS -Lr $uri/HEAD .git/HEAD_$name
+$id=$(cat .git/HEAD_$name)
+rm .git/HEAD_$name
+
+if [ -z $id ] ; then
+ echo The remote system doesn't have a HEAD file: Doing an initial
upload. 2
+ echo . 2
+elif [ $(cat-file -t $id) != commit ]; then
+ echo The remote system has stuff we don't have: pull first! 2
+ echo Commit ID: $id 2
+ exit 1
+fi
+
+# We already saw the MOTD, thank you very much.
+rsync $RSYNC_FLAGS --ignore-existing --whole-file \
+ -v -r .git/objects $uri | grep -v '^MOTD:'
+
+# FIXME: Warn about conflicting tag names?
+rsync $RSYNC_FLAGS --ignore-existing \
+ -v -r .git/tags $uri 2/dev/null | grep -v '^MOTD:'
+
+# Finally, update the remote HEAD
+rsync $RSYNC_FLAGS -Lr .git/HEAD $uri/HEAD \
+ 2/dev/null | grep -v '^MOTD:'
+
+echo Now up to date.
+exit
+
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Improve usage messages
This patch adds somewhat-improved usage messages to some of Linus' programs.
Specifically, they now handle -? / --help.
Signed-Off-By: Matthias Urlichs [EMAIL PROTECTED]
Index: check-files.c
===
--- 42a073eb6b5bb397a3e8768a032463a7fa02e6b9/check-files.c (mode:100644
sha1:7d16691aa9d51b5b4670d5837b3527ee7c7da79c)
+++ 265515f9c4f089b1b61e9d2312c4b3babe189618/check-files.c (mode:100644
sha1:be904b13659a60eab31787b010a64f2274048a9f)
@@ -40,6 +40,8 @@
{
int i;
+ if(argc == 2 (!strcmp(argv[1],-?) || !strcmp(argv[1],--help)))
+ usage(check-files filename...);
read_cache();
for (i = 1; i argc ; i++)
check_file(argv[i]);
Index: diff-tree.c
===
--- 42a073eb6b5bb397a3e8768a032463a7fa02e6b9/diff-tree.c (mode:100644
sha1:b0122e42631410fa579115f025efc3cab777cde6)
+++ 265515f9c4f089b1b61e9d2312c4b3babe189618/diff-tree.c (mode:100644
sha1:03fcc2fae2f0b06f3834f0b6e0d8762e70f49f51)
@@ -193,6 +193,11 @@
}
}
+static const char diff_tree_usage[] =
+ diff-tree [ -r (recurse) | -z (\\0-terminate) ]
+ \n\ttree sha1 tree sha1;
+
+
int main(int argc, char **argv)
{
unsigned char old[20], new[20];
@@ -209,11 +214,11 @@
line_termination = '\0';
continue;
}
- usage(diff-tree [-r] [-z] tree sha1 tree sha1);
+ usage(diff_tree_usage);
}
if (argc != 3 || get_sha1_hex(argv[1], old) || get_sha1_hex(argv[2],
new))
- usage(diff-tree [-r] [-z] tree sha1 tree sha1);
+ usage(diff_tree_usage);
commit_to_tree(old);
commit_to_tree(new);
return diff_tree_sha1(old, new, );
--- 42a073eb6b5bb397a3e8768a032463a7fa02e6b9/init-db.c (mode:100644
sha1:dad06351ca35d0d2f68cd9e719c49805386f96fa)
+++ 265515f9c4f089b1b61e9d2312c4b3babe189618/init-db.c (mode:100644
sha1:4afd436e719b347cdf6b4420c9d926e453f1f95b)
@@ -26,6 +26,9 @@
char *sha1_dir, *path;
int len, i;
+ if(argc != 1)
+ usage(init-db);
+
safe_create_dir(.git);
sha1_dir = getenv(DB_ENVIRONMENT);
--- 42a073eb6b5bb397a3e8768a032463a7fa02e6b9/write-tree.c (mode:100644
sha1:827809dbddbff6dd8cf842641f6db5ad2f3ae07a)
+++ 265515f9c4f089b1b61e9d2312c4b3babe189618/write-tree.c (mode:100644
sha1:55fe1c75c3065c8d5bef34f4f2e7af7aa147ea9d)
@@ -101,9 +101,13 @@
int main(int argc, char **argv)
{
int i, unmerged;
- int entries = read_cache();
+ int entries;
unsigned char sha1[20];
+ if(argc != 1)
+ usage(write-tree);
+
+ entries = read_cache();
if (entries = 0)
die(write-tree: no cache contents to write);
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Switching between branches
Hi, Petr Baudis wrote: Hello, Perhaps it's a naive question, but how do I switch between branches? I mean an equivalent of svn switch or cvs update -r branch that would reuse the existing working directory. you can't. There was 'git update' (and intermediate never-committed 'git switch'), but I decided not to support it for now, since I don't have any compelling usage case for it. I do -- I have a project which builds several slightly-customized versions, and I'd like to keep the generated objects around if possible. So I just build one version, then git cancel FOO to the next version, and let the make rules take care of rebuilding what needs to be rebuilt. (cancel already does most of the job anyway, i.e. cleanup stuff which the build process might have changed that it shouldn't have.) Cf. the last of the patches I've just mailed to the list. -- Matthias Urlichs - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Missing linefeeds
Hi,
Petr Baudis:
Why? report() already prints linefeed.
Ah, it didn't when I wrote this.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add DEST Makefile variable
Hi,
Junio C Hamano:
I sent essentially the same some time ago and got a comment to
follow established naming convention.
Well, for a Makefile which installs in basically one directory, that
seems to be overkill.
# DESTDIR=
BINDIR=$(HOME)/bin
install foobar $(DESTDIR)$(BINDIR)/
That doesn't make sense; if you set DESTDIR, you are not going to
install in $HOME.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git-pasky-0.6.2 heads-up on upcoming changes
Linus Torvalds wrote: I realize that there is probably a law that there has to be a space, but I actually personally use tab-completion all the time You can actually teach bash3 to do that (yes, with space). In general, though, I tend to agree -- dashes work with more shells and avoid namespace collisions. -- Matthias Urlichs - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
