For the record, no MS products were used in the creation of those papers, nor the presentations. I wrote plain ASCII text for the papers, and the presentation was done in OpenOffice. After that, however, I don't know how Linux Magazine produced the PDF files for the articles. :-) jdl -

Yes, I _know_ you meant "do well", not "Use MS Excel"... :-) jdl -

Hi, I fully agree. Even the OA did not understand the code fully ;-) How about adding "int force_reparse" to the signature of unregister_shallow()? (Just like we added "int cleanup" to get_merge_bases() to avoid pilot errors.) Ciao, Dscho -

Jumping into this a day late, but: Agreed totally on the second point. It would be great if git natively supported everything people use in Cogito. I find myself using native git commands for the most part, except for one Cogito command: "cg-update". It is vastly more convenient than git-pull in large part because it automatically merges upstream changes with uncommitted working-copy changes. I suppose you could classify this as "hide the index" in some sense. Maybe I should give an exa...

I think it would be just great if it worked at least for fast-forwarding case; I think this is where it is actually most useful. Cogito tries to support even the three-way case as long as the changes touch different files, but I'm not sure if it was a good idea to begin with. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ #!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj $/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1 lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/...

I am not sure what you mean. .git/remotes files do not describe any relationship between local branches (and that is where one of the problem raised in recent thread -- pull does not notice on which branch you are on and change its behaviour depending on it), so I do not think there is anything gained for "git branch I muttered something in a near-by thread Message-ID: <7vr6w78b4x.fsf@assigned-by-dhcp.cox.net> I am reasonably sure a separate tool (what I tentatively called "maint-rem...

Although if you have reflog enabled on your current branch there is a 1 character shorter syntax: gitk HEAD@{1}.. as recent Git understands that to mean the value that HEAD just had, which is also what is in ORIG_HEAD. Except that unlike ORIG_HEAD it can also show even older values (e.g. HEAD@{3}, 3 ops back) and it works very, very well on tracking branches. "What did I just fetch in next?" `git log next@{1}..next` -- Shawn. -

Yes, this was my exact thought when reading what Linus wrote. ORIG_HEAD might be fine and all, but it pales in functionality compared to what reflog provides. I would very much like to see reflog getting first-class citizen support in git: 1. Be on by default 2. Get documented in all the right places, (much better than adding documentation for ORIG_HEAD in my opinion) 3. Tighter integration with branch manipulations. Do we already delete reflog when deleting a branch? We don't have ...

Why is it not useful for tags for having logs? I also have a question: Does git-fsck-objects/prune check the ref logs? Mark -

Heh. With a finnish keyboard, that "@" is AltGr+'2', and the '{'/'}' is AltGr+'7'/'0', I guarantee that it's not "1 character shorter", it's "three pretty complicated characters longer" and "off the normal path where you hold your fingers on the keyboard ;) And that's not even mentioning that '{'/'}' is a magic sequence for filename expansion to the shell, so every time I see that, I have to think about it (and it turns out that because there is no comma in between there, it's ok. Other...

