Diagnosing stray/stale .keep files -- explore what is in a pack?

2014-01-14 Thread Martin Langhoff
hi folks, I have a git server which gets pushes of data (not code) from a couple hundred VMs every hour. Every round of pushes leaves two stray .keep files, so I am guessing two clients are having problems completing the push. The contents being pushed are reports of a puppet run. Is there a

Re: Diagnosing stray/stale .keep files -- explore what is in a pack?

2014-01-14 Thread Martin Langhoff
On Tue, Jan 14, 2014 at 9:54 AM, Martin Langhoff martin.langh...@gmail.com wrote: Is there a handy way to list the blobs in a pack, so I can feed them to git-cat-file and see what's in there? I'm sure that'll help me narrow down on the issue. git show-index /var/lib/ppg/reports.git/objects

Error logging for git over ssh?

2014-01-14 Thread Martin Langhoff
Diagnosing errors with git over ssh has historically required tooling up for debugging or looking at things from the client side, because git does not log anything on the server side. It would be a boon to those running busy git servers to be able to diagnose by looking at a log. It can be both

Re: Diagnosing stray/stale .keep files -- explore what is in a pack?

2014-01-14 Thread Martin Langhoff
On Tue, Jan 14, 2014 at 2:36 PM, Martin Fick mf...@codeaurora.org wrote: Perhaps the receiving process is dying hard and leaving stuff behind? Out-of-memory, out of disk space? Yes, that's my guess as well. This server had gc misconfigured, so it hit ENOSPC a few weeks ago. It is likely that

Re: Error logging for git over ssh?

2014-01-14 Thread Martin Langhoff
On Tue, Jan 14, 2014 at 8:51 PM, Duy Nguyen pclo...@gmail.com wrote: We'll need to output the error side bands to stderr too in case side-band is used. Agreed, we'd need to tee the output so it gets to the logger _and_ to stderr. I thought perhaps daemon.c would have something in this spirit,

Re: Diagnosing stray/stale .keep files -- explore what is in a pack?

2014-01-15 Thread Martin Langhoff
On Wed, Jan 15, 2014 at 4:12 AM, Jeff King p...@peff.net wrote: We see these occasionally at GitHub, too. I haven't yet figured out a definite cause, though whatever it is, it's relatively rare. Do you have a cleanup script to safely get rid of stale .keep and .lock files? I wonder what other

Re: Diagnosing stray/stale .keep files -- explore what is in a pack?

2014-01-15 Thread Martin Langhoff
On Wed, Jan 15, 2014 at 12:49 PM, Junio C Hamano gits...@pobox.com wrote: As long as we can reliably determine that it is safe to do so without risking races, automatically cleaning .lock files is a good thing to do. If the .lock file is a day old, it seems to me that it should be safe to call

Re: Running make rpm fails on a CentOS 6.3 machine

2014-02-03 Thread Martin Langhoff
On Sun, Feb 2, 2014 at 4:07 PM, Todd Zullinger t...@pobox.com wrote: # Install fedpkg $ yum install fedpkg fedpkg is amazing. I (ab)use it (and the associated build machinery) for lots of private package builds. # Create an el6 srpm $ fedpkg --dist el6 srpm here I just say fedpkg --dist el6

Testing for commit reachability through plumbing commands

2014-03-06 Thread Martin Langhoff
I have a shell script that trims old history on a cronjob. This is for a repo that is used to track reports that have limited life (like logs). Old history is trimmed with grafts pointing to an empty root commit. Right now, info/graft grows unbound. I am looking for a way to trim unreachable

Re: Testing for commit reachability through plumbing commands

2014-03-06 Thread Martin Langhoff
On Thu, Mar 6, 2014 at 2:17 PM, Andreas Schwab sch...@linux-m68k.org wrote: Does git fsck --unreachable --no-reflogs help? Well, my script, called regularly, does: - adds grafts - git repack -AFfd (which unpacks unreachable objects) - git prune --expire now hmm, I guess could prune the

gc/repack has no option to lose grafted parents

2014-03-06 Thread Martin Langhoff
Back in http://git.661346.n2.nabble.com/PATCH-0-2-Make-git-gc-more-robust-with-regard-to-grafts-td3310281.html we got gc/repack to be safer for users who might be shooting themselves in the foot. Would a patch be welcome to add --discard-grafted-objects ? or --keep-real-parents=idontthinkso ?

Re: gc/repack has no option to lose grafted parents

