Re: Last mile to 1.0?

Monday, 18 July 2005 09:35 Junio C Hamano wrote: > Alexey Nezhdanov <[EMAIL PROTECTED]> writes: > > I'd add the UTF-8 native support. Currently neither commit nor gitk > > doesn't support that. Probably this should be done at as low as possible > > level. > > I do not understand your proposal. Car

Re: [PATCH] git-revover-tags-script

[EMAIL PROTECTED] (Eric W. Biederman) writes: > The big question is in what format should we return the heads? > Just a space separated list of sha1's or a directory hierarchy > like git-clone-pack uses. My knee-jerk reaction is something like this: $ git-list-remote jg-libata 9956d54ace

Re: Last mile to 1.0?

David Lang <[EMAIL PROTECTED]> writes: > a very common one will be prople who want to setup a cron job to > update their local tree nightly, in this case having a pre-generated > pack file with each day's updates will save a significant amount of > processing power. > > would it make sense to have

Re: [PATCH] git-revover-tags-script

Junio C Hamano <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] (Eric W. Biederman) writes: > >> Actually looking a little deeper unless I have misread >> the code git-fetch-pack at least will only ask for commit >> objects so git fetch will never return a tag object. > > I thought so but then I tr

Re: Last mile to 1.0?

Alexey Nezhdanov <[EMAIL PROTECTED]> writes: > I'd add the UTF-8 native support. Currently neither commit nor gitk doesn't > support that. Probably this should be done at as low as possible level. I do not understand your proposal. Care to clarify? You can write your commit messages in UTF-8 t

Re: Last mile to 1.0?

Satturday, 16 July 2005 21:46 Junio C Hamano wrote: > I do not know what release plan Linus has in mind, and also > expect things to be quieter next week during OLS and kernel > summit, but I think we are getting really really close. > > Here are the things I think we would want to see before we hi

git, porcelain, darcs, and version 1.0

Juliusz Chroboczek wrote: There are three ways to do that: (1) require that the users put a suitable libgit.a in /usr/local/lib before building Darcs, and distribute a tarball of Git from darcs.net; I was under the impression that the stablest interface to git was the command li

Re: Barebone Porcelain. Where to stop?

Junio C Hamano wrote: I have been somewhat disturbed and confused by the fact that the line between what Porcelain like Cogito does and what we ship as part of "core GIT" is getting more and more blurred. This was especially so while I was working on the $GIT_DIR/branches/ patch. I have also b

[PATCH UPDATED] cg-commit chokes when given a very large list of files

cg-commit currently chokes when passed a very large list of files. Fix it. Resent again. This time we completely avoid messing with IFS, resulting in support for filenames with line feeds. Signed-off-by: Bryan Larsen <[EMAIL PROTECTED]> --- cg-Xlib | 18 ++ cg-commit |

Re: [PATCH] cg-commit chokes when given a very large list of files

This patch is broken. The original patch still works. Bryan Bryan Larsen wrote: cg-commit currently chokes when passed a very large list of files. Fix it. This patch depends on your filenames not containing line feeds. No big deal, other parts of cogito break on filenames containing line fe

[PATCH] cg-commit chokes when given a very large list of files

cg-commit currently chokes when passed a very large list of files. Fix it. This patch depends on your filenames not containing line feeds. No big deal, other parts of cogito break on filenames containing line feeds. Resent because previous send appears to have been dropped. This patch is cleane

[PATCH 1/6 RESEND] cogito: remove use of xargs -r, a non-portable GNU extension

Remove usage of xargs -r, a non-portable gnu extension. Resent with nasty bug fixed. Signed-off-by: Bryan Larsen <[EMAIL PROTECTED]> --- cg-add |6 +++--- cg-init |2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/cg-add b/cg-add --- a/cg-add +++ b/cg-add @@ -25,8

[PATCH 5/6] cogito: remove findutils dependency from Portfile

Gnu findutils (xargs) is no longer required; remove the dependency. Gnu coreutils is still required, but only if awk is not installed. Signed-off-by: Bryan Larsen <[EMAIL PROTECTED]> --- Portfile.in |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Portfile.in b/Portf

[PATCH 6/6] cogito: update documentation

Update the documentation to add a README.osx and update requirements. Signed-off-by: Bryan Larsen <[EMAIL PROTECTED]> --- README |2 ++ README.osx | 31 +++ 2 files changed, 33 insertions(+), 0 deletions(-) diff --git a/README b/README --- a/README +++ b/RE

[PATCH 4/6] cogito: try harder to find gnu date

