Re: [PATCH 4/7] submodule update --init: correct path handling in recursive submodules

Stefan Beller writes: > This fixes the test introduced by the parent commit. > > Signed-off-by: Stefan Beller Unlike 2/7, this is kinda on the thin side in the explanation department, it looks. > --- > git-submodule.sh| 5 +++-- >

Re: [PATCH 3/7] submodule update --init: test path handling in recursive submodules

Stefan Beller writes: > @@ -95,6 +99,35 @@ test_expect_success 'submodule update from subdirectory' ' > ) > ' > > +supersha1=$(cd super && git rev-parse HEAD) "supersha1=$(git -C super rev-parse HEAD)" perhaps? > +cat +Submodule path '../super': checked

Re: [PATCH 2/7] submodule foreach: correct path computation in recursive submodules

Stefan Beller writes: > The test which is fixed by this patch would report > Entering 'nested1/nested2/../nested3' > instead of the expected > Entering '../nested1/nested2/nested3' > > because the prefix is put unconditionally in front and after that a > computed

Re: [GSoC] A late proposal: a modern send-email

2016-03-29 0:49 GMT+08:00 Ævar Arnfjörð Bjarmason : > On Sat, Mar 26, 2016 at 3:13 AM, 惠轶群 wrote: >> 2016-03-26 2:16 GMT+08:00 Junio C Hamano : >>> 惠轶群 writes: >>> # Purpose The current implementation of

Re: [PATCH v2 08/17] read-cache: invalidate untracked cache data when reading WAMA

