Re: difflame

On Thu, Feb 2, 2017 at 10:46 PM, Edmundo Carmona Antoranz wrote: > I have been "scripting around git blame --reverse" for some days now. > Mind taking a look? I've been working on blame-deletions for this. blame-deletions branch, that is Sorry for the previous top-posting.

Re: difflame

I have been "scripting around git blame --reverse" for some days now. Mind taking a look? I've been working on blame-deletions for this. 22:41 $ ../difflame/difflame.py HEAD~5 HEAD diff --git a/file b/file index b414108..051c298 100644 --- a/file +++ b/file @@ -1,6 +1,9 @@ ^1513353 (Edmundo

Re: How to use git show's "%<([,trunc|ltrunc|mtrunc])"?

On 2 February 2017 at 20:19, G. Sylvie Davies wrote: > On Thu, Feb 2, 2017 at 9:51 AM, Hilco Wijbenga > wrote: >> Hi all, >> >> I'm trying to get the committer date printed in a custom fashion. >> Using "%cI" gets me close: >> >> $ git show

Re: How to use git show's "%<([,trunc|ltrunc|mtrunc])"?

On Thu, Feb 2, 2017 at 9:51 AM, Hilco Wijbenga wrote: > Hi all, > > I'm trying to get the committer date printed in a custom fashion. > Using "%cI" gets me close: > > $ git show --format="%cI | %an" master | head -n 1 > 2017-01-31T17:02:13-08:00 | Hilco Wijbenga > > I

Re: [PATCH 00/12] completion: speed up refs completion

On Thu, Feb 2, 2017 at 6:53 PM, SZEDER Gábor wrote: > This series speeds up refs completion for large number of refs, partly > by giving up disambiguating ambiguous refs (patch 6) and partly by > eliminating most of the shell processing between 'git for-each-ref' > and

possible bug: inconsistent CLI behaviour for empty user.name

The problem is that GIT accepts a user.name of " " for some operations (for example when doing a simple "git commit"), but does require a "non-empty" user.name for others (like git commit --amend and git rebase). In case of the latter commands GIT fails with the message "fatal: empty ident name

[PATCH 04/12] completion: support excluding full refs

Commit 49416ad22 (completion: support excluding refs, 2016-08-24) made possible to complete short refs with a '^' prefix. Extend the support to full refs to make completing '^refs/...' work. Signed-off-by: SZEDER Gábor --- contrib/completion/git-completion.bash | 8

[PATCH 05/12] completion: don't disambiguate tags and branches

When the completion script has to list only tags or only branches, it uses the 'git for-each-ref' format 'refname:short', which makes sure that all listed tags and branches are unambiguous. However, disambiguating tags and branches in these cases is wrong, because: - __git_tags(), the helper

[PATCH 08/12] completion: let 'for-each-ref' strip the remote name from remote branches

The code listing unique remote branches for 'git checkout's tracking DWIMery uses a shell parameter expansion in a loop iterating over each listed ref to remove the remote's name from the remote branches, i.e. the leading path component from the short ref. When listing refs from a configured

[PATCH 06/12] completion: don't disambiguate short refs

When the completion script lists short refs it does so using the 'git for-each-ref' format 'refname:short', which makes sure that all listed refs are unambiguous. While disambiguating refs is technically correct in this case, as opposed to the cases discussed in the previous patch, this

[PATCH 12/12] completion: fill COMPREPLY directly when completing refs

