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...

Of course "git log -p --merge -- $path" would give the patch "show $merge" is really "diff-tree --cc -p $merge". So first I should (not necessarily "you should to the readers of this document") talk about three ways to describe a merge commit with textual diffs. (1) N independent diffs between each of the parents and the child. We could get this with git diff-tree -m -p $merge but it is mostly useless, because very often many paths in a merge are truly trivial and the ...

Ah. Missed that patch, which is indeed a superset of mine. Looks like you committed it on branch "next"; is that a personal experimental branch, or the integration branch against which patches should be generated? Cheers, - Michael -

Ok, this is a _really_ stupid case, and I don't think it matters, but hey, we should never SIGSEGV. Steps to reproduce: mkdir duh cd duh git init-db git-fmt-merge-msg < /dev/null will cause a SIGSEGV in cmd_fmt_merge_msg(), because we're doing a strncmp() with a NULL current_branch. And yeah, it's an insane schenario, and no, it doesn't really matter. The only reason I noticed was that a broken version of my "git pull" into an empty directory would cause this. This silly p...

Actually it is not pushed out anywhere yet but will appear on both 'maint' and 'master' along with other post 1.4.4 fixes and will be contained in the 1.4.4.1 maintenance release. The role of each branch at my public repository is desribed in this message: Message-ID: <7vk62qhy4k.fsf@assigned-by-dhcp.cox.net> http://article.gmane.org/gmane.comp.version-control.git/29951 In general, if your changes and fixes are applicable in isolation to "master", it is most appropriate to send patch...

I have no objection to this if it is done in a controlled way that does not make life more difficult for people who work with multiple remote repositories. And I think "git fetch" is the tool for what you want if enhanced properly; see Linus's message that explaind that we already have that support in "manually configurable" form but initializing and maintaining the configuration is currently all manual and can be improved. -

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. -

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...

> object ID, plus a newline.

That one did the job... funny, removing these two // did the job, for both versions, GNU bash, version 3.1.17(1)-release (powerpc-unknown-linux-gnu) and GNU bash, version 3.2.5(1)-release (x86_64-pc-linux-gnu). Thx for fixing that script. It really helps me. Sincerly Nicolas -

Hi, I show him how to use it. And that's actually a fine analogy: While the principle of a screw is quite clever, working with it -- even with an electric screwdriver -- is easy. And the most important part: I never read instructions on how to use it. I saw somebody use it and -- voila! -- I I think that the importance of documentation is overrated. Users have come to expect to use programs without reading a manual. DWIM comes to mind. Ciao, Dscho -

-------- Original-Nachricht -------- Datum: Wed, 15 Nov 2006 16:11:57 -0600 Von: Timur Tabi <timur@freescale.com> An: git@vger.kernel.org Is it possible to do this with shallow clone? Shallow clone the local repository my.git (which should be trimmed) starting from the last needed commit to a new local repository my_trimmed.git. And then remove my.git (with something like rm -rf my.git) and rename my_trimmed.git to my.git? Thomas -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekost...

This already should be the case if you use separate-remote. I haven't run "clone --separate-remote" myself for a long time, but the design was certainly to make it behave that way. Specifically, map everything in refs/heads/ at remote to refs/remotes/$origin/ with corresponding names, one-to-one. I do not see much reason to change the mapping of master:origin which is done for the traditional layout. The traditional layout is not suitable for your workflow anyway, and that is why you prefer ...

True. "<pre>" in RSS feed is better (I don't know if you can give CSS Which one liner? As far as I can see the patch does NOT use href(-full=>1,...) but esc_url(...). Perhaps this is for next patch. BTW I have encountered something calles Atom Publishing Protocol (APP): perhaps we should also add this in addition to currently used OPML. -- Jakub Narebski Torun, Poland ShadeHawk on #git -

Often, it would be a branch or a tag, so no problem there. For commits in general, it should not be hard to compute the set of branches and tags the commit is part of, and in the (probably) common case where this set has exactly one element, the problem is solved. For the remaining cases, it should not be too horrible to ask the user to describe what is being merged. -- Karl Hasselstr

>>>

What about proposed (and I think not accepted) merge strategy "rebase" (formerly called "subordinate" or something like that)? -- Jakub Narebski Warsaw, Poland ShadeHawk on #git -

This is really, really good stuff that you've written! Have you any thoughts or suggestions about where this text should end up? Personally, I think this information is actually more important to an end-user than the current "part two" of the tutorial, which discusses the object database and the index file. Perhaps this should be "part 2", and the object database and index file should become "part 3"? It might also be a good to consider moving some of the "discussion" portion the top-level gi...

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...

I agree, this would certainly be the best solution. But it would imply hiding the 'index' by default which would probably an incompatible change. The alternative would be to explain that git is a low level tool suitable mostly for integrators like Linus (that, and that Cogito and/or StGit should be used by developers/contributors). Mark -

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(...

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...

That sounds very interesting. Has it ever been implemented, or only discussed? -- Alexandre Julliard julliard@winehq.org -

It doesn't - look at the "Maintaining external patches" crash course. Porcelains are integral part of the Git environment. I think several people have already tried to explain it before. -- 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 17:53:33 +0100 There is enough native Git documentation and hopefully more coming that third party tools should be pushed behind the scenes a bit. At least on the GIT website. Of course there is nothing wrong with having information there, but the main thrust should be about Git and how to use it directly without porcelains. Especially in the light that people have recently expressed a desire to advocate and document the use of native Git more strongly. Having a link to C...