Why does it say Unmerged changes and not Unpushed changes?

[Dich0tomy]

Hello, the last time I used neogit was a long time ago and commits that have not been pushed yet were under the Unmerged changes "category", after that I moved to fugitive which rightfully puts such commits under Unpushed to <remote> category.

I saw that neogit saw a really big update so I gave it another try (and I'm not disappointed, quite the opposite, massive piece of work, congrats!), but it still says Unmerged.

Is there a reason for such naming? I'm not a git expert, so I may not exactly understand why such a name was chosen, but I don't think it's just an overlook, especially since it's quite visible and often seen.

[ten3roberts]

It is because they have not been "Merged" into origin/master.

It is technically possible to set a branch's upstream to a local branch, at which point it is more correct of "commits not merged into other_branch", as you are not really pushing to a local branch, though I think very few people do local only feature branches like that. I agree that perhaps Unpushed is a better description and holds for most cases

[CKolkey]

It's also because we're using the Magit nomenclature, which uses "unmerged" :)

^^ Thats from Magit

[Dich0tomy]

Thanks for the answer.

Btw. are there any plans for a shortcut for manipulating .gitignore and .git/info/exclude?

Fugitive had those and they are extremely useful, especially the second one (info/exclude is a file which acts as .gitignore, but it's even more local, as it's an internal part of the repository and doesn't get pushed anyway, like .gitignore).

If not, I'd be happy to contribute.

[CKolkey]

Here's the ignore popup from Magit:

Those actions open up a fuzzy-finder like so:

Those patterns are built off two untracked files currently in in the repo: profile.log and profile.svg

It's bound to i :)

You don't need to do the fuzzy-finder bit, that can come later. Just wanted to share it.

Feel free to ask any questions if you have any! PR's are most welcome

[Dich0tomy]

Really cool, thanks for the insights. I most certainly won't have time to work on this today, but I'll probably start tommorow. I'll make sure to ask questions if I'll need to :p Thanks.

[CKolkey]

No worries or rush - thanks for taking this on :D

[Dich0tomy]

Okay, I actually took a lot more time to look into this than I wanted to, but I'm finally starting to implement this feature.

My question is - wouldn't it be better to make ignore work the same way stage works? Ignoring:

• One file: i(t/s/p/g)
• Several files: Vjjji(t/s/p/g)
• Whole section: <Cursor on section>i(t/s/p/g)

Instead of relying on the fuzzy finder?

Also what about files that have been pushed already or staged. Do we issue a warning or do we let the user decide silently (which can lead to "Why isn't my file ignored properly" issues later)?

[CKolkey]

Great questions.

The way magit does it is sort of a halfway between what you're describing, and full fuzzy-finding for all files. The options to select in the fuzzy finder are the files currently in the index that are untracked, and some permutations on them (see above screenshot). I think that flexibility is quite nice, since it lets you quickly add patterns to the ignore file, as well as just the filepaths. If a user wants to add a file not in the fuzzy finder, we need a way to just accept the input as-is, even though nothing matches, because thats the filepath they want to ignore.

That said, It would be quite cool to support Vjjji(...) too! Check out the revert or cherry-pick popups, since thats how they work too. If thats the case, we can skip the fuzzy finder (just like the cherry pick popup) and use the selections).

Drawing from that, if a user manually enters an already-tracked file, they had to go out of their way to do so, so I don't think a warning is in order.