- Mail original -
Hi folks,
I apologize for being off the grid for a while. We had a baby and
unexpectedly ended up in the NICU. We just got him home a week ago.
Everyone is doing fine but I had to pretty much drop all
non-essential
work for a month or so.
Good to here that
Replace 'since..until' with 'revision range', in accordance with
the documentation.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Junio: sorry I missed this detail. Can you squeeze this patch
between [6/7] and [7/7] so that the commit message in [7/7] makes
sense?
Thanks.
Would it make sense to integrate this in git shortlog, which
already
does something similar?
Conceptually, yes, but the end result will be much larger in scope.
I am not sure if shortlog is still a good label for it.
since we are throwing ideas around...
The first place where I
Hi,
My .gitconfig has aliases like the following:
[alias]
bD = branch -D
bM = branch -M
Unfortunately, since the current config-parsing code unconditionally
runs tolower() on all keys, these aliases don't work. My proposal is
to modify alias.c::alias_lookup() to call a
Any comment on that ? I think anyone using a Topic Workflow could
use that feature and that it would be a nice addition to the project.
Maybe I'm totally wrong in the proposal below (please tell me !), but
there are some unanswered question that prevents me from starting (and
I'd really like this
Hi,
Following the discussion on merge with uncommited changes inside the
git pull --autostash thread, I did a bit of testing, and encountered a
case with silent data loss. In short: merge a branch introducing changes
to a file. If the file has been renamed in the current branch, then git
merge
Junio C Hamano gits...@pobox.com writes:
This is a minimalistic patch to fix the formatting. I removed the
extra sentence after the enumeration and moved it to the end of the
main text, but somebody may have a better idea to persuade AsciiDoc
to format it in a more reasonable way while
Hi,
As some might remember, I made a script that writes notes (as in
git-notes) linking patches to emails back in 2009:
http://thread.gmane.org/gmane.comp.version-control.git/109074
I resurrected this idea the other week, using a faster implementation
(the N command in fast-import is great!)
Jeff King venit, vidit, dixit 21.04.2013 05:37:
On Sat, Apr 20, 2013 at 03:38:53PM +0200, Michael J Gruber wrote:
Wait, this does the opposite of the last patch. If we do want to do
this, shouldn't the last one have been an expect_failure?
The last patch just documents the status quo, which
Ramkumar Ramachandra artag...@gmail.com writes:
was checking it out: a 'git log pathspec', when referring to a file
inside the subtree, doesn't work as expected: it only displays the
HEAD commit.
This is somehow expected: the subtree merge changed the filename during
merge (it is
Matthieu Moy wrote:
This is somehow expected: the subtree merge changed the filename during
merge (it is subtree/file.txt after the merge, and just file.txt
before), so git log without --follow just considers the file appeared.
No, a merge does not change any filenames. The history of the
Ramkumar Ramachandra artag...@gmail.com writes:
Matthieu Moy wrote:
This is somehow expected: the subtree merge changed the filename during
merge (it is subtree/file.txt after the merge, and just file.txt
before), so git log without --follow just considers the file appeared.
No, a merge
Thomas Rast wrote:
Umm, it should follow the rename.
There is no rename. Unless there is a commit with the following diff
(with heuristically similar content), I don't see how --follow can
work:
diff --git a/README b/README
deleted file mode 100644
diff --git a/subproject/README
Ramkumar Ramachandra wrote:
Unless there is a commit with the following diff
(with heuristically similar content), I don't see how --follow can
work:
diff --git a/README b/README
deleted file mode 100644
diff --git a/subproject/README b/subproject/README
new file mode
Ramkumar Ramachandra artag...@gmail.com writes:
So after a long IRC discussion trying to hash out what you *want* it to
do, here's the summary for everyone else. This test is wrong on several
counts. For simplicity I'll denote by M the subtree merge, called
$new_h in the actual test.
Thomas Rast tr...@inf.ethz.ch writes:
+test_expect_failure 'log pathspec in tree read into prefix' '
+git checkout --orphan subtree
+git rm -rf .
+echo foodle ichi
'ichi' also exists in M^1 because you reused a name from another test.
So rename detection will never pair the
Am 4/22/2013 11:24, schrieb Matthieu Moy:
Following the discussion on merge with uncommited changes inside the
git pull --autostash thread, I did a bit of testing, and encountered a
case with silent data loss. In short: merge a branch introducing changes
to a file. If the file has been renamed
Thomas Rast wrote:
[...]
I think you've misunderstood the whole thing. The histories of M^1
and M^2 are completely unrelated: they're from different projects
altogether. Considering the /ichi in M^2 a rename of the /ichi in
M^1 is completely wrong. They have nothing to do with each other. I
- Original Message -
From: ode
Date: 4/21/2013 4:22 PM
I went looking on Google and found git-cola gui client which works for
staging individual lines to the commit.
The 'git gui' that ships with Git also stages individual lines and
groups of lines, FWIW.
-Josh
--
To unsubscribe from
Johannes Sixt j.s...@viscovery.net writes:
Am 4/22/2013 11:24, schrieb Matthieu Moy:
Following the discussion on merge with uncommited changes inside the
git pull --autostash thread, I did a bit of testing, and encountered a
case with silent data loss. In short: merge a branch introducing
Thomas Rast tr...@inf.ethz.ch writes:
Thomas Rast tr...@inf.ethz.ch writes:
-- 8 --
Subject: [PATCH] git-log(1): remove --full-line-diff description
BTW, I generated this with your jc/format-patch, but it stopped working
after fc/send-email-annotate made it into next; I need this on top.
Ramkumar Ramachandra wrote:
$ git log README.md
What do you expect? The same output you would get if you cloned
gh:artagnon/clayoven separately and executed 'git log README.md' on
it.
And the reason I brought up rev-parse in the first place is because
this problem is not unique to log.
The --follow feature can be used to follow the history of a file over
a merge commit, and is useful even when the file hasn't been
copied/renamed. Add a test to show off this feature.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
I haven't updated the documentation, because I can't
Matthieu Moy matthieu@grenoble-inp.fr writes:
I could have expected git merge --abort to fail, but the problem is
really more serious here: data loss is done silently before giving me an
opportunity to do or abort anything.
I think this is a well known and longstanding failure case in the
Thomas Rast tr...@student.ethz.ch writes:
As some might remember, I made a script that writes notes (as in
git-notes) linking patches to emails back in 2009:
http://thread.gmane.org/gmane.comp.version-control.git/109074
I resurrected this idea the other week, using a faster implementation
Ramkumar Ramachandra artag...@gmail.com writes:
Thomas Rast wrote:
[...]
I think you've misunderstood the whole thing. The histories of M^1
and M^2 are completely unrelated: they're from different projects
altogether. Considering the /ichi in M^2 a rename of the /ichi in
M^1 is
Jeff King p...@peff.net writes:
Just my two cents as a reviewer.
My reasoning is twofold:
- consistency between git show commit and git show blob
I'm not sure I agree with this line of reasoning. git show commit is
showing a diff, not the file contents; textconv has always been about
On Mon, Apr 22, 2013 at 08:25:41AM -0700, Junio C Hamano wrote:
True. Applying textconv to otherwise unreadable blobs is often
useful, but I agree that it is unexpected if it is done by default,
especially given that many people have learned to do:
git show HEAD~4:binary-gob
On Sun, Apr 21, 2013 at 11:01:58AM -0700, Junio C Hamano wrote:
I think the rule could be something like:
1. If it looks like a URL (^scheme://), it is.
2. Otherwise, if it is a path in the filesystem, it is.
3. Otherwise, if it has a colon, it's host:path
4. Otherwise,
git show --textconv HEAD~4:binary-gob | less
but I doubt it is a good idea to turn it on by default this late in
the game.
Exactly. I certainly do not mind it as an option, and I am on the
fence
regarding it as a default (I think it might have been a sane thing to
do
from the
Thomas Rast wrote:
So (I think?) in the above you claim that $USER interprets
git log -- README.md
as
Show me the history of README.md.
But there's no such thing as the history of a file!
I made no such claims. I might not know as much as you or the others
on the list about git, but
Thomas Rast wrote:
The only thing that's broken in any of this is that I think, as
explained on IRC, that a hypothetical fixed --follow -C should be able
to figure out this case. By spending extra cycles on analysis,
naturally.
For the 100th time, nothing has been copied. There is no need
Ramkumar Ramachandra wrote:
For the 100th time, nothing has been copied. There is no need to
spend time on any analysis. It's a very straightforward problem that
requires no computation or heuristics: it just requires you to strip
the leading subproject/ when looking for pathspecs in the M^2
Jeremy Rosen jeremy.ro...@openwide.fr writes:
some features detect if they are piping to a terminal... couldn't we do
something like that ?
That's OK for convenience features like colors or so, but that would be
really, really unexpected to have
$ git show HEAD:file
foo
$ git show HEAD:file
Jeff King p...@peff.net writes:
So I think one reasonable path would be:
1. Do not treat host:path as ssh if host has a slash, which should
not regress anybody. It does not allow unadorned relative paths
with colons, but it lets you use absolute paths or ./ to
disambiguate.
The usage string for cherry-pick and revert has never been updated to
reflect their ability to handle multiple commits. Other documentation is
already correct.
Signed-off-by: Kevin Bracey ke...@bracey.fi
---
builtin/revert.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Do this by removing a couple of useless return statements. Without this
change, compilation with Sun C Compiler 5.9 (SunOS_i386 Patch 124868-15
2010/08/11) fails with the following message:
zlib.c, line 192: void function cannot return value
zlib.c, line 201: void function cannot return
Thomas Rast tr...@inf.ethz.ch writes:
So (I think?) in the above you claim that $USER interprets
git log -- README.md
as
Show me the history of README.md.
But there's no such thing as the history of a file! The command instead
says
If I filter all history for only changes
Stefano Lattarini stefano.lattar...@gmail.com writes:
Do this by removing a couple of useless return statements. Without this
change, compilation with Sun C Compiler 5.9 (SunOS_i386 Patch 124868-15
2010/08/11) fails with the following message:
zlib.c, line 192: void function cannot return
Am 22.04.2013 18:18, schrieb Stefano Lattarini:
Do this by removing a couple of useless return statements. Without this
change, compilation with Sun C Compiler 5.9 (SunOS_i386 Patch 124868-15
2010/08/11) fails with the following message:
zlib.c, line 192: void function cannot return value
Ramkumar Ramachandra wrote:
And if you're still not convinced, run 'git log HEAD^2 -- README.md'
from the toplevel directory. You'll get the log of README.md from the
subproject.
On IRC, Thomas explained to me that mixing in changes from various
branches into the pathspec will break this
On 04/22/2013 06:48 PM, Junio C Hamano wrote:
Stefano Lattarini stefano.lattar...@gmail.com writes:
Do this by removing a couple of useless return statements. Without this
change, compilation with Sun C Compiler 5.9 (SunOS_i386 Patch 124868-15
2010/08/11) fails with the following message:
Junio C Hamano wrote:
[...]
(3) When (1) notices that the path being followed did not exist in
any of the parents (be it a merge or a non-merge) and finds a
different path with a similar looking content, it _switches_
the pathspec to it, but the single pathspec it uses is a
Adam Spiers g...@adamspiers.org writes:
On Thu, Apr 11, 2013 at 03:11:32PM -0400, Jeff King wrote:
I always get a little nervous with sleeps in the test suite, as they are
indicative that we are trying to avoid some race condition, which means
that the test can fail when the system is under
Ramkumar Ramachandra artag...@gmail.com writes:
Meanwhile, you're evading the issue of assuming that all trees are
read into /, and are really representing the same project's history,
while this is not the case.
This is fundamenally how Git works. Git works with commit objects, each
commit
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
[...]
(3) When (1) notices that the path being followed did not exist in
any of the parents (be it a merge or a non-merge) and finds a
different path with a similar looking content, it _switches_
the
Ramkumar Ramachandra artag...@gmail.com writes:
Ramkumar Ramachandra wrote:
And if you're still not convinced, run 'git log HEAD^2 -- README.md'
from the toplevel directory. You'll get the log of README.md from the
subproject.
On IRC, Thomas explained to me that mixing in changes from
Since SSL provides no protection if the certificates aren't verified it's
better not to include sslverify=false in the examples.
Also in the post 1.8.2.1 era git is able to properly verify the validity of a
certificate as well it's origin.
Signed-off-by: Barbu Paul - Gheorghe
History simplification previously always treated merges as TREESAME
if they were TREESAME to any parent.
While the desired default behaviour, this could be extremely unhelpful
when searching detailed history, and could not be overridden. For
example, if a merge had ignored a change, as if by -s
Kevin Bracey ke...@bracey.fi writes:
diff --git a/revision.c b/revision.c
index eb98128..96fe3f5 100644
--- a/revision.c
+++ b/revision.c
@@ -516,8 +516,14 @@ static void try_to_simplify_commit(struct rev_info
*revs, struct commit *commit)
}
die(bad tree
Thanks for the feedback; here is a re-roll. A number of points
discussed on the mailing list were fixed. The main change, in patch
17, is how repack_without_ref() deals with references that cannot be
peeled when re-writing the packed-refs file:
if ISBROKEN:
emit an error and omit reference
Document the bits that can appear in the flags parameter passed to
an each_ref_function and/or in the ref_entry::flag field.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
refs.c | 12 +++-
refs.h | 13 +
2 files changed, 24 insertions(+), 1 deletion(-)
diff --git
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
refs.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/refs.c b/refs.c
index 1df1ccd..44cc2fc 100644
--- a/refs.c
+++ b/refs.c
@@ -525,10 +525,14 @@ static void sort_ref_dir(struct ref_dir *dir)
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
refs.c | 12
1 file changed, 12 insertions(+)
diff --git a/refs.c b/refs.c
index 30b4bf7..1df1ccd 100644
--- a/refs.c
+++ b/refs.c
@@ -109,7 +109,19 @@ struct ref_entry;
* (ref_entry-flag REF_DIR) is zero.
*/
struct
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
refs.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/refs.c b/refs.c
index 44cc2fc..efad658 100644
--- a/refs.c
+++ b/refs.c
@@ -528,6 +528,15 @@ static void sort_ref_dir(struct ref_dir *dir)
/* Include broken references in
Instead of copying the reference's SHA1 into a caller-supplied
variable, just return the ref_entry itself (or NULL if there is no
such entry). This change will allow the function to be used from
elsewhere.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
refs.c | 20 +---
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
refs.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/refs.c b/refs.c
index 91a2940..09b68e4 100644
--- a/refs.c
+++ b/refs.c
@@ -1282,10 +1282,9 @@ int peel_ref(const char *refname, unsigned char *sha1)
It is a nice, logical unit of work, and putting it in a function
removes the need to use a goto in peel_ref(). Soon it will also have
other uses.
The algorithm is unchanged.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
refs.c | 50 ++
Instead of just returning a success/failure bit, return an enumeration
value that explains the reason for any failure. This will come in
handy shortly.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
refs.c | 32
1 file changed, 24 insertions(+), 8
The old version was inconsistent: when a reference was
REF_KNOWS_PEELED but with a null peeled value, it returned non-zero
for the current reference but zero for other references. Change the
behavior for non-current references to match that of current_ref,
which is what callers expect. Document
Peel the entry, and as a side effect store the peeled value in the
entry. Use this function from two places in peel_ref(); a third
caller will be added soon.
Please note that this change can lead to ref_entries for unpacked refs
being peeled. This has no practical benefit but is harmless.
Stop emitting an error message when deleting a packed reference if we
find another dangling packed reference that is overridden by a loose
reference. See the previous commit for a longer explanation of the
issue.
We have to be careful to make sure that the invalid packed reference
really *is*
Add a function remove_ref(), which removes a single entry from a
reference cache.
Use this function to reimplement repack_without_ref(). The old
version iterated over all refs, packing all of them except for the one
to be deleted, then discarded the entire packed reference cache. The
new
When a reference that existed in the packed-refs file is deleted, the
packed-refs file must be rewritten. Previously, the file was
rewritten without any peeled refs, even if the file contained peeled
refs when it was read. This was not a bug, because the packed-refs
file header didn't claim that
Establish an internal API for iterating over references, which gives
the callback functions direct access to the ref_entry structure
describing the reference. (Do not change the iteration API that is
exposed outside of the module.)
Define a new internal callback signature
int
Change pack_one_ref() to call peel_entry() rather than using its own
code for peeling references. Aside from sharing code, this lets it
take advantage of the optimization introduced by 6c4a060d7d.
Please note that we *could* use any peeled values that happen to
already be stored in the
Change pack_refs() to work with a file descriptor instead of a FILE*
(making the file-locking code less awkward) and use
write_packed_entry() to do the writing.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
refs.c | 33 -
1 file changed, 8
There is no way to drop out of the while loop. This code has been
dead since 432ad41e.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
refs.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/refs.c b/refs.c
index e1e9ddd..7260768 100644
--- a/refs.c
+++ b/refs.c
@@ -666,13
Thomas Rast wrote:
There is a market for a rename detection that works at the tree level.
Exactly. And making it auto-follow with a low threshold would be a
great default. We'll have to deal with D/F conflicts that Junio was
talking about in (2), every once in a while. We'll have a lot more
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
refs.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/refs.c b/refs.c
index efad658..e1e9ddd 100644
--- a/refs.c
+++ b/refs.c
@@ -805,6 +805,9 @@ void invalidate_ref_cache(const char *submodule)
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
refs.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/refs.c b/refs.c
index 09b68e4..1c8edb1 100644
--- a/refs.c
+++ b/refs.c
@@ -1820,9 +1820,11 @@ static int repack_without_ref(const char *refname)
{
It is a nice unit of work and soon will be needed from multiple
locations.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
refs.c | 28
1 file changed, 20 insertions(+), 8 deletions(-)
diff --git a/refs.c b/refs.c
index 1c8edb1..8b554d8 100644
--- a/refs.c
A packed reference can be overridden by a loose reference, in which
case the packed reference is obsolete and is never used. The object
pointed to by such a reference can be garbage collected. Since
d66da478f2, this could lead to the emission of a spurious error
message:
error:
Change search_ref_dir() to return the index of the sought entry (or -1
on error) rather than a pointer to the entry. This will make it more
natural to use the function for removing an entry from the list.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
refs.c | 30
Use a single struct lock_file for both pack_refs() and
repack_without_ref().
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
refs.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/refs.c b/refs.c
index b41dd5e..850df8e 100644
--- a/refs.c
+++ b/refs.c
@@
pack-refs.c doesn't contain much code, and the code it does contain is
closely related to reference handling. Moreover, there is some
duplication between pack_refs() and repack_without_ref(). Therefore,
merge pack-refs.c into refs.c and pack-refs.h into refs.h.
The code duplication will be
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
refs.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/refs.c b/refs.c
index df670cb..b1cda1b 100644
--- a/refs.c
+++ b/refs.c
@@ -2007,18 +2007,17 @@ static int pack_one_ref(struct ref_entry *entry, void
Function do_not_prune() was redundantly checking REF_ISSYMREF, which
was already tested at the top of pack_one_ref(), so remove that check.
And the rest was trivial, so inline the function.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
refs.c | 11 ++-
1 file changed, 2
This code is about to be moved, so name the function more
distinctively.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
pack-refs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/pack-refs.c b/pack-refs.c
index 4461f71..d840055 100644
--- a/pack-refs.c
+++
pack_refs() was not using any of the extra features of for_each_ref(),
so change it to use do_for_each_entry(). This also gives it access to
the ref_entry and in particular its peeled field, which will be taken
advantage of in the next commit.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
Add a test that demonstrates that the peeled values recorded in
packed-refs are lost if a packed ref is deleted. (The code in
repack_without_ref() doesn't even attempt to write peeled refs.) This
will be fixed in a moment.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
Make this function conform to the naming convention established in
65385ef7d4 for the rest of the refs.c file.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
refs.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/refs.c b/refs.c
index 268c1a0..b41dd5e
Hold the ref_cache instance for the main repository in a dedicated,
statically-allocated instance to avoid the need for a function call
and a linked-list traversal when it is needed.
Suggested by: Heiko Voigt hvo...@hvoigt.net
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
refs.c | 60
Change the callers convert submodule names into ref_cache pointers.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
refs.c | 29 ++---
1 file changed, 14 insertions(+), 15 deletions(-)
diff --git a/refs.c b/refs.c
index b1cda1b..f246b77 100644
--- a/refs.c
+++
What's cooking in git.git (Apr 2013, #07; Mon, 22)
--
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
Both of the two topics on preparing git
Junio C Hamano wrote:
(1) It uses the given pathname as single pathspec and drill down
the same way without --follow until it notices the path
disappears and until then there is no attempt to detect renames
is made. And it only does -M variant of rename detection
On this. It
Applying Jonathan's idea on top of the early part that has graduated
to 'master', here is to add --ignore-removal (which is a more
natural way to say --no-all) and use it in the warning message.
Junio C Hamano (2):
git add: --ignore-removal is a better named --no-all
git add: rephrase
In the historical context of git add --all . that tells the
command to pay attention to all kinds of changes (implying
without ignoring removals), the option --no-all to countermand
it may have made some sense, but because we will be making --all
the default when a pathspec is given, it makes more
With the synonym --ignore-removal for --no-all, we can rephrase
the Git 2.0 transition warning message in a more natural way.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/add.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/builtin/add.c
From: Ramkumar Ramachandra artag...@gmail.com
Sent: Monday, April 22, 2013 8:54 PM
Thomas Rast wrote:
There is a market for a rename detection that works at the tree
level.
Exactly. And making it auto-follow with a low threshold would be a
great default. We'll have to deal with D/F
On Mon, Apr 15, 2013 at 11:53:39 +0200, Torstein Hegge wrote:
On Mon, Apr 15, 2013 at 06:38:09 +0200, Christian Couder wrote:
I wonder if we should also write something into the bisect log if for
example the bisection stopped because there are only 'skip'ped commits
left to test. But maybe
Thomas Rast tr...@inf.ethz.ch writes:
So how can we fix that? We could try to somehow figure out that M:sub/
refers to the same thing as M^2:/, by looking at them at the tree level.
Let's provisionally call this --follow-tree-rename.
There was a patch serie long ago that implemented
Philip Oakley wrote:
Is this not similar to the previous attempts at bulk rename detection? Such
as $gmane/160233.
Yes. Does anyone know what happened to the series?
... and I wonder how git merge -s subtree works (still reading).
--
To unsubscribe from this list: send the line unsubscribe
Torstein Hegge he...@resisty.net writes:
I took another look at this. I wasn't able to come up with anything
useful for the The merge base $rev is bad case, but for the only
skipped commits left to test case one could do something like this.
We skipped them because we can gain _no_
On Mon, Apr 22, 2013 at 12:18 PM, Stefano Lattarini
stefano.lattar...@gmail.com wrote:
zlib: fix compilation failures with Sun C Compilaer
s/Compilaer/compiler/
Do this by removing a couple of useless return statements. Without this
change, compilation with Sun C Compiler 5.9 (SunOS_i386
Hi,
Now that the safter first round is merged to master, it's time for the second
round which is a little tricker. Most of the patches should be safe, but the
later ones might be not. All the tests pass, even gitifyhg ones, so everything
seems to be fine, but we shall see.
Among the important
It is possible that the remote has changed the bookmarks, so let's fetch
them before we make any assumptions, just the way mercurial does.
Probably doesn't make a difference, but better be safe than sorry.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
From: Dusty Phillips du...@linux.ca
It is deprecated.
[fc: do the same in remote-bzr]
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-bzr | 2 +-
contrib/remote-helpers/git-remote-hg | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
It's simpler, and we don't need to depend on certain Mercurial versions.
Also, now we don't update the URL if 'file://' is not present.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 9 +
1 file changed, 5 insertions(+), 4
Idea from gitifyhg, the backwards compatibility is how Mercurial used to
do it.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-hg
1 - 100 of 130 matches
Mail list logo
