Pushing new branches does not set up tracking branch completely

[Yogu]

When you push a local branch that does not exist on the remote (using the refspec overload), libgit2sharp automatically creates a tracking branch, but it does not set up the config for the local branch

i.e. the following config entries are missing:

branch.(branch_name).remote
branch.(branch_name).merge

Currently, I push a new branch like as follows:

string refspec = string.Format("{0}:{1}",
    currentBranch.CanonicalName, currentBranch.CanonicalName);
repo.Network.Push(remote, refspec, handler, credentials);
repo.Branches.Update(repo.Head, delegate(BranchUpdater updater)
{
    updater.Remote = remote.Name;
    updater.UpstreamBranch = repo.Head.CanonicalName;
});

I feel like this should be simplified. Either by doing the BranchUpdater stuff in Push(), or by extending the Push(Branch, ...) overload to let it accept non-tracking branches and do the whole process.

I also did not find a test fixture covering that feature, so the intended behaviour should at least be specified.

[dahlbyk]

Yeah, we don't support git push -u at the moment, but it seems reasonable that we would.

It may be about time to add PushOptions, as we've started doing elsewhere. At a glance, I'd say OnPushStateError and Credentials could live there, along with a new bool SetUpstream option.

[nulltoken]

This test by @yorah illustrates how to push a commit against a empty (and bare) repository.

I agree with @dahlbyk that that may make sense to provide a shortcut to dynamically configure the branch properties. Maybe should we also check that we don't overwrite an existing upstream configuration when performing this.

/cc @carlosmn @jamill Thoughts?

[carlosmn]

The push operation has nothing to do with setting up upstream configurations. git-core's push command optionally does set up the upstream configuration in addition to pushing.

If newer versions of git support a configuration variable to auto-set the upstream configuration, then it would make sense to follow it, but we can't have the library arbitrarily setting upstreams. If the bindings want to add an option, I guess that would be ok, as well.

[Yogu]

This test by @yorah illustrates how to push a commit against a empty (and bare) repository.

Ah, that's better. I did not think of configuring first, to be able to push the branch normally. Thanks!

[jamill]

I think LibGit2Sharp would be a reasonable layer to support this functionality (as an optional behavior, not enabled by default). I also agree with @dahlbyk with moving the API to use PushOptions - as I believe we will have some more callbacks to include as well, when libgit2/libgit2#1412 lands.

[nulltoken]

Let's make this happen, then!

Labeled as Up for grabs :wink:

[ethomson]

This is indeed reasonable, but it seems like an API addition and not something that we explicitly need for a stable API.

[wilkovanderveen]

I know this topic is from 9 years ago. But is this fixed?

[Lapeno94]

Hey @wilkovanderveen,

There is a workaround how to solve this.

`

       var pushOptions = new PushOptions
        {
            CredentialsProvider = (_, _, _) =>
                new UsernamePasswordCredentials()
                {
                    Username = yourUsername,
                    Password =yourPassword
                }
        };
        
       // branch -> your local branch which are you working on name: feature/foo/bar
       // trackedBranchName -> refs/remotes/origin/feature/foo/bar
       
        repository.Network.Push(repository.Network.Remotes["origin"], branch.CanonicalName, trackedBranchName, 
            pushOptions);
            
       // update branch references
        repository.Branches.Update(repository.Head, updater =>
        {
            updater.Remote = repository.Network.Remotes["origin"].Name;
            updater.UpstreamBranch = repository.Head.CanonicalName;
        });
        // push to the server
        repository.Network.Push(repository.Branches[branchName], pushOptions);`