On Sat, Mar 19, 2016 at 8:04 AM, David Turner wrote: > @@ -1407,10 +1472,24 @@ static int read_watchman_ext(struct index_state > *istate, const void *data, > ewah_each_bit(bitmap, mark_no_watchman, istate); > ewah_free(bitmap); > > - /* > -

Re: [PATCH v2] path.c enter_repo(): fix unproper strbuf unwrapping and memory leakage

2016-03-29 1:55 GMT+08:00 Jeff King : > On Mon, Mar 28, 2016 at 11:56:10PM +0800, Hui Yiqun wrote: > >> According to strbuf.h, strbuf_detach is the sole supported method >> to unwrap a memory buffer from its strbuf shell. >> >> So we should not return the pointer of strbuf.buf

Re: [PATCH v3] path.c enter_repo(): fix unproper strbuf unwrapping and memory leakage

2016-03-29 1:58 GMT+08:00 Junio C Hamano : > Hui Yiqun writes: > >> According to strbuf.h, strbuf_detach is the sole supported method >> to unwrap a memory buffer from its strbuf shell. >> ... >> diff --git a/path.c b/path.c >> index 969b494..9801617 100644

Re: [PATCH v2 06/17] index-helper: add --detach

On Sat, Mar 19, 2016 at 8:04 AM, David Turner wrote: > @@ -237,6 +239,7 @@ int main(int argc, char **argv) > N_("exit if not used after some seconds")), > OPT_BOOL(0, "strict", _verify, > "verify shared

Re: [PATCH v2 03/17] index-helper: new daemon for caching index and related stuff

On Sat, Mar 19, 2016 at 8:04 AM, David Turner wrote: > From: Nguyễn Thái Ngọc Duy > > Instead of reading the index from disk and worrying about disk > corruption, the index is cached in memory (memory bit-flips happen > too, but hopefully less often).

Re: [PATCH v3 1/2] refs: add a new function set_worktree_head_symref

On Mon, 2016-03-28 at 10:48 -0700, Junio C Hamano wrote: > Kazuki Yamaguchi writes: > > > Add a new function set_worktree_head_symref, to update HEAD symref > > for > > the specified worktree. > > > > To update HEAD of a linked working tree, > >

weird diff output?

On Mon, Mar 28, 2016 at 4:28 PM, Stefan Beller wrote: > cat > expect < +Entering '../nested1' > +Entering '../nested1/nested2' > +Entering '../nested1/nested2/nested3' > +Entering '../nested1/nested2/nested3/submodule' > +Entering '../sub1' > +Entering '../sub2' > +Entering

Re: Gitk "External diff" broken when using worktree

I've done that, and here are the two arguments that it gives to the diff tool: >From the main repository (in which case the it works): .git/.gitk-tmp.CCxPmN/1/[1980e260494cbd225d482b5d962e77bdcdb2321c] RemoteTransaction.C .git/.gitk-tmp.CCxPmN/1/[2759bf6053e73cb5f7c11c646aee206242db2cd4]

[PATCH 6/7] submodule status: test path handling in recursive submodules

This replicates the previous test except that it executes from a sub directory. Document the expected outcome, which currently fails by having too many '../' prefixed. Signed-off-by: Stefan Beller --- t/t7407-submodule-foreach.sh | 19 +++ 1 file changed, 19

[PATCH 5/7] t7407: make expectation as clear as possible

Not everyone (including me) grasps the sed expression in a split second as they would grasp the 4 lines printed as is. Signed-off-by: Stefan Beller --- t/t7407-submodule-foreach.sh | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git

[PATCH 7/7] submodule status: fix path handling in recursive submodules

This fixes the test which was introduced in the parent commit. Signed-off-by: Stefan Beller --- git-submodule.sh | 1 + t/t7407-submodule-foreach.sh | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/git-submodule.sh b/git-submodule.sh index

[PATCH 4/7] submodule update --init: correct path handling in recursive submodules

This fixes the test introduced by the parent commit. Signed-off-by: Stefan Beller --- git-submodule.sh| 5 +++-- t/t7406-submodule-update.sh | 2 +- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/git-submodule.sh b/git-submodule.sh index

[PATCH 2/7] submodule foreach: correct path computation in recursive submodules

The test which is fixed by this patch would report Entering 'nested1/nested2/../nested3' instead of the expected Entering '../nested1/nested2/nested3' because the prefix is put unconditionally in front and after that a computed display path with is affected by `wt_prefix`. This is wrong

[PATCH 1/7] submodule foreach: test path handling in recursive submodules

This replicates the previous test with the difference of executing from a sub directory. By executing from a sub directory all we would expect all paths to be prefixed by '../'. Document this as failure in this patch, to be fixed in a later patch. Signed-off-by: Stefan Beller

[PATCH 0/7] Fix path bugs in submodule commands executed from sub dir [WAS: submodule--helper clone: lose the extra prefix option]

Junio wrote: > I suspect that the fix in your 1&2 may be demonstratable without > forcing an early failure by switching to "git -C". So for now I present test coverage and their minimal fixes. This series follows a "tick-tock" pattern except for patch5, which I wrote quickly as I was annoying by

[PATCH 3/7] submodule update --init: test path handling in recursive submodules

This demonstrates a failure to handle paths correctly. Instead of getting the expected Submodule 'submodule' (${pwd}/submodule) registered for path '../super/submodule' the `super` directory is omitted and you get Submodule 'submodule' (${pwd}/submodule) registered for path '../submodule'

Re: Warning about conflict markers - undocumented 'diff --check' feature & suggestion

Ori Avtalion writes: > A bug report and a suggestion: > > `git diff --check` has been warning about conflict markers since 2008: > https://marc.info/?l=git=122398500726634=2 > > This is an undocumented feature. The current documentation for the > flag only mentions

[PATCH v2 07/11] rerere: do use multiple variants

This enables the multiple-variant support for real. Multiple conflicts of the same shape can have differences in contexts where they appear, interfering the replaying of recorded resolution of one conflict to another, and in such a case, their resolutions are recorded as different variants under

[PATCH v2 11/11] rerere: adjust 'forget' to multi-variant world order

Because conflicts with the same contents inside conflict blocks enclosed by "<<<" and ">>>" can now have multiple variants to help three-way merge to adjust to the differences outside the conflict blocks, "rerere forget $path" needs to be taught that there may be multiple recorded

[PATCH v2 10/11] rerere: split code to call ll_merge() further

The merge() helper function is given an existing rerere ID (i.e. the name of the .git/rr-cache/* subdirectory, and the variant number) that identifies one pair, try to see if the conflicted state in the given path can be resolved by using the pair, and if this succeeds, then

Warning about conflict markers - undocumented 'diff --check' feature & suggestion

A bug report and a suggestion: `git diff --check` has been warning about conflict markers since 2008: https://marc.info/?l=git=122398500726634=2 This is an undocumented feature. The current documentation for the flag only mentions "whitespace errors". This check will also be useful in `git

[PATCH v2 05/11] rerere: allow multiple variants to exist

The shape of the conflict in a path determines the conflict ID. The preimage and postimage pair that was recorded for the conflict ID previously may or may not replay well for the conflict we just saw. Currently, we punt when the previous resolution does not cleanly replay, but ideally we should

[PATCH v2 08/11] rerere: gc and clear

Adjust "git rerere gc" and "git rerere clear" to the new world order with rerere database with multiple variants for the same shape of conflicts. Signed-off-by: Junio C Hamano --- * New in v2; a preview appeared on $gmane/288454 rerere.c | 87

[PATCH v2 03/11] rerere: handle leftover rr-cache/$ID directory and postimage files

If by some accident there is only $GIT_DIR/rr-cache/$ID directory existed, we wouldn't have recorded a preimage for a conflict that is newly encountered, which would mean after a manual resolution, we wouldn't have recorded it by storing the postimage, because the logic used to be "if there is no

[PATCH v2 02/11] rerere: scan $GIT_DIR/rr-cache/$ID when instantiating a rerere_id

This will help fixing bootstrap corner-case issues, e.g. having an empty $GIT_DIR/rr-cache/$ID directory would fail to record a preimage, in later changes in this series. Signed-off-by: Junio C Hamano --- * Unchanged. rerere.c | 32 +--- 1 file

[PATCH v2 04/11] rerere: delay the recording of preimage

We record the preimage only when there is no directory to record the conflict we encountered, i.e. when $GIT_DIR/rr-cache/$ID does not exist. As the plan is to allow multiple pairs as variants for the same conflict ID eventually, this logic needs to go. As the first step in

[PATCH v2 06/11] t4200: rerere a merge with two identical conflicts

When the context of multiple identical conflicts are different, two seemingly the same conflict resolution cannot be safely applied. In such a case, at least we should be able to record these two resolutions separately in the rerere database, and reuse them when we see the same conflict later.

[PATCH v2 09/11] rerere: move code related to "forget" together

"rerere forget" is the only user of handle_cache() helper, which in turn is the only user of rerere_io that reads from an in-core buffer whose getline method is implemented as rerere_mem_getline(). Gather them together. Signed-off-by: Junio C Hamano --- * New in v2.

[ANNOUNCE] Git v2.8.0

The latest feature release Git v2.8.0 is now available at the usual places. It is comprised of 532 non-merge commits since v2.7.0, contributed by 74 people, 22 of which are new faces. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/ The following public repositories

[PATCH v2 00/11] saving and replaying multiple variants with rerere

Take two after several months. That is what you get when you end up running a busy project, instead of staying to be an individual contributor ;-). The previous round starts at the message this is a response to and is found at http://thread.gmane.org/gmane.comp.version-control.git/277878 The

A note from the maintainer

Welcome to the Git development community. This message is written by the maintainer and talks about how Git project is managed, and how you can work with it. * Mailing list and the community The development is primarily done on the Git mailing list. Help requests, feature proposals, bug reports

[PATCH v2 01/11] rerere: split conflict ID further

The plan is to keep assigning the backward compatible conflict ID based on the hash of the (normalized) text of conflicts, keep using that conflict ID as the directory name under $GIT_DIR/rr-cache/, but allow each conflicted path to use a separate "variant" to record resolutions, i.e. having more

Re: pre-push hook does not get input on non-fast-forward pushes

On Mon, 28 Mar 2016 14:44:20 -0700 Junio C Hamano wrote: > Stefan Tauner writes: > > The pre-push hook is not the only thing that may prevent you from > pushing a ref update. As you noticed, non-fast-forward check may > trigger and decide

Re: pre-push hook does not get input on non-fast-forward pushes

On Mon, Mar 28, 2016 at 2:44 PM, Junio C Hamano wrote: > Stefan Tauner writes: > >> I noticed that without an additional --force the pre-push hook does not >> get any input on stdin if a push would result in non-fast-forward >> uploads. This

Re: pre-push hook does not get input on non-fast-forward pushes

Stefan Tauner writes: > I noticed that without an additional --force the pre-push hook does not > get any input on stdin if a push would result in non-fast-forward > uploads. This is not a problem per se (although I don't get the > rationale) but it is

pre-push hook does not get input on non-fast-forward pushes

Hi, I noticed that without an additional --force the pre-push hook does not get any input on stdin if a push would result in non-fast-forward uploads. This is not a problem per se (although I don't get the rationale) but it is undocumented and the latter left me puzzled. (Please keep me in CC

Re: [RFC/PATCH] t/perf: "make clean" from the top-level to clean results

On Mon, Mar 28, 2016 at 01:16:50PM -0700, Junio C Hamano wrote: > Running "make clean" from the top-level after running perf tests > left t/perf/test-results/ directory and tons of files in it. At > least "make distclean" should turn things back to pristine state. > > Signed-off-by: Junio C

[RFC/PATCH] t/perf: "make clean" from the top-level to clean results

Running "make clean" from the top-level after running perf tests left t/perf/test-results/ directory and tons of files in it. At least "make distclean" should turn things back to pristine state. Signed-off-by: Junio C Hamano --- * Perhaps I am missing some reason why this

Re: [Bug] git rev-parse --git-common-dir executed from a sub dir of the main worktree is wrong

Mike Rappazzo writes: > I found a case where it seems that the result of `git rev-parse > --git-common-dir` is incorrect. If you execute the command from > within a subdirectory in the main worktree, it returns the path from > the root of the worktree to the current dir +

[Bug] git rev-parse --git-common-dir executed from a sub dir of the main worktree is wrong

I found a case where it seems that the result of `git rev-parse --git-common-dir` is incorrect. If you execute the command from within a subdirectory in the main worktree, it returns the path from the root of the worktree to the current dir + "/.git". (As a refresher, running this command from

Re: git show -m with a parent number

Jeff King writes: > On Sun, Mar 27, 2016 at 08:46:02PM +, Anatoly Borodin wrote: > >> is there a good reason for `git show -m` to not accept the number of a >> parent of a merge commit? I can run `git show --first-parent COMMIT`, >> but need to write `git diff COMMIT^2 COMMIT`

Re: git show -m with a parent number

On Sun, Mar 27, 2016 at 08:46:02PM +, Anatoly Borodin wrote: > is there a good reason for `git show -m` to not accept the number of a > parent of a merge commit? I can run `git show --first-parent COMMIT`, > but need to write `git diff COMMIT^2 COMMIT` every time I want to diff > with the

Re: [PATCH v9 1/3] parse-options.c: make OPTION__COUNTUP consider negative values

On Mon, Mar 28, 2016 at 2:42 PM, Pranit Bauva wrote: >> A couple of new tests to t0040-parse-options.sh would be great to >> ensure that starting from a negative value works as advertised, i.e. >> at least that '--option' jumps to 1 and '--no-option' resets to 0. > > I

Re: [PATCH v2] rebase-i: print an abbreviated hash when stop for editing

Ralf Thielow writes: > The message that is shown when rebase-i stops for editing prints > the full hash of the commit where it stopped which makes the message > overflow to the next line on smaller terminal windows. Print an > abbreviated hash instead. > > Signed-off-by:

Re: [PATCH v9 1/3] parse-options.c: make OPTION__COUNTUP consider negative values

> A couple of new tests to t0040-parse-options.sh would be great to > ensure that starting from a negative value works as advertised, i.e. > at least that '--option' jumps to 1 and '--no-option' resets to 0. I think adding tests to t0040-parse-options.sh cannot reflect the behavior introduced by

Re: [PATCH v3] path.c enter_repo(): fix unproper strbuf unwrapping and memory leakage

Hui Yiqun writes: > According to strbuf.h, strbuf_detach is the sole supported method > to unwrap a memory buffer from its strbuf shell. > ... > diff --git a/path.c b/path.c > index 969b494..9801617 100644 > --- a/path.c > +++ b/path.c > @@ -625,6 +625,7 @@ const char

Re: [PATCH v2] path.c enter_repo(): fix unproper strbuf unwrapping and memory leakage

On Mon, Mar 28, 2016 at 11:56:10PM +0800, Hui Yiqun wrote: > According to strbuf.h, strbuf_detach is the sole supported method > to unwrap a memory buffer from its strbuf shell. > > So we should not return the pointer of strbuf.buf directly. > > What's more, some memory leakages are solved.

Re: [PATCH v3 1/2] refs: add a new function set_worktree_head_symref

Kazuki Yamaguchi writes: > Add a new function set_worktree_head_symref, to update HEAD symref for > the specified worktree. > > To update HEAD of a linked working tree, > create_symref("worktrees/$work_tree/HEAD", "refs/heads/$branch", msg) > could be used. However when it comes to

Re: [PATCH v4] worktree: add: introduce --checkout option

Ray Zhang writes: > By adding this option which defaults to true, we can use the > corresponding --no-checkout to make some customizations before > the checkout, like sparse checkout, etc. > > Helped-by: Eric Sunshine > Helped-by: Junio C Hamano

Re: [PATCH v3/GSoC 2/5] path.c: implement xdg_runtime_dir()

惠轶群 writes: > For example: > > const char *enter_repo(const char *path, int strict) > { > static struct strbuf validated_path = STRBUF_INIT; > static struct strbuf used_path = STRBUF_INIT; > > if (!path) > return NULL; // no need to

Re: [PATCHv3 5/5] submodule--helper clone: lose the extra prefix option

Junio C Hamano writes: > I am talking about a case where > > cd repo > cd untracked > git submodule --recurse-submodules --read-from=file > > wants to run , using information stored in repo/untracked/file, > and work on submodules repo/sub and

Re: [PATCH v2] branch -d: refuse deleting a branch which is currently checked out

On Mon, Mar 28, 2016 at 3:22 AM, Kazuki Yamaguchi wrote: > When a branch is checked out by current working tree, deleting the > branch is forbidden. However when the branch is checked out only by > other working trees, deleting is allowed. It's not quite clear from this description

Re: [GSoC] A late proposal: a modern send-email

On Sat, Mar 26, 2016 at 3:13 AM, 惠轶群 wrote: > 2016-03-26 2:16 GMT+08:00 Junio C Hamano : >> 惠轶群 writes: >> >>> # Purpose >>> The current implementation of send-email is based on perl and has only >>> a tui, it has two problems: >>> -

[PATCH v2] rebase-i: print an abbreviated hash when stop for editing

The message that is shown when rebase-i stops for editing prints the full hash of the commit where it stopped which makes the message overflow to the next line on smaller terminal windows. Print an abbreviated hash instead. Signed-off-by: Ralf Thielow ---

Re: [PATCH v3] path.c enter_repo(): fix unproper strbuf unwrapping and memory leakage

Sorry, I sent the patch repeatedly to fix a wrongly indent with space. 2016-03-28 23:57 GMT+08:00 Hui Yiqun : > According to strbuf.h, strbuf_detach is the sole supported method > to unwrap a memory buffer from its strbuf shell. > > So we should not return the pointer of

[PATCH v3] path.c enter_repo(): fix unproper strbuf unwrapping and memory leakage

According to strbuf.h, strbuf_detach is the sole supported method to unwrap a memory buffer from its strbuf shell. So we should not return the pointer of strbuf.buf directly. What's more, some memory leakages are solved. --- path.c | 15 ++- 1 file changed, 10 insertions(+), 5

[PATCH v2] path.c enter_repo(): fix unproper strbuf unwrapping and memory leakage

According to strbuf.h, strbuf_detach is the sole supported method to unwrap a memory buffer from its strbuf shell. So we should not return the pointer of strbuf.buf directly. What's more, some memory leakages are solved. --- path.c | 15 ++- 1 file changed, 10 insertions(+), 5

[PATCH] path.c enter_repo(): fix unproper strbuf unwrapping and memory leakage

According to strbuf.h, strbuf_detach is the sole supported method to unwrap a memory buffer from its strbuf shell. So we should not return the pointer of strbuf.buf directly. What's more, some memory leakages are solved. --- path.c | 15 ++- 1 file changed, 10 insertions(+), 5

Re: [PATCH 1/4] config --show-origin: report paths with forward slashes

Hi Hannes, On Mon, 28 Mar 2016, Johannes Sixt wrote: > A change like this whould have been preferable: > [...] The problem with your patch is that it does not account for backslashes in paths resulting in quoting. I am afraid that your patch will most likely *not* let the tests pass in Git for

Re: [PATCH v3/GSoC 2/5] path.c: implement xdg_runtime_dir()

2016-03-28 22:50 GMT+08:00 Junio C Hamano : > 惠轶群 writes: > >> After read the source code of strbuf more carefully, I get the conclusion >> that if a strbuf is initialized with STRBUF_INIT but is not used, there is >> no need to release it. Is it true? > >

Re: How to use @{-1} with push?

On Fri, Mar 25, 2016 at 1:58 PM, Junio C Hamano wrote: > I thought these are clear from their documentation. "push" works on > refnames, "branch" works on branch names. "push" takes an branch > name as a short-hand and adds refs/heads/ when it makes sense, but > because it

Re: [PATCH v3/GSoC 2/5] path.c: implement xdg_runtime_dir()

惠轶群 writes: > After read the source code of strbuf more carefully, I get the conclusion > that if a strbuf is initialized with STRBUF_INIT but is not used, there is > no need to release it. Is it true? If it is initialized with STRBUF_INIT and never used, there is no reason

Re: [PATCH v3/GSoC 2/5] path.c: implement xdg_runtime_dir()

惠轶群 writes: > Excuse me, but I could not find > `Documentation/technical/api-strbuf.txt` in master branch. Do you > refer to the header of `strbuf.h`? In which, I learnt how to > initialize the strbuf and how to take use of it when I began to > use it. Ah, yes, it was a

git difftool help

'git diff 'is opening in meld. I could not create a patch using - git diff > ./patch-01 i did not make any change to pick meld, by default it is picking meld. Which "git difftool" will help to create patch ? i do want to use format patch as changes are not yet committed ? -Ratheesh -- To

Re: [PATCH v3/GSoC 2/5] path.c: implement xdg_runtime_dir()

2016-03-26 1:59 GMT+08:00 Jeff King : > On Fri, Mar 25, 2016 at 10:21:48PM +0800, 惠轶群 wrote: > >> > There are some minor English problems here (and elsewhere). E.g., you >> > probably want "So we just issue a warning and leave it to the user to >> > solve.". >> >> Sorry for my

[no subject]

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

Re: [PATCH v3/GSoC 2/5] path.c: implement xdg_runtime_dir()

2016-03-26 0:55 GMT+08:00 Junio C Hamano : > 惠轶群 writes: > >>> There's a lot of "what" here that the caller doesn't really care about, >>> and which may go stale with respect to the implementation over time. Can >>> we make something more succinct like: >>>

Re: [GSoC] A late proposal: a modern send-email

2016-03-28 6:00 GMT+08:00 Eric Wong : > Junio C Hamano wrote: >> 惠轶群 writes: >> > - Build a simple email client (maybe a web components based web app or >> > wxwidgets based GUI client, they are both cross-platform) which is >> > easy

[PATCH v4] worktree: add: introduce --checkout option

By adding this option which defaults to true, we can use the corresponding --no-checkout to make some customizations before the checkout, like sparse checkout, etc. Helped-by: Eric Sunshine Helped-by: Junio C Hamano Reviewed-by: Eric Sunshine

[ANNOUNCE] git-push-update, tool to push with "server-side" merge or rebase

Hello. I would like to announce git-push-update, a tool which emulates server-side merge or rebase. The link: https://github.com/max630/git-push-update It is a bash script which fetches latest remote branch, creates temporary clone, performs there merge or rebase, pushes results to server. If

Re: [PATCH 1/4] config --show-origin: report paths with forward slashes

Am 22.03.2016 um 18:42 schrieb Johannes Schindelin: > On Windows, the backslash is the native directory separator, but all > supported Windows versions also accept the forward slash in most > circumstances. > > Our tests expect forward slashes. > > Relative paths are generated by Git using

[PATCH v2] branch -d: refuse deleting a branch which is currently checked out

When a branch is checked out by current working tree, deleting the branch is forbidden. However when the branch is checked out only by other working trees, deleting is allowed. Use find_shared_symref() to check if the branch is in use, not just comparing with the current working tree's HEAD.

Re: [PATCH v2 5/5] branch -d: refuse deleting a branch which is currently checked out

On Sun, Mar 27, 2016 at 01:52:18PM -0400, Eric Sunshine wrote: > On Fri, Mar 25, 2016 at 2:28 PM, Kazuki Yamaguchi wrote: > > When a branch is checked out by current working tree, deleting the > > branch is forbidden. However when the branch is checked out only by > > other working