Re: What's cooking in git.git (Feb 2013, #05; Tue, 12)
Junio C Hamano gits...@pobox.com writes: * Introduce git add --ignore-removal option in the release after the current cycle (a new feature is too late for this cycle): Too late in the cycle even if the option is simply ignored ... ? [To extend the range of git versions where it's not an error] -miles -- Kilt, n. A costume sometimes worn by Scotchmen [sic] in America and Americans in Scotland. -- 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 (Feb 2013, #05; Tue, 12)
Miles Bader mi...@gnu.org writes: Junio C Hamano gits...@pobox.com writes: * Introduce git add --ignore-removal option in the release after the current cycle (a new feature is too late for this cycle): Too late in the cycle even if the option is simply ignored ... ? [To extend the range of git versions where it's not an error] I'd feel safer to have enough time to cook the alleged no-op before merging it to 'master' and include it in a release. Possible implementation mistakes aside, --ignore-removal is probably too long to type, we haven't even discussed if it deserves a short-and-sweet single letter option, the obvious -i is not available, etc. etc. I do not think we have a concensus that the transition plan outlined is a good way to go in the first place. So, I do think it is a bit too late for this cycle, especially when we still have doubts about the design. Actually it is *I* who have doubts; I do not even know if other people share the doubts or they support the direction wholeheartedly. -- 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 (Feb 2013, #05; Tue, 12)
Junio C Hamano gits...@pobox.com writes: * dg/subtree-fixes (2013-02-05) 6 commits (merged to 'next' on 2013-02-09 at 8f19ebe) + contrib/subtree: make the manual directory if needed + contrib/subtree: honor DESTDIR + contrib/subtree: fix synopsis + contrib/subtree: better error handling for 'subtree add' + contrib/subtree: use %B for split subject/body + contrib/subtree: remove test number comments contrib/subtree updates, but here are only the ones that looked ready to be merged to 'next'. For the remainder, they will have another day. Great, I've got updates for the rest. -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
Re: What's cooking in git.git (Feb 2013, #05; Tue, 12)
Andrew Ardill andrew.ard...@gmail.com writes: If that is the change we are going to make, and if you can guarantee that nobody who is used to the historical behaviour will complain, then I am fine with it, but I think the latter part of the condition will not hold. Does the impossibility of asserting that no-one will complain put this in the 'too hard' bucket? Basically, yes. Cannot be done without UI regression. It could be a Git 2.0 item, if you plan the transition right, though. The implication here is that a relatively small number of people will be inconvenienced by needing to specify extra flags/set up an alias. Compare this to the many for whom the expected behaviour is now default, and we have a net win. We take backward compatibility a lot more seriously; it is not even a democracy. Net win does not mean an iota. Even if small number is 47 and large majority is 4 million, it does not change the fact that you are breaking things these 47 people have depended on working in an expected (the expected does not have to be intuitive in this sentence; what counts more is that it is the way they are accustomed to) way and introducing a UI regression. -- 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 (Feb 2013, #05; Tue, 12)
Junio C Hamano gits...@pobox.com writes: Andrew Ardill andrew.ard...@gmail.com writes: If that is the change we are going to make, and if you can guarantee that nobody who is used to the historical behaviour will complain, then I am fine with it, but I think the latter part of the condition will not hold. Does the impossibility of asserting that no-one will complain put this in the 'too hard' bucket? Basically, yes. Cannot be done without UI regression. It could be a Git 2.0 item, if you plan the transition right, though. I have been staring at the patch again, but I do not think of an easy way out without retraining the old timers to introduce this if we knew better, we would have done so from day one and the world would have been a much better place change. If we were to have this in the longer term, we would need a proper transition plan, similar to the one we devised to change the default used for a lazy git push (and git push $there) from the traditional matching to simple at Git 2.0 boundary. The transition would go like this: * Introduce git add --ignore-removal option in the release after the current cycle (a new feature is too late for this cycle): - when git add pathspec is given without --ignore-removal, give a warning about upcoming default change, and advise people to use either --ignore-removal or --all option, but behave as if --ignore-removal were given. - when git add --ignore-removal pathspec is given, only add additions and modifications, just like the current behaviour. - obviously, -u, -A, and --ignore-removal are mutually exclusive. * Run with the above for a few releases. * Change the behaviour of git add pathspec without -u, -A nor --ignore-removal to error out with the same warning and advise. * Run with the above for a few releases. * At Git 2.0, change git add pathspec without -u, -A nor --ignore-removal to behave as if git add -A pathspec were given. At any point during the above transtion, git add without any pathspec will not change its meaning; it will stay a no-op. -- 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 (Feb 2013, #05; Tue, 12)
Andrew Ardill andrew.ard...@gmail.com writes: On 13 February 2013 11:34, Junio C Hamano gits...@pobox.com wrote: The change could negatively affect people who expect that removing files that are not used for their purpose (e.g. a large file that is unnecessary for their build) will _not_ affect what they get from git add .; How big a problem is this? As you said below, it could be fairly big, if you expect a lot of people do not use git add -u. If we need to support this behaviour than I would suppose a config option is required. A default config transition path similar to git push defaults would probably work well, in the case where breaking these expectations is unacceptable. We've discussed that before. http://thread.gmane.org/gmane.comp.version-control.git/171811/focus=171818 obviously they must have trained themselves not to do git add -u or git commit -a. Many people use git add -p by default, so I would not be surprised about people not using -u or -a. -- 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 (Feb 2013, #05; Tue, 12)
On 14 February 2013 02:27, Junio C Hamano gits...@pobox.com wrote: If we need to support this behaviour than I would suppose a config option is required. A default config transition path similar to git push defaults would probably work well, in the case where breaking these expectations is unacceptable. We've discussed that before. http://thread.gmane.org/gmane.comp.version-control.git/171811/focus=171818 Something that I couldn't find discussed was the option of, rather than providing a config to 'turn it off', inverting the current default/flags combo. That is, currently git add defaults to not staging file deletions, and we provide command line flags to include them. The consensus in the thread is that it is better to stage them by default; it seems reasonable to me that if we stage deletions by default we should provide flags to _not_ stage them. If that was the entirety of the change, would your position from that thread, if we need this optional, then it is not worth doing this, still hold? Some people would be adversely affected by this change, but any objections I can come up with are not game stoppers. - It is possible newcomers might stumble at deleted files being staged for commit by a command called 'add', but if they can already grok the concept of staging then including deletions in that is trivial. If they don't understand staging then we have a different issue. - For people who rely heavily on file deletions remaining out of the index, providing a flag allows them to keep their workflow. No data would be lost, and most accidents would be easily recoverable. - For scripts that rely on this behaviour, a flag allows it to be updated, though it may break in the meantime. (I would presume that not many of these scripts exist in the first place, but I don't really know) Finally, making this change makes sense from a consistency point of view. For example, we don't track file renames because (and I paraphrase) we can work that out from the content that is moved. However if I rename a file and then 'git add .' I see that a new file is added, not that it has been renamed! Manually adding the deletion to the index causes git to correctly detect the rename, however this is unintuitive and not consistent with how git works and is communicated in general. Git add is also inconsistent with git add -p (although that might be due to unclear documentation for -p). When in patch mode, git add will propose deletions get added to the index as well, not just additions and modifications. Regards, Andrew Ardill -- 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 (Feb 2013, #05; Tue, 12)
Andrew Ardill andrew.ard...@gmail.com writes: We've discussed that before. http://thread.gmane.org/gmane.comp.version-control.git/171811/focus=171818 Something that I couldn't find discussed was the option of, rather than providing a config to 'turn it off', inverting the current default/flags combo. That is, currently git add defaults to not staging file deletions, and we provide command line flags to include them. The consensus in the thread is that it is better to stage them by default; it seems reasonable to me that if we stage deletions by default we should provide flags to _not_ stage them. If that was the entirety of the change, would your position from that thread, if we need this optional, then it is not worth doing this, still hold? If that is the change we are going to make, and if you can guarantee that nobody who is used to the historical behaviour will complain, then I am fine with it, but I think the latter part of the condition will not hold. Some people would be adversely affected by this change, but any objections I can come up with are not game stoppers. - It is possible newcomers might stumble at deleted files being staged for commit by a command called 'add',... New people are fair game; we haven't trained them with the inconsistent behaviour, and the default being different from historical behaviour will not affect them adversely. - For people who rely heavily on file deletions remaining out of the index, providing a flag allows them to keep their workflow. Allowing to do the things they used to be able to do is a bare minimum. You are still forcing them to do things differently. - For scripts that rely on this behaviour, a flag allows it to be updated, though it may break in the meantime. Likewise. Finally, making this change makes sense from a consistency point of view. That is a given. Otherwise we wouldn't be even discussing this. -- 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 (Feb 2013, #05; Tue, 12)
On 14 February 2013 15:36, Junio C Hamano gits...@pobox.com wrote: That is, currently git add defaults to not staging file deletions, and we provide command line flags to include them. The consensus in the thread is that it is better to stage them by default; it seems reasonable to me that if we stage deletions by default we should provide flags to _not_ stage them. If that was the entirety of the change, would your position from that thread, if we need this optional, then it is not worth doing this, still hold? If that is the change we are going to make, and if you can guarantee that nobody who is used to the historical behaviour will complain, then I am fine with it, but I think the latter part of the condition will not hold. Does the impossibility of asserting that no-one will complain put this in the 'too hard' bucket? Some people would be adversely affected by this change, but any objections I can come up with are not game stoppers. - It is possible newcomers might stumble at deleted files being staged for commit by a command called 'add',... New people are fair game; we haven't trained them with the inconsistent behaviour, and the default being different from historical behaviour will not affect them adversely. - For people who rely heavily on file deletions remaining out of the index, providing a flag allows them to keep their workflow. Allowing to do the things they used to be able to do is a bare minimum. You are still forcing them to do things differently. The implication here is that a relatively small number of people will be inconvenienced by needing to specify extra flags/set up an alias. Compare this to the many for whom the expected behaviour is now default, and we have a net win. Finally, making this change makes sense from a consistency point of view. That is a given. Otherwise we wouldn't be even discussing this. Obviously I agree. I was actually bringing up a point about patch mode and it got incorporated into the bigger picture; patch mode includes deletions by default and I don't even know if you can turn that behaviour off. So, when we talk about git add -u and git add -A, we should also mention git add -p. Regards, Andrew Ardill -- 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 (Feb 2013, #05; Tue, 12)
Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. A preview of the upcoming release 1.8.2-rc0 is expected to be tagged late this week. 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 -- [Graduated to master] * sp/smart-http-content-type-check (2013-02-06) 3 commits (merged to 'next' on 2013-02-06 at 8bc6434) + http_request: reset type strbuf before adding (merged to 'next' on 2013-02-05 at 157812c) + t5551: fix expected error output (merged to 'next' on 2013-02-04 at d0759cb) + Verify Content-Type from smart HTTP servers The smart HTTP clients forgot to verify the content-type that comes back from the server side to make sure that the request is being handled properly. -- [New Topics] * da/p4merge-mktemp-fix (2013-02-10) 1 commit - p4merge: fix printf usage Will merge to 'next'. * jn/shell-disable-interactive (2013-02-11) 2 commits - shell: pay attention to exit status from 'help' command - shell doc: emphasize purpose and security model Will merge to 'next'. * jk/read-commit-buffer-data-after-free (2013-02-11) 1 commit - log: re-encode commit messages before grepping Will merge to 'next'. * mk/old-expat (2013-02-11) 1 commit - Allow building with xmlparse.h Will merge to 'next'. * ef/non-ascii-parse-options-error-diag (2013-02-11) 1 commit - parse-options: report uncorrupted multi-byte options Will merge to 'next'. * jk/rebase-i-comment-char (2013-02-12) 1 commit - rebase -i: respect core.commentchar Will merge to 'next'. * mm/config-local-completion (2013-02-12) 1 commit - completion: support 'git config --local' Will merge to 'next'. -- [Stalled] * mp/diff-algo-config (2013-01-16) 3 commits - diff: Introduce --diff-algorithm command line option - config: Introduce diff.algorithm variable - git-completion.bash: Autocomplete --minimal and --histogram for git-diff Add diff.algorithm configuration so that the user does not type diff --histogram. Looking better; may want tests to protect it from future breakages, but otherwise it looks ready for 'next'. Expecting a follow-up to add tests. * mb/gitweb-highlight-link-target (2012-12-20) 1 commit - Highlight the link target line in Gitweb using CSS Expecting a reroll. $gmane/211935 * jk/lua-hackery (2012-10-07) 6 commits - pretty: fix up one-off format_commit_message calls - Minimum compilation fixup - Makefile: make lua a bit more configurable - add a lua pretty format - add basic lua infrastructure - pretty: make some commit-parsing helpers more public Interesting exercise. When we do this for real, we probably would want to wrap a commit to make it more like an object with methods like parents, etc. * rc/maint-complete-git-p4 (2012-09-24) 1 commit - Teach git-completion about git p4 Comment from Pete will need to be addressed ($gmane/206172). * jc/maint-name-rev (2012-09-17) 7 commits - describe --contains: use name-rev --algorithm=weight - name-rev --algorithm=weight: tests and documentation - name-rev --algorithm=weight: cache the computed weight in notes - name-rev --algorithm=weight: trivial optimization - name-rev: --algorithm option - name_rev: clarify the logic to assign a new tip-name to a commit - name-rev: lose unnecessary typedef git name-rev names the given revision based on a ref that can be reached in the smallest number of steps from the rev, but that is not useful when the caller wants to know which tag is the oldest one that contains the rev. This teaches a new mode to the command that uses the oldest ref among those which contain the rev. I am not sure if this is worth it; for one thing, even with the help from notes-cache, it seems to make the describe --contains even slower. Also the command will be unusably slow for a user who does not have a write access (hence unable to create or update the notes-cache). Stalled mostly due to lack of responses. * jc/xprm-generation (2012-09-14) 1 commit - test-generation: compute generation numbers and clock skews A toy to analyze how bad the clock skews are in histories of real world projects. Stalled mostly due to lack of responses. * jc/add-delete-default (2012-08-13) 1 commit - git add: notice removal of tracked paths by default git add dir/ updated modified files and added new files, but does not notice removed files, which may be Huh? to some users. They can of course use git add -A dir/, but why should they? Resurrected from graveyard, as I thought it was a worthwhile thing to do in the longer term. Stalled mostly due to lack of responses. * mb/remote-default-nn-origin (2012-07-11) 6 commits - Teach
jn/shell-disable-interactive (Re: What's cooking in git.git (Feb 2013, #05; Tue, 12))
Junio C Hamano wrote: * jn/shell-disable-interactive (2013-02-11) 2 commits - shell: pay attention to exit status from 'help' command - shell doc: emphasize purpose and security model Will merge to 'next'. Please hold off on merging the second patch. I'd like to reroll renaming the command to 'no-interactive-login' or some such, which would be less disruptive to existing setups and should be easier to explain. Thanks, Jonathan -- 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: jn/shell-disable-interactive (Re: What's cooking in git.git (Feb 2013, #05; Tue, 12))
Jonathan Nieder jrnie...@gmail.com writes: Junio C Hamano wrote: * jn/shell-disable-interactive (2013-02-11) 2 commits - shell: pay attention to exit status from 'help' command - shell doc: emphasize purpose and security model Will merge to 'next'. Please hold off on merging the second patch. I'd like to reroll renaming the command to 'no-interactive-login' or some such, which would be less disruptive to existing setups and should be easier to explain. Thanks; that sounds like a sensible and safer change. -- 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 (Feb 2013, #05; Tue, 12)
On 13 February 2013 11:06, Junio C Hamano gits...@pobox.com wrote: * jc/add-delete-default (2012-08-13) 1 commit - git add: notice removal of tracked paths by default git add dir/ updated modified files and added new files, but does not notice removed files, which may be Huh? to some users. They can of course use git add -A dir/, but why should they? Resurrected from graveyard, as I thought it was a worthwhile thing to do in the longer term. Stalled mostly due to lack of responses. What do you need to progress this? I have been bitten by this before (the 'huh?' reaction) and think the previous discussions and patch look reasonable. Does it need testing? Further input?? Regards, Andrew Ardill -- 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 (Feb 2013, #05; Tue, 12)
Andrew Ardill andrew.ard...@gmail.com writes: On 13 February 2013 11:06, Junio C Hamano gits...@pobox.com wrote: * jc/add-delete-default (2012-08-13) 1 commit - git add: notice removal of tracked paths by default git add dir/ updated modified files and added new files, but does not notice removed files, which may be Huh? to some users. They can of course use git add -A dir/, but why should they? Resurrected from graveyard, as I thought it was a worthwhile thing to do in the longer term. Stalled mostly due to lack of responses. What do you need to progress this? I have been bitten by this before (the 'huh?' reaction) and think the previous discussions and patch look reasonable. Does it need testing? I _think_ the code does what it claims it does; I do not think that is what is lacking (more testing would not _hurt_, of course). Further input?? The updated behaviour is a departure from the traditional norm, and it would surprise people who do not expect git add . to update the index for removed paths. For many of them, it may be a pleasant surprise, but many is not all. The change could negatively affect people who expect that removing files that are not used for their purpose (e.g. a large file that is unnecessary for their build) will _not_ affect what they get from git add .; obviously they must have trained themselves not to do git add -u or git commit -a. -- 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 (Feb 2013, #05; Tue, 12)
On 13 February 2013 11:34, Junio C Hamano gits...@pobox.com wrote: The change could negatively affect people who expect that removing files that are not used for their purpose (e.g. a large file that is unnecessary for their build) will _not_ affect what they get from git add .; How big a problem is this? If we need to support this behaviour than I would suppose a config option is required. A default config transition path similar to git push defaults would probably work well, in the case where breaking these expectations is unacceptable. obviously they must have trained themselves not to do git add -u or git commit -a. Many people use git add -p by default, so I would not be surprised about people not using -u or -a. Regards, Andrew Ardill -- 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
