Hi Duy,
On Tue, 15 Mar 2016, Duy Nguyen wrote:
> On Tue, Mar 15, 2016 at 3:54 AM, Johannes Schindelin
> wrote:
> > In my 'interactive-rebase' branch...
>
> 64 commits! Maybe next time we should announce wip branches like this
> when we start doing stuff so people don't overlap. Of course these
Hi Junio,
On Mon, 14 Mar 2016, Junio C Hamano wrote:
> If the [has_uncommitted_changes()] function will be made a public helper
> that may be called by anybody, a possible error reporting mechanism
> would be to give a list of modified paths to the caller that asks them,
> and have the caller app
On Tue, Mar 15, 2016 at 3:54 AM, Johannes Schindelin
wrote:
> In my 'interactive-rebase' branch...
64 commits! Maybe next time we should announce wip branches like this
when we start doing stuff so people don't overlap. Of course these
branches do not have to be perfect (and can be force pushed f
Johannes Schindelin writes:
> Also, you might want to join my discussion with Junio about the sense or
> nonsense of keeping the prefix parameter instead of silently removing it
> while moving the functions.
This is a tangent to Paul's topic, but it is an important tangent in
the other thread, i
Hi Paul,
On Sat, 12 Mar 2016, Paul Tan wrote:
> In the upcoming git-rebase-to-C rewrite, it is a common operation to
> check if the worktree has unstaged changes, so that it can complain that
> the worktree is dirty.
>
> builtin/pull.c already implements this function. Move it to
> rebase-common
In the upcoming git-rebase-to-C rewrite, it is a common operation to
check if the worktree has unstaged changes, so that it can complain that
the worktree is dirty.
builtin/pull.c already implements this function. Move it to
rebase-common.c so that it can be shared between all rebase backends and
6 matches
Mail list logo
