Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report for Bug 1129 on
Developer Community or GitHub if you have new
information to add and do not yet see a matching new report.
If the latest results still closely match this report, you can use the
In special cases on GitHub you might also want the comments:
GitHub Markdown with public comments
I'd like to be able to commit parts of a file (line and hunk based staging, like git gui can do). This obviously makes it necessary for MD to use the git index properly.
Another advantage is that it's a way to store the selected files when reviewing changes - closing and reopening the "Review Changes" dialog will re-select all deselected files.
The way gitx allows staging lines and hunks is awesome. I usually use it reviewing and for committing.
See also bug 372 - git addin uses index inconsistently
I'll consider using the git index for everything, although this requires some important changes and right now there are other priorities. Here are some changes that need to be done in the Review Changes view:
* It can't support reviewing changes in a specific directory. The index is global, so all operations will have be done at solution (or repository root) level.
* We need api to support adding/removing files to the index, and link that to the commit checkbox we currently have in the changes list.
* Added/removed files will require special handling, since you can't arbitrarily select them in the index, they will always be included in the next commit.
(In reply to comment #2)
> * Added/removed files will require special handling, since you can't
> arbitrarily select them in the index, they will always be included in the next
What do you mean here? It is possible to commit parts of a new file too with git (or not commit them at all).
Let's say you add two new files to the index:
git add file1.cs
git add file2.cs
Is it possible to make a commit which includes the addition of file1.cs but not file2.cs?
git rm --cached file2.cs
will remove it from the index (but not from the file system).
That's not what I'm talking about. The current Review Changes view allows selecting what you want to commit. You may have for example a file modification and a file addition. You'll see both in the changes view. You can select the modification and only commit that. You can later select the addition and commit the addition. This can currently be done because the index is not being used, those are direct commits.
Now, if all commit operations are done through the index, whatever is in the index will be committed. For modified files that's not a problem, because you can stage/unstage modified files and that will not change the status of "file modified". But for file additions/removals that's different. For a file to be marked as added or removed, the file has to be in the index. If you unstage a file addition, you are effectively reverting the file addition. So on an index-based Review Changes view, you should not be able to unselect file additions/removals. You can of course Revert them but that's a different operation.
I'm not saying that's good or bad. I'm just exposing changes that will have to be done.
What does Revert mean for new files: remove from index or delete file completely?
Remove from the index. The file is not deleted.
The problem is that the addin's abusing the operation of "adding to the index" to make new files show up in the commit dialog. The correct way to do this is to list all unknown files, then the user can choose to stage them or not. That's what .gitignore's for.