Re: What's cooking in git.git (Feb 2013, #05; Tue, 12)
Miles Bader writes: > Junio C Hamano 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 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)
Junio C Hamano 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)
Junio C Hamano writes: > Andrew Ardill 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 " 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 " 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 " 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 " without "-u", "-A" nor "--ignore-removal" to behave as if "git add -A " 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 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)
On 14 February 2013 15:36, Junio C Hamano 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
Re: What's cooking in git.git (Feb 2013, #05; Tue, 12)
Andrew Ardill 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 02:27, Junio C Hamano 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 writes: > On 13 February 2013 11:34, Junio C Hamano 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 13 February 2013 11:34, Junio C Hamano 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
Re: What's cooking in git.git (Feb 2013, #05; Tue, 12)
Andrew Ardill writes: > On 13 February 2013 11:06, Junio C Hamano 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:06, Junio C Hamano 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: jn/shell-disable-interactive (Re: What's cooking in git.git (Feb 2013, #05; Tue, 12))
Jonathan Nieder 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
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
