Some of the ref manipulation tools (git-for-each-ref and git-show-ref in particular) would not handle hidden (~ /^\./) refs. This may be an acceptable or possibly even desirable behaviour for the ref walkers and repackers, but git-show-ref hiddenrefname must work. This makes Git not ignore hidden refs at all. I'm not opposed to making some particular parts of the ref interface to continue to ignore hidden refs, but the restriction cannot be so deep. Signed-off-by: Petr Baudis <pasky@suse.cz&gt...

Cogito creates such refs for internal purposes in two scenarios, on the other hand it could be argued that in one of those cases the file has no business in refs/ at all (temporary fetching refs, but they may be actually symrefs) and in the other case it has no business in refs/heads/ at all (pointers to shelved changes in a branch). However, I in fact *did* intend to make leading-dot refnames a public interface. The thing is, I need a way to mark some tags as private to your repository if Cogi...

Unfortunately, git-for-each-refs is currently unusable for peeking into tag comments, since it uses freed pointers, so it just prints out all sort of garbage. This makes it strdup() contents and body values. Signed-off-by: Petr Baudis <pasky@suse.cz> --- builtin-for-each-ref.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/builtin-for-each-ref.c b/builtin-for-each-ref.c index 173bf38..227aa3c 100644 --- a/builtin-for-each-ref.c +++ b/builtin-for-each-ref...

I would rather not do that in any new code since it's gonna be a problem if you use this outside of the standalone command as part of libgit. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ The meaning of Stonehenge in Traflamadorian, when viewed from above, is: "Replacement part being rushed with all possible speed." -- Kurt Vonnegut, Sirens from Titan -

Asciidoc-include it into the manuals for programs that use the --pretty command-line option, for consistency among the docs. Signed-off-by: Chris Riddoch <chris@syntacticsugar.org> --- Documentation/git-diff-tree.txt | 7 +++---- Documentation/git-log.txt | 3 +-- Documentation/git-rev-list.txt | 6 +----- Documentation/git-show.txt | 5 +---- Documentation/pretty-formats.txt | 29 +++++++++++++++++++++++++++++ 5 files changed, 35 insertions(+), 15 deletions(-...

Gary has uploaded some new software for you! Click here to view available updated software from Gary: http://mama-papap.org/?Gary machine ``i386'' authentication and to forward packets, possibly on a multi-homed total 337.00 154 $ 6.74 4 7 CA 105 RTS DTE Request to Send conversion of newlines, and more. But there is no way to specify a ll recommended. -m Send mail after completing the print job. With this option, the these or any of the formatting options ...

It's not about documentation but ease to use. I agree and sympathise very much with the effort of making core Git more easy to use and obsoleting Cogito, but until it gets there we should have what's nicest If someone writes a crash course in pure Git covering the same grounds as the current ones (possibly by just extending/retouching the tutorial) (it does not necessarily need to be a "refugee" crash course, it can build up from scratch), I can add it on the web. If it becomes as easy to use and...

As a relatively new user myself, I ran into the same confusion when I came to the website for the first time. One of the most prominent things on the front page is the "Git Crash Courses." Clicking on that gives me the crash courses, all of which are about Cogito, not for Git. So why doesn't the front page say "Cogito Crash Courses" instead? And I don't think it matters much whether Cogito makes things easier or not -- the Git website really should make Git's documentation more prominent than...

But it is encouraged (also for example by git-completion.bash) to use "git foo" form in command line (because git commands can be not in the PATH, It would be useful to cover all non-reductible cases of recursive merge strategy (the default merge strategy for two-head merges) conflicts: contents (covered), add/add, rename/modify etc. So some info about recirsive merge strategy would be useful. -- Jakub Narebski Warsaw, Poland ShadeHawk on #git -

This is the most appropriate. Right now it is not independently controllable but it is not so inplausible for somebody to want to get non recursive view of 'raw' part along with textual diffs when running "--raw -p" diff and your solution c. is robust against even such changes. I would probably not call that "caching" but keeping track of where you are, and you would need to know in which filepair you are in anyway when you want to implement links to blob view from I am not sure what's more u...

What about it? I've never said patch compatibility is an issue. We have something patch cannot represent or understand and you should admit it. The point is to make it easier to massage by hand, when the recipient does not have git handy. With -M, the recipient can read and understand the patch text better than "remove this oldfile and create this newfile that the diff output does not tell you is related" diff. And we say "rename" in plain language so the recipient _can_ do "mv A B" then "pat...

Honestly, I do not have strong feeling either way. As you say, I suspect diff to change between symlink and regular file is not readable no matter how you present it, and it is a corner case that is not very interesting. It happens in real life but it is rare enough that split patches or a single patch would not make much difference either way. So I would not oppose to a patch to add an option to update git-diff to produce either format, but I doubt it is worth the effort required to make sure...

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

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 -

There was some implementation with warts http://thread.gmane.org/gmane.comp.version-control.git/30068 Message-Id: <20061025155009.GD5591@parisc-linux.org> which didn't got corrected and resent. -- Jakub Narebski Poland -

>>>

> You can specify what to fetch on the git-fetch command line.

linux@horizon.com wrote: > There is always a current head, known as HEAD.

Just a note: this doesn't work with bash 3.2. I think they altered the way of trimming variables in this version. on systems with bash 3.2 installed, i get [master!linus-2.6/vm/vm]$ with the example above. on systems with bash 3.1, it works properly. unfortunatelly, i am not so good in bash scripting, so it will take some time for me to fix it. Sincerly Nicolas -

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

This improves the workflow for, say, kernel subsystem backporting. Signed-off-by: Michael K. Edwards <medwards-linux@gmail.com> --- git-checkout.sh | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/git-checkout.sh b/git-checkout.sh index dd47724..5866604 100755 --- a/git-checkout.sh +++ b/git-checkout.sh @@ -106,7 +106,8 @@ Did you intend to checkout '$@' which ca git-ls-tree --full-name -r "$new" "$@" | git-update-index --index-info || exit $? fi - gi...

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 -

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 -

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