use cl-do instead of do #567

wants to merge 60 commits into from

4 participants

Magit member

Sorry, I misses that one.

sigma and others added some commits Jun 16, 2012
@sigma sigma Merge branch 'master' into next 3b17726
@sigma sigma Merge branch 'master' into next d2ae189
@sigma sigma Merge branch 'master' into next e8d5e31
@sigma sigma Merge branch 'master' into next 6d7d8ef
@sigma sigma Merge branch 'master' into next 839f575
@sigma sigma Merge branch 'master' into next 9f8e88e
@tarsius tarsius magit-push: only push to branch.b.merge when pushing to branch.b.remote
The branch specified by the former is only meaningful when pushing to
the remote specified by the latter.  When pushing to another remote
and the remote branch is not specified explicitly then pusing to the
remote branch with the same name as the local branch being pushed is
much more reasonable than pushing to branch.b.merge which could be
anything.  This is also how "git push <remote> <branch>" behaves.
@tarsius tarsius always respect value of magit-set-upstream-on-push
Previously both branch.<name>.remote and branch.<name>.merge where set
under certain conditions ignoring the value of magit-set-upstream-on-push:
when both branch.<name>.remote and remote.origin.url are unset
branch.<name>.remote was always set.  When additionally no prefix argument
is used branch.<name>.merge was also set ignoring the value of
@tarsius tarsius magit-builtin-completing-read: handle REQUIRE-MATCH safely
completing-read does allow the user to exit with null input, leaving
it to the caller to handle that case.  Possible options would be to
use some default value or raise an error.

Since magit-builtin-completing-read is a convenience wrapper for
completing-read it seems reasonable to do the latter here so that not
every caller of magit-completing-read has to do this on it's own.

A similar change is not required for magit-iswitchb-completing-read
and magit-ido-completing-read; they already don't allow the user to
exit with a null value.
@tarsius tarsius magit-read-remote: require that an existing remote is selected
All current uses of magit-read-remote actually require a remote to
be returned as the behaviour of nil being returned is not defined.
E.g. magit-push would try to push to a remote with the name "nil".

It would be better to give magit-read-remote a REQUIRE-MATCH argument
but since all callers expect a match this is not strictly unnecessary
at the moment.  Also some other magit-read-* functions could benefit
from a similar change.
@tarsius tarsius magit-push: ensure we are pushing to a branch
Do this by always using the full ref instead of just the name for
the remote branch.  Without this we could end pushing to some other
non-branch ref if no branch by the specified name exists remotely
but some other ref by that name does.
@tarsius tarsius magit-push: set branch.<name>.merge correctly
The backward compatibility hack that ensured that branch.<name>.merge
was set even when using an old version of git used the wrong local
variable.  In many cases that variable contains the correct value but
this does not have to be the case.  More specifically it always used
the same ref as the ref of the local branch.  When the user selected
another branch name that obviously is not correct.  So this kludge for
older git versions could actually harm users of recent versions.
@tarsius tarsius magit-push: do not use magit-get-remote to get the branch-remote
The meaning of "branch-remote" is "the remote configured for branch"
but if no remote is configured magit-get-remote might return "origin"
instead.  This is wrong here because we later use the value of
branch-remote to determine if we we should push to branch.<name>.merge
or just <name>.

So this ensures that we do the right thing when branch.<name>.merge is
set but branch.<name>.remote is not.
@tarsius tarsius magit-push: update doc-string to reflect recent changes
Actually this new doc-string - for the bigger part - would have been
correct even before these changes since most of them are actually
bugfixes.  So the new doc-string wouldn't have been more wrong than
the old one :-)

No longer say that in certain cases something "hairy" is done when
that behaviour is well defined in git-push(1) and also reasonable.
Instead explicitly say what is done (pushing to the remote branch
with the same name as the local branch) and under what conditions.