2014-03-06 Thread Martin Langhoff
On Thu, Mar 6, 2014 at 6:26 PM, Junio C Hamano gits...@pobox.com wrote: Given that we in general frown upon long-term use of grafts (or replace for that matter), I am not sure if we want to go in that direction. Just a knee-jerk reaction, though. Fair enough. If I state my actual goals --

Re: question about: Facebook makes Mercurial faster than Git

2014-03-10 Thread Martin Langhoff
On Mon, Mar 10, 2014 at 1:56 PM, David Lang da...@lang.hm wrote: there's also the issue of managed vs generated files, if you update the mtime all the way up the tree because a source file was compiled and a binary created, that will quickly defeat the value of the recursive mime. I think this

Re: [PATCH v1 00/25] contrib: cleanup

2014-05-08 Thread Martin Langhoff
On Thu, May 8, 2014 at 8:58 PM, Felipe Contreras felipe.contre...@gmail.com wrote: Let us be honest, the vast majority of tools in 'contrib/' have no chance of ever graduating, so let's remove them. I am curious -- have you checked what parts of contrib downstreams packageship? Are you planning

Re: [PATCH v1 00/25] contrib: cleanup

2014-05-09 Thread Martin Langhoff
On Fri, May 9, 2014 at 11:57 AM, Felipe Contreras felipe.contre...@gmail.com wrote: I already explained: That's right, and they are Cc'ed so they can respond. Some tools have only one commit or two, and in those I didn't even bother Cc'ing anyone. contrib/persistent-https consist of a

Re: [PATCH v1 1/2] Remove 'git archimport'

2014-05-13 Thread Martin Langhoff
On Thu, May 8, 2014 at 9:33 PM, Felipe Contreras felipe.contre...@gmail.com wrote: No updates since 2010, and no tests. NAK. IMHO, this is quite unfriendly. Is this removal based on your opinion, or Junio's position (or consensus from maintainers from the list)? If there is a clear consensus

Re: [PATCH v2 01/17] contrib: remove outdated README

2014-05-13 Thread Martin Langhoff
On Fri, May 9, 2014 at 5:54 PM, Felipe Contreras felipe.contre...@gmail.com wrote: You are once more twisting the sequence of events. Found this gem looking for background to the proposed removal to code of mine. Felipe, if you are wanting to have a war of words with Junio, go have it, with

Re: [PATCH v1 1/2] Remove 'git archimport'

2014-05-13 Thread Martin Langhoff
On Fri, May 9, 2014 at 1:44 PM, Junio C Hamano gits...@pobox.com wrote: Eric Wong normalper...@yhbt.net writes: Felipe Contreras felipe.contre...@gmail.com wrote: No updates since 2010, and no tests. Who benefits from this removal? Is this causing a maintenance burden for Junio? No. See

Re: [PATCH v1 1/2] Remove 'git archimport'

2014-05-13 Thread Martin Langhoff
On Tue, May 13, 2014 at 2:05 PM, Felipe Contreras felipe.contre...@gmail.com wrote: This tool doesn't even work anyway. It doesn't? Bug report / more info please? cheers, m -- martin.langh...@gmail.com - ask interesting questions - don't get distracted with shiny stuff - working code

Re: [PATCH v2 01/17] contrib: remove outdated README

2014-05-13 Thread Martin Langhoff
Felipe, someone can contribute positively, and also be very destructive. Your positive contributions, nobody will deny. However, you have to tame the other part to be good company. I have had patches and contributions rejected in the past, sometimes rudely. Same has happened to many others, if

Re: [PATCH v2 01/17] contrib: remove outdated README

2014-05-14 Thread Martin Langhoff
On Wed, May 14, 2014 at 3:35 PM, Felipe Contreras felipe.contre...@gmail.com wrote: You are not paying attention at all. Junio may have been trying to be polite and not tell you directly that attitude was a factor. Whatever. He is the maintainer. Of all the folks in this list, he gets to call

Re: [PATCH v2 01/17] contrib: remove outdated README

2014-05-14 Thread Martin Langhoff
On Wed, May 14, 2014 at 7:28 PM, Felipe Contreras felipe.contre...@gmail.com wrote: Do we no longer have to be afraid of that? WHY? All the responses from the contrib cleanup patches seem to suggest that pretty much *everyone* The responses also been clear in that you are toxic. You've hijacked

Re: git and cyrillic branches

