On Wed, Apr 10, 2013 at 10:35 PM, Antoine Pelisse wrote:
> The goal is to propose a structure for storing and pre-merging pairs of
> commits.
>
> Data-structure
> ==
>
> We could use a note ref to store the pre-merge information. Each commit
> would be annotated with a blob containing
Hi,
Ramkumar Ramachandra wrote:
> 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.
I can't claim to have followed the discussion, but I don't understand
the
On Mon, Apr 22, 2013 at 6:41 PM, Junio C Hamano wrote:
> diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
> index 48754cb..77ad391 100644
> --- a/Documentation/git-add.txt
> +++ b/Documentation/git-add.txt
> @@ -53,8 +53,14 @@ OPTIONS
> Files to add content from. Fileglo
On Tue, Apr 23, 2013 at 12:43 AM, Junio C Hamano wrote:
> No docs? No tests?
Maybe simply adding this text to git-commit.txt,
The default can be changed by the 'commit.gpg-sign' configuration
variable (see linkgit:git-config[1]).
after,
-S[]::
--gpg-sign[=]::
GPG-sign commit.
would be suffic
Ramkumar Ramachandra writes:
> Am I making any sense?
I dunno. Depends on the definition of "sense".
It sounds like you are repeating the same old "let's record renames
in the commit", and in a system (not Git) where recording renames
may make sense, you may be making sense.
But we will not r
Joel Jacobson writes:
> Signed-off-by: Joel Jacobson
> ---
> builtin/commit.c | 4 +++-
No docs? No tests?
As to the design, any regular configuration variable settings must
be overridable from the command line for a single invocation. Please
design an escape hatch in, for somebody who has th
On 04/22/2013 04:35 PM, Felipe Contreras wrote:
On Mon, Apr 22, 2013 at 5:28 PM, Junio C Hamano wrote:
Felipe Contreras writes:
From: Dusty Phillips
It is deprecated.
[fc: do the same in remote-bzr]
Signed-off-by: Felipe Contreras
---
No sign-off by the author?
It does not matter for
Felipe Contreras writes:
> On Mon, Apr 22, 2013 at 5:32 PM, Junio C Hamano wrote:
>> Felipe Contreras writes:
>>
>>> Mercurial supports them, Git doesn't.
>>
>> Another important thing to note is that you represent a SP with
>> three underscores on our side, no?
>
> Probably, I don't think it's
Ramkumar Ramachandra wrote:
> [...]
Oh, and I forgot the best part. True floating submodules when the
bind line references a zeroed-out hex. Naturally, the diff'ing to
figure out changes introduced by the submodule will be blocked. Also
good for dropping in huge binary files at a particular pat
Junio C Hamano wrote:
> I have forgotten about this topic (and its numerous iterations in
> the past), but it appears me that people mostly lost interest after
> v7 review cycle where the series looked like a solution that is
> looking for a problem.
I agree. Over-generalizing the problem is goin
Make "git add ..." notice paths that have been removed
from the working tree, i.e. a synonym to "git add -A ...".
Given that "git add " is to update the index with the
state of the named part of the working tree as a whole, it makes it
more intuitive, and also makes it possible to simplify the adv
On Mon, Apr 22, 2013 at 5:32 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> Mercurial supports them, Git doesn't.
>
> Another important thing to note is that you represent a SP with
> three underscores on our side, no?
Probably, I don't think it's really important. Perhaps some users
Torstein Hegge writes:
> On Mon, Apr 22, 2013 at 14:13:00 -0700, Junio C Hamano wrote:
>> Torstein Hegge 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
On Mon, Apr 22, 2013 at 5:28 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> From: Dusty Phillips
>>
>> It is deprecated.
>>
>> [fc: do the same in remote-bzr]
>>
>> Signed-off-by: Felipe Contreras
>> ---
>
> No sign-off by the author?
>
> It does not matter for something so trivial l
Felipe Contreras writes:
> So that we can find already exported ones. We can never be 100% sure
> that we already exported such data, due to mercurial design, it at least
> sometimes we should detect them, and so should give ups some performance
s/ups/us/ (will locally tweak).
> boost.
>
> Sign
Felipe Contreras writes:
> Mercurial supports them, Git doesn't.
Another important thing to note is that you represent a SP with
three underscores on our side, no?
> Signed-off-by: Felipe Contreras
> ---
> contrib/remote-helpers/git-remote-hg | 25 +
> 1 file changed,
Felipe Contreras writes:
> From: Dusty Phillips
>
> It is deprecated.
>
> [fc: do the same in remote-bzr]
>
> Signed-off-by: Felipe Contreras
> ---
No sign-off by the author?
It does not matter for something so trivial like this that there is
no other way to write, but it is a good habit you
Michael Haggerty writes:
> For now I left the sleeps in t3210. Given that the problem will be
> solved by topic jc/prune-all, building a fancier workaround into this
> test for the old broken --expire behavior seems like a waste of time.
> I propose that the sleeps be removed when this patch ser
Michael Haggerty writes:
> 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 in
On Mon, Apr 22, 2013 at 14:13:00 -0700, Junio C Hamano wrote:
> Torstein Hegge 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 li
On 04/22/2013 11:41 PM, Eric Sunshine wrote:
> On Mon, Apr 22, 2013 at 12:18 PM, Stefano Lattarini
> wrote:
>> zlib: fix compilation failures with Sun C Compilaer
>
> s/Compilaer/compiler/
>
Oops, well spotted. Junio, can you fix this locally?
Thanks, and sorry for the stupid typo,
Stefano
-
There's no functional change since mercurial commit operation strips
that anyway, but that's no excuse for us not to do the right thing. So
let's be explicit about it.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-hg | 4
1 file changed, 4 insertions(+)
diff --git a
So that we can find already exported ones. We can never be 100% sure
that we already exported such data, due to mercurial design, it at least
sometimes we should detect them, and so should give ups some performance
boost.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-hg |
Load previous manifest first as Mercurial does; for caching reasons.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-hg | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index 6
Mercurial supports them, Git doesn't.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-hg | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index dbb4091
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-hg | 3 +++
1 file changed, 3 insertions(+)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index 4f6c7b7..dbb4091 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remot
Matthieu Moy writes:
> Thomas Rast 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 imp
So that we can use shortened URLs, for example 'bb:://felipec/repo'
(Bitbucket).
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-hg | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-hg | 10 --
contrib/remote-helpers/test-hg.sh| 8
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index 3c6eeb7.
There's no point in calling the tag method for such simple action. Not
that we care much about the hg-git compat mode, it's mostly just for
comparison testing purposes.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-hg | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-hg | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index f5e4ba7..f685990 100755
--- a/contrib/remote-helpers/git-remote-hg
The one from mercurial is meant for users, on top of the latest tip.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-hg | 33 -
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remo
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-hg | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index bd93f82..4a1c637 100755
--- a/contrib/remote-helpers/git-remot
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-hg | 4
1 file changed, 4 insertions(+)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index b6589a3..a4db5b0 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remo
Idea from gitifyhg, the backwards compatibility is how Mercurial used to
do it.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-hg | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/
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
---
contrib/remote-helpers/git-remote-hg | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/contrib/r
From: Dusty Phillips
It is deprecated.
[fc: do the same in remote-bzr]
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-bzr | 2 +-
contrib/remote-helpers/git-remote-hg | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/contrib/remote-helpers/git-remo
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
---
contrib/remote-helpers/git-remote-hg | 2 ++
1 file c
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 cha
On Mon, Apr 22, 2013 at 12:18 PM, Stefano Lattarini
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 Patch 124868-15
> 2010/08/11
Ramkumar Ramachandra wrote:
> 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?
Hm, this and the series Matthieu posted ($gmane/163328) seems to be
solving the more genera
Torstein Hegge 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_ information from test
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
Thomas Rast 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 directory rename
detect
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
From: "Ramkumar Ramachandra"
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 conflicts that Junio was
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
---
builtin/add.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/builtin/add.c b/builtin/add.c
index a
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 m
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 -A/-
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
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
Change the callers convert submodule names into ref_cache pointers.
Signed-off-by: Michael Haggerty
---
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
+++ b/refs.c
@@ -1503,16 +
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
Signed-off-by: Michael Haggerty
---
refs.c | 60 +++--
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
---
t/t3211-peel-ref.sh | 9 +
Make this function conform to the naming convention established in
65385ef7d4 for the rest of the refs.c file.
Signed-off-by: Michael Haggerty
---
refs.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/refs.c b/refs.c
index 268c1a0..b41dd5e 100644
--- a/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
---
refs.c | 29 +++
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
---
refs.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(
This code is about to be moved, so name the function more
distinctively.
Signed-off-by: Michael Haggerty
---
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
+++ b/pack-refs.c
@@ -23,7 +2
Signed-off-by: Michael Haggerty
---
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
*cb_data)
{
s
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 addre
Use a single struct lock_file for both pack_refs() and
repack_without_ref().
Signed-off-by: Michael Haggerty
---
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
@@ -2091,7 +2091,7 @@ sta
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
---
refs.c | 30 ++
1 file cha
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: refs/heads/ma
Signed-off-by: Michael Haggerty
---
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)
{
struct repack_withou
It is a nice unit of work and soon will be needed from multiple
locations.
Signed-off-by: Michael Haggerty
---
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
+++ b/refs.c
@@ -529,
Signed-off-by: Michael Haggerty
---
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)
clear_loose_ref_cache(refs);
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
i
There is no way to drop out of the while loop. This code has been
dead since 432ad41e.
Signed-off-by: Michael Haggerty
---
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 +666,6 @@ static int do_
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
---
refs.c | 33 -
1 file changed, 8 insertions(+), 25 deletions(-)
di
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 ref_entrie
Extract the I/O code from the "business logic" in repack_ref_fn().
Later there will be another caller for this function.
Signed-off-by: Michael Haggerty
---
refs.c | 46 ++
1 file changed, 30 insertions(+), 16 deletions(-)
diff --git a/refs.c b/refs.c
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 each_ref_entry_f
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
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 version
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.
Signe
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* ove
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 t
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
---
refs.c | 32
1 file changed, 24 insertions(+), 8 deletions(-)
diff --git
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
---
refs.c | 50 ++
1 file changed, 30 i
Signed-off-by: Michael Haggerty
---
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)
return -1;
Signed-off-by: Michael Haggerty
---
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 a do_for_each_ref*()
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
---
refs.c | 20 +---
1 file changed, 9 i
Signed-off-by: Michael Haggerty
---
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 ref_value {
+ /*
Signed-off-by: Michael Haggerty
---
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)
dir->sorted = dir->nr
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
---
refs.c | 12 +++-
refs.h | 13 +
2 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/refs.c b/refs.c
i
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 f
Kevin Bracey 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 compare for
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 o
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
---
Documentation/g
Ramkumar Ramachandra 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 various
> bran
Ramkumar Ramachandra 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 pathspec to i
Ramkumar Ramachandra 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 object points to a
Adam Spiers 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 load, or when
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
On 04/22/2013 06:48 PM, Junio C Hamano wrote:
> Stefano Lattarini 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", lin
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 so
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
Stefano Lattarini 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 value
> "zlib.c",
Thomas Rast 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 affecting a
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 v
1 - 100 of 139 matches
Mail list logo