I think the new doc-string is much easier to understand.  For better
readability I removed the instructions how prefix arguments are used;
the user has to get that knowledge elsewhere.  Not every command that
supports prefix arguments documents that basics of their use; why
should this one be different?
@tarsius tarsius magit-push: set branch.<name>.merge when -u is in magit-custom-options
When --set-upstream is set through magit-key-mode use the same
backward compatibility hack to ensure branch.<name>.merge is set
even when using an old git version as is used when --set-upstream
is used due to the value of the magit-set-upstream-on-push option.
@tarsius tarsius magit-push-tags: allow selecting the remote 70366ca
@sigma sigma fix call to magit-read-remote 5b37565
@sigma sigma Merge branch 'tarsius/push-fixes' into next 9168299
@sigma sigma Merge branch 'master' into next 8f35426
@tarsius tarsius magit-run*: only magit-mode buffers need to be refreshed
Refreshing means that point moves to the beginning of the line which
is not desirable for non-magit-mode buffers.  This fixes issue #441.
@tarsius tarsius magit-run*: only advertise key for *magit-process* if there is one 80f5f95
@sigma sigma Merge branch 'master' into next bcdea56
@sigma sigma Merge commit 'beae52bc6e21da0e74b4e4eaba339248981bb77b' into next 648f811
@sigma sigma Merge commit '80f5f9597e3801acd14742dd747f2d77cb33e273' into next 42bb20f
@artagnon artagnon magit-key-mode: don't delete other windows to show menu
Signed-off-by: Ramkumar Ramachandra <>
@sigma sigma Merge branch 'master' into next 7f25553
@sigma sigma Merge commit '3b590e01ba51f6453ec07e3da4bcb180933f2e6a' into artagnon…
@sigma sigma Merge branch 'artagnon/magit-key-mode' into next 5167400
@sigma sigma Merge branch 'master' into next bfe5721
@sigma sigma Merge branch 'master' into next 4d03353
@vanicat vanicat Merge branch 'mainline-master' into mainline-next 0a2f985
@vanicat vanicat Merge branch 'mainline-master' into mainline-next b051a92
@vanicat vanicat Merge branch 'master' into next 5f1d812
@sigma sigma Merge branch 'master' into next 3325f4b
@sigma sigma Merge branch 'master' into next a83f865
@sigma sigma Merge branch 'master' into next 340aead
@sigma sigma Merge branch 'master' into next f3b4fd2
@sigma sigma Merge branch 'master' into next 8bfb7c1
@sigma sigma Merge branch 'master' into next 3237c38
@sigma sigma Merge branch 'master' into next ebba349
@sigma sigma Merge branch 'master' into next a127fd3
@sigma sigma Merge branch 'master' into next a32a021
@sigma sigma Merge branch 'master' into next 4a2cc80
@sigma sigma Merge branch 'master' into next cff6630
@tarsius tarsius magit-section-context-type: de-uglify 5081e87
@tarsius tarsius magit-prefix-p: improve doc-string
The old doc-string wasn't very precise, e.g. it left out that `equal'
is used for comparison.

Also rename arguments;  It just doesn't feel right to say.

  PREFIX is a prefix ... if ...

The hole point of this function is to check whether the first list is
a prefix of the second.  It might very well not be, so let's just call
it a list.
@tarsius tarsius add new function magit-section-match e36af46
@tarsius tarsius refactor magit-section-case and related functions
`magit-section-case' used to return t if a clause succeeds but the
value of it's body is nil.  This was due to internal needs; it allowed
`run-hook-with-args-until-sucess' to detect that a clause and therefor
the hook function succeeded.  However, while it was documented in the
doc-string, callers should not have to deal with this.

* `magit-section-case' and `magit-section-action' always return
  the value of the BODY now.  In other words they can return nil.
* `magit-section-case' doesn't need to know about OPCODE.
  Running the OPCODE hook is done in `magit-section-action' now.
* `magit-add-section' wrap each BODY so that `magit-section-action'
  can detect whether a CLAUSE succeeded.  Previously that was done
  in `magit-section-case' for *any* CLAUSE.
* Disallow a t/otherwise CLAUSE in `magit-section-action' as that
  would prevent the OPCODE hook from running.
* Replace uses of `magit-section-action' without OPCODE to use
  `magit-section-case' instead.
@tarsius tarsius rename magit-add-action{ => -clauses} 7cd08d0
@sigma sigma Merge branch 'tarsius/section-case' into next b266fa3
@sigma sigma Merge branch 'master' into next 25b9b6e
@sigma sigma Merge branch 'master' into next 1d3aa45
@sigma sigma Merge branch 'master' into next dff002c
@sigma sigma Merge branch 'master' into next e470cc3
@tarsius tarsius use cl- prefixed symbols from cl-lib.el
instead of the prefix-less variants from cl.el

@tarsius tarsius don't use cl-flet
The forward-compatibility cl-lib does not define it.  Instead use let
and funcall (2x) or refactor so that tempory overriding function
definitions are not needed (1x).
@tarsius tarsius require cl-lib at runtime, suppress warnings
Suppress the "cl package called at runtime" warning in Emacsen before
24.3, using `with-no-warnings`.  When doing that would me more hideous
than replace the cl function with a non-cl replacment, then do the
@sigma sigma Merge branch 'master' into next 971929f
@sigma sigma Merge branch 'tarsius/cl-lib' into next
@tarsius tarsius use cl-do instead of do 232df41
Magit member

wrong branch

@tarsius tarsius closed this Feb 22, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment