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 wh
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
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 'subt
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
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 tha
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 d
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.
>
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.
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
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
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 b
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
>
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 pat
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
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
15 matches
Mail list logo
