On Tue, Jun 16, 2015 at 11:22:31PM -0400, Jeff King wrote:
> On Wed, Jun 17, 2015 at 10:15:31AM +0900, Mike Hommey wrote:
>
> > init_notes() is essentially the only point of entry to the notes API.
> > It is an arbitrary restriction that all it allows as input is a strict
On Tue, Jun 16, 2015 at 08:17:03PM -0700, Junio C Hamano wrote:
> Mike Hommey writes:
>
> > init_notes() is essentially the only 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 w
o the user. This change pre-emptively checks so we can exit
with a helpful error if necessary.
Signed-off-by: Mike Edgar
---
fetch-pack.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fetch-pack.c b/fetch-pack.c
index a912935..a136772 100644
--- a/fetch-pack.c
+++ b/fetch-p
o the user. This change pre-emptively checks so we can exit
with a helpful error if necessary.
Signed-off-by: Mike Edgar
Acked-by: Jeff King
---
fetch-pack.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fetch-pack.c b/fetch-pack.c
index 48526aa..849a9d6 100644
--- a/fetch-p
On Wed, Jun 17, 2015 at 3:41 PM, Junio C Hamano wrote:
> Michael Rappazzo writes:
>
>> For some mergetools, the current invocation of git mergetool will
>> include an auto-merge flag. By default the flag is included, however if
>> the git config option 'merge.automerge' is set to 'false', then t
On Thu, Jun 18, 2015 at 4:43 AM David Aguilar wrote:
>
> On Wed, Jun 17, 2015 at 10:27:58PM -0400, Mike Rappazzo wrote:
> >
> > I feel that the auto-merge takes away the context of the changes.
> >
> > I use araxis merge as my mergetool of choice. I almost always
work than necessary.
Even more so when the pack flush code 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
is has the side 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
---
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 is n
is has the side 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
---
builtin/notes.c | 29 -
notes-cache.c | 11 ++-
notes-utils.c | 6 +++---
notes
On Mon, Jul 06, 2015 at 03:54:35PM -0700, Junio C Hamano wrote:
> Mike Hommey 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&qu
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 writes:
> >
> > > One of the first things parse_from does is unconditionally throw away
> > > the tree for the given br
cularly slow at least on OSX.
So, avoid resetting 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
---
fast-import.c | 29 +
1 file changed, 17 inse
On Thu, Jul 09, 2015 at 01:37:02PM -0700, Junio C Hamano wrote:
> Mike Hommey 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 k
the side effect 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
Reviewed-by: Johan Herland
---
builtin/notes.c | 29 -
notes-cache.c | 11 ++-
notes-utils.c | 6 +++---
notes
On Fri, Jul 10, 2015 at 09:16:16AM +0200, Johan Herland wrote:
> On Fri, Jul 10, 2015 at 3:28 AM, Mike Hommey 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
>
the side effect 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
---
builtin/notes.c | 29 -
notes-cache.c| 11 ++-
notes-utils.c| 6 +++---
notes.c | 11 +
On Mon, Jul 13, 2015 at 09:35:40AM -0700, Junio C Hamano wrote:
> Mike Hommey 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 g
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 o
t allowing you to clone in to a
non-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 tha
82ee36b3e1bec1db8db24817270080424e
2e6e3e829f3759823d70e7af511bc04cd05ad0af
At 7 digits, there are 5 actual commit collisions in the git repo and
718 in the kernel repo only one of those collisions involve more than 2
commits.
Mike
On Wed, Oct 12, 2016 at 6:50 AM, wrote:
> Hi.
>
> I created a new branch named hotfix from master.
> I switched to the branch, changed 1 file.
>
> Now I want to see the diff from the both using
>
> git diff hotfix master
>
> I do not see any output (difference).
> When I do a git status I see my
the same if I remove
my .gitconfig file.
I am on Arch Linux, with all of my software updated to the latest
versions as of this morning. git 2.9.3 and lower works perfectly.
Any ideas?
Thanks,
Mike
On Wed, Nov 16, 2016 at 10:16 AM, Vanderhoof, Tzadik
wrote:
> When I do: "git merge -h" to get help, the option "--no-ff" is left out of
> the list of options.
I am running git version 2.10.0, and running git merge --help contains
these lines:
--ff
When the merge resolves as
ents (like '--ff'), there is an automatic counter
argument with "no-" in there ('--no-ff') to disable the option. Maybe
it would make sense to word the output to include both.
>
> -Original Message-
> From: Mike Rappazzo [mailto:rappa...@gmail.com]
>
Refactor send_message() to remove dependency on deprecated
Net::SMTP::SSL:
<http://search.cpan.org/~rjbs/Net-SMTP-SSL-1.04/lib/Net/SMTP/SSL.pm#DEPRECATED>
Signed-off-by: Mike Fisher
---
git-send-email.perl | 54
+
1 file chang
Greetings,
git-daemon went broke on me post v2.9.3 due to binaries being installed
in /usr/lib/git, which is not in PATH. Reverting 650c449250d7 fixes it
up, as does ln -s /usr/lib/git/git-daemon /usr/bin/git-daemon 'course,
but thought I should report it, since it used to work without that.
Pro
On Sat, 2016-11-26 at 12:09 -0500, Jeff King wrote:
> On Sat, Nov 26, 2016 at 03:03:48PM +0100, Mike Galbraith wrote:
>
> > git-daemon went broke on me post v2.9.3 due to binaries being installed
> > in /usr/lib/git, which is not in PATH. Reverting 650c449250d7 fixes it
>
r pushing merges, with caveats. See
https://github.com/glandium/git-cinnabar/issues/20 for details about
the current status.
And since I realize I didn't announce beta 3:
What's new since 0.4.0b2?
- Properly handle bundle2 errors, avoiding git to believe a push
happened when it didn't. (0.3.x is unaffected)
Mike
for the second revision walk to work.
So the question is, are consumers supposed to reset those flags on their
own, or should reset_revision_walk clear them?
Mike
On Mon, Dec 05, 2016 at 08:09:58AM +0900, Mike Hommey wrote:
> Hi,
>
> While trying to use the revision walking API twice in a row, I noticed
> that the second time for the same setup would not yield the same result.
> In my case, it turns out I was requesting
ually.
Signed-off-by: Mike Hommey
---
This is something I should have submitted a patch for a long time ago, back
when this was discussed in the thread starting from
https://www.spinics.net/lists/git/msg242426.html. The message most relevant to
this patch in the thread is https://www.spinics.net/l
ifests`. If they contain sha1
mismatches, please reclone.
- Updated git to 2.11.0 for cinnabar-helper
- Improvements to the `git cinnabar download` command
- Various small code cleanups
- Improvement to the experimental support for pushing merges.
Mike
On Tue, Dec 20, 2016 at 05:47:44PM +0900, Mike Hommey wrote:
> Hi,
>
> Git-cinnabar is a git remote helper to interact with mercurial
> repositories. It allows to clone, pull and push from/to mercurial remote
> repositories, using git.
>
> Code on https://github.com/glandiu
On Tue, Dec 20, 2016 at 11:34:04AM -0800, Junio C Hamano wrote:
> Mike Hommey writes:
>
> > In typical uses of fast-import, trees are inherited from a parent
> > commit. In that case, the tree_entry for the branch looks like:
> > ...
> > +# Create another notes tr
ually.
Signed-off-by: Mike Hommey
---
fast-import.c| 8 +---
t/t9301-fast-import-notes.sh | 42 ++
2 files changed, 47 insertions(+), 3 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index cb545d7df5..5e528b1999 100644
--- a/f
Sorry, I forgot the v2 in the subject.
Mike
an argument could be made that null_sha1 should be treated
specially at a lower level (read_sha1_file, I guess).
What would be sensible to do here?
Mike
d, 1 deletion(-)
I'm actually not sure what the right thing would be. I guess this is a
case where -B should help, but it doesn't.
Any thoughts?
Mike
with other
options (I'm thinking e.g. -i, but -i already has a problem with
--preserve-merges). But it does seem like it would be a worthwhile
improvement.
What do you think?
Mike
tion it in case if spurs any brilliance.
Something that is kind-of in the same family of problems is the
"loosening" or objects on repacks, before they can be pruned.
When you have a large repository and do large rewrite operations
(extreme case, a filter-branch on a multi-hundred-thousands commits),
and you gc for the first time, git will possibly create a *lot* of loose
objects, each of which will consume an inode and a file system block. In
the extreme case, you can end up with git gc filling up multiple extra
gigabytes on your disk.
Mike
caveats. See
https://github.com/glandium/git-cinnabar/issues/20 for details about
the current status.
- Fail graft earlier when no commit was found to graft
- Allow graft to work with git version < 1.9
- Allow `git cinnabar bundle` to do the same grafting as git push
Mike
gpg.
With this change applied, the output becomes, on this new machine:
gpg: keyblock resource '/usr/share/keyrings/debian-keyring.gpg': No
such file or directory
error: gpg failed to sign the data
error: unable to sign the tag
which makes it clearer what's wrong.
Signed-off-
On Wed, Jan 25, 2017 at 03:04:38PM -0800, Junio C Hamano wrote:
> Mike Hommey writes:
>
> > For instance, after changing my laptop for a new one, I copied my
> > configs, but had some environment differences that broke gpg.
> > With this change applied, the output beco
On Wed, Jan 25, 2017 at 06:37:55PM -0800, Junio C Hamano wrote:
> Mike Hommey writes:
>
> > On Wed, Jan 25, 2017 at 03:04:38PM -0800, Junio C Hamano wrote:
> > ...
> >> Overall I think this is a good thing to do. Instead of eating the
> >> status output, sho
On Tue, Feb 07, 2017 at 06:49:24PM -0800, Linus Torvalds wrote:
> On Tue, Feb 7, 2017 at 6:40 PM, Mike Hommey wrote:
> >
> > As such, the default positive match should be ':/' (which is shorter and
> > less cumbersome than ':(top)', btw)
>
> S
that way if people
> think that makes sense.
>
> Comments?
It seems to me that `git diff` and `git diff -- :^stuff` should have the
same output if there aren't changes in stuff, and `git diff` does the
same as `git diff -- :/` if you are in a subdirectory, not the same as
`git diff .`.
As such, the default positive match should be ':/' (which is shorter and
less cumbersome than ':(top)', btw)
Mike
On Thu, Feb 9, 2017 at 4:48 AM, Duy Nguyen wrote:
> On Wed, Feb 8, 2017 at 7:17 PM, Johannes Schindelin
> wrote:
>> In addition to making git_path() aware of certain file names that need
>> to be handled differently e.g. when running in worktrees, the commit
>> 557bd833bb (git_path(): be aware of
On Thu, Feb 9, 2017 at 5:54 PM, Junio C Hamano wrote:
>
> That leaves what the right single-step behaviour change should be.
> As I recall Duy said something about --common-dir and other things
> Mike's earlier change also covered, I'd prefer to leave it to three
> of you to figure out what the fi
o->mode) ||
diff_populate_filespec(p->one, CHECK_SIZE_ONLY) ||
diff_populate_filespec(p->two, CHECK_SIZE_ONLY) ||
(p->one->size != p->two->size) ||
!diff_filespec_is_identical(p->one, p->two)) /* (2) */
p->skip_stat_unmatc
On Friday 17 February 2017 at 14:05:17 -0800, Junio C Hamano wrote:
> Mike Crowe writes:
>
> > If "git diff --quiet" finds it necessary to compare actual file contents,
> > and a file requires CRLF conversion, then it incorrectly exits with an exit
> > co
On Friday 17 February 2017 at 22:19:58 +, Mike Crowe wrote:
> On Friday 17 February 2017 at 14:05:17 -0800, Junio C Hamano wrote:
> > Mike Crowe writes:
> >
> > > If "git diff --quiet" finds it necessary to compare actual file contents,
> > > a
Signed-off-by: Mike Hommey
---
connect.c | 54 --
1 file changed, 36 insertions(+), 18 deletions(-)
diff --git a/connect.c b/connect.c
index 4be06f4..0819c25 100644
--- a/connect.c
+++ b/connect.c
@@ -588,11 +588,13 @@ static char *get_port
however preserve hostandport, at least for now.
Note that in git_tcp_connect_sock, the port was set to "" in a
case that never can happen, so that code path was removed.
Signed-off-by: Mike Hommey
---
connect.c | 47 +++
1 file changed, 23
e, re-derive one from the host and port variables.
This will allow to refactor parse_connect_url() to return separate host
and port strings.
Signed-off-by: Mike Hommey
---
connect.c | 31 +++
1 file changed, 23 insertions(+), 8 deletions(-)
diff --git a/connect.c b/conn
Changes from v7:
- Fixed comments.
Mike Hommey (9):
connect: document why we sometimes call get_port after
get_host_and_port
connect: call get_host_and_port() earlier
connect: re-derive a host:port string from the separate host and port
variables
connect: make parse_connect_url
the "user@" part of the host, in order to pick the port
properly.
Signed-off-by: Mike Hommey
---
connect.c | 47 ---
t/t5500-fetch-pack.sh | 32 +---
2 files changed, 49 insertions(+), 30 deletions(-)
di
Signed-off-by: Mike Hommey
---
connect.c | 108 +-
1 file changed, 58 insertions(+), 50 deletions(-)
diff --git a/connect.c b/connect.c
index 9aea3cd..076ae09 100644
--- a/connect.c
+++ b/connect.c
@@ -684,6 +684,61 @@ static enum
Currently, urls of the for git://user@host don't work because user@host
is not resolving at the DNS level, but we shouldn't be relying on it
being an invalid host name, and actively reject it for containing a
username in the first place.
Signed-off-by: Mike Hommey
---
connect.c | 3 +
Signed-off-by: Mike Hommey
---
connect.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/connect.c b/connect.c
index c53f3f1..6e520c3 100644
--- a/connect.c
+++ b/connect.c
@@ -742,6 +742,13 @@ struct child_process *git_connect(int fd[2], const char
*url
Previous changes made both branches handling CONNECT_DIAG_URL identical.
We can now remove one of those branches and have CONNECT_DIAG_URL be
handled in one place.
Signed-off-by: Mike Hommey
---
connect.c | 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
diff --git a
Signed-off-by: Mike Hommey
---
connect.c | 6 ++
t/t5500-fetch-pack.sh | 14 --
2 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/connect.c b/connect.c
index 0819c25..0c4d23b 100644
--- a/connect.c
+++ b/connect.c
@@ -714,10 +714,8 @@ struct
that it needs
> to be made automatic such that when I `git add foo.rb` it is
> automatically made executable.
Moreover, *.sh, *.rb, etc. are not necessarily meant to be executables.
The files might be modules, included from executables or other modules.
There's an example of this right in the git
On Fri, May 27, 2016 at 5:06 PM, Junio C Hamano wrote:
> Michael Rappazzo writes:
>
>> For those who use two-factor authentication with gmail, git-send-email
>> will not work unless it is setup with an app-specific password. The
>> example for setting up git-send-email for use with gmail will now
On Fri, May 27, 2016 at 04:24:20PM +0200, Torsten Bögershausen wrote:
> On 27.05.16 04:27, Mike Hommey wrote:
> > Changes from v7:
> > - Fixed comments.
> >
> > Mike Hommey (9):
> > connect: document why we sometimes call get_port after
> >
On Sat, May 28, 2016 at 07:02:01AM +0200, Torsten Bögershausen wrote:
> On 27.05.16 23:59, Mike Hommey wrote:
> > On Fri, May 27, 2016 at 04:24:20PM +0200, Torsten Bögershausen wrote:
> >> On 27.05.16 04:27, Mike Hommey wrote:
> >>> Changes from v7:
> >>>
On Sat, May 28, 2016 at 10:17:19AM +0200, Torsten Bögershausen wrote:
> On 28.05.16 07:33, Mike Hommey wrote:
> > On Sat, May 28, 2016 at 07:02:01AM +0200, Torsten Bögershausen wrote:
> >> On 27.05.16 23:59, Mike Hommey wrote:
> >>> On Fri, May 27, 2016 at 04:24:20
round alloc such that it's always a multiple
of, say, 4, and stick flags in the low, unused bits.
Whether it's worth doing is another question.
Mike
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
Mor
On Tue, May 31, 2016 at 12:46:23AM +0200, William Duclot wrote:
> Mike Hommey writes:
> >> struct strbuf {
> >> + unsigned int flags;
> >>size_t alloc;
> >>size_t len;
> >>char *buf;
> >> };
> >
> > Depending wh
to me why he wants to remove the
comment about [].
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
test this is to
check that the parser thinks the output for it is host=example.com:123
port=NONE. Which sounds like an awful way to check for this.
(Also, the discussion back then was about
git://[example.com:123]:/path/to/repo, not
git://[example.com:123]/path/to/repo)
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
On Fri, Jun 03, 2016 at 04:47:33PM -0700, Junio C Hamano wrote:
> Mike Hommey writes:
>
> > In fact, the parser doesn't even reject the one that is considered
> > invalid (the first).
>
> My question was what the desired behaviour is, and if your "fix"
>
On Sat, Jun 04, 2016 at 04:51:28PM +0200, Torsten Bögershausen wrote:
> On 2016-06-04 07.14, Mike Hommey wrote:
> > On Fri, Jun 03, 2016 at 04:47:33PM -0700, Junio C Hamano wrote:
> >> Mike Hommey writes:
> >>
> >>> In fact, the parser doesn't even rej
connect: re-derive a host:port string from the separate host and port
> variables
> - connect: call get_host_and_port() earlier
> - connect: document why we sometimes call get_port after get_host_and_port
>
> Ok, folks, is everybody happy with this version?
Good for me, thanks.
series)
Does this mean you're going to fork/exec() a new for each of
these? It would probably be better if it was "batched", where the
executable is invoked once and the commands are passed to its stdin.
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
On Wed, Jun 8, 2016 at 8:31 AM, Eric Frederich wrote:
> Thanks for confirming. I do a similar workaround too.
> The issue is when new Git users don't even have a ~/.config/git/gitk to
> modify.
> They first have to run it natively where lime exists, then they can
> edit it and use it over VNC.
>
> - completion: factor out untracked file modes into a variable
>
> The completion script (in contrib/) learned to complete "git
> status" options.
>
>
> * tr/doc-tt (2016-06-08) 4 commits
> - doc: change configuration variables format
> - doc: more consistency in environment variables format
> - doc: change environment variables format
> - doc: clearer rule about formatting literals
>
> The documentation set has been updated so that literal commands,
> configuration variables and environment variables are consistently
> typeset in fixed-width font and bold in manpages.
>
> Will merge to 'next'.
>
>
> * vs/prompt-avoid-unset-variable (2016-06-06) 1 commit
> - git-prompt.sh: Don't error on null ${ZSH,BASH}_VERSION, $short_sha
>
> The git-prompt scriptlet (in contrib/) was not friendly with those
> who uses "set -u", which has been fixed.
>
>
> * rj/compat-regex-size-max-fix (2016-06-06) 1 commit
> - regex: fix a SIZE_MAX macro redefinition warning
>
> A compilation fix.
>
> Will merge to 'next'.
>
>
> * bc/cocci-object-id (2016-06-06) 8 commits
> - merge-recursive: convert merge_recursive_generic to object_id
> - merge-recursive: convert leaf functions to use struct object_id
> - merge-recursive: convert struct merge_file_info to object_id
> - merge-recursive: convert struct stage_data to use object_id
> - Rename struct diff_filespec's sha1_valid member.
> - Convert struct diff_filespec to struct object_id
> - Apply standard object_id Coccinelle transformations.
> - Add basic Coccinelle transforms.
>
> Move from "unsigned char [20]" to "struct object_id" continues,
> with help from an automated tool.
>
>
> * et/add-chmod-x (2016-06-07) 1 commit
> - add: add --chmod=+x / --chmod=-x options
>
> "git update-index --add --chmod=+x file" may be usable as an escape
> hatch, but not a friendly thing to force for people who do need to
> use it regularly. "git add --chmod=+x file" can be used instead.
>
> Will merge to 'next'.
>
>
> * mh/connect (2016-06-06) 10 commits
> - connect: [host:port] is legacy for ssh
> - connect: move ssh command line preparation to a separate function
> - connect: actively reject git:// urls with a user part
> - connect: change the --diag-url output to separate user and host
> - connect: make parse_connect_url() return the user part of the url as a
> separate value
> - connect: group CONNECT_DIAG_URL handling code
> - connect: make parse_connect_url() return separated host and port
> - connect: re-derive a host:port string from the separate host and port
> variables
> - connect: call get_host_and_port() earlier
> - connect: document why we sometimes call get_port after get_host_and_port
>
> Ok, folks, is everybody happy with this version?
$gmane/296609
$gmane/296610
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
On Wed, Jun 15, 2016 at 11:32:39AM -0700, Junio C Hamano wrote:
> Mike Hommey writes:
>
> > On Tue, Jun 14, 2016 at 03:08:04PM -0700, Junio C Hamano wrote:
>
> >> * mh/connect (2016-06-06) 10 commits
> >> - connect: [host:port] is legacy for ssh
> >
s an assumption that might work for git repositories, but not for
foreign repositories imported in git (think e.g. mercurial repositories
accessed with a remote helper)
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
The are many ways in which fast-import ends up calling gfi_unpack_entry,
and fery few work-arounds. I've patched fast-import for it to be smarter
in corner cases, allowing some additional work-arounds, but it's just
too easy to fall on gfi_unpack_entry again, so I abandonned that path.
The problem
On Mon, Jul 04, 2016 at 08:44:39AM +0900, Mike Hommey wrote:
> + /* Ensure a pack window on the data before that, otherwise,
> + * use_pack() may try to create a window that overlaps with
> + * this one, and that won't work because it won
innabar without
having mercurial installed.
- Use a mercurial subprocess to access local mercurial repositories.
- Cinnabar-helper now handles fast-import, with workarounds for
performance issues on macOS.
Mike
--
To unsubscribe from this list: send the line "unsubscribe git"
change to the gender neutral
> "their_tree" after that.
You make it sound like the decision to use "his" was conscious and on
purpose. I doubt that was the case, especially 11 years ago, when these
issues weren't as publicized. Let's not attribute to malice on p
security scale.
Cheers,
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
d IIRC that's what Travis uses.
>
> However, it is possible to install a 32-bit toolchain and use that to
> compile Git.
You just need to install gcc-multilib on travis, and you can use -m32. I
did that for jemalloc recently.
See https://github.com/jemalloc/jemalloc/blob/dev/.travi
On Thu, Jul 14, 2016 at 12:58:47PM +0200, Johannes Schindelin wrote:
> Hi Mike,
>
> On Thu, 14 Jul 2016, Mike Hommey wrote:
>
> > On Thu, Jul 14, 2016 at 09:58:45AM +0200, Johannes Schindelin wrote:
> > > Hi Junio,
> > >
> > > On Wed, 13 Jul 20
When blaming files, changes in the work tree are taken into account
and displayed as being "Not Committed Yet".
However, when blaming a file that is not known to the current HEAD,
git blame fails with `no such path 'foo' in HEAD`, even when the file
was git add'ed.
This would seem uninteresting w
iated mercurial changesets e.g. hg::d4a5c8fbfc20
- providing information for --decorate
Here the idea would be the converse of the above, and would make e.g.
`git log --decorate` show hg::d4a5c8fbfc20cebcae60d1e073874d19fa47d831
or the abbreviated form hg::d4a5c8fbfc20 for the corresponding git
com
On Fri, Jul 15, 2016 at 12:45:15PM +0200, Johannes Schindelin wrote:
> Hi Mike,
>
> On Fri, 15 Jul 2016, Mike Hommey wrote:
>
> > When blaming files, changes in the work tree are taken into account
> > and displayed as being "Not Committed Yet".
> >
>
On Fri, Jul 15, 2016 at 08:37:59AM -0400, Jeff King wrote:
> On Fri, Jul 15, 2016 at 09:32:45PM +0900, Mike Hommey wrote:
>
> > > > +test_expect_success 'blame wholesale copy and more in the index' '
> > > > +
> > > > + {
> >
would seem uninteresting with the plain `git blame` case, which
it is, but it becomes useful when using copy detection, and the new file
was created from pieces already in HEAD, moved or copied from other
files.
Signed-off-by: Mike Hommey
---
builtin/blame.c | 4 ++-
t/t8003-b
;, although it
only identifies the "theirs" part of the merge conflict when blaming
the file straight out of the merge failure, but that'd be a separate
issue.
> But the user can be in the same conflicted rename situation with
> "git am -3" or cherry-pi
Somehow, this test was using:
{
echo A
echo B
} > file
block to feed file contents. This changes those to the form most common
in git test scripts:
cat >file <<-\EOF
A
B
EOF
Signed-off-by: Mike Hommey
---
t/t8003-blame-corner-c
would seem uninteresting with the plain `git blame` case, which
it is, but it becomes useful when using copy detection, and the new file
was created from pieces already in HEAD, moved or copied from other
files.
Signed-off-by: Mike Hommey
---
builtin/blame.c | 10 +-
t/t8
Hi,
Any thoughts on the following?
Mike
On Mon, Jul 04, 2016 at 08:44:39AM +0900, Mike Hommey wrote:
> The are many ways in which fast-import ends up calling gfi_unpack_entry,
> and fery few work-arounds. I've patched fast-import for it to be smarter
> in corner cases, allowing s
1?
- Some more bug fixes.
- Updated git to 2.9.2 for cinnabar-helper.
- Now supports `git push --dry-run`.
- Added a new `git cinnabar fetch` command to fetch a specific revision
that is not necessarily a head.
- Some improvements to the experimental native wire protocol support.
Mike
--
To unsubsc
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.
>> When executed from a subpath of the main
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 easy to read the branch
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 without
>> minding the environment variables and
t match)
`.*?` is a lazy match. I think it is 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"), p
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 me
101 - 200 of 551 matches
Mail list logo