2013-07-25 Thread Martin Langhoff
On Thu, Jul 25, 2013 at 10:51 AM, ксовиран xowi...@yandex.ru wrote: problem is still here, i've got ubuntu on VM and same shared git-folder causes this problem on Mac Os and no problems on Ubuntu. git version on Mac is 1.8.0.1 (on Ubuntu is 1.7.10.4) OSX filesystem code canonicalizes UTF-8

Re: OSLC connectivity to GIT in Java

2012-08-13 Thread Martin Langhoff
On Mon, Aug 13, 2012 at 8:12 AM, rahul.chandrashekar rahul.chandrashe...@in.bosch.com wrote: I am interested to connect to a GIT SCM through OSLC. It seems to me a very strange request. There is a very well implemented, fit-for-purpose git protocol. OSLC, after some googling, is a REST-style

Re: How do I pronounce blob?

2012-09-15 Thread Martin Langhoff
On Sat, Sep 15, 2012 at 9:24 AM, Yi, EungJun semtlen...@gmail.com wrote: bee-lob or bla:b? Like Bob, add an L in there. m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first

Re: Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper

2012-11-01 Thread Martin Langhoff
On Thu, Nov 1, 2012 at 9:46 AM, René Scharfe rene.scha...@lsrfire.ath.cx wrote: You probably didn't intend it, but your sentences at the top can be read more like: This is a logical consequence. If you don't understand that, your mental capabilities must be lacking.. That's obviously (ha!) a

Re: Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper

2012-11-01 Thread Martin Langhoff
Felipe, I'll invite you to reread some of your words: That being said, I did wonder what must be going through his mind to not see that as obvious, (...) Following the guideline of always assuming good faith So perhaps it does apply that you could try to assume good intellectual faith in

Re: Python extension commands in git - request for policy change

2012-12-04 Thread Martin Langhoff
On Sat, Nov 24, 2012 at 9:44 PM, Eric S. Raymond e...@thyrsus.com wrote: git presently contains one Python extension command, Pete Wycoff's p4 importer. If my git-weave code is merged it will acquire another. Write a really compelling tool. Don't argue languages. Make it wonderful. The git

Re: [PATCH] Replace git-cvsimport with a rewrite that fixes major bugs.

2013-01-02 Thread Martin Langhoff
First of all, I am at the same time a sad, nostalgic, and very happy that old cvsimport is getting replaced. On Wed, Jan 2, 2013 at 11:18 AM, Eric S. Raymond e...@thyrsus.com wrote: Two of the three claims in this paragraph are false. The manual page does not tell you what is true, which is

Re: [PATCH] Replace git-cvsimport with a rewrite that fixes major bugs.

2013-01-02 Thread Martin Langhoff
On Wed, Jan 2, 2013 at 11:41 AM, Eric S. Raymond e...@thyrsus.com wrote: Martin Langhoff martin.langh...@gmail.com: Replacement with something more solid is welcome, but until you are extremely confident of its handling of legacy setups... I would still provide the old cvsimport, perhaps

Re: [PATCH] Replace git-cvsimport with a rewrite that fixes major bugs.

2013-01-02 Thread Martin Langhoff
On Wed, Jan 2, 2013 at 5:28 PM, Eric S. Raymond e...@thyrsus.com wrote: Martin Langhoff martin.langh...@gmail.com: I dealt with enough CVS repos to see that the branch point could be ambiguous, and that some cases were incurably ugly and ambiguous. You are quite right, but you have

cg-clone failing to get cogito latest tree.

2005-07-31 Thread Martin Langhoff
On a new machine, trying to boostrap into latest cogito, I download and make cogito 0.12.1, and then... $ cg-clone http://www.kernel.org/pub/scm/cogito/cogito.git cogito defaulting to local storage area 14:48:53 URL:http://www.kernel.org/pub/scm/cogito/cogito.git/refs/heads/master [41/41] -

Re: [PATCH] Debian packaging for 0.99.4

2005-08-10 Thread Martin Langhoff
On 8/11/05, Matthias Urlichs [EMAIL PROTECTED] wrote: Debian packaging fixes for 0.99.4: Is this anywhere in the archive? cheers, martin - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at

Re: [OT?] git tools at SourceForge ?

2005-08-12 Thread Martin Langhoff
I don't think he wants sourceforge to host git, I think he'd like sourceforge to provide access to source trees via git, instead of cvs. Read that as, I want to do: Correct, that's what I am looking for. My hope is that if enough people ask SF might actually provide such a service.

