"Horst H. von Brand" <vonbrand@xxxxxxxxxxxx> writes:
> What are possible values of that variable? What happens if it is set/unset?
> I'd suppose that if it is set, you get the old format, but that isn't clear.
All are valid questions, but the release notes will be too long
if it made into "migration manual plus full documentation of new
features". Its purpose is to list things you would want to pay
attention to.
> ...
> I don't see an upgrade path here that doesn't involve keeping cruft "new
> feature is on" variables around indefinitely...
The new feature will be on regardless of the configuration at
some point, perhaps in GIT 2.0. For now it isn't, and that is
another reason the release notes do not have to (and probably
should not for the sake of brevity) talk about gory details to
turn the feature on. If we were to do the feature in
"incompatible by default" way, the release notes should talk
about how to turn it off and keep the old way.
>> - git-add tries to be more friendly to users by offering an
>> interactive mode.
>
> Why not tell about "git add -i"?
Thanks, will update. s/mode\.$/mode ("git-add -i")./
>> - After detaching your HEAD, you can go back to an existing
>> branch with usual "git checkout $branch". Also you can
>> start a new branch using "git checkout -b $newbranch".
>
> Where is such a branch rooted?
I did not think it needs to be mentioned as "git checkout -b
$newbranch" has always been "git checkout -b $newbranch HEAD"
and this is not changed with detached HEAD. Maybe I should add
"... to start a new branch at that commit" at the end of the
sentence. Thanks.
>> - You can even pull from other repositories, make merges and
>> commits while your HEAD is detached. Also you can use "git
>> reset" to jump to arbitrary commit.
>
> Does this leave you on that branch, or still in limbo?
Perhaps "s/\.$/, while still keeping your HEAD detached./".
Will update.
>> lose the current stat you arrived in these ways, and "git
>> checkout" refuses when the detached HEAD is not pointed by
>> any existing ref (an existing branch, a remote tracking
>> branch or a tag). This safety can be overriden with "git
>> checkout -f $branch".
>
> What happens if there are changes in the tracked files?
The answer is "just like normal checkout does", but I think that
level of detail does not belong to the release notes. The list
of features is meant to be just to introduce what new things
there are, and people interested should learn the details from
the documentation.
> A bit of detail on how to specify shallowness would be nice here...
The same comment as the above applies here.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html