[PATCH 4/6] connect: pass separate host and port to git_tcp_connect and git_proxy_connect

, the port was set to "" in a case that never can happen, so that code path was removed. Signed-off-by: Mike Hommey <m...@glandium.org> --- connect.c | 31 ++- 1 file changed, 14 insertions(+), 17 deletions(-) diff --git a/connect.c b/connect.c index 1c8ed6b

[PATCH 5/6] connect: don't xstrdup target_host

Now that hostandport is left unmodified in git_connect (we don't pass it to get_host_and_port() anymore), we can avoid xstrdup'ing it. Signed-off-by: Mike Hommey <m...@glandium.org> --- connect.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/connect.c b/connect.c

[PATCH v3 0/6] connect: various cleanups

er in which the changes have been done in this new series is debatable, but I thought the split in smaller parts made things easier to review, even if they could have been done in different orders. I'm leaving the optional follows-up for now. I'll work around the functions being static somehow on my

[PATCH 1/6] connect: remove get_port()

get_host_and_port(), works on a modified host string that has square brackes removed if there were any. I cannot think of any legal host:port string that would not have a port returned by get_host_and_port() *and* have one returned by get_port(). So just remove get_port(). Signed-off-by: Mike Hommey &l

[PATCH 3/6] connect: only match the host with core.gitProxy

This per-port behavior seems like an oversight rather than a deliberate choice, so, make git://kernel.org:port/path call the gitProxy script in the case described above. Signed-off-by: Mike Hommey <m...@glandium.org> --- connect.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --g

[PATCH 6/6] connect: move ssh command line preparation to a separate function

Signed-off-by: Mike Hommey <m...@glandium.org> --- connect.c | 101 ++ 1 file changed, 55 insertions(+), 46 deletions(-) diff --git a/connect.c b/connect.c index e2b976e..db78eb2 100644 --- a/connect.c +++ b/connect.c @@ -639,6 +

[RFC PATCH 1/3] connect: make parse_connect_url public

Signed-off-by: Mike Hommey <m...@glandium.org> --- connect.c | 11 ++- connect.h | 9 + 2 files changed, 11 insertions(+), 9 deletions(-) diff --git a/connect.c b/connect.c index c53f3f1..29569b3 100644 --- a/connect.c +++ b/connect.c @@ -231,13 +231,6 @@ int server_su

[RFC PATCH 2/3] connect: group CONNECT_DIAG_URL handling code

Signed-off-by: Mike Hommey <m...@glandium.org> --- connect.c | 27 --- 1 file changed, 12 insertions(+), 15 deletions(-) Note this makes http://marc.info/?l=git=146183714532394 irrelevant. diff --git a/connect.c b/connect.c index 29569b3..ce216cb 100644 --- a/con

[RFC PATCH 3/3] connect: move ssh command line preparation to a separate (public) function

Signed-off-by: Mike Hommey <m...@glandium.org> --- connect.c | 108 +- connect.h | 2 ++ 2 files changed, 60 insertions(+), 50 deletions(-) diff --git a/connect.c b/connect.c index ce216cb..c71563f 100644 --- a/connect.c

Re: [RFC PATCH 0/4] git_connect: add some flexibility

On Thu, Apr 28, 2016 at 10:41:12AM -0700, Junio C Hamano wrote: > Mike Hommey <m...@glandium.org> writes: > > > As you may be aware, I'm working on a git remote helper to access > > mercurial repositories (https://github.com/glandium/git-cinnabar/). > > > > At

[PATCH 1/4] git_connect: extend to take a pseudo format string for the program to run

. With this change, when the program/command passed to git_connect() contains a "%s", that "%s" is replaced with the path from the url, allowing the path to be at a different position than last on the executed command line. Signed-off-by: Mike Hommey <m...@glandium.o

[PATCH 4/4] git_connect: add a flag to consider the path part of ssh urls relative

In Mercurial ssh urls, the path part of the url is relative to the home directory of the account being logged to instead of being absolute. Add a flag allowing git_connect() to handle this kind of usecase. Signed-off-by: Mike Hommey <m...@glandium.org> --- connect.c | 10 +++--- con

[RFC PATCH 0/4] git_connect: add some flexibility

could be done in sq_quote_buf instead, arguably. I'm certainly open to any better ideas as long as they can make it to mainline :). Mike Hommey (4): git_connect: extend to take a pseudo format string for the program to run git_connect: avoid quoting the path on the command line when it's n

[PATCH 3/4] git_connect: allow a file descriptor to be allocated for stderr

It can be useful to the caller of git_connect() to get access to stderr, so add a flag that makes start_command allocate a file descriptor for it. Signed-off-by: Mike Hommey <m...@glandium.org> --- connect.c | 2 ++ connect.h | 1 + 2 files changed, 3 insertions(+) diff --git a/conne

[PATCH 2/4] git_connect: avoid quoting the path on the command line when it's not necessary

o the list. Signed-off-by: Mike Hommey <m...@glandium.org> --- connect.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/connect.c b/connect.c index 96c8c1d..919bf9e 100644 --- a/connect.c +++ b/connect.c @@ -668,6 +668,17 @@ static void prepare_connect_command(struct strbuf *

Re: [PATCH v3 0/2] gitk: changes for the "Tags and heads" view

On Sun, Mar 27, 2016 at 11:06 AM, Michael Rappazzo wrote: > Changes since v2[1]: > - Instead of getting the remote info for each local branch individually, >grab it all at once and store the result > - Instead of a command line option to enable the new sorting option, >

[PATCH] Fix memory leak in git_connect with CONNECT_DIAG_URL

Signed-off-by: Mike Hommey <m...@glandium.org> --- connect.c | 1 + 1 file changed, 1 insertion(+) diff --git a/connect.c b/connect.c index c53f3f1..dccf673 100644 --- a/connect.c +++ b/connect.c @@ -755,6 +755,7 @@ struct child_process *git_connect(int fd[2], const char

Announcing git-cinnabar 0.3.2

all refs meant to be removed when using git version lower than 2.1. Mike -- 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: "gitk --author=foo" shows also parent

On Tue, Apr 26, 2016 at 9:08 AM, Nikolai Kosjar wrote: > Hi! > > $ gitk --author=foo > > ...seems to show also the parent of each author-matched commit, whereas > > $ git log --author=foo > > does not. Is this intended or a bug? I've stumbled over this while

Re: [PATCH 13/21] rev-parse: add '--absolute-git-dir' option

On Thu, Feb 25, 2016 at 5:54 PM SZEDER Gábor wrote: > > Some scripts can benefit from not having to deal with the possibility > of relative paths to the repository, but the output of 'git rev-parse > --git-dir' can be a relative path. Case in point: supporting 'git -C > ' in

Re: fast-import's gfi_unpack_entry causes too many munmap/mmap cycles

On Sun, Apr 17, 2016 at 09:54:43AM +0900, Mike Hommey wrote: > On Sat, Apr 16, 2016 at 08:04:03PM +0900, Mike Hommey wrote: > > So I think I got myself a workaround... > > > > > A --- B > > > \ > > > \-- C > > > > > > I have: >

Re: fast-import's gfi_unpack_entry causes too many munmap/mmap cycles

On Sat, Apr 16, 2016 at 08:04:03PM +0900, Mike Hommey wrote: > So I think I got myself a workaround... > > > A --- B > > \ > > \-- C > > > > I have: > > - diff between null-tree and A > > - diff between A and B > > - diff between B and

Re: fast-import's gfi_unpack_entry causes too many munmap/mmap cycles

On Sat, Apr 16, 2016 at 06:18:39PM +0900, Mike Hommey wrote: > And even if I am okay with that overhead, I still hit the problem again > when using that tree later with `M 04 $sha1 ` in the next commit, > because that does a load_tree() for the tree sha1, after a commit having &

Re: fast-import's gfi_unpack_entry causes too many munmap/mmap cycles

On Sat, Apr 16, 2016 at 06:18:39PM +0900, Mike Hommey wrote: > Now, while each individual case could be improved to avoid > gfi_unpack_entry, it seems to me it would be better to make > gfi_unpack_entry better somehow. Come to think of it, there are cases that might still be worth fix

fast-import's gfi_unpack_entry causes too many munmap/mmap cycles

y, it seems to me it would be better to make gfi_unpack_entry better somehow. I wonder if there's not a better way than having it close and reopen windows all the time for recent objects. Can't the pack be pre-allocated and mapped by window-size fragments, for example? (Would that maybe not work prop

Re: Cannot checkout a branch / worktree shows multiple branches for the same directory

On Thu, Apr 14, 2016 at 3:51 PM, Krzysztof Voss wrote: > Hi, > > I stumbled upon an interesting problem when checking out a branch. > I had to switch to a testing branch to merge in some changes from yet > another branch, but when I tried to check out the testing branch I got > a

Re: Ambiguous sha-1 during a rebase

mits in my repository, only 156 have collisions with other commits (0.05%), but when comparing them to all the 3260854 objects in the repository, I see 3545 have collisions (1.2%). Mike -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger

Re: Ambiguous sha-1 during a rebase

On Wed, Apr 13, 2016 at 03:42:44PM -0700, Junio C Hamano wrote: > Mike Hommey <m...@glandium.org> writes: > > > Should git-rebase use full sha-1s under the hood to avoid these type of > > races? > > It already should be doing so since Aug 2013, IIRC. I'm usin

Ambiguous sha-1 during a rebase

that fits the same short sha1 is a tree... maybe git should be able to disambiguate in that case, since it was looking for a commit, and there's only one commit with that short sha1? Mike -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message

Re: [PATCH] gitk: Fix how remote branch names with / are drawn

s an extended-regex, and your version is probably more efficient anyway. echo "remotes/origin/dev/test1" | grep -Eo "remotes/.*?/" > > > Thank you. > (Most people on this list don't like "top posting"), please try to reply inline instead. > On Wed, Apr 13,

Re: [PATCH] t1500-rev-parse: rewrite each test to run in isolation

On Wed, Apr 13, 2016 at 12:54 AM, Eric Sunshine wrote: > On Sat, Apr 9, 2016 at 7:19 AM, Michael Rappazzo wrote: >> t1500-rev-parse has many tests which change directories and leak >> environment variables. This makes it difficult to add new tests

Re: [PATCH] gitk: Fix how remote branch names with / are drawn

On Tue, Apr 12, 2016 at 9:59 PM, David Holmer wrote: > Consider this example branch: > > remotes/origin/master > > gitk displays this branch with different background colors for each part: > "remotes/origin" in orange and "master" in green. The idea is to make it > visually

Re: [PATCH] rev-parse: fix --git-common-dir when executed from subpath of main tree

On Fri, Apr 8, 2016 at 7:47 AM, Duy Nguyen wrote: > On Mon, Apr 4, 2016 at 8:42 AM, Michael Rappazzo wrote: >> Executing `git-rev-parse --git-common-dir` from the root of the main >> worktree results in '.git', which is the relative path to the git 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: [PATCH v2] worktree: add: introduce --checkout option

On Fri, Mar 25, 2016 at 7:41 AM, Duy Nguyen wrote: > On Fri, Mar 25, 2016 at 6:31 PM, Zhang Lei wrote: >> By the way, Duy, another unrelated question: why worktree name under >> .git/worktrees is being named >> after the working tree path basename? I

Re: [PATCH][Outreachy] branch: allow - as abbreviation of '@{-1}'

you won't have to tell them about it :) Mike -- 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 0/3] config: add '--sources' option to print the source of a config value

On Sat, Feb 13, 2016 at 9:24 AM, wrote: > From: Lars Schneider > > diff to v2: > * rename cmd to cmdline > * rename function current_config_name to current_config_type_name > * add 'type' to config_source struct that identifies config type > *

`git rev-parse --git-common-dir` doesn't work in a subdirectory of the main work tree

work tree. In the latter case it returns ".git" instead of the full path to it. Mike -- 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: Bug: Branch Deletion Doesn't Clean Up

ith making the branch-creation > process more robust to races (since we might create "refs/heads/foo" in > order to make "refs/heads/foo/bar" while somebody else is deleting it to > get rid of "refs/heads/foo/baz"). Can't we come up with a system that would up

Re: Bug: Branch Deletion Doesn't Clean Up

On Thu, Feb 04, 2016 at 03:17:59AM -0500, Jeff King wrote: > On Thu, Feb 04, 2016 at 05:12:20PM +0900, Mike Hommey wrote: > > > > > It seems like git branch -d ascend the hierarchy (up to > > > > .git/refs/heads/), deleting any empty directories. > > > &

parse_object does check_sha1_signature but not parse_object_buffer?

nature? Mike -- 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: parse_object does check_sha1_signature but not parse_object_buffer?

On Tue, Feb 02, 2016 at 10:57:01AM +0900, Mike Hommey wrote: > Hi, > > You might or might not be aware of this thread: > https://groups.google.com/forum/#!topic/binary-transparency/f-BI4o8HZW0 > > Anyways, this got me to take a look around, and I noticed that > parse_object

Re: parse_object does check_sha1_signature but not parse_object_buffer?

On Mon, Feb 01, 2016 at 07:10:04PM -0800, Junio C Hamano wrote: > Mike Hommey <m...@glandium.org> writes: > > > Shouldn't parse_object_buffer also do check_sha1_signature? > > In general, it shouldn't; its callers are supposed to do it as > additional check when/if ne

Re: Is there interest in a n-sect tool?

On Wed, Jan 20, 2016 at 02:05:22PM -0800, Junio C Hamano wrote: > Mike Hommey <m...@glandium.org> writes: > > > On Mon, Jan 18, 2016 at 07:54:21PM -0800, Junio C Hamano wrote: > > > >> Hmm, sorry. For the two-trait example I gave (that can be extended > &

Re: Git 2.7.0 gitignore behaviour regression

it’s also a big area where libgit2 was inconsistent with Git’s behaviour on either of those versions too. I’ve played around and now got a .gitignore file that behaves consistently across Git 2.6, Git 2.7 and libgit2 0.23.4 (https://github.com/Homebrew/homebrew/blob/master/.gitignore) so ther

Git 2.7.0 gitignore behaviour regression

`` ?? .gitignore ?? a/ ``` The output with Git 2.7.0 is: ``` ?? .gitignore ``` Let me know if you need any more information, thanks! Mike McQuaid http://mikemcquaid.com-- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org Mo

Re: RefTree: Alternate ref backend

t; I want to say more, but I'm going to hold back right now. There's more > going on in my head than just this. > > > Of course, the lack of reachability has advantages, too. You can > > drop commits pointed to by old reflogs without rewriting the ref > > history. > >

Re: [PATCH] show signature of commit in gitk

On Sun, Dec 13, 2015 at 9:15 AM, Daniel Fahlke wrote: > It seems my Patch got no attention yet, is there anything wrong? > Do I need to ping someone in particular? > gitk patches should cc +Paul Mackerras who maintains gitk -- To unsubscribe from this

[PATCH 2/2] push: Use "last one wins" convention for --recurse-submodules

Use the "last one wins" convention for --recurse-submodules rather than treating conflicting options as an error. Also, fix the declaration of the file-scope recurse_submodules global variable to put it on a separate line. Signed-off-by: Mike Crowe <m...@mcrowe.com> ---

[PATCH 1/2] push: Fully test --recurse-submodules on command line overrides config

message. Signed-off-by: Mike Crowe <m...@mcrowe.com> --- t/t5531-deep-submodule-push.sh | 32 1 file changed, 28 insertions(+), 4 deletions(-) diff --git a/t/t5531-deep-submodule-push.sh b/t/t5531-deep-submodule-push.sh index 9fda7b0..721be32 100755 --- a/t

Re: [PATCH] push: Improve --recurse-submodules support

On Wednesday 02 December 2015 at 15:21:13 -0800, Junio C Hamano wrote: > Mike Crowe <m...@mcrowe.com> writes: > > > b33a15b08131514b593015cb3e719faf9db20208 added support for the > > push.recurseSubmodules config option. After it was merged Junio C Hamano > &g

Re: [PATCH v3] push: add recurseSubmodules config option

On Tuesday 01 December 2015 at 19:40:32 -0500, Jeff King wrote: > On Tue, Dec 01, 2015 at 11:49:43AM +0000, Mike Crowe wrote: > > > The --recurse-submodules command line parameter has existed for some > > time but it has no config file equivalent. > > > > Following

[PATCH] push: Improve --recurse-submodules support

one winning. (This simplified the implementation too.) Also slightly improve one of the tests added in b33a15b08131514b593015cb3e719faf9db20208. Signed-off-by: Mike Crowe <m...@mcrowe.com> --- builtin/push.c | 12 +++- t/t5531-deep-submodule-push.s

[PATCH v3] push: add recurseSubmodules config option

-submodules=no to allow the configuration to be overridden on the command line when required. The most straightforward way to implement this appears to be to make push use code in submodule-config in a similar way to fetch. Signed-off-by: Mike Crowe <m...@mcrowe.com> --- Changes in v3: * Incor

Re: [PATCH] push: add recurseSubmodules config option

On Monday 30 November 2015 at 10:31:26 -0800, Junio C Hamano wrote: > Mike Crowe <m...@mcrowe.com> writes: > > > diff --git a/builtin/push.c b/builtin/push.c > > index 3bda430..dfced74 100644 > > --- a/builtin/push.c > > +++ b/builtin/push.c > >

[PATCHv2] push: add recurseSubmodules config option

of --recurse-submodules=no to allow the configuration to be overridden on the command line when required. The most straightforward way to implement this appears to be to make push use code in submodule-config in a similar way to fetch. Signed-off-by: Mike Crowe <m...@mcrowe.com> --- Documen

Re: [PATCH 0/5] ff-refs: builtin command to fast-forward local refs

On Tue, Nov 17, 2015 at 10:28 AM, Michael J Gruber <g...@drmicha.warpmail.net> wrote: > Mike Rappazzo venit, vidit, dixit 17.11.2015 14:58: > > I still don't like the idea of having a new command just for the purpose > of fast-forwarding local branches from specified upstreams

[PATCH] push: add recurseSubmodules config option

of --recurse-submodules=no to allow the configuration to be overridden on the command line when required. The most straightforward way to implement this appears to be to make push use code in submodule-config in a similar way to fetch. Signed-off-by: Mike Crowe <m...@mcrowe.com> --- Documen

Re: [PATCH] push: add recurseSubmodules config option

; > > + git commit -m "Recurse on-demand on command line for > > gar/bage" && > > + git push --recurse-submodules=on-demand ../pub.git master && > > + # Check that the supermodule commit got there > > +

Re: [PATCH 0/5] ff-refs: builtin command to fast-forward local refs

On Wed, Nov 11, 2015 at 5:41 AM, Michael J Gruber wrote: > Michael Rappazzo venit, vidit, dixit 11.11.2015 03:11: >> This patch series is built on (based on) 'next' because it relies on >> worktree.c >> >> `ff-refs` will update local branches which can be fast-forwarded

Re: [BUG] Wrong worktree path when using multiple worktree

On Tue, Nov 3, 2015 at 11:58 AM, Nicolas Morey-Chaisemartin wrote: > Hi, > > There seem to be an issue with the path computed for a worktree when multiple > worktree were created (using git worktree) > In my Setup, I have 3 repos: > A/repo (main One) >

Re: [BUG] Wrong worktree path when using multiple worktree

On Tue, Nov 3, 2015 at 5:27 PM, Mike Rappazzo <rappa...@gmail.com> wrote: > On Tue, Nov 3, 2015 at 11:58 AM, Nicolas Morey-Chaisemartin > <nico...@morey-chaisemartin.com> wrote: >> Hi, >> >> There seem to be an issue with the path computed for a worktree whe

Re: Feature request: commit count in git-describe should use a different method

ot;. If your branch had been merged into v1.2, and you merged v1.2 back, then you would have a lower count. One way to look at it is that the count tells you how much your branch differs from the tag, and 97 is a more realistic indicator of the amount of difference between the tag and your bran

Re: What's the ".git/gitdir" file?

On Tue, Oct 27, 2015 at 6:54 PM, Junio C Hamano wrote: > Kyle Meyer writes: > >> When a ".git" file points to another repo, a ".git/gitdir" file is >> created in that repo. >> >> For example, running >> >> $ mkdir repo-a repo-b >> $ cd repo-a >> $

Re: How to rebase when some commit hashes are in some commit messages

On Tue, Oct 13, 2015 at 1:07 PM, Jacob Keller wrote: > On Tue, Oct 13, 2015 at 6:29 AM, Philip Oakley wrote: >> My tuppence is that the only sha1's that could/would be rewritten would be >> those for the commits within the rebase. During rebasing it

[PATCH v6] notes: allow treeish expressions as notes ref

, or will be updated. With this change, operations that use notes read-only can be fed any notes-shaped tree-ish can be used, e.g. git log --notes=notes@{1}. Signed-off-by: Mike Hommey <m...@glandium.org> --- I'm really not satisfied with the documentation change, but I don't have a better id

Re: [PATCH] notes: Allow treeish expressions as notes ref

stinction: $ ./git-log --notes=fdsfgsfdg HEAD^! --pretty=short warning: notes ref refs/notes/fdsfgsfdg is invalid commit e5b68b2e879608d881c2e3600ce84962fcdefc88 Author: Mike Hommey <m...@glandium.org> notes: allow treeish expressions as notes ref $ ./git-log --notes=foo HEAD

Re: What's cooking in git.git (Oct 2015, #01; Mon, 5)

On Tue, Oct 6, 2015 at 1:55 AM, Junio C Hamano wrote: > Torsten Bögershausen writes: > >> Minor comment from my compiler: >> >> worktree.c:181: warning: assuming signed overflow does not occur when >> assuming >> that (X + c) > X is always true > > Thanks; I

[BUG] Broken link in the git basics introduction

I was reading the git introduction in the git-scm website and the link inside the section 'Git Generally Only Adds Data' (Undoing Things) was broken. Webpage: https://git-scm.com/book/en/v2/Getting-Started-Git-Basics Broken link: https://git-scm.com/book/en/v2/1-git-basics/_undoing -- To

Re: Convenient shortcut to push delete current branch?

On Thu, Oct 1, 2015 at 2:37 PM, Robert Dailey wrote: > On Thu, Oct 1, 2015 at 1:22 PM, Jacob Keller wrote: >> On Thu, Oct 1, 2015 at 9:43 AM, Robert Dailey >> wrote: >>> For convenient pushing of current branch, git

Re: can't install on OS X

Looks like you have it installed properly. The typical usage is from the terminal, (try `git --version` to be sure). There is also a pretty great UI packaged with git called git-gui. You should be able to make a link or an alias to it in your Applications folder (or invoke it from the terminal

Re: [PATCH v8 4/4] worktree: add 'list' command

On Tue, Sep 22, 2015 at 3:42 PM, Junio C Hamano wrote: > Michael Rappazzo writes: > >> >> +--porcelain:: >> + With `list`, output in an easy-to-parse format for scripts. >> + This format will remain stable across Git versions and regardless of >>

Re: [PATCH v7 1/3] worktree: add top-level worktree.c

On Wed, Sep 16, 2015 at 4:32 PM, Eric Sunshine <sunsh...@sunshineco.com> wrote: > On Mon, Sep 14, 2015 at 8:20 AM, Mike Rappazzo <rappa...@gmail.com> wrote: >> On Sat, Sep 12, 2015 at 10:39 PM, Eric Sunshine <sunsh...@sunshineco.com> >> wrote: >>>&g

Re: [PATCH v7 2/3] worktree: move/refactor find_shared_symref from branch.c

On Wed, Sep 16, 2015 at 5:09 PM, Eric Sunshine <sunsh...@sunshineco.com> wrote: > On Mon, Sep 14, 2015 at 1:44 PM, Mike Rappazzo <rappa...@gmail.com> wrote: >> On Sat, Sep 12, 2015 at 11:19 PM, Eric Sunshine <sunsh...@sunshineco.com> >> wrote: >>> On Fri

Re: [PATCH 0/2] notes: allow read only notes actions on refs outside of refs/notes

fs/notes. I haven't found the time to finish that topic yet, but I haven't forgotten it. Sorry about that. Mike -- 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 v7 1/3] worktree: add top-level worktree.c

On Sat, Sep 12, 2015 at 10:39 PM, Eric Sunshine wrote: > I realize that this is modeled closely after existing code in > branch.c, but, with the exception of parsing the ref file and > constructing a worktree structure, the main worktree case (id == NULL) > is entirely

Re: [PATCH v7 2/3] worktree: move/refactor find_shared_symref from branch.c

On Sat, Sep 12, 2015 at 11:19 PM, Eric Sunshine wrote: > On Fri, Sep 4, 2015 at 5:39 PM, Michael Rappazzo wrote: >> The code formerly in branch.c was largely the basis of the >> get_worktree_list implementation is now moved to worktree.c, >> and the

Re: [PATCH v7 2/3] worktree: move/refactor find_shared_symref from branch.c

On Fri, Sep 11, 2015 at 12:16 PM, Junio C Hamano wrote: > Michael Rappazzo writes: > >> The code formerly in branch.c was largely the basis of the >> get_worktree_list implementation is now moved to worktree.c, >> and the find_shared_symref implementation

Re: [PATCH v7 1/3] worktree: add top-level worktree.c

On Thu, Sep 10, 2015 at 4:04 PM, Junio C Hamano wrote: > Michael Rappazzo writes: > >> Including functions to get the list of all worktrees, and to get >> a specific worktree (primary or linked). > > Was this meant as a continuation of the sentence started

Re: [PATCH v7 2/3] worktree: move/refactor find_shared_symref from branch.c

On Fri, Sep 11, 2015 at 7:10 PM, Eric Sunshine wrote: > On Fri, Sep 11, 2015 at 5:52 PM, Junio C Hamano wrote: > > Thanks for bringing this up. I haven't found a sufficient block of > time yet to review these patches, however, I had the same thought

Re: [PATCH v6 1/2] worktree: add 'for_each_worktree' function

On Mon, Aug 31, 2015 at 1:11 AM, Eric Sunshine wrote: > Thanks for working on this. I apologize for not reviewing earlier > rounds (other than v2 [1]); it's been difficult to find a block of > time to do so... I appreciate your time and comments. > > On Sun, Aug 30,

Re: [PATCH v6 1/2] worktree: add 'for_each_worktree' function

On Mon, Aug 31, 2015 at 3:47 PM, Eric Sunshine <sunsh...@sunshineco.com> wrote: > On Mon, Aug 31, 2015 at 2:57 PM, Mike Rappazzo <rappa...@gmail.com> wrote: >> I wasn't sure that a bare repo would be considered a worktree. I >> don't think that it would b

Re: [PATCH 1/2 v4] worktree: add 'for_each_worktree' function

I will reroll this series with adjustments as you suggested, and I will add the extra tests for bare repos. On Thu, Aug 13, 2015 at 3:23 PM, David Turner dtur...@twopensource.com wrote: The scope of d can be smaller; move it down to the place I've marked below I have adjusted the scoping. I

Re: [PATCH v3] worktree: add 'list' command

On Mon, Aug 10, 2015 at 6:10 PM, Junio C Hamano gits...@pobox.com wrote: Michael Rappazzo rappa...@gmail.com writes: +static int list(int ac, const char **av, const char *prefix) +{ + int main_only = 0; + struct option options[] = { + OPT_BOOL(0, main-only, main_only,

Re: [PATCH v3] worktree: add 'list' command

On Mon, Aug 10, 2015 at 10:55 PM, David Turner dtur...@twopensource.com wrote: On Mon, 2015-08-10 at 16:53 -0400, Michael Rappazzo wrote: + while ((d = readdir(dir)) != NULL) { I think it would be useful to break this loop out into a for_each_worktree function. While

Re: [PATCH] worktree: list operation

Withdrawn -- I staged but did not amend the final commit. I will adjust and resend. On Sat, Aug 8, 2015 at 4:34 PM, Michael Rappazzo rappa...@gmail.com wrote: 'git worktree list' will list the main worktree followed by any linked worktrees which were created using 'git worktree add'. The

Re: fetching from an hg remote fails with bare git repositories

, you may want to give a try to https://github.com/glandium/git-cinnabar. Anyways, your error looks like what I fixed in 33cae54, which git describe tells me made it to git 2.3.2. Mike -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord

Can we get a git clone flag to override the required empty directory behaviour?

-empty directory. If there already was a .git directory in that directory, sure that's a no-go scenario. An with a name like --force, it should be aggressive, overwriting anything it sees. Again, git can already do this, it's just a lot more long winded that it should be. Thanks, Mike Kasprzak

Re: git send-email Connection Closed

I believe that this is due to gmail not allowing the email. I think there are two ways to fix this: 1. Temporarily enable less secure apps for your gmail account while you send the email [see here](https://support.google.com/accounts/answer/6010255?hl=en). 2. Setup multi-factor authentication

Re: [PATCH] notes: Allow treeish expressions as notes ref

On Mon, Jul 13, 2015 at 09:35:40AM -0700, Junio C Hamano wrote: Mike Hommey m...@glandium.org writes: init_notes() is the main point of entry to the notes API. It is an arbitrary restriction that all it allows as input is a strict ref name, when callers may want to give an arbitrary

[PATCH] notes: Allow treeish expressions as notes ref

of enabling the use of treeish as notes refs in commands allowing them, e.g. git log --notes=foo@{1}. Signed-off-by: Mike Hommey m...@glandium.org --- builtin/notes.c | 29 - notes-cache.c| 11 ++- notes-utils.c| 6 +++--- notes.c | 11

Re: [PATCH v4] notes: Allow treeish expressions as notes ref

On Fri, Jul 10, 2015 at 09:16:16AM +0200, Johan Herland wrote: On Fri, Jul 10, 2015 at 3:28 AM, Mike Hommey m...@glandium.org wrote: init_notes() is the main point of entry to the notes API. It is an arbitrary restriction that all it allows as input is a strict ref name, when callers may

[PATCH v4] notes: Allow treeish expressions as notes ref

of enabling the use of treeish as notes refs in commands allowing them, e.g. git log --notes=foo@{1}. Signed-off-by: Mike Hommey m...@glandium.org Reviewed-by: Johan Herland jo...@herland.net --- builtin/notes.c | 29 - notes-cache.c | 11 ++- notes-utils.c

[PATCH] fast-import: Do less work when given from matches current branch head

the tree when it's unmodified, and avoid calling gfi_unpack_entry when the given mark points to the same commit as the current branch head. Signed-off-by: Mike Hommey m...@glandium.org --- fast-import.c | 29 + 1 file changed, 17 insertions(+), 12 deletions(-) diff

Re: [PATCH] fast-import: Do less work when given from matches current branch head

On Thu, Jul 09, 2015 at 01:37:02PM -0700, Junio C Hamano wrote: Mike Hommey m...@glandium.org writes: Cc'ed a few people who appear at the top of shortlog --no-merges; I think the end result is not incorrect, but I want to hear second opinions on this one. I do not know Shawn still

[PATCH v2 - RFH] notes: Allow committish expressions as notes ref

effect of enabling the use of committish as notes refs in commands allowing them, e.g. git log --notes=foo@{1}. Signed-off-by: Mike Hommey m...@glandium.org --- The die() message in init_notes is left to be desired. But I don't have a better idea at the moment. Note that die()ing in an API

Re: suboptimal behavior of fast-import in some cases with from

On Mon, Jul 06, 2015 at 03:54:35PM -0700, Junio C Hamano wrote: Mike Hommey m...@glandium.org writes: One of the first things parse_from does is unconditionally throw away the tree for the given branch, and then the from tree is loaded. So when the from commit is the current head

[PATCH v3] notes: Allow committish expressions as notes ref

effect of enabling the use of committish as notes refs in commands allowing them, e.g. git log --notes=foo@{1}. Signed-off-by: Mike Hommey m...@glandium.org --- builtin/notes.c | 29 - notes-cache.c | 11 ++- notes-utils.c | 6 +++--- notes.c | 11

Re: suboptimal behavior of fast-import in some cases with from

On Thu, Jul 09, 2015 at 02:03:15PM +0900, Mike Hommey wrote: On Mon, Jul 06, 2015 at 03:54:35PM -0700, Junio C Hamano wrote: Mike Hommey m...@glandium.org writes: One of the first things parse_from does is unconditionally throw away the tree for the given branch, and then the from tree

suboptimal behavior of fast-import in some cases with from

in gfi_unpack_entry is triggered, which, on mac, is extra slow (and explains the huge slow down there). Now, I do understand that my script is doing something stupid. So the question is whether it's worth fixing in fast-import or not. I already fixed my script anyways. Mike -- To unsubscribe from this list

<    1   2   3   4   5   >