__gitcomp_nl() iterates over all the possible completion words it gets as argument - filtering matching words, - appending a trailing space to each matching word (in all but two cases), - prepending a prefix to each matching word (when completing words after e.g. '--option=' or

[PATCH 03/12] completion: support completing full refs after '--option=refs/'

Completing full refs currently only works when the full ref stands on in its own on the command line, but doesn't work when the current word to be completed contains a prefix before the full ref, e.g. '--option=refs/' or 'master..refs/bis'. The reason is that __git_refs() looks at the current

[PATCH 11/12] completion: list only matching symbolic and pseudorefs when completing refs

The previous changes in this series ensure that __git_refs() lists only refs that match the current word to be completed, but non-matching symbolic and pseudo refs still show up in its output. Filter out non-matching symbolic and pseudo refs as well, so anything __git_refs() outputs matches the

[PATCH 07/12] completion: let 'for-each-ref' and 'ls-remote' filter matching refs

When completing refs, several __git_refs() code paths list all the refs from the refs/{heads,tags,remotes}/ hierarchy and then __gitcomp_nl() iterates over those refs in a shell loop to filter out refs not matching the current word to be completed. This comes with a considerable performance

[PATCH 02/12] completion: wrap __git_refs() for better option parsing

__git_refs() currently accepts two optional positional parameters: a remote and a flag for 'git checkout's tracking DWIMery. To fix a minor bug, and, more importantly, for faster refs completion, this series will add three more parameters: a prefix, the current word to be completed and a suffix,

[PATCH 10/12] completion: let 'for-each-ref' sort remote branches for 'checkout' DWIMery

When listing unique remote branches for 'git checkout's tracking DWIMery, __git_refs() runs the classic '... |sort |uniq -u' pattern to filter out duplicate remote branches. Let 'git for-each-ref' do the sorting, sparing the overhead of fork()+exec()ing 'sort' and a stage in the pipeline where

[PATCH 09/12] completion: let 'for-each-ref' filter remote branches for 'checkout' DWIMery

The code listing unique remote branches for 'git checkout's tracking DWIMery outputs only remote branches that match the current word to be completed, but the filtering is done in a shell loop iterating over all remote refs. Let 'git for-each-ref' do the filtering, as it can do so much more

[PATCH 00/12] completion: speed up refs completion

This series speeds up refs completion for large number of refs, partly by giving up disambiguating ambiguous refs (patch 6) and partly by eliminating most of the shell processing between 'git for-each-ref' and 'ls-remote' and Bash's completion facility. The rest is a bit of preparatory

[PATCH 01/12] completion: remove redundant __gitcomp_nl() options from _git_commit()

Those two options are specifying the default values that __gitcomp_nl() would use anyway when invoked with no options at all. Signed-off-by: SZEDER Gábor --- contrib/completion/git-completion.bash | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCHv2 14/21] completion: fix completion after 'git -C '

The main completion function finds the name of the git command by iterating through all the words on the command line in search for the first non-option-looking word. As it is not aware of 'git -C's mandatory path argument, if the '-C ' option is present, 'path' will be the first such word and it

[PATCHv2 09/21] completion: respect 'git --git-dir=' when listing remote refs

In __git_refs() the git commands listing refs, both short and full, from a given remote repository are run without giving them the path to the git repository which might have been specified on the command line via 'git --git-dir='. This is bad, those git commands should access the

[PATCHv2 01/21] completion: improve __git_refs()'s in-code documentation

That "first argument is passed to __gitdir()" statement in particular is not really helpful, and after this series it won't be the case anyway. Signed-off-by: SZEDER Gábor --- contrib/completion/git-completion.bash | 8 +--- 1 file changed, 5 insertions(+), 3

[PATCHv2 06/21] completion tests: add tests for the __git_refs() helper function

Check how __git_refs() lists refs in different scenarios, i.e. - short and full refs, - from a local or from a remote repository, - remote specified via path, name or URL, - with or without a repository specified on the command line, - non-existing remote, - unique remote branches for

[PATCHv2 08/21] completion: fix most spots not respecting 'git --git-dir='

The completion script already respects the path to the repository specified on the command line most of the time, here we add the necessary '--git-dir=$(__gitdir)' options to most of the places where git was executed without it. The exceptions where said option is not added are the git

[PATCHv2 20/21] completion: extract repository discovery from __gitdir()

To prepare for caching the path to the repository in the following commit, extract the repository discovering part of __gitdir() into the __git_find_repo_path() helper function, which stores the found path in the $__git_repo_path variable instead of printing it. Make __gitdir() a wrapper around

[PATCHv2 10/21] completion: list refs from remote when remote's name matches a directory

If the remote given to __git_refs() happens to match both the name of a configured remote and the name of a directory in the current working directory, then that directory is assumed to be a git repository, and listing refs from that directory will be attempted. This is wrong, because in such a

[PATCHv2 19/21] completion: don't guard git executions with __gitdir()

Three completion functions, namely __git_index_files(), __git_heads() and __git_tags(), first run __gitdir() and check that the path it outputs exists, i.e. that there is a git repository, and run a git command only if there is one. After the previous changes in this series there are no further

[PATCHv2 15/21] rev-parse: add '--absolute-git-dir' option

The output of 'git rev-parse --git-dir' can be either a relative or an absolute path, depending on whether the current working directory is at the top of the worktree or the .git directory or not, or how the path to the repository is specified via the '--git-dir=' option or the $GIT_DIR

[PATCHv2 17/21] completion: don't use __gitdir() for git commands

Several completion functions contain the following pattern to run git commands respecting the path to the repository specified on the command line: git --git-dir="$(__gitdir)" This imposes the overhead of fork()ing a subshell for the command substitution and potentially fork()+exec()ing 'git

[PATCHv2 13/21] completion: don't offer commands when 'git --opt' needs an argument

The main git options '--git-dir', '-c', '-C', '--worktree' and '--namespace' require an argument, but attempting completion right after them lists git commands. Don't offer anything right after these options, thus let Bash fall back to filename completion, because - the three options

[PATCHv2 18/21] completion: consolidate silencing errors from git commands

Outputting error messages during completion is bad: they disrupt the command line, can't be deleted, and the user is forced to Ctrl-C and start over most of the time. We already silence stderr of many git commands in our Bash completion script, but there are still some in there that can spew

[PATCHv2 21/21] completion: cache the path to the repository

After the previous changes in this series there are only a handful of $(__gitdir) command substitutions left in the completion script, but there is still a bit of room for improvements: 1. The command substitution involves the forking of a subshell, which has considerable overhead on some

[PATCHv2 04/21] completion tests: consolidate getting path of current working directory

Some tests of the __gitdir() helper function use the $TRASH_DIRECTORY variable in direct path comparisons. In general this should be avoided, because it might contain symbolic links. There happens to be no issues with this here, however, because those tests use $TRASH_DIRECTORY both for

[PATCHv2 02/21] completion tests: don't add test cruft to the test repository

While preparing commits, three tests added newly created files to the index using 'git add .', which added not only the files in question but leftover test cruft from previous tests like the files 'expected' and 'actual' as well. Luckily, this had no effect on the tests' correctness. Add only

[PATCHv2 00/21] completion: various __gitdir()-related improvements

This is a long overdue reroll of a bunch of bugfixes, cleanups and optimizations related to how the completion script finds the path to the repository and how it uses that path. Most importantly this series adds support for completion following 'git -C path', and it eliminates a few subshells and

[PATCHv2 05/21] completion tests: check __gitdir()'s output in the error cases

The __gitdir() helper function shouldn't output anything if not in a git repository. The relevant tests only checked its error code, so extend them to ensure that there's no output. Signed-off-by: SZEDER Gábor --- t/t9902-completion.sh | 8 +--- 1 file changed, 5

[PATCHv2 03/21] completion tests: make the $cur variable local to the test helper functions

The test helper functions test_gitcomp() and test_gitcomp_nl() leak the $cur variable into the test environment. Since this variable has a special role in the Bash completion script (it holds the word currently being completed) it influences the behavior of most completion functions and thus this

[PATCHv2 07/21] completion: ensure that the repository path given on the command line exists

The __gitdir() helper function prints the path to the git repository to its stdout or stays silent and returns with error when it can't find a repository or when the repository given via $GIT_DIR doesn't exist. This is not the case, however, when the path in $__git_dir, i.e. the path to the

[PATCHv2 16/21] completion: respect 'git -C '

'git -C ' option(s) on the command line should be taken into account during completion, because - like '--git-dir=', it can lead us to a different repository, - a few git commands executed in the completion script do care about in which directory they are executed, and - the command

[PATCHv2 11/21] completion: don't list 'HEAD' when trying refs completion outside of a repo