Re: [OT?] git tools at SourceForge ?

2005-08-12 Thread Martin Langhoff
- the git architecture is admirably suited to an _untrusted_ central server, ie exactly the SourceForge kind of setup. I realize that the Definitely. And beyond that too. Using SF for CVS means that when SF's CVS service is down (often enough) you can't commit (or even fscking diff) until

Re: git/cogito workshop/bof at linuxconf au?

2005-08-13 Thread Martin Langhoff
On 8/14/05, Linus Torvalds [EMAIL PROTECTED] wrote: I was planning to be there. I like lca, but passed it over this year because of it being in Canberra And how are things lining up for the upcoming one (January 2006, Dunedin, NZ)? I would gladly try and organize a workshop, but I am far

Re: [ANNOUNCE] qgit-0.9

2005-08-14 Thread Martin Langhoff
Marco, How do I get this to build on Debian? Not familiar with scons, and it is complaining that it can't find qt and related header files, when they are there... It's been mentioned on the list that v0.3 didn't build on Debian, but I thought it had been dealt with. There were no fixes mentioned

Switching heads and head vs branch after CVS import

2005-08-14 Thread Martin Langhoff
After having done a cvs import of Moodle using git-cvsimport-script all the cvs branches show up as heads. How do I switch heads within a checkout? cogito doesn't seem to be able to, and I'm unsure on how to do it with git. And I am confused about the difference between heads and branches. Git

Re: Switching heads and head vs branch after CVS import

2005-08-14 Thread Martin Langhoff
Just do git checkout branch-name to switch between them. thanks! I was doing cg-branch-chg branch-name and it wasn't working. So in a cvsimport, you'll never see a merge back to the head, even if one technically took place. There may be some surprises in here! gitk --all shows

[PATCH] Add -k kill keyword expansion option to git-cvsimport

2005-08-15 Thread Martin Langhoff
our chances of detecting merges and reduce imported repository size. Signed-off: Martin Langhoff [EMAIL PROTECTED] --- Documentation/git-cvsimport-script.txt |7 ++- git-cvsimport-script | 10 ++ 2 files changed, 12 insertions(+), 5 deletions

Re: [PATCH] Add -k kill keyword expansion option to git-cvsimport

2005-08-15 Thread Martin Langhoff
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

[PATCH] Add -k kill keyword expansion option to git-cvsimport

2005-08-15 Thread Martin Langhoff
size. Signed-off: Martin Langhoff [EMAIL PROTECTED] --- Documentation/git-cvsimport-script.txt |7 ++- git-cvsimport-script | 12 +++- 2 files changed, 13 insertions(+), 6 deletions(-) 68d02ed3485e389315f33ab6387c0f1fc028b255 diff --git a/Documentation/git

Re: [PATCH] Add -k kill keyword expansion option to git-cvsimport

2005-08-15 Thread Martin Langhoff
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

Re: [PATCH] Add -k kill keyword expansion option to git-cvsimport

2005-08-15 Thread Martin Langhoff
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

Re: [PATCH] Add -k kill keyword expansion option to git-cvsimport

2005-08-15 Thread Martin Langhoff
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

Re: [ANNOUNCE] qgit-0.9

2005-08-15 Thread Martin Langhoff
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

Re: Switching heads and head vs branch after CVS import

2005-08-15 Thread Martin Langhoff
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

Re: Switching heads and head vs branch after CVS import

2005-08-15 Thread Martin Langhoff
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

Mergeback patch - (was: Switching heads and head vs branch after CVS import)

2005-08-15 Thread Martin Langhoff
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

How do I track pu branch?

2005-08-15 Thread Martin Langhoff
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

Re: How do I track pu branch?

2005-08-15 Thread Martin Langhoff
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

[PATCH] Add -k kill keyword expansion option to git-cvsimport - revised

2005-08-15 Thread Martin Langhoff
exploration of the different -k modes in the cvs protocol, we use -kk which kills keyword expansion wherever possible. Against the protocol spec, -ko and -kb will sometimes expand keywords. Should improve our chances of detecting merges and reduce imported repository size. Signed-off: Martin

[PATCH] Add merge detection to git-cvsimport

2005-08-16 Thread Martin Langhoff
are bogus or incomplete, the resulting branches are in better state to go forward (and merge) than without any merge detection. Signed-off-by: Martin Langhoff [EMAIL PROTECTED] --- Documentation/git-cvsimport-script.txt | 13 - git-cvsimport-script | 48

