Change URL of and rename remote

[mbunkus]

With the integration of managing remotes from the branch manager window a lot of functionality that I'm pretty sure existed before has been dropped, which is unfortunate. Amongst them:

• renaming a remote
• pruning a remote
• changing the remote's URL

[mbunkus]

More functions that were available include:

• fetching from the remote at point. f shows the standard fetch menu in which I have to select other and then enter the name if I want to fetch a different remote than the one that the current branch tracks.

[dudebout]

I am not sure what you are referring to. Can you give me a commit where things were working the way you like and the keys you were using at that time.

BTW, renaming a remote is done by typing r on the remote.

Apart from changing the remote's URL, the other functionalities are only a few keystrokes away:

• fetching from the remote at point is f o <return> since autocompletion looks at the current remote
• pruning is accordinly f -p o <return>

[mbunkus]

I have two goals in mind: consistency and efficient usage (not efficient runtime behavior).

Meh, sorry for the noise. In January 2011 I wrote my own implementation of a remote manager for magit which wasn't merged into the official repository. It could not do all the current integrated branches/remotes manager can do, but it could:

• fetch the remote at point with a single key stroke; see below for further discussion
• prune remote at point (yes I know about "f -p o ", same discussion from below this list applies)
• deleting, adding, renaming remotes (can be done with current implementation as well)
• show remotes (git remote show name)
• change the URL of a remote

About fetching and pruning. Yes I know about "f o ", however, as I've argued in #340, having most commands that can sensibly work differently depending on where point is should indeed operate on point with a single keystroke. It has bitten me yet again, and I consider myself to be an advanced user of magit. Us telling all the users that "the functions always work depending on where point is!" is simply not true for "f" in the branches/remotes buffer, and here having "f" work differently on where point is actually makes a LOT of sense.

Example what I would consider a sensible implementation for fetching:

• if point is on a remote
• if point is on a branch in a remote then fetch the remote; if the branch has been removed from the remote then tell the user so and ask whether or not he wants to prune the remote
• if the point is on a local branch then fetch the remote this local branch tracks if it tracks one, otherwise signal an error

Then map the fetch popup window to something else, e.g. "F". Or leave "f" the way it is and implement the stuff from above with "F".

For pruning a key could be available that prunes the remote at point if point is on a remote or a remote branch.

I'd also like to see the option to change the remote's URL including immediately fetching the remote afterwards (maybe asking the user whether or not he wants to fetch).

So this ticket is about three things: fetching thingy at point, pruning thingy at point, changing the URL at point and fetching. The first two are about consistency ("magit always does things depending on point"), the last one is about efficiency.

[dudebout]

magit as it is is consistent. However, I agree that we could do better. Currently, the command f consistently works on the remote associated with the current branch. You would like it to work with the point instead. I think it would be a saner default.

I would suggest you implement it as follows. We already have a command similar to f which is F (for pull). We could put together pulling and fetching the current branch under the letter F. We would have F F for git pull and F f for git fetch. Then you can reuse f to only work with the point. f would fetch the remote at point (which already includes the case where the point is on a branch in a remote). We could then have an option magit-prune-when-fetching with values always, never, and ask. C-u f would be doing the opposite of the option (and no effect for ask for example). We could then use U (for update) to fetch all.

For modifying the url at point, the key u is undefined in the branch manager and would be a perfect candidate to put such a functionality. Another option (magit-fetch-when-changing-url) with similar values would be good in that setting too.

Trying to put more functionalities on the keys raises, in my opinion, other questions of consistency. It would be nice to know that, for example, uppercase keys are global and affect the current branch while lowercase work with the point.

[tarsius]

Close in favor of #1321.