* [Announce] GIT v1.5.0-rc2 @ 2007-01-21 8:56 Junio C Hamano 2007-01-21 9:40 ` Jakub Narebski 2007-01-21 11:20 ` Junio C Hamano 0 siblings, 2 replies; 75+ messages in thread From: Junio C Hamano @ 2007-01-21 8:56 UTC (permalink / raw) To: git; +Cc: linux-kernel This hopefully is pretty much it for 1.5.0 modulo potential bugs especially in newer topics. Aside from many bugfixes, changes since -rc1 are: - 'git log' is now reflog aware, and 'git show-branch' which knew about reflog already has become much more useful with reflogs. - the porcelain/ancillary/plumbing categorization in the git main documentation has been reviewed and updated. - merge and pull operations are much less chatty. - operation in a bare repositories is more pleasant. - the default file extension for format-patch output is .patch now. ---------------------------------------------------------------- Bob Proulx (1): git-revert: Fix die before git-sh-setup defines it. Chris Wedgwood (1): cache.h; fix a couple of prototypes David Kågedal (2): Shell syntax fix in git-reset Document --ignore-if-in-upstream in git-format-patch Doug Maxey (1): gitk: add current directory to main window title Eric Wong (2): git-svn: fix tests to work with older svn git-svn: print and flush authentication prompts to STDERR Jason Riedy (4): Start all test scripts with /bin/sh. Set _ALL_SOURCE for AIX, but avoid its struct list. Replace "echo -n" with printf in shell scripts. Solaris 5.8 returns ENOTDIR for inappropriate renames. Jeff King (1): git-pull: disallow implicit merging to detached HEAD Johannes Schindelin (9): Fix spurious compile error config_set_multivar(): disallow newlines in keys show_date(): fix relative dates apply --cached: fix crash in subdirectory Do not verify filenames in a bare repository Teach the revision walker to walk by reflogs with --walk-reflogs --walk-reflogs: disallow uninteresting commits --walk-reflogs: actually find the right commit by date. --walk-reflogs: do not crash with cyclic reflog ancestry Junio C Hamano (69): reflog-expire: brown paper bag fix. merge-recursive: do not report the resulting tree object name Explain "Not a git repository: '.git'". glossary typofix Make git-prune-packed a bit more chatty. Define cd_to_toplevel shell function in git-sh-setup Use cd_to_toplevel in scripts that implement it by hand. Allow whole-tree operations to be started from a subdirectory Use log output encoding in --pretty=email headers. t3901: test "format-patch | am" pipe with i18n git-commit documentation: -a adds and also removes Consistent message encoding while reusing log from an existing commit. More tests in t3901. git log documentation: teach -<n> form. Add describe test. Documentation: merge-output is not too verbose now. Use merge-recursive in git-revert/git-cherry-pick git reflog expire: document --stale-fix option. Fix git-fetch while on detached HEAD not to give needlessly alarming errors git-push documentation: remaining bits git-rm documentation: remove broken behaviour from the example. tutorial: shorthand for remotes but show distributed nature of git git-commit documentation: remove comment on unfixed git-rm Use merge-recursive in git-checkout -m (branch switching) Document where configuration files are in config.txt git-commit: document log message formatting convention Documentation/SubmittingPatches: Gnus tips Documentation/git-tag: the command can be used to also verify a tag. Documentation/git-tools.txt: mention tig and refer to wiki Documentation/git-tar-tree.txt: default umask is now 002 Documentation/git-status.txt: mention color configuration Documentation/git-whatchanged.txt: show -<n> instead of --max-count. Documentation/git-sh-setup.txt: programmer's docs Documentation: detached HEAD Make a short-and-sweet "git-add -i" synonym for "git-add --interactive" Documentation: describe shallow repository Documentation/glossary.txt: unpacked objects are loose. Documentation/glossary.txt: describe remotes/ tracking and packed-refs Introduce 'git-format-patch --suffix=.patch' git-format-patch: do not crash with format.headers without value. Documentation/git-resolve: deprecated. Documentation: suggest corresponding Porcelain-level in plumbing docs. Documentation: m can be relative in "git-blame -Ln,m" Documentation/git-parse-remote.txt: we deal with config vars as well git-format-patch -3 Add --summary to git-format-patch by default git-format-patch: make --binary on by default git-format-patch: the default suffix is now .patch, not .txt Use fixed-size integers for .idx file I/O Documentation: move command list in git.txt into separate files. Documentation: sync git.txt command list and manual page title Documentation: Generate command lists. for_each_reflog_ent: do not leak FILE * refs.c::read_ref_at(): fix bogus munmap() call. Documentation: generated cmds-*.txt does not depend on git.txt Documentation/git.txt: command re-classification dwim_ref(): Separate name-to-ref DWIM code out. Extend read_ref_at() to be usable from places other than sha1_name. show-branch --reflog: show the reflog message at the top. show-branch --reflog: tighten input validation. show-branch --reflog: fix show_date() call Stop ignoring Documentation/README git-tag -d: allow deleting multiple tags at once. branch -f: no reason to forbid updating the current branch in a bare repo. git-rebase: allow rebasing a detached HEAD. log --walk-reflog: documentation reflog-walk: build fixes Fix --walk-reflog with --pretty=oneline GIT v1.5.0-rc2 Linus Torvalds (2): Clean up write_in_full() users Fix up totally buggered read_or_die() Matthias Lederhofer (2): prune-packed: add -q to usage prune: --grace=time Michael S. Tsirkin (1): fix documentation for git-commit --no-verify Nicolas Pitre (4): use 'init' instead of 'init-db' for shipped docs and tools simplify the "no changes added to commit" message some doc updates sanitize content of README file Peter Baumann (1): Make gitk work when launched in a subdirectory Quy Tonthat (1): git-remote: no longer silent on unknown commands. René Scharfe (1): Documentation: a few spelling fixes Santi Béjar (1): tutorial: Use only separate layout Shawn O. Pearce (18): Improve merge performance by avoiding in-index merges. Hide output about SVN::Core not being found during tests. Remove read_or_die in favor of better error messages. Remove unnecessary call_depth parameter in merge-recursive. Allow the user to control the verbosity of merge-recursive. Enable output buffering in merge-recursive. Display a progress meter during merge-recursive. Convert output messages in merge-recursive to past tense. Always perfer annotated tags in git-describe. Hash tags by commit SHA1 in git-describe. Use binary searching on large buckets in git-describe. Improve git-describe performance by reducing revision listing. Correct priority of lightweight tags in git-describe. Remove hash in git-describe in favor of util slot. Use nice names in conflict markers during cherry-pick/revert. Document the master@{n} reflog query syntax. Refer users to git-rev-parse for revision specification syntax. Document pack .idx file format upgrade strategy. Simon 'corecode' Schubert (2): Use fixed-size integers for the on-disk pack structure. Use standard -t option for touch. Uwe Kleine-König (4): document --exec for git-push Update documentation of fetch-pack, push and send-pack make --exec=... option to git-push configurable rename --exec to --receive-pack for push and send-pack ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 2007-01-21 8:56 [Announce] GIT v1.5.0-rc2 Junio C Hamano @ 2007-01-21 9:40 ` Jakub Narebski 2007-01-21 10:52 ` Junio C Hamano 2007-01-21 11:08 ` Johannes Schindelin 2007-01-21 11:20 ` Junio C Hamano 1 sibling, 2 replies; 75+ messages in thread From: Jakub Narebski @ 2007-01-21 9:40 UTC (permalink / raw) To: git By the way, was the pager configured to saner values, so "git diff" on a repository with no changes does not output empty page? What about my Documentation/config.txt changes? -- Jakub Narebski Warsaw, Poland ShadeHawk on #git ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 2007-01-21 9:40 ` Jakub Narebski @ 2007-01-21 10:52 ` Junio C Hamano 2007-01-21 11:08 ` Johannes Schindelin 1 sibling, 0 replies; 75+ messages in thread From: Junio C Hamano @ 2007-01-21 10:52 UTC (permalink / raw) To: Jakub Narebski; +Cc: git Jakub Narebski <jnareb@gmail.com> writes: > By the way, was the pager configured to saner values, so "git diff" > on a repository with no changes does not output empty page? That's been set to the right way since commit 0abc0260 (October 22, 2006, v1.4.3.2~6) as far as I know. > What about my Documentation/config.txt changes? I was not sure about that one, given a lot of commentary in your message, suggesting more research and revision is needed, like these... >>> +All the other lines are recognized as setting variables, in the form >>> +'name = value'. If there is no equal sign on the line, the entire line >>> +is taken as 'name' and the variable is recognized as boolean "true". >>> +Variable names are case insensitive. >> >> They cannot contain anything else than alphanumeric characters, in >> particular no whitespace. > > It is mentioned above "Syntax" section, but perhaps it should be repeated. > I haven't took a look at code to check what values for section names and > for key/variable names are allowed. > ... >> One thing that left me puzzled after reading the description was >> what a user can do with "subsection". It is unclear from the >> description if [section "sub.section"], [section "sub.sec=ti.on"] >> or worse yet, [section "sub\nsection with an embbedded LF"] are >> allowed. The rest seemed sane. > > I'm not sure what is allowed in section name, and in subsection name, > so for now I have left it as is. I can amend this commit, or add new > commit explaining this. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 2007-01-21 9:40 ` Jakub Narebski 2007-01-21 10:52 ` Junio C Hamano @ 2007-01-21 11:08 ` Johannes Schindelin 2007-01-23 18:12 ` Bill Lear 1 sibling, 1 reply; 75+ messages in thread From: Johannes Schindelin @ 2007-01-21 11:08 UTC (permalink / raw) To: Jakub Narebski; +Cc: git Hi, On Sun, 21 Jan 2007, Jakub Narebski wrote: > By the way, was the pager configured to saner values, so "git diff" on a > repository with no changes does not output empty page? As Junio mentioned: it already does. Maybe you have set the environment variable "LESS", and forgot to include "-F"? Hth, Dscho ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 2007-01-21 11:08 ` Johannes Schindelin @ 2007-01-23 18:12 ` Bill Lear 2007-01-23 19:12 ` Johannes Schindelin 2007-01-23 20:32 ` Linus Torvalds 0 siblings, 2 replies; 75+ messages in thread From: Bill Lear @ 2007-01-23 18:12 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Jakub Narebski, git On Sunday, January 21, 2007 at 12:08:25 (+0100) Johannes Schindelin writes: >Hi, > >On Sun, 21 Jan 2007, Jakub Narebski wrote: > >> By the way, was the pager configured to saner values, so "git diff" on a >> repository with no changes does not output empty page? > >As Junio mentioned: it already does. Maybe you have set the environment >variable "LESS", and forgot to include "-F"? I can't seem to get this to work, no matter what I do, using the latest 1.5.0-rc2 code. I have the environment variables LESS, PAGER, PAGER_FLAGS, and I can't seem to get 'git diff' to not plough through my screen each time it is run, no matter the combinations... Could someone post the magic? Bill ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 2007-01-23 18:12 ` Bill Lear @ 2007-01-23 19:12 ` Johannes Schindelin 2007-01-23 20:12 ` Bill Lear 2007-01-23 20:32 ` Linus Torvalds 1 sibling, 1 reply; 75+ messages in thread From: Johannes Schindelin @ 2007-01-23 19:12 UTC (permalink / raw) To: Bill Lear; +Cc: git Hi, On Tue, 23 Jan 2007, Bill Lear wrote: > I can't seem to get this to work, no matter what I do, using the latest > 1.5.0-rc2 code. I have the environment variables LESS, PAGER, > PAGER_FLAGS, and I can't seem to get 'git diff' to not plough through my > screen each time it is run, no matter the combinations... Could someone > post the magic? Try this: PAGER=less LESS=-FRS git diff Hth, Dscho ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 2007-01-23 19:12 ` Johannes Schindelin @ 2007-01-23 20:12 ` Bill Lear 2007-01-23 20:22 ` Uwe Kleine-König ` (2 more replies) 0 siblings, 3 replies; 75+ messages in thread From: Bill Lear @ 2007-01-23 20:12 UTC (permalink / raw) To: Johannes Schindelin; +Cc: git On Tuesday, January 23, 2007 at 20:12:36 (+0100) Johannes Schindelin writes: >Hi, > >On Tue, 23 Jan 2007, Bill Lear wrote: > >> I can't seem to get this to work, no matter what I do, using the latest >> 1.5.0-rc2 code. I have the environment variables LESS, PAGER, >> PAGER_FLAGS, and I can't seem to get 'git diff' to not plough through my >> screen each time it is run, no matter the combinations... Could someone >> post the magic? > >Try this: > > PAGER=less LESS=-FRS git diff Replied to Johannes off-line and thought this was working --- sorry for the false positive. It is in one regard: it completely suppresses output if there is less than a full screen of output. If I do this: % export PAGER=less % unset LESS % git diff I get 30 lines of output in my current repository, as I should. If I then do this: % LESS=-FRS git diff I get nothing --- I do see a brief blink of output, but it's as if less swallows it whole and I see nothing but the next prompt. Hmmm ... I do seem to be using a rather old version of less: % less --version less 382 Copyright (C) 2002 Mark Nudelman Could this be the culprit? Will try and see... Nope, downloaded, built, and installed less-394 and I still see the same problem. I also see this problem when I do 'man git-gc', for example --- the manpage just disappears. If I set LESS to '-F' it fails. If set to '-RS', output is seen but then I see the screen blanked when there is no output from git diff. This is on Centos 4.3. I have not yet tried this on my Fedora Core 6 laptop, at home... Bill ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 2007-01-23 20:12 ` Bill Lear @ 2007-01-23 20:22 ` Uwe Kleine-König 2007-01-23 20:31 ` Bill Lear 2007-01-23 20:22 ` Johannes Schindelin 2007-01-23 21:09 ` Peter Baumann 2 siblings, 1 reply; 75+ messages in thread From: Uwe Kleine-König @ 2007-01-23 20:22 UTC (permalink / raw) To: Bill Lear; +Cc: Johannes Schindelin, git Hello Bill, > > % export PAGER=less > % unset LESS > % git diff > > I get 30 lines of output in my current repository, as I should. > > If I then do this: > > % LESS=-FRS git diff What about: LESS=-FRSX git diff ? HTH Uwe -- Uwe Kleine-König http://www.google.com/search?q=sin%28pi%2F2%29 ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 2007-01-23 20:22 ` Uwe Kleine-König @ 2007-01-23 20:31 ` Bill Lear 2007-01-24 10:06 ` Uwe Kleine-König 0 siblings, 1 reply; 75+ messages in thread From: Bill Lear @ 2007-01-23 20:31 UTC (permalink / raw) To: Uwe Kleine-König; +Cc: Johannes Schindelin, git On Tuesday, January 23, 2007 at 21:22:32 (+0100) Uwe Kleine-König writes: >> % export PAGER=less >> % unset LESS >> % git diff >> >> I get 30 lines of output in my current repository, as I should. >> >> If I then do this: >> >> % LESS=-FRS git diff >What about: > > LESS=-FRSX git diff Well, I see output when there is output to show, yes, but it still blanks the screen --- or, I should say, scrolls all the way to the bottom --- when there is no difference to show. I do note that if LESS is not set, git sets it (in pager.c) to just what you have above (FRSX). Bill ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 2007-01-23 20:31 ` Bill Lear @ 2007-01-24 10:06 ` Uwe Kleine-König 0 siblings, 0 replies; 75+ messages in thread From: Uwe Kleine-König @ 2007-01-24 10:06 UTC (permalink / raw) To: Bill Lear; +Cc: Johannes Schindelin, git Bill Lear wrote: > On Tuesday, January 23, 2007 at 21:22:32 (+0100) Uwe Kleine-König writes: > >> % export PAGER=less > >> % unset LESS > >> % git diff > >> > >> I get 30 lines of output in my current repository, as I should. > >> > >> If I then do this: > >> > >> % LESS=-FRS git diff > >What about: > > > > LESS=-FRSX git diff > > Well, I see output when there is output to show, yes, but it still > blanks the screen --- or, I should say, scrolls all the way to the > bottom --- when there is no difference to show. Ah, OK, now I got it. Sorry, I understood you wrong. Seems like something that needs fixing in less. At least I cannot find an option for that. But I'm not sure that all people would consider that being a bug. Best regards Uwe -- Uwe Kleine-König http://www.google.com/search?q=72+PS+point+in+inch ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 2007-01-23 20:12 ` Bill Lear 2007-01-23 20:22 ` Uwe Kleine-König @ 2007-01-23 20:22 ` Johannes Schindelin 2007-01-23 21:09 ` Peter Baumann 2 siblings, 0 replies; 75+ messages in thread From: Johannes Schindelin @ 2007-01-23 20:22 UTC (permalink / raw) To: Bill Lear; +Cc: git Hi, On Tue, 23 Jan 2007, Bill Lear wrote: > % less --version > less 382 It works here, with 381 _and_ 376+iso254. > If I set LESS to '-F' it fails. If set to '-RS', output is seen but > then I see the screen blanked when there is no output from git diff. This looks more like a broken terminal interaction to me. Ciao, Dscho ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 2007-01-23 20:12 ` Bill Lear 2007-01-23 20:22 ` Uwe Kleine-König 2007-01-23 20:22 ` Johannes Schindelin @ 2007-01-23 21:09 ` Peter Baumann 2007-01-23 21:54 ` Bill Lear 2 siblings, 1 reply; 75+ messages in thread From: Peter Baumann @ 2007-01-23 21:09 UTC (permalink / raw) To: git Bill Lear <rael@zopyra.com> schrieb: > On Tuesday, January 23, 2007 at 20:12:36 (+0100) Johannes Schindelin writes: >>Hi, >> >>On Tue, 23 Jan 2007, Bill Lear wrote: >> >>> I can't seem to get this to work, no matter what I do, using the latest >>> 1.5.0-rc2 code. I have the environment variables LESS, PAGER, >>> PAGER_FLAGS, and I can't seem to get 'git diff' to not plough through my >>> screen each time it is run, no matter the combinations... Could someone >>> post the magic? >> >>Try this: >> >> PAGER=less LESS=-FRS git diff > > Replied to Johannes off-line and thought this was working --- sorry > for the false positive. It is in one regard: it completely suppresses > output if there is less than a full screen of output. > > If I do this: > > % export PAGER=less > % unset LESS > % git diff > > I get 30 lines of output in my current repository, as I should. > > If I then do this: > > % LESS=-FRS git diff > > I get nothing --- I do see a brief blink of output, but it's as if > less swallows it whole and I see nothing but the next prompt. > This is propably caused by activating "Enable Alternate Screen Switching" in xterm. If you have this feature enabled, you get a clean screen (no fragments of the displayed file are shown after quitting less). Try to disable it and see if it works. -Peter ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 2007-01-23 21:09 ` Peter Baumann @ 2007-01-23 21:54 ` Bill Lear 0 siblings, 0 replies; 75+ messages in thread From: Bill Lear @ 2007-01-23 21:54 UTC (permalink / raw) To: Peter Baumann; +Cc: git On Tuesday, January 23, 2007 at 22:09:24 (+0100) Peter Baumann writes: >Bill Lear <rael@zopyra.com> schrieb: >>... >> If I do this: >> >> % export PAGER=less >> % unset LESS >> % git diff >> >> I get 30 lines of output in my current repository, as I should. >> >> If I then do this: >> >> % LESS=-FRS git diff >> >> I get nothing --- I do see a brief blink of output, but it's as if >> less swallows it whole and I see nothing but the next prompt. >> > >This is propably caused by activating "Enable Alternate Screen Switching" >in xterm. If you have this feature enabled, you get a clean screen (no >fragments of the displayed file are shown after quitting less). Try to >disable it and see if it works. Tried as instructed: I get output when I should get output. However, when I should get no output, it clears/scrolls all the way down to the bottom of the screen (LESS=-FRS git diff). Bill ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 2007-01-23 18:12 ` Bill Lear 2007-01-23 19:12 ` Johannes Schindelin @ 2007-01-23 20:32 ` Linus Torvalds 2007-01-24 17:54 ` Mark Nudelman ` (2 more replies) 1 sibling, 3 replies; 75+ messages in thread From: Linus Torvalds @ 2007-01-23 20:32 UTC (permalink / raw) To: Bill Lear Cc: Johannes Schindelin, Jakub Narebski, Git Mailing List, Mark Nudelman [ Added "less" author Mark Nudelman to Cc: ] On Tue, 23 Jan 2007, Bill Lear wrote: > > I can't seem to get this to work, no matter what I do, using the > latest 1.5.0-rc2 code. I have the environment variables LESS, PAGER, > PAGER_FLAGS, and I can't seem to get 'git diff' to not plough through > my screen each time it is run, no matter the combinations... Could > someone post the magic? I think "less" is actually seriously buggy with -F. There are two bugs: - it will always screw up the screen and move to the end. It does this even if you use -FX which should disable any init sequences, so it's not about that problem. - if you resize the terminal while less is waiting for input, less will exit entirely without even showing the output. This is very noticeable if you do something like "git diff" on a big and cold-cache tree and git takes a few seconds to think, and then you resize the window while it's preparing. Boom. No output AT ALL. Both bugs are easily seen with this simple command line clear ; (sleep 5 ; echo Hello) | less -F where you would EXPECT that the "Hello" would show up at the first line of the screen (since we cleared the screen and moved to the top left corner), but in fact it doesn't. And try resizing the terminal to make it bigger during the five-second pause, and now you'll see less not show the "Hello" at _all_. It's just gone (this is true even if the output was _more_ than a screen: try with (sleep 10 ; yes ) | less -F and resize the screen, and it will exit silently after 10 seconds - never showing any output at all! Even though the output is obviously bigger than a screen.. Tested with Kterm, gnome-terminal and xterm. They all behave the same for me. I don't know exactly what the bug is, but I find the "eof" handling very confusing in the less sources. It makes me suspect that there is something that gets confused by the partial read, sets EOF (since we're on the last line), and then thinks that it should quit, since EOF is set. I dunno. Mark? Linus ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 2007-01-23 20:32 ` Linus Torvalds @ 2007-01-24 17:54 ` Mark Nudelman 2007-01-24 18:18 ` Linus Torvalds 2007-01-24 19:21 ` Linus Torvalds 2007-03-27 0:07 ` Mark Nudelman 2 siblings, 1 reply; 75+ messages in thread From: Mark Nudelman @ 2007-01-24 17:54 UTC (permalink / raw) To: Linus Torvalds Cc: Bill Lear, Johannes Schindelin, Jakub Narebski, Git Mailing List On 1/23/2007 12:32 PM, Linus Torvalds wrote: > I think "less" is actually seriously buggy with -F. > > There are two bugs: > > - it will always screw up the screen and move to the end. It does this > even if you use -FX which should disable any init sequences, so it's > not about that problem. > > - if you resize the terminal while less is waiting for input, less > will exit entirely without even showing the output. This is very > noticeable if you do something like "git diff" on a big and cold-cache > tree and git takes a few seconds to think, and then you resize the > window while it's preparing. Boom. No output AT ALL. > > Both bugs are easily seen with this simple command line > > clear ; (sleep 5 ; echo Hello) | less -F > > where you would EXPECT that the "Hello" would show up at the first line of > the screen (since we cleared the screen and moved to the top left corner), > but in fact it doesn't. > > And try resizing the terminal to make it bigger during the five-second > pause, and now you'll see less not show the "Hello" at _all_. It's just > gone (this is true even if the output was _more_ than a screen: try with > > (sleep 10 ; yes ) | less -F > > and resize the screen, and it will exit silently after 10 seconds - never > showing any output at all! Even though the output is obviously bigger than > a screen.. > > Tested with Kterm, gnome-terminal and xterm. They all behave the same for > me. > > I don't know exactly what the bug is, but I find the "eof" handling very > confusing in the less sources. It makes me suspect that there is something > that gets confused by the partial read, sets EOF (since we're on the last > line), and then thinks that it should quit, since EOF is set. > > I dunno. Mark? > > Linus Hi Linus, The first issue that you mention (that we move to the bottom of the screen before printing the first line) is behavior that has always existed in less. It's not the init sequence that's doing it; less deliberately moves to lowerleft before printing any output that is intended to go at the bottom of the screen, including both file data and the prompt. This was a design decision from the first version of less, and I've never been brave enough to try to find all the places that would be affected by changing this. For example, less tries to keep track of exactly what's displayed on the screen at all times, and it's harder to do this if we don't know whether some output scrolled the screen or not. It may or may not be a big job to make all the changes that would be required. I will move this up the priority list and take a look at it for the next release of less. BTW, this issue is documented as enhancement request #112 at http://www.greenwoodsoftware.com/less/bugs.html. Your second issue is definitely a bug. Less's handling of -F and eof in general is indeed rather baroque and confusing, and probably needs a complete revision. Some of the complexity comes from being portable to many (not necessarily Unix-like) systems. But in this case, I think the early exit is happening because less makes the decision about whether to quit due to -F based on the state of the input when the first prompt occurs. When less receives SIGWIND, it repaints the screen and *reprompts*. So if it gets this signal before the first screen is completely filled, it tries to prompt, somehow gets confused and thinks that the partially filled screen is evidence of a short file, and exits. I will add this to the bug list and try to fix it in the next release. --Mark ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 2007-01-24 17:54 ` Mark Nudelman @ 2007-01-24 18:18 ` Linus Torvalds 0 siblings, 0 replies; 75+ messages in thread From: Linus Torvalds @ 2007-01-24 18:18 UTC (permalink / raw) To: Mark Nudelman Cc: Bill Lear, Johannes Schindelin, Jakub Narebski, Git Mailing List On Wed, 24 Jan 2007, Mark Nudelman wrote: > > The first issue that you mention (that we move to the bottom of the screen > before printing the first line) is behavior that has always existed in less. > > BTW, this issue is documented as enhancement request #112 at > http://www.greenwoodsoftware.com/less/bugs.html. I don't dispute that the "move to the bottom of the screen" is probably a good feature in general, but it is _not_ a good feature when -F is in effect (similar to the init/exit sequence being a horrible thing to do when -F is in effect). So the problem is that it basically makes -F largely useless.. The whole _point_ of anybody using -F is that it turns off the "pager" feature for small output that fits on a page, wouldn't you say? (The reason the init/exit sequence doesn't mix with -F is that many terminal descriptions basically have a "switch to secondary screen" for init, and "switch back" for exit, which means that together with -F, small output simply won't be shown at all - or perhaps it just flickers too quickly for the user to see it). So this really is only a -F issue. Now, for the init/exit sequence, at least we have -X to turn that off (and git does indeed default to using "FRSX" if the user doesn't have any LESS environment variable set), so perhaps the "move to end of screen" could also get another flag? That way it would be something that users can control - but see above on why I pretty much guarantee that anybody who uses -F would want to use the new flag too. > Your second issue is definitely a bug. Less's handling of -F and eof in > general is indeed rather baroque and confusing, and probably needs a complete > revision. Some of the complexity comes from being portable to many (not > necessarily Unix-like) systems. Yeah, I tried to look at the sources, and ran awya screaming ;) Linus ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 2007-01-23 20:32 ` Linus Torvalds 2007-01-24 17:54 ` Mark Nudelman @ 2007-01-24 19:21 ` Linus Torvalds 2007-01-24 23:23 ` Junio C Hamano 2007-03-27 0:07 ` Mark Nudelman 2 siblings, 1 reply; 75+ messages in thread From: Linus Torvalds @ 2007-01-24 19:21 UTC (permalink / raw) To: Junio C Hamano Cc: Johannes Schindelin, Jakub Narebski, Git Mailing List, Mark Nudelman, Bill Lear On Tue, 23 Jan 2007, Linus Torvalds wrote: > > I think "less" is actually seriously buggy with -F. > > There are two bugs: > > - it will always screw up the screen and move to the end. It does this > even if you use -FX which should disable any init sequences, so it's > not about that problem. > > - if you resize the terminal while less is waiting for input, less > will exit entirely without even showing the output. This is very > noticeable if you do something like "git diff" on a big and cold-cache > tree and git takes a few seconds to think, and then you resize the > window while it's preparing. Boom. No output AT ALL. Heh. This extremely hacky patch works around the second bug. It does so by simply adding a "select()" on the input before even starting "less", which will mean that by the time less starts, it always has something to read, and that in turn hides the bug with resizing the terminal window while less is waiting for input. I'm sure there's still a window for the bug to trigger, but I can no longer trivially reproduce the problem any more. (The way to reproduce the problem is to do some pager operation that takes a while in git, and resizing the window while git is thinking about the output. I use git diff --stat v2.6.12.. in the kernel tree to do something where it takes a while for git to start outputting information) Without this patch, I can easily just resize the window while git is thinking, and the end result is that "less" will exit early and indeed leave the tty in a broken state with no echo etc. With this patch, less doesn't get confused. NOTE! To see this problem, you must use the LESS environment that git provides by default (LESS=FRSX) and not have your own environment set that overrides the git ones (or if you do, it must have -F set). Is it ugly? Yes. Does it work? Yes. Do we want to apply it? You decide. Linus --- diff --git a/pager.c b/pager.c index 4587fbb..5f280ab 100644 --- a/pager.c +++ b/pager.c @@ -1,5 +1,7 @@ #include "cache.h" +#include <sys/select.h> + /* * This is split up from the rest of git so that we might do * something different on Windows, for example. @@ -7,6 +9,16 @@ static void run_pager(const char *pager) { + /* + * Work around bug in "less" by not starting it until we + * have real input + */ + fd_set in; + + FD_ZERO(&in); + FD_SET(0, &in); + select(1, &in, NULL, &in, NULL); + execlp(pager, pager, NULL); execl("/bin/sh", "sh", "-c", pager, NULL); } ^ permalink raw reply related [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 2007-01-24 19:21 ` Linus Torvalds @ 2007-01-24 23:23 ` Junio C Hamano 0 siblings, 0 replies; 75+ messages in thread From: Junio C Hamano @ 2007-01-24 23:23 UTC (permalink / raw) To: Linus Torvalds Cc: Johannes Schindelin, Jakub Narebski, Git Mailing List, Mark Nudelman, Bill Lear Linus Torvalds <torvalds@linux-foundation.org> writes: > NOTE! To see this problem, you must use the LESS environment that git > provides by default (LESS=FRSX) and not have your own environment set that > overrides the git ones (or if you do, it must have -F set). > > Is it ugly? Yes. Does it work? Yes. Do we want to apply it? You decide. I would not call it ugly. I once consiered to fork another process in between the pager and the caller here and make it buffer "the first screenful" before actually spawning the pager, or write out the short output itself without spawning, to fix the "no output but the cursor goes to the end" problem. THAT's ugly. But I do not think your patch is ugly, and it would help normal people who work in a windowed environment (I did not see the need for it myself since I usually never resize the terminal -- even working inside X my terminals are usually fixed size and are always running "screen"). ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 2007-01-23 20:32 ` Linus Torvalds 2007-01-24 17:54 ` Mark Nudelman 2007-01-24 19:21 ` Linus Torvalds @ 2007-03-27 0:07 ` Mark Nudelman 2 siblings, 0 replies; 75+ messages in thread From: Mark Nudelman @ 2007-03-27 0:07 UTC (permalink / raw) To: Linus Torvalds Cc: Bill Lear, Johannes Schindelin, Jakub Narebski, Git Mailing List Hi all, I'm not sure if you are still interested in this, but I have posted a beta release of less (less-401) which I believe fixes both of these problems. See http://www.greenwoodsoftware.com/less. If you try it, let me know how it works for you. --Mark On 1/23/2007 12:32 PM, Linus Torvalds wrote: > [ Added "less" author Mark Nudelman to Cc: ] > > On Tue, 23 Jan 2007, Bill Lear wrote: >> I can't seem to get this to work, no matter what I do, using the >> latest 1.5.0-rc2 code. I have the environment variables LESS, PAGER, >> PAGER_FLAGS, and I can't seem to get 'git diff' to not plough through >> my screen each time it is run, no matter the combinations... Could >> someone post the magic? > > I think "less" is actually seriously buggy with -F. > > There are two bugs: > > - it will always screw up the screen and move to the end. It does this > even if you use -FX which should disable any init sequences, so it's > not about that problem. > > - if you resize the terminal while less is waiting for input, less > will exit entirely without even showing the output. This is very > noticeable if you do something like "git diff" on a big and cold-cache > tree and git takes a few seconds to think, and then you resize the > window while it's preparing. Boom. No output AT ALL. > > Both bugs are easily seen with this simple command line > > clear ; (sleep 5 ; echo Hello) | less -F > > where you would EXPECT that the "Hello" would show up at the first line of > the screen (since we cleared the screen and moved to the top left corner), > but in fact it doesn't. > > And try resizing the terminal to make it bigger during the five-second > pause, and now you'll see less not show the "Hello" at _all_. It's just > gone (this is true even if the output was _more_ than a screen: try with > > (sleep 10 ; yes ) | less -F > > and resize the screen, and it will exit silently after 10 seconds - never > showing any output at all! Even though the output is obviously bigger than > a screen.. > > Tested with Kterm, gnome-terminal and xterm. They all behave the same for > me. > > I don't know exactly what the bug is, but I find the "eof" handling very > confusing in the less sources. It makes me suspect that there is something > that gets confused by the partial read, sets EOF (since we're on the last > line), and then thinks that it should quit, since EOF is set. > > I dunno. Mark? > > Linus > ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 2007-01-21 8:56 [Announce] GIT v1.5.0-rc2 Junio C Hamano 2007-01-21 9:40 ` Jakub Narebski @ 2007-01-21 11:20 ` Junio C Hamano 2007-01-21 13:42 ` Bill Lear ` (5 more replies) 1 sibling, 6 replies; 75+ messages in thread From: Junio C Hamano @ 2007-01-21 11:20 UTC (permalink / raw) To: git; +Cc: linux-kernel BTW, as the upcoming v1.5.0 release will introduce quite a bit of surface changes (although at the really core it still is the old git and old ways should continue to work), I am wondering if it would help people to try out and find wrinkles before the real thing for me to cut a tarball and a set of RPM packages. Comments? Also, in the same spirit of giving the release an early exposure, here is the current draft of 1.5.0 release notes. -- >8 -- cut here -- >8 -- GIT v1.5.0 Release Notes (draft) ================================ Old news -------- This section is for people who are upgrading from ancient versions of git. Although all of the changes in this section happened before the current v1.4.4 release, they are summarized here in the v1.5.0 release notes for people who skipped earlier versions. In general, you should not have to worry about incompatibility, and there is no need to perform "repository conversion" if you are updating to v1.5.0. However, some of the changes are one-way street upgrades; once you use them your repository can no longer be used with ancient git. - There is a configuration variable core.legacyheaders that changes the format of loose objects so that they are more efficient to pack and to send out of the repository over git native protocol, since v1.4.2. However, loose objects written in the new format cannot be read by git older than that version; people fetching from your repository using older clients over dumb transports (e.g. http) using older versions of git will also be affected. - Since v1.4.3, configuration repack.usedeltabaseoffset allows packfile to be created in more space efficient format, which cannot be read by git older than that version. The above two are not enabled by default and you explicitly have to ask for them, because these two features make repositories unreadable by older versions of git, and in v1.5.0 we still do not enable them by default for the same reason. We will change this default probably 1 year after 1.4.2's release, when it is reasonable to expect everybody to have new enough version of git. - 'git pack-refs' appeared in v1.4.4; this command allows tags to be accessed much more efficiently than the traditional 'one-file-per-tag' format. Older git-native clients can still fetch from a repository that packed and pruned refs (the server side needs to run the up-to-date version of git), but older dumb transports cannot. Packing of refs is done by an explicit user action, either by use of "git pack-refs --prune" command or by use of "git gc" command. - 'git -p' to paginate anything -- many commands do pagination by default on a tty. Introduced between v1.4.1 and v1.4.2; this may surprise old timers. - 'git archive' superseded 'git tar-tree' in v1.4.3; - 'git cvsserver' was new invention in v1.3.0; - 'git repo-config', 'git grep', 'git rebase' and 'gitk' were seriously enhanced during v1.4.0 timeperiod. - 'gitweb' became part of git.git during v1.4.0 timeperiod and seriously modified since then. - reflog is an v1.4.0 invention. This allows you to name a revision that a branch used to be at (e.g. "git diff master@{yesterday} master" allows you to see changes since yesterday's tip of the branch). Updates in v1.5.0 since v1.4.4 series ------------------------------------- * Index manipulation - git-add is to add contents to the index (aka "staging area" for the next commit), whether the file the contents happen to be is an existing one or a newly created one. - git-add without any argument does not add everything anymore. Use 'git-add .' instead. Also you can add otherwise ignored files with an -f option. - git-add tries to be more friendly to users by offering an interactive mode. - git-commit <path> used to refuse to commit if <path> was different between HEAD and the index (i.e. update-index was used on it earlier). This check was removed. - git-rm is much saner and safer. It is used to remove paths from both the index file and the working tree, and makes sure you are not losing any local modification before doing so. - git-reset <tree> <paths>... can be used to revert index entries for selected paths. - git-update-index is much less visible. * Repository layout and objects transfer - The data for origin repository is stored in the configuration file $GIT_DIR/config, not in $GIT_DIR/remotes/, for newly created clones. The latter is still supported and there is no need to convert your existing repository if you are already comfortable with your workflow with the layout. - git-clone always uses what is known as "separate remote" layout for a newly created repository with a working tree; i.e. tracking branches in $GIT_DIR/refs/remotes/origin/ are used to track branches from the origin. - New branches that appear on the origin side after a clone is made are also tracked automatically. This is done with an wildcard refspec "refs/heads/*:refs/remotes/origin/*", which older git does not understand, so if you clone with 1.5.0, you would need to downgrade remote.*.fetch in the configuration file to specify each branch you are interested in individually if you plan to fetch into the repository with older versions of git (but why would you?). - git-branch and git-show-branch know remote tracking branches. - git-push can now be used to delete a remote branch or a tag. This requires the updated git on the remote side. - git-push more agressively keeps the transferred objects packed. Earlier we recommended to monitor amount of loose objects and repack regularly, but you should repack when you accumulated too many small packs this way as well. Updated git-count-objects helps you with this. - A new command, git-remote, can help you manage your remote tracking branch definitions. * Bare repositories - Certain commands change their behaviour in a bare repository (i.e. a repository without associated working tree). We use a fairly conservative heuristic (if $GIT_DIR is ".git", or ends with "/.git", the repository is not bare) to decide if a repository is bare, but "core.bare" configuration variable can be used to override the heuristic when it misidentifies your repository. - git-fetch used to complain updating the current branch but this is now allowed for a bare repository. So is the use of 'git-branch -f' to update the current branch. - Porcelain-ish commands that require a working tree refuses to work in a bare repository. * Reflog - Reflog records the history of where the tip of each branch was at each moment. This facility is enabled by default for repositories with working trees, and can be accessed with the "branch@{time}" and "branch@{Nth}" notation. - "git show-branch" learned showing the reflog data with the new --reflog option. "git log" has --walk-reflogs option to view reflog entries in a more verbose manner. - git-branch knows how to rename branches and moves existing reflog data from the old branch to the new one. - The commits referred to by reflog entries are now protected against pruning. The new command "git reflog expire" can be used to truncate older reflog entries and entries that refer to commits that have been pruned away previously with older versions of git. Existing repositories that have been using reflog may get complaints from fsck-objects and may not be able to run git-repack, if you had run git-prune from older git; please run "git reflog expire --stale-fix --all" first to remove reflog entries that refer to commits that are no longer in the repository when that happens. * Crufts removal - We used to say "old commits are retrievable using reflog and 'master@{yesterday}' syntax as long as you haven't run git-prune". We no longer have to say the latter half of the above sentence, as git-prune does not remove things reachable from reflog entries. - 'git-prune' by default does not remove _everything_ unreachable, as there is a one-day grace period built-in. - There is a toplevel garbage collector script, 'git-gc', that is an easy way to run 'git-repack -a -d', 'git-reflog gc', and 'git-prune'. * Detached HEAD - You can give non-branch to "git checkout" now. This will dissociate your HEAD from any of your branches. A typical use of this feature is to "look around". E.g. $ git checkout v2.6.16 ... compile, test, etc. $ git checkout v2.6.17 ... compile, test, etc. - After detaching your HEAD, you can go back to an existing branch with usual "git checkout $branch". Also you can start a new branch using "git checkout -b $newbranch". - You can even pull from other repositories, make merges and commits while your HEAD is detached. Also you can use "git reset" to jump to arbitrary commit. Going back to undetached state by "git checkout $branch" can lose the current stat you arrived in these ways, and "git checkout" refuses when the detached HEAD is not pointed by any existing ref (an existing branch, a remote tracking branch or a tag). This safety can be overriden with "git checkout -f $branch". * Packed refs - Repositories with hundreds of tags have been paying large overhead, both in storage and in runtime, due to the traditional one-ref-per-file format. A new command, git-pack-refs, can be used to "pack" them in more efficient representation. - Clones and fetches over dumb transports are now aware of packed refs and can download from repositories that use them. * Configuration - configuration related to color setting are consolidated under color.* namespace (older diff.color.*, status.color.* are still supported). * Less external dependency - We no longer require the "merge" program from the RCS suite. All 3-way file-level merges are now done internally. - The original implementation of git-merge-recursive which was in Python has been removed; we have C implementation of it now. - git-shortlog is no longer a Perl script. It no longer requires output piped from git-log; it can accept revision parameters directly on the command line. * I18n - We have always encouraged the commit message to be encoded in UTF-8, but the users are allowed to use legacy encoding as appropriate for their projects. This will continue to be the case. However, a non UTF-8 commit encoding _must_ be explicitly set with i18n.commitencoding in the repository where a commit is made; otherwise git-commit-tree will complain if the log message does not look like a valid UTF-8 string. - The value of i18n.commitencoding in the originating repository is recorded in the commit object on the "encoding" header, if it is not UTF-8. git-log and friends notice this, and reencodes the message to the log output encoding when displaying, if they are different. The log output encoding is determined by "git log --encoding=<encoding>", i18n.logoutputencoding configuration, or i18n.commitencoding configuration, in the decreasing order of preference, and defaults to UTF-8. - Tools for e-mailed patch application now default to -u behaviour; i.e. it always re-codes from the e-mailed encoding to the encoding specified with i18n.commitencoding. This unfortunately forces projects that have happily been using a legacy encoding without setting i18n.commitencoding to set the configuration, but taken with other improvement, please excuse us for this very minor one-time inconvenience. * e-mailed patches - See the above I18n section. - git-format-patch now enables --binary without being asked. git-am does _not_ default to it, as sending binary patch via e-mail is unusual and is harder to review than textual patches and it is prudent to require the person who is applying the patch to explicitly ask for it. - The default suffix for git-format-patch output is now ".patch", not ".txt". This can be changed with --suffix=.txt option, or "format.suffix = .txt" in the configuration. * Foreign SCM interfaces - git-svn now requires the Perl SVN:: libraries, the command-line backend was too slow and limited. - the 'commit' subcommand of git-svn has been renamed to 'set-tree', and 'dcommit' is the recommended replacement for day-to-day work. * User support - Quite a lot of documentation updates. - Bash completion scripts have been updated heavily. - Better error messages for often used Porcelainish commands. * Sliding mmap - We used to assume that we can mmap the whole packfile while in use, but with a large project this consumes huge virtual memory space and truly huge ones would not fit in the userland address space on 32-bit platforms. We now mmap huge packfile in pieces to avoid this problem. * Shallow clones - There is a partial support for 'shallow' repositories that keeps only recent history. A 'shallow clone' is created by specifying how deep that truncated history should be. Currently a shallow repository has number of limitations: - Cloning and fetching _from_ a shallow clone are not supported (nor tested -- so they might work by accident but they are not expected to). - Pushing from nor into a shallow clone are not expected to work. - Merging inside a shallow repository would work as long as a merge base is found in the recent history, but otherwise it will be like merging unrelated histories and may result in huge conflicts. but this would be more than adequate for people who want to look at near the tip of a big project with a deep history and send patches in e-mail format. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 2007-01-21 11:20 ` Junio C Hamano @ 2007-01-21 13:42 ` Bill Lear 2007-01-21 13:52 ` Bill Lear 2007-01-21 13:43 ` Willy Tarreau ` (4 subsequent siblings) 5 siblings, 1 reply; 75+ messages in thread From: Bill Lear @ 2007-01-21 13:42 UTC (permalink / raw) To: Junio C Hamano; +Cc: git, linux-kernel On Sunday, January 21, 2007 at 03:20:06 (-0800) Junio C Hamano writes: >BTW, as the upcoming v1.5.0 release will introduce quite a bit of >surface changes (although at the really core it still is the old >git and old ways should continue to work), I am wondering if it >would help people to try out and find wrinkles before the real >thing for me to cut a tarball and a set of RPM packages. > >Comments? I asked this in the context of the "fatal: protocol error" thread, but can I install the 1.5.0rcX on my machine and use it with our company repository, running 1.4.4.1? In any case, I think trying to find wrinkles before the real thing is certainly healthy. Bill ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 2007-01-21 13:42 ` Bill Lear @ 2007-01-21 13:52 ` Bill Lear 2007-01-21 15:02 ` Michael 2007-01-21 21:26 ` Johannes Schindelin 0 siblings, 2 replies; 75+ messages in thread From: Bill Lear @ 2007-01-21 13:52 UTC (permalink / raw) To: Junio C Hamano, git, linux-kernel Also (apologies for the ignorance), how do I get the 1.5.0-rc2 release? Bill On Sunday, January 21, 2007 at 07:42:56 (-0600) Bill Lear writes: >On Sunday, January 21, 2007 at 03:20:06 (-0800) Junio C Hamano writes: >>BTW, as the upcoming v1.5.0 release will introduce quite a bit of >>surface changes (although at the really core it still is the old >>git and old ways should continue to work), I am wondering if it >>would help people to try out and find wrinkles before the real >>thing for me to cut a tarball and a set of RPM packages. >> >>Comments? > >I asked this in the context of the "fatal: protocol error" >thread, but can I install the 1.5.0rcX on my machine and use >it with our company repository, running 1.4.4.1? > >In any case, I think trying to find wrinkles before the real >thing is certainly healthy. > > >Bill >- >To unsubscribe from this list: send the line "unsubscribe git" in >the body of a message to majordomo@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 @ 2007-01-21 15:02 ` Michael 0 siblings, 0 replies; 75+ messages in thread From: Michael @ 2007-01-21 15:02 UTC (permalink / raw) To: git; +Cc: Bill Lear Bill Lear: > Also (apologies for the ignorance), how do I get the 1.5.0-rc2 release? git clone git://git.kernel.org/pub/scm/git/git.git Then checkout the commit tagged 'v1.5.0-rc2'. There are no such tarballs (yet) on: http://www.kernel.org/pub/software/scm/git/ ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 @ 2007-01-21 15:02 ` Michael 0 siblings, 0 replies; 75+ messages in thread From: Michael @ 2007-01-21 15:02 UTC (permalink / raw) To: git; +Cc: Bill Lear Bill Lear: > Also (apologies for the ignorance), how do I get the 1.5.0-rc2 release? git clone git://git.kernel.org/pub/scm/git/git.git Then checkout the commit tagged 'v1.5.0-rc2'. There are no such tarballs (yet) on: http://www.kernel.org/pub/software/scm/git/ ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 2007-01-21 13:52 ` Bill Lear 2007-01-21 15:02 ` Michael @ 2007-01-21 21:26 ` Johannes Schindelin 2007-01-21 21:33 ` Jakub Narebski 1 sibling, 1 reply; 75+ messages in thread From: Johannes Schindelin @ 2007-01-21 21:26 UTC (permalink / raw) To: Bill Lear; +Cc: Junio C Hamano, git, linux-kernel Hi, On Sun, 21 Jan 2007, Bill Lear wrote: > Also (apologies for the ignorance), how do I get the 1.5.0-rc2 release? Direct your browser to http://repo.or.cz/w/git.git?a=snapshot;h=eaf6459e4d482af51429f9464125621b805eb5f BTW please don't top post. It uses bandwidth unnecessarily (both in terms of megabytes and attention). Ciao, Dscho ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 2007-01-21 21:26 ` Johannes Schindelin @ 2007-01-21 21:33 ` Jakub Narebski 0 siblings, 0 replies; 75+ messages in thread From: Jakub Narebski @ 2007-01-21 21:33 UTC (permalink / raw) To: linux-kernel; +Cc: git Johannes Schindelin wrote: > On Sun, 21 Jan 2007, Bill Lear wrote: > >> Also (apologies for the ignorance), how do I get the 1.5.0-rc2 release? > > Direct your browser to > > http://repo.or.cz/w/git.git?a=snapshot;h=eaf6459e4d482af51429f9464125621b805eb5f Better URL is http://repo.or.cz/w/git.git?a=snapshot;h=v1.5.0-rc2 -- Jakub Narebski Warsaw, Poland ShadeHawk on #git ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 @ 2007-01-21 21:33 ` Jakub Narebski 0 siblings, 0 replies; 75+ messages in thread From: Jakub Narebski @ 2007-01-21 21:33 UTC (permalink / raw) To: git; +Cc: linux-kernel Johannes Schindelin wrote: > On Sun, 21 Jan 2007, Bill Lear wrote: > >> Also (apologies for the ignorance), how do I get the 1.5.0-rc2 release? > > Direct your browser to > > http://repo.or.cz/w/git.git?a=snapshot;h=eaf6459e4d482af51429f9464125621b805eb5f Better URL is http://repo.or.cz/w/git.git?a=snapshot;h=v1.5.0-rc2 -- Jakub Narebski Warsaw, Poland ShadeHawk on #git ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 2007-01-21 21:33 ` Jakub Narebski (?) @ 2007-01-21 22:01 ` Johannes Schindelin 2007-01-21 22:24 ` Jakub Narebski -1 siblings, 1 reply; 75+ messages in thread From: Johannes Schindelin @ 2007-01-21 22:01 UTC (permalink / raw) To: Jakub Narebski; +Cc: git, linux-kernel Hi, On Sun, 21 Jan 2007, Jakub Narebski wrote: > Johannes Schindelin wrote: > > > On Sun, 21 Jan 2007, Bill Lear wrote: > > > >> Also (apologies for the ignorance), how do I get the 1.5.0-rc2 release? > > > > Direct your browser to > > > > http://repo.or.cz/w/git.git?a=snapshot;h=eaf6459e4d482af51429f9464125621b805eb5f > > Better URL is > > http://repo.or.cz/w/git.git?a=snapshot;h=v1.5.0-rc2 It is a better URL. Somehow I fscked up when I tried it, so I had the impression that does not work. But it does. Sorry, Dscho ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 2007-01-21 22:01 ` Johannes Schindelin @ 2007-01-21 22:24 ` Jakub Narebski 0 siblings, 0 replies; 75+ messages in thread From: Jakub Narebski @ 2007-01-21 22:24 UTC (permalink / raw) To: linux-kernel; +Cc: git Johannes Schindelin wrote: > On Sun, 21 Jan 2007, Jakub Narebski wrote: >> Johannes Schindelin wrote: >>> On Sun, 21 Jan 2007, Bill Lear wrote: >>> >>>> Also (apologies for the ignorance), how do I get the 1.5.0-rc2 release? >>> >>> Direct your browser to >>> >>> http://repo.or.cz/w/git.git?a=snapshot;h=eaf6459e4d482af51429f9464125621b805eb5f >> >> Better URL is >> >> http://repo.or.cz/w/git.git?a=snapshot;h=v1.5.0-rc2 > > It is a better URL. Somehow I fscked up when I tried it, so I had the > impression that does not work. But it does. Most probably you wrote '1.5.0-rc2' instead of 'v1.5.0-rc2' (with 'v' prefix). -- Jakub Narebski Warsaw, Poland ShadeHawk on #git ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 @ 2007-01-21 22:24 ` Jakub Narebski 0 siblings, 0 replies; 75+ messages in thread From: Jakub Narebski @ 2007-01-21 22:24 UTC (permalink / raw) To: git; +Cc: linux-kernel Johannes Schindelin wrote: > On Sun, 21 Jan 2007, Jakub Narebski wrote: >> Johannes Schindelin wrote: >>> On Sun, 21 Jan 2007, Bill Lear wrote: >>> >>>> Also (apologies for the ignorance), how do I get the 1.5.0-rc2 release? >>> >>> Direct your browser to >>> >>> http://repo.or.cz/w/git.git?a=snapshot;h=eaf6459e4d482af51429f9464125621b805eb5f >> >> Better URL is >> >> http://repo.or.cz/w/git.git?a=snapshot;h=v1.5.0-rc2 > > It is a better URL. Somehow I fscked up when I tried it, so I had the > impression that does not work. But it does. Most probably you wrote '1.5.0-rc2' instead of 'v1.5.0-rc2' (with 'v' prefix). -- Jakub Narebski Warsaw, Poland ShadeHawk on #git ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 2007-01-21 11:20 ` Junio C Hamano 2007-01-21 13:42 ` Bill Lear @ 2007-01-21 13:43 ` Willy Tarreau 2007-01-21 15:06 ` Jakub Narebski 2007-01-21 18:58 ` Junio C Hamano 2007-01-21 19:46 ` Horst H. von Brand ` (3 subsequent siblings) 5 siblings, 2 replies; 75+ messages in thread From: Willy Tarreau @ 2007-01-21 13:43 UTC (permalink / raw) To: Junio C Hamano; +Cc: git, linux-kernel Hi Junio ! On Sun, Jan 21, 2007 at 03:20:06AM -0800, Junio C Hamano wrote: > BTW, as the upcoming v1.5.0 release will introduce quite a bit of > surface changes (although at the really core it still is the old > git and old ways should continue to work), I am wondering if it > would help people to try out and find wrinkles before the real > thing for me to cut a tarball and a set of RPM packages. > > Comments? Anything you can do to make tester's life easier will always slightly increase the number of testers. Hint: how often do you try random software that requires that you first install CVS, SVN or arch just to get it, compared to how often you try random software provided as tar.gz ? Pre-release tar.gz and rpms coupled with a freshmeat announcement should get you a bunch of testers and newcomers. This will give the new doc a real trial, and will help discover traps in which beginners often fall. > Also, in the same spirit of giving the release an early > exposure, here is the current draft of 1.5.0 release notes. (...) > - There is a configuration variable core.legacyheaders that > changes the format of loose objects so that they are more > efficient to pack and to send out of the repository over git > native protocol, since v1.4.2. However, loose objects > written in the new format cannot be read by git older than > that version; people fetching from your repository using > older clients over dumb transports (e.g. http) using older > versions of git will also be affected. > > - Since v1.4.3, configuration repack.usedeltabaseoffset allows > packfile to be created in more space efficient format, which > cannot be read by git older than that version. I know it's a bit late to ask, but if new on-disk format changes, isn't it time to bump the version to 2.0 ? It would be easier for many people to remember that GIT 1.X uses format version 1 and that GIT 2.X uses format version 2 with backwards compatibility with 1.X. I also think that 1.5 is much more different from 1.0 than a mid-term 2.0 would be from current 1.5. That said, kudos for the nice changelog ! Regards, Willy ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 2007-01-21 13:43 ` Willy Tarreau @ 2007-01-21 15:06 ` Jakub Narebski 2007-01-21 18:58 ` Junio C Hamano 1 sibling, 0 replies; 75+ messages in thread From: Jakub Narebski @ 2007-01-21 15:06 UTC (permalink / raw) To: linux-kernel; +Cc: git Willy Tarreau wrote: > On Sun, Jan 21, 2007 at 03:20:06AM -0800, Junio C Hamano wrote: >> BTW, as the upcoming v1.5.0 release will introduce quite a bit of >> surface changes (although at the really core it still is the old >> git and old ways should continue to work), I am wondering if it >> would help people to try out and find wrinkles before the real >> thing for me to cut a tarball and a set of RPM packages. >> >> Comments? > > Anything you can do to make tester's life easier will always slightly > increase the number of testers. Hint: how often do you try random > software that requires that you first install CVS, SVN or arch just to > get it, compared to how often you try random software provided as tar.gz ? > Pre-release tar.gz and rpms coupled with a freshmeat announcement should > get you a bunch of testers and newcomers. This will give the new doc a > real trial, and will help discover traps in which beginners often fall. RPMS are nicely divided into (sub)packages, so you need CVS indtalled only if you install git-cvs package, for example to interact with CVS. git-core has minimal dependencies. To compile git you truly don't need other software installed (1.5.0 for example does not require RCS anymore for RCS merge). -- Jakub Narebski Warsaw, Poland ShadeHawk on #git ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 @ 2007-01-21 15:06 ` Jakub Narebski 0 siblings, 0 replies; 75+ messages in thread From: Jakub Narebski @ 2007-01-21 15:06 UTC (permalink / raw) To: git; +Cc: linux-kernel Willy Tarreau wrote: > On Sun, Jan 21, 2007 at 03:20:06AM -0800, Junio C Hamano wrote: >> BTW, as the upcoming v1.5.0 release will introduce quite a bit of >> surface changes (although at the really core it still is the old >> git and old ways should continue to work), I am wondering if it >> would help people to try out and find wrinkles before the real >> thing for me to cut a tarball and a set of RPM packages. >> >> Comments? > > Anything you can do to make tester's life easier will always slightly > increase the number of testers. Hint: how often do you try random > software that requires that you first install CVS, SVN or arch just to > get it, compared to how often you try random software provided as tar.gz ? > Pre-release tar.gz and rpms coupled with a freshmeat announcement should > get you a bunch of testers and newcomers. This will give the new doc a > real trial, and will help discover traps in which beginners often fall. RPMS are nicely divided into (sub)packages, so you need CVS indtalled only if you install git-cvs package, for example to interact with CVS. git-core has minimal dependencies. To compile git you truly don't need other software installed (1.5.0 for example does not require RCS anymore for RCS merge). -- Jakub Narebski Warsaw, Poland ShadeHawk on #git ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 2007-01-21 13:43 ` Willy Tarreau 2007-01-21 15:06 ` Jakub Narebski @ 2007-01-21 18:58 ` Junio C Hamano 2007-01-21 19:49 ` H. Peter Anvin 2007-01-21 20:01 ` Horst H. von Brand 1 sibling, 2 replies; 75+ messages in thread From: Junio C Hamano @ 2007-01-21 18:58 UTC (permalink / raw) To: Willy Tarreau; +Cc: git, linux-kernel, hpa Willy Tarreau <w@1wt.eu> writes: > Anything you can do to make tester's life easier will always slightly > increase the number of testers. > ... > Pre-release tar.gz and rpms coupled with a freshmeat announcement should > get you a bunch of testers and newcomers. This will give the new doc a > real trial, and will help discover traps in which beginners often fall. One worry I had about releasing git-1.5.0-rc2-1.rpm and friends just like the "official" ones was that people might have scripts to automate downloading & updating of packages, and they may not like to get "beta" installed for them. I wonder if kernel.org machines are also affected... >> Also, in the same spirit of giving the release an early >> exposure, here is the current draft of 1.5.0 release notes. > > (...) > >> - There is a configuration variable core.legacyheaders that >> changes the format of loose objects so that they are more >> efficient to pack and to send out of the repository over git >> native protocol, since v1.4.2. However, loose objects >> written in the new format cannot be read by git older than >> that version; people fetching from your repository using >> older clients over dumb transports (e.g. http) using older >> versions of git will also be affected. >> >> - Since v1.4.3, configuration repack.usedeltabaseoffset allows >> packfile to be created in more space efficient format, which >> cannot be read by git older than that version. > > I know it's a bit late to ask, but if new on-disk format changes, isn't > it time to bump the version to 2.0? It would be easier for many people to > remember that GIT 1.X uses format version 1 and that GIT 2.X uses format > version 2 with backwards compatibility with 1.X. I also think that 1.5 > is much more different from 1.0 than a mid-term 2.0 would be from current > 1.5. I think we could have gone either way (as you said, it is probably a bit too late to discuss this), but it should probably be Ok to stay at 1.X as long as these one-way-street format updates are turned off by default. And the above happened way before this round and people have hopefully been happily using. For example, v1.4.2 was done early August 2006. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 2007-01-21 18:58 ` Junio C Hamano @ 2007-01-21 19:49 ` H. Peter Anvin 2007-01-22 17:23 ` Nicolas Pitre 2007-01-21 20:01 ` Horst H. von Brand 1 sibling, 1 reply; 75+ messages in thread From: H. Peter Anvin @ 2007-01-21 19:49 UTC (permalink / raw) To: Junio C Hamano; +Cc: Willy Tarreau, git, linux-kernel Junio C Hamano wrote: > > One worry I had about releasing git-1.5.0-rc2-1.rpm and friends > just like the "official" ones was that people might have scripts > to automate downloading & updating of packages, and they may not > like to get "beta" installed for them. > > I wonder if kernel.org machines are also affected... > Put them in a different directory hierarchy if you don't want to make them installed. >> I know it's a bit late to ask, but if new on-disk format changes, isn't >> it time to bump the version to 2.0? It would be easier for many people to >> remember that GIT 1.X uses format version 1 and that GIT 2.X uses format >> version 2 with backwards compatibility with 1.X. I also think that 1.5 >> is much more different from 1.0 than a mid-term 2.0 would be from current >> 1.5. > > I think we could have gone either way (as you said, it is > probably a bit too late to discuss this), but it should probably > be Ok to stay at 1.X as long as these one-way-street format > updates are turned off by default. > > And the above happened way before this round and people have > hopefully been happily using. For example, v1.4.2 was done > early August 2006. In general, though, I would agree that the major number should change if there is an incompatible change. -hpa ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 2007-01-21 19:49 ` H. Peter Anvin @ 2007-01-22 17:23 ` Nicolas Pitre 0 siblings, 0 replies; 75+ messages in thread From: Nicolas Pitre @ 2007-01-22 17:23 UTC (permalink / raw) To: H. Peter Anvin; +Cc: Junio C Hamano, Willy Tarreau, git, lkml On Sun, 21 Jan 2007, H. Peter Anvin wrote: > In general, though, I would agree that the major number should change if there > is an incompatible change. Maybe when those incompatible features are enabled by default. Right now they're not. Nicolas ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 2007-01-21 18:58 ` Junio C Hamano 2007-01-21 19:49 ` H. Peter Anvin @ 2007-01-21 20:01 ` Horst H. von Brand 2007-01-22 1:27 ` Junio C Hamano 1 sibling, 1 reply; 75+ messages in thread From: Horst H. von Brand @ 2007-01-21 20:01 UTC (permalink / raw) To: Junio C Hamano; +Cc: Willy Tarreau, git, linux-kernel, hpa Junio C Hamano <junkio@cox.net> wrote: > Willy Tarreau <w@1wt.eu> writes: > > Anything you can do to make tester's life easier will always slightly > > increase the number of testers. > > ... > > Pre-release tar.gz and rpms coupled with a freshmeat announcement should > > get you a bunch of testers and newcomers. This will give the new doc a > > real trial, and will help discover traps in which beginners often fall. > > One worry I had about releasing git-1.5.0-rc2-1.rpm and friends > just like the "official" ones was that people might have scripts > to automate downloading & updating of packages, and they may not > like to get "beta" installed for them. Then put them into a "testing" or "pre-release" directory... -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 2007-01-21 20:01 ` Horst H. von Brand @ 2007-01-22 1:27 ` Junio C Hamano 0 siblings, 0 replies; 75+ messages in thread From: Junio C Hamano @ 2007-01-22 1:27 UTC (permalink / raw) To: Horst H. von Brand; +Cc: Willy Tarreau, git, linux-kernel, hpa "Horst H. von Brand" <vonbrand@inf.utfsm.cl> writes: > Junio C Hamano <junkio@cox.net> wrote: >> Willy Tarreau <w@1wt.eu> writes: >> > Anything you can do to make tester's life easier will always slightly >> > increase the number of testers. >> > ... >> > Pre-release tar.gz and rpms coupled with a freshmeat announcement should >> > get you a bunch of testers and newcomers. This will give the new doc a >> > real trial, and will help discover traps in which beginners often fall. >> >> One worry I had about releasing git-1.5.0-rc2-1.rpm and friends >> just like the "official" ones was that people might have scripts >> to automate downloading & updating of packages, and they may not >> like to get "beta" installed for them. > > Then put them into a "testing" or "pre-release" directory... Ok, thanks for the suggestion. The preview RPMs for i386 and x86_64 and an SRPM are available at: /pub/software/scm/git/testing/ The tarball for 1.5.0-rc2 is found at: /pub/software/scm/git/git-1.5.0.rc2.tar.gz along with tarballs of preformatted htmldocs and manpages. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 2007-01-21 11:20 ` Junio C Hamano 2007-01-21 13:42 ` Bill Lear 2007-01-21 13:43 ` Willy Tarreau @ 2007-01-21 19:46 ` Horst H. von Brand 2007-01-21 20:51 ` Junio C Hamano 2007-01-21 21:55 ` Johannes Schindelin ` (2 subsequent siblings) 5 siblings, 1 reply; 75+ messages in thread From: Horst H. von Brand @ 2007-01-21 19:46 UTC (permalink / raw) To: Junio C Hamano; +Cc: git, linux-kernel Junio C Hamano <junkio@cox.net> wrote: > BTW, as the upcoming v1.5.0 release will introduce quite a bit of > surface changes (although at the really core it still is the old > git and old ways should continue to work), I am wondering if it > would help people to try out and find wrinkles before the real > thing for me to cut a tarball and a set of RPM packages. > > Comments? > > Also, in the same spirit of giving the release an early > exposure, here is the current draft of 1.5.0 release notes. > > -- >8 -- cut here -- >8 -- > > GIT v1.5.0 Release Notes (draft) > ================================ > > Old news > -------- [...] > - There is a configuration variable core.legacyheaders that > changes the format of loose objects so that they are more > efficient to pack and to send out of the repository over git > native protocol, since v1.4.2. However, loose objects > written in the new format cannot be read by git older than > that version; people fetching from your repository using > older clients over dumb transports (e.g. http) using older > versions of git will also be affected. Huh? What are possible values of that variable? What happens if it is set/unset? I'd suppose that if it is set, you get the old format, but that isn't clear. > - Since v1.4.3, configuration repack.usedeltabaseoffset allows > packfile to be created in more space efficient format, which > cannot be read by git older than that version. Same as above. > The above two are not enabled by default and you explicitly have > to ask for them, because these two features make repositories > unreadable by older versions of git, and in v1.5.0 we still do > not enable them by default for the same reason. We will change > this default probably 1 year after 1.4.2's release, when it is > reasonable to expect everybody to have new enough version of > git. I don't see an upgrade path here that doesn't involve keeping cruft "new feature is on" variables around indefinitely... Why not just a repository version? [...] > Updates in v1.5.0 since v1.4.4 series > ------------------------------------- > > * Index manipulation [...] > - git-add without any argument does not add everything > anymore. Use 'git-add .' instead. Also you can add > otherwise ignored files with an -f option. I suppose "git add ." works for 'adding everything' only at the top? > - git-add tries to be more friendly to users by offering an > interactive mode. Why not tell about "git add -i"? [...] > * Detached HEAD [...] > - After detaching your HEAD, you can go back to an existing > branch with usual "git checkout $branch". Also you can > start a new branch using "git checkout -b $newbranch". Where is such a branch rooted? > - You can even pull from other repositories, make merges and > commits while your HEAD is detached. Also you can use "git > reset" to jump to arbitrary commit. Does this leave you on that branch, or still in limbo? > Going back to undetached state by "git checkout $branch" can s/undetached/attached/ > lose the current stat you arrived in these ways, and "git > checkout" refuses when the detached HEAD is not pointed by > any existing ref (an existing branch, a remote tracking > branch or a tag). This safety can be overriden with "git > checkout -f $branch". What happens if there are changes in the tracked files? [...] > * Shallow clones > > - There is a partial support for 'shallow' repositories that > keeps only recent history. A 'shallow clone' is created by > specifying how deep that truncated history should be. A bit of detail on how to specify shallowness would be nice here... Very nice work, thanks! -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 2007-01-21 19:46 ` Horst H. von Brand @ 2007-01-21 20:51 ` Junio C Hamano 0 siblings, 0 replies; 75+ messages in thread From: Junio C Hamano @ 2007-01-21 20:51 UTC (permalink / raw) To: Horst H. von Brand; +Cc: git "Horst H. von Brand" <vonbrand@inf.utfsm.cl> writes: > What are possible values of that variable? What happens if it is set/unset? > I'd suppose that if it is set, you get the old format, but that isn't clear. All are valid questions, but the release notes will be too long if it made into "migration manual plus full documentation of new features". Its purpose is to list things you would want to pay attention to. > ... > I don't see an upgrade path here that doesn't involve keeping cruft "new > feature is on" variables around indefinitely... The new feature will be on regardless of the configuration at some point, perhaps in GIT 2.0. For now it isn't, and that is another reason the release notes do not have to (and probably should not for the sake of brevity) talk about gory details to turn the feature on. If we were to do the feature in "incompatible by default" way, the release notes should talk about how to turn it off and keep the old way. >> - git-add tries to be more friendly to users by offering an >> interactive mode. > > Why not tell about "git add -i"? Thanks, will update. s/mode\.$/mode ("git-add -i")./ >> - After detaching your HEAD, you can go back to an existing >> branch with usual "git checkout $branch". Also you can >> start a new branch using "git checkout -b $newbranch". > > Where is such a branch rooted? I did not think it needs to be mentioned as "git checkout -b $newbranch" has always been "git checkout -b $newbranch HEAD" and this is not changed with detached HEAD. Maybe I should add "... to start a new branch at that commit" at the end of the sentence. Thanks. >> - You can even pull from other repositories, make merges and >> commits while your HEAD is detached. Also you can use "git >> reset" to jump to arbitrary commit. > > Does this leave you on that branch, or still in limbo? Perhaps "s/\.$/, while still keeping your HEAD detached./". Will update. >> lose the current stat you arrived in these ways, and "git >> checkout" refuses when the detached HEAD is not pointed by >> any existing ref (an existing branch, a remote tracking >> branch or a tag). This safety can be overriden with "git >> checkout -f $branch". > > What happens if there are changes in the tracked files? The answer is "just like normal checkout does", but I think that level of detail does not belong to the release notes. The list of features is meant to be just to introduce what new things there are, and people interested should learn the details from the documentation. > A bit of detail on how to specify shallowness would be nice here... The same comment as the above applies here. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 2007-01-21 11:20 ` Junio C Hamano ` (2 preceding siblings ...) 2007-01-21 19:46 ` Horst H. von Brand @ 2007-01-21 21:55 ` Johannes Schindelin 2007-01-21 22:45 ` Jakub Narebski ` (4 more replies) 2007-01-22 18:08 ` [Announce] GIT v1.5.0-rc2 Carl Worth 2007-01-22 18:22 ` Jakub Narebski 5 siblings, 5 replies; 75+ messages in thread From: Johannes Schindelin @ 2007-01-21 21:55 UTC (permalink / raw) To: Junio C Hamano; +Cc: git, linux-kernel Hi, On Sun, 21 Jan 2007, Junio C Hamano wrote: > - 'git pack-refs' appeared in v1.4.4; You should probably mention that it is not necessary to run git-pack-refs by hand: git-gc is what you want. BTW have I praised y'all for inventing git-gc? It is _awesome_. I think I will turn into a DWIM geek yet; it is soooo much more convenient to issue "git gc" from time to time, than to think exactly about what I want to clean up right now. > - 'git repo-config', 'git grep', 'git rebase' and 'gitk' were > seriously enhanced during v1.4.0 timeperiod. Should we introduce "git config" in time for the "let's please end-users" release (1.5.0)? > - git-clone always uses what is known as "separate remote" > layout for a newly created repository with a working tree; > i.e. tracking branches in $GIT_DIR/refs/remotes/origin/ are > used to track branches from the origin. ... instead of $GIT_DIR/refs/heads/, making the difference between remotely tracked and local branches more obvious. > - git-branch and git-show-branch know remote tracking branches. ... (use the command line switch "-r" to list only tracked branches.) > - git-push can now be used to delete a remote branch or a tag. > This requires the updated git on the remote side. ... (use "git push <remote> :refs/heads/<branch>" to delete "branch".) > - git-push more agressively keeps the transferred objects > packed. Earlier we recommended to monitor amount of loose > objects and repack regularly, but you should repack when you > accumulated too many small packs this way as well. Updated > git-count-objects helps you with this. It might make sense to enable something similar for git-fetch in time for 1.5.0. > * Reflog > > - Reflog records the history of where the tip of each branch > was at each moment. It might make sense to reformulate that: Reflog records the history from the view point of the local repository. In other words, regardless of the real history, the reflog shows the history as seen by one particular repository (this enables you to ask "what was the current revision in _this_ repository, yesterday at 1pm?"). > - There is a toplevel garbage collector script, 'git-gc', that > is an easy way to run 'git-repack -a -d', 'git-reflog gc', > and 'git-prune'. Did I mention that I really _love_ git-gc? > - The original implementation of git-merge-recursive which was > in Python has been removed; we have C implementation of it > now. I am no native speaker, but should that not be "we have a C implementation" instead? > - The default suffix for git-format-patch output is now ".patch", > not ".txt". This can be changed with --suffix=.txt option, > or "format.suffix = .txt" in the configuration. I fully expect people to complain that a config like this format.suffix = .txt does not work. better say ... or setting the config variable "format.suffix" to ".txt". > - Better error messages for often used Porcelainish commands. Amen. I think this really helped a lot of people already. > - Cloning and fetching _from_ a shallow clone are not > supported (nor tested -- so they might work by accident but > they are not expected to). Maybe we should go the "restrict first, and loosen later" approach? I.e. forbid git-upload-pack to run if is_repository_shallow()? > - Pushing from nor into a shallow clone are not expected to > work. Maybe forbid git-push and git-receive-pack to run if is_repository_shallow()? (I _think_ git-push should be safe, but not git-receive-pack.) Ciao, Dscho ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 2007-01-21 21:55 ` Johannes Schindelin @ 2007-01-21 22:45 ` Jakub Narebski 2007-01-22 0:55 ` Junio C Hamano ` (3 subsequent siblings) 4 siblings, 0 replies; 75+ messages in thread From: Jakub Narebski @ 2007-01-21 22:45 UTC (permalink / raw) To: linux-kernel; +Cc: git Johannes Schindelin wrote: > On Sun, 21 Jan 2007, Junio C Hamano wrote: >> * Reflog >> >> - Reflog records the history of where the tip of each branch >> was at each moment. > > It might make sense to reformulate that: > > Reflog records the history from the view point of the local > repository. In other words, regardless of the real history, > the reflog shows the history as seen by one particular repository > (this enables you to ask "what was the current revision in _this_ > repository, yesterday at 1pm?"). I think that _both_ sentences are right. Reflog records history of where the tip of each branch was at each moment, logging also what command was used to move tip of branch (was it commit, amending commit, rebase, reset, or creating branch anew, git-am or pull). But where tip of each branch was is purely local matter. What is global is DAG of commits, refs are always as seen by one particular repository. -- Jakub Narebski Warsaw, Poland ShadeHawk on #git ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 @ 2007-01-21 22:45 ` Jakub Narebski 0 siblings, 0 replies; 75+ messages in thread From: Jakub Narebski @ 2007-01-21 22:45 UTC (permalink / raw) To: git; +Cc: linux-kernel Johannes Schindelin wrote: > On Sun, 21 Jan 2007, Junio C Hamano wrote: >> * Reflog >> >> - Reflog records the history of where the tip of each branch >> was at each moment. > > It might make sense to reformulate that: > > Reflog records the history from the view point of the local > repository. In other words, regardless of the real history, > the reflog shows the history as seen by one particular repository > (this enables you to ask "what was the current revision in _this_ > repository, yesterday at 1pm?"). I think that _both_ sentences are right. Reflog records history of where the tip of each branch was at each moment, logging also what command was used to move tip of branch (was it commit, amending commit, rebase, reset, or creating branch anew, git-am or pull). But where tip of each branch was is purely local matter. What is global is DAG of commits, refs are always as seen by one particular repository. -- Jakub Narebski Warsaw, Poland ShadeHawk on #git ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 2007-01-21 22:45 ` Jakub Narebski (?) @ 2007-01-21 22:52 ` Johannes Schindelin 2007-01-21 23:08 ` Jakub Narebski -1 siblings, 1 reply; 75+ messages in thread From: Johannes Schindelin @ 2007-01-21 22:52 UTC (permalink / raw) To: Jakub Narebski; +Cc: git Hi, On Sun, 21 Jan 2007, Jakub Narebski wrote: > Johannes Schindelin wrote: > > > On Sun, 21 Jan 2007, Junio C Hamano wrote: > > >> * Reflog > >> > >> - Reflog records the history of where the tip of each branch > >> was at each moment. > > > > It might make sense to reformulate that: > > > > Reflog records the history from the view point of the local > > repository. In other words, regardless of the real history, > > the reflog shows the history as seen by one particular repository > > (this enables you to ask "what was the current revision in _this_ > > repository, yesterday at 1pm?"). > > I think that _both_ sentences are right. Reflog records history of where the > tip of each branch was at each moment, logging also what command was used > to move tip of branch (was it commit, amending commit, rebase, reset, or > creating branch anew, git-am or pull). > > But where tip of each branch was is purely local matter. What is global > is DAG of commits, refs are always as seen by one particular repository. What I meant was: people not familiar with git development will probably not understand the shorter, concise statement. They will not know off-hand that there is a difference between the history of development, and the history, as seen from the local repository's viewpoint. So of course, both sentences are right. Your point -- that reflog also records the action -- is less important IMHO. It is just meta-data of the local view. To your second point: the global history remains global, of course. But this is what you _usually_ refer to, when talking about the development history, anyway. Therefore, to motivate reflogs, you should point out the differences between local and global history. And this means to at least _mention_ the word "local". Ciao, Dscho ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 2007-01-21 22:52 ` Johannes Schindelin @ 2007-01-21 23:08 ` Jakub Narebski 2007-01-21 23:13 ` Johannes Schindelin 0 siblings, 1 reply; 75+ messages in thread From: Jakub Narebski @ 2007-01-21 23:08 UTC (permalink / raw) To: Johannes Schindelin; +Cc: git, Junio C Hamano Johannes Schindelin wrote: > On Sun, 21 Jan 2007, Jakub Narebski wrote: > >> Johannes Schindelin wrote: >> >>> On Sun, 21 Jan 2007, Junio C Hamano wrote: >> >>>> * Reflog >>>> >>>> - Reflog records the history of where the tip of each branch >>>> was at each moment. >>> >>> It might make sense to reformulate that: >>> >>> Reflog records the history from the view point of the local >>> repository. In other words, regardless of the real history, >>> the reflog shows the history as seen by one particular repository >>> (this enables you to ask "what was the current revision in _this_ >>> repository, yesterday at 1pm?"). >> >> I think that _both_ sentences are right. Reflog records history of where the >> tip of each branch was at each moment, logging also what command was used >> to move tip of branch (was it commit, amending commit, rebase, reset, or >> creating branch anew, git-am or pull). >> >> But where tip of each branch was is purely local matter. What is global >> is DAG of commits, refs are always as seen by one particular repository. > > What I meant was: people not familiar with git development will probably > not understand the shorter, concise statement. They will not know off-hand > that there is a difference between the history of development, and the > history, as seen from the local repository's viewpoint. > > So of course, both sentences are right. > > Your point -- that reflog also records the action -- is less important > IMHO. It is just meta-data of the local view. > > To your second point: the global history remains global, of course. But > this is what you _usually_ refer to, when talking about the development > history, anyway. Therefore, to motivate reflogs, you should point out the > differences between local and global history. > > And this means to at least _mention_ the word "local". So I'd say: - Reflog records local history of where the tip of each branch was at each moment. I think both "local" and "tip of branch" are important for understanding reflog. -- Jakub Narebski Poland ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 2007-01-21 23:08 ` Jakub Narebski @ 2007-01-21 23:13 ` Johannes Schindelin 2007-01-21 23:36 ` Jakub Narebski 0 siblings, 1 reply; 75+ messages in thread From: Johannes Schindelin @ 2007-01-21 23:13 UTC (permalink / raw) To: Jakub Narebski; +Cc: git, Junio C Hamano Hi, On Mon, 22 Jan 2007, Jakub Narebski wrote: > So I'd say: > > - Reflog records local history of where the tip of each branch > was at each moment. > > I think both "local" and "tip of branch" are important > for understanding reflog. 'kay. Probably the simple addition of "local" is enough. Like it. Ciao, Dscho ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 2007-01-21 23:13 ` Johannes Schindelin @ 2007-01-21 23:36 ` Jakub Narebski 0 siblings, 0 replies; 75+ messages in thread From: Jakub Narebski @ 2007-01-21 23:36 UTC (permalink / raw) To: Johannes Schindelin; +Cc: git, Junio C Hamano Johannes Schindelin wrote: > On Mon, 22 Jan 2007, Jakub Narebski wrote: > >> So I'd say: >> >> - Reflog records local history of where the tip of each branch >> was at each moment. >> >> I think both "local" and "tip of branch" are important >> for understanding reflog. > > 'kay. Probably the simple addition of "local" is enough. Like it. Or perhaps this would be better: - Reflog records the history of where the tip of each branch was at each moment in given repository. Just nitpicking. -- Jakub Narebski Poland ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 2007-01-21 21:55 ` Johannes Schindelin 2007-01-21 22:45 ` Jakub Narebski @ 2007-01-22 0:55 ` Junio C Hamano 2007-01-22 6:25 ` Junio C Hamano ` (2 subsequent siblings) 4 siblings, 0 replies; 75+ messages in thread From: Junio C Hamano @ 2007-01-22 0:55 UTC (permalink / raw) To: Johannes Schindelin; +Cc: git I've read your message only once (may have to come back to think about ramifications of some finer points), but I generally agree. I'd appreciate a patch to the 'todo' branch ;-). ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 2007-01-21 21:55 ` Johannes Schindelin 2007-01-21 22:45 ` Jakub Narebski 2007-01-22 0:55 ` Junio C Hamano @ 2007-01-22 6:25 ` Junio C Hamano 2007-01-23 6:47 ` [PATCH 1/2] Refactor the pack header reading function out of receive-pack.c Junio C Hamano 2007-01-23 6:47 ` [PATCH 2/2] Allow fetch-pack to decide keeping the fetched pack without exploding Junio C Hamano 4 siblings, 0 replies; 75+ messages in thread From: Junio C Hamano @ 2007-01-22 6:25 UTC (permalink / raw) To: Johannes Schindelin; +Cc: git Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: >> - Cloning and fetching _from_ a shallow clone are not >> supported (nor tested -- so they might work by accident but >> they are not expected to). > > Maybe we should go the "restrict first, and loosen later" approach? I.e. > forbid git-upload-pack to run if is_repository_shallow()? > >> - Pushing from nor into a shallow clone are not expected to >> work. > > Maybe forbid git-push and git-receive-pack to run if > is_repository_shallow()? > > (I _think_ git-push should be safe, but not git-receive-pack.) I think that is sensible. Let's do this. -- >8 -- [PATCH] shallow repository: disable unsupported operations for now. We currently do not support fetching/cloning from a shallow repository nor pushing into one. Make sure these are not attempted so that we do not have to worry about corrupting repositories needlessly. Signed-off-by: Junio C Hamano <junkio@cox.net> --- receive-pack.c | 3 +++ upload-pack.c | 3 ++- 2 files changed, 5 insertions(+), 1 deletions(-) diff --git a/receive-pack.c b/receive-pack.c index c176d8f..6333f00 100644 --- a/receive-pack.c +++ b/receive-pack.c @@ -421,6 +421,9 @@ int main(int argc, char **argv) if (!enter_repo(dir, 0)) die("'%s': unable to chdir or not a git archive", dir); + if (is_repository_shallow()) + die("attempt to push into a shallow repository"); + setup_ident(); /* don't die if gecos is empty */ ignore_missing_committer_name(); diff --git a/upload-pack.c b/upload-pack.c index 3a466c6..3648aae 100644 --- a/upload-pack.c +++ b/upload-pack.c @@ -672,7 +672,8 @@ int main(int argc, char **argv) if (!enter_repo(dir, strict)) die("'%s': unable to chdir or not a git archive", dir); - + if (is_repository_shallow()) + die("attempt to fetch/clone from a shallow repository"); upload_pack(); return 0; } -- 1.5.0.rc2 ^ permalink raw reply related [flat|nested] 75+ messages in thread
* [PATCH 1/2] Refactor the pack header reading function out of receive-pack.c 2007-01-21 21:55 ` Johannes Schindelin ` (2 preceding siblings ...) 2007-01-22 6:25 ` Junio C Hamano @ 2007-01-23 6:47 ` Junio C Hamano 2007-01-23 6:47 ` [PATCH 2/2] Allow fetch-pack to decide keeping the fetched pack without exploding Junio C Hamano 4 siblings, 0 replies; 75+ messages in thread From: Junio C Hamano @ 2007-01-23 6:47 UTC (permalink / raw) To: Johannes Schindelin; +Cc: git I'll be reusing it on the fetch-pack side as well. Signed-off-by: Junio C Hamano <junkio@cox.net> --- Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: >> - git-push more agressively keeps the transferred objects >> packed. Earlier we recommended to monitor amount of loose >> objects and repack regularly, but you should repack when you >> accumulated too many small packs this way as well. Updated >> git-count-objects helps you with this. > > It might make sense to enable something similar for git-fetch in time for > 1.5.0. I have two patches that could become the beginning of this, not much tested. This is the first of the two. pack.h | 5 +++++ receive-pack.c | 26 ++++++++++++++------------ sha1_file.c | 21 +++++++++++++++++++++ 3 files changed, 40 insertions(+), 12 deletions(-) diff --git a/pack.h b/pack.h index 821706f..deb427e 100644 --- a/pack.h +++ b/pack.h @@ -44,4 +44,9 @@ struct pack_header { #define PACK_IDX_SIGNATURE 0xff744f63 /* "\377tOc" */ extern int verify_pack(struct packed_git *, int); + +#define PH_ERROR_EOF (-1) +#define PH_ERROR_PACK_SIGNATURE (-2) +#define PH_ERROR_PROTOCOL (-3) +extern int read_pack_header(int fd, struct pack_header *); #endif diff --git a/receive-pack.c b/receive-pack.c index 6333f00..b3a4552 100644 --- a/receive-pack.c +++ b/receive-pack.c @@ -250,20 +250,22 @@ static void read_head_info(void) static const char *parse_pack_header(struct pack_header *hdr) { - char *c = (char*)hdr; - ssize_t remaining = sizeof(struct pack_header); - do { - ssize_t r = xread(0, c, remaining); - if (r <= 0) - return "eof before pack header was fully read"; - remaining -= r; - c += r; - } while (remaining > 0); - if (hdr->hdr_signature != htonl(PACK_SIGNATURE)) + switch (read_pack_header(0, hdr)) { + case PH_ERROR_EOF: + return "eof before pack header was fully read"; + + case PH_ERROR_PACK_SIGNATURE: return "protocol error (pack signature mismatch detected)"; - if (!pack_version_ok(hdr->hdr_version)) + + case PH_ERROR_PROTOCOL: return "protocol error (pack version unsupported)"; - return NULL; + + default: + return "unknown error in parse_pack_header"; + + case 0: + return NULL; + } } static const char *pack_lockfile; diff --git a/sha1_file.c b/sha1_file.c index 43ff402..498665e 100644 --- a/sha1_file.c +++ b/sha1_file.c @@ -2048,3 +2048,24 @@ int index_path(unsigned char *sha1, const char *path, struct stat *st, int write } return 0; } + +int read_pack_header(int fd, struct pack_header *header) +{ + char *c = (char*)header; + ssize_t remaining = sizeof(struct pack_header); + do { + ssize_t r = xread(fd, c, remaining); + if (r <= 0) + /* "eof before pack header was fully read" */ + return PH_ERROR_EOF; + remaining -= r; + c += r; + } while (remaining > 0); + if (header->hdr_signature != htonl(PACK_SIGNATURE)) + /* "protocol error (pack signature mismatch detected)" */ + return PH_ERROR_PACK_SIGNATURE; + if (!pack_version_ok(header->hdr_version)) + /* "protocol error (pack version unsupported)" */ + return PH_ERROR_PROTOCOL; + return 0; +} -- 1.5.0.rc2.gc9a89 ^ permalink raw reply related [flat|nested] 75+ messages in thread
* [PATCH 2/2] Allow fetch-pack to decide keeping the fetched pack without exploding 2007-01-21 21:55 ` Johannes Schindelin ` (3 preceding siblings ...) 2007-01-23 6:47 ` [PATCH 1/2] Refactor the pack header reading function out of receive-pack.c Junio C Hamano @ 2007-01-23 6:47 ` Junio C Hamano 2007-01-23 10:32 ` Johannes Schindelin 4 siblings, 1 reply; 75+ messages in thread From: Junio C Hamano @ 2007-01-23 6:47 UTC (permalink / raw) To: Johannes Schindelin; +Cc: git With --keep-auto option, fetch-pack decides to keep the pack without exploding it just like receive-pack does. We may want to later make this the default. Signed-off-by: Junio C Hamano <junkio@cox.net> --- And this is the second half. It looks larger than it really is, because it involves some code movements; it removes two separate functions that called get_pack() and moves what they did to get_pack() after setup_sideband() happens. Although I did test it with --keep-auto with large and small packs once each. I haven't tested this at all with the git-fetch script. fetch-pack.c | 91 +++++++++++++++++++++++++++++++++++++-------------------- 1 files changed, 59 insertions(+), 32 deletions(-) diff --git a/fetch-pack.c b/fetch-pack.c index 726140a..4ee041c 100644 --- a/fetch-pack.c +++ b/fetch-pack.c @@ -4,9 +4,11 @@ #include "commit.h" #include "tag.h" #include "exec_cmd.h" +#include "pack.h" #include "sideband.h" static int keep_pack; +static int keep_auto; static int quiet; static int verbose; static int fetch_all; @@ -486,13 +488,58 @@ static pid_t setup_sideband(int fd[2], int xd[2]) return side_pid; } -static int get_pack(int xd[2], const char **argv) +static int get_pack(int xd[2]) { int status; pid_t pid, side_pid; int fd[2]; + const char *argv[20]; + char keep_arg[256]; + char hdr_arg[256]; + const char **av; + int do_keep = keep_pack; side_pid = setup_sideband(fd, xd); + + av = argv; + *hdr_arg = 0; + if (keep_auto) { + struct pack_header header; + + if (read_pack_header(fd[0], &header)) + die("protocol error: bad pack header"); + snprintf(hdr_arg, sizeof(hdr_arg), "--pack_header=%u,%u", + ntohl(header.hdr_version), ntohl(header.hdr_entries)); + if (ntohl(header.hdr_entries) < keep_auto) + do_keep = 0; + else + do_keep = 1; + } + + if (do_keep) { + *av++ = "index-pack"; + *av++ = "--stdin"; + if (!quiet) + *av++ = "-v"; + if (use_thin_pack) + *av++ = "--fix-thin"; + if (keep_pack > 1 || keep_auto) { + int s = sprintf(keep_arg, + "--keep=fetch-pack %d on ", getpid()); + if (gethostname(keep_arg + s, sizeof(keep_arg) - s)) + strcpy(keep_arg + s, "localhost"); + *av++ = keep_arg; + } + } + else { + *av++ = "unpack-objects"; + if (quiet) + *av++ = "-q"; + } + if (*hdr_arg) + *av++ = hdr_arg; + *av++ = NULL; + pid = fork(); if (pid < 0) die("fetch-pack: unable to fork off %s", argv[0]); @@ -522,39 +569,10 @@ static int get_pack(int xd[2], const char **argv) die("%s died of unnatural causes %d", argv[0], status); } -static int explode_rx_pack(int xd[2]) -{ - const char *argv[3] = { "unpack-objects", quiet ? "-q" : NULL, NULL }; - return get_pack(xd, argv); -} - -static int keep_rx_pack(int xd[2]) -{ - const char *argv[6]; - char keep_arg[256]; - int n = 0; - - argv[n++] = "index-pack"; - argv[n++] = "--stdin"; - if (!quiet) - argv[n++] = "-v"; - if (use_thin_pack) - argv[n++] = "--fix-thin"; - if (keep_pack > 1) { - int s = sprintf(keep_arg, "--keep=fetch-pack %i on ", getpid()); - if (gethostname(keep_arg + s, sizeof(keep_arg) - s)) - strcpy(keep_arg + s, "localhost"); - argv[n++] = keep_arg; - } - argv[n] = NULL; - return get_pack(xd, argv); -} - static int fetch_pack(int fd[2], int nr_match, char **match) { struct ref *ref; unsigned char sha1[20]; - int status; get_remote_heads(fd[0], &ref, 0, NULL, 0); if (is_repository_shallow() && !server_supports("shallow")) @@ -589,8 +607,7 @@ static int fetch_pack(int fd[2], int nr_match, char **match) */ fprintf(stderr, "warning: no common commits\n"); - status = (keep_pack) ? keep_rx_pack(fd) : explode_rx_pack(fd); - if (status) + if (get_pack(fd)) die("git-fetch-pack: fetch failed."); all_done: @@ -655,6 +672,16 @@ int main(int argc, char **argv) keep_pack++; continue; } + if (!strcmp("--keep-auto", arg)) { + keep_auto = 100; + continue; + } + if (!strncmp("--keep-auto=", arg, 12)) { + keep_auto = strtoul(arg + 12, NULL, 0); + if (keep_auto < 20) + keep_auto = 20; + continue; + } if (!strcmp("--thin", arg)) { use_thin_pack = 1; continue; -- 1.5.0.rc2.gc9a89 ^ permalink raw reply related [flat|nested] 75+ messages in thread
* Re: [PATCH 2/2] Allow fetch-pack to decide keeping the fetched pack without exploding 2007-01-23 6:47 ` [PATCH 2/2] Allow fetch-pack to decide keeping the fetched pack without exploding Junio C Hamano @ 2007-01-23 10:32 ` Johannes Schindelin 2007-01-23 10:55 ` Jakub Narebski ` (2 more replies) 0 siblings, 3 replies; 75+ messages in thread From: Johannes Schindelin @ 2007-01-23 10:32 UTC (permalink / raw) To: Junio C Hamano; +Cc: git Hi, On Mon, 22 Jan 2007, Junio C Hamano wrote: > With --keep-auto option, fetch-pack decides to keep the pack without > exploding it just like receive-pack does. I like both patches. (Did not have time to test yet, but from looking at the patches, it seems indeed to be mostly code moves.) > We may want to later make this the default. You have my vote for sooner rather than later. Ciao, Dscho P.S.: These patches make me dream of yet another diff format enhancement: code moves! Of course, for this to be really usable, you'd also have to automatically determine indent changes... You may say I'm a dreamer. But I'm not the only one... ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH 2/2] Allow fetch-pack to decide keeping the fetched pack without exploding 2007-01-23 10:32 ` Johannes Schindelin @ 2007-01-23 10:55 ` Jakub Narebski 2007-01-23 11:07 ` code movements in diffs, was " Johannes Schindelin 2007-01-23 16:01 ` Nicolas Pitre 2007-01-23 16:15 ` [PATCH 2/2] Allow fetch-pack to decide keeping the fetched pack without exploding Linus Torvalds 2 siblings, 1 reply; 75+ messages in thread From: Jakub Narebski @ 2007-01-23 10:55 UTC (permalink / raw) To: git Johannes Schindelin wrote: > P.S.: These patches make me dream of yet another diff format enhancement: > code moves! Of course, for this to be really usable, you'd also have to > automatically determine indent changes... You may say I'm a dreamer. But > I'm not the only one... I wonder if it could be done with e.g. --- a/fromfile +++ b/somefile <code movement or copying> --- a/somefile +++ b/somefile <other changes> The problem is that context differs usually for code movement. -- Jakub Narebski Warsaw, Poland ShadeHawk on #git ^ permalink raw reply [flat|nested] 75+ messages in thread
* code movements in diffs, was Re: [PATCH 2/2] Allow fetch-pack to decide keeping the fetched pack without exploding 2007-01-23 10:55 ` Jakub Narebski @ 2007-01-23 11:07 ` Johannes Schindelin 0 siblings, 0 replies; 75+ messages in thread From: Johannes Schindelin @ 2007-01-23 11:07 UTC (permalink / raw) To: Jakub Narebski; +Cc: git Hi, On Tue, 23 Jan 2007, Jakub Narebski wrote: > Johannes Schindelin wrote: > > > P.S.: These patches make me dream of yet another diff format enhancement: > > code moves! Of course, for this to be really usable, you'd also have to > > automatically determine indent changes... You may say I'm a dreamer. But > > I'm not the only one... > > I wonder if it could be done with e.g. > > --- a/fromfile > +++ b/somefile > <code movement or copying> > > --- a/somefile > +++ b/somefile > <other changes> > > The problem is that context differs usually for code movement. There is a more fundamental problem here: both "diff" and "patch" walk the file pair in a direction. The whole "code movement" stuff would break this paradigm. What you found is just _one_ consequence. But as I said: a man can still dream, can't he? Ciao, Dscho ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH 2/2] Allow fetch-pack to decide keeping the fetched pack without exploding 2007-01-23 10:32 ` Johannes Schindelin 2007-01-23 10:55 ` Jakub Narebski @ 2007-01-23 16:01 ` Nicolas Pitre 2007-01-25 1:14 ` [PATCH] fetch-pack: remove --keep-auto and make it the default Junio C Hamano 2007-01-25 1:14 ` [PATCH] Consolidate {receive,fetch}.unpackLimit Junio C Hamano 2007-01-23 16:15 ` [PATCH 2/2] Allow fetch-pack to decide keeping the fetched pack without exploding Linus Torvalds 2 siblings, 2 replies; 75+ messages in thread From: Nicolas Pitre @ 2007-01-23 16:01 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Junio C Hamano, git On Tue, 23 Jan 2007, Johannes Schindelin wrote: > On Mon, 22 Jan 2007, Junio C Hamano wrote: > > > We may want to later make this the default. > > You have my vote for sooner rather than later. Seconded. Nicolas ^ permalink raw reply [flat|nested] 75+ messages in thread
* [PATCH] fetch-pack: remove --keep-auto and make it the default. 2007-01-23 16:01 ` Nicolas Pitre @ 2007-01-25 1:14 ` Junio C Hamano 2007-01-25 8:23 ` Johannes Schindelin 2007-01-25 1:14 ` [PATCH] Consolidate {receive,fetch}.unpackLimit Junio C Hamano 1 sibling, 1 reply; 75+ messages in thread From: Junio C Hamano @ 2007-01-25 1:14 UTC (permalink / raw) To: Nicolas Pitre; +Cc: git, Johannes Schindelin This makes git-fetch over git native protocol to automatically decide to keep the downloaded pack if the fetch results in more than 100 objects, just like receive-pack invoked by git-push does. This logic is disabled when --keep is explicitly given from the command line, so that a very small clone still keeps the downloaded pack as before. The 100 threshold can be adjusted with fetch.unpacklimit configuration. We might want to introduce transfer.unpacklimit to consolidate the two unpacklimit variables, which will be a topic for the next patch. Signed-off-by: Junio C Hamano <junkio@cox.net> --- Nicolas Pitre <nico@cam.org> writes: > On Tue, 23 Jan 2007, Johannes Schindelin wrote: > >> On Mon, 22 Jan 2007, Junio C Hamano wrote: >> >> > We may want to later make this the default. >> >> You have my vote for sooner rather than later. > > Seconded. > > Nicolas Ok, how about this, on top of the previous ones? Documentation/config.txt | 10 ++++++++++ fetch-pack.c | 31 +++++++++++++++++-------------- t/t5500-fetch-pack.sh | 3 ++- 3 files changed, 29 insertions(+), 15 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index d8244b1..383ff29 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -295,6 +295,16 @@ diff.renames:: will enable basic rename detection. If set to "copies" or "copy", it will detect copies, as well. +fetch.unpackLimit:: + If the number of objects fetched over the git native + transfer is below this + limit, then the objects will be unpacked into loose object + files. However if the number of received objects equals or + exceeds this limit then the received pack will be stored as + a pack, after adding any missing delta bases. Storing the + pack from a push can make the push operation complete faster, + especially on slow filesystems. + format.headers:: Additional email headers to include in a patch to be submitted by mail. See gitlink:git-format-patch[1]. diff --git a/fetch-pack.c b/fetch-pack.c index dd67e48..fc0534c 100644 --- a/fetch-pack.c +++ b/fetch-pack.c @@ -8,7 +8,7 @@ #include "sideband.h" static int keep_pack; -static int keep_auto; +static int unpack_limit = 100; static int quiet; static int verbose; static int fetch_all; @@ -503,14 +503,14 @@ static int get_pack(int xd[2]) av = argv; *hdr_arg = 0; - if (keep_auto) { + if (unpack_limit) { struct pack_header header; if (read_pack_header(fd[0], &header)) die("protocol error: bad pack header"); snprintf(hdr_arg, sizeof(hdr_arg), "--pack_header=%u,%u", ntohl(header.hdr_version), ntohl(header.hdr_entries)); - if (ntohl(header.hdr_entries) < keep_auto) + if (ntohl(header.hdr_entries) < unpack_limit) do_keep = 0; else do_keep = 1; @@ -523,7 +523,7 @@ static int get_pack(int xd[2]) *av++ = "-v"; if (use_thin_pack) *av++ = "--fix-thin"; - if (keep_pack > 1 || keep_auto) { + if (keep_pack > 1 || unpack_limit) { int s = sprintf(keep_arg, "--keep=fetch-pack %d on ", getpid()); if (gethostname(keep_arg + s, sizeof(keep_arg) - s)) @@ -642,6 +642,16 @@ static int remove_duplicates(int nr_heads, char **heads) return dst; } +static int fetch_pack_config(const char *var, const char *value) +{ + if (strcmp(var, "fetch.unpacklimit") == 0) { + unpack_limit = git_config_int(var, value); + return 0; + } + + return git_default_config(var, value); +} + static struct lock_file lock; int main(int argc, char **argv) @@ -653,6 +663,8 @@ int main(int argc, char **argv) struct stat st; setup_git_directory(); + setup_ident(); + git_config(fetch_pack_config); nr_heads = 0; heads = NULL; @@ -674,16 +686,7 @@ int main(int argc, char **argv) } if (!strcmp("--keep", arg) || !strcmp("-k", arg)) { keep_pack++; - continue; - } - if (!strcmp("--keep-auto", arg)) { - keep_auto = 100; - continue; - } - if (!strncmp("--keep-auto=", arg, 12)) { - keep_auto = strtoul(arg + 12, NULL, 0); - if (keep_auto < 20) - keep_auto = 20; + unpack_limit = 0; continue; } if (!strcmp("--thin", arg)) { diff --git a/t/t5500-fetch-pack.sh b/t/t5500-fetch-pack.sh index ef78df6..7fd651b 100755 --- a/t/t5500-fetch-pack.sh +++ b/t/t5500-fetch-pack.sh @@ -97,7 +97,8 @@ pull_to_client () { ( mkdir client && cd client && - git-init 2>> log2.txt + git-init 2>> log2.txt && + git repo-config fetch.unpacklimit 0 ) add A1 ^ permalink raw reply related [flat|nested] 75+ messages in thread
* Re: [PATCH] fetch-pack: remove --keep-auto and make it the default. 2007-01-25 1:14 ` [PATCH] fetch-pack: remove --keep-auto and make it the default Junio C Hamano @ 2007-01-25 8:23 ` Johannes Schindelin 2007-01-25 21:32 ` Junio C Hamano 0 siblings, 1 reply; 75+ messages in thread From: Johannes Schindelin @ 2007-01-25 8:23 UTC (permalink / raw) To: Junio C Hamano; +Cc: Nicolas Pitre, git Hi, On Wed, 24 Jan 2007, Junio C Hamano wrote: > Ok, how about this, on top of the previous ones? Thanks! > @@ -653,6 +663,8 @@ int main(int argc, char **argv) > struct stat st; > > setup_git_directory(); > + setup_ident(); > + git_config(fetch_pack_config); Why do you need setup_ident()? Ciao, Dscho ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH] fetch-pack: remove --keep-auto and make it the default. 2007-01-25 8:23 ` Johannes Schindelin @ 2007-01-25 21:32 ` Junio C Hamano 2007-01-25 23:46 ` Johannes Schindelin ` (2 more replies) 0 siblings, 3 replies; 75+ messages in thread From: Junio C Hamano @ 2007-01-25 21:32 UTC (permalink / raw) To: Johannes Schindelin; +Cc: git Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > On Wed, 24 Jan 2007, Junio C Hamano wrote: > >> Ok, how about this, on top of the previous ones? > > Thanks! > >> @@ -653,6 +663,8 @@ int main(int argc, char **argv) >> struct stat st; >> >> setup_git_directory(); >> + setup_ident(); >> + git_config(fetch_pack_config); > > Why do you need setup_ident()? Because presumably you would be updating the reflog that records who did the fetch? But then we should do the same ignore_missing_committer_name() we have in receive-pack to allow anonymous fetchers to fetch from outside world, I guess. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH] fetch-pack: remove --keep-auto and make it the default. 2007-01-25 21:32 ` Junio C Hamano @ 2007-01-25 23:46 ` Johannes Schindelin 2007-01-26 3:05 ` Junio C Hamano 2007-01-26 8:37 ` [PATCH] fetch-pack: remove --keep-auto and make it the default Johannes Sixt 2 siblings, 0 replies; 75+ messages in thread From: Johannes Schindelin @ 2007-01-25 23:46 UTC (permalink / raw) To: Junio C Hamano; +Cc: git Hi, On Thu, 25 Jan 2007, Junio C Hamano wrote: > > Why do you need setup_ident()? > > Because presumably you would be updating the reflog that records > who did the fetch? Ah yes, that makes sense! Thank you, Dscho ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH] fetch-pack: remove --keep-auto and make it the default. 2007-01-25 21:32 ` Junio C Hamano 2007-01-25 23:46 ` Johannes Schindelin @ 2007-01-26 3:05 ` Junio C Hamano 2007-01-26 3:30 ` [PATCH] Allow non-developer to clone, checkout and fetch easier Junio C Hamano 2007-01-26 8:37 ` [PATCH] fetch-pack: remove --keep-auto and make it the default Johannes Sixt 2 siblings, 1 reply; 75+ messages in thread From: Junio C Hamano @ 2007-01-26 3:05 UTC (permalink / raw) To: Johannes Schindelin; +Cc: git, Shawn O. Pearce Junio C Hamano <junkio@cox.net> writes: > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > >> On Wed, 24 Jan 2007, Junio C Hamano wrote: >> >>> Ok, how about this, on top of the previous ones? >> >> Thanks! >> >>> @@ -653,6 +663,8 @@ int main(int argc, char **argv) >>> struct stat st; >>> >>> setup_git_directory(); >>> + setup_ident(); >>> + git_config(fetch_pack_config); >> >> Why do you need setup_ident()? > > Because presumably you would be updating the reflog that records > who did the fetch? > > But then we should do the same ignore_missing_committer_name() > we have in receive-pack to allow anonymous fetchers to fetch > from outside world, I guess. This turns out to be more serious than I expected. The code that uses committer_info() in reflog can barf and die. And I do not think calling ignore_missing_committer_name() upfront like recent receive-pack did in the aplication is a reasonable workaround. So I am thinking about doing something like the attached patch. What the patch does. - git_committer_info() takes one parameter. It used to be "if this is true, then die() if the name is not available due to bad GECOS, otherwise issue a warning once but leave the name empty". The reason was because we wanted to prevent bad commits from being made by git-commit-tree (and its callers). The value 0 is only used by "git var -l". Now it takes -1, 0 or 1. When set to -1, it does not complain but uses the pw->pw_name when name is not available. Existing 0 and 1 values mean the same thing as they used to mean before. 0 means issue warnings and leave it empty, 1 means barf and die. - ignore_missing_committer_name() and its existing caller (receive-pack, to set the reflog) have been removed. - git-format-patch, to come up with the phoney message ID when asked to thread, now passes -1 to git_committer_info(). This codepath uses only the e-mail part, ignoring the name. It used to barf and die. The other call in the same program when asked to add signed-off-by line based on committer identity still passes 1 to make sure it barfs instead of adding a bogus s-o-b line. - log_ref_write in refs.c, to come up with the name to record who initiated the ref update in the reflog, passes -1. It used to barf and die. The last change means that git-update-ref, git-branch, and commit walker backends can now be used in a repository with reflog by somebody who does not have the user identity required to make a commit. They all used to barf and die. I've run tests and all of them seem to pass, and also tried "git clone" as a user whose GECOS is empty -- git clone works again now (it was broken when reflog was enabled by default). But this definitely needs extra sets of eyeballs. --- diff --git a/builtin-log.c b/builtin-log.c index 503cd1e..56acc13 100644 --- a/builtin-log.c +++ b/builtin-log.c @@ -352,7 +352,7 @@ static void get_patch_ids(struct rev_info *rev, struct diff_options *options, co static void gen_message_id(char *dest, unsigned int length, char *base) { - const char *committer = git_committer_info(1); + const char *committer = git_committer_info(-1); const char *email_start = strrchr(committer, '<'); const char *email_end = strrchr(committer, '>'); if(!email_start || !email_end || email_start > email_end - 1) diff --git a/cache.h b/cache.h index 473197d..9486132 100644 --- a/cache.h +++ b/cache.h @@ -320,7 +320,6 @@ void datestamp(char *buf, int bufsize); unsigned long approxidate(const char *); extern int setup_ident(void); -extern void ignore_missing_committer_name(void); extern const char *git_author_info(int); extern const char *git_committer_info(int); diff --git a/fetch-pack.c b/fetch-pack.c index 4df7450..83a1d7b 100644 --- a/fetch-pack.c +++ b/fetch-pack.c @@ -671,8 +671,6 @@ int main(int argc, char **argv) setup_git_directory(); setup_ident(); - /* don't die if gecos is empty */ - ignore_missing_committer_name(); git_config(fetch_pack_config); if (0 <= transfer_unpack_limit) diff --git a/ident.c b/ident.c index 6ad8fed..f967790 100644 --- a/ident.c +++ b/ident.c @@ -180,12 +180,21 @@ static const char *get_ident(const char *name, const char *email, email = git_default_email; if (!*name) { - if (name == git_default_name && env_hint) { + struct passwd *pw; + + if (0 <= error_on_no_name && + name == git_default_name && env_hint) { fprintf(stderr, env_hint, au_env, co_env); env_hint = NULL; /* warn only once, for "git-var -l" */ } - if (error_on_no_name) + if (0 < error_on_no_name) die("empty ident %s <%s> not allowed", name, email); + pw = getpwuid(getuid()); + if (!pw) + die("You don't exist. Go away!"); + strlcpy(git_default_name, pw->pw_name, + sizeof(git_default_name)); + name = git_default_name; } strcpy(date, git_default_date); @@ -218,18 +227,3 @@ const char *git_committer_info(int error_on_no_name) getenv("GIT_COMMITTER_DATE"), error_on_no_name); } - -void ignore_missing_committer_name() -{ - /* If we did not get a name from the user's gecos entry then - * git_default_name is empty; so instead load the username - * into it as a 'good enough for now' approximation of who - * this user is. - */ - if (!*git_default_name) { - struct passwd *pw = getpwuid(getuid()); - if (!pw) - die("You don't exist. Go away!"); - strlcpy(git_default_name, pw->pw_name, sizeof(git_default_name)); - } -} diff --git a/receive-pack.c b/receive-pack.c index 8b59b32..7d26326 100644 --- a/receive-pack.c +++ b/receive-pack.c @@ -430,8 +430,6 @@ int main(int argc, char **argv) die("attempt to push into a shallow repository"); setup_ident(); - /* don't die if gecos is empty */ - ignore_missing_committer_name(); git_config(receive_pack_config); if (0 <= transfer_unpack_limit) diff --git a/refs.c b/refs.c index 8117328..4323e9a 100644 --- a/refs.c +++ b/refs.c @@ -958,7 +958,7 @@ static int log_ref_write(struct ref_lock *lock, lock->log_file, strerror(errno)); } - committer = git_committer_info(1); + committer = git_committer_info(-1); if (msg) { maxlen = strlen(committer) + strlen(msg) + 2*40 + 5; logrec = xmalloc(maxlen); ^ permalink raw reply related [flat|nested] 75+ messages in thread
* [PATCH] Allow non-developer to clone, checkout and fetch easier. 2007-01-26 3:05 ` Junio C Hamano @ 2007-01-26 3:30 ` Junio C Hamano 2007-01-26 14:20 ` Alex Riesen 0 siblings, 1 reply; 75+ messages in thread From: Junio C Hamano @ 2007-01-26 3:30 UTC (permalink / raw) To: git The code that uses committer_info() in reflog can barf and die whenever it is asked to update a ref. And I do not think calling ignore_missing_committer_name() upfront like recent receive-pack did in the aplication is a reasonable workaround. What the patch does. - git_committer_info() takes one parameter. It used to be "if this is true, then die() if the name is not available due to bad GECOS, otherwise issue a warning once but leave the name empty". The reason was because we wanted to prevent bad commits from being made by git-commit-tree (and its callers). The value 0 is only used by "git var -l". Now it takes -1, 0 or 1. When set to -1, it does not complain but uses the pw->pw_name when name is not available. Existing 0 and 1 values mean the same thing as they used to mean before. 0 means issue warnings and leave it empty, 1 means barf and die. - ignore_missing_committer_name() and its existing caller (receive-pack, to set the reflog) have been removed. - git-format-patch, to come up with the phoney message ID when asked to thread, now passes -1 to git_committer_info(). This codepath uses only the e-mail part, ignoring the name. It used to barf and die. The other call in the same program when asked to add signed-off-by line based on committer identity still passes 1 to make sure it barfs instead of adding a bogus s-o-b line. - log_ref_write in refs.c, to come up with the name to record who initiated the ref update in the reflog, passes -1. It used to barf and die. The last change means that git-update-ref, git-branch, and commit walker backends can now be used in a repository with reflog by somebody who does not have the user identity required to make a commit. They all used to barf and die. I've run tests and all of them seem to pass, and also tried "git clone" as a user whose GECOS is empty -- git clone works again now (it was broken when reflog was enabled by default). But this definitely needs extra sets of eyeballs. Signed-off-by: Junio C Hamano <junkio@cox.net> --- * Here is an updated patch -- the previous one was on top of what was never committed, and was useless. builtin-log.c | 2 +- cache.h | 1 - ident.c | 28 +++++++++++----------------- receive-pack.c | 2 -- refs.c | 2 +- 5 files changed, 13 insertions(+), 22 deletions(-) diff --git a/builtin-log.c b/builtin-log.c index 503cd1e..56acc13 100644 --- a/builtin-log.c +++ b/builtin-log.c @@ -352,7 +352,7 @@ static void get_patch_ids(struct rev_info *rev, struct diff_options *options, co static void gen_message_id(char *dest, unsigned int length, char *base) { - const char *committer = git_committer_info(1); + const char *committer = git_committer_info(-1); const char *email_start = strrchr(committer, '<'); const char *email_end = strrchr(committer, '>'); if(!email_start || !email_end || email_start > email_end - 1) diff --git a/cache.h b/cache.h index 473197d..9486132 100644 --- a/cache.h +++ b/cache.h @@ -320,7 +320,6 @@ void datestamp(char *buf, int bufsize); unsigned long approxidate(const char *); extern int setup_ident(void); -extern void ignore_missing_committer_name(void); extern const char *git_author_info(int); extern const char *git_committer_info(int); diff --git a/ident.c b/ident.c index 6ad8fed..f967790 100644 --- a/ident.c +++ b/ident.c @@ -180,12 +180,21 @@ static const char *get_ident(const char *name, const char *email, email = git_default_email; if (!*name) { - if (name == git_default_name && env_hint) { + struct passwd *pw; + + if (0 <= error_on_no_name && + name == git_default_name && env_hint) { fprintf(stderr, env_hint, au_env, co_env); env_hint = NULL; /* warn only once, for "git-var -l" */ } - if (error_on_no_name) + if (0 < error_on_no_name) die("empty ident %s <%s> not allowed", name, email); + pw = getpwuid(getuid()); + if (!pw) + die("You don't exist. Go away!"); + strlcpy(git_default_name, pw->pw_name, + sizeof(git_default_name)); + name = git_default_name; } strcpy(date, git_default_date); @@ -218,18 +227,3 @@ const char *git_committer_info(int error_on_no_name) getenv("GIT_COMMITTER_DATE"), error_on_no_name); } - -void ignore_missing_committer_name() -{ - /* If we did not get a name from the user's gecos entry then - * git_default_name is empty; so instead load the username - * into it as a 'good enough for now' approximation of who - * this user is. - */ - if (!*git_default_name) { - struct passwd *pw = getpwuid(getuid()); - if (!pw) - die("You don't exist. Go away!"); - strlcpy(git_default_name, pw->pw_name, sizeof(git_default_name)); - } -} diff --git a/receive-pack.c b/receive-pack.c index 8b59b32..7d26326 100644 --- a/receive-pack.c +++ b/receive-pack.c @@ -430,8 +430,6 @@ int main(int argc, char **argv) die("attempt to push into a shallow repository"); setup_ident(); - /* don't die if gecos is empty */ - ignore_missing_committer_name(); git_config(receive_pack_config); if (0 <= transfer_unpack_limit) diff --git a/refs.c b/refs.c index 8117328..4323e9a 100644 --- a/refs.c +++ b/refs.c @@ -958,7 +958,7 @@ static int log_ref_write(struct ref_lock *lock, lock->log_file, strerror(errno)); } - committer = git_committer_info(1); + committer = git_committer_info(-1); if (msg) { maxlen = strlen(committer) + strlen(msg) + 2*40 + 5; logrec = xmalloc(maxlen); -- 1.5.0.rc2.g1b55 ^ permalink raw reply related [flat|nested] 75+ messages in thread
* Re: [PATCH] Allow non-developer to clone, checkout and fetch easier. 2007-01-26 3:30 ` [PATCH] Allow non-developer to clone, checkout and fetch easier Junio C Hamano @ 2007-01-26 14:20 ` Alex Riesen 0 siblings, 0 replies; 75+ messages in thread From: Alex Riesen @ 2007-01-26 14:20 UTC (permalink / raw) To: Junio C Hamano; +Cc: git On 1/26/07, Junio C Hamano <junkio@cox.net> wrote: > The code that uses committer_info() in reflog can barf and die > whenever it is asked to update a ref. And I do not think > calling ignore_missing_committer_name() upfront like recent > receive-pack did in the aplication is a reasonable workaround. > > What the patch does. > > - git_committer_info() takes one parameter. It used to be "if > this is true, then die() if the name is not available due to > bad GECOS, otherwise issue a warning once but leave the name > empty". The reason was because we wanted to prevent bad > commits from being made by git-commit-tree (and its > callers). The value 0 is only used by "git var -l". > > Now it takes -1, 0 or 1. When set to -1, it does not > complain but uses the pw->pw_name when name is not > available. Existing 0 and 1 values mean the same thing as > they used to mean before. 0 means issue warnings and leave > it empty, 1 means barf and die. enum { CMITR_INFO_PW_NAME = -1, CMITR_INFO_EMPTY = 0, CMITR_INFO_DIE = 1, }; - const char *committer = git_committer_info(CMITR_INFO_DIE); + const char *committer = git_committer_info(CMITR_INFO_PW_NAME); The code becoming increasingly harder to read, doesn't it... ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH] fetch-pack: remove --keep-auto and make it the default. 2007-01-25 21:32 ` Junio C Hamano 2007-01-25 23:46 ` Johannes Schindelin 2007-01-26 3:05 ` Junio C Hamano @ 2007-01-26 8:37 ` Johannes Sixt 2 siblings, 0 replies; 75+ messages in thread From: Johannes Sixt @ 2007-01-26 8:37 UTC (permalink / raw) To: git Junio C Hamano wrote: > > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > > > On Wed, 24 Jan 2007, Junio C Hamano wrote: > > > >> Ok, how about this, on top of the previous ones? > > > > Thanks! > > > >> @@ -653,6 +663,8 @@ int main(int argc, char **argv) > >> struct stat st; > >> > >> setup_git_directory(); > >> + setup_ident(); > >> + git_config(fetch_pack_config); > > > > Why do you need setup_ident()? > > Because presumably you would be updating the reflog that records > who did the fetch? > > But then we should do the same ignore_missing_committer_name() > we have in receive-pack to allow anonymous fetchers to fetch > from outside world, I guess. Instead of using ignore_missing_committer_name(), use get_committer_info(0) in refs.c. cherry-pick 4feaf032d3 from my tree at git://repo.or.cz/git/mingw.git if you want. Although this approach leaves the name+email in the reflog entry empty instead of writing "unkown"... -- Hannes ^ permalink raw reply [flat|nested] 75+ messages in thread
* [PATCH] Consolidate {receive,fetch}.unpackLimit 2007-01-23 16:01 ` Nicolas Pitre 2007-01-25 1:14 ` [PATCH] fetch-pack: remove --keep-auto and make it the default Junio C Hamano @ 2007-01-25 1:14 ` Junio C Hamano 2007-01-25 3:32 ` Nicolas Pitre 2007-01-25 5:14 ` Shawn O. Pearce 1 sibling, 2 replies; 75+ messages in thread From: Junio C Hamano @ 2007-01-25 1:14 UTC (permalink / raw) To: Nicolas Pitre; +Cc: git, Johannes Schindelin This allows transfer.unpackLimit to specify what these two configuration variables want to set. We would probably want to deprecate the two separate variables, as I do not see much point in specifying them independently. Signed-off-by: Junio C Hamano <junkio@cox.net> --- Documentation/config.txt | 5 +++++ fetch-pack.c | 14 +++++++++++++- receive-pack.c | 24 ++++++++++++++++-------- t/t5500-fetch-pack.sh | 2 +- 4 files changed, 35 insertions(+), 10 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index 383ff29..8086d75 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -488,3 +488,8 @@ receive.denyNonFastForwards:: even if that push is forced. This configuration variable is set when initializing a shared repository. +transfer.unpackLimit:: + When `fetch.unpackLimit` or `receive.unpackLimit` are + not set, the value of this variable is used instead. + + diff --git a/fetch-pack.c b/fetch-pack.c index fc0534c..83a1d7b 100644 --- a/fetch-pack.c +++ b/fetch-pack.c @@ -8,6 +8,8 @@ #include "sideband.h" static int keep_pack; +static int transfer_unpack_limit = -1; +static int fetch_unpack_limit = -1; static int unpack_limit = 100; static int quiet; static int verbose; @@ -645,7 +647,12 @@ static int remove_duplicates(int nr_heads, char **heads) static int fetch_pack_config(const char *var, const char *value) { if (strcmp(var, "fetch.unpacklimit") == 0) { - unpack_limit = git_config_int(var, value); + fetch_unpack_limit = git_config_int(var, value); + return 0; + } + + if (strcmp(var, "transfer.unpacklimit") == 0) { + transfer_unpack_limit = git_config_int(var, value); return 0; } @@ -666,6 +673,11 @@ int main(int argc, char **argv) setup_ident(); git_config(fetch_pack_config); + if (0 <= transfer_unpack_limit) + unpack_limit = transfer_unpack_limit; + else if (0 <= fetch_unpack_limit) + unpack_limit = fetch_unpack_limit; + nr_heads = 0; heads = NULL; for (i = 1; i < argc; i++) { diff --git a/receive-pack.c b/receive-pack.c index b3a4552..8b59b32 100644 --- a/receive-pack.c +++ b/receive-pack.c @@ -10,6 +10,8 @@ static const char receive_pack_usage[] = "git-receive-pack <git-dir>"; static int deny_non_fast_forwards = 0; +static int receive_unpack_limit = -1; +static int transfer_unpack_limit = -1; static int unpack_limit = 100; static int report_status; @@ -18,21 +20,22 @@ static int capabilities_sent; static int receive_pack_config(const char *var, const char *value) { - git_default_config(var, value); - - if (strcmp(var, "receive.denynonfastforwards") == 0) - { + if (strcmp(var, "receive.denynonfastforwards") == 0) { deny_non_fast_forwards = git_config_bool(var, value); return 0; } - if (strcmp(var, "receive.unpacklimit") == 0) - { - unpack_limit = git_config_int(var, value); + if (strcmp(var, "receive.unpacklimit") == 0) { + receive_unpack_limit = git_config_int(var, value); return 0; } - return 0; + if (strcmp(var, "transfer.unpacklimit") == 0) { + transfer_unpack_limit = git_config_int(var, value); + return 0; + } + + return git_default_config(var, value); } static int show_ref(const char *path, const unsigned char *sha1, int flag, void *cb_data) @@ -431,6 +434,11 @@ int main(int argc, char **argv) ignore_missing_committer_name(); git_config(receive_pack_config); + if (0 <= transfer_unpack_limit) + unpack_limit = transfer_unpack_limit; + else if (0 <= receive_unpack_limit) + unpack_limit = receive_unpack_limit; + write_head_info(); /* EOF */ diff --git a/t/t5500-fetch-pack.sh b/t/t5500-fetch-pack.sh index 7fd651b..058cce0 100755 --- a/t/t5500-fetch-pack.sh +++ b/t/t5500-fetch-pack.sh @@ -98,7 +98,7 @@ pull_to_client () { mkdir client && cd client && git-init 2>> log2.txt && - git repo-config fetch.unpacklimit 0 + git repo-config transfer.unpacklimit 0 ) add A1 -- 1.5.0.rc2.gae1d ^ permalink raw reply related [flat|nested] 75+ messages in thread
* Re: [PATCH] Consolidate {receive,fetch}.unpackLimit 2007-01-25 1:14 ` [PATCH] Consolidate {receive,fetch}.unpackLimit Junio C Hamano @ 2007-01-25 3:32 ` Nicolas Pitre 2007-01-25 5:14 ` Shawn O. Pearce 1 sibling, 0 replies; 75+ messages in thread From: Nicolas Pitre @ 2007-01-25 3:32 UTC (permalink / raw) To: Junio C Hamano; +Cc: git, Johannes Schindelin On Wed, 24 Jan 2007, Junio C Hamano wrote: > This allows transfer.unpackLimit to specify what these two > configuration variables want to set. > > We would probably want to deprecate the two separate variables, > as I do not see much point in specifying them independently. Well... since they're already there and not hurting anything I would let them live. Never know how they might be useful. Nicolas ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH] Consolidate {receive,fetch}.unpackLimit 2007-01-25 1:14 ` [PATCH] Consolidate {receive,fetch}.unpackLimit Junio C Hamano 2007-01-25 3:32 ` Nicolas Pitre @ 2007-01-25 5:14 ` Shawn O. Pearce 1 sibling, 0 replies; 75+ messages in thread From: Shawn O. Pearce @ 2007-01-25 5:14 UTC (permalink / raw) To: Junio C Hamano; +Cc: Nicolas Pitre, git, Johannes Schindelin Junio C Hamano <junkio@cox.net> wrote: > This allows transfer.unpackLimit to specify what these two > configuration variables want to set. > > We would probably want to deprecate the two separate variables, > as I do not see much point in specifying them independently. Indeed. I was going to fix this too, but reuse receive.unpackLimit. From my point of view both fetch and receive-pack are recieving objects into this repository; and in either case I want the same behavior with regards to loose object/pack management. -- Shawn. ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH 2/2] Allow fetch-pack to decide keeping the fetched pack without exploding 2007-01-23 10:32 ` Johannes Schindelin 2007-01-23 10:55 ` Jakub Narebski 2007-01-23 16:01 ` Nicolas Pitre @ 2007-01-23 16:15 ` Linus Torvalds 2007-01-23 16:28 ` David Kågedal 2 siblings, 1 reply; 75+ messages in thread From: Linus Torvalds @ 2007-01-23 16:15 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Junio C Hamano, git On Tue, 23 Jan 2007, Johannes Schindelin wrote: > > P.S.: These patches make me dream of yet another diff format enhancement: > code moves! It's basically impossible. Why? You need the context. In a _context_less_ diff, it's fairly trivial to indicate code movement: you just say "move bytes x-y into z". However, if you want anything approaching readability and safety, you want context, and that automatically means that you need to have the stuff around the context, which in turn means that you can't sanely do that. Sure, you could do a diff that has the *context* repeated around the code that moves (and not actually quoting all the movement itself, except for the first and last three lines or something), but that would be really unreadable. A lot more unreadable than what we have now, with delete+add chunks. > Of course, for this to be really usable, you'd also have to > automatically determine indent changes... Indeed. Much code movement isn't just pure data movement, it's re-indentation too. Making the thing even less tractable. In other words - you can do it (and we _do_ do it) when you don't do diffs at all, but deltas. Our deltas actually do contain block movement. But diffs? Forget about it. > You may say I'm a dreamer. But I'm not the only one... I am the walrus. Linus ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH 2/2] Allow fetch-pack to decide keeping the fetched pack without exploding 2007-01-23 16:15 ` [PATCH 2/2] Allow fetch-pack to decide keeping the fetched pack without exploding Linus Torvalds @ 2007-01-23 16:28 ` David Kågedal 2007-01-23 16:43 ` Johannes Schindelin 0 siblings, 1 reply; 75+ messages in thread From: David Kågedal @ 2007-01-23 16:28 UTC (permalink / raw) To: git Linus Torvalds <torvalds@linux-foundation.org> writes: > On Tue, 23 Jan 2007, Johannes Schindelin wrote: >> >> P.S.: These patches make me dream of yet another diff format enhancement: >> code moves! > > It's basically impossible. > > Why? You need the context. Yes, I think that a diff format for code moves wouldn't be useful. What could potentially be useful is a graphical diff browser that can e.g. show two versions side-by-side and show code moves in that. I have a vague memory that the ClearCase merge tool did that. But as long as the code moves are within a single file, that merge tool could derive that move from an ordinary diff. -- David Kågedal ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH 2/2] Allow fetch-pack to decide keeping the fetched pack without exploding 2007-01-23 16:28 ` David Kågedal @ 2007-01-23 16:43 ` Johannes Schindelin 2007-01-23 17:22 ` Jakub Narebski 0 siblings, 1 reply; 75+ messages in thread From: Johannes Schindelin @ 2007-01-23 16:43 UTC (permalink / raw) To: David Kågedal; +Cc: git, Linus Torvalds [-- Attachment #1: Type: TEXT/PLAIN, Size: 1481 bytes --] Hi, [Re-Cc'ing Linus] On Tue, 23 Jan 2007, David Kågedal wrote: > Linus Torvalds <torvalds@linux-foundation.org> writes: > > > On Tue, 23 Jan 2007, Johannes Schindelin wrote: > >> > >> P.S.: These patches make me dream of yet another diff format enhancement: > >> code moves! > > > > It's basically impossible. > > > > Why? You need the context. > > Yes, I think that a diff format for code moves wouldn't be useful. > What could potentially be useful is a graphical diff browser that can > e.g. show two versions side-by-side and show code moves in that. I > have a vague memory that the ClearCase merge tool did that. I don't need no steenking graphical tools. I want to read me mailing list, that's it. > But as long as the code moves are within a single file, that merge tool > could derive that move from an ordinary diff. Actually, you could even derive a code movement between files from the set of diffs. Though not code copies. But then, we don't do code copies. Seriously again, your comment got me thinking: it could actually make sense to include the information of code moves and code copies (for easier review) in the "@@ .. @@" lines (or before them, if git apply does not choke on inserting garbage lines before them). But maybe it is not that good after all: if you review code, you should inspect it (even if it was only moved), since it might have all kinds of side effects, or you might have missed some other aspect before. Ciao, Dscho ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [PATCH 2/2] Allow fetch-pack to decide keeping the fetched pack without exploding 2007-01-23 16:43 ` Johannes Schindelin @ 2007-01-23 17:22 ` Jakub Narebski 0 siblings, 0 replies; 75+ messages in thread From: Jakub Narebski @ 2007-01-23 17:22 UTC (permalink / raw) To: git Johannes Schindelin wrote: > Seriously again, your comment got me thinking: it could actually make > sense to include the information of code moves and code copies (for easier > review) in the "@@ .. @@" lines (or before them, if git apply does not > choke on inserting garbage lines before them). > > But maybe it is not that good after all: if you review code, you should > inspect it (even if it was only moved), since it might have all kinds of > side effects, or you might have missed some other aspect before. It would be nice to have extended git header dealing with code copies (or stuff it in chunk header or above), because sometimes both sides of code movement (removal from one file, adding in next file) can be separated by a few pagefulls of chunks. -- Jakub Narebski Warsaw, Poland ShadeHawk on #git ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 2007-01-21 11:20 ` Junio C Hamano ` (3 preceding siblings ...) 2007-01-21 21:55 ` Johannes Schindelin @ 2007-01-22 18:08 ` Carl Worth 2007-01-22 19:28 ` Junio C Hamano 2007-01-22 18:22 ` Jakub Narebski 5 siblings, 1 reply; 75+ messages in thread From: Carl Worth @ 2007-01-22 18:08 UTC (permalink / raw) To: Junio C Hamano; +Cc: git, linux-kernel [-- Attachment #1: Type: text/plain, Size: 4897 bytes --] On Sun, 21 Jan 2007 03:20:06 -0800, Junio C Hamano wrote: > Also, in the same spirit of giving the release an early > exposure, here is the current draft of 1.5.0 release notes. Thanks, these are very good and really show how much great progress has gone into git recently. Congratulations to everyone who has helped with this! A few comments: > In general, you should not have to worry about incompatibility, > and there is no need to perform "repository conversion" if you > are updating to v1.5.0. However, some of the changes are > one-way street upgrades; once you use them your repository > can no longer be used with ancient git. This "one-way street upgrades" sentence makes the upgrade to 1.5 sound scarier than it really is. It's only after two more paragraphs of fairly dense technical content that the reader is told that none of this stuff is enabled by default yet. Maybe replace the second sentence with something like: As of git v1.5.0 there are some optional changes to the repository that allow data to be stored and transferred more efficiently. These changes are not enabled by default as they will make the repository unusable with git versions before v1.4.2. Specifically the available options are: or something along those lines. > - git-update-index is much less visible. It's not clear what this sentence means. Perhaps add something like: , (many mentions of update-index in git output and documentation have now been replaced by simpler commands such as "git add" or "git rm"). > - git-clone always uses what is known as "separate remote" > layout for a newly created repository with a working tree; > i.e. tracking branches in $GIT_DIR/refs/remotes/origin/ are > used to track branches from the origin. This change has some workflow impact that is not at all obvious from the above description. For example, after cloning git.git, things that used to work like "git checkout -b my-next next" now no longer work, (needing to use "origin/next" instead). And these branches also won't appear in "git branch" output, (without the new -r option). I think the release notes should spend a little more attention on an issue like this. Maybe a separate section on changes to existing interfaces, (as opposed to most of the other changes which are improvements in the implementation of existing interfaces or just plain new interfaces such as "git remote", "git gc", etc.) If there is a new section, the previous paragraphs describing the move of cloned origin information from .git/remotes/origin to .git/config might belong there as well, (depending on whether you consider those file contents a user-visible interface or not). > - git-branch and git-show-branch know remote tracking branches. Should mention "-r" here. > - git-push can now be used to delete a remote branch or a tag. > This requires the updated git on the remote side. What's the syntax for this? I know you don't want to turn the release notes into a user manual, but it'd be nice to have brief mentions of the new interfaces, (like the nice mention of "git add -i" for example). Even with a quick skim through the git-push documentation, I'm not immediately seeing how to delete a remote branch or tag. > - There is a toplevel garbage collector script, 'git-gc', that > is an easy way to run 'git-repack -a -d', 'git-reflog gc', > and 'git-prune'. I think it's definitely worthwhile to note the fix of race conditions, etc. here. It would be nice to have some short rule such as: "git gc" is free from any known race conditions with simultaneous git processes modifying the repository. So it's perfectly safe to run "git gc" from a cron job. Or a similarly succinct rule that's actually true, (I think the recent thread suggested "git gc" would only be safe with an extra option---I'd much rather see it be safe by default and make the user ask for extra unsafe pruning with an option). > - You can give non-branch to "git checkout" now. Rather than "non-branch" I think it would be nice to say something that mentioned tags. Maybe something like: You can now use 'git checkout' to checkout tags or any other revision, rather than just named branches." > - Repositories with hundreds of tags have been paying large > overhead, both in storage and in runtime, due to the > traditional one-ref-per-file format. A new command, > git-pack-refs, can be used to "pack" them in more efficient > representation. Is git-gc doing this housekeeping? If not, should it be? If so, should it be mentioned here (and in the description of git-gc above)? > - There is a partial support for 'shallow' repositories that > keeps only recent history. A 'shallow clone' is created by > specifying how deep that truncated history should be. Here's another description that could definitely benefit from a very short example command. -Carl [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 2007-01-22 18:08 ` [Announce] GIT v1.5.0-rc2 Carl Worth @ 2007-01-22 19:28 ` Junio C Hamano 2007-01-23 1:01 ` Carl Worth 0 siblings, 1 reply; 75+ messages in thread From: Junio C Hamano @ 2007-01-22 19:28 UTC (permalink / raw) To: Carl Worth; +Cc: git, linux-kernel Thanks for your comments; the attached probably needs proofreading. The changes in response to the remainder of your comments are quite straightforward and I do not think needs proofreading, so I'll incorporate them and push the result out in 'todo'. diff --git a/v1.5.0.txt b/v1.5.0.txt index c0ff071..596bfd2 100644 --- a/v1.5.0.txt +++ b/v1.5.0.txt @@ -107,11 +107,40 @@ Updates in v1.5.0 since v1.4.4 series already comfortable with your workflow with the layout. - git-clone always uses what is known as "separate remote" - layout for a newly created repository with a working tree; - i.e. tracking branches in $GIT_DIR/refs/remotes/origin/ are - used to track branches from the origin, instead of - $GIT_DIR/refs/heads/, making the difference between remotely - tracked and local branches more obvious. + layout for a newly created repository with a working tree. + + A repository with the separate remote layout starts with only + one default branch, 'master', to be used for your own + development. Unlike the traditional layout that copied all + the upstream branches into your branch namespace (while + renaming their 'master' to your 'origin'), they are not made + into your branches. Instead, they are kept track of using + 'refs/remotes/origin/$upstream_branch_name'. + + This layout keeps your own branch namespace less cluttered, + avoids name collision with your upstream, makes it possible + to automatically track new branches created at the remote + after you clone from it, and makes it easier to interact with + more than one remote repositories. There might be some + surprises: + + * 'git branch' does not show the branches from your upstream. + It only lists your own branches. Use '-r' option to view + the tracking branches. + + * If you are forking off of a branch obtained from the + upstream, you would have done something like 'git branch + my-next next', because traditional layout dropped the + tracking branch 'next' into your own branch namespace. + With the separate remote layout, you say 'git branch next + origin/next', which allows you to use the matching name + 'next' for your own branch. It also allows you to track a + remote other than 'origin' (i.e. where you initially cloned + from) and fork off of a branch from there the same way + (e.g. "git branch mingw j6t/master"). + + Repositories initialized with the traditional layout + continues to work (and will continue to work). - New branches that appear on the origin side after a clone is made are also tracked automatically. This is done with an ^ permalink raw reply related [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 2007-01-22 19:28 ` Junio C Hamano @ 2007-01-23 1:01 ` Carl Worth 0 siblings, 0 replies; 75+ messages in thread From: Carl Worth @ 2007-01-23 1:01 UTC (permalink / raw) To: Junio C Hamano; +Cc: git, linux-kernel [-- Attachment #1: Type: text/plain, Size: 2193 bytes --] On Mon, 22 Jan 2007 11:28:32 -0800, Junio C Hamano wrote: > Thanks for your comments; You're welcome. > the attached probably needs proofreading. In general, I like it. The git-branch documentation already talks about "remote-tracking branches" so I've rewritten a couple of sentence below to use that same terminology. Also there are a couple of grammar errors related to pluralization, (likely the fault of English being quite a bit less consistent than other languages with subject/verb number agreement, etc.). > + A repository with the separate remote layout starts with only > + one default branch, 'master', to be used for your own > + development. Unlike the traditional layout that copied all > + the upstream branches into your branch namespace (while > + renaming their 'master' to your 'origin'), they are not made > + into your branches. Instead, they are kept track of using > + 'refs/remotes/origin/$upstream_branch_name'. renaming remote 'master' to local 'origin'), the new approach puts upstream branches into local "remote-tracking branches" with their own namespace. These can be referenced with names such as "origin/$upstream_branch_name" and are stored in .git/refs/remotes rather than .git/refs/heads where normal branches are stored. > + This layout keeps your own branch namespace less cluttered, > + avoids name collision with your upstream, makes it possible > + to automatically track new branches created at the remote > + after you clone from it, and makes it easier to interact with > + more than one remote repositories. There might be some Should be "more than one remote repository.". Also I'd add, ", (see the new 'git remote' command)" before the end of that sentence. > + * 'git branch' does not show the branches from your upstream. Again to use the same terminology, "does not show the remote-tracking branches.". > + Repositories initialized with the traditional layout > + continues to work (and will continue to work). The 's' on "continues" is incorrect. Perhaps: continue to work (and will work in the future as well). or just drop the parenthetical phrase. -Carl [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 2007-01-21 11:20 ` Junio C Hamano @ 2007-01-22 18:22 ` Jakub Narebski 2007-01-21 13:43 ` Willy Tarreau ` (4 subsequent siblings) 5 siblings, 0 replies; 75+ messages in thread From: Jakub Narebski @ 2007-01-22 18:22 UTC (permalink / raw) To: linux-kernel; +Cc: git Junio C Hamano wrote: > GIT v1.5.0 Release Notes (draft) > ================================ Would they be somewhere besides todo branch of git.git repository, like the v1.5.0 tag comment (content), or the NEWS file? -- Jakub Narebski Warsaw, Poland ShadeHawk on #git ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 @ 2007-01-22 18:22 ` Jakub Narebski 0 siblings, 0 replies; 75+ messages in thread From: Jakub Narebski @ 2007-01-22 18:22 UTC (permalink / raw) To: git; +Cc: linux-kernel Junio C Hamano wrote: > GIT v1.5.0 Release Notes (draft) > ================================ Would they be somewhere besides todo branch of git.git repository, like the v1.5.0 tag comment (content), or the NEWS file? -- Jakub Narebski Warsaw, Poland ShadeHawk on #git ^ permalink raw reply [flat|nested] 75+ messages in thread
* Re: [Announce] GIT v1.5.0-rc2 2007-01-22 18:22 ` Jakub Narebski (?) @ 2007-01-22 18:46 ` Junio C Hamano -1 siblings, 0 replies; 75+ messages in thread From: Junio C Hamano @ 2007-01-22 18:46 UTC (permalink / raw) To: Jakub Narebski; +Cc: git Jakub Narebski <jnareb@gmail.com> writes: > Junio C Hamano wrote: > >> GIT v1.5.0 Release Notes (draft) >> ================================ > > Would they be somewhere besides todo branch of git.git repository, like the > v1.5.0 tag comment (content), or the NEWS file? Most likely the former would happen when the real thing is made. ^ permalink raw reply [flat|nested] 75+ messages in thread
end of thread, other threads:[~2007-03-27 0:13 UTC | newest] Thread overview: 75+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-01-21 8:56 [Announce] GIT v1.5.0-rc2 Junio C Hamano 2007-01-21 9:40 ` Jakub Narebski 2007-01-21 10:52 ` Junio C Hamano 2007-01-21 11:08 ` Johannes Schindelin 2007-01-23 18:12 ` Bill Lear 2007-01-23 19:12 ` Johannes Schindelin 2007-01-23 20:12 ` Bill Lear 2007-01-23 20:22 ` Uwe Kleine-König 2007-01-23 20:31 ` Bill Lear 2007-01-24 10:06 ` Uwe Kleine-König 2007-01-23 20:22 ` Johannes Schindelin 2007-01-23 21:09 ` Peter Baumann 2007-01-23 21:54 ` Bill Lear 2007-01-23 20:32 ` Linus Torvalds 2007-01-24 17:54 ` Mark Nudelman 2007-01-24 18:18 ` Linus Torvalds 2007-01-24 19:21 ` Linus Torvalds 2007-01-24 23:23 ` Junio C Hamano 2007-03-27 0:07 ` Mark Nudelman 2007-01-21 11:20 ` Junio C Hamano 2007-01-21 13:42 ` Bill Lear 2007-01-21 13:52 ` Bill Lear 2007-01-21 15:02 ` Michael 2007-01-21 15:02 ` Michael 2007-01-21 21:26 ` Johannes Schindelin 2007-01-21 21:33 ` Jakub Narebski 2007-01-21 21:33 ` Jakub Narebski 2007-01-21 22:01 ` Johannes Schindelin 2007-01-21 22:24 ` Jakub Narebski 2007-01-21 22:24 ` Jakub Narebski 2007-01-21 13:43 ` Willy Tarreau 2007-01-21 15:06 ` Jakub Narebski 2007-01-21 15:06 ` Jakub Narebski 2007-01-21 18:58 ` Junio C Hamano 2007-01-21 19:49 ` H. Peter Anvin 2007-01-22 17:23 ` Nicolas Pitre 2007-01-21 20:01 ` Horst H. von Brand 2007-01-22 1:27 ` Junio C Hamano 2007-01-21 19:46 ` Horst H. von Brand 2007-01-21 20:51 ` Junio C Hamano 2007-01-21 21:55 ` Johannes Schindelin 2007-01-21 22:45 ` Jakub Narebski 2007-01-21 22:45 ` Jakub Narebski 2007-01-21 22:52 ` Johannes Schindelin 2007-01-21 23:08 ` Jakub Narebski 2007-01-21 23:13 ` Johannes Schindelin 2007-01-21 23:36 ` Jakub Narebski 2007-01-22 0:55 ` Junio C Hamano 2007-01-22 6:25 ` Junio C Hamano 2007-01-23 6:47 ` [PATCH 1/2] Refactor the pack header reading function out of receive-pack.c Junio C Hamano 2007-01-23 6:47 ` [PATCH 2/2] Allow fetch-pack to decide keeping the fetched pack without exploding Junio C Hamano 2007-01-23 10:32 ` Johannes Schindelin 2007-01-23 10:55 ` Jakub Narebski 2007-01-23 11:07 ` code movements in diffs, was " Johannes Schindelin 2007-01-23 16:01 ` Nicolas Pitre 2007-01-25 1:14 ` [PATCH] fetch-pack: remove --keep-auto and make it the default Junio C Hamano 2007-01-25 8:23 ` Johannes Schindelin 2007-01-25 21:32 ` Junio C Hamano 2007-01-25 23:46 ` Johannes Schindelin 2007-01-26 3:05 ` Junio C Hamano 2007-01-26 3:30 ` [PATCH] Allow non-developer to clone, checkout and fetch easier Junio C Hamano 2007-01-26 14:20 ` Alex Riesen 2007-01-26 8:37 ` [PATCH] fetch-pack: remove --keep-auto and make it the default Johannes Sixt 2007-01-25 1:14 ` [PATCH] Consolidate {receive,fetch}.unpackLimit Junio C Hamano 2007-01-25 3:32 ` Nicolas Pitre 2007-01-25 5:14 ` Shawn O. Pearce 2007-01-23 16:15 ` [PATCH 2/2] Allow fetch-pack to decide keeping the fetched pack without exploding Linus Torvalds 2007-01-23 16:28 ` David Kågedal 2007-01-23 16:43 ` Johannes Schindelin 2007-01-23 17:22 ` Jakub Narebski 2007-01-22 18:08 ` [Announce] GIT v1.5.0-rc2 Carl Worth 2007-01-22 19:28 ` Junio C Hamano 2007-01-23 1:01 ` Carl Worth 2007-01-22 18:22 ` Jakub Narebski 2007-01-22 18:22 ` Jakub Narebski 2007-01-22 18:46 ` Junio C Hamano
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.