Re: Importing from CVS issues

2005-08-16 Thread Martin Langhoff
I haven't seen this problem myself. There are some recent patches Junio merged that handle some oddities better. Give the 'pu' branch a go if you can. I take it that the repo is not public. I'd like to try and reproduce the problem. Can you get it to happen with a public repository? For

Re: [PATCH] Add -k kill keyword expansion option to git-cvsimport

2005-08-16 Thread Martin Langhoff
On 8/16/05, Junio C Hamano [EMAIL PROTECTED] wrote: However, the -kk change one is a corrupted patch and does not apply. Your MUA ate leading whitespaces, perhaps. I stupidly did a forward. Rebased to your current pu branch and sent. From now on I'll be sending straight from cmdline. I have

Re: [RFC] Patches exchange is bad?

2005-08-16 Thread Martin Langhoff
On 8/17/05, Marco Costalba [EMAIL PROTECTED] wrote: What do you think? From what I understand, you'll want the StGIT infrastructure. If you use git/cogito, there is an underlying assumption that you'll want all the patches merged across, and a simple cg-update will bring in all the pending

Re: [PATCH] Add merge detection to git-cvsimport

2005-08-16 Thread Martin Langhoff
On 8/16/05, Sven Verdoolaege [EMAIL PROTECTED] wrote: On Tue, Aug 16, 2005 at 10:35:27PM +1200, Martin Langhoff wrote: + +sub get_headref($$) { If you want to check whether a ref is valid, then it is better to use git-rev-parse... We are reading/writing directly to .git/refs/heads/ a lot

Re: FUNKY tags.

2005-08-16 Thread Martin Langhoff
On 8/17/05, Dave Jones [EMAIL PROTECTED] wrote: I've no idea what I did when I tagged those trees, but according to a google search, cvsps does that when it find patchsets which are chronologically (and thus by patchset id) earlier than the tag, but are tagwise after. Spooky. It's probably

Re: FUNKY tags.

2005-08-17 Thread Martin Langhoff
On 8/17/05, Dave Jones [EMAIL PROTECTED] wrote: In my case, at least the most recent of those cvs tag operations was just a 'cvs tag x86info-1_14'. Nothing fancy. I'm fairly sure there was nothing fancy about the earlier instance either. So sure in fact, I had to look up that -F flag in the

Re: [RFC] Patches exchange is bad?

2005-08-17 Thread Martin Langhoff
On 8/17/05, Marco Costalba [EMAIL PROTECTED] wrote: Of course I can feed proper subject and description to git-commit but I would like to find something less intrusive I don't know if it helps, but I think that StGIT is what you are looking for, not only because you have more tools to deal

Small team cogito/git setup

2005-08-17 Thread Martin Langhoff
We have a small team of 3, and our main activity is to run local branches of upstream projects, plus some local development. In that context, I am designing our cogito/git usage strategy, and I'm interested in comments. My intention is to use cogito as much as possible, and insulate our team from

Re: Small team cogito/git setup

2005-08-18 Thread Martin Langhoff
On 8/18/05, Martin Langhoff [EMAIL PROTECTED] wrote: We have a small team of 3, and our main activity is to run local To self: RTFM, specifically, Documentation/tutorial.txt I had read it early on and either didn't get to the end of it, or had forgotten already. Apologies, martin

Questions on 'cvs migration guide''

2005-08-18 Thread Martin Langhoff
In the section 'Emulating CVS behaviour', where the team setup is described with a team 'merger'. What is not clear is how to deal with project-wide branches. Should they be created in the master repo, and everyone clone a new repo from it? With a team of 10 people, and perhaps 4 or 5 branches,

Cannot use cg-clone over http after packing a public repo

2005-08-18 Thread Martin Langhoff
With todays git and cogito: moodle-git-merge$ git-push-script --all ~/public_html/repos/moodle.git This unpacked the repo completely, in spite if it being local. Anyway, from a remote machine I could do cg-clone and it succeeded, though it took ages: cg-clone

Re: Cannot use cg-clone over http after packing a public repo

2005-08-18 Thread Martin Langhoff
Resolved. I was missing a call to git-update-server-info. It fails to make the objects/info directory, so that had to be done manually. GIT_DIR=~/public_html/repos/moodle.git git-update-server-info error: cannot open /home/martin/public_html/repos/moodle.git/objects/info/packs+ mkdir

[RFC] Importing from a patch-oriented SCM

2005-08-19 Thread Martin Langhoff
I am drafting an import script to turn a GNU Arch into a GIT archive. Importing the branches and commits increamentally is reasonably straightforward -- or so it seems so far. Note: the repository manipulation is based on cvsimport -- so my knowledge of the git repo internals is still pertty close

[RFC] cg-log -r order:matters

2005-08-23 Thread Martin Langhoff
It's sometimes unclear which head is ahead of the other. If I get the order wrong, cg-log shows no log output. Is this expected? I was expecting a warning, or a reverse-ordered log. Or both. ;) martin - To unsubscribe from this list: send the line unsubscribe git in the body of a message to

Re: arch2git import script

2005-08-23 Thread Martin Langhoff
On 8/24/05, Martin Langhoff [EMAIL PROTECTED] wrote: First draft of an Arch import. And now, with sample script attached, too. cheers, martin git-archimport-script Description: Binary data

git-archimport-script - 2nd iteration

2005-08-24 Thread Martin Langhoff
Gave the code another pass. The code should be more readable, and make a bit more sense. It now: - handles commit timestamps correctly - handles binary files correctly - uses parselog() to tell git-update-cache what's been added/deleted/modified - much faster commits on large trees - gets the

Re: Storing state in $GIT_DIR

2005-08-25 Thread Martin Langhoff
Linus, I like the solution you are suggesting, but I suspect it will create more problems that it will solve, and while the coolness factor is drawing me in we ain't gonna need it, as the xp people say. More below... On 8/26/05, Linus Torvalds [EMAIL PROTECTED] wrote: Git won't care, so

Re: Storing state in $GIT_DIR

2005-08-25 Thread Martin Langhoff
On 8/26/05, Linus Torvalds [EMAIL PROTECTED] wrote: OTOH, storing the metadata in a branch will allow us to run the import in alternating repositories. But as Junio points out, unless I can guarantee that the metadata and the tree are in sync, I cannot trivially resume the import cycle

Re: Merges without bases

2005-08-26 Thread Martin Langhoff
On 8/26/05, Junio C Hamano [EMAIL PROTECTED] wrote: their core GIT tools come from. But how would _I_ pull from that My Project, if I did not want to pull unrelated stuff in? and then... What I think _might_ deserve a bit more support would be a merge of a foreign project as a subdirectory

Re: Merges without bases

2005-08-27 Thread Martin Langhoff
On 8/27/05, Daniel Barkalow [EMAIL PROTECTED] wrote: The problem with both of these (and doing it in the build system) is that, when a project includes another project, you generally don't want whatever revision of the included project happens to be the latest; you want the revision of the

Re: Status of Mac OS/X ports of git and cogito?

2005-08-27 Thread Martin Langhoff
I am running git/cogito on MacOSX 10.3.x mostly as a client, and it works pretty well. My main dev machines are Debian boxes, so the OSX build is most often just fetching commits and running cg-log. So it's not very intensive ;) I get all my build dependencies from Fink, and also get diffutils

Re: cvsimport error: need a valid pathname

2005-08-27 Thread Martin Langhoff
On 8/28/05, Kalle Valo [EMAIL PROTECTED] wrote: The documentation says that it should be possible to update incrementally from the CVS repository. Am I doing something wrong or is this a bug? It _should_ work the way you are running it, so consider it a bug. Do you think you can do some

Re: Status of Mac OS/X ports of git and cogito?

2005-08-29 Thread Martin Langhoff
On 8/27/05, Martin Langhoff [EMAIL PROTECTED] wrote: There is _one_ bug I've seen with cg-diff and I haven't had time to fix. On OSX, running cg-diff with no parameters doesn't show anything. For some reason, it fails to list the files. If you give it the paths explicitly, it'll give you

Re: question git branches

2005-08-29 Thread Martin Langhoff
On 8/29/05, Ben Greear [EMAIL PROTECTED] wrote: I created a new branch 'ben_dev_rfcnt'. Now, I also have another patch that I wanted to pull into git. Before merging this, I created another branch 'foo'. I changed to this branch foo and imported my patch and resolved the conflicts, etc.

Cogito Petr dormant?

2005-08-29 Thread Martin Langhoff
Petr's tree in kernel.org hasn't been updated for 2 weeks, and we haven't seen him on the list for about 2 weeks too. Is he on holiday or otherwise MIA? Yesterday I got a bunch of patches from a cow-orker to get cogito-0.13 debian build scripts to work correctly, and when I looked at the cogito

[PATCH] cg-diff fixed to work with BSD xargs

2005-08-30 Thread Martin Langhoff
Calls to cg-diff without filename parameters were dependent on GNU xargs traits. BSD xargs is hardcoded to do --no-run-if-empty -- so if the filter is effectively empty we avoid calling xargs. Signed-off-by: Martin Langhoff [EMAIL PROTECTED] --- cg-diff |6 +- 1 files changed, 5

Re: Status of Mac OS/X ports of git and cogito?

2005-08-30 Thread Martin Langhoff
On 8/29/05, Martin Langhoff [EMAIL PROTECTED] wrote: Blame the xargs implementation. Fixed. I posted the patch at the same time that I was writing this, but it got eaten by a b0rken MTA setup on my laptop. Reposted. cheers, martin - To unsubscribe from this list: send the line unsubscribe git

[PATCH] cg-update - refuse to update dirty tree

2005-08-30 Thread Martin Langhoff
cg-merge currently clobbers local changes while runnign cg-update. Do the safe thing and refuse to update on a dirty tree. Signed-off-by: Martin Langhoff [EMAIL PROTECTED] --- cg-update |4 1 files changed, 4 insertions(+), 0 deletions(-) 7a961c02ee6228c2a80869b4b3f179a7e279df8e

[PATCH] Initial import of git-archimport-script

2005-08-30 Thread Martin Langhoff
' Signed-off-by: Martin Langhoff [EMAIL PROTECTED] --- diff --git a/git-archimport-script b/git-archimport-script new file mode 100755 --- /dev/null +++ b/git-archimport-script @@ -0,0 +1,593 @@ +#!/usr/bin/perl -w +# +# This tool is copyright (c) 2005, Martin Langhoff. +# It is released under the Gnu

Re: Replay on arbitrary branches

2005-09-02 Thread Martin Langhoff
Agreed on the impossibility of 3-way merges with binary files. In the branch I want to replay, though, I have commits that add and change binary files. About 'unrelated' trees, if you know of a good tree you can use setup snipped $ git-read-tree -m -u c master b $ git-merge-cache -o

Re: Could not interpret heads/dbrt-test as something to pull

2005-09-04 Thread Martin Langhoff
On 9/4/05, Kalle Valo [EMAIL PROTECTED] wrote: I was trying to clone the git repository this morning and it fails every time: got 15891f81e0fa99333ad81e9271df5b2a72ba368e error: Couldn't get http://www.kernel.org/pub/scm/git/git.git/refs/heads/dbrt-test for heads/dbrt-test Tried to repro,

[PATCH] archimport: avoid committing on an Arch tag

2005-09-04 Thread Martin Langhoff
Arch tags are full commits (without any changed files) as well. Trust Arch to have put an unchanged tree in place (which seems to do reliably), and just add a tag new branch. Speeds up Arch imports significantly, and leaves history in a much saner state. Signed-off-by: Martin Langhoff [EMAIL

[PATCH] archimport autodetects import status, supports incremental imports

2005-09-04 Thread Martin Langhoff
If there is no GIT directory, archimport will assume it is an initial import. It now also supports incremental imports, skipping seen commits. You can now run it repeatedly to pull new commits from the Arch repository. Signed-off-by: Martin Langhoff [EMAIL PROTECTED] --- git-archimport

Re: [PATCH 0/2] Update git-send-email-script with --compose

2005-09-05 Thread Martin Langhoff
Ryan, is it possible to fix the git-send-email script to just work reading in the emails that `git-format-patch-script -o patchdir origin` generates? I have a very ugly local patch to git-send-email-script that - reads from from git-var, can be overridden by passing an explicit --from - reads

Re: [PATCH 0/2] Update git-send-email-script with --compose

2005-09-05 Thread Martin Langhoff
On 9/6/05, Junio C Hamano [EMAIL PROTECTED] wrote: Ryan Anderson [EMAIL PROTECTED] writes: Sorry about that - I always export using git-format-patch using --mbox, and those work nicely. I'm a bit reluctant to do the [PATCH] fixup, but I think I will: Thanks Ryan for the clarification! I

Re: [PATCH 0/2] Update git-send-email-script with --compose

2005-09-05 Thread Martin Langhoff
On 9/6/05, Junio C Hamano [EMAIL PROTECTED] wrote: Not really; --mbox output is one-file-per-patch and it is up to you which ones to pick and concatenate them in what order, if you want them in a single file. Hr. Then I better hide away in a little cave, and shut my big mouth up. ;-) It

Re: Tool renames? was Re: First stab at glossary

2005-09-05 Thread Martin Langhoff
On 9/6/05, Linus Torvalds [EMAIL PROTECTED] wrote: Grepping for strings. For example, when renaming a binary, the sane way to check that you fixed all users right now is grep old-binary-name *.c *.h *-scripts and you catch all users. Grep knows how to ignore binary files. Try:

Re: Tool renames? was Re: First stab at glossary

2005-09-06 Thread Martin Langhoff
On 9/6/05, Linus Torvalds [EMAIL PROTECTED] wrote: That wasn't the _point_. Agreed - sorry I should have qualified my comment. I agree with having useful extensions for ease of development. And I agree with the suggestion of installing them with stripped extensions -- to extend the abstraction.

Re: [PATCH] git-cvsimport-script: handling of tags

2005-09-06 Thread Martin Langhoff
On 9/7/05, H. Peter Anvin [EMAIL PROTECTED] wrote: Martin Langhoff wrote: Tell me more about how you are trying the 'recognize merge'. It is a pretty unsophisticated thing, as it trusts the commit message in the first place. But when it works, it works. Perhaps it would be good

Re: [PATCH] git-cvsimport-script: handling of tags

2005-09-06 Thread Martin Langhoff
On 9/7/05, H. Peter Anvin [EMAIL PROTECTED] wrote: This patch changes git-cvsimport-script so that it creates tag objects instead of refs to commits, and adds an option, -u, to convert underscores in branch and tag names to dots (since CVS doesn't allow dots in branches and tags.) looks good.

gitweb feature request: tarball for each commit

2005-09-07 Thread Martin Langhoff
With Archzoom, when looking at a particular commit/cset you get a small [tarball] link that does an 'export' of the whole tree at that patchlevel and tars it up for the user. It's heavy on the server and bandwidth, but if you can afford it, it is mighty useful to push out patches immediately to

Re: gitweb feature request: tarball for each commit

2005-09-08 Thread Martin Langhoff
Yes, this is nice for smaller projects. But I don't think, that we want to do such a thing on the kernel.org servers. I think this is a very useful feature for for some, but not all, repositories. Default it to off and have a magic file (like git-daemon), or a config variable turn it on.

Re: git with large files...

2012-07-20 Thread Martin Langhoff
On Fri, Jul 20, 2012 at 6:54 PM, Randal L. Schwartz mer...@stonehenge.com wrote: Darek == Darek Bridges darek.brid...@me.com writes: Darek I use git for many things, but I am trying to work out the Darek workflow to use git for deployment. Don't. Heh. Best to keep in mind that it just

Re: git with large files...

2012-07-21 Thread Martin Langhoff
On Fri, Jul 20, 2012 at 11:47 PM, David Aguilar dav...@gmail.com wrote: I'm not sure if it was the big files part that Randal was responding to. IIUC it was the using git for deployment part. Packaging tools (Makefiles, .rpm, .deb, etc) are a better suited for deploying software. Fair

Re: git with large files...

2012-07-21 Thread Martin Langhoff
On Sat, Jul 21, 2012 at 3:11 AM, Elia Pinto gitter.spi...@gmail.com wrote: Well, many folks use puppet in serverless configuration pushing the manifest from a central git server via cron and applying locally the configuration fetched. In this sense git IS used for deployement. And, for a

Re: A new way to get a sha1?

2012-07-30 Thread Martin Langhoff
On Mon, Jul 30, 2012 at 11:45 AM, Junio C Hamano gits...@pobox.com wrote: git show -s ':/^t1100-.*: Fix an interm' That doesn't work for me (git 1.7.10.4 as per Fedora 18 rpms) in git.git. But the idea is sound -- git can give you the sha1 trivially. You don't need additional glue. But

Re: A new way to get a sha1?

2012-07-30 Thread Martin Langhoff
On Mon, Jul 30, 2012 at 2:29 PM, Junio C Hamano gits...@pobox.com wrote: The idea was that you do not have to give abbreviated SHA-1 to Git in the first place. Ah, sorry, I didn't get _that_ point. I thought you were trying to demo a way to get a sha1. What doesn't work? My copy of v1.7.10.1

  1   2   >