confidential transaction to you.
I am SSgt Anderson Mike; I hope all is well with you? I am female
soldier working as United Nations peacekeeping troop in Afghanistan on
war against terrorism. I have in my possession the sum of $3.5million
USD Which I made here in Afghanistan 2014, I deposited this
users
> acquire the end product, some are not aware that they can contribute.
6. Newcomers don't really have any idea /what/ they could contribute.
They either have to come with their own itch to scratch, or read the
code to figure out if there's something to fix.
Mike
It is possible to end up in situations where a replace ref points to
itself. In that case, it would seem better to stop the lookup rather
than try to follow the link infinitely and fail with "replace depth too
high".
Signed-off-by: Mike Hommey
---
replace-object.c | 2 +-
1 file
commit'
Recorded preimage for 'taskcluster/ci/build/linux.yml'
(... this is where I fix my conflict ...)
$ git add -u
$ git cherry-pick --continue
error: cannot cherry-pick during a revert.
fatal: cherry-pick failed
So apparently, cherry-pick thinks it was doing a revert when it hit a
conflict?
(This is with git 2.23)
Mike
On Mon, Aug 26, 2019 at 11:14:13AM -0700, Junio C Hamano wrote:
> Mike Hommey writes:
>
> > First, revision.c doesn't come with a function to clear a struct
> > rev_info
> > Then, revision.c kind of does nasty things to commit objects...
>
> Yeah, these
On Mon, Aug 26, 2019 at 11:06:29AM -0700, Junio C Hamano wrote:
> Mike Hommey writes:
>
> > Signed-off-by: Mike Hommey
> > ---
> > packfile.c | 11 +++
> > 1 file changed, 7 insertions(+), 4 deletions(-)
> >
> > Note, I'm not sure this i
vel enough that I don't know any other library that would work for
my use case. Another is that I was hoping that in the long term, it
could be merged into git.git. I guess the more time passes, the less
likely the latter is to happen. Which is fine, but it's good to know.
Mike
Signed-off-by: Mike Hommey
---
http.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/http.c b/http.c
index 27aa0a3192..9e33584f2d 100644
--- a/http.c
+++ b/http.c
@@ -1073,6 +1073,7 @@ void http_init(struct remote *remote, const char *url,
int proactive_auth)
git_config
Signed-off-by: Mike Hommey
---
packfile.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
Note, I'm not sure this is the right place to do it.
diff --git a/packfile.c b/packfile.c
index fc43a6c52c..b0cb84adda 100644
--- a/packfile.c
+++ b/packfile.c
@@ -339,13 +339,16 @@
The index field in the commit object is used to find the buffer
corresponding to that commit in the buffer_slab. Resetting it first
means free_commit_buffer is not going to free the right buffer.
Signed-off-by: Mike Hommey
---
commit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
On Sun, Aug 25, 2019 at 02:18:18PM +0900, Mike Hommey wrote:
> When add_note is called multiple times with the same key/value pair, the
> leaf_node it creates is leaked by notes_tree_insert.
For completeness, since I realized it was missing:
Signed-off-by: Mike Hommey
Mike
_next_command() will invalidate any held pointers, making it easier
> to find bugs. In fact, we can drop the extra input lines added to the
> test case by the previous commit, as the unfixed bug would now trigger
> just from reading the commit message, even without any modified files in
>
On Sun, Aug 25, 2019 at 02:57:48AM -0400, Jeff King wrote:
> On Sun, Aug 25, 2019 at 01:13:48PM +0900, Mike Hommey wrote:
>
> > command_buf.buf is also stored in cmd_hist, so instead of
> > strbuf_release, the current code uses strbuf_detach in order to
> > "leak&quo
When add_note is called multiple times with the same key/value pair, the
leaf_node it creates is leaked by notes_tree_insert.
---
notes.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/notes.c b/notes.c
index 75c028b300..ec35f5b551 100644
--- a/notes.c
+++ b/notes.c
@@ -269
command_buf.buf is also stored in cmd_hist, so instead of
strbuf_release, the current code uses strbuf_detach in order to
"leak" the buffer as far as the strbuf is concerned.
However, strbuf_detach does more than "leak" the strbuf buffer: it
possibly reallocates it to ensure a terminating nul char
on.
>
> You can do
>
> git clone --no-checkout --filter=blob:none $url repo
TIL. Why doesn't --filter appear in the git-clone manual page?
Mike
On Fri, Jul 05, 2019 at 02:45:16PM +0900, Mike Hommey wrote:
> On Fri, Jul 05, 2019 at 01:09:55AM -0400, Jeff King wrote:
> > On Thu, Jul 04, 2019 at 07:05:30PM +0900, Mike Hommey wrote:
> > > Finally, with 1 thread, the picture changes greatly. The overall process
> >
On Fri, Jul 05, 2019 at 01:14:13AM -0400, Jeff King wrote:
> On Thu, Jul 04, 2019 at 10:13:20PM +0900, Mike Hommey wrote:
>
> > > "public-inbox-index" (reading from git, writing to Xapian+SQLite)
> > > on a dev machine got slow because core count exceeded what
On Fri, Jul 05, 2019 at 01:09:55AM -0400, Jeff King wrote:
> On Thu, Jul 04, 2019 at 07:05:30PM +0900, Mike Hommey wrote:
> > Finally, with 1 thread, the picture changes greatly. The overall process
> > takes 2.5h:
> > - 50 seconds enumerating and counting objects.
> >
On Thu, Jul 04, 2019 at 07:05:30PM +0900, Mike Hommey wrote:
> My guess is all those stalls are happening when processing the files I
> already had problems with in the past[3], except there are more of them
> now (thankfully, they were removed, so there won't be more, but that
>
On Thu, Jul 04, 2019 at 07:05:30PM +0900, Mike Hommey wrote:
> Hi,
>
> I was looking at the disk size of the gecko repository on github[1],
> which started at 4.7GB, and `git gc --aggressive`'d it, which made that
> into 2.0G. But to achieve that required quite some reso
On Thu, Jul 04, 2019 at 12:04:11PM +, Eric Wong wrote:
> Mike Hommey wrote:
> > I'm puzzled by the fact writing objects is so much faster with 1 thread.
>
> I/O contention in the multi-threaded cases?
>
> "public-inbox-index" (reading from git, writing
m/mozilla/gecko
2.
https://docs.google.com/spreadsheets/d/1IE8E3BhKurXsXgwBYFXs4mRBT_512v--ip6Vhxc3o-Y/edit?usp=sharing
3. https://public-inbox.org/git/20180703223823.qedmoy2imp4dc...@glandium.org/T/
Any thoughts?
Mike
good state.
- Avoid git cinnabar sometimes thinking the helper is not up-to-date
when it is.
- Removing bookmarks on a Mercurial server is now working properly.
Mike
bout _the_ URL.
The only thing that seems to be talking about this is the documentation
for git-remote, which has --add for set-url. There doesn't seem to be any
documentation about what conditions are required for the non-primary URL
to be used.
Mike
On Sat, Jun 15, 2019 at 12:26:18PM +0100, Thomas Gummerer wrote:
> On 06/14, Mike Hommey wrote:
> > Hi,
> >
> > `git stash ` where n is a number used to work until 2.21.*.
> > It doesn't work in 2.22.0.
> >
> > Bisection points to:
> >
> &g
2019 +
stash: convert show to builtin
which I guess makes sense :)
Mike
From: Mike Mueller
git p4 unshelve was failing with these errors:
fatal: Not a valid object name HEAD0
Command failed: git cat-file commit HEAD^0
(git version 2.21.0.windows.1, python 2.7.16)
The pOpen call used by git-p4 to invoke the git command can take either a
string or an array as a
ing a string instead of an array as first argument, which is what
is done by extractLogMessageFromGitCommit.
Solution is to use the array format of passing the command to fOpen, which
is preferred (see https://docs.python.org/2/library/subprocess.html) and is
used in other parts of this code anyw
e to me, so I added some log messages to expand_topo_walk()
> and notices we were walking the UNINITERESTING commits. This is part
> of the reason the new logic is slower for A..B commands, but not the
> whole reason.
>
> You'll want this patch as well for a test.
Both patches help, thanks.
Mike
On Sat, May 18, 2019 at 12:58:28PM +0900, Mike Hommey wrote:
> On Sat, May 18, 2019 at 03:50:05AM +0200, SZEDER Gábor wrote:
> > On Sat, May 18, 2019 at 09:54:12AM +0900, Mike Hommey wrote:
> > > There are established corner cases, where in a repo where commit dates
> >
On Sat, May 18, 2019 at 03:50:05AM +0200, SZEDER Gábor wrote:
> On Sat, May 18, 2019 at 09:54:12AM +0900, Mike Hommey wrote:
> > There are established corner cases, where in a repo where commit dates
> > are not monotonically increasing, revision walking can go horribly
>
dig into this, but if someone familiar with the
algorithm could give me some hints as to what I might be missing in the
big picture, that would be helpful.
Cheers,
Mike
On Thu, May 16, 2019 at 05:47:52PM -0400, Jeff King wrote:
> On Thu, May 16, 2019 at 05:35:19PM +0900, Mike Hommey wrote:
>
> > On Wed, May 15, 2019 at 11:28:02PM -0400, Jeff King wrote:
> > > Totally orthogonal, but I think we might also want to introduce a helper
> >
eam it's offered to use, but can't be a fetch helper
either)
Mike
On Wed, May 15, 2019 at 07:56:09PM +0900, Mike Hommey wrote:
> Hi,
>
> I started getting a weird error message during some test case involving
> git-cinnabar, which is a remote-helper to access mercurial
> repositories.
>
> The error says:
> fatal: mmap failed: Bad file d
On Wed, May 15, 2019 at 07:53:40PM -0400, Jeff King wrote:
> On Thu, May 16, 2019 at 07:08:34AM +0900, Mike Hommey wrote:
>
> > > >> - Except, well, fds being what they are, we in fact just closed a fd
> > > >> from a packed_git->pack_fd. So, when use_pac
use_pack has its own error message on mmap error, but it can't be
reached when using xmmap, which dies with its own error.
Signed-off-by: Mike Hommey
---
packfile.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/packfile.c b/packfile.c
index 16bcb75262..6a66b605e9 1
d, which means close() is called with
an invalid fd (since it was already closed as per above). Or worse, with
a valid fd owned by something else (since fd numbers can be reused).
Signed-off-by: Mike Hommey
---
transport-helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Wed, May 15, 2019 at 07:59:49PM +0200, Johannes Sixt wrote:
> Am 15.05.19 um 13:43 schrieb Ævar Arnfjörð Bjarmason:
> >
> > On Wed, May 15 2019, Mike Hommey wrote:
> >
> >> Hi,
> >>
> >> I started getting a weird error message during some t
e (which, in fact, could be more useful in other
cases). It seems like it should call xmmap_gently instead.
Cheers,
Mike
ing a string instead of an array as first argument, which is what
is done by extractLogMessageFromGitCommit.
Solution is to use the array format of passing the command to fOpen, which
is preferred (see https://docs.python.org/2/library/subprocess.html) and is
used in other parts of this code anyw
From: Mike Mueller
git p4 unshelve was failing with these errors on Windows:
fatal: Not a valid object name HEAD0
Command failed: git cat-file commit HEAD^0
(git version 2.21.0.windows.1, python 2.7.16)
The pOpen call used by git-p4 to invoke the git command can take either a
string or an
ter handling of mercurial branchmap tips.
- Better support for end of parts in bundle v2.
- Improvements handling urls to local mercurial repositories.
- Fixed compatibility with (very) old mercurial servers when using mercurial
5.0 libraries.
- Converted Continuous Integration scripts to Python 3.
Mike
n the number of items read
or written. This number equals the number of bytes transferred
only when size is 1. If an error occurs, or the end of the file
is reached, the return value is a short item count (or zero).
Signed-off-by: Mike Hommey
---
http.c | 12 ++--
1 file chang
n the number of items read
or written. This number equals the number of bytes transferred
only when size is 1. If an error occurs, or the end of the file
is reached, the return value is a short item count (or zero).
Signed-off-by: Mike Hommey
---
http.c | 12 ++--
1 file chang
own issue on macOS specifically on large repos is that
the number of files explodes the inode cache in the kernel, and lstat
becomes slow.
e.g.
https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/p9U4jqz8kxo
Mike
the question is
whether there's a reason this shouldn't run in the background? Another
is whether there's something that makes this slower than it should be.
Mike
On Fri, Mar 22, 2019 at 02:39:43PM +0100, Johannes Schindelin wrote:
> Hi Peff & Mike,
>
> On Fri, 22 Mar 2019, Jeff King wrote:
>
> > On Wed, Mar 20, 2019 at 07:19:41PM +0900, Mike Hommey wrote:
> >
> > > I thought of a few options (it's worth noting
patch for git itself. But that doesn't quite address the nitpick case
where ETC_GITCONFIG could be either `/etc/gitconfig` or
`etc/gitconfig` depending how git was compiled, and there's no way to
know which is the right one.
WDYT?
Mike
ithout a git repack.
For one-shot conversions, you can just rely on git repack.
Mike
The pkt-line formatted lines contained the wrong pkt-len.
Signed-off-by: Mike Hommey
---
Documentation/technical/pack-protocol.txt | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/technical/pack-protocol.txt
b/Documentation/technical/pack-protocol.txt
ded up doing `git rebase
--continue` in that shell in many cases, which didn't end up so well
when I terminated said shell (just an error message, though, nothing
actually broke as a consequence). This feature is a blessing.
Mike
Hello,
Sorry for the delay, it was due to fire disaster in our Zonal Office but
everything is okay now,I want to know if you still ready to work with us part
time or Full time ? Kindly get back to me Via email asap for details.
Email: humanresourcemanagermikemud...@gmail.com
Mike Murdock
On Thu, Dec 13, 2018 at 3:48 PM Stefan Beller wrote:
>
> > > The current situation is definitely a problem. If I am in a worktree,
> > > using "head" should be the same as "HEAD".
>
> By any chance, is your file system case insensitive?
> That is usually the source of confusion for these discussi
On Thu, Dec 13, 2018 at 3:43 PM Duy Nguyen wrote:
>
> On Thu, Dec 13, 2018 at 9:34 PM Mike Rappazzo wrote:
> >
> > On Thu, Dec 13, 2018 at 3:23 PM Duy Nguyen wrote:
> > >
> > > On Thu, Dec 13, 2018 at 8:56 PM Michael Rappazzo via GitGitGadget
> > >
On Thu, Dec 13, 2018 at 3:23 PM Duy Nguyen wrote:
>
> On Thu, Dec 13, 2018 at 8:56 PM Michael Rappazzo via GitGitGadget
> wrote:
> >
> > From: Michael Rappazzo
> >
> > On a worktree which is not the primary, using the symbolic-ref 'head' was
> > incorrectly pointing to the main worktree's HEAD.
is planned to be 0.6.0. These include:
- Changes in behavior.
- Changes in metadata.
- Stabilizing experimental features.
- Remove backwards compability with older metadata (< 0.5.0).
Mike
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 "
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:
> >>
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
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 that
ote unpack failed: unpack-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
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
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
gets down to 3:33.
I'll also note that Facebook 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
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
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
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 that, and I found myself using it
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
ch 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
Missing ')' after the closing '`'.
"If is a branch name (call it `` and"
On Wed, Jan 24, 2018 at 02:23:57PM -0800, Junio C Hamano wrote:
> Mike Hommey 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 object store suppor
t;
> 1. Find what the main branch is
> 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
t; a powerful way and could end the contention. 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
On Fri, Oct 13, 2017 at 12:26:46PM +0200, Christian Couder wrote:
> On Fri, Oct 13, 2017 at 12:06 PM, Mike Hommey wrote:
> > On Fri, Oct 13, 2017 at 12:51:58PM +0300, Constantine wrote:
> >> There's a gitbomb on github. It is undoubtedly creative and funny, but
> >
What 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
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 memories
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
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:
>
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
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
>
as the currently 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
ce, 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
https://stackoverflow.com/questions/24090739/possible-compiler-bug-in-msvc12-vs2013-with-designated-initializer
Mike
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 (and the order we would like to enc
grade 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
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
s 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
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
erestingly, 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
---
Documentation/git-fast-import.txt | 2 +-
ople need not use it if they dont want
> to.
Git 2.13.0 has that already.
git stash -- file1 file2
Mike
r the .git/hgrc file for mercurial specific
configuration.
- Support any version of Git (was previously limited to 1.8.5 minimum)
Mike
to
> fetch. The problem for your 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
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 that `git rebase -i` would print:
>> p deadbe
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 on
> a different comput
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 ple
Allows the user to verify and/or change the contents of the merge
before committing as necessary
Signed-off-by: Mike Lewis
---
contrib/subtree/git-subtree.sh | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree
the parent
int_node*.
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
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
1 - 100 of 551 matches
Mail list logo