When refs completion is attempted while not in a git repository, the completion script offers 'HEAD' erroneously. Check early in __git_refs() that there is either a repository or a remote to work on, and return early if neither is given. Signed-off-by: SZEDER Gábor ---

[PATCHv2 12/21] completion: list short refs from a remote given as a URL

e832f5c09680 (completion: avoid ls-remote in certain scenarios, 2013-05-28) turned a 'git ls-remote ' query into a 'git for-each-ref refs/remotes//' to improve responsiveness of remote refs completion by avoiding potential network communication. However, it inadvertently made impossible to

RE

Assalam Alaikum, how are you doing my friend? my name is Madam Aleena Aasim Abdulaziz from Turkey and i have something very important to discuss with you please contact me now on my private email: aleen@hotmail.com

[PATCH] reset: add an example of how to split a commit into two

From: Jacob Keller It is sometimes useful to break a commit into parts to more logically show how the code changes. There are many possible ways to achieve this result, but one simple and powerful one is to use git reset -p. Add an example to the documentation showing

What's cooking in git.git (Feb 2017, #01; Thu, 2)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. The tip of 'master' has most of

[ANNOUNCE] Git v2.11.1

The latest maintenance release Git v2.11.1 is now available at the usual places. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/ The following public repositories all have a copy of the 'v2.11.1' tag and the 'maint' branch that the tag points at: url =

Re: git-scm.com status report

For anyone interested, this thread is on the HN front page right now[0]. There's one suggestion in particular that stands out to me - shifting to Digital Ocean[1], which for $240/mo offers wa more than what it sounds like the current Heroku costs are. [0]

[PATCH v2] git-prompt.sh: add submodule indicator

Hi everyone again, I guess this time I'm rerolling my patch the right way. Thanks again Gábor for your feedback. And thanks to Junio for being patient and explaining the reroll workflow Greeting, Benjamin Benjamin Fuchs (1): git-prompt.sh: add submodule indicator

[PATCH v2] git-prompt.sh: add submodule indicator

I expirienced that working with submodules can be confusing. A submodule can be anywhere in your parent git repository. While walking through the parent repository it would be good to have a reminder to know when you entered a submodule. This new indicator will show if you are in a submodule. The

Re: [PATCH] ls-remote: add "--diff" option to show only refs that differ

