Re: What's cooking in git.git (May 2013, #04; Wed, 15)
Duy Nguyen pclo...@gmail.com writes: Point taken. I guess the message would be something like this? Refname '%.*s' is ignored. It may be created by mistake. Or should we be more elaborate? I dunno; with s/may be/may have been/, I think it is better than refname is ambiguous. -- 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: What's cooking in git.git (May 2013, #04; Wed, 15)
On Mon, May 20, 2013 at 11:17 PM, Junio C Hamano gits...@pobox.com wrote: Think why the user has such a hard to type ref in the first place. The user may have done this previously, thinking that he is detaching the HEAD to fix an earlier mistake in a branch: $ BAD_COMMIT=$(git rev-parse nd/magic~8) $ git checkout $BAD_COMMIT but by mistake gave a -b after checkout, i.e. $ git checkout -b $BAD_COMMIT After this, commands that want to work on branch name would still work as expected, with the expectation being the user would be working on the refs/heads/$BAD_COMMIT branch, e.g. $ git checkout $BAD_COMMIT $ git branch -m $BAD_COMMIT nd/magic-fix but commands that want to work on commit object name will resolve it to the $BAD_COMMIT object (i.e. nd/magic~8), e.g. $ git log $BAD_COMMIT and needs disambiguation if the user wants to work on the commit at the tip of the branch, e.g. $ git log heads/$BAD_COMMIT So we really do want the users to notice and take corrective action, and one way to attract the attention of the users is to phrase the message more explicitly to let them know what is going on. Point taken. I guess the message would be something like this? Refname '%.*s' is ignored. It may be created by mistake. Or should we be more elaborate? -- Duy -- 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: What's cooking in git.git (May 2013, #04; Wed, 15)
Thomas Rast tr...@inf.ethz.ch writes: Junio C Hamano gits...@pobox.com writes: In addition to your topic, it may be a good idea to notice this at the Porcelain level (e.g. checkout -b and branch, but not at the update-ref level) and warn or even die if a Porcelain tries to create a branch with such a name. But if we're going there and deprecating some ways of naming refs, This is not about deprecating but is discouraging a confusing use at the Porcelain level (i.e. enforcing one policy decision that may not apply to those who wrote their own workflow using plumbing commands, knowing and following the full 40-hex is taken as an object name, not a dwimmed ref rule---to them there is no ambiguities). I think I see where you are going and I do not necessarily disagree with that, but it is a separate topic. please also disallow some other funny things in the same go. Michael suggested this earlier in some thread: the fewer ways we have of legally spelling refnames, the more syntax is available for revision syntax. -- 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: What's cooking in git.git (May 2013, #04; Wed, 15)
Duy Nguyen pclo...@gmail.com writes: On Thu, May 16, 2013 at 6:42 AM, Junio C Hamano gits...@pobox.com wrote: * nd/warn-ambiguous-object-name (2013-05-07) 1 commit - get_sha1: improve ambiguity warning regarding SHA-1 and ref names git cmd name, when name happens to be a 40-hex string, directly uses the 40-hex string as an object name, even if a ref refs/some hierarchy/name exists. This disambiguation order is unlikely to change, but we should warn about the ambiguity just like we warn when more than one refs/ hierachies share the same name. The message needs to be fixed up, as this is not refname is ambiguous. hm.. how should the message be rephrased? ambiguity of 40-hex string and a ref path? At that point, the user gave us a full object name and we are going to treat it as a full object name, no? Wouldn't it be necessary to let the user know that it is different from having two ambiguous refs? Think why the user has such a hard to type ref in the first place. The user may have done this previously, thinking that he is detaching the HEAD to fix an earlier mistake in a branch: $ BAD_COMMIT=$(git rev-parse nd/magic~8) $ git checkout $BAD_COMMIT but by mistake gave a -b after checkout, i.e. $ git checkout -b $BAD_COMMIT After this, commands that want to work on branch name would still work as expected, with the expectation being the user would be working on the refs/heads/$BAD_COMMIT branch, e.g. $ git checkout $BAD_COMMIT $ git branch -m $BAD_COMMIT nd/magic-fix but commands that want to work on commit object name will resolve it to the $BAD_COMMIT object (i.e. nd/magic~8), e.g. $ git log $BAD_COMMIT and needs disambiguation if the user wants to work on the commit at the tip of the branch, e.g. $ git log heads/$BAD_COMMIT So we really do want the users to notice and take corrective action, and one way to attract the attention of the users is to phrase the message more explicitly to let them know what is going on. In addition to your topic, it may be a good idea to notice this at the Porcelain level (e.g. checkout -b and branch, but not at the update-ref level) and warn or even die if a Porcelain tries to create a branch with such a name. -- 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
What's cooking in git.git (May 2013, #04; Wed, 15)
Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. We are past -rc2 and haven't seen any regression reported since the feature freeze started, which may be a good sign (the coming release is perfect) or a bad sign (nobody is testing). We'll see soon when we tag the 1.8.3 final sometime next week. We may see subsystem (git-svn? gitk? git-gui?) and l10n updates before that happens. You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-public-repositories.html -- [New Topics] * dw/asciidoc-sources-are-dot-txt-files (2013-05-10) 1 commit - CodingGuidelines: Documentation/*.txt are the sources * fc/doc-style (2013-05-09) 2 commits - SQUASH??? more consistently update docs - documentation: trivial style cleanups * da/darwin (2013-05-15) 3 commits - imap-send: eliminate HMAC deprecation warnings on Mac OS X - cache.h: eliminate SHA-1 deprecation warnings on Mac OS X - Makefile: fix default regex settings on Darwin Waiting for polishing discussion to finish. * fc/macos-x-clipped-write (2013-05-10) 2 commits - SQUASH??? - compate/clipped-write.c: large write(2) fails on Mac OS X/XNU The tip needs to be squashed, as it was reported to have tested OK. * fc/remote-hg (2013-05-15) 39 commits - remote-hg: remove files before modifications - remote-hg: improve lightweight tag author - remote-hg: use remote 'default' not local one - remote-hg: improve branch listing - remote-hg: simplify branch_tip() - remote-hg: check diverged bookmarks - remote-hg: pass around revision refs - remote-hg: implement custom checkheads() - remote-hg: implement custom push() - remote-hg: only update necessary revisions - remote-hg: force remote bookmark push selectively - remote-hg: reorganize bookmark handling - remote-hg: add test for failed double push - remote-hg: add test for big push - remote-hg: add test for new bookmark special - remote-hg: add test for bookmark diverge - remote-hg: add test for diverged push - remote-hg: add test to push new bookmark - remote-hg: add remote tests - remote-hg: add check_bookmark() test helper - remote-bzr: simplify test checks - remote-hg: always point HEAD to master - remote-hg: improve progress calculation - remote-hg: trivial cleanups - remote-hg: ensure remote rebasing works - remote-hg: upgrade version 1 marks - remote-hg: switch from revisions to SHA-1 noteids - remote-hg: add version checks to the marks - remote-hg: improve node traversing - remote-hg: shuffle some code - remote-hg: use a shared repository store - remote-hg: load all extensions - remote-hg: test: simplify previous branch checkout - remote-helpers: test: simplify remote URLs - remote-helpers: tests: general improvements - remote-helpers: test: cleanup style - remote-helpers: test: cleanup white-spaces - remote-hg: trivial reorganization - remote-hg: test: be a little more quiet Probably will be one of the early topics to graduate post 1.8.3. * hv/config-from-blob (2013-05-12) 5 commits - do not die when error in config parsing of buf occurs - teach config --blob option to parse config from database - config: make parsing stack struct independent from actual data source - config: drop cf validity check in get_next_char() - config: factor out config file stack management * jc/t5551-posix-sed-bre (2013-05-12) 1 commit - t5551: do not use unportable sed '\+' Not a regression fix and not urgent. * jk/fetch-always-update-tracking (2013-05-12) 4 commits - fetch: opportunistically update tracking refs - refactor ref-merge flag - fetch/pull doc: untangle meaning of bare ref - t5510: start tracking-ref tests from a known state git fetch origin master unlike git fetch origin or git fetch does not update refs/remotes/origin/master and it was an early design decision to keep the update of remote tracking branches predictable, but in practice it turns out that people find it more convenient to opportunisticly update them whenever we have a chance, and we have been updating them when we run git push which already breaks the original predictability anyway. * nd/clone-connectivity-shortcut (2013-05-11) 4 commits - clone: open a shortcut for connectivity check - index-pack: remove dead code (it should never happen) - fetch-pack: prepare updated shallow file before fetching the pack - clone: let the user know when check_everything_connected is run * rr/rebase-autostash (2013-05-12) 7 commits - rebase: implement --[no-]autostash and rebase.autostash - rebase --merge: return control to caller, for housekeeping - rebase -i: return control to caller, for housekeeping - am: return control to caller, for housekeeping - rebase: prepare to do generic housekeeping - rebase -i: don't error out if $state_dir already
Re: What's cooking in git.git (May 2013, #04; Wed, 15)
On Wed, May 15, 2013 at 4:42 PM, Junio C Hamano gits...@pobox.com wrote: Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. We are past -rc2 and haven't seen any regression reported since the feature freeze started, which may be a good sign (the coming release is perfect) or a bad sign (nobody is testing). We'll see soon when we tag the 1.8.3 final sometime next week. We may see subsystem (git-svn? gitk? git-gui?) and l10n updates before that happens. You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-public-repositories.html -- [New Topics] * dw/asciidoc-sources-are-dot-txt-files (2013-05-10) 1 commit - CodingGuidelines: Documentation/*.txt are the sources * fc/doc-style (2013-05-09) 2 commits - SQUASH??? more consistently update docs - documentation: trivial style cleanups * da/darwin (2013-05-15) 3 commits - imap-send: eliminate HMAC deprecation warnings on Mac OS X - cache.h: eliminate SHA-1 deprecation warnings on Mac OS X - Makefile: fix default regex settings on Darwin Waiting for polishing discussion to finish. Thanks. imap-send and cache.h are now on their v6 patch which I just sent. That last few rounds have been cosmetic/superficial changes and I would like to consider this topic done. We've painted this shed enough times ;-) I believe fix default regex settings on Darwin is uncontroversial and should be included in the upcoming release. It may even be maint-worthy. Without it we fail t0070-fundamental.sh. The two patches that follow it can wait and cook like normal. -- David -- 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
