After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 698633 - can't run 'git commit' with no filename
can't run 'git commit' with no filename
Status: RESOLVED OBSOLETE
Product: meld
Classification: Other
Component: version
git master
Other Linux
: Normal normal
: ---
Assigned To: meld-maint
meld-maint
Depends on:
Blocks:
 
 
Reported: 2013-04-23 06:05 UTC by Adam Dingle
Modified: 2017-12-13 19:02 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Adam Dingle 2013-04-23 06:05:51 UTC
Currently if I right click the root of a local repository and select Commit, Meld runs 'git commit .'  Usually that works to commit all outstanding changes, but when a cherry-pick is in progress it fails:

fatal: cannot do a partial commit during a cherry-pick.
Exit code: 128

In this situation only a 'git commit' with no filename will work.  I think Meld should run a simple 'git commit' if the user commits when the top-level directory is selected or if nothing is selected at all.

This is similar to bug 698564, by the way.
Comment 1 Adam Dingle 2013-04-27 18:44:34 UTC
Also, in this situation the Commit dialog currently lists the directory itself as the only file to be committed.  Instead, it would be nicer if the Commit Files area listed all individual files to be committed.
Comment 2 Kai Willadsen 2013-04-28 21:18:54 UTC
I think this behaviour is a bit of a hack, but I can't come up with a better option that can be easily implemented, so sure. Aside from poor discoverability, the big problem is that this won't work at all when doing a VC comparison on a subdirectory, and in that case we shouldn't do a blanket commit. Essentially, this will have to end up as 'if vc.location == vc.root: <naked commit call>'.

The better solution (though still with no design, let alone implementation) would be to add index support (see bug 619559).

I've filed your second comment as bug 699182.
Comment 3 Adam Dingle 2013-04-28 21:26:51 UTC
I agree this is not super discoverable, but I think it makes sense in a way, and in any case I think it's the best easy option before us.  I stay let's go with it for now.  If it turns out to be confusing to users or has edge cases we haven't anticipated we can always reconsider.
Comment 4 Kai Willadsen 2013-05-03 22:06:54 UTC
I just realised that there's no way we can make this change. 'git commit .' at the top level is our equivalent of 'git commit -a', and I really can't take that support away.

The only reasonable option here (other than full-on index support) would be if we could check for an in-progress cherry-pick on a top-level commit, and change the command at that point. I haven't figured out how to do this yet.
Comment 5 GNOME Infrastructure Team 2017-12-13 19:02:31 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/meld/issues/52.