On Sun, Dec 29, 2013 at 12:30:02PM +0100, Antoine Pelisse wrote:
Mercurial can have bookmarks pointing to nullid (the empty root
revision), while Git can not have references to it.
When cloning or fetching from a Mercurial repository that has such a
bookmark, the import will fail because
On Mon, Dec 30, 2013 at 08:41:13AM +0100, Antoine Pelisse wrote:
On Sun, Dec 29, 2013 at 11:24 PM, Mike Hommey m...@glandium.org wrote:
On Sun, Dec 29, 2013 at 12:30:02PM +0100, Antoine Pelisse wrote:
Mercurial can have bookmarks pointing to nullid (the empty root
revision), while Git can
On Wed, Jan 15, 2014 at 06:13:30AM -0500, Jeff King wrote:
On Wed, Jan 15, 2014 at 11:37:08AM +0100, David Kastrup wrote:
The question is what guarantees I have with regard to the commit date of
a commit in relation to that of its parent commits:
a) none
b) commitdate(child) =
On Fri, Jan 24, 2014 at 10:49:13PM +, brian m. carlson wrote:
On Fri, Jan 24, 2014 at 11:24:36PM +0100, Johannes Schindelin wrote:
In general, I'm wary of changing permissions on a file to suit Windows's
rename because of the symlink issue and the security issues that can
result.
On Wed, Jan 29, 2014 at 01:47:30PM +0700, Duy Nguyen wrote:
Just a quick update for the enthusiasts. My branch file-watcher [1]
has got working per-user inotify support. It's a 20 patch series so
I'll refrain from spamming git@vger for a while, even though it hurts
your eyes a lot less than
On Wed, Feb 12, 2014 at 08:15:24PM +0100, David Kastrup wrote:
Stefan Zager sza...@chromium.org writes:
On Wed, Feb 12, 2014 at 10:50 AM, David Kastrup d...@gnu.org wrote:
Really, give the above patch a try. I am taking longer to finish it
than anticipated (with a lot due to
On Wed, Feb 12, 2014 at 12:00:19PM +0100, Karsten Blees wrote:
Am 12.02.2014 04:43, schrieb Duy Nguyen:
On Wed, Feb 12, 2014 at 9:02 AM, Robin H. Johnson robb...@gentoo.org
wrote:
On Tue, Feb 11, 2014 at 05:54:51PM -0800, Stefan Zager wrote:
We in the chromium project have a keen
On Thu, Feb 13, 2014 at 07:04:02AM +0100, David Kastrup wrote:
Mike Hommey m...@glandium.org writes:
On Wed, Feb 12, 2014 at 08:15:24PM +0100, David Kastrup wrote:
Stefan Zager sza...@chromium.org writes:
On Wed, Feb 12, 2014 at 10:50 AM, David Kastrup d...@gnu.org wrote:
Really
On Thu, Feb 13, 2014 at 06:34:39PM +0900, Mike Hommey wrote:
On Thu, Feb 13, 2014 at 07:04:02AM +0100, David Kastrup wrote:
Mike Hommey m...@glandium.org writes:
On Wed, Feb 12, 2014 at 08:15:24PM +0100, David Kastrup wrote:
Stefan Zager sza...@chromium.org writes:
On Wed, Feb
On Tue, Feb 18, 2014 at 12:52:28AM +0100, Johannes Schindelin wrote:
Hopefully the Postfix Greylisting Policy Server will not try again to
greylist me, as it might however do without violating the RFC.
-- Forwarded message --
Date: Tue, 18 Feb 2014 00:38:54 +0100 (CET)
From:
On Tue, Feb 18, 2014 at 10:04:54AM +0100, Erik Faye-Lund wrote:
It's right here: https://github.com/msysgit/msysgit/pull/159
You probably looked in our git repo rather than our msysGit repo.
Oh indeed I was, thanks.
Mike
--
To unsubscribe from this list: send the line unsubscribe git in
the
On Tue, Apr 01, 2014 at 07:45:03AM -0400, Jeff King wrote:
On Tue, Apr 01, 2014 at 07:25:54PM +0900, Mike Hommey wrote:
I am currently prototyping a native mercurial remote handler for git,
For my own curiosity, how does this differ from what is in
contrib/remote-helpers/git-remote-hg
On Tue, Apr 01, 2014 at 09:15:12AM -0400, Jeff King wrote:
It seems to me fast-import keeps a kind of human readable format for its
protocol, i wonder if xdelta format would fit the bill. That being said,
I also wonder if i shouldn't just try to write a pack on my own...
The fast-import
On Tue, Apr 01, 2014 at 10:14:02AM -0700, Junio C Hamano wrote:
Mike Hommey m...@glandium.org writes:
On Tue, Apr 01, 2014 at 09:15:12AM -0400, Jeff King wrote:
It seems to me fast-import keeps a kind of human readable format for its
protocol, i wonder if xdelta format would fit
On Tue, Apr 01, 2014 at 03:32:49PM -0700, Junio C Hamano wrote:
[Footnote]
*1* I am still not sure how useful the feature would be outside
slurping from Hg and Git---for obvious reasons, though. As long as
the change is to a cleanly isolated codepath, it would be OK, I
guess.
That's why I
On Wed, Apr 02, 2014 at 01:29:13AM +0200, Max Horn wrote:
On 01.04.2014, at 15:15, Jeff King p...@peff.net wrote:
On Tue, Apr 01, 2014 at 10:07:03PM +0900, Mike Hommey wrote:
For my own curiosity, how does this differ from what is in
contrib/remote-helpers/git-remote-hg?
contrib
Hi,
In one of my workflows, I constantly rebase topic branches on top of new
upstream imports. As there are several upstream import branches, I have
similar topic branches on top of different imports.
When rebasing the topic branches, I can hit conflict resolution that I
already had to do for
On Sat, Oct 20, 2012 at 05:00:06PM +0200, Felipe Contreras wrote:
Changes since v1:
* Improved documentation
* Use more common 'python' binary
* Warn, don't barf when a branch has multiple heads
* Fixed marks to fetch after cloned
* Support for cloning/pulling remote repositories
*
On Wed, May 15, 2013 at 10:50:25AM +0100, John Keeping wrote:
On Wed, May 15, 2013 at 11:34:41AM +0200, Matthieu Moy wrote:
Antoine's answer is correct. In addition, I'd say that you may want to
enable color in the output to make it clearer (the @@ ... @@ part would
be colored, but not the
Hi,
For some reason, I need to know the sha1 corresponding to some marks
I'm putting in a fast-import stream. Unfortunately, this does not appear
to be possible.
- I'd rather not require a checkpoint to export marks each time I need
such a sha1, and I'd rather not do that work that requires
On Tue, Nov 18, 2014 at 09:34:26AM +0900, Mike Hommey wrote:
Hi,
For some reason, I need to know the sha1 corresponding to some marks
I'm putting in a fast-import stream. Unfortunately, this does not appear
to be possible.
- I'd rather not require a checkpoint to export marks each time I
On Mon, Nov 17, 2014 at 05:40:28PM -0800, Jonathan Nieder wrote:
Mike Hommey wrote:
- fast-import's `ls` command documentation about its output format
mentions that the output may contain commits, so I tried the trick of
creating a tree with commits, but fast-import then fails
On Tue, Nov 18, 2014 at 11:21:37AM +0900, Mike Hommey wrote:
On Tue, Nov 18, 2014 at 09:34:26AM +0900, Mike Hommey wrote:
Hi,
For some reason, I need to know the sha1 corresponding to some marks
I'm putting in a fast-import stream. Unfortunately, this does not appear
to be possible
On Mon, Nov 17, 2014 at 06:51:31PM -0800, Jonathan Nieder wrote:
Mike Hommey wrote:
On Mon, Nov 17, 2014 at 05:40:28PM -0800, Jonathan Nieder wrote:
How did you get that Not a blob message?
When trying to *create* a tree with a commit in it, so instead of giving
the mark for a blob
On Mon, Nov 17, 2014 at 06:53:59PM -0800, Jonathan Nieder wrote:
Mike Hommey wrote:
BTW, if it so happens that all the operations that were done end up
creating objects that already existed for some reason, checkpoint
doesn't do anything, which is fine for the pack and tags
On Mon, Nov 17, 2014 at 07:27:41PM -0800, Jonathan Nieder wrote:
Mike Hommey wrote:
And while I'm here, it's sad that one needs to emit a dummy cat-blob or
ls command to wait for a checkpoint to be finished
That's a good point. (Though relying on checkpoints to read back
information
On Tue, Nov 18, 2014 at 12:11:47PM +0900, Mike Hommey wrote:
Oh, so `ls dataref` would print out what dataref is? That would
definitely help, although with the trick above, I probably wouldn't
actually need it anymore.
So, in the end, I was able to do everything with what's currently
provided
On Tue, Nov 18, 2014 at 06:21:22PM -0800, Jonathan Nieder wrote:
Mike Hommey wrote:
So, in the end, I was able to do everything with what's currently
provided by git fast-import, but one thing would probably make life
easier for me: being able to initialize a commit tree from a commit
The git-fast-import manual page says about both cat-blob and ls that they can
be used anywhere in the stream that comments are accepted, but in practice
it turns out it was only true for cat-blob. This change makes fast-import
behavior match its documentation.
Signed-off-by: Mike Hommey m
On Wed, Nov 26, 2014 at 07:25:39AM +0900, Mike Hommey wrote:
The git-fast-import manual page says about both cat-blob and ls that they can
be used anywhere in the stream that comments are accepted, but in practice
it turns out it was only true for cat-blob. This change makes fast-import
Hi,
I have a note tree with a bit more than 200k notes.
$ time git notes --ref foo show $sha1 /dev/null
real0m0.147s
user0m0.136s
sys 0m0.008s
That's a lot of time, especially when you have a script that does that
on a fair amount of sha1s.
Now, the interesting thing is this:
$
On Tue, Nov 25, 2014 at 08:24:49PM -0500, Jeff King wrote:
On Tue, Nov 25, 2014 at 08:00:51PM -0500, Jeff King wrote:
On Wed, Nov 26, 2014 at 09:42:42AM +0900, Mike Hommey wrote:
I have a note tree with a bit more than 200k notes.
$ time git notes --ref foo show $sha1 /dev/null
On Tue, Nov 25, 2014 at 08:34:57PM -0500, Jeff King wrote:
On Tue, Nov 25, 2014 at 08:24:48PM -0500, Jeff King wrote:
However, this is not what trees created by git-notes look like. It
shards the object sha1s into subtrees (1a/2b/{36}), and I think does so
dynamically in a way that keeps
/objects), while the result of that lookup is
not used when returning a non-abbreviated hex sha1.
Signed-off-by: Mike Hommey m...@glandium.org
---
sha1_name.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
This hit me on a corner case, where I kind of abuse commit links and
have a tree
On Wed, Nov 26, 2014 at 12:46:20PM +0100, Johan Herland wrote:
(First of all, thanks to both for great investigation and analysis)
On Wed, Nov 26, 2014 at 5:46 AM, Jeff King p...@peff.net wrote:
On Wed, Nov 26, 2014 at 11:25:53AM +0900, Mike Hommey wrote:
Now, looking at the notes tree
On Wed, Nov 26, 2014 at 08:03:33AM +0900, Mike Hommey wrote:
On Wed, Nov 26, 2014 at 07:25:39AM +0900, Mike Hommey wrote:
The git-fast-import manual page says about both cat-blob and ls that they
can
be used anywhere in the stream that comments are accepted, but in practice
it turns out
Hi,
I've (re)started work on a longstanding idea of mine of having a git tool
talking the mercurial wire protocol directly. I'm now at a stage where
the tool can clone and pull/fetch from mercurial.
As it is a prototype, there are many things that it doesn't handle (like
named branches,
On Fri, Dec 05, 2014 at 05:59:30PM -0500, Jeff King wrote:
On Fri, Dec 05, 2014 at 02:13:19PM -0800, Jonathan Nieder wrote:
Mike Hommey wrote:
I'm currently evaluating what the final tool would look like. I'm *very*
tempted to implement it in C, based on core git code, because
On Fri, Dec 05, 2014 at 03:13:30PM -0800, Jonathan Nieder wrote:
Jeff King wrote:
One of the nice things about spinning remote-hg out of the core repo is
that it means we do not have to endorse a particular implementation, and
they can compete with each other on their merits.
True.
Hi,
As you now know, I'm working on a mercurial remote helper for git. As
such, it uses fast-import.
In the mercurial history of mozilla-central, there have been various
renames of files with only case changes, and it so happens that my
remote helper blows things up on case insensitive file
On Tue, Dec 09, 2014 at 09:12:11AM +0900, Mike Hommey wrote:
Hi,
As you now know, I'm working on a mercurial remote helper for git. As
such, it uses fast-import.
In the mercurial history of mozilla-central, there have been various
renames of files with only case changes, and it so happens
Hi,
As you may or may not know, I'm working on a remote-helper to interact
with mercurial servers, with the main focus being to make it work with
developer workflows at Mozilla.
I think remote-helpers, in the context of non-git remotes, can be
leveraged to improve git user experience with
Hi,
There are two major differences between adding notes with fast-import
and git notes, one of which is a serious problem:
- fast-import doesn't want to add notes for non commits, while git notes
does.
- fast-import and git notes have different, conflicting fanouts:
- take e.g. the git
On Mon, Dec 22, 2014 at 10:07:26AM +0900, Mike Hommey wrote:
Hi,
As you may or may not know, I'm working on a remote-helper to interact
with mercurial servers, with the main focus being to make it work with
developer workflows at Mozilla.
I think remote-helpers, in the context of non-git
On Fri, Jan 23, 2015 at 10:41:10AM -0800, Junio C Hamano wrote:
Mike Hommey m...@glandium.org writes:
While -C implies -M, it is quite common to see both on example command lines
here and there. The unintuitive thing is that if -M appears after -C, then
copy detection is turned off
On Fri, Jan 23, 2015 at 06:04:19AM -0500, Jeff King wrote:
On Fri, Jan 23, 2015 at 10:29:08AM +0900, Mike Hommey wrote:
While fooling around with copy/rename detection, I noticed that it
doesn't detect the case where you copy or rename a file on top of
another:
$ git init
$ (echo
On Tue, Feb 03, 2015 at 10:32:45AM +0100, Lukas Fleischer wrote:
On Tue, 03 Feb 2015 at 10:17:15, Mike Hommey wrote:
Symptoms: $ git blame HEAD -- foo fatal: no such path foo in random
garbage
Expected output: $ git blame HEAD -- foo fatal: no such path foo in
HEAD
Bisect says
Symptoms:
$ git blame HEAD -- foo
fatal: no such path foo in random garbage
Expected output:
$ git blame HEAD -- foo
fatal: no such path foo in HEAD
Bisect says this was introduced in 1da1e07c835e900337714cfad6c32a8dc0b36ac3
valgrind output looks like this:
==4738== Memcheck, a memory
branches.
Signed-off-by: Mike Hommey m...@glandium.org
---
Documentation/git-show-branch.txt | 6 ++
builtin/show-branch.c | 42 +--
2 files changed, 46 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-show-branch.txt
b
On Wed, Jan 21, 2015 at 10:46:48PM -0800, Junio C Hamano wrote:
Mike Hommey m...@glandium.org writes:
A typical remote helper will return a `list` of refs containing a symbolic
ref HEAD, pointing to, e.g. refs/heads/master. In the case of a clone, all
the refs are being requested through
On Wed, Jan 21, 2015 at 11:41:51PM -0800, Junio C Hamano wrote:
Mike Hommey m...@glandium.org writes:
Note the most important part is actually between the parens: that only
happens when the remote helper returns '?' to the `list` command, which
non-git remotes helpers (like git-remote-hg
and request the ref they point to instead.
Then, resolve the symbolic refs values based on the pointed ref.
This assumes there is no more than one level of indirection (a symbolic
ref doesn't point to another symbolic ref).
Signed-off-by: Mike Hommey m...@glandium.org
---
git-remote-testgit.sh | 8
On Thu, Jan 22, 2015 at 09:52:55AM -0800, Junio C Hamano wrote:
Mike Hommey m...@glandium.org writes:
The patch changes the behavior in all cases, because it didn't feel
necessary to have a different behavior between the normal case and the
'?' case: it makes sense to request the ref
On Thu, Jan 22, 2015 at 08:00:36AM -0500, Jeff King wrote:
On Thu, Jan 22, 2015 at 06:50:37PM +0600, Alexander Kuleshov wrote:
Standard user has no need in debugging information. This patch adds
DEBUG=1 option to compile git with debugging symbols and compile without
it by default.
their order, copy
detection is on.
Signed-off-by: Mike Hommey m...@glandium.org
---
Interestingly, I even found mentions of -C -M in this order for benchmarks,
on this very list (see 6555655.XSJ9EnW4BY@mako).
diff.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/diff.c b
On Thu, Jan 22, 2015 at 01:35:38PM -0500, Jeff King wrote:
On Thu, Jan 22, 2015 at 06:36:41PM +0100, Matthieu Moy wrote:
Yes, main point is size of executable.
The Git executable is a few megabytes, i.e. 0.001% the size of a really
small hard disk. The benefit seems really negligible
Hi,
While fooling around with copy/rename detection, I noticed that it
doesn't detect the case where you copy or rename a file on top of
another:
$ git init
$ (echo foo; echo bar) foo
$ git add foo
$ git commit -m foo
$ echo 0 bar
$ git add bar
$ git commit -m bar
$ git mv -f foo bar
$ git
On Thu, Feb 12, 2015 at 07:10:01PM +0900, Mike Hommey wrote:
Signed-off-by: Mike Hommey m...@glandium.org
---
transport-helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/transport-helper.c b/transport-helper.c
index c3868e4..b72fd4a 100644
--- a/transport
Currently, the progress and verbosity options are only emitted for the fetch
and push commands, but they should also be emitted for other commands, such as
import or export, and, why not, even list.
Signed-off-by: Mike Hommey m...@glandium.org
---
transport-helper.c | 5 +++--
1 file changed, 3
Signed-off-by: Mike Hommey m...@glandium.org
---
transport-helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/transport-helper.c b/transport-helper.c
index c3868e4..b72fd4a 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -861,7 +861,7 @@ static int
The check-connectivity, cloning, and update-shallow options are currently only
emitted for the fetch command but should also be emitted for the import
command.
Signed-off-by: Mike Hommey m...@glandium.org
---
transport-helper.c | 20 ++--
1 file changed, 10 insertions(+), 10
the remote helper about those options after asking for its
capabilities ensures it can act accordingly for all commands.
Signed-off-by: Mike Hommey m...@glandium.org
---
transport-helper.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/transport-helper.c b/transport-helper.c
supports 'import' can't distinguish
between a clone and a pull besides doing some assumptions from the
git directory state.
Signed-off-by: Mike Hommey m...@glandium.org
---
transport-helper.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/transport-helper.c b
Hi,
diff-format.txt says this:
An output line is formatted this way:
(snip)
That is, from the left to the right:
(snip)
. status, followed by optional score number.
(snip)
Status letters C and R are always followed by a score (denoting the
percentage of similarity between the
., 2008-11-02) and it was wrong from the day one.
Noticed-by: Mike Hommey
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Documentation/diff-format.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/diff-format.txt b/Documentation/diff-format.txt
On Tue, Jan 06, 2015 at 02:24:58AM -0800, Junio C Hamano wrote:
Mike Hommey m...@glandium.org writes:
I would like to know if the revision walking API works as one would
expect with a calling sequence like the following:
- init_revisions
- add_pending_object/setup_revisions
Hi,
I would like to know if the revision walking API works as one would
expect with a calling sequence like the following:
- init_revisions
- add_pending_object/setup_revisions
- prepare_revision_walk
- get_revision (repeated)
- reset_revision_walk (I guess)
- add_pending_object
-
On Thu, Jan 08, 2015 at 06:17:37PM +0900, Mike Hommey wrote:
`git show-branch --upstream` is equivalent to `git show-branch
$(git for-each-ref refs/heads --format '%(refname:short)')
$(git for-each-ref refs/heads --format '%(upstream:short)')`
`git show-branch --upstream foo bar
Hi,
Cinnabar is the common natural form in which mercury can be found on
Earth. It contains mercury sulfide and its powder is used to make the
vermillion pigment.
What does that have to do with git?
Hint: mercury.
Git-cinnabar is a git remote helper to interact with mercurial
repositories. It
On Fri, Feb 13, 2015 at 11:36:24AM -0800, Junio C Hamano wrote:
Mike Hommey m...@glandium.org writes:
A remote helper is currently only told about the 'check-connectivity',
'cloning', and 'update-shallow' options when it supports the 'fetch'
command, but not when it supports 'import
branches.
Signed-off-by: Mike Hommey m...@glandium.org
---
Refreshed against current next.
Documentation/git-show-branch.txt | 6 ++
builtin/show-branch.c | 44 ---
2 files changed, 47 insertions(+), 3 deletions(-)
diff --git a/Documentation
refs/heads/bar
--format '%(upstream:short)')`
Combined with --topics, it shows commits that are NOT on any of
the upstream branches.
Signed-off-by: Mike Hommey m...@glandium.org
---
Note that in the --topics --upstream case, when there are different
upstreams branches involved, only the merge-base
Hi,
I was trying to use --color-words with a regex to check a diff, and it appears
it displays things out of order. Am I misunderstanding what my regexp should be
doing or is there a bug?
$ git diff -U3 HEAD^ dom/base/nsDOMFileReader.cpp
diff --git a/dom/base/nsDOMFileReader.cpp
On Mon, Mar 16, 2015 at 05:38:06PM +0900, Mike Hommey wrote:
git show-branch --topics rev revs... displays ancestry graph, only
considering commits that are in all given revs, except the first one.
git show-branch displays ancestry graph for all local branches.
Unfortunately, git show
On Mon, Mar 16, 2015 at 05:13:25PM +0700, Duy Nguyen wrote:
On Mon, Mar 16, 2015 at 3:05 PM, Mike Hommey m...@glandium.org wrote:
Hi,
git-verify-pack's man page says the following about --stat-only:
Do not verify the pack contents; only show the histogram of delta
chain length
On Wed, Mar 18, 2015 at 09:27:22PM -0400, Jeff King wrote:
On Thu, Mar 19, 2015 at 07:31:48AM +0700, Duy Nguyen wrote:
Or we could count/estimate the number of loose objects again after
repack/prune. Then we can maybe have a way to prevent the next gc that
we know will not improve the
On Thu, Mar 19, 2015 at 12:14:53AM -0400, Jeff King wrote:
On Thu, Mar 19, 2015 at 11:01:17AM +0900, Mike Hommey wrote:
I don't think packing the unreachables is a good plan. They just end up
accumulating then, and they never expire, because we keep refreshing
their mtime at each pack
On Fri, Mar 20, 2015 at 12:03:43AM +0100, Thomas Braun wrote:
Hi,
the Git for Windows team just released the first maintenance release of
the Windows-specific installers for git 1.9.5.
is it expected that there is no corresponding release on
https://github.com/git-for-windows/git/releases ?
git show-branch --topics rev revs... displays ancestry graph, only
considering commits that are in all given revs, except the first one.
git show-branch displays ancestry graph for all local branches.
Unfortunately, git show-branch --topics rev only prints out the rev
info for the given rev, and
On Tue, Mar 10, 2015 at 11:18:45PM -0700, Junio C Hamano wrote:
One thing we already do is to give an extra Author: line in the
comment when the user edits the log message, so that it is clear
that what is being edited is not their own work but hers. We obviously
can add the extra warning,
... $(git for-each-ref refs/heads refs/remotes
--format='%(refname:short)')
instead of
show-branch --topics $(git for-each-ref refs/heads refs/remotes
--format='%(refname:short)')
Signed-off-by: Mike Hommey m...@glandium.org
---
builtin
On Mon, Mar 30, 2015 at 03:24:26PM -0700, Junio C Hamano wrote:
Mike Hommey m...@glandium.org writes:
(Maybe --topics should always require one rev on the command
line?)
That sounds line a good thing to do.
- else if (all_heads + all_remotes)
- snarf_refs(all_heads
On Tue, Mar 31, 2015 at 08:35:52AM +0900, Mike Hommey wrote:
On Tue, Mar 31, 2015 at 08:02:09AM +0900, Mike Hommey wrote:
Hi,
I am trying to get all the children commits of a set of commits. To do
that, I'm using this:
git rev-list --topo-order --ancestry-path --boundary all heads
On Tue, Mar 31, 2015 at 08:02:09AM +0900, Mike Hommey wrote:
Hi,
I am trying to get all the children commits of a set of commits. To do
that, I'm using this:
git rev-list --topo-order --ancestry-path --boundary all heads ^A ^B ...
where A, B, and following are those commits I want
Hi,
I am trying to get all the children commits of a set of commits. To do
that, I'm using this:
git rev-list --topo-order --ancestry-path --boundary all heads ^A ^B ...
where A, B, and following are those commits I want the children of. From
the gitrevisions documentation, it seems that
Hi,
Sometimes I want to know what (possibly remote) branch contains a given
commit. The repository where I do that has thousands of branches:
$ git for-each-ref | wc -l
7657
And a lot of commits:
$ git rev-list --all | wc -l
538174
Using git branch --contains can be a very expensive thing:
$
Hi,
Currently, in git-cinnabar[1], I'm using a private namespace
(refs/cinnabar) for various different things:
- references to all the imported heads (which may or may not
match remote refs),
- the last refs used for a fetch (part of the refspec protocol for
remote-helpers)
- a branch
On Tue, Mar 31, 2015 at 04:14:49PM -0700, Jonathan Nieder wrote:
Mike Hommey wrote:
Octopus merges are limited to 16 parents.
The note about this in fast-import is out of date (e.g., see
t/t7602-merge-octopus-many.sh and v1.6.0-rc0~194, 2008-06-27). How
about this patch?
Aha! I wasn't
On Tue, Mar 31, 2015 at 01:23:23PM -0700, Junio C Hamano wrote:
Mike Hommey m...@glandium.org writes:
So I thought, since commits are already allowed in tree objects, for
submodules, why not add a bit to the mode that would tell git that
those commit object references are meant to always
On Wed, Mar 04, 2015 at 12:41:57PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
On Wed, Mar 04, 2015 at 04:06:17PM +0100, Michael J Gruber wrote:
Complexity: Was that due to replace refs? Other than that, it seemed to
be simple: max(parent generation numbers)+1.
On Mon, May 11, 2015 at 07:04:20PM -0700, Junio C Hamano wrote:
Mike Hommey m...@glandium.org writes:
So, the reason this is happening is that 2879bc3 moved sending the
progress helper option earlier, and for clone, it's early enough that
transport_set_verbosity happens afterwards. Since
Currently, fast-import does case folding depending on `core.ignorecase`.
`core.ignorecase` depends on the file system where the working tree is.
However, different kind of imports require different kinds of semantics,
and they usually aren't tied with the file system, but with the data being
On Fri, Apr 17, 2015 at 11:44:00AM -0700, Junio C Hamano wrote:
So perhaps we should rip the case folding out altogether instead?
The entry for the change in the Release Notes may say:
* git fast-import incorrectly case-folded the paths recorded in
the history when core.ignorease is set
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/glandium/git-cinnabar
[ Previous announcements:
http://marc.info/?l=gitm=142364715001983
Hi,
I noticed that in some weird cases, git rev-list and friends would
appear to not do their work as intended. As I wasn't entirely sure at
the time I saw previous occurrence (which involved lots of refs and
big history) , I kept that on the side to look back later, but today,
it happened again
On Thu, Jun 11, 2015 at 08:16:02AM -0700, Junio C Hamano wrote:
Mike Hommey m...@glandium.org writes:
I do agree that this is all confusing, but allow me to point out that
it's already plenty confusing: namespace is a term that has been used to
designate a generic kind of namespace
have an equivalent override.
Add a GIT_REPLACE_REF_BASE environment variable to control where git is
going to look for replace refs.
Signed-off-by: Mike Hommey m...@glandium.org
---
builtin/replace.c | 6 +++---
cache.h | 2 ++
environment.c | 6 ++
log-tree.c| 5
On Tue, Jun 16, 2015 at 08:17:03PM -0700, Junio C Hamano wrote:
Mike Hommey m...@glandium.org 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 want to give
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
ref name, when callers may
have an equivalent override.
Add a GIT_REPLACE_NAMESPACE environment variable to control where git is
going to look for replace refs.
Signed-off-by: Mike Hommey m...@glandium.org
---
I'm not sure if I need to care about avoiding strlen in log-tree.c, or if I
should handle the lack
1 - 100 of 315 matches
Mail list logo
