Re: Merges without bases
Darrin Thompson wrote: What I'm going to do is actually an inversion of that. Publishing a repository with the _intent_ of being merged into existing history, and observing obvious naming conventions as the prior arrangement. I thought once I got the initial baseless merges done and committed that I do fetch-octopus from that point on. But octopus was still complaining about not finding a merge base. I'm going to verify that I didn't just mess something up in the process. If I can get octopus working as the tool for doing merges _after_ the baseless merges then I can live with the current situation. Heh. Git repositories as components. -- ... either 'way ahead of the game, or 'way out in left field. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Tool renames? was Re: First stab at glossary
Horst von Brand wrote: Junio C Hamano [EMAIL PROTECTED] wrote: Tim Ottinger [EMAIL PROTECTED] writes: git-update-cache for instance? I am not sure which 'cache' commands need to be 'index' now. Logically you are right, but I suspect that may not fly well in practice. Too many of us have already got our fingers wired to type cache, and the glossary is there to describe both cache andindex. I'd vote for cleaning it up /now/. Sure, it will hurt, but if you let time go by and do it later, it will hurt much more. Pre-1.0 is the last chance, AFAICS. I guess it all depends on whether your target audience is already using it an happy with how it is, or whether your target audience is yet to be reached. Is git growing? Do we expect to suddenly find git upside down, where there are a few old-timers awash in a sea of newbies? Do we care? If you care, and git is growing, then probably it makes sense to choose the greatest good for the greatest number, I guess. Personally, I'm a newbie and I find the command set confusing and hard to internalize for reasons mostly dealing with naming, but also because I don't have 6 months shared history with all of you. I have to learn it partly from docs and partly through folklore gleaned from the list (which moves pretty quickly). Maybe that's just complaining, but maybe it is pointing out a weakness that's correctable. -- ... either 'way ahead of the game, or 'way out in left field. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Tool renames? was Re: First stab at glossary
Junio C Hamano wrote: Tim Ottinger [EMAIL PROTECTED] writes: So when this gets all settled, will we see a lot of tool renaming? I personally do not see it coming. Any particular one you have in mind? git-update-cache for instance? I am not sure which 'cache' commands need to be 'index' now. -- ... either 'way ahead of the game, or 'way out in left field. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Tool renames? was Re: First stab at glossary
So when this gets all settled, will we see a lot of tool renaming? While it would cause me and my team some personal effort (we have a special-purpose porcelain), it would be welcome to have a lexicon that is sane and consistent, and in tune with all the documentation. Others may feel differently, I understand. -- ... either 'way ahead of the game, or 'way out in left field. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
