{"thread":{"id":"6234","subject":"a few remaining issues...","startedAt":"2007-01-05T11:06:46Z","lastAt":"2007-01-10T13:56:10Z","messageCount":16,"participants":["Junio C Hamano","Alex Riesen","Johannes Schindelin","Juergen Ruehle","Shawn O. Pearce"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"30875","messageId":"7v7iw1hgvt.fsf@assigned-by-dhcp.cox.net","threadId":"6234","inReplyTo":null,"subject":"a few remaining issues...","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-05T11:06:46Z","receivedAt":"2007-01-05T11:06:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"This is not meant to be an exhaustive list, and I probably will\nchange my mind after I sleep on them, but before I go to bed,\nhere are a handful of glitches I think are worth fixing.\n\n* Bare repository.\n\nWe have a heuristic to determine bareness and change our\nbehaviour (albeit slightly) based on it.  The heuristic is not\nperfect, but the intent is to avoid things that are undesirable\nfor bare repository when we know (or guess) it is one, and allow\nthe repository owner to override if we guessed wrong.  Currently\nthe only such \"undesirable thing\" is the use of reflog even when\ncore.logallrefupdates is not set, but we have an RFC patch\nfloating around to forbid working-tree operations in a bare\nrepository to prevent accidents from happening.  I think at that\npoint it may be prudent to also give users a way to mark a bare\nrepository explicitly as such, say, with \"core.bare = true\".\nRepository creation by init-db and clone with --bare option can\nautomatically set this, so adding this should not be too painful\nfor the users.\n\n* Packed refs.\n\n'git-pack-refs --all' leaves heads/ unpacked because they are\nexpected to change often, but it packs remotes/.  This does not\nmake any sense (it is another fallout from \"separate remote\"\nlayout that many people pushed, even though I was mildly against\nit and mostly uninterested in it, and in the retrospect I think\nthey did not know about or knew but did not tell me about issues\nlike this, which makes me somewhat unhappy X-<).  I'd like to\nchange the command not to pack anything but tags/ hierarchy.\nThis keeps bases/ used by StGIT unpacked, which makes a lot of\nsense -- the hierarchy is even more volatile than heads/.\n\n'git-pack-refs' should default to --prune.  There is no point\nnot to, really.\n\n'git-pack-refs' should probably learn how to unpack, although\nthere is no real need for it.\n\n* Remote management.\n\nI pushed out 'git-remote' in 'next' tonight, but as I said, I\nthink it does very limited things it should do in the current\nshape.  What it involves is just scripting and requires no deep\ncore knowledge, so it might be a good project to enhance on for\nnew people.\n\nOften people suggest \"git checkout -b next origin/next\" to add\nbranch.next.remote = origin and branch.next.merge = refs/heads/next.\n\nI do not think it should be the default, but I do understand why\npeople would want this (what I mean is that I do not think -b\ndoes not imply you would want to keep tracking and merging from\nthere for almost all the time -- rather I would suspect it would\nbe 50:50 thing), so I am not opposed to add an easy way to ask\nfor these two variables to be set up when the new branch is\nmade.  Perhaps \"git checkout -B\"?\n\n* Handling paths that are unknown to the index.\n\nI sent out patches tonight to teach \"git reset <tree> -- <path>\"\nto restore the absense of path in the index from the tree\ntonight.  There was another one recently brought up on the list:\n\"git commit -- <path>\" for path that is no longer known to the\nindex.  While jumping the index is a practice I particularly do\nnot want to encourage by extending git to support it, we already\nhave support for most of the cases, so I think it makes sense to\ndo this for consistency.  I haven't thought about the necessary\nchanges yet, so people can beat me if they want to.  My vague\nidea is to check HEAD to see if <path> exists and if so refrain\nfrom complaining.\n\n* Detached HEAD.\n\nYou've seen an experimental patch, discussion, and a few\nfollow-up patches, all in 'pu'.  I'm not actively looking at\nthis right now.\n\n* Reflogs.\n\n'git reflog show' needs to be done -- and preferrably in a way\nthat does not add too much code.\n\nAfter rebasing a huge series, you need to know that N patches\nwere involved and have to say HEAD@{N}, instead of HEAD@{1}.\nThis is unfortunate --- we might want to find a way to make the\nreflog's recording granularity match the user operation\ngranularity better.  But this is probably a fairly intrusive\nchange we would not want right now.\n\n* Misconfigured \"tracking branch\" refspecs.\n\nThere is a special hack in git-pull that passes --update-head-ok\nto git-fetch.  This is a workaround for a case where underlying\ngit-fetch is told to update the current branch that is also used\nas a tracking branch.  This can happen either because the user\nmisconfigured \"Pull: refs/heads/master:refs/heads/master\", or\nthe user checked out a tracking branch to take a peek, and\nforgot he was on such a branch and issued \"git pull\".  Both are\nmuch less likely to happen in the separate remote layout, and I\nthink we should deprecate both --update-head-ok flag in\ngit-fetch and support for this situation in git-pull.\n\nInstead, we should unconditionally allow fetching into the\ncurrent branch for bare repositories.\n\nThe reason we should not allow fetching into the current branch\nfor a repository with a working tree is that allowing so will\nmake the index and working tree useless.  Such a fetch updates\nthe value of HEAD, and after that happens the old value of HEAD\nis lost and, there is no way to even run a 3-way merge between\nthe (old) HEAD, index and the working tree.  Even if the old\nvalue of HEAD is kept somewhere before the fetch happens (which\nis what --update-head-ok code allows git-pull to do), the\ndifference between old HEAD and HEAD needs to be propagated to\nboth index and the working tree separately, so it involves two\n3-way merges, which is way complicated than it is really worth.\n\n* Topic management.\n\nIn 'todo' branch there is a git-topic script I use to generate\nthe \"What's cooking\" messages.  Although the script in its\ncurrent form is probably too specific to my workflow (which has\none baseline with two development branches, and names topics in\ncertain ways -- the latter is customizable from the command\nline), I think something like that may be useful for people who\nneed to manage multiple topic branches.\n"},{"id":"30880","messageId":"81b0412b0701050327u6bf2a716s1fb38fb62e2ebb9d@mail.gmail.com","threadId":"6234","inReplyTo":"7v7iw1hgvt.fsf@assigned-by-dhcp.cox.net","subject":"Re: a few remaining issues...","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-01-05T11:27:55Z","receivedAt":"2007-01-05T11:27:55Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 1/5/07, Junio C Hamano <junkio@cox.net> wrote:\n> This is not meant to be an exhaustive list, and I probably will\n> change my mind after I sleep on them, but before I go to bed,\n> here are a handful of glitches I think are worth fixing.\n\nMaybe we should at least mention another cygwin quirk:\ncygwin (or is it its bash?) treats .exe files and +x-files without\nextension somehow stupid: it prefers the file without extension\nto the .exe. For example, after installation of git-merge-recursive\nyou have the old python script and git-merge-recursive.exe in\nthe same directory. Guess which one is used... Right, the old\npython script. Same for count-objects and other recently\nrewritten scripts.\n"},{"id":"30885","messageId":"Pine.LNX.4.63.0701051453520.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6234","inReplyTo":"7v7iw1hgvt.fsf@assigned-by-dhcp.cox.net","subject":"Re: a few remaining issues...","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-05T13:55:46Z","receivedAt":"2007-01-05T13:55:46Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 5 Jan 2007, Junio C Hamano wrote:\n\n> * Reflogs.\n> \n> 'git reflog show' needs to be done -- and preferrably in a way that does \n> not add too much code.\n\nI do not have time to follow up on my earlier attempts to teach git-log \nabout traversing reflogs instead of the commit parents. But Shawn had a \nworking proposal, didn't he?\n\nCiao,\nDscho\n"},{"id":"30889","messageId":"17822.33497.895000.694542@lapjr.intranet.kiel.bmiag.de","threadId":"6234","inReplyTo":"7v7iw1hgvt.fsf@assigned-by-dhcp.cox.net","subject":"Re: a few remaining issues...","fromName":"Juergen Ruehle","fromEmail":"j.ruehle@bmiag.de","sentAt":"2007-01-05T16:54:49Z","receivedAt":"2007-01-05T16:54:49Z","isPatch":false,"sender":{"key":"j.ruehle@bmiag.de","avatar":null},"body":"Junio C Hamano writes:\n > * Handling paths that are unknown to the index.\n > \n > I sent out patches tonight to teach \"git reset <tree> -- <path>\"\n > to restore the absense of path in the index from the tree\n > tonight.  There was another one recently brought up on the list:\n > \"git commit -- <path>\" for path that is no longer known to the\n > index.  While jumping the index is a practice I particularly do\n > not want to encourage by extending git to support it, we already\n > have support for most of the cases, so I think it makes sense to\n > do this for consistency.  I haven't thought about the necessary\n > changes yet, so people can beat me if they want to.  My vague\n > idea is to check HEAD to see if <path> exists and if so refrain\n > from complaining.\n\nThis looks like a job for your para-walk topic. For this git-commit\ncase we just need a\n\n  git-ls --no-workdir --error-unmatch HEAD -- <pattern>...\n\nto replace git-ls-files. To my untrained eyes it looks like this is\nmostly there (AFAICS it doesn't do pattern matching and the\n--error-unmatch thingy).\n"},{"id":"30895","messageId":"20070105193306.GB8753@spearce.org","threadId":"6234","inReplyTo":"Pine.LNX.4.63.0701051453520.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: a few remaining issues...","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-05T19:33:06Z","receivedAt":"2007-01-05T19:33:06Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> On Fri, 5 Jan 2007, Junio C Hamano wrote:\n> \n> > * Reflogs.\n> > \n> > 'git reflog show' needs to be done -- and preferrably in a way that does \n> > not add too much code.\n> \n> I do not have time to follow up on my earlier attempts to teach git-log \n> about traversing reflogs instead of the commit parents. But Shawn had a \n> working proposal, didn't he?\n\nYes, but my proposal added a lot of code.  Junio's comment is that\nhe would prefer one that doesn't, such as by reusing as much of the\nrevision listing machinary as possible.  Which you had looked into\ndoing.\n\nI myself am also severly lacking in time right now.  *if* I get\nany more Git time in the next week its going to be to finish out\nsome patches on the bash-completion, so I can try to sneak them\ninto the v1.5.0 release (if possible).  Its unlikely I'll be able\nto look at a `reflog show` anytime soon.\n\n-- \nShawn.\n"},{"id":"31164","messageId":"7vr6u5uqm6.fsf@assigned-by-dhcp.cox.net","threadId":"6234","inReplyTo":"7v7iw1hgvt.fsf@assigned-by-dhcp.cox.net","subject":"Re: a few remaining issues...","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-08T21:59:29Z","receivedAt":"2007-01-08T21:59:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Updates to the previous \"remaining issues\" list before 1.5.0.\n\n* Bare repository.\n\nI think what I have in 'next' to add 'core.bare' configuration\nto make the bare repository detection safer is ready to be used\nto port the RFC patch from Shawn to forbid working-tree\noperations in a bare repository to prevent accidents from\nhappening.  It would be nice if we can cook it for a few days in\n'next' and push it out to 'master' before v1.5.0-rc1.\n\nVolunteers?\n\n\n* Packed refs.\n\n'git-pack-refs' should default to --prune.  There is no point\nnot to, really.  Objections?\n\nWe _might_ want to teach 'git-pack-refs' how to unpack, although\nthere is no real need for it.  I do not care too deeply either\nway.\n\n\n* Detached HEAD.\n\nThis is now in 'master' ;-).\n\n\n* Make -u default to 'git-am'.\n\nSince we are talking about allowing potentially incompatible UI\nchanges in v1.5.0 iff the change improves the general situation,\nI would say why not.  I'd add --no-utf8 just in case, but\npersonally I do not offhand see need for it.  Projects that want\ntheir commit log messages in legacy encoding can and should say\n\"i18n.commitencoding = EUCJP\" or somesuch and they can continue\nusing their preferred encodings without changing their tools nor\nwork habit and without having to worry about re-coding errors.\n"},{"id":"31167","messageId":"7vhcv1upxh.fsf@assigned-by-dhcp.cox.net","threadId":"6234","inReplyTo":"7vr6u5uqm6.fsf@assigned-by-dhcp.cox.net","subject":"Re: a few remaining issues...","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-08T22:14:18Z","receivedAt":"2007-01-08T22:14:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <junkio@cox.net> writes:\n\n> Updates to the previous \"remaining issues\" list before 1.5.0.\n> ...\n> * Detached HEAD.\n>\n> This is now in 'master' ;-).\n\nBzzzzzt.\n\nSorry, it is not.  Although it is in 'next' and I am hoping we\ncan straighten potential wrinkles out before -rc1.\n"},{"id":"31235","messageId":"Pine.LNX.4.63.0701091218080.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6234","inReplyTo":"20070105193306.GB8753@spearce.org","subject":"Re: a few remaining issues...","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-09T11:21:52Z","receivedAt":"2007-01-09T11:21:52Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 5 Jan 2007, Shawn O. Pearce wrote:\n\n> I myself am also severly lacking in time right now.\n\nDid you have any chance to look at the patch I posted? It adds \n\"--walk-reflogs\" option to the revision walker, and as long as there is \nreflog information, traverses the commits in that order. It also shows the \nreflog data just below the \"commit\" line.\n\nCiao,\nDscho\n"},{"id":"31274","messageId":"7vtzz0j6hf.fsf@assigned-by-dhcp.cox.net","threadId":"6234","inReplyTo":"Pine.LNX.4.63.0701091218080.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: a few remaining issues...","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-09T20:22:04Z","receivedAt":"2007-01-09T20:22:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> On Fri, 5 Jan 2007, Shawn O. Pearce wrote:\n>\n>> I myself am also severly lacking in time right now.\n>\n> Did you have any chance to look at the patch I posted? It adds \n> \"--walk-reflogs\" option to the revision walker, and as long as there is \n> reflog information, traverses the commits in that order. It also shows the \n> reflog data just below the \"commit\" line.\n\nWhat does it do when you say, for example:\n\n\tgit log --walk-reflogs master..next\n\nI couldn't make heads or tails out of the patch and did not\nunderstand what it was trying to do.  It looked as if you were\nmaking the log traversal machinery to walk _both_ reflog\n(probably from the latest to older) and the usual ancestry.\n"},{"id":"31314","messageId":"Pine.LNX.4.63.0701100051350.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6234","inReplyTo":"7vtzz0j6hf.fsf@assigned-by-dhcp.cox.net","subject":"Re: a few remaining issues...","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-09T23:53:34Z","receivedAt":"2007-01-09T23:53:34Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 9 Jan 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n> \n> > On Fri, 5 Jan 2007, Shawn O. Pearce wrote:\n> >\n> >> I myself am also severly lacking in time right now.\n> >\n> > Did you have any chance to look at the patch I posted? It adds \n> > \"--walk-reflogs\" option to the revision walker, and as long as there is \n> > reflog information, traverses the commits in that order. It also shows the \n> > reflog data just below the \"commit\" line.\n> \n> What does it do when you say, for example:\n> \n> \tgit log --walk-reflogs master..next\n\nIt means that (ideally) all revisions are shown which are in the reflog \nchain of next, and _not_ in the reflog chain of master.\n\nHowever, once the reflog traversal hits the oldest reflog entry, it \nreverts to commit parent traversal.\n\n> I couldn't make heads or tails out of the patch and did not understand \n> what it was trying to do.  It looked as if you were making the log \n> traversal machinery to walk _both_ reflog (probably from the latest to \n> older) and the usual ancestry.\n\nYes, first reflog, then usual ancestry.\n\nWould you want that changed to _only_ reflog traversal?\n\nCiao,\nDscho\n"},{"id":"31317","messageId":"20070110001619.GF30023@spearce.org","threadId":"6234","inReplyTo":"Pine.LNX.4.63.0701100051350.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: a few remaining issues...","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-10T00:16:19Z","receivedAt":"2007-01-10T00:16:19Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> On Tue, 9 Jan 2007, Junio C Hamano wrote:\n> \n> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n> > \n> > > On Fri, 5 Jan 2007, Shawn O. Pearce wrote:\n> > >\n> > >> I myself am also severly lacking in time right now.\n> > >\n> > > Did you have any chance to look at the patch I posted?\n\nNo, I had not had a chance to look at it.  I don't see the patch in\nmy inbox currently, so I must have deleted it earlier.  As much as\nI want this feature in 1.5.0's final release I don't really have\nthe time/inclination to dredge though my own local mailing list\narchives or through the online ones to locate it either.\n\nRight now I want to track down a nasty bug in git-http-fetch that I\nnoticed recently that's keeping me from tracking git.git through an\nHTTP proxy, and then I need to do some hacking on this lightweight\nsubproject implementation I'm working on.  None of the existing\nimplementations do what I needed over two weeks ago, so I'm writing\nmy own.  I really need it to be done before the end of the week.\n\n> > > It adds \n> > > \"--walk-reflogs\" option to the revision walker, and as long as there is \n> > > reflog information, traverses the commits in that order. It also shows the \n> > > reflog data just below the \"commit\" line.\n> > \n> > What does it do when you say, for example:\n> > \n> > \tgit log --walk-reflogs master..next\n> \n> It means that (ideally) all revisions are shown which are in the reflog \n> chain of next, and _not_ in the reflog chain of master.\n\nThat makes a lot of sense actually.  Cute feature.\n \n> However, once the reflog traversal hits the oldest reflog entry, it \n> reverts to commit parent traversal.\n\nThat doesn't make sense...\n\n> > I couldn't make heads or tails out of the patch and did not understand \n> > what it was trying to do.  It looked as if you were making the log \n> > traversal machinery to walk _both_ reflog (probably from the latest to \n> > older) and the usual ancestry.\n> \n> Yes, first reflog, then usual ancestry.\n> \n> Would you want that changed to _only_ reflog traversal?\n\nYes.  The old ancestry has nothing to do with my local reflog.  I\nwant to know where my reflog ends, as there's no record of that\nbranch's lifespan before that point.\n\nRight now I have a reflog on `pu` which I've had since reflogs were\nfirst introduced last summer.  Yet it only goes back to Dec 23, 2006.\nLooking at the old ancestry of pu back into last Oct isn't really\ninteresting when I'm studying what changes happened to locally.\n\n-- \nShawn.\n"},{"id":"31344","messageId":"Pine.LNX.4.63.0701100220370.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6234","inReplyTo":"20070110001619.GF30023@spearce.org","subject":"Re: a few remaining issues...","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-10T01:23:11Z","receivedAt":"2007-01-10T01:23:11Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 9 Jan 2007, Shawn O. Pearce wrote:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n>\n> > However, once the reflog traversal hits the oldest reflog entry, it \n> > reverts to commit parent traversal.\n> \n> That doesn't make sense...\n> \n> > On Tue, 9 Jan 2007, Junio C Hamano wrote:\n> > \n> > > I couldn't make heads or tails out of the patch and did not understand \n> > > what it was trying to do.  It looked as if you were making the log \n> > > traversal machinery to walk _both_ reflog (probably from the latest to \n> > > older) and the usual ancestry.\n> > \n> > Yes, first reflog, then usual ancestry.\n> > \n> > Would you want that changed to _only_ reflog traversal?\n> \n> Yes.  The old ancestry has nothing to do with my local reflog.  I\n> want to know where my reflog ends, as there's no record of that\n> branch's lifespan before that point.\n> \n> Right now I have a reflog on `pu` which I've had since reflogs were\n> first introduced last summer.  Yet it only goes back to Dec 23, 2006.\n> Looking at the old ancestry of pu back into last Oct isn't really\n> interesting when I'm studying what changes happened to locally.\n\nFair enough. It actually simplifies the patch. And if you want to dig on, \nyou can just \"git log pu@{whatever}\", right?\n\nSo, is this wanted? (If not, I'd rather spend my time on my day job...)\n\nCiao,\nDscho\n"},{"id":"31385","messageId":"Pine.LNX.4.63.0701101320300.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6234","inReplyTo":"81b0412b0701050327u6bf2a716s1fb38fb62e2ebb9d@mail.gmail.com","subject":"Re: a few remaining issues...","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-10T12:21:58Z","receivedAt":"2007-01-10T12:21:58Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 5 Jan 2007, Alex Riesen wrote:\n\n> On 1/5/07, Junio C Hamano <junkio@cox.net> wrote:\n> > This is not meant to be an exhaustive list, and I probably will\n> > change my mind after I sleep on them, but before I go to bed,\n> > here are a handful of glitches I think are worth fixing.\n> \n> Maybe we should at least mention another cygwin quirk:\n> cygwin (or is it its bash?) treats .exe files and +x-files without\n> extension somehow stupid: it prefers the file without extension\n> to the .exe. For example, after installation of git-merge-recursive\n> you have the old python script and git-merge-recursive.exe in\n> the same directory. Guess which one is used... Right, the old\n> python script. Same for count-objects and other recently\n> rewritten scripts.\n\nI just sent out a patch in my mail \"[PATCH] Makefile: add \nclean-obsolete-scripts target\" which should help.\n\nIt might be necessary (under obscure circumstances) to remake all and make \nclean-obsolete-scripts again, to remove the correct files. But in general, \nit should be fine to be called just once.\n\nCiao,\nDscho\n"},{"id":"31387","messageId":"81b0412b0701100440n6fe9e406yfe712cf236a784e2@mail.gmail.com","threadId":"6234","inReplyTo":"Pine.LNX.4.63.0701101320300.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: a few remaining issues...","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-01-10T12:40:17Z","receivedAt":"2007-01-10T12:40:17Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 1/10/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> > On 1/5/07, Junio C Hamano <junkio@cox.net> wrote:\n> > > This is not meant to be an exhaustive list, and I probably will\n> > > change my mind after I sleep on them, but before I go to bed,\n> > > here are a handful of glitches I think are worth fixing.\n> >\n> > Maybe we should at least mention another cygwin quirk:\n> > cygwin (or is it its bash?) treats .exe files and +x-files without\n> > extension somehow stupid: it prefers the file without extension\n> > to the .exe. For example, after installation of git-merge-recursive\n> > you have the old python script and git-merge-recursive.exe in\n> > the same directory. Guess which one is used... Right, the old\n> > python script. Same for count-objects and other recently\n> > rewritten scripts.\n>\n> I just sent out a patch in my mail \"[PATCH] Makefile: add\n> clean-obsolete-scripts target\" which should help.\n\nWell, you also have to give people at least notice _when_ the\ntarget should be called. It can take long time until the victim\nnotices that he has git-branch (from .sh) and git-branch(.exe).\nAnd that in two places: in the installation target directory and\nin the build directory (because in windows it is not fcking\npossible to remove \".\" from the beginning of PATH).\n\n> But in general, it should be fine to be called just once.\n\nDon't think so. We still have candidates for conversion\ninto C (git-checkout and git-commit being my favorites).\n"},{"id":"31391","messageId":"Pine.LNX.4.63.0701101442520.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6234","inReplyTo":"81b0412b0701100440n6fe9e406yfe712cf236a784e2@mail.gmail.com","subject":"Re: a few remaining issues...","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-10T13:46:12Z","receivedAt":"2007-01-10T13:46:12Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 10 Jan 2007, Alex Riesen wrote:\n\n> On 1/10/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> > > On 1/5/07, Junio C Hamano <junkio@cox.net> wrote:\n> > > > This is not meant to be an exhaustive list, and I probably will\n> > > > change my mind after I sleep on them, but before I go to bed,\n> > > > here are a handful of glitches I think are worth fixing.\n> > >\n> > > Maybe we should at least mention another cygwin quirk:\n> > > cygwin (or is it its bash?) treats .exe files and +x-files without\n> > > extension somehow stupid: it prefers the file without extension\n> > > to the .exe. For example, after installation of git-merge-recursive\n> > > you have the old python script and git-merge-recursive.exe in\n> > > the same directory. Guess which one is used... Right, the old\n> > > python script. Same for count-objects and other recently\n> > > rewritten scripts.\n> > \n> > I just sent out a patch in my mail \"[PATCH] Makefile: add\n> > clean-obsolete-scripts target\" which should help.\n> \n> Well, you also have to give people at least notice _when_ the\n> target should be called.\n\nOkay. Fair enough. So maybe this is the wrong approach: maybe the \"all\" \ntarget should look for _all_ executables if there is a script of the same \nname, and in that case remove it; and the \"install\" target should do the \nsame in the gitexecdir?\n\n> > But in general, it should be fine to be called just once.\n> \n> Don't think so. We still have candidates for conversion\n> into C (git-checkout and git-commit being my favorites).\n\nI was referring to\n\n\tmake clean-obsolete-scripts; make; make clean-obsolete-scripts\n\nbeing necessary, because the script somehow got a newer time stamp than \nthe executable.\n\nBut yes, I think there are way more candidates, my pet peeves being \ngit-ls-remote and git-fetch.\n\nCiao,\nDscho\n"},{"id":"31393","messageId":"81b0412b0701100556h1a1338d1q7c6ee99eaad60ab5@mail.gmail.com","threadId":"6234","inReplyTo":"Pine.LNX.4.63.0701101442520.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: a few remaining issues...","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-01-10T13:56:10Z","receivedAt":"2007-01-10T13:56:10Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 1/10/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> > > I just sent out a patch in my mail \"[PATCH] Makefile: add\n> > > clean-obsolete-scripts target\" which should help.\n> >\n> > Well, you also have to give people at least notice _when_ the\n> > target should be called.\n>\n> Okay. Fair enough. So maybe this is the wrong approach: maybe the \"all\"\n> target should look for _all_ executables if there is a script of the same\n> name, and in that case remove it; and the \"install\" target should do the\n> same in the gitexecdir?\n\n...but unless they're in the index and the build directory is a git repo.\nIt's going to far. I suggest just giving a word of warning on cygwin at\nat the end of build. It is the only platform broken in such a stupid way.\n"}]}