Matt Draisey <[EMAIL PROTECTED]> writes:
> On Sun, 2005-08-14 at 22:12 -0700, Junio C Hamano wrote:
>> I would like to know
>> a use case or two to illustrate why there are symlinks pointing
>> at real files outside .git/refs/ hierarchy, and how that
>> arrangement is useful.
>...
> This email is
[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 ex
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 no
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(-
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
This adds essentially the same logic to local-pull that http-pull has,
with the exception that it reads the index out of the source directory,
rather than copying it. This, in turn, requires the ability to use an
index file in some other directory.
1: Use index file in another directory
2: Co
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 h
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
At Sat, 13 Aug 2005 14:31:59 -0700,
Junio C Hamano wrote:
>
> Yasushi SHOJI <[EMAIL PROTECTED]> writes:
>
> > oops. probably my english wasn't clear. my patch fixes
> > diff_free_filepair().
>
> When the command is run on linux-2.6 repository, virtual memory
> consumption of git-diff-tree comma
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,
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 suspect the Subject: line and your question do not mes
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
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)
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. T
Linus Torvalds <[EMAIL PROTECTED]> writes:
> This makes it somewhat more expensive - I was thinking about disabling it
> in git-diff-tree, since the rename logic already knows how many
> new/deleted files there are.
That's doable. I'll rig something up on my next GIT day, along
with the clean-
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
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-corru
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 8326dd8350b
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 eith
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
Carl Baldwin <[EMAIL PROTECTED]> writes:
> Somewhere in the thread something was mentioned about maintaining
> : pairs in the git repository when pushes
> and pulls are performed. I think the argument was actually against
> keeping this information and ultimately against allowing pushes to a
> br
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 p
Martin Langhoff <[EMAIL PROTECTED]> writes:
> So this patch is obsolete too.
I take it to mean that it should be dropped and replaced with
the one you sent today with -kk change.
However, the -kk change one is a corrupted patch and does not
apply. Your MUA ate leading whitespaces, perhaps.
I
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 ref
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
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
comm
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.
> [...]
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 alr
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 import
Hi,
On Mon, 15 Aug 2005, Carl Baldwin wrote:
> Somewhere in the thread something was mentioned about maintaining
> : pairs in the git repository when pushes
> and pulls are performed. I think the argument was actually against
> keeping this information and ultimately against allowing pushes to a
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
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 l
On Tue, 16 Aug 2005, Martin Langhoff 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 m
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
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 th
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
At Mon, 15 Aug 2005 11:53:20 -0700 (PDT),
Linus Torvalds wrote:
>
> On Tue, 16 Aug 2005, Yasushi SHOJI wrote:
> >
> > It seems to me that git-diff-tree needs huge memory if you try to diff
> > on big change with rename detection enabled.
> >
> > This isn't problem for sane project but if you cre
For people whose workflow involves switching back and forth between a
lot of branches, it can be really helpful to be able to quickly tell
which branch you are on and which ones are available. This patch
introduces a small script that when invoked as `git branches' prints a
list of available branc
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 overlapping
> requests like ssh-pull now does.
I li
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
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 cv
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
GIT as a Linux subsystem maintainer.
I suspect that I'm
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
On Tue, 16 Aug 2005, Yasushi SHOJI wrote:
>
> It seems to me that git-diff-tree needs huge memory if you try to diff
> on big change with rename detection enabled.
>
> This isn't problem for sane project but if you create a repo with only
> major releases imports, git-diff-tree run by git_commi
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 handle
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
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
(Sorry for the repost. The other one was an accident.)
Over the week-end, I was thinking about the thread "Re: How is working
on arbitrary remote heads supposed to work in Cogito". I wanted to
weigh in an opinion that I've developed on it but thought it deserved a
new thread.
Somewhere in the t
Over the week-end, I was thinking about the thread "Re: How is working
on arbitrary remote heads supposed to work in Cogito". I wanted to
weigh in an opinion that I've developed on it but thought it deserved a
new thread.
Somewhere in the thread something was mentioned about maintaining
: pairs i
[PATCH] Just run Ispell through git.txt
Signed-off-by: Yasushi SHOJI <[EMAIL PROTECTED]>
---
Documentation/git.txt | 16
1 files changed, 8 insertions(+), 8 deletions(-)
7752fb658ce21b5156547593df01a3a4584ebf80
diff --git a/Documentation/git.txt b/Documentation/git.txt
--- a/
On Mon, Aug 15, 2005 at 12:38:53PM +0200, Matthias Urlichs wrote:
> Hi, Wolfgang Denk wrote:
>
> > 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?
>
> Two ways:
> - you can enhance cvs2git to
[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 ex
On 8/15/05, Martin Langhoff <[EMAIL PROTECTED]> wrote:
> I think the other modes are relevant in different scenarios. -kv is
> only meaningful as file mode over the life of the file in the repo.
> -kk is only meaningful when calling cvs update with -j -j parameters
> or cvs diff, and is effectively
Hi, Wolfgang Denk wrote:
> 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?
Two ways:
- you can enhance cvs2git to do it at the appropriate time. Good luck.
- after the fact, and after finding the
Martin Langhoff wrote:
>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?
I have qt 3 3.3.4 installed and I never dared to hope qgit can compile
with qt4, being a so huge compatibility br
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 witho
Make sure that we say --verify when we want to get a single SHA1
name. Also when we say --verify, --revs-only is redundant.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
git-rebase-script |2 +-
git-reset-script |4 ++--
git-tag-script|2 +-
3 files changed, 4 insertion
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
> 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
Problems found while importing dasher's CVS:
* Allow spaces in filenames.
* cvsps may create unnamed branches with revisions that don't really
exist, which causes the CVS server to return something we haven't
hitherto expected.
* Report deleted files when being verbose.
* Also, report the comm
There are other ways to do these, explained in this thread. I will
only show the StGIT way, just choose which one suits you better.
Steve French <[EMAIL PROTECTED]> wrote:
> 1) There is no way to send a particular changeset from the "middle"
> of a set from one tree to another, without exporting i
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,
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 meani
On Mon, 2005-08-15 at 00:41 -0700, Junio C Hamano wrote:
> Matt Draisey <[EMAIL PROTECTED]> writes:
>
> > ... My own programming efforts rarely exceed two or three files
> > per project, and don't justify there own .git/objects repository.
> > Still, a few projects do benefit from having their ow
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
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 sayi
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 basic
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]>
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 m
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 majord
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
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
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 previou
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 previou
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 u
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 descripti
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 unsubscr
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 a
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
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 mig
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 siz
81 matches
Mail list logo