Look harder for gnu date, use if available. Signed-off-by: Bryan Larsen <[EMAIL PROTECTED]> --- cg-Xlib | 12 ++-- 1 files changed, 10 insertions(+), 2 deletions(-) diff --git a/cg-Xlib b/cg-Xlib --- a/cg-Xlib +++ b/cg-Xlib @@ -70,7 +70,7 @@ showdate () { secs=$(($secs + $tzho

[PATCH 3/6] cogito: try harder to find gnu stat

Look harder for gnu stat. Cogito has code to use awk if gnu stat is missing. Look harder for gnu stat under alternate names such as gstat and gnustat, avoiding the use of awk if possible. Signed-off-by: Bryan Larsen <[EMAIL PROTECTED]> --- cg-Xlib | 13 + 1 files changed, 9 inse

[PATCH 2/6] cogito: remove use of cp -a, a non-portable GNU extension

Remove usage of cp -a, a non-portable gnu extension. Signed-off-by: Bryan Larsen <[EMAIL PROTECTED]> --- cg-pull |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/cg-pull b/cg-pull --- a/cg-pull +++ b/cg-pull @@ -217,7 +217,7 @@ fetch_local () { [ "$1" = "-i" ] &&

[PATCH 1/6] cogito: remove use of xargs -r, a non-portable GNU extension

Remove usage of xargs -r, a non-portable gnu extension. Signed-off-by: Bryan Larsen <[EMAIL PROTECTED]> --- cg-add |6 +++--- cg-init |2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/cg-add b/cg-add --- a/cg-add +++ b/cg-add @@ -25,8 +25,6 @@ USAGE="cg-add [-N] FI

[PATCH 0/6] cogito: compatibility with OS X

This is a resend of my previous set of patches. I have updated these patches with Junio's suggestion. I have also added some documentation, a simple README.osx. Once you have applied these patches, could you choose one of these 4 options, Junio? 1) send me the result of "make Portfile" on next

Re: [PATCH] git-revover-tags-script

[EMAIL PROTECTED] (Eric W. Biederman) writes: > There are a couple pieces of your example that disturb me. Did you actually think I suggested you to make that into a script that cannot be configured? No, it was Junio acquiring a habit from Linus to give a rough outline in a code form in his e-ma

Re: [PATCH] git-revover-tags-script

Junio C Hamano <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] (Eric W. Biederman) writes: > >> What we care about are the tag objects, those are the only kind >> that are verifiable and usable remotely. >> >> Now that I know we do not pull tags currently with any of the >> optimized transports,

Re: [PATCH] git-revover-tags-script

Junio C Hamano <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] (Eric W. Biederman) writes: > >> What we care about are the tag objects, those are the only kind >> that are verifiable and usable remotely. >> >> Now that I know we do not pull tags currently with any of the >> optimized transports,

Cannot get git any more?

Hi, I cannot access the git repositorey any more: -> rpm -q cogito cogito-0.12.1-1 -> cd git -> cat .git/branches/origin rsync://rsync.kernel.org/pub/scm/git/git.git -> cg-update @ERROR: Unknown module 'pub' rsync: connection unexpectedly closed (41 bytes read so far) rsync error: error in rsync

Re: [PATCH] git-revover-tags-script

[EMAIL PROTECTED] (Eric W. Biederman) writes: > What we care about are the tag objects, those are the only kind > that are verifiable and usable remotely. > > Now that I know we do not pull tags currently with any of the > optimized transports, I would suggest taking the list of commit > objects

[offtopic]Re: "git cvsimport" with branches?

Sorry for noise again. I have found two bugs in cvsps that results in the wrong import to git. I tried to contact developer but it seems that his mail have no mailserver ATM. Since he has made some changes for git already - probably someone on this list have his new contact. Please tell me it or

Re: "git cvsimport" with branches?

Sunday, 17 July 2005 14:48 Alexey Nezhdanov wrote: > Sunday, 17 July 2005 13:37 Matthias Urlichs wrote: > > 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. > > But i

Re: "git cvsimport" with branches?

Sunday, 17 July 2005 13:37 Matthias Urlichs wrote: > 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. But it does not, at least in some cases. See my previous mail: http://ma

Re: [darcs-devel] Darcs-Git: upgrading to Git 0.99

On Sat, Jul 16, 2005 at 10:45:47PM +0200, Juliusz Chroboczek wrote: > > I'd like to upgrade the Git code used in Darcs to 0.99 (we're > currently using 0.6). [...] Great! > Now I'm wondering how to do that. Currently, I'm using a nasty hack > using the C preprocessor to include just the sources

Re: "git cvsimport" with branches?

In message <[EMAIL PROTECTED]> you wrote: > > > 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 >

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

Re: "git cvsimport" with branches?

В сообщении от Воскресенье 17 Июль 2005 12:40 Wolfgang Denk написал(a): > Is there a way to make "git cvsimport" create branches in git for any > branches it encounters in the CVS repository? Heh. I was just preparing mail about the same problem. It seems that git-cvsimport-script really don't like

[PATCH] Audit rev-parse users.

This patch changes rev-parse users that pass a single argument that is supposed to be a rev parameter to use "--verify". Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]> --- *** This does not have anything to do with the --sq flag. git-checkout-script |2 +- git-cherry |8

"git cvsimport" with branches?

Is there a way to make "git cvsimport" create branches in git for any branches it encounters in the CVS repository? All my imports so far show just a linear line of development, and CVS branch information seems lost. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime S

Re: [PATCH] git-revover-tags-script

Junio C Hamano <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] (Eric W. Biederman) writes: > >> First pass at a script to dig through .git/objects and find dangling >> tags. It likely has a lot of weird limitations, I don't know if it >> will work with packs, and the policy it implments is pretty

[PATCH] diffcore-pickaxe: switch to "counting" behaviour.

Instead of finding old/new pair that one side has and the other side does not have the specified string, find old/new pair that contains the specified string as a substring different number of times. This would still not catch a case where you introduce two static variable declarations and remove

[PATCH] rev-parse --sq bugfixes.

We expect --sq output to be used to construct a string to be "eval"ed in shell scripts, so we should not be separating the parameter with LF, which would cause the current command to be ended. Also there was a silly thinko for doing the shell quoting. Signed-off-by: Junio C Hamano <[EMAIL PROTECT

[RFC/PATCH] git-rev-parse vs IFS

"git whatchanged" does not work with parameters that have an IFS character; this includes a filename with SP in it. A silly example: $ git-whatchanged --max-count=1 diff-tree 98800286dffc76736549d7279622157ca2be9a3b (from 9171e0... Author: Junio C Hamano <[EMAIL PROTECTED]> Date: