[ANNOUNCE] git-cinnabar 0.5.0

e 0.6.0. These include: - Changes in behavior. - Changes in metadata. - Stabilizing experimental features. - Remove backwards compability with older metadata (< 0.5.0). Mike

Re: Checks added for CVE-2018-11235 too restrictive?

On Wed, Jul 04, 2018 at 07:30:30AM +0900, Mike Hommey wrote: > That being said, I'm not even sure this particular use case is worth a > new feature. I'm not storing random stuff as gitlinks, I'm storing > sha1s. Well, maybe a mode that makes the distinction between "git oid"

Re: fast-import slowness when importing large files with small differences

On Tue, Jul 03, 2018 at 06:05:16PM +0200, Ævar Arnfjörð Bjarmason wrote: > > On Fri, Jun 29 2018, Mike Hommey wrote: > > > On Sat, Jun 30, 2018 at 12:10:24AM +0200, Ævar Arnfjörð Bjarmason wrote: > >> > >> On Fri, Jun 29 2018, Mike Hommey wrote: > >>

Re: Checks added for CVE-2018-11235 too restrictive?

On Tue, Jul 03, 2018 at 10:15:19AM -0400, Jeff King wrote: > On Tue, Jul 03, 2018 at 04:06:50PM +0900, Mike Hommey wrote: > > > I had a first shot at that a few months ago, but the format of the > > metadata branch made it impossible to push to github, hitting its push > &g

Re: [PATCH] fast-import: Don't count delta attempts against an empty buffer

On Tue, Jul 03, 2018 at 11:41:42AM -0700, Junio C Hamano wrote: > Mike Hommey writes: > > > When the reference buffer is empty, diff_delta returns NULL without > > really attempting anything, yet fast-import counts that as a delta > > attempt. > > But t

Checks added for CVE-2018-11235 too restrictive?

npack-objects abnormal exit To ../qux ! [remote rejected] bar -> bar (unpacker error) error: failed to push some refs to '../qux' Would it be reasonable to make the transfer.fsckObject checks ignore non-blob .gitmodules? Cheers, Mike

[PATCH] fast-import: Don't count delta attempts against an empty buffer

When the reference buffer is empty, diff_delta returns NULL without really attempting anything, yet fast-import counts that as a delta attempt. Signed-off-by: Mike Hommey --- fast-import.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fast-import.c b/fast-import.c index

Re: fast-import slowness when importing large files with small differences

On Sat, Jun 30, 2018 at 12:10:24AM +0200, Ævar Arnfjörð Bjarmason wrote: > > On Fri, Jun 29 2018, Mike Hommey wrote: > > > I noticed some slowness when fast-importing data from the Firefox mercurial > > repository, where fast-import spends more than 5 minutes importing ~2000

fast-import slowness when importing large files with small differences

has imported xdiff from the git code base into mercurial and improved performance on it, so it might also be worth looking at what's worth taking from there. Cheers, Mike

[PATCH] git-stash.txt: document show options

Signed-off-by: Mike Frysinger --- Documentation/git-stash.txt | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt index 7ef8c4791177..76e4ca788102 100644 --- a/Documentation/git-stash.txt +++ b/Documentation/git

Re: Wrong -dirty suffix set by setlocalversion (was: BUG in git diff-index)

How about something like this? It ignores attributes that should have no bearing on whether the kernel is considered dirty. Copied trees with no other changes would no longer be marked with -dirty. Plus it works on read-only media since no index updating is required. Would this also be considered

Re: commit -> public-inbox link helper

On Wed, Apr 4, 2018 at 12:35 PM, Johannes Schindelin wrote: > Hi team, > > I found myself in dear need to quickly look up mails in the public-inbox > mail archive corresponding to any given commit in git.git. Some time ago, > I wrote a shell script to help me with

RE: removed submodules shown as untracked when switching branches

Thank You. This is interesting. There seems to be also a config option submodule.recurse. I did not know that these options have such an effect on the checkout command. Best Regards, Mike -Original Message- From: Stefan Beller [mailto:sbel...@google.com] Sent: Thursday, February 22

removed submodules shown as untracked when switching branches

#On branch master #Untracked files: # (use "git add ..." to include in what will be committed) # #sub/ # #nothing added to commit but untracked files present (use "git add" to track) # expected: nothing to commit, working tree clean

[PATCH] git-worktree.txt (single char)

Missing ')' after the closing '`'. "If is a branch name (call it `` and"

Re: Git packs friendly to block-level deduplication

On Wed, Jan 24, 2018 at 02:23:57PM -0800, Junio C Hamano wrote: > Mike Hommey <m...@glandium.org> writes: > > > FWIW, I sidestep the problem entirely by using alternatives. > > That's a funny way to use the word "side-step", I would say, as the > alternate

Re: Git packs friendly to block-level deduplication

; 2. Get its commits in reverse order, produce packs of some chunk-size > of commit batches. > 3. Pack all the remaining content > > This would delta much less efficiently, but as noted above the > block-level deduplication might make up for it, and in any case some > might want to use less disk space. > > Has anyone here barked up this tree before? Suggestions? Tips on where > to start hacking the repack code to accomplish this would be most > welcome. FWIW, I sidestep the problem entirely by using alternatives. Mike

Re: Bring together merge and rebase

ention. Thanks for your > consideration. FWIW, your proposal has a lot in common (but is not quite equivalent) to mercurial's obsolescence markers and changeset evolution features. Mike

Re: git-clone causes out of memory

On Fri, Oct 13, 2017 at 12:26:46PM +0200, Christian Couder wrote: > On Fri, Oct 13, 2017 at 12:06 PM, Mike Hommey <m...@glandium.org> wrote: > > On Fri, Oct 13, 2017 at 12:51:58PM +0300, Constantine wrote: > >> There's a gitbomb on github. It is undoubtedly creative an

Re: git-clone causes out of memory

fills memory is actually the checkout part of the command. git clone -n doesn't fail. Credit should go where it's due: https://kate.io/blog/git-bomb/ (with the bonus that it comes with explanations) Mike

Re: [git-for-windows] Re: Revision resolution for remote-helpers?

On Fri, Aug 25, 2017 at 09:02:36PM +0900, Mike Hommey wrote: > On Fri, Aug 25, 2017 at 12:58:52PM +0200, Johannes Schindelin wrote: > > > > > Cc-ing the Git for Windows mailing list as an FYI. > > > > > > > > > > I have faint memori

Re: [git-for-windows] Re: Revision resolution for remote-helpers?

On Fri, Aug 25, 2017 at 12:58:52PM +0200, Johannes Schindelin wrote: > Hi Mike, > > On Thu, 24 Aug 2017, Mike Hommey wrote: > > > On Tue, Aug 22, 2017 at 10:15:20PM +0200, Johannes Schindelin wrote: > > > > > > On Fri, 18 Aug 2017, Jonathan Nieder wrote

Re: [git-for-windows] Re: Revision resolution for remote-helpers?

On Tue, Aug 22, 2017 at 10:15:20PM +0200, Johannes Schindelin wrote: > Hi, > > On Fri, 18 Aug 2017, Jonathan Nieder wrote: > > > Mike Hommey wrote[1]: > > > On Fri, Aug 18, 2017 at 03:06:37PM -0700, Jonathan Nieder wrote: > > >> Mike Hommey wrote: &g

Re: Revision resolution for remote-helpers?

On Fri, Aug 18, 2017 at 03:06:37PM -0700, Jonathan Nieder wrote: > Hi, > > Mike Hommey wrote: > > > My thought is that a string like :: could be used > > wherever a committish is expected. That would call some helper > > and request to resolve revision, and

Re: Revision resolution for remote-helpers?

On Fri, Aug 18, 2017 at 08:15:09AM -0400, Jeff King wrote: > On Fri, Aug 18, 2017 at 03:42:08PM +0900, Mike Hommey wrote: > > > I was thinking it could be useful to have a special syntax for revisions > > that would query a helper program. The helper program could use a &g

Revision resolution for remote-helpers?

y discussed reftable. On the opposite end of the problem, I'm also thinking about git log --decorate= displaying the mercurial revisions where branch decorations would normally go. I have no patch to show for it. Those are ideas that I first want to discuss before implementing anything. Thoughts? Mike

Re: [PATCH] strbuf: use designated initializers in STRBUF_INIT

e problems. For instance, MSVC only supports ##__VA_ARGS__ by way of ignoring ## somehow, but has the default behavior of dropping the comma when __VA_ARGS__ is empty, which means , __VA_ARGS__ *without* ## has a different behavior. See also https://connect.microsoft.com/VisualStudio/feedback/details/380090/variadic-macro-replacement Mike

Re: [PATCH] strbuf: use designated initializers in STRBUF_INIT

https://stackoverflow.com/questions/24090739/possible-compiler-bug-in-msvc12-vs2013-with-designated-initializer Mike

Re: [PATCH] push: add config option to --force-with-lease by default.

On Wed, Jul 5, 2017 at 12:43 PM, Francesco Mazzoli wrote: >> On 5 Jul 2017, at 17:17, Junio C Hamano wrote: >> >> The take-away lesson that the earlier thread gave me was that the >> order in which the three options are ranked by their desirebility >> in the UI

[ANNOUNCE] git-cinnabar 0.5.0b2

separately from `fsck`. - Metadata upgrade is now significantly faster. - `git cinnabar fsck` also faster. - Both now also use significantly less memory. - Updated git to 2.13.1 for git-cinnabar-helper. Mike

Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

On Thu, Jun 15, 2017 at 09:01:45AM -0400, Jeff King wrote: > On Thu, Jun 15, 2017 at 08:05:18PM +0900, Mike Hommey wrote: > > > On Thu, Jun 15, 2017 at 12:30:46PM +0200, Johannes Schindelin wrote: > > > Footnote *1*: SHA-256, as all hash functions whose output is essenti

Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

ness of SHA-256 leads to, > say, a collision attack. What do the experts think or SHA512/256, which completely removes the concerns over length extension attack? (which I'd argue is better than sweeping them under the carpet) Mike

Re: [PATCH] fast-import: Increase the default pack depth to 50

On Thu, Jun 08, 2017 at 03:05:37AM -0400, Jeff King wrote: > On Thu, Jun 08, 2017 at 02:34:36PM +0900, Mike Hommey wrote: > > > In 618e613a70, 10 years ago, the default for pack depth used for > > git-pack-objects and git-repack was changed from 10 to 50, while > > leavi

[PATCH] fast-import: Increase the default pack depth to 50

, fast-import uses pack.depth when it's set, and the git-config manual says the default for pack.depth is 50. While the git-fast-import manual does say the default depth is 10, the inconsistency is also confusing. Signed-off-by: Mike Hommey <m...@glandium.org> --- Documentation/git-fast-import.t

Re: Feature request: Please add support to stash specific files

ople need not use it if they dont want > to. Git 2.13.0 has that already. git stash -- file1 file2 Mike

[ANNOUNCE] git-cinnabar 0.5.0b1

for the .git/hgrc file for mercurial specific configuration. - Support any version of Git (was previously limited to 1.8.5 minimum) Mike

Re: [PATCH] fetch-pack: always allow fetching of literal SHA1s

ur case really is just on the client side, and > this patch fixes it. More broadly, I think it is desirable that any commit that can be reached from public refs can be fetched by an explicit sha1 without allowTipSHA1InWant. Mike

Re: [PATCH v2] rebase -i: add config to abbreviate command-names

On Tue, Apr 25, 2017 at 5:57 AM, Andreas Schwab wrote: > On Apr 25 2017, Liam Beguin wrote: > >> Add the 'rebase.abbrevCmd' boolean config option to allow `git rebase -i` >> to abbreviate the command-names in the instruction list. >> >> This means

Re: [ANNOUNCE] Git for Windows 2.12.2

Forwarding to the lists, as my original message was rejected for html. On Thu, Mar 30, 2017 at 3:44 PM, Andrew Witte wrote: > Just updated back to git 2.12.2 and git-lfs 2.0.2 and everything worked > fine. Wish I could have gotten more info when it happened as its happened

Re: [PATCH] contrib/subtree: add "--no-commit" flag for merge and pull

ommit" and "--no-commit" options in $OPTS_SPEC leads to the expected resulting argument, but I wasn't sure if both arguments should be documented, as none of the other "default" options (for instance, "--no-squash") are documented in the help output. But please

[PATCH] contrib/subtree: add "--no-commit" flag for merge and pull

Allows the user to verify and/or change the contents of the merge before committing as necessary Signed-off-by: Mike Lewis <m...@mplew.is> --- contrib/subtree/git-subtree.sh | 17 + 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/contrib/subtree/git-subtre

[PATCH] notes: Fix note_tree_consolidate not to break the note_tree structure

*. This doesn't have a practical effect on git because all that happens after a remove_note is a write_notes_tree, which just iterates the entire note tree, but this affects anything using libgit.a that would try to do lookups after removing notes. Signed-off-by: Mike Hommey <m...@glandium.

Re: RFC: Another proposed hash function transition plan

es of > being simple, already existing, and having already been ported to Java > (allowing JGit can read and write the same format). > > If that doesn't work, we'd try some other key-value store like Samba's > tdb or Kyoto Cabinet. FWIW, I'm using notes-like data to store mercurial->git mappings in git-cinnabar, (ab)using the commit type in tree items. It's fast enough. Mike

Re: Server-side hooks on non-bare repository

ys, thanks for responding, and I apologize again if my first email was poorly written and rushed. Mike Lewis > On Mar 6, 2017, at 16:42, Junio C Hamano <gits...@pobox.com> wrote: > > Mike Lewis <m...@mplew.is> writes: > >> I’m having some issues with using server-

Server-side hooks on non-bare repository

duced in 2.3.0. Thanks, and I’d be happy to provide any other information that anyone needs to take a look at this. Mike Lewis

Re: [PATCH v1 1/1] git diff --quiet exits with 1 on clean tree with CRLF conversions

Hi Torsten, Your patch has been superseded, but I thought I ought to answer your questions rather than leave them hanging. On Thursday 02 March 2017 at 19:17:00 +0100, Torsten Bögershausen wrote: > On 2017-03-01 22:25, Mike Crowe wrote: > > On Wednesday 01 March 2017 at 18:04:44 +

Re: SHA1 collisions found

ugh for it to leave a lasting impact. What if the "object version" is a hash of the content (as opposed to header + content like the normal git hash)? Mike

Re: [PATCH v1 1/1] git diff --quiet exits with 1 on clean tree with CRLF conversions

On Thursday 02 March 2017 at 10:33:59 -0800, Junio C Hamano wrote: > Mike Crowe <m...@mcrowe.com> writes: > > > All the solutions presented so far do cause a small change in behaviour > > when using git diff --quiet: they may now cause warning messages like

git status reports file modified when only line-endings have changed (was git diff --quiet exits with 1 on clean tree with CRLF conversions)

x from https://public-inbox.org/git/xmqqshmyhtnu@gitster.mtv.corp.google.com/T/#m67cbfad1f2efe721f0c2afac2a1523b743bb57ca Here's the test case. Test 3 is the part that currently fails: commit de5f3f1d9161cdd46342689abe38a046fc71850e Author: Mike Crowe <m...@mcrowe.com> Date: Sat Feb 25 09:28:37 2017 +000

Re: [PATCH v1 1/1] git diff --quiet exits with 1 on clean tree with CRLF conversions

lds of filespec > structures to skip content comparison, this bug manifests as a > false "there are differences" for a file that needs eol conversion, > for example. > > Reported-by: Mike Crowe <m...@mcrowe.com> > Helped-by: Torsten Bögershausen <tbo...@web.de>

Re: [PATCH v1 1/1] git diff --quiet exits with 1 on clean tree with CRLF conversions

0. > > Add calls to would_convert_to_git() before blindly saying that a different > size means different content. > > Reported-By: Mike Crowe <m...@mcrowe.com> > Signed-off-by: Torsten Bögershausen <tbo...@web.de> > --- > This is what I can come up with, collecting all t

Re: SHA1 collisions found

(or whatever), and fallback to treating it as > a sha1. > > Using a syntactically-obvious name like that also solves one other > problem: there are sha1 hashes whose first bytes will encode as a "this > is sha256" multihash, creating some ambiguity. Indeed, multihash only really is interesting when *all* hashes use it. And obviously, git can't change the existing sha1s. Mike

Re: git diff --quiet exits with 1 on clean tree with CRLF conversions

ot;touch -r .datetime" technique from racy-git.txt but it doesn't help. It seems that I'm unable to stop Git from using its cache without sleeping. :( diff --git a/t/t4063-diff-converted.sh b/t/t4063-diff-converted.sh new file mode 100755 index 000..31a730d --- /dev/null +++ b/t/t4063-

Re: git diff --quiet exits with 1 on clean tree with CRLF conversions

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 <m...@mcrowe.com> writes: > > > > > If "git diff --quiet" finds it necessary to compare actual file

Re: git diff --quiet exits with 1 on clean tree with CRLF conversions

On Friday 17 February 2017 at 14:05:17 -0800, Junio C Hamano wrote: > Mike Crowe <m...@mcrowe.com> writes: > > > If "git diff --quiet" finds it necessary to compare actual file contents, > > and a file requires CRLF conversion, then it incorrectly exi

git diff --quiet exits with 1 on clean tree with CRLF conversions

;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_unmatch_res

Re: [PATCH] rev-parse --git-path: fix output when running in a subdirectory

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

Re: [PATCH] rev-parse --git-path: fix output when running in a subdirectory

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,

Re: Fwd: Possibly nicer pathspec syntax?

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

Re: Fwd: Possibly nicer pathspec syntax?

On Tue, Feb 07, 2017 at 06:49:24PM -0800, Linus Torvalds wrote: > On Tue, Feb 7, 2017 at 6:40 PM, Mike Hommey <m...@glandium.org> wrote: > > > > As such, the default positive match should be ':/' (which is shorter and > > less cumbersome than ':(top)', btw) >

Re: [PATCH] gpg-interface: Add some output from gpg when it errors out.

On Wed, Jan 25, 2017 at 06:37:55PM -0800, Junio C Hamano wrote: > Mike Hommey <m...@glandium.org> 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 > &

Re: [PATCH] gpg-interface: Add some output from gpg when it errors out.

On Wed, Jan 25, 2017 at 03:04:38PM -0800, Junio C Hamano wrote: > Mike Hommey <m...@glandium.org> 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 chan

[PATCH] gpg-interface: Add some output from gpg when it errors out.

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-by: Mike Hommey

[ANNOUNCE] git-cinnabar 0.4.0

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

Re: Preserve/Prune Old Pack Files

t 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

Rebasing multiple branches at once

y has a problem with --preserve-merges). But it does seem like it would be a worthwhile improvement. What do you think? Mike

Counter-intuitive result from diff -C --stat

) 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

Corner case involving null sha1, alternates, cache misses, and submodule config API

ld be treated specially at a lower level (read_sha1_file, I guess). What would be sensible to do here? Mike

Re: [PATCH] fast-import: properly fanout notes when tree is imported

Sorry, I forgot the v2 in the subject. Mike

[PATCH] fast-import: properly fanout notes when tree is imported

. Signed-off-by: Mike Hommey <m...@glandium.org> --- 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

Re: [PATCH] fast-import: properly fanout notes when tree is imported

On Tue, Dec 20, 2016 at 11:34:04AM -0800, Junio C Hamano wrote: > Mike Hommey <m...@glandium.org> 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: > > ... > &g

Re: [ANNOUNCE] git-cinnabar 0.4.0 release candidate 2

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/

[ANNOUNCE] git-cinnabar 0.4.0 release candidate 2

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

[PATCH] fast-import: properly fanout notes when tree is imported

. Signed-off-by: Mike Hommey <m...@glandium.org> --- 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 http

Re: Should reset_revision_walk clear more flags?

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 reques

Should reset_revision_walk clear more flags?

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

[ANNOUNCE] git-cinnabar 0.4.0 release candidate

. 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

Re: git-daemon regression: 650c449250d7 common-main: call git_extract_argv0_path()

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 >

git-daemon regression: 650c449250d7 common-main: call git_extract_argv0_path()

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.

[PATCH] Remove dependency on deprecated Net::SMTP::SSL

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 <mfis...@csh.rit.edu> --- git-send-email.perl | 54 +

Re: merge --no-ff is NOT mentioned in help

(Please reply inline) On Wed, Nov 16, 2016 at 10:48 AM, Vanderhoof, Tzadik wrote: > I am running:git version 2.10.1.windows.1 > > I typed: git merge -h > > and got: > > usage: git merge [] [...] >or: git merge [] HEAD >or: git merge --abort > >

Re: merge --no-ff is NOT mentioned in help

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

git mergetool indefinite hang on version 2.10+

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

Re: git diff

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

Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits

1536dd9c61b5582cf07057cb715dd6dc6620 2e6e3e82ee36b3e1bec1db8db24817270080424e 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

[PATCH] vcs-svn/fast_export: fix timestamp fmt specifiers

Two instances of %ld being used for unsigned longs Signed-off-by: Mike Ralphson <mike.ralph...@gmail.com> --- vcs-svn/fast_export.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/vcs-svn/fast_export.c b/vcs-svn/fast_export.c index bd0f2c2..97cba39 100644 --- a/v

Bug

To whom this may concern, I found a bug in git while trying to push my website. I redid the process and it happened again. I also tried it on another computer and it happened again. I was wondering how to claim a bug? Thank you, Michael Hawes

Re: [PATCH] make rebase respect core.hooksPath if set

On Sun, Aug 14, 2016 at 12:29 PM, ryenus wrote: > Patch attached. > > It seems gmail ruined the white spaces. > Not sure how to stop gmail from doing that. > Sorry for me, and for Gmail. Did you use git-send-email? I don't think that the gmail ui works. If you have 2-factor

Re: What's cooking in git.git (Aug 2016, #02; Thu, 4)

On Mon, Aug 08, 2016 at 08:48:55AM +0200, Torsten Bögershausen wrote: > On 2016-08-05 01.32, Junio C Hamano wrote: > > Mike Hommey <m...@glandium.org> writes: > [] > > >> What kind of support are you expecting? > > > > The only rat

Re: What's cooking in git.git (Aug 2016, #02; Thu, 4)

On Thu, Aug 04, 2016 at 04:32:02PM -0700, Junio C Hamano wrote: > Mike Hommey <m...@glandium.org> writes: > > > On Thu, Aug 04, 2016 at 03:28:55PM -0700, Junio C Hamano wrote: > >> * mh/connect (2016-06-06) 10 commits > >> - connect: [host:port] is lega

Re: What's cooking in git.git (Aug 2016, #02; Thu, 4)

behaviour. > > It has been two months without any support. We may want to discard > this. What kind of support are you expecting? FWIW, I have WIP cleaning up the code further, tha obviously depends on this series. Mike -- To unsubscribe from this list: send the line "unsubscr

[ANNOUNCE] git-cinnabar 0.4.0 beta 2

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 unsubscribe from this list: send the line

Re: [PATCH/RFC] fast-import: Keep a fake pack window on the recently written data

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 some a

[PATCH v3 1/2] blame: Allow to blame paths freshly added to the index

nteresting 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 <m...@glandium.org> --- builtin/blame.c | 10 +

[PATCH v3 2/2] t/t8003-blame-corner-cases.sh: Use here documents

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 <m...@glandium.org> --- t/t8003-blame-co

Re: [PATCH] blame: Allow to blame paths freshly added to the index

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-pick, and in these cases th

[PATCH v2] blame: Allow to blame paths freshly added to the index

nteresting 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 <m...@glandium.org> --- builtin/blame.c | 4 ++- t/t8

Re: [PATCH] blame: Allow to blame paths freshly added to the index

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' ' > > > > + > > > > + { > > > > +

Re: [PATCH] blame: Allow to blame paths freshly added to the index

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". >

Re: Plugin mechanism(s) for Git?

: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 commit. Cheers, Mike -- To unsu

  1   2   3   4   5   >