Re: [Announce] GIT v1.5.0-rc2
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 pgpJ2CCBnd3h5.pgp Description: PGP signature
Re: [Announce] GIT v1.5.0-rc2
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
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
Re: [Announce] GIT v1.5.0-rc2
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
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 pgpbnlQIvUfaj.pgp Description: PGP signature
Re: [Announce] GIT v1.5.0-rc2
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
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 pgpJ2CCBnd3h5.pgp Description: PGP signature
Re: [Announce] GIT v1.5.0-rc2
"Horst H. von Brand" <[EMAIL PROTECTED]> writes: > Junio C Hamano <[EMAIL PROTECTED]> wrote: >> Willy Tarreau <[EMAIL PROTECTED]> 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
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 s 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 :refs/heads/" 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
Junio C Hamano <[EMAIL PROTECTED]> 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 InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
Junio C Hamano <[EMAIL PROTECTED]> wrote: > Willy Tarreau <[EMAIL PROTECTED]> 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 InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
Willy Tarreau <[EMAIL PROTECTED]> 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
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 linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
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 [EMAIL PROTECTED] >More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
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 [EMAIL PROTECTED] 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 used to refuse to commit if 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 ... 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
[Announce] GIT v1.5.0-rc2
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 - 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 - 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 *
[Announce] GIT v1.5.0-rc2
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():
Re: [Announce] GIT v1.5.0-rc2
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 [EMAIL PROTECTED] 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.
Re: [Announce] GIT v1.5.0-rc2
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
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 linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
Willy Tarreau [EMAIL PROTECTED] 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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
Junio C Hamano [EMAIL PROTECTED] wrote: Willy Tarreau [EMAIL PROTECTED] 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 InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
Junio C Hamano [EMAIL PROTECTED] 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 InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
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 s 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] GIT v1.5.0-rc2
Horst H. von Brand [EMAIL PROTECTED] writes: Junio C Hamano [EMAIL PROTECTED] wrote: Willy Tarreau [EMAIL PROTECTED] 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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
