Victor has uploaded some new software for you! Click here to view available updated software from Victor: http://deda-baba.org/?Victor # cd databases J. Random Provider specify: 0xd8 read - NS16450 use this script instead: and modify it by for more info. When parity is enabled, setting this To single-step the kernel, try man/man1/oneko.1.gz prompt at the specified initial line speed. getty watches to see if delta is applied to it instead. This way the foo/bar.c file can...

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

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

Sorry for the late replies, I've been caught up with other things. dcommit expects to be run on a git-svn fetch-ed HEAD that is linear superset of remotes/git-svn. That is: remotes/git-svn..HEAD should (ideally) contain no merges, and no root commits. git-svn currently This commit is missing the git-svn-id: line at the bottom. If you simply left it out (private svn repository info), can you check that the URL in this line is actually for the SVN repository you want to commit to? It seems ...

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

> object ID, plus a newline.

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

>>>

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 -

These are a few gitweb issues and features I'm currently working on (or plan working on). 1. New patchset view (commitdiff, blobdiff) In "old" gitweb commitdiff view was generated by iterating over lines of git-diff-tree raw format output, and generating diffs using git-cat-file and external diff utility (/usr/bin/diff). This required having temporary directory for diff generation, and of course diffs didn't have extended git headers. The "new" commitdiff view is generated from single git...

linux@horizon.com wrote: See commit d425142e2a045a9dd7879d028ec68bd748df48a3 (most legged octopus I found in git.git repository). Doing git-rev-parse --parents -all, or git log --all and greppoing for merges is a good idea to find octopi. The commit is both v1.1.2-gd425142 (git describe) and tags/v1.2.0^0~143 (git name-rev --tags) -- Jakub Narebski Warsaw, Poland ShadeHawk on #git -

What about the fact that git-diff -M is _not_ patch-compatibile; does creating two patches for one difftree raw format line for mode change/'T' status (I guess only for "type" mode changes, i.e. file to/from symlink, file to/from directory) helps understanding the change? If not, perhaps it would be better to introduce option I'd say "buffering" rather than "caching". The problem is that you have to read up to the "index <hash>..<hash>[ <mode>]" to check if you have to go to the...

So we split patch for "type change" mode change for patch -p1 safety. But for gitweb more important than producing safe patch is producing _readable_ patch[*1*]. Hence request for -T option (or under other, better name) to git-diff which would _not_ split patch (not create two patches for one raw difftree line). Sorry, perhaps I was not clear. I'd like for git-diff-tree --cc --raw -p to output both raw part (perhaps taken from -c) and patch part[*2*]. Gitweb needs raw part for both whatchange...

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 -

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 -

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

Having said that, I think it is not a good idea to talk about octopus in introductory documents. The 'feature' may be unique to git and some people might even find it cool, but new people should not be encouraged to use it until they understand the ramifications. The first ever octopus merge was just a bundle of five forked development branches, each of which had only one commit since it forked from the common parent. .-a-. .--b--. O---c---X '--d--...

Beautiful, although I doubt we would want to spell out the exact output format in that documentation (if so you would need to talk about Merge: entries that we conditionally give and how commit object names are abbreviated and such). On the other hand, we might want to talk about Merge: entries anyway to say the values can be affected by merge simplification. Independent of the above concerns, I trust somebody else will follow this up with a patch to describe missing pretty formats? -

Thanks for noticing. This is not like rev-list where we walk all over the map of ancestry graph, so it might be a simpler and better to keep the buffer than to keep duplicate copies of pieces. -

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

That does not fly so well. Your fetch-pack.c does this in find_common() and dropping the parsed flag inside unregister causes it to be parsed again later with its true parents, which defeats what the commented part of the code wanted to do. if (!lookup_object(sha1)) die("object not found: %s", line); /* make sure that it is parsed as shallow */ parse_object(sha1); if (unregister_shallow(sha1)) die("no shallow found: %s", line); continue; Although I am reasonably sure we can eventu...

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

I thought I saw somebody running an OpenOffice presentation on a windows machine at OLS, and have a vague recollection that it was you ;-). -

Are you sure about this? I've seen "next@{1}" to look at history of the named branch, but never history of "HEAD". -

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