On Thu, Feb 2, 2017 at 1:05 PM, Junio C Hamano wrote: > > Another case I can think of that "--diff" would help is when you are > inspecting your own mirror (but that can be seen as a special case > of the "they have copies of yours plus their own", if you think of > your mirror

Re: [PATCH] ls-remote: add "--diff" option to show only refs that differ

Linus Torvalds writes: > I basically don't see downstream contributor doing ls-remote, it's a > upstream maintainer command. > > But that may be a lack of imagination on my part. I actually share that perception. For the "downstream wonders about the state of the

Re: [PATCH] ls-remote: add "--diff" option to show only refs that differ

On Thu, Feb 2, 2017 at 12:03 PM, Junio C Hamano wrote: > > Most downstream folks seem to care about refs/remotes/origin/$branch > and I think in that context "git ls-remote --diff [origin]" that > compares their refs/heads/* and refs/remotes/origin/* would make > sense. Hmm.

Re: [PATCH 00/11] nd/worktree-move update

Johannes Schindelin writes: > Also, the more important reply was Peff's reply that suggested that the > proposed fix was incomplete, as it misses --unpack-unreachable: > https://public-inbox.org/git/20160601160143.ga9...@sigill.intra.peff.net/ While I think that

Re: [PATCH] ls-remote: add "--diff" option to show only refs that differ

Linus Torvalds writes: > My main use of "git ls-remote" tends to be to check what the other end > has when some pull request goes wrong (they forgot to push, or they used > the wrong ref name or whatever), and it ends up being hard to see all > the relevant data

[PATCH] ls-remote: add "--diff" option to show only refs that differ

From: Linus Torvalds Date: Thu, 2 Feb 2017 11:37:49 -0800 Subject: [PATCH] ls-remote: add "--diff" option to show only refs that differ My main use of "git ls-remote" tends to be to check what the other end has when some pull request goes wrong (they forgot to

Re: [PATCH v3 00/27] Revamp the attribute system; another round

Brandon Williams writes: > Per some of the discussion online and off I locally broke up up the question > and answer and I wasn't very thrilled with the outcome for a number of > reasons. > > 1. The API is more complex > 2. Performance hit > ... > Given the above, v3

How to use git show's "%<([,trunc|ltrunc|mtrunc])"?

Hi all, I'm trying to get the committer date printed in a custom fashion. Using "%cI" gets me close: $ git show --format="%cI | %an" master | head -n 1 2017-01-31T17:02:13-08:00 | Hilco Wijbenga I would like to get rid of the "-08:00" bit at the end of the timestamp. According to the "git show"

Re: [PATCH 4/7] completion: teach ls-remote to complete options

Cornelius Weig writes: > On 02/02/2017 02:40 AM, SZEDER Gábor wrote: >> >>> ls-remote needs to complete remote names and its own options. >> >> And refnames, too. > > Yes, right. However, do you think it is reasonable to complete remote > refnames? I don't think so,

[PATCH] document behavior of empty color name

On Thu, Feb 02, 2017 at 04:16:15PM +0700, Duy Nguyen wrote: > > I hadn't heard anything back, > > Sorry I was accidentally busy during Luna new year holiday. No problem. That sounds much more fun than working on Git. :) > > - if (!len) > > - return -1; > > + if (!len) { > > +

Re: init --separate-git-dir does not set core.worktree

Duy Nguyen writes: > On Thu, Feb 2, 2017 at 10:55 AM, Kyle Meyer wrote: >> >> As of 6311cfaf9 (init: do not set unnecessary core.worktree, >> 2016-09-25), "git init --separate-git-dir" no longer sets core.worktree >> (test below). Based on the commit message

Re: [PATCH 00/11] nd/worktree-move update

Hi Duy, On Thu, 2 Feb 2017, Johannes Schindelin wrote: > Hi Duy, > > On Thu, 2 Feb 2017, Duy Nguyen wrote: > > > On Thu, Feb 2, 2017 at 5:37 PM, Johannes Schindelin > > wrote: > > > > > > On Thu, 2 Feb 2017, Duy Nguyen wrote: > > > > > >> You meant this one [1]?

Business Proposal

Dear Friend, I would like to discuss a very important issue with you. I am writing to find out if this is your valid email. Please, let me know if this email is valid Kind regards Adrien Saif Attorney to Quatif Group of Companies

Re: [PATCH 00/11] nd/worktree-move update

Hi Duy, On Thu, 2 Feb 2017, Duy Nguyen wrote: > On Thu, Feb 2, 2017 at 5:37 PM, Johannes Schindelin > wrote: > > > > On Thu, 2 Feb 2017, Duy Nguyen wrote: > > > >> On Thu, Feb 2, 2017 at 4:43 PM, Johannes Schindelin > >> wrote: > >> > >

Please get back to me

Dear Friend, I would like to discuss a very important issue with you. I am writing to find out if this is your valid email. Please, let me know if this email is valid Kind regards Adrien Saif Attorney to Qatif Group of Companies

Re: [PATCH 00/11] nd/worktree-move update

On Thu, Feb 2, 2017 at 5:37 PM, Johannes Schindelin wrote: > Hi Duy, > > On Thu, 2 Feb 2017, Duy Nguyen wrote: > >> On Thu, Feb 2, 2017 at 4:43 PM, Johannes Schindelin >> wrote: >> > >> > On Thu, 2 Feb 2017, Duy Nguyen wrote: >> > >> >> On

Re: [PATCH v2 7/7] completion: recognize more long-options

On 02/02/2017 03:00 AM, SZEDER Gábor wrote: >> Personally, I agree with you that >>> Adding more long options that git commands learn along the way is >>> always an improvement. >> However, people may start complaining that their terminal becomes too >> cluttered when doing a double-Tab. In my

Re: [PATCH 00/11] nd/worktree-move update

Hi Duy, On Thu, 2 Feb 2017, Duy Nguyen wrote: > On Thu, Feb 2, 2017 at 4:43 PM, Johannes Schindelin > wrote: > > > > On Thu, 2 Feb 2017, Duy Nguyen wrote: > > > >> On Thu, Feb 2, 2017 at 4:16 PM, Johannes Schindelin > >> wrote: > >> > >

Re: [PATCH 00/11] nd/worktree-move update

On Thu, Feb 2, 2017 at 4:43 PM, Johannes Schindelin wrote: > Hi Duy, > > On Thu, 2 Feb 2017, Duy Nguyen wrote: > >> On Thu, Feb 2, 2017 at 4:16 PM, Johannes Schindelin >> wrote: >> > Hi Duy, >> > >> > On Thu, 2 Feb 2017, Nguyễn Thái Ngọc

Re: [PATCH 00/11] nd/worktree-move update

Hi Duy, On Thu, 2 Feb 2017, Duy Nguyen wrote: > On Thu, Feb 2, 2017 at 4:16 PM, Johannes Schindelin > wrote: > > Hi Duy, > > > > On Thu, 2 Feb 2017, Nguyễn Thái Ngọc Duy wrote: > > > >> This squashes two changes from Johannes and Ramsay: [...] > > > > Sorry, I lost

Re: [PATCH 4/7] completion: teach ls-remote to complete options

On 02/02/2017 02:40 AM, SZEDER Gábor wrote: > >> ls-remote needs to complete remote names and its own options. > > And refnames, too. Yes, right. However, do you think it is reasonable to complete remote refnames? I don't think so, because it would mean we would have to run ls-remote during

Fwd: [PATCH 1/2] doc: add doc for git-push --recurse-submodules=only

Looks good to me! Thanks for writing the documentation. I really need to be better about getting documentation done at the same time I'm adding features :) -Brandon On Wed, Feb 1, 2017 at 3:16 PM, Junio C Hamano wrote: > > cornelius.w...@tngtech.com writes: > > > From:

Re: init --separate-git-dir does not set core.worktree

On Thu, Feb 2, 2017 at 10:55 AM, Kyle Meyer wrote: > Hello, > > As of 6311cfaf9 (init: do not set unnecessary core.worktree, > 2016-09-25), "git init --separate-git-dir" no longer sets core.worktree > (test below). Based on the commit message and the corresponding thread > [1],

Re: [PATCH 2/2] completion: add completion for --recurse-submodules=only

On Wed, Feb 1, 2017 at 3:07 PM, wrote: > From: Cornelius Weig > > Command completion for 'git-push --recurse-submodules' already knows to > complete some modes. However, the recently added mode 'only' is missing. > > Adding 'only' to the

Re: [PATCH 00/11] nd/worktree-move update

On Thu, Feb 2, 2017 at 4:16 PM, Johannes Schindelin wrote: > Hi Duy, > > On Thu, 2 Feb 2017, Nguyễn Thái Ngọc Duy wrote: > >> This squashes two changes from Johannes and Ramsay: [...] > > Sorry, I lost track of the worktree discussions... Could you remind me > which

Re: git-daemon shallow checkout fail

On Tue, Jan 31, 2017 at 12:27 AM, Jeff King wrote: > On Sat, Jan 28, 2017 at 05:29:32PM -0700, Bob Proulx wrote: > >> However the problem driving me crazy is that this only fails this way >> on one machine. Unfortunately failing on the machine I need to use. >> If I try this same

Re: [PATCH 2/7] completion: add subcommand completion for rerere

On 02/02/2017 01:57 AM, SZEDER Gábor wrote: > You didn't add 'rerere' to the list of porcelain commands, i.e. it > won't be listed after 'git '. I'm not saying it should be > listed there, because I can't decide whether 'rerere' is considered > porcelain or plumbing... Just wanted to make sure

Re: [PATCH 00/11] nd/worktree-move update

Hi Duy, On Thu, 2 Feb 2017, Nguyễn Thái Ngọc Duy wrote: > This squashes two changes from Johannes and Ramsay: [...] Sorry, I lost track of the worktree discussions... Could you remind me which patch is supposed to fix my continuous reflog corruption? Thanks, Dscho

Re: [PATCH] color_parse_mem: allow empty color spec

On Wed, Feb 01, 2017 at 01:21:29AM +0100, Jeff King wrote: > On Tue, Jan 31, 2017 at 02:45:40PM -0800, Junio C Hamano wrote: > > > * nd/log-graph-configurable-colors (2017-01-23) 3 commits > > (merged to 'next' on 2017-01-23 at c369982ad8) > > + log --graph: customize the graph lines with

Google Doc about the Contributors' Summit

Hi team, I just started typing stuff up in a Google Doc, and made it editable to everyone, feel free to help and add things: https://docs.google.com/document/d/1KDoSn4btbK5VJCVld32he29U0pUeFGhpFxyx9ZJDDB0/edit?usp=sharing Ciao, Johannes

[PATCH 09/11] worktree move: accept destination as directory

Similar to "mv a b/", which is actually "mv a b/a", we extract basename of source worktree and create a directory of the same name at destination if dst path is a directory. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano ---

[PATCH 11/11] worktree remove: new command

Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano --- Documentation/git-worktree.txt | 21 + builtin/worktree.c | 79 ++ contrib/completion/git-completion.bash | 5 ++-

[PATCH 10/11] worktree move: refuse to move worktrees with submodules

Submodules contains .git files with relative paths. After a worktree move, these files need to be updated or they may point to nowhere. This is a bandage patch to make sure "worktree move" don't break people's worktrees by accident. When .git file update code is in place, this

[PATCH 04/11] worktree.c: get_worktrees() takes a new flag argument

This is another no-op patch, in preparation for get_worktrees() to do optional things, like sorting. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano --- branch.c | 2 +- builtin/branch.c | 2 +- builtin/worktree.c | 6 +++---

[PATCH 08/11] worktree move: new command

There are two options to move the main worktree, but both have complications, so it's not implemented yet. Anyway the options are: - convert the main worktree to a linked one and move it away, leave the git repository where it is. The repo essentially becomes bare after this move. - move

[PATCH 07/11] worktree.c: add update_worktree_location()

Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano --- worktree.c | 21 + worktree.h | 6 ++ 2 files changed, 27 insertions(+) diff --git a/worktree.c b/worktree.c index 929072ad89..7684951da5 100644 --- a/worktree.c

[PATCH 06/11] worktree.c: add validate_worktree()

This function is later used by "worktree move" and "worktree remove" to ensure that we have a good connection between the repository and the worktree. For example, if a worktree is moved manually, the worktree location recorded in $GIT_DIR/worktrees/.../gitdir is incorrect and we should not move

[PATCH 02/11] worktree: reorder an if statement

This is no-op. But it helps reduce diff noise in the next patch. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano --- builtin/worktree.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/builtin/worktree.c

[PATCH 05/11] worktree list: keep the list sorted

It makes it easier to write tests for. But it should also be good for the user since locating a worktree by eye would be easier once they notice this. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano --- builtin/worktree.c | 2 +-

[PATCH 03/11] get_worktrees() must return main worktree as first item even on error

This is required by git-worktree.txt, stating that the main worktree is the first line (especially in --porcelain mode when we can't just change behavior at will). There's only one case when get_worktrees() may skip main worktree, when parse_ref() fails. Update the code so that we keep first item

[PATCH 01/11] worktree.c: zero new 'struct worktree' on allocation

This keeps things a bit simpler when we add more fields, knowing that default values are always zero. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano --- worktree.c | 14 ++ 1 file changed, 2 insertions(+), 12 deletions(-)

[PATCH 00/11] nd/worktree-move update

This squashes two changes from Johannes and Ramsay: diff --git a/builtin/worktree.c b/builtin/worktree.c index 339c622e20..a1c91f1542 100644 --- a/builtin/worktree.c +++ b/builtin/worktree.c @@ -528,7 +528,7 @@ static int unlock_worktree(int ac, const char **av, const char *prefix) static