tree c1fd8207f7d7b3e1db7d0f28ffae88f0dc205083
parent 2ba84684e8cf6f980e4e95a2300f53a505eb794e
author Robert Love [EMAIL PROTECTED] Mon, 15 Aug 2005 20:27:54 -0400
committer Linus Torvalds [EMAIL PROTECTED] Mon, 15 Aug 2005 23:48:31 -0700
[PATCH] inotify: fix idr_get_new_above usage
We are saving
On Sun, Aug 14, 2005 at 12:02:33AM -0400, Ryan Anderson wrote:
On Sat, Aug 13, 2005 at 10:35:50PM -0500, Steve French wrote:
2) There is no way to update the comment field of a changeset after it
goes in (e.g. to add a bugzilla bug number for a bug that was opened
just after the fix went
[PATCH] Add -k kill keyword expansion option to git-cvsimport
Early versions of git-cvsimport defaulted to using preexisting keyword
expansion settings. This change preserves compatibility with existing cvs
imports and allows new repository migrations to kill keyword expansion.
Should improve
On 8/15/05, Martin Langhoff [EMAIL PROTECTED] wrote:
[PATCH] Add -k kill keyword expansion option to git-cvsimport
Bad patch! Please ignore while I fix and resend...
apologies.
martin
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
On Sun, Aug 14, 2005 at 10:19:18PM -0700, Junio C Hamano wrote:
Ryan Anderson [EMAIL PROTECTED] writes:
Junio, do you want to pull this into the git tree?
Yes, but I have been wondering where it should go. Should it go
under Documentation/ and made into html via asciidoc along with
Early versions of git-cvsimport defaulted to using preexisting keyword
expansion settings. This change preserves compatibility with existing cvs
imports and allows new repository migrations to kill keyword expansion.
Should improve our chances of detecting merges and reduce imported
repository
Martin Langhoff [EMAIL PROTECTED] writes:
[PATCH] Add -k kill keyword expansion option to git-cvsimport
Early versions of git-cvsimport defaulted to using preexisting keyword
expansion settings. This change preserves compatibility with existing cvs
imports and allows new repository
Ryan Anderson [EMAIL PROTECTED] writes:
I guess this means, I dunno, either place works for me.
I was hoping it means to Oh, come to think of it, maybe I
should send this to [EMAIL PROTECTED] ;-).
I agree with you that this may be a lot more suitable for people
_before_ they get the git
On 8/15/05, Junio C Hamano [EMAIL PROTECTED] wrote:
The discussion between you and Linus since you brought this up
has kept me wondering if -ko is the only thing people may want
to do, or sometimes -kk or even -kb or -kv make sense for some
The git-cvsimport script requests the full file at a
Martin Langhoff [EMAIL PROTECTED] writes:
I think -kv is just the wrong thing to do if you are migrating to git.
Anyway, this script has so far followed cvs's own default... which is
-kv, and I am generally unwilling to break backwards compatibility.
Isn't cvs default -kkv?
-
To unsubscribe
On 8/15/05, Junio C Hamano [EMAIL PROTECTED] wrote:
Isn't cvs default -kkv?
You're right, default is -kkv (expand keyword/value every time) and
not -kv (expand keyword/value only if previously unexpanded).
There's something else in the -kb / -ko distinction according to the
protocol description
On Mon, Aug 15, 2005 at 12:17:46AM -0700, Junio C Hamano wrote:
Ryan Anderson [EMAIL PROTECTED] writes:
I guess this means, I dunno, either place works for me.
I was hoping it means to Oh, come to think of it, maybe I
should send this to [EMAIL PROTECTED] ;-).
I was waiting until you
On Sun, 2005-08-14 at 22:12 -0700, Junio C Hamano wrote:
Matt Draisey [EMAIL PROTECTED] writes:
The behaviour of the symlinked in ref directories has changed from
earlier versions of git. They used to be taken into account in
git-fsck-cache --unreachable.
Can the previous behaviour
On Sun, 2005-08-14 at 22:12 -0700, Junio C Hamano wrote:
Matt Draisey [EMAIL PROTECTED] writes:
The behaviour of the symlinked in ref directories has changed from
earlier versions of git. They used to be taken into account in
git-fsck-cache --unreachable.
Can the previous behaviour
On Sun, Aug 14, 2005 at 07:49:26PM -0700, Linus Torvalds wrote:
On Mon, 15 Aug 2005, Martin Langhoff wrote:
Except for the keyword expansion. surely there's a way to tell cvsps
to not do it. Why would we ever want it?
Ahh. I don't think we should blame cvsps, I think cvsimport should use
Signed-off-by: Ryan Anderson [EMAIL PROTECTED]
---
Documentation/git-pack-objects.txt |4 +++
Documentation/git-prune-packed.txt | 42 +++
Documentation/git-repack-script.txt | 41 ++
3 files changed, 87 insertions(+), 0
Ryan Anderson [EMAIL PROTECTED] writes:
I was waiting until you said, Ok, 1.00 tomorrow morning
Makes sense. There would be some weeks until that happens I am
afraid.
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo
Martin Langhoff [EMAIL PROTECTED] writes:
..., in which case instead of a -k option that does not allow
anything but -ko, making it take an optional single letter
o/k/b/v might might more sense. A single -k defaulting to -ko
is fine by me if you did so, because I think that is the most
I think these are useful, and I think putting them in a new howto
directory might help some users until we get to the point of splitting
up the tutorial to be easier to read.
Given the authorship, I think it's safe to put these in the repository.
Signed-off-by: Ryan Anderson [EMAIL PROTECTED]
In message [EMAIL PROTECTED] you wrote:
One thing that git cvsimport does not know to do is to show when a
branch was merged back into the HEAD. That would be a very interesting
thing to see, but I don't think there's any way to get that information
out of CVS (so you'd have to basically
Martin Langhoff [EMAIL PROTECTED] writes:
Do you want just -kv or you'd like to handle all the modes?
No, I do not.
I was just wondering if we are limiting options for people who
want to convert their own CVS repositories by always using
either -kkv or -ko and nothing else. Your simply saying
Junio C Hamano [EMAIL PROTECTED] wrote:
Petr Baudis [EMAIL PROTECTED] writes:
Dear diary, on Sun, Aug 14, 2005 at 09:57:13AM CEST, I got a letter
where Junio C Hamano [EMAIL PROTECTED] told me that...
Linus Torvalds [EMAIL PROTECTED] writes:
Junio, maybe you want to talk about how you
On 8/15/05, Junio C Hamano [EMAIL PROTECTED] wrote:
I was just wondering if we are limiting options for people who
want to convert their own CVS repositories by always using
either -kkv or -ko and nothing else.
I think the other modes are relevant in different scenarios. -kv is
only
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,
You just need to add -I/usr/include/qt3/ in the appropriate place in the
scons control file, IIRC.
I figured out that it wanted qt3-mt, installed it, and fiddled with
the SConfiguration file. Still no dice, perhaps because I have a qt4
build environment?
$ QTDIR=/usr/ make
scons -Q
Retrieved
On 8/15/05, Matthias Urlichs [EMAIL PROTECTED] wrote:
Umm, actually, no, cvsimport doesn't do merges. Dunno where Martin got his
from, but it wasn't me. ;-)
Just wishful thinking, and a viewing things on a remote box over a
slow x11-over-ssh connection. When I think about it, it doesn't seem
Often I find myself wanting to do quick branches check when I am
not in the windowing environment and cannot run gitk.
This stupid script shows commits leading to the heads of
interesting branches with indication which ones belong to which
branches, so that fork point is somewhat discernible
On Mon, 15 Aug 2005, Wolfgang Denk wrote:
I asked this question before without receiving any reply:
Assume I know exactly where the merge back happenend - is there any
way to tell git about it, so I don't see all these dangling heads any
more?
You'd have to teach cvsimport about it.
On Sat, 13 Aug 2005, Petr Baudis wrote:
Hello,
I've wondered how slow the protocols other than rsync are, and the
(well, a bit dubious; especially wrt. caching on the remote side)
results are:
git clone-pack:ssh 25s
git rsync 27s
git
The git-cvsimport-script had a copule of small bugs that prevented me
from importing a big CVS repository.
The first was that it didn't handle removed files with a multi-digit
primary revision number.
The second was that it was asking the CVS server for F messages,
although they were not
On Mon, 15 Aug 2005, Junio C Hamano wrote:
Ryan Anderson [EMAIL PROTECTED] writes:
I was waiting until you said, Ok, 1.00 tomorrow morning
Makes sense. There would be some weeks until that happens I am
afraid.
It might be worth putting the list of things left to do before 1.0 in the
On 8/16/05, Linus Torvalds [EMAIL PROTECTED] wrote:
The good news is that if you guess wrong, and you claim a merge where none
exists, it doesn't really do any real damage.
I had figured out what part of the code I wanted to hack, but was
concerned that marking things that were merges in
In message [EMAIL PROTECTED] you wrote:
If I find the time, I'll add some sort of pattern-match parameters to
be tried against the commitmsg to extract likely head/branch names
where we are merging from. My problem right now is that the only cvs
repo with interesting branches and merges I
Just a work-in-progress sample. I've done a pretty successful import
of a small tree with this patch. It is showing the merges /almost/ in
the right place. The almost is due to bad cvs practices, and not this
code.
Definitely doable, though it'll never be nice -- CVS doesn't have
the right data
On Saturday 13 August 2005 11:08, Junio C Hamano wrote:
Also add --verify to make sure the lines you introduced are
clean, which is more useful in commit but not very much in
format-patch as it was originally implemented, because finding
botches at format-patch time is too late.
I think that
On Mon, 15 Aug 2005, Junio C Hamano wrote:
Daniel Barkalow [EMAIL PROTECTED] writes:
I should be able to get http-pull down to the neighborhood of
(current) ssh-pull; http-pull is that slow (when the source repository
isn't packed) because it's entirely sequential, rather than
Hi,
On Mon, 15 Aug 2005, [EMAIL PROTECTED] wrote:
Linus Torvalds wrote:
I'll happily help anybody who wants to try to write some nice
documentation (answer questions etc), but I'm just not very good at doing
it myself.
Here's something that I've been putting together on how I'm using
On Tue, 16 Aug 2005, Yasushi SHOJI wrote:
Instead of disabling it entirely, how about just having some limit on it?
ah, that's a good idea. here is a quick and dirty patch.
This makes it somewhat more expensive - I was thinking about disabling it
in git-diff-tree, since the rename logic
Hi,
On Mon, 15 Aug 2005, Carl Baldwin wrote:
Somewhere in the thread something was mentioned about maintaining
local branch:remote branch pairs in the git repository when pushes
and pulls are performed. I think the argument was actually against
keeping this information and ultimately
Hi,
On Mon, 15 Aug 2005, Linus Torvalds wrote:
I was seriously considering just breaking the remote cvs support
entirely (you can always just use cvsup or something to download it to
make it local), and just taking the RCS parsing code from GNU rcs/cvs and
making a C language CVS importer.
Johannes Schindelin [EMAIL PROTECTED] writes:
Here's something that I've been putting together on how I'm using
GIT as a Linux subsystem maintainer.
This is perfect material for the newly introduced howto/ directory! How
about Documentation/howto/how-tony-luck-does-it.txt :-)
I already
Hi,
On Sat, 13 Aug 2005, Brad Roberts wrote:
I'm seeing this on a standard os/x 10.3.9 install which seems to have an
old, but still GNU based, diff.
$ which diff
/usr/bin/diff
$ diff --version
diff - GNU diffutils version 2.7
That is exactly the same as with 10.2.8.
[...]
* FAIL
The topmost couple of commits in the master branch made from
your patches are incorrectly attributed to me.
What happened was that I stumbled upon a merge conflict during
git-rebase, and ended up hand committing these two without
carrying the authorship information forward from the original
Hi,
On Sat, 13 Aug 2005, Junio C Hamano wrote:
+Note that your maintainer does not subscribe to the git mailing
+list (he reads it via mail-to-news gateway).
Wow. I didn't even read a newsgroup in decades...
BTW, I don't know how many people still use pine, but for those poor souls
it may
Hi,
On Sat, 13 Aug 2005, Junio C Hamano wrote:
Johannes posted a script on the list a couple of days ago, which
should work well, except that it was written before the
git-fetch-pack command was updated to natively download from
multiple refs, so it does not know how to fetch multiple refs
Josef Weidendorfer [EMAIL PROTECTED] writes:
These verification scripts should be used per default, and git-commit should
have an option to force bypassing verification.
I agree that it would be a good place to do a hook. Also it may
not be a bad idea, if you volunteer to come up with a
Carl Baldwin [EMAIL PROTECTED] writes:
Somewhere in the thread something was mentioned about maintaining
local branch:remote branch pairs in the git repository when pushes
and pulls are performed. I think the argument was actually against
keeping this information and ultimately against
Since git-commit-script has a --signoff option, use that in
git-format-patch-script, too (and since partial option names are
supported,--sign is still valid).
Also, if the message already contains the S-O-B line, silently ignore the
--signoff request.
Signed-off-by: Johannes Schindelin
Johannes Schindelin [EMAIL PROTECTED] writes:
BTW, I don't know how many people still use pine, but for those poor souls
it may be good to mention that the quell-flowed-text is needed for recent
versions.
Contributions from pine users are very much appreciated. Among
the patches I either
On Tue, 16 Aug 2005, Johannes Schindelin wrote:
BTW, I don't know how many people still use pine, but for those poor souls
it may be good to mention that the quell-flowed-text is needed for recent
versions.
And 4.58 needs at least this
Linus
---
diff-tree
Linus Torvalds [EMAIL PROTECTED] writes:
And 4.58 needs at least this
diff-tree 8326dd8350be64ac7fc805f6563a1d61ad10d32c (from
e886a61f76edf5410573e92e38ce22974f9c40f1)
Author: Linus Torvalds [EMAIL PROTECTED]
Date: Mon Aug 15 17:23:51 2005 -0700
Fix pine whitespace-corruption bug
Hi,
On Mon, 15 Aug 2005, Linus Torvalds wrote:
On Tue, 16 Aug 2005, Johannes Schindelin wrote:
BTW, I don't know how many people still use pine, but for those poor souls
it may be good to mention that the quell-flowed-text is needed for recent
versions.
And 4.58 needs at least
Johannes Schindelin [EMAIL PROTECTED] writes:
Maybe we should enhance git-applymbox to detect whitespace corruption in
particular, and output the User-Agent header (or if that does not
exist, the Message-ID header; thanks, pine) on error.
We _could_ but I doubt it would help anybody. The
Hi,
On Mon, 15 Aug 2005, Junio C Hamano wrote:
Johannes Schindelin [EMAIL PROTECTED] writes:
Maybe we should enhance git-applymbox to detect whitespace corruption in
particular, and output the User-Agent header (or if that does not
exist, the Message-ID header; thanks, pine) on error.
Following an extenal repo, I am not getting all the heads. This is by
design, AFAIK, and the question is how do I find what heads the repo
offers and pull them in so I can call them by name?
cheers,
martin
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message
Junio C Hamano [EMAIL PROTECTED] writes:
Martin Langhoff [EMAIL PROTECTED] writes:
Following an extenal repo, I am not getting all the heads. This is by
design, AFAIK, and the question is how do I find what heads the repo
offers and pull them in so I can call them by name?
Sorry, git
On 8/16/05, Junio C Hamano [EMAIL PROTECTED] wrote:
Martin Langhoff [EMAIL PROTECTED] writes:
Following an extenal repo, I am not getting all the heads. This is by
design, AFAIK, and the question is how do I find what heads the repo
offers and pull them in so I can call them by name?
I
On Tue, Aug 16, 2005 at 03:41:04AM +0200, Johannes Schindelin wrote:
On Mon, 15 Aug 2005, Junio C Hamano wrote:
Johannes Schindelin [EMAIL PROTECTED] writes:
Maybe we should enhance git-applymbox to detect whitespace corruption in
particular, and output the User-Agent header (or if
Note that the pack file has to be in the usual location if it gets
installed later.
Signed-off-by: Daniel Barkalow [EMAIL PROTECTED]
---
cache.h |2 ++
sha1_file.c | 10 --
2 files changed, 10 insertions(+), 2 deletions(-)
59e5c6d163edae5da6136560d48a4750cceacdc6
diff --git
If it doesn't find an object, it looks for an index that contains it
and uses the same methods on that instead.
Signed-off-by: Daniel Barkalow [EMAIL PROTECTED]
---
local-pull.c | 112 +++---
1 files changed, 91 insertions(+), 21 deletions(-)
Yasushi SHOJI [EMAIL PROTECTED] writes:
parepare_temp_file() and diff_populate_filespec() has a lot in
similarity. so it'd be nice to refactor some. and re-introduce
diff_free_filespec_data() and call right after prep_temp_blob() in
prepare_temp_file().
Another thing that may (or may not)
[PATCH] Add -k kill keyword expansion option to git-cvsimport - revised
Early versions of git-cvsimport defaulted to using preexisting keyword
expansion settings. This change preserves compatibility with existing cvs
imports and allows new repository migrations to kill keyword expansion.
After
62 matches
Mail list logo
