Re: [ANNOUNCE] Git v1.8.3-rc0
Michael Haggerty mhag...@alum.mit.edu writes:
On 04/27/2013 04:24 AM, shawn wilson wrote:
On Fri, Apr 26, 2013 at 8:22 PM, Junio C Hamano gits...@pobox.com wrote:
* There was no good way to ask I have a random string that came from
outside world. I want to turn it into a 40-hex object name while
making sure such an object exists. A new peeling suffix ^{object}
can be used for that purpose, together with rev-parse --verify.
What does this mean / what is the reason behind this? I can only think
it might be useful in a test suite to make sure git isn't doing
anything stupid with hashes...?
The topic is discussed here:
http://git.661346.n2.nabble.com/Bug-in-quot-git-rev-parse-verify-quot-td7580929.html
As discussed in the thread, when verifying that an argument names an
existing object, it is usually also appropriate to verify that the named
object is of a particular type (or can be converted to a particular
type), which could already be done with syntax like
$userstring^{commit}. But if, for example, you want to avoid
unwrapping tags but also want to verify that the named object really
exists, $userstring^{object} now provides a way.
And what do you have against test suites? :-)
And it is not about test in the first place. Git is designed to be
scriptable, and it is not unreasonable for a scripted Porcelain to
want to learn the full object name of the object that is referred to
by a string that it suspects may be an object name. Perhaps you are
feeding the entire git mailing list archive to a script that picks
up any object name in the messages and tallying the number of times
each object is mentioned. Then you would want to key the table that
counts the number of appearances for each object with the object
name, because different message may spell the name of the same
object differently, e.g. f9fc12cf3, v1.8.3-rc0, etc. With a helper
function found_one_more_instance that records the fact you saw
another mention of an object, such a program may do something like
this:
tokenize_git_mailing_list_message |
while read userstring
do
canonical=$(git rev-parse $userstring^{object})
found_one_more_instance $canonical
done
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Git v1.8.3-rc0
John Keeping j...@keeping.me.uk writes: On Fri, Apr 26, 2013 at 05:22:22PM -0700, Junio C Hamano wrote: * git difftool allows the user to write into the temporary files being shown; if the user makes changes to the working tree at the same time, one of the changes has to be lost in such a case, but it tells the user what happened and refrains from overwriting the copy in the working tree. This feels slightly misleading to me, perhaps something like this would be clearer? git difftool allows the user to write into the temporary files being shown; if the user makes changes to the working tree at the same time, it now refrains from overwriting the copy in the working tree and leaves the temporary file so that changes can be merged manually. Probably. I'll keep the above in my stash and roll it in by -rc1. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Git v1.8.3-rc0
On Fri, Apr 26, 2013 at 05:22:22PM -0700, Junio C Hamano wrote: * git difftool allows the user to write into the temporary files being shown; if the user makes changes to the working tree at the same time, one of the changes has to be lost in such a case, but it tells the user what happened and refrains from overwriting the copy in the working tree. This feels slightly misleading to me, perhaps something like this would be clearer? git difftool allows the user to write into the temporary files being shown; if the user makes changes to the working tree at the same time, it now refrains from overwriting the copy in the working tree and leaves the temporary file so that changes can be merged manually. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ANNOUNCE] Git v1.8.3-rc0
A release candidate preview Git v1.8.3-rc0 is now available for testing at the usual places. The release tarballs are found at: http://code.google.com/p/git-core/downloads/list and their SHA-1 checksums are: f0b0b415f0c693865895c1918859b12c4a7d5b17 git-1.8.3.rc0.tar.gz 089efc61b3d45504cb53003719d1bb3d953a41a8 git-htmldocs-1.8.3.rc0.tar.gz 57a6e889667597f2699e4d6fb97c8cf6e595cb4a git-manpages-1.8.3.rc0.tar.gz Also the following public repositories all have a copy of the v1.8.3-rc0 tag and the master branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://code.google.com/p/git-core/ url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git Git v1.8.3 Release Notes (draft) Backward compatibility notes (for Git 2.0) -- When git push [$there] does not say what to push, we have used the traditional matching semantics so far (all your branches were sent to the remote as long as there already are branches of the same name over there). In Git 2.0, the default will change to the simple semantics that pushes the current branch to the branch with the same name, only when the current branch is set to integrate with that remote branch. There is a user preference configuration variable push.default to change this. If you are an old-timer who is used to the matching semantics, you can set it to matching to keep the traditional behaviour. If you want to live in the future early, you can set it to simple today without waiting for Git 2.0. When git add -u and git add -A, that does not specify what paths to add on the command line is run from inside a subdirectory, these commands will operate on the entire tree in Git 2.0 for consistency with git commit -a and other commands. Because there will be no mechanism to make git add -u behave as if git add -u ., it is important for those who are used to git add -u (without pathspec) updating the index only for paths in the current subdirectory to start training their fingers to explicitly say git add -u . when they mean it before Git 2.0 comes. A warning is issued when these commands are run without a pathspec and when you have local changes outside the current directory, because the behaviour in Git 2.0 will be different from today's version in such a situation. In Git 2.0, git add path will behave as git add -A path, so that git add dir/ will notice paths you removed from the directory and record the removal. Versions before Git 2.0, including this release, will keep ignoring removals, but the users who rely on this behaviour is encouraged to use git add --ignore-removal path and get used to it. Updates since v1.8.2 Foreign interface * remote-hg and remote-bzr helpers (in contrib/) have been updated. UI, Workflows Features * git branch --vv learned to paint the name of the branch it integrates with in a different color (color.branch.upstream, which defaults to blue). * In a sparsely populated working tree, git checkout pathspec no longer unmarks paths that match the given pathspec that were originally ignored with --sparse (use --ignore-skip-worktree-bits option to resurrect these paths out of the index if you really want to). * git log --format specifier learned %C(auto) token that tells Git to use color when interpolating %d (decoration), %h (short commit object name), etc. for terminal output. * git bisect leaves the final outcome as a comment in its bisect log file. * git clone --reference can now refer to a gitfile textual symlink that points at the real location of the repository. * git count-objects learned --human-readable aka -H option to show various large numbers in Ki/Mi/GiB scaled as necessary. * git cherry-pick $blob and git cherry-pick $tree are nonsense, and a more readable error message e.g. can't cherry-pick a tree is given (we used to say expected exactly one commit). * The --annotate option to git send-email can be turned on (or off) by default with sendemail.annotate configuration variable (you can use --no-annotate from the command line to override it). * The --cover-letter option to git format-patch can be turned on (or off) by default with format.coverLetter configuration variable. By setting it to 'auto', you can turn it on only for a series with two or more patches. * The bash completion support (in contrib/) learned that cherry-pick takes a few more options than it already knew about. * git help learned -g option to show the list of guides just like list of commands are given with -a. * A triangular pull from one place, push to another place workflow is supported better by new remote.pushdefault (overrides the origin thing) and branch.*.pushremote (overrides
Re: [ANNOUNCE] Git v1.8.3-rc0
On Fri, Apr 26, 2013 at 8:22 PM, Junio C Hamano gits...@pobox.com wrote:
* There was no good way to ask I have a random string that came from
outside world. I want to turn it into a 40-hex object name while
making sure such an object exists. A new peeling suffix ^{object}
can be used for that purpose, together with rev-parse --verify.
What does this mean / what is the reason behind this? I can only think
it might be useful in a test suite to make sure git isn't doing
anything stupid with hashes...?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Git v1.8.3-rc0
On 04/27/2013 04:24 AM, shawn wilson wrote:
On Fri, Apr 26, 2013 at 8:22 PM, Junio C Hamano gits...@pobox.com wrote:
* There was no good way to ask I have a random string that came from
outside world. I want to turn it into a 40-hex object name while
making sure such an object exists. A new peeling suffix ^{object}
can be used for that purpose, together with rev-parse --verify.
What does this mean / what is the reason behind this? I can only think
it might be useful in a test suite to make sure git isn't doing
anything stupid with hashes...?
The topic is discussed here:
http://git.661346.n2.nabble.com/Bug-in-quot-git-rev-parse-verify-quot-td7580929.html
As discussed in the thread, when verifying that an argument names an
existing object, it is usually also appropriate to verify that the named
object is of a particular type (or can be converted to a particular
type), which could already be done with syntax like
$userstring^{commit}. But if, for example, you want to avoid
unwrapping tags but also want to verify that the named object really
exists, $userstring^{object} now provides a way.
And what do you have against test suites? :-)
Michael
--
Michael Haggerty
mhag...@alum.mit.edu
http://softwareswirl.blogspot.com/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
