On Mon, May 13, 2013 at 2:55 PM, Jonathan Nieder wrote:
> My experience is the opposite. I wonder "What did the author of this
> nonsense comment mean?" or "What is the purpose of this strange
> condition in this if () statement?". Then "git log -S" finds the
> culprit
Only if that if () statem
On Mon, May 13, 2013 at 3:33 PM, Jonathan Nieder wrote:
> Well, no, it should find the final change that brought it into the
> current form. Just like "git blame".
>
> Has it been finding zero results in some cases where the current code
> matches the pattern? That sounds like a bug.
Ummm, mayb
On Fri, May 17, 2013 at 5:10 AM, Michael Haggerty wrote:
> For one-time imports, the fix is to use a tool that is not broken, like
> cvs2git.
As one of the earlier maintainers of cvsimport, I do believe that
cvs2git is less broken, for one-shot imports, than cvsimport. Users
looking for a one-sho
On Fri, May 17, 2013 at 9:34 AM, Andreas Krey wrote:
> On Fri, 17 May 2013 15:14:58 +, Michael Haggerty wrote:
> ...
>> We both know that the CVS history omits important data, and that the
>> history is mutable, etc. So there are lots of hypothetical histories
>> that do not contradict CVS.
On Sat, Nov 24, 2012 at 9:44 PM, Eric S. Raymond 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 maintainers, tool
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 wrote:
> Two of the three claims in this paragraph are false. The manual page
> does not tell you what is true, which is that old cvsps wi
On Wed, Jan 2, 2013 at 11:41 AM, Eric S. Raymond wrote:
> Martin Langhoff :
>> 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 in contri
On Wed, Jan 2, 2013 at 5:28 PM, Eric S. Raymond wrote:
> Martin Langhoff :
>> 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 misintepreted the subje
On Sat, Dec 22, 2012 at 12:36 PM, Eric S. Raymond wrote:
> It is pure accident that I now maintain two of these.
Maintainership is always temporary.
> Having three different tools for this job seems to me duplicative and
> pointless; two of them should probably be let die an honorable death.
Pe
On Sat, Sep 15, 2012 at 9:24 AM, Yi, EungJun 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
- http://wiki.la
On Thu, Nov 1, 2012 at 9:46 AM, René Scharfe
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 rude
> thing to say.
+
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
On Thu, May 8, 2014 at 8:58 PM, Felipe Contreras
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
package&ship? Are you planning on CC'ing the (inactive
On Fri, May 9, 2014 at 11:57 AM, Felipe Contreras
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 *single* commit, I didn
On Thu, May 8, 2014 at 9:33 PM, Felipe Contreras
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 or direction for old code s
On Fri, May 9, 2014 at 5:54 PM, Felipe Contreras
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 him. I don't know (nor care)
On Fri, May 9, 2014 at 1:44 PM, Junio C Hamano wrote:
> Eric Wong writes:
>
>> Felipe Contreras wrote:
>>> No updates since 2010, and no tests.
>>
>> Who benefits from this removal? Is this causing a maintenance
>> burden for Junio?
>
> No. See http://thread.gmane.org/gmane.comp.version-contro
On Tue, May 13, 2014 at 2:05 PM, Felipe Contreras
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 first
~ http://docs.moodle.
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
On Wed, May 14, 2014 at 3:35 PM, Felipe Contreras
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 the shots when the criteria
On Wed, May 14, 2014 at 7:28 PM, Felipe Contreras
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
this mailing list on a p
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 g
On Thu, Mar 6, 2014 at 2:17 PM, Andreas Schwab 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 grafts using git fsc
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 ?
ch
On Thu, Mar 6, 2014 at 6:26 PM, Junio C Hamano 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 -- discarding o
On Mon, Mar 10, 2014 at 1:56 PM, David Lang 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 points us
On Mon, Jun 10, 2013 at 2:11 PM, Martin von Zweigbergk
wrote:
> On Mon, Jun 10, 2013 at 9:58 AM, Felipe Contreras
> wrote:
>> On Mon, Jun 10, 2013 at 4:05 AM, Stefano Lattarini
>> wrote:
>>
You need two sides to have an argument.
>>
>>> I disagree. Unless you mean than, whenever a part beh
On Thu, Jul 25, 2013 at 10:51 AM, ксовиран 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 filenames in a wa
On Thu, Aug 8, 2013 at 4:04 PM, Ramkumar Ramachandra wrote:
> You will need to educate your contributors and potential contributors
> if you want these problems to be fixed.
TBH, I think Junio is exceedingly kind and generous with his time.
IME (and there's quite a few years of it :-) ), good co
Hi git list,
I am trying to diagnose a strange problem in a VM running as a 'git
over ssh server', with one repo which periodically grows very quickly.
The complete dataset packs to a single pack+index of ~650MB. Growth is
slow, these are ASCII text reports that use a template -- highly
compressi
On Thu, Nov 21, 2013 at 2:52 PM, Junio C Hamano wrote:
>> - if it's receiving from many pushers, it races with itself; needs
>> some lock or back-off mechanism
>
> Surely.
>
> I think these should help:
>
> 64a99eb4 (gc: reject if another gc is running, unless --force is given,
> 2013-08-08)
On Thu, Nov 21, 2013 at 10:21 AM, Martin Langhoff
wrote:
> Do client pushes over git+ssh ever trigger a repack on the server?
man git-config
[snip]
receive.autogc
By default, git-receive-pack will run "git-gc --auto" after
receiving data from git-push
When using git filter-branch --prune-empty --directory-filter foo/bar
to extract the history of the foo/bar directory, I am getting a very
strange result.
Directory foo/bar is "slow moving". Say, 22 commits out of several
thousand. I would like to extract just those 22 commits.
Instead, I get ~15
On Tue, Dec 3, 2013 at 5:44 PM, Martin Langhoff
wrote:
> As they have not been skipped, they are fully fleshed out. By this, I
> mean that we have the whole tree in place. So these 22 commits appear
> with foo/bar pulled out to the root of the project, in the midst of
> 1500 commits
On Wed, Dec 4, 2013 at 10:46 AM, Krzesimir Nowak wrote:
> On Wed, 2013-12-04 at 16:11 +0100, Jakub Narębski wrote:
>> On Wed, Dec 4, 2013 at 2:42 PM, Krzesimir Nowak
>> wrote:
>>
>> > So future reader will know what does it mean without running "perldoc
>> > perlvar".
>>
>> Hmmm... shouldn't fut
On Tue, Dec 3, 2013 at 5:44 PM, Martin Langhoff
wrote:
> Am I doing it wrong?
Looks like I was doing something wrong. Apologies about the noise.
cheers,
m
--
martin.langh...@gmail.com
- ask interesting questions
- don't get distracted with shiny stuff - working code first
Hi folks.
currently working on a project based on Moodle (the LMS that got me
into git in the first place). This is a highly modular software, and I
would like to maintain a bunch of "out of tree" modules in a single
repository, and be able to publish them in "per-module" repositories.
So I would
On Wed, Dec 4, 2013 at 6:01 PM, Martin Langhoff
wrote:
> Is there a reasonable approach to scripting this?
Found my answers.
The 'subtree' merge strategy is smart enough to "mostly" help here.
However, it does not handle new files created in the subdirectory.
My work
On Thu, Dec 5, 2013 at 2:18 PM, Jens Lehmann wrote:
> Without knowing more I can't think of a reason why submodules should
> not suit your use case (but you'd have to script branching and tagging
> yourself until these commands learn to recurse into submodules too).
The submodules feature is way
On Thu, Dec 5, 2013 at 2:54 PM, Jens Lehmann wrote:
> Am 05.12.2013 20:27, schrieb Martin Langhoff:
>> On Thu, Dec 5, 2013 at 2:18 PM, Jens Lehmann wrote:
>>> Without knowing more I can't think of a reason why submodules should
>>> not suit your use case (but yo
Tested with git 1.7.12.4 (Apple Git-37) and git 1.8.3.1 on F20.
$ mkdir foo
$ cd foo
$ git init
Initialized empty Git repository in /tmp/foo/.git/
$ mkdir -p modules/boring
$ mkdir -p modules/interesting
$ touch modules/boring/lib.c
$ touch modules/interesting/other.c
$ touch modules/interesting/l
On Fri, Dec 6, 2013 at 3:48 AM, Jens Lehmann wrote:
> Right you are, we need tutorials for the most prominent use cases.
In the meantime, are there any hints? Emails on this list showing a
current "smart" workflow? Blog posts? Notes on a wiki?
>> Early git was very pedantic, and over time it lea
On Wed, Dec 11, 2013 at 7:17 PM, Eric S. Raymond wrote:
> I tried very hard to salvage this program - the ability to
> remote-fetch CVS repos without rsync access was appealing
Is that the only thing we lose, if we abandon cusps? More to the
point, is there today an incremental import option, out
On Wed, Dec 11, 2013 at 11:26 PM, Eric S. Raymond wrote:
> You'll have to remind me what you mean by "incremental" here. Possibly
> it's something cvs-fast-export could support.
User can
- run a cvs to git import at time T, resulting in repo G
- make commits to cvs repo
- run cvs to git impor
On Thu, Dec 12, 2013 at 12:17 PM, Andreas Krey wrote:
> But anyway, the replacement question is a) how fast the cvs-fast-export is
> and b) whether its output is stable
In my prior work, the "better" CVS importers would not have stable
output, so were not appropriate for incremental imports.
And
On Thu, Dec 12, 2013 at 1:15 PM, Eric S. Raymond wrote:
> That terminology -- "flying fish" and "dovetail" -- is interesting, and
> I have not heard it before. It might be woth putting in the Jargon File.
> Can you point me at examples of live usage?
The canonical reference would be
http://cvsbo
On Thu, Dec 12, 2013 at 1:29 PM, Eric S. Raymond wrote:
> I am almost certain the output of cvs-fast-export is stable. I
> believe the output of cvsps-3.x was, too. Not sure about 2.x.
IIRC, making the output stable is nontrivial, specially on branches.
Two cases are still in my mind, from when
On Thu, Dec 12, 2013 at 2:39 PM, Eric S. Raymond wrote:
> Yikes! That is a much stricter stability criterion than I thought you
> were specifying.
:-) -- cvsps's approach is: if you have a cache, you can remember the
lies you told earlier.
It is impossible to be stable purely from the source da
On Thu, Dec 12, 2013 at 3:58 PM, Eric S. Raymond wrote:
>> - regardless of commit ids, do you synthesize an artificial commit?
>> How do you define parenthood for that artificial commit?
>
> Because tagging is never used to deduce changesets, the case does not arise.
So if a branch has a nonsens
On Thu, Dec 12, 2013 at 6:04 PM, Eric S. Raymond wrote:
> I'm not sure what counts as a nonsensical branching point. I do know that
> Keith left this rather cryptic note in a REAME:
Keith names exactly what we are talking about. At that time, Keith was
struggling with the old xorg cvs repo which
On Wed, Dec 18, 2013 at 11:27 AM, Eric S. Raymond wrote:
>> Anyway I hope that incremental CVS import would be needed less
>> and less as CVS is replaced by any more modern version control system.
>
> I agree. I have never understood why people on this list are attached to it.
I think I have ans
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 hand
On Tue, Jan 14, 2014 at 9:54 AM, Martin Langhoff
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/re
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 ol
On Tue, Jan 14, 2014 at 2:36 PM, Martin Fick 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 the .lock files we
On Tue, Jan 14, 2014 at 8:51 PM, Duy Nguyen 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, but
the trivia
On Wed, Jan 15, 2014 at 4:12 AM, Jeff King 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 stale bits me
On Wed, Jan 15, 2014 at 12:49 PM, Junio C Hamano 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 it stale.
Can
On Sun, Feb 2, 2014 at 4:07 PM, Todd Zullinger 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 mockbuild
On Tue, Feb 20, 2018 at 5:00 PM, Julius Musseau wrote:
> I was hoping to concoct a situation where "git pull --rebase" makes a
> mess of things.
It breaks quite easily with some workflows. They are all in the "don't
do that" territory.
Open a long-lived feature-dev branch, work on it. Other folk
nkedin.com/in/martinlanghoff
- don't be distracted~ http://github.com/martin-langhoff
by shiny stuff
com
- ask interesting questions ~ http://linkedin.com/in/martinlanghoff
- don't be distracted~ http://github.com/martin-langhoff
by shiny stuff
e same codebase compressed really well in git. I've
also seen projects where storage space is ~101% of the "uncompressed"
size.
my 2c,
m
--
martin.langh...@gmail.com
- ask interesting questions ~ http://linkedin.com/in/martinlanghoff
- don't be distracted ~ http://
sting questions ~ http://linkedin.com/in/martinlanghoff
- don't be distracted~ http://github.com/martin-langhoff
by shiny stuff
On Sun, Nov 4, 2018 at 2:34 PM _g e r r y _ _l o w r y _
wrote:
>
> [1a] Which do you prefer: Git GUI, Git command line?
git cli
>
> [1b] What is your reason for your [1a] preference?
I'm a cli guy, I know git well, and it gives me all the power.
However, understanding history/branch struct
't be distracted~ http://github.com/martin-langhoff
by shiny stuff
l and hurt themselves with something else, but
that's part of removing sharp edges from a product.
cheers,
m
--
martin.langh...@gmail.com
- ask interesting questions ~ http://linkedin.com/in/martinlanghoff
- don't be distracted~ http://github.com/martin-langhoff
by shiny stuff
tin.langh...@gmail.com
- ask interesting questions ~ http://linkedin.com/in/martinlanghoff
- don't be distracted~ http://github.com/martin-langhoff
by shiny stuff
interesting questions ~ http://linkedin.com/in/martinlanghoff
- don't be distracted ~ http://github.com/martin-langhoff
by shiny stuff
--
martin.langh...@gmail.com
- ask interesting questions ~ http://linkedin.com/in/martinlanghoff
- don't be distracted~ http:
no wrote:
>
> Forwarding to Jonathan, as I think this is an interesting supporting
> vote for the topic that we were stuck on.
>
> Eric Wong writes:
>
> > Martin Langhoff wrote:
> >> Hi folks,
> >>
> >> Long time no see! Importing a 3GB (~25K revs, tons o
temporary state?
Yeah, thats suspicious and I don't know why. I've worked on other
importers and while those needed 'gc' to generate packs, they didn't
generate garbage objects. After gc, the repo was "clean".
cheers,
m
--
martin.langh...@gmail.com
- a
- ask interesting questions ~ http://linkedin.com/in/martinlanghoff
- don't be distracted~ http://github.com/martin-langhoff
by shiny stuff
langh...@gmail.com
- ask interesting questions ~ http://linkedin.com/in/martinlanghoff
- don't be distracted~ http://github.com/martin-langhoff
by shiny stuff
ution db
automagically? rerere is plenty automagic already...
cheers,
m
--
martin.langh...@gmail.com
- ask interesting questions ~ http://linkedin.com/in/martinlanghoff
- don't be distracted~ http://github.com/martin-langhoff
by shiny stuff
101 - 174 of 174 matches
Mail list logo