It's not even all that convenient on a U.S. keyboard. My pinky suffers a bit having to pop on and off of shift for the '{', '1', '}'. Then again, I don't like having to hold shift down for all of ORIG_HEAD either, (but it's definitely easier in comparison). But since reflog does everything ORIG_HEAD does and more, shall we just clean up the syntax somehow? Ideas anyone? And then fix the documentation to explain that? -Carl

That's fine with me. Maybe I didn't explain this well before, but my desire is exactly for this to work with multiple repositories. Specifically, what we have in cairo is a "central" shared tree that many people push to. But we only have two branches there, (one for bug-fixes only for our stable releases, and one for ongoing development of new features, and that only of stuff that's well cooked). So that tree looks and acts an awful lot like our cvs tree back in the past. It's often very linea...

Hi, I introduced the remote.<nick>.{url,fetch,push} entries into the config with the goal to enhance -fetch to remember the current command line with a setting. I was the only one to find that useful. BTW I still would argue that it is better to write the remote information into the config, because you have a saner way to manipulate that from I think a message like "This remote branch no longer exists. Maybe you want to use 'git branch -d <branch>' to remove it locally?" ...

With separate-remote layout, this can be done without risk of tracking refname clashing with local refname, which was the primary reason for an earlier reluctance. While separate-remote layout also solves Carl's "do not want to track tracking branches remote has" problem, local branch namespace can have both for-others (not necessarily "public" but could be "for colleagues") and throwaway branches, so --all is probably not the right thing to do in most cases. But I am Ok with the approach of ...

Seems sane to me. Jakub, how do you like this one? If it looks Ok to you, please arrange to include your one-liner that this depends on and forward a readily applicable patch with appropriate commit log message. -

Wouldn't it be better to fix git-checkout-index to checkout a whole directory if specified? -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ #!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj $/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1 lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/) -

On Fri, 17 Nov 2006 01:55:10 -0700, Eric Wong <normalperson@yhbt.net> I didn't remove anything, but I did double-check and the URL is correct. But the following may shed light on why there is no git-svn-id anywhere: IIRC, this is how my current repository came to be (from the very beginning): 1.) Way back when, before I even started on the project, it started life as a CVS repository 2.) Was converted from CVS -> SVN in early '05 (pre-git) 3.) I converted from SVN->git i...

This has some useful material that fills gaps in the existing documentation. We need to think a little more about the intended audience, and about how to fit it in with existing documentation. Who's the audience for the above? I can see that it's useful for administrators, who may need help deciding how to install stuff, and for developers, who need to know where the heck the code for "git-add" came from. But the case I'm most interested in is the user whose distribution installs git for them,...

Yeah, the really difficult problem here is figuring out how to organize the documentation. There are a few needs: 1. Quick-start/task-based documentation - We want to "sell" git to the beginning user by getting them up and running as quickly as possible. - We need to help people with some limited needs-- testers who just need to download the latest linux git tree, or bisect, or whatever. - It's also a fun way to demonstrate the richness of some git features (e.g. history...

Yes, and I am actually interested in at least doing the initial damage assessment myself but people are welcome to beat me to it. The easies part would be to just try writing a bare SHA-1 to .git/HEAD with: H=$(git-rev-parse --verify HEAD) echo $H >.git/HEAD git.git itself is full of them, but the very first octopus (it actually is a pentapus) is rather nice to watch in gitk: 211232bae64bcc60bbf5d1b5e5b2344c22ed767e You can look for them with: git rev-list --parents HE...

On Fri, 17 Nov 2006 10:32:46 -0500 It would be nice to post this information on the Git website and not have it overshadowed by Cogito examples with paragraphs explaining how Cogito makes things easier. The current website distracts users away from learning Git or ever reading about this kind of information. Maybe we can pass a hat around for some funds for a separate Cogito That's quite a good idea. The name was fixed when the option to move this info into the config file was added (remote.&l...

On Fri, 17 Nov 2006 23:19:23 +0700 Pasky has already given a lot to Git, and it would be great to see even more merged back into Git where a consensus can be reached. In fact Pasky has said that his plan is to push a lot more towards Git and make Cogito a thinner UI layer. Either way, there's absolutely nothing wrong with people choosing to use Cogito rather than Git. It's just that the separate Cogito tool shouldn't have a place on the Git website any more prominent than say StGit does. The ...

I think we are trying to figure that out in the last few days in those mammoth threads. UI-wise with no big breakthroughs so far I guess, This is in essence what many people (including Junio) are saying. I'm not saying it's a totally great situation, hence the previous paragraph. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ #!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj $/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1 lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack(...

"The only intuitive user interface is the nipple; all else is learned." As Linus is explaining, the fundamental *problem* is the mental model. Once you know how to break your goals apart into the right kind of pieces, little things like terminology are truly little. I'm not sure that git is sufficiently like anything else that a few well-chosen command names can bring a good analogy to mind. There just isn't a simple analogy that won't lead you astray; you have to understand the thing on its o...

On 17 Nov 2006 00:11:57 -0500 The thing is that other SCM's like hg look a lot more like a nipple than Git. And they have the same conceptual models, more or less, to deal with as Git. So why is it so many people think Git has a UI problem where the same complaint isn't levelled at Mercurial? The thing is, the focus of Git has been different, it's been about creating great plumbing. It's had great success at doing that, and anyone who warms up to Git is well rewarded with a tool that gives th...