Re: [PATCH/RFC/GSoC 09/17] rebase-common: implement cache_has_unstaged_changes()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.c so that it can be shared between all rebase backends and
> git-pull.

This function is not specific to rebases, even if you only use it for
those purposes for the moment.

In my 'interactive-rebase' branch, I moved it to wt-status (which is a
more logical place, methinks).

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.

Furthermore, it is not really the cache (which I thought we settled on
calling "index" these days) that has unstaged changes, but the working
directory.

For simplicity's sake, I therefore kept the has_unstaged_changes() name
(it is not like there is a lot of confusion *what* can have unstaged
changes).

Ciao,
Johannes
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]