Re: Zero padded file modes...
On 09/05/2013 11:36 AM, Jeff King wrote: [...] I haven't looked carefully at the pack v4 patches yet, but I suspect that yes, it's still a problem. The premise of pack v4 is that we can do better by not storing the raw git object bytes, but rather storing specialized representations of the various components. For example, by using an integer to store the mode rather than the ascii representation. But that representation does not represent the oops, I have a 0-padded mode quirk. And we have to be able to recover the original object, byte for byte, from the v4 representation (to verify sha1, or to generate a loose object or v2 pack). There are basically two solutions: 1. Add a single-bit flag for I am 0-padded in the real data. We could probably even squeeze it into the same integer. 2. Have a classic section of the pack that stores the raw object bytes. For objects which do not match our expectations, store them raw instead of in v4 format. They will not get the benefit of v4 optimizations, but if they are the minority of objects, that will only end up with a slight slow-down. As I said, I have not looked carefully at the v4 patches, so maybe they handle this case already. But of the two solutions, I prefer (2). Doing (1) can solve _this_ problem, but it complicates the format, and does nothing for any future compatibility issues. Whereas (2) is easy to implement, since it is basically just pack v2 (and implementations would need a pack v2 reader anyway). 3. Keep those objects in v2 packs instead of the v4 pack. Transfers would have to be v3 or multi-pack transfers would need to be supported. 4. Don't use v4 packs with projects that have crufty objects. Projects with such objects may choose to pay the cost to upgrade to v4 compatibility. There's nothing that requires the next pack format to support all of the broken stuff that's happened over the years. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] howto: Use all-space indentation in ASCII art
Those text files are installed as documentation (at least on my distribution). That's probably a distribution bug (or a git makefile bug, depending on how you look at it). It would be better to ship the HTML documentation, converted to text, instead of keeping the version with markup including occasional random \ signs, linkgit:, ``, etc. What distribution do you use? (As maintainer of packaging for a Linux distro, I know at least one that is guilty of this.) From the AcsiiDoc Home Page: =begin quote= You write an AsciiDoc document the same way you would write a normal text document, there are no markup tags or weird format notations. AsciiDoc files are designed to be viewed, edited and printed directly or translated to other presentation formats using the asciidoc(1) command. =end quote= So, the asciidoc source files should be readable in their unprocessed form. And, not using tabs in ASCII art doesn't appear to have any downside. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation/CommunityGuidelines
On 06/10/2013 03:45 PM, Ramkumar Ramachandra wrote: [...] It is absolutely imperative to keep all our contributors productive, and maximize output. Why? A useful product with a maintainable code base are what seems to be more important to a successful open source effort. A Large Angry SCM -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation/CommunityGuidelines
On 06/10/2013 04:56 PM, Ramkumar Ramachandra wrote: A Large Angry SCM wrote: It is absolutely imperative to keep all our contributors productive, and maximize output. Why? A useful product with a maintainable code base are what seems to be more important to a successful open source effort. Doesn't a successful open source effort (with a good review process, which we already have) imply a maintainable product with lots of users? What am I missing, and what change do you propose? It's not about keeping all of the contributers productive or maximizing output. It's about the result being useful. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFD: fast-import is picky with author names (and maybe it should - but how much so?)
On 11/11/2012 07:41 AM, Felipe Contreras wrote: On Sat, Nov 10, 2012 at 8:25 PM, A Large Angry SCMgitzi...@gmail.com wrote: On 11/10/2012 01:43 PM, Felipe Contreras wrote: So, the options are: a) Leave the name conversion to the export tools, and when they miss some weird corner case, like 'Authoremail', let the user face the consequences, perhaps after an hour of the process. We know there are sources of data that don't have git-formatted author names, so we know every tool out there must do this checking. In addition to that, let the export tool decide what to do when one of these bad names appear, which in many cases probably means do nothing, so the user would not even see that such a bad name was there, which might not be what they want. b) Do the name conversion in fast-import itself, perhaps optionally, so if a tool missed some weird corner case, the user does not have to face the consequences. The tool writers don't have to worry about this, so we would not have tools out there doing a half-assed job of this. And what happens when such bad names end up being consistent: warning, a scaffold mapping of bad names, etc. One is bad for the users, and the tools writers, only disadvantages, the other is good for the users and the tools writers, only advantages. c) Do the name conversion, and whatever other cleanup and manipulations you're interesting in, in a filter between the exporter and git-fast-import. Such a filter would probably be quite complicated, and would decrease performance. Really? The fast import stream protocol is pretty simple. All the filter really needs to do is pass through everything that isn't a 'commit' command. And for the 'commit' command, it only needs to do something with the 'author' and 'committer' lines; passing through everything else. I agree that an additional filter _may_ decrease performance somewhat if you are already CPU constrained. But I suspect that the effect would be negligible compared to the all of the SHA-1 calculations. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] GIT Repository Annotation Convention
Junio C Hamano wrote: A Large Angry SCM [EMAIL PROTECTED] writes: Junio C Hamano wrote: A Large Angry SCM [EMAIL PROTECTED] writes: Naming and Directory Structure -- Annotations are named by appending .txt to the basename of the repository component it describes, and by appending .dir to each directory patch component leading to the repository component from $GIT_DIR, and by prepending annotations/ to the annotation pathname. I suspect you can do the same without .dir but only with .txt. Think about a directory containing directories foo and foo.txt: And where do you see foo.txt under $GIT_DIR/ hierarchy? Are you saying I can't name a branch foo.txt? Or have the following branches? $GIT_DIR/refs/head/WidgetSoft/Blue $GIT_DIR/refs/head/WidgetSoft/Red $GIT_DIR/refs/head/WidgetSoft.txt/Blue $GIT_DIR/refs/head/WidgetSoft.txt/Red - 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
Documentation call for help
The good news: There is now some usable documentation for all the git commands except for the following: git-archimport (Martin?) gitk(Paul?) The bad news: Some, if not most, of the command documentation is incomplete or possibly incorrect. Mostly it's a case of the documentation not keeping pace with changes in the code. You can help by comparing the implementation of a command with it's documentation and producing a patch to fix or, at least, improve the documentation. - 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: [RFC] GIT Repository Annotation Convention
Chuck Lever wrote: yay! are you also proposing some git tools to deal with these? it would be great to have some version control (keep these like generation files so we can see the history of revisions). A Large Angry SCM wrote: GIT Repository Annotation Convention [...] I'm not proposing any new tools, just a convention that existing tools or tools that others may create can adopt to provide information to a repositories users. Some existing tools that could use the annotations are: git-branch git-show-branch gitweb There are likely others. Like any other file under $GIT_DIR, these files are not automatically versioned. Rather, each repository maintainer, needs to decide how a repository's meta-data (project meta-meta-data) is tracked or generated. - 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: [PATCH 0/2] A new merge algorithm, take 3
Junio C Hamano wrote: [...] Subject: [PATCH] Multi-backend merge driver. This is just an illustration of concept patch. The new command 'git merge' takes the current head and one or more remote heads, with the commit log message for the automated case. If the heads being merged are simple fast-forwards, it acts the same way as the current 'git resolve'. Otherwise, it tries different merge strategies and takes the result from the one that succeeded auto-merging, if there is any. If no merge strategy succeeds auto-merging, their results are evaluated for number of paths needed for hand resolving, and the one with the least number of such paths is left in the working tree. The user is asked to resolve them by hand and make a commit manually. [...] This last paragraph concerns me because it limits us to a very simple metric, number of paths needed for hand resolving. Some hand resolving situations can be more complex than others and it would nice to use that information if it was available. Of course I have no idea what that information may be or how it can be computed. - 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
[PATCH] Docs for git-checkout-script.
Signed-off-by: A Large Angry SCM [EMAIL PROTECTED] --- Documentation/git-checkout-script.txt | 23 ++- 1 files changed, 14 insertions(+), 9 deletions(-) ac5328903884c402905dd2a778ce51a00c041ffc diff --git a/Documentation/git-checkout-script.txt b/Documentation/git-checkout-script.txt --- a/Documentation/git-checkout-script.txt +++ b/Documentation/git-checkout-script.txt @@ -3,26 +3,31 @@ git-checkout-script(1) NAME -git-checkout-script - Some git command not yet documented. - +git-checkout-script - Checkout and switch to a branch. SYNOPSIS -'git-checkout-script' [ --option ] args... +'git-checkout-script' [-f] [-b new_branch] [branch] DESCRIPTION --- -Does something not yet documented. - +Updates the index and working tree to reflect the specified branch, +branch. Updates HEAD to be branch or, if specified, new_branch. OPTIONS --- ---option:: - Some option not yet documented. +-f:: + Force an re-read of everything. + +-b:: + Create a new branch and start it at branch. -args...:: - Some argument not yet documented. +new_branch:: + Name for the new branch. +branch:: + Branch to checkout; may be any object ID that resolves to a + commit. Defaults to HEAD. Author -- - 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
[PATCH] Docs for git-reset-script.
Signed-off-by: A Large Angry SCM [EMAIL PROTECTED] --- Documentation/git-reset-script.txt | 27 +-- 1 files changed, 17 insertions(+), 10 deletions(-) e6c59b4622ab3eac9c4a74cd1571136ab586ac5a diff --git a/Documentation/git-reset-script.txt b/Documentation/git-reset-script.txt --- a/Documentation/git-reset-script.txt +++ b/Documentation/git-reset-script.txt @@ -3,26 +3,33 @@ git-reset-script(1) NAME -git-reset-script - Some git command not yet documented. - +git-reset-script - Reset current HEAD to the specified state. SYNOPSIS -'git-reset-script' [ --option ] args... +'git-reset-script' [--mixed | --soft | --hard] [commit-ish] DESCRIPTION --- -Does something not yet documented. - +Sets the current head to the specified commit and optionally resets the +index and working tree to match. OPTIONS --- ---option:: - Some option not yet documented. - -args...:: - Some argument not yet documented. +--mixed:: + Like --soft but reports what has not been updated. This is the + default action. + +--soft:: + Does not touch the index file nor the working tree at all, but + requires them in a good order. + +--hard:: + Matches the working tree and index to that of the tree being + switched to. +commit-ish:: + Commit to make the current HEAD. Author -- - 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
[PATCH] Docs for git-show-rev-cache.
Signed-off-by: A Large Angry SCM [EMAIL PROTECTED] --- Documentation/git-show-rev-cache.txt | 19 +-- 1 files changed, 9 insertions(+), 10 deletions(-) 818a8f421dfa978aa4df7103e34aeadf1ba971f5 diff --git a/Documentation/git-show-rev-cache.txt b/Documentation/git-show-rev-cache.txt --- a/Documentation/git-show-rev-cache.txt +++ b/Documentation/git-show-rev-cache.txt @@ -3,26 +3,25 @@ git-show-rev-cache(1) NAME -git-show-rev-cache - Some git command not yet documented. - +git-show-rev-cache - Show the contents of a rev-cache file. SYNOPSIS -'git-show-rev-cache' [ --option ] args... +'git-show-rev-cache' rev-cache-file DESCRIPTION --- -Does something not yet documented. +Show the contents of rev-cache-file. +A rev-cache file describes the commit ancestry reachable from references +supplied as input to get-build-rev-cache. This file is in an +append-only binary format to make the server side friendly to rsync +mirroring scheme. OPTIONS --- ---option:: - Some option not yet documented. - -args...:: - Some argument not yet documented. - +rev-cache-file:: + Rev-cache file to display. Author -- - 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
[PATCH] Docs for git-build-rev-cache.
Signed-off-by: A Large Angry SCM [EMAIL PROTECTED] --- Documentation/git-build-rev-cache.txt | 20 ++-- 1 files changed, 10 insertions(+), 10 deletions(-) c7c6e77b9efa05b8a7b84fdf630f4ff64664872f diff --git a/Documentation/git-build-rev-cache.txt b/Documentation/git-build-rev-cache.txt --- a/Documentation/git-build-rev-cache.txt +++ b/Documentation/git-build-rev-cache.txt @@ -3,26 +3,26 @@ git-build-rev-cache(1) NAME -git-build-rev-cache - Some git command not yet documented. - +git-build-rev-cache - Create or update a rev-cache file. SYNOPSIS -'git-build-rev-cache' [ --option ] args... +'git-build-rev-cache' [-v] rev-cache-file list-of-heads DESCRIPTION --- -Does something not yet documented. - +Creates or updates a file that describes the commit ancestry reachable +from the list-of-head read from stdin. This file is in an append-only +binary format to make the server side friendly to rsync mirroring +scheme, and can be read by the git-show-rev-cache command. OPTIONS --- ---option:: - Some option not yet documented. - -args...:: - Some argument not yet documented. +-v:: + Verbose. +rev-cache-file:: + The rev-cache to operate on. Author -- - 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: [PATCH] Docs for git-checkout-script.
Actually, I'm cherry-picking the easier ones in an effort to reduce my stress about my impending move to the LA area. Hopefully you did git-diff-script, git-format-patch-script, and git-rev-parse which don't look easy to document. Junio C Hamano wrote: You read my mind. I just finished documenting some other commands and was about to push things out. - 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
git-stripspace unfairly accused of being undocumented.
Junio, Looking over the latest commits I just noticed the no documentation section in git.txt lists git-stripspace in error. - 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: Add git-version-script.
Junio C Hamano wrote: Martin Atukunda [EMAIL PROTECTED] writes: This script simply reports the version of git you have installed. I wanted to ahve some way of recording the git version, but I am wondering if 'git' without parameter telling the version number would be good enough without introducing yet another script. git --version - 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: git/gitweb - feature request: Add description to the branches.
Santi Béjar wrote: [...] One thing I'm missing is a way to describe a branch. It can be done in the $GIT_DIR/description, the first line for the whole repository and the rest for the branches. So description file for the git.git repository could be: [description] The core git plumbing pu: Proposed updates rc: Release candidate todo: Todo list [/description] And it can be added to the gitweb tool. Having somewhere to describe the intent of a branch would be a useful convention. But I think the descriptions should be in separate files; one for each branch and one for the repository as a whole. That way it would be possible to have long, multi-line descriptions of the repository and branches with the tools displaying just the first line unless more information is requested; like gitk and gitkweb do with commit messages. An unrelated gitweb feature request: include a timestamp near the top of the projects page so that I don't have to try to remember when I last reloaded the page. TZ=UTC preferred. - 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
Missing documentation
The following is the list of files in the Documentation directory that have *NO* useful text in them at all. git-build-rev-cache.txt git-checkout-script.txt git-diff-script.txt git-format-patch-script.txt git-get-tar-commit-id.txt git-reset-script.txt git-rev-parse.txt git-show-rev-cache.txt gitk.txt The list is the output of the following trivial script: cd Documentation grep -l 'Does something not yet documented.' * If you are the/an author of one or more of these commands (or anyone else), please create some documentation for it. If you care to, please review the rest of the documentation for out of date and/or incomplete text and either produce a patch or let Junio know so it can be added to the TODO list. - 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: [PATCH] git-repack-script: Add option to repack all objects.
Junio C Hamano wrote: This originally came from Frank Sorenson but with a bit of rework to allow future enhancement to the command without changing the external interface for removal part. With the '-a' option, all objects in the current repository are packed into a single pack. When the '-d' option is given at the same time, existing packs that were made redundant by this round of repacking are deleted. Since we currently have only two repacking strategies, one '-a' (everything into one) and the other not '-a' (incrementally pack only the unpacked ones), '-d' is meaningful only used with '-a' and removes all the existing packs before repacking for now. [Rest of updated patch snipped] Frank, Can you produce a patch to update the git-repack-script documentation to reflect the new functionality? - 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: [PATCH] git-repack-script: Add option to repack all objects.
Junio C Hamano wrote: A Large Angry SCM [EMAIL PROTECTED] writes: Frank, Can you produce a patch to update the git-repack-script documentation to reflect the new functionality? Not including the doc changes in the patch was my fault, but the message was meant primarily as an explanation of what I meant, not for immediate inclusion in the master branch. I have some other documentation updates sitting in the proposed updates, so I'd do it myself along with other manual pages if you and Frank do not mind. In any case, I first would like to make sure that the proposed patch you are replying to is something Frank agrees to. I sent my request to Frank because he was/is the sponsor of the change but anyone can provide the documentation. :-) I think it'd be a good idea for documentation updates to accompany all patches (and for the maintainer to not be shy about asking for them). Just my $0.02 as I look at which commands have no documentation. - 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
[PATCH] Documentation for git-applypatch.
Copy paste source comments into documentation. Signed-off-by: [EMAIL PROTECTED] --- Documentation/git-applypatch.txt | 22 +- 1 files changed, 13 insertions(+), 9 deletions(-) 0c00e0e3bd83cc1297e2581cae66aeebc65e52a6 diff --git a/Documentation/git-applypatch.txt b/Documentation/git-applypatch.txt --- a/Documentation/git-applypatch.txt +++ b/Documentation/git-applypatch.txt @@ -3,26 +3,30 @@ git-applypatch(1) NAME -git-applypatch - Some git command not yet documented. - +git-applypatch - Apply an unpacked patch to current tree. SYNOPSIS -'git-applypatch' [ --option ] args... +'git-applypatch' message file patch file info file [signoff file] DESCRIPTION --- -Does something not yet documented. - +Takes four file arguments, and uses those to apply the unpacked patch that they +represent to the current tree. OPTIONS --- ---option:: - Some option not yet documented. +message file:: + File with commit message. + +patch file:: + File with the actual patch. -args...:: - Some argument not yet documented. +info file:: + File with Author, Email, and Subject information. +signoff file:: + File containing signoff ot add. Author -- - 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
[PATCH] Documentation for git-request-pull-script.
Copy paste source comments into documentation. Signed-off-by: [EMAIL PROTECTED] --- Documentation/git-request-pull-script.txt | 18 ++ 1 files changed, 10 insertions(+), 8 deletions(-) c309197099fceb12fa05d9aa23b0b7e5adf5f061 diff --git a/Documentation/git-request-pull-script.txt b/Documentation/git-request-pull-script.txt --- a/Documentation/git-request-pull-script.txt +++ b/Documentation/git-request-pull-script.txt @@ -3,26 +3,28 @@ git-request-pull-script(1) NAME -git-request-pull-script - Some git command not yet documented. - +git-request-pull-script - Generates a summary of pending changes. SYNOPSIS -'git-request-pull-script' [ --option ] args... +'git-request-pull-script' start url [end] DESCRIPTION --- -Does something not yet documented. +Summarizes the changes between two commits to the standard output, and includes +the given URL in the generated summary. OPTIONS --- ---option:: - Some option not yet documented. +start:: + Commit to start at. -args...:: - Some argument not yet documented. +url:: + URL to include in the summary. +end:: + Commit to send at; defaults to HEAD. Author -- - 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
[PATCH] Update Thunderbird specific hints.
Setting the wraplength to zero keeps the bird from trimming WS. Signed-off-by: [EMAIL PROTECTED] --- Documentation/SubmittingPatches |8 ++-- 1 files changed, 2 insertions(+), 6 deletions(-) 10c16a0043ea3bc1fd97b29bfb6ea62404c9790e diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -239,7 +239,7 @@ Thunderbird (A Large Angry SCM) Here are some hints on how to successfully submit patches inline using -Thunderbird. [*3*] +Thunderbird. This recipe appears to work with the current [*1*] Thunderbird from Suse. @@ -260,7 +260,7 @@ patch. [*2*] for the patch, use Tools-about:config to set the following to the indicated values: mailnews.send_plaintext_flowed = false - mailnews.wraplength = 999 + mailnews.wraplength = 0 4) Open a compose window and click the external editor icon. @@ -284,7 +284,3 @@ settings but I haven't tried, yet. mail.identity.default.compose_html = false mail.identity.id?.compose_html = false -*3* Even after following these hints, Thunderbird will still trim -trailing whitespace from each line. I currently have no work around for -for this issue. - - 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: [PATCH] Documentation for git-daemon.
Linus Torvalds wrote: On Mon, 29 Aug 2005, A Large Angry SCM wrote: Signed-off-by: [EMAIL PROTECTED] Btw, I enjoy your email address and name, but especially with something that is supposed to hopefully have some legal value down the line if somebody starts making SCO noises, it really would be nice to have a real person to associate things with.. It would be embarrassing later if there is no way to even look you up somehow. If you don't want your realname/affiliation to be public/official, maybe you could at least let people know in private? Thanks. I tried to find something interesting for this mailing list. My real[*1*] name is Raymond S Brand and I currently no affiliation. Footnotes - *1* For some definition of real. - 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: [PATCH 6/9] New option --ignore-whitespace for git-apply.
Linus Torvalds wrote: On Sun, 28 Aug 2005, Robert Fitzsimons wrote: Allow the user to force a patch to be applied even though there might be whitespace differences. Added a test case for the new option. If you ignore whitespace, then you should probably accept patches that are whitespace corrupted in another way: lines missing the ' ' at the beginning. Especially lines that are empty. That's actually the most common form of whitespace corruption there is. Actually, a more restricted from of --ignore-whitespace may be useful, --ignore-trailing-whitespace (needs a shorter name!). Ignore only trailing whitespace differences (including empty context lines without the initial space). - 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
Subject: [PATCH] Add some documentation.
Add some documentation. Text taken from the the commit messages and the command sources. --- I made no attempt to use the proper terminology, as defined by the new glossary, but instead used the text from the original commit messages and/or the program source. These are some of the easy ones. Some others (like git-diff-script) will require real effort to adequately document. Hopefully I followed my own instructions correctly and will avoid being hit by the shiny blue bat. :-) Documentation/git-add-script.txt | 17 ++--- Documentation/git-branch-script.txt| 19 ++- Documentation/git-cherry.txt | 22 +- Documentation/git-count-objects-script.txt | 18 -- Documentation/git-patch-id.txt | 19 +-- Documentation/git-rebase-script.txt| 17 +++-- Documentation/git-relink-script.txt| 19 +-- Documentation/git-revert-script.txt| 18 +++--- Documentation/git-sh-setup-script.txt | 18 +++--- Documentation/git-verify-tag-script.txt| 16 +--- 10 files changed, 77 insertions(+), 106 deletions(-) a02a9ef2a347e4fac8088fb289dd24c7110c4ee4 diff --git a/Documentation/git-add-script.txt b/Documentation/git-add-script.txt --- a/Documentation/git-add-script.txt +++ b/Documentation/git-add-script.txt @@ -3,26 +3,21 @@ git-add-script(1) NAME -git-add-script - Some git command not yet documented. - +git-add-script - Add files to the cache. SYNOPSIS -'git-add-script' [ --option ] args... +'git-add-script' [file]\+ DESCRIPTION --- -Does something not yet documented. - +A simple wrapper to git-update-cache to add files to the cache for people used +to do cvs add. OPTIONS --- ---option:: - Some option not yet documented. - -args...:: - Some argument not yet documented. - +file:: + Files to add to the cache. Author -- diff --git a/Documentation/git-branch-script.txt b/Documentation/git-branch-script.txt --- a/Documentation/git-branch-script.txt +++ b/Documentation/git-branch-script.txt @@ -3,26 +3,27 @@ git-branch-script(1) NAME -git-branch-script - Some git command not yet documented. - +git-branch-script - Create a new branch. SYNOPSIS -'git-branch-script' [ --option ] args... +'git-branch-script' [branchname [start-point]] DESCRIPTION --- -Does something not yet documented. +If no argument is provided, show available branches and mark current +branch with star. Otherwise, create a new branch of name branchname. +If a starting point is also specified, that will be where the branch is +created, otherwise it will be created at the current HEAD. OPTIONS --- ---option:: - Some option not yet documented. - -args...:: - Some argument not yet documented. +branchname:: + The name of the branch to create. +start-point:: + Where to make the branch; defaults to HEAD. Author -- diff --git a/Documentation/git-cherry.txt b/Documentation/git-cherry.txt --- a/Documentation/git-cherry.txt +++ b/Documentation/git-cherry.txt @@ -3,26 +3,30 @@ git-cherry(1) NAME -git-cherry - Some git command not yet documented. - +git-cherry - Find commits not merged upstream. SYNOPSIS -'git-cherry' [ --option ] args... +'git-cherry' [-v] upstream [head] DESCRIPTION --- -Does something not yet documented. - +Each commit between the fork-point and head is examined, and compared against +the change each commit between the fork-point and upstream introduces. +Commits already included in upstream are prefixed with '-' (meaning drop from +my local pull), while commits missing from upstream are prefixed with '+' +(meaning add to the updated upstream). OPTIONS --- ---option:: - Some option not yet documented. +-v:: + Verbose. -args...:: - Some argument not yet documented. +upstream:: + Upstream branch to compare against. +head:: + Working branch; defaults to HEAD. Author -- diff --git a/Documentation/git-count-objects-script.txt b/Documentation/git-count-objects-script.txt --- a/Documentation/git-count-objects-script.txt +++ b/Documentation/git-count-objects-script.txt @@ -3,26 +3,16 @@ git-count-objects-script(1) NAME -git-count-objects-script - Some git command not yet documented. - +git-count-objects-script - Reports on unpacked objects. SYNOPSIS -'git-count-objects-script' [ --option ] args... +'git-count-objects-script' DESCRIPTION --- -Does something not yet documented. - - -OPTIONS ---option:: - Some option not yet documented. - -args...:: - Some argument not yet documented. - +This counts the number of unpacked object files and disk space consumed by +them, to help you decide when it is a good time to repack. Author -- diff --git
Re: [RFC] Looking at multiple ancestors in merge
Daniel Barkalow wrote: I'm starting to work on letting the merging process see multiple ancestors, and I think it's messy enough that I should actually discuss it. Review of the issue: It is possible to lost reverts in cases when merging two commits with multiple ancestors, in the following pattern: (letters representing blobs at some filename, children to the right) a-b-b-a-? \ X / a-b-b [Lots of stuff deleted] There seems to be a lot of effort being put into auto-magically choosing the right merge in the presence of multiple possible merge bases. Unfortunately, most (all?) of the proposals are attempting to divine intent, and so, are guaranteed to be 100% wrong at least some of the time. Wouldn't it be better, instead, to detect that current merge being attempted is ambiguous and require the user to specify the correct merge base? The alternative is a tool that appears to work all of the time but does the wrong thing some of the time. - 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
Submitting patches w/ Thunderbird [was: Re: [PATCH] Add SubmittingPatches]
Johannes Schindelin wrote: Hi, On Mon, 15 Aug 2005, Junio C Hamano wrote: Johannes Schindelin [EMAIL PROTECTED] writes: Maybe we should enhance git-applymbox to detect whitespace corruption in particular, and output the User-Agent header (or if that does not exist, the Message-ID header; thanks, pine) on error. Alternatively, SubmittingPatches could include a big fat CAVEAT, and a note that the submitter might want to send a single SP to herself, save the received mail and check that all is well, prior to sending the first patch. I mean, well, erm, it is sort of, uh, annoying, to send out a corrupt patch *speaksofyourstruly*. Here are some hints on how to successfully submit patches inline using Thunderbird. This recipe appears to work with the current [*1*] Thunderbird from Suse. The following Thunderbird extensions are needed: AboutConfig 0.5 http://aboutconfig.mozdev.org/ External Editor 0.5.4 http://extensionroom.mozdev.org/more-info/exteditor 1) Prepare the patch as a text file using your method of choice. 2) Before opening a compose window, use Edit-Account Settings to uncheck the Compose messages in HTML format setting in the Composition Addressing panel of the account to be used to send the patch. [*2*] 3) In the main Thunderbird window, _before_ you open the compose window for the patch, use Tools-about:config to set the following to the indicated values: mailnews.send_plaintext_flowed = false mailnews.wraplength = 999 4) Open a compose window and click the external editor icon. 5) In the external editor window, read in the patch file and exit the editor normally. 6) Back in the compose window: Add whatever other text you wish to the message, complete the addressing and subject fields, and press send. 7) Optionally, undo the about:config/account settings changes made in steps 2 3. [Footnotes] *1* Version 1.0 (20041207) from the MozillaThunderbird-1.0-5 rpm of Suse 9.3 professional updates. *2* It may be possible to do this with about:config and the following settings but I haven't tried, yet. mail.html_compose = false mail.identity.default.compose_html = false mail.identity.id?.compose_html = false - 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: gitk parent information in commit window
Paul Mackerras wrote: ... I have been thinking about adding dialog windows to allow the user to select which repository and which range of commits they want to look at. Do you think that would be useful for you? Yes! - 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: gitk parent information in commit window
Linus Torvalds wrote: This adds a useful Parent: line to the git commit information window. It looks something like this (from the infamous octopus merge): Author: Junio C Hamano [EMAIL PROTECTED] 2005-05-05 16:16:54 Committer: Junio C Hamano [EMAIL PROTECTED] 2005-05-05 16:16:54 Parent: fc54a9c30ccad3fde5890d2c0ca2e2acc0848fbc (Update git-apply-patch-script ...) Parent: 9e30dd7c0ecc9f10372f31539d0122db97418353 (Make git-prune-script executa ...) Parent: c4b83e618f1df7d8ecc9392fa40e5bebccbe6b5a (Do not write out new index if ...) Parent: 660265909fc178581ef327076716dfd3550e6e7b (diff-cache shows differences ...) Parent: b28858bf65d4fd6d8bb070865518ec43817fe7f3 (Update diff engine for symlin ...) Octopus merge of the following five patches. Update git-apply-patch-script for symbolic links. Make git-prune-script executable again. Do not write out new index if nothing has changed. diff-cache shows differences for unmerged paths without --cache. Update diff engine for symlinks stored in the cache. Signed-off-by: Junio C Hamano [EMAIL PROTECTED] where all the parent commit ID's are clickable, because the new lines are added as part of the comment string, and thus the regular clickability thing will match them automatically. This new functionality is great except when it truncates the commit description needlessly. When running gitk full-screen on a large display, I have a commit information window that is much wider than needed for the truncated parent information. Leaving me with a lot of whitespace that should be used for the commit descriptions. On a related nit: some of the diffs I'm viewing have lines longer than the width of the commit information window and it's annoying that gitk wraps the line rather than providing horizontal scrolling. How about implementing horizontal scrolling in the commit information window when the commit text or the diffs are wider than the window and not truncating the commit descriptions? - 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: Template files location
Junio C Hamano wrote: ... If the template files are to become something that always have to exist, /etc first and then falling back on /usr/share would make a lot of sense. But as Johannes Schindelin correctly argued against the Use the template mechanism to set up refs/ hierarchy as well. patch [*2*], I think git-init-db should work when there is no template directory. In other words, its primary purpose is to help local project administrators ensure newly created repositories have hooks and probably info/exclude that they recommend to the project members. So templates are project specific. The reason to have a sample one shipped as part of the core package is just to help newbies --- they would get a boilerplate hooks/update that explains how they can set it up when they do git-init-db even when they do not have their own customized set of templates yet. For this kind of use, I do not think one default falling back to another is needed. Shipping samples with the plumbing makes sense, especially when the documentation in is insufficient. But installing the samples as part of the default install process seems less than desirable. Or, alternately, install the samples in with the documentation as (non-executable) examples. ... *1* This would probably break Linus, myself and others --- everybody has to say make prefix=$HOME, so I do not think I am actually going to do it any time soon, if ever. Having prefix=/usr/local as default only helps people who are installing system-wide from the source, and nobody else. People who are writing spec.in and/or debian/rules need to override it to prefix=/usr anyway, and it forces people who are installing to their home to say prefix=$HOME/. I suspect it is an inertia from the good old days when nobody used binary distributions. Rather than changing the default install location in such a way as to make half the user unhappy, make everybody (un)happy by removing the default and forcing it to be specified when make is executed. - 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
[PATCH] Fix warning about non-void return in a void function.
[PATCH] Fix warning about non-void return in a void function.
Signed-off-by: A Large Angry SCM [EMAIL PROTECTED]
---
receive-pack.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
8eda2e60f24221255b77e48f4dd60e2b025839ed
diff --git a/receive-pack.c b/receive-pack.c
--- a/receive-pack.c
+++ b/receive-pack.c
@@ -186,7 +186,7 @@ static void unpack(void)
int code = run_command(unpacker, NULL);
switch (code) {
case 0:
- return 0;
+ return;
case -ERR_RUN_COMMAND_FORK:
die(unpack fork failed);
case -ERR_RUN_COMMAND_EXEC:
-
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: Fix interesting git-rev-list corner case
Ryan Anderson wrote: Maybe it'd make sense to have the commits refuse to add a commit when it would be younger than one of it's parents? Better not to trust timestamps in distributed federations since you can't guarantee any kind of accuracy across administrative boundaries. - 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: [PATCH/RFC] Recursive Make considered harmful
Kirby C. Bohling wrote: On Wed, Jul 27, 2005 at 10:25:10AM -0400, A Large Angry SCM wrote: Ryan Anderson wrote: Convert build process from recurse Make to a single Make Please explain the rational for this. I'm new to the list, but given the subject, I'm fairly confident it's this. http://www.canb.auug.org.au/~millerp/rmch/recu-make-cons-harm.html ... He used the exact wording just about everyone dones when referring to it conceptually. It's easy to google for support and rebuttal: http://www.google.com/search?hl=enq=Recursive+Make+considered+harmfulbtnG=Google+Search Thanks for the references. A quick read of the paper and some of the rebuttals make me think that either way (recursive/non-recursive): * require about the same amount of makefile/dependency maintenance work from developers. * allow developers to be lazy in different ways with makefiles/dependencies. * achieves the same end. The non-recursive make method may have a small advantage for developers using Git for their SCM because the Git operations are also performed at the top level due to Git's design. - 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: Linux BKCVS kernel history git import..
Diego Calleja wrote: El Tue, 26 Jul 2005 11:57:43 -0700 (PDT), Linus Torvalds [EMAIL PROTECTED] escribió: I'm planning on doing the 2.4 tree too some day - either as a separate branch in the same archive, or as a separate git archive, I haven't quite It'd be great to have the same thing but for the 1.0 - 2.2 tree. Of course there are no changelogs for that, but incremental patches are still available, and it'd be very interesting (for historical reasons) to see how things were added/removed Also a really good stress test for the various git-blame/git-annotate implementations. - 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
[PATCH] Add -a option to get-tag-script to annotate but not sign a tag
Add -a option to get-tag-script to annotate but not sign a tag Also fix the test for an existing tag. Signed-off-by: A Large Angry SCM [EMAIL PROTECTED] --- git-tag-script | 21 +++-- 1 files changed, 15 insertions(+), 6 deletions(-) a49029e5cf9cca0c2999c0241e75789bcc38dbb5 diff --git a/git-tag-script b/git-tag-script --- a/git-tag-script +++ b/git-tag-script @@ -3,11 +3,15 @@ . git-sh-setup-script || die Not a git archive +annotate= signed= force= while case $# in 0) break ;; esac do case $1 in +-a) + annotate=1 + ;; -s) signed=1 ;; @@ -23,15 +27,16 @@ done name=$1 [ $name ] || die I need a tag-name -[ -e $GIT_DIR/refs/tags/$name ] - [ $force ] || die tag '$name' already exists +if [ -e $GIT_DIR/refs/tags/$name -a -z $force ]; then +die tag '$name' already exists +fi shift object=$(git-rev-parse --verify --revs-only --default HEAD $@) || exit 1 type=$(git-cat-file -t $object) || exit 1 tagger=$(git-var GIT_COMMITTER_IDENT) || exit 1 -if [ $signed ]; then +if [ $annotate -o $signed ]; then ( echo # echo # Write a tag message echo # ) .editmsg @@ -42,10 +47,14 @@ if [ $signed ]; then [ -s .tagmsg ] || exit ( echo -e object $object\ntype $type\ntag $name\ntagger $tagger\n; cat .tagmsg ) .tmp-tag -rm -f .tmp-tag.asc .tagmsg -gpg -bsa .tmp-tag cat .tmp-tag.asc .tmp-tag +rm -f .tagmsg +if [ $signed ]; then + rm -f .tmp-tag.asc + gpg -bsa .tmp-tag cat .tmp-tag.asc .tmp-tag + rm -f .tmp-tag.sig +fi object=$(git-mktag .tmp-tag) -rm -f .tmp-tag .tmp-tag.sig +rm -f .tmp-tag fi mkdir -p $GIT_DIR/refs/tags - 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: [PATCH 0/2] apply.c: a fix and an enhancement
Junio C Hamano wrote: Ryan Anderson [EMAIL PROTECTED] writes: On Fri, Jul 22, 2005 at 09:56:19AM -0700, Junio C Hamano wrote: Now if we had a mechanism to graft a later history which starts at 2.6.12-rc2 on top of this earlier history leading up to it,... ;-) We do - it's not even very hard, we just end up with 2 commits for every change/merge that's unique to git, until we get to the current head: Aren't you essentially rewriting the history after 2.6.12-rc2?. I suspect that would invalidate the current linux-2.6 history people have been basing their work on since 2.6.12-rc2, which is unacceptable. That is not what I meant by grafting. What I meant was to give a hint to the core that says this 2.6.12-rc2 commit in the current linux-2.6.git tree is recorded as not having a parent, but please consider it the same as this other 2.6.12-rc2 commit in the 2.4.0-2.6.12-rc2 history when traversing the commit ancestry chain. If git-rev-list is taught about that, then you will see git log going across 2.6.12-rc2. If git-merge-base is taught about that, it will be able to find a merge base to merge a line of development that is forked from say 2.6.11 to the current tip of linux-2.6 tree. I think that rewriting history in this case may be the better option in _this_ case. But only because the tools are new and the users are understanding. :-) To do it without the history rewrite, create an alternate_history directory under .git with it's own objects tree. And populate that object tree with alternative content for the objects in the normal trees. Then teach the things the lookup/read objects to look there first and to _not_ care about invalid SHAs. Of course, if you do this, you will never be able to trust your repository. - 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
