magit-submodule-update:
Update the submodule of the current git repository
magit-submodule-update-init:
Update and init the submodule of the current git repository
magit-submodule-init:
Initialize the submodules
magit-submodule-sync
Synchronizes submodules' remote URL configurationDocs: F p to pull, not f f. Mention P p to push.
The (newer) "magit-log-oneline-re" regular expression was requiring
--graph, making the (older) magit-configure-have-graph logic
irrelevant: it had to return "true". Making --graph optional again is
not just fixing support for old git clients but also opening some log
possibilities, like removing the spurious star or showing tags in the
status view.
Amending a commit quite a common operation: Extend magit-log-edit to
accept prefix (C-u) to toggle amending.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
"Rebasing:" was the longest message, but the status bar wasn't aligned
before, now this:
Local: (detached) ~/g/git/
Head: c6b2a51 gettextize: git-clone "Cloning into" message
Rebasing: onto master (26 of 159); Press "R" to Abort, Skip, or Continue
Is aligned like this:
Local: (detached) ~/g/git/
Head: c6b2a51 gettextize: git-clone "Cloning into" message
Rebasing: onto master (26 of 159); Press "R" to Abort, Skip, or Continue
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Now it'll ask you:
Rebase in progress. [A]bort, [S]kip, or [C]ontinue?
The message didn't indicate how you made the selction before.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
The Head section already tells us what commit we're on. Now this looks
like this:
Local: (detached) ~/g/git/
Head: c6b2a51 gettextize: git-clone "Cloning into" message
Rebasing: onto master (26 of 159)
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Fix the bug in magit-rebase-info that I introduced in 81bb2ba. Here's
the description of the bug from a message of mine to the mailing list:
I sent an incomplete fix for the "R" rebase method recently:
http://github.com/philjackson/magit/pull/59
But Phil pulled it in as-is:
81bb2ba2d3
Anyway, it needs a small fixup, this:
(length (magit-file-lines ".git/rebase-merge/git-rebase-todo.backup"))
Will be way off, because it'll count the (length) of lines like:
("pick cb925f0 check message..." "pick 2f811b6 take done length"
"pick 29332e6 use backup" "" "# Rebase 19e2dd7..29332e6 onto 19e2dd7"
"#" ...
What it should do instead so we can get the correct count is to only
count up until the "" (uninclusive) so the above example would return
3.
I couldn't find an idiomatic way of doing this in elisp, I could with
the (loop) macro, but that'd require cl.el.
As it turns out magit already needs cl.el, so I can just use (loop) to
fix this.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
When using the native Windows emacs build (not a cygwin build), but a cygwin
build of 'make', then make fails because we send unix-style paths using CURDIR
to emacs. If instead we use (expand-file-name "."), then emacs does the magic
for us.
I looked around and found that org-mode's Makefile does exactly this. It seems
like the right thing to do.
Prompts are now fed to magit-completing-read in a form that makes them look
ok if magit-completing-read-function is set directly to completing-read or
a compatible function instead of a Magit-specific wrapper.
