libgit2 / libgit2/libgit2sharp

Repository.Checkout() doesn't unstage submodule changes

Open
#1,206 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
C#
Stars
3.5k
Forks
925
PR merge metrics
No merged PRs in 30d

Description

If I have a repo in this status

On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        modified:   App_Data/Submodule
        modified:   file.txt

with App_Data/Submodule being a git submodule and file.txt is just a normal file.

Running git checkout master --force will put the repo in this condition

On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   App_Data/Submodule (new commits)

no changes added to commit (use "git add" and/or "git commit -a")

but doing the same from LibGit2Sharp using the following code

using (var repo = new LibGit2Sharp.Repository(RepositoryPath))
{
  repo.Checkout("master", new CheckoutOptions { CheckoutModifiers = CheckoutModifiers.Force });
}

leaves the repo in this state

On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        modified:   App_Data/Submodule

Calling reset however works as expected.

using (var repo = new LibGit2Sharp.Repository(RepositoryPath))
{
    repo.Reset(ResetMode.Hard, "master");
}

Is that behavior expected from LibGit2Sharp? Should I be calling Reset myself if I want to mirror exactly the same git behavior?

ref: http://stackoverflow.com/q/33030355/3234163

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with Repository.Checkout and reproduce the shown staged-submodule scenario using CheckoutModifiers.Force. Compare its result with git checkout master --force and the existing Reset(ResetMode.Hard, "master") behavior; done means Checkout unstages the submodule change consistently with Git, or the difference is documented as expected.

Written by the indexing model from the issue text.

Assessment

Tech stack
csharp, git
Domain
tooling
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.