Torstein Hegge writes:
> When bisect successfully finds a single revision, the first bad commit
> should be shown to human readers of 'git bisect log'.
>
> This resolves the apparent disconnect between the bisection result and
> the log when a bug reporter says "I know that the first bad commit i
Ramkumar Ramachandra writes:
> Currently, executing a 'git pull' on a dirty worktree gives the
> following annoying message:
s/annoying//;
In general, avoid forcing your value judgement to readers when you
do not have to. Instead, you can just highlight the source of your
annoyance and let the
On 04/14/2013 01:33 PM, Eric S. Raymond wrote:
> [...]
> I wish I could point you at a convertor I really trust. I can't.
> There is a third tool, cvs2git (based on the analyzer from cvs2svn)
> that I don't maintain, which has problems of its own.
^
From: Torstein Hegge
Subject: [PATCH] bisect: Store first bad commit as comment in log file
Date: Sat, 13 Apr 2013 17:22:57 +0200
> When bisect successfully finds a single revision, the first bad commit
> should be shown to human readers of 'git bisect log'.
>
> This resolves the apparent discon
Ramkumar Ramachandra writes:
> ... In my proposal, the
> precedence order branch..pushremote, remote.pushdefault,
> branch..remote, remote.default, origin, remains the same: we
> just want to change which branch that refers to.
That "changing the meaning of " in the middle, and doing so
will b
On Sun, Apr 14, 2013 at 10:51 PM, Junio C Hamano wrote:
> Here is what I tentatively queued.
>
> rebase-am: explicitly disable cover-letter
>
> If the user has a cover-letter configuration set to anything
> other than 'false', 'git format-patch' may generate a cover
> letter, which
Felipe Contreras writes:
> Otherwise when using 'git branch -vv' it's hard to see them among so
> much output.
>
> Signed-off-by: Felipe Contreras
> ---
>
> This time with strbuf.
>
> Documentation/config.txt | 3 ++-
> builtin/branch.c | 38 ++
> 2
Felipe Contreras writes:
>> You are mean to say "fix regression", which gave me a small heart
>> attack ;-). I was worried if we had already merged it to 'next'.
>>
>> As I already wrote in the recent "What's cooking", the series looks
>> good to me. I am inclined to say that we should merge it
Junio C Hamano writes:
> If the envisioned use of this is to use it as a building block of
> something else that is user-facing (e.g. the user says "git add",
> and before the command finishes, somewhere we internally run "git
> clone"), then would it be possible that you are better off running
>
Otherwise when using 'git branch -vv' it's hard to see them among so
much output.
Signed-off-by: Felipe Contreras
---
This time with strbuf.
Documentation/config.txt | 3 ++-
builtin/branch.c | 38 ++
2 files changed, 32 insertions(+), 9 deletions(-
On Sun, Apr 14, 2013 at 8:48 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> If you have a cover-letter configuration set to anything other than
>> 'false', 'git format-patch' might generate a cover letter, and 'git am'
>> doesn't seem to like that.
>>
>> Ideally 'git am' should skip th
On Sun, Apr 14, 2013 at 8:52 PM, Junio C Hamano wrote:
> Jeff King writes:
>
>> On Sun, Apr 14, 2013 at 06:38:27PM -0500, Felipe Contreras wrote:
>>
>>> +if (want_color(branch_use_color))
>>> +snprintf(fancy, sizeof(fancy), "%s%s%s",
>>> +
> 15 git rebase --stash, git pull --rebase --stash
It seems that Ramkumar Ramachandra is working on this in his "[PATCH
v2 0/3] Introduce pull.autostash" series
Ping Yin
On Mon, Apr 15, 2013 at 4:04 AM, Matthieu Moy
wrote:
> Hi,
>
> Like the years before, I'm going to offer my students a 1 mont
Jeff King writes:
> On Sun, Apr 14, 2013 at 06:38:27PM -0500, Felipe Contreras wrote:
>
>> +if (want_color(branch_use_color))
>> +snprintf(fancy, sizeof(fancy), "%s%s%s",
>> +branch_get_color(BRANCH_COLOR_UPSTREAM),
>> +
Felipe Contreras writes:
> If you have a cover-letter configuration set to anything other than
> 'false', 'git format-patch' might generate a cover letter, and 'git am'
> doesn't seem to like that.
>
> Ideally 'git am' should skip the cover-letter, but for now lets just fix
> the regression.
>
>
"Philip Oakley" writes:
>> If the "parsing" is done for white/blacklist purposes, is there a
>> need to straight-jacket the verison string format like this series?
>
> The purpose is to document what we felt we could guarantee, and that
> which was open to variation, so that those, like the Git-G
On Sun, Apr 14, 2013 at 8:31 PM, Duy Nguyen wrote:
> On Mon, Apr 15, 2013 at 11:24 AM, Felipe Contreras
> wrote:
>> On Sun, Apr 14, 2013 at 7:55 PM, Duy Nguyen wrote:
>>> On Mon, Apr 15, 2013 at 9:54 AM, Felipe Contreras
>>> wrote:
On Sun, Apr 14, 2013 at 6:46 PM, Duy Nguyen wrote:
>
Jeff King writes:
> On Sat, Apr 13, 2013 at 11:04:49PM -0700, Junio C Hamano wrote:
>
>> Suppose you want to give one bit per existing ref and paint commits
>> down to find which refs are descendants of each commit. You find
>> that you have 320 refs only at runtime.
>>
>> The code can declare a
On Mon, Apr 15, 2013 at 11:24 AM, Felipe Contreras
wrote:
> On Sun, Apr 14, 2013 at 7:55 PM, Duy Nguyen wrote:
>> On Mon, Apr 15, 2013 at 9:54 AM, Felipe Contreras
>> wrote:
>>> On Sun, Apr 14, 2013 at 6:46 PM, Duy Nguyen wrote:
On Mon, Apr 15, 2013 at 9:22 AM, Felipe Contreras
wrote
Jeff King writes:
> Yes, but isn't that a constant:
>
> (512*1024-32) / sizeof(struct commit_slab_piece)
>
> Leaving it as such lets the compiler optimize better, and is safe from
> anybody changing it at runtime. But I think the answer to my question is
> "yes, that would be the best thing for
Ramkumar Ramachandra writes:
> This configuration variable comes into effect when 'git clone' is
> invoked inside an existing git repository's worktree. When set,
> instead of cloning the given repository as-is, it relocates the gitdir
> of the repository to the path specified by this variable.
On Sun, Apr 14, 2013 at 7:55 PM, Duy Nguyen wrote:
> On Mon, Apr 15, 2013 at 9:54 AM, Felipe Contreras
> wrote:
>> On Sun, Apr 14, 2013 at 6:46 PM, Duy Nguyen wrote:
>>> On Mon, Apr 15, 2013 at 9:22 AM, Felipe Contreras
>>> wrote:
On Sun, Apr 14, 2013 at 5:31 PM, Duy Nguyen wrote:
> O
On Sat, Apr 13, 2013 at 12:03:15PM +0100, João Joyce wrote:
> I have tried to remove and recreate my git folder and remove some
> files to get more logs. Here they are:
Your output looks quite odd.
> packet: push<
> capabilities^{}\0 report-statu
On Mon, Apr 15, 2013 at 9:54 AM, Felipe Contreras
wrote:
> On Sun, Apr 14, 2013 at 6:46 PM, Duy Nguyen wrote:
>> On Mon, Apr 15, 2013 at 9:22 AM, Felipe Contreras
>> wrote:
>>> On Sun, Apr 14, 2013 at 5:31 PM, Duy Nguyen wrote:
On Sun, Apr 14, 2013 at 11:46 AM, Felipe Contreras
wrote
On Sun, Apr 14, 2013 at 06:38:27PM -0500, Felipe Contreras wrote:
> + if (want_color(branch_use_color))
> + snprintf(fancy, sizeof(fancy), "%s%s%s",
> + branch_get_color(BRANCH_COLOR_UPSTREAM),
> +
On Sun, Apr 14, 2013 at 6:46 PM, Duy Nguyen wrote:
> On Mon, Apr 15, 2013 at 9:22 AM, Felipe Contreras
> wrote:
>> On Sun, Apr 14, 2013 at 5:31 PM, Duy Nguyen wrote:
>>> On Sun, Apr 14, 2013 at 11:46 AM, Felipe Contreras
>>> wrote:
+ char fancy[80];
- if (show_upstrea
On Mon, Apr 15, 2013 at 9:25 AM, Adam Spiers wrote:
>> > The introduction of argc also makes it possible to invoke
>> > check_ignore() with arguments which are not self-consistent.
>>
>> This is the same problem with main()
>
> How could main() be invoked with argc inconsistent with argv?
The poi
On Mon, Apr 15, 2013 at 9:22 AM, Felipe Contreras
wrote:
> On Sun, Apr 14, 2013 at 5:31 PM, Duy Nguyen wrote:
>> On Sun, Apr 14, 2013 at 11:46 AM, Felipe Contreras
>> wrote:
>>> + char fancy[80];
>>>
>>> - if (show_upstream_ref)
>>> + if (show_upstream_ref) {
>>>
Otherwise when using 'git branch -vv' it's hard to see them among so
much output.
Signed-off-by: Felipe Contreras
---
Documentation/config.txt | 3 ++-
builtin/branch.c | 35 +++
2 files changed, 29 insertions(+), 9 deletions(-)
diff --git a/Documentatio
On Sat, Apr 13, 2013 at 09:09:33AM +1000, Duy Nguyen wrote:
> On Sat, Apr 13, 2013 at 1:03 AM, Adam Spiers wrote:
> >> -static int check_ignore(const char *prefix, const char **pathspec)
> >> +static int check_ignore(int argc, const char **argv, const char *prefix)
> >> {
> >> struct dir_st
On Sun, Apr 14, 2013 at 5:31 PM, Duy Nguyen wrote:
> On Sun, Apr 14, 2013 at 11:46 AM, Felipe Contreras
> wrote:
>> + char fancy[80];
>>
>> - if (show_upstream_ref)
>> + if (show_upstream_ref) {
>> ref = shorten_unambiguous_ref(branch->merge[0]->dst, 0);
>> +
On Sun, Apr 14, 2013 at 11:46 AM, Felipe Contreras
wrote:
> + char fancy[80];
>
> - if (show_upstream_ref)
> + if (show_upstream_ref) {
> ref = shorten_unambiguous_ref(branch->merge[0]->dst, 0);
> + if (want_color(branch_use_color))
> +
If you have a cover-letter configuration set to anything other than
'false', 'git format-patch' might generate a cover letter, and 'git am'
doesn't seem to like that.
Ideally 'git am' should skip the cover-letter, but for now lets just fix
the regression.
Signed-off-by: Felipe Contreras
---
git
From: "Junio C Hamano"
Sent: Sunday, April 14, 2013 8:22 PM
Philip Oakley writes:
This patch series seeks to add tests for the version string format
and document it.
The key questions to be answered are:
* should the test be inside t, or somewhere else?
* should the version string be lim
On Sat, Apr 13, 2013 at 10:49:36PM -0700, Junio C Hamano wrote:
> Thanks. I'll queue with the following API fix-up on this, with
> obvious adjustments necessary for the later ones.
>
> * read_blob_data_from_index() is descriptive enough. If you read a
>blob from the index, you would ask for i
Hi,
Like the years before, I'm going to offer my students a 1 month project
(end of May -> end of June) where they can contribute to a free
software, in particular Git.
Students are free to pick the feature they want, but I maintain a list
of small project ideas on the wiki to help them:
https
Jeff King writes:
> On Sun, Apr 14, 2013 at 05:34:56PM +0100, John Keeping wrote:
>
>> After the location of $TRASH_DIRECTORY is adjusted by
>> $TEST_OUTPUT_DIRECTORY, we go on to use the $test variable to make the
>> trash directory and cd into it. This means that when
>> $TEST_OUTPUT_DIRECTORY
On Sun, Apr 14, 2013 at 05:34:56PM +0100, John Keeping wrote:
> After the location of $TRASH_DIRECTORY is adjusted by
> $TEST_OUTPUT_DIRECTORY, we go on to use the $test variable to make the
> trash directory and cd into it. This means that when
> $TEST_OUTPUT_DIRECTORY is not "." and an absolute
Philip Oakley writes:
> This patch series seeks to add tests for the version string format
> and document it.
>
> The key questions to be answered are:
> * should the test be inside t, or somewhere else?
> * should the version string be limited to one line, <80 characters?
One line, perhaps,
On Sun, Apr 14, 2013 at 11:51:40AM -0700, Junio C Hamano wrote:
> > I don't know if shrinking the size of the realloc is all that big a
> > deal. We are doubling, so the allocation cost is already amortized
> > constant time.
>
> I was more disturbed about copying the actual bytes. One of the
> e
Felipe Contreras writes:
> It's hard to see them among so much output otherwise.
>
> Signed-off-by: Felipe Contreras
> ---
> builtin/branch.c | 27 ---
> 1 file changed, 20 insertions(+), 7 deletions(-)
>
> diff --git a/builtin/branch.c b/builtin/branch.c
> index 00d17d2
On Sun, Apr 14, 2013 at 8:56 PM, Jeff King wrote:
>> More to the point, I can easily imagine many scripts relying on git
>> config returning a value to indicate that a config item has been set.
>> Your proposed change would break all those. For that reason, it might
>> be nicer to introduce a fla
Jeff King writes:
> Thanks, this writeup makes sense to me. Obviously,
>
> Signed-off-by: Jeff King
>
> Comparing a slab index versus a util pointer, I think the differences
> should be:
> ...
> So I think the util pointer is strictly better, except for point (2). And
> the main cost is point
On Sun, Apr 14, 2013 at 11:45:10AM -0700, Junio C Hamano wrote:
> Just rerolling with what _you_ think is an appropriate level of
> explanation (either or both in log and in-code) and see what happens
> would probably be the best way to proceed, I think, at this
> point. Either you hear "It still
On Sun, Apr 14, 2013 at 10:47:31PM +1000, Andrew Ardill wrote:
> More to the point, I can easily imagine many scripts relying on git
> config returning a value to indicate that a config item has been set.
> Your proposed change would break all those. For that reason, it might
> be nicer to introdu
Am 13.04.2013 06:04, schrieb eacousineau:
> Signed-off-by: eacousineau
> ---
> I see what you meant by the extra variables, so I've fixed that so the
> original flags aren't needed with recursion.
Thanks, the code is looking much better now and you nicely
described the changes you made since the
Jeff King writes:
> On Sat, Apr 13, 2013 at 11:04:48PM -0700, Junio C Hamano wrote:
>
>> Instead of using a single "slab" and keep reallocating it as we find
>> that we need to deal with commits with larger values of commit->index,
>> make a "slab" an array of many "slab_piece"s. Each access may
Felipe Contreras writes:
> On Sun, Apr 14, 2013 at 12:13 AM, Junio C Hamano wrote:
>> Felipe Contreras writes:
>>
>>> Why wasn't this patch merged to 'pu'? To my knowledge nobody raised
>>> any real concerns.
>>
>> There are many reasons not to queue _everything_ ever posted to the
>> list on '
On Sat, Apr 13, 2013 at 11:04:49PM -0700, Junio C Hamano wrote:
> Suppose you want to give one bit per existing ref and paint commits
> down to find which refs are descendants of each commit. You find
> that you have 320 refs only at runtime.
>
> The code can declare a commit slab "struct flagbit
After the location of $TRASH_DIRECTORY is adjusted by
$TEST_OUTPUT_DIRECTORY, we go on to use the $test variable to make the
trash directory and cd into it. This means that when
$TEST_OUTPUT_DIRECTORY is not "." and an absolute --root has not been
specified, we do not remove the trash directory on
On Sun, Apr 14, 2013 at 12:23 AM, Junio C Hamano wrote:
> "Double" may only be showing that we do not have enough trusted
> maintainers; ideally I would like it to have "Triple" or more.
A double or triple review raises *a single* standard higher, but
having more than one standard is never good.
On Sun, Apr 14, 2013 at 12:13 AM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> Why wasn't this patch merged to 'pu'? To my knowledge nobody raised
>> any real concerns.
>
> There are many reasons not to queue _everything_ ever posted to the
> list on 'pu', and they are almost always not
On Sat, Apr 13, 2013 at 11:04:48PM -0700, Junio C Hamano wrote:
> Instead of using a single "slab" and keep reallocating it as we find
> that we need to deal with commits with larger values of commit->index,
> make a "slab" an array of many "slab_piece"s. Each access may need
> two levels of indir
On Sat, Apr 13, 2013 at 11:04:47PM -0700, Junio C Hamano wrote:
> From: Jeff King
>
> The "indegree" field in the commit object is only used while sorting
> a list of commits in topological order, and wasting memory otherwise.
>
> We would prefer to shrink the size of individual commit objects,
Sebastian Schuberth wrote:
> Hi,
>
> I'm just wondering why it was decided to work like this. IMHO it's quite
> inconvenient that git config outputs nothing for any unset (but known)
> variable. Usually when I query a variable I'm not so much interested in
> whether it is at all (explicitly) set t
The git version string is used in the wild, and in git gui,
for capability checking purposes. Test the string format
and version X.Y.Z number.
The version string shall be:
* a single line
* less that 80 characters
* start with `git version `
* with a following numeric X.Y.Z version.
The remaining
In $gmane/217004 I was noted that the git version string is used
in the wild for confirming which git version is in use.
This patch series seeks to add tests for the version string format
and document it.
The key questions to be answered are:
* should the test be inside t, or somewhere else?
Provide the regular expression that matches the
'git --version' strings.
Scripts in the wild, including 'git gui', check the git version.
Signed-off-by: Philip Oakley
---
Should the string be described by a regular expression?
How to format the regular expression for asciidocs - it doesn't
get
Junio C Hamano wrote:
> [...]
> In any case, dispelling a misplaced blame on "matching" is not the
> main point of this message.
I _thought_ "matching" was a good scapegoat to blame current user
expectations on. However, it's okay if you think that we're
misplacing the blame. As long as we can a
On 14 April 2013 22:56, Sebastian Schuberth wrote:
>> The closest thing I can see for doing this is git config --list, but
>> perhaps there should be a flag to check if a config item is set?
>
> Yet more command line options? Well, there's probably no way around
> that in order to maintain backwar
Signed-off-by: Michael Haggerty
---
refs.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/refs.c b/refs.c
index 923d34f..361a28f 100644
--- a/refs.c
+++ b/refs.c
@@ -2005,16 +2005,15 @@ static int pack_one_ref(struct ref_entry *entry, void
*cb_data)
{
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 +++
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
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
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 c523978..dfc8600 100644
--- a/refs.c
+++ b/refs.c
@@ -529,
Signed-off-by: Michael Haggerty
---
refs.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/refs.c b/refs.c
index 1df1ccd..f503ec4 100644
--- a/refs.c
+++ b/refs.c
@@ -525,10 +525,14 @@ static void sort_ref_dir(struct ref_dir *dir)
dir->sorted = dir->nr =
Signed-off-by: Michael Haggerty
---
refs.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/refs.c b/refs.c
index 88ff153..7cbf228 100644
--- a/refs.c
+++ b/refs.c
@@ -805,6 +805,9 @@ void invalidate_ref_cache(const char *submodule)
clear_loose_ref_cache(refs);
Signed-off-by: Michael Haggerty
---
refs.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/refs.c b/refs.c
index cf017a5..c523978 100644
--- a/refs.c
+++ b/refs.c
@@ -1818,9 +1818,11 @@ static int repack_without_ref(const char *refname)
{
struct repack_withou
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
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
On Sun, Apr 14, 2013 at 2:47 PM, Andrew Ardill wrote:
> On 14 April 2013 22:34, Sebastian Schuberth wrote:
>> Usually when I query a variable I'm not so much interested in whether it is
>> at all (explicitly) set to some value or not, but what value is currently in
>> use.
>
> With your change
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
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 +++--
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
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 361a28f..cfcb42f 100644
--- a/refs.c
+++ b/refs.c
@@ -1505,14 +
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(
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
---
Please checked that I am using the file-locking API correctly; I'm not
that familiar with it.
ref
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
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 16c237c..e0411c5 100644
--- a/refs.c
+++ b/refs.c
@@ -2089,7 +2089,7 @@ sta
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 | 9 +
1 file changed, 9 insertions(+)
diff --git a/refs.c b/refs.c
index f503ec4..88ff153 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*()
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 7cbf228..9f508dd 100644
--- a/refs.c
+++ b/refs.c
@@ -666,13 +666,6 @@ static int do_
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 6c7f92c..16c237c 100644
--- a/refs.c
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
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 | 40 +++-
1 file changed, 27 insertions(+), 13 deletions(-)
diff --git a/refs.c b/refs.c
index
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
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 +
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
Stop emitting an error message for dangling packed references found
when deleting another packed reference. See the previous commit for a
longer explanation of the issue.
Change repack_without_ref_fn() to silently ignore dangling packed
references.
Signed-off-by: Michael Haggerty
---
refs.c
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
Signed-off-by: Michael Haggerty
---
refs.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/refs.c b/refs.c
index de5dc7d..cf017a5 100644
--- a/refs.c
+++ b/refs.c
@@ -1282,10 +1282,9 @@ int peel_ref(const char *refname, unsigned char *sha1)
return -1;
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
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
The highlight of this patch series are that (1) peeled references are
not lost from the packed-refs file when a packed reference is deleted
and (2) there is more code sharing between the code used by "git
packed-refs" and the code used by repack_without_ref() for deleting a
packed reference. Along
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 {
+ /*
On 14 April 2013 22:34, Sebastian Schuberth wrote:
> Usually when I query a variable I'm not so much interested in whether it is
> at all (explicitly) set to some value or not, but what value is currently in
> use.
With your change in place, how do you know if the config item has been
explicitl
Hi,
I just realized Git merge still outputs
Automatic merge failed; fix conflicts and then commit the result.
although all of my conflicts were resolved using a previously recorded
resolution. I think it's OK for Git to not just do the merge commit in that
case to sort of force a review of
Hi,
I'm just wondering why it was decided to work like this. IMHO it's quite
inconvenient that git config outputs nothing for any unset (but known)
variable. Usually when I query a variable I'm not so much interested in
whether it is at all (explicitly) set to some value or not, but what
valu
Ilya Basin :
> IB> Hi esr.
> IB> In cvsps 3.10 the flag --norc was removed. It broke 'git cvsimport'.
> IB> Please give the option back and write something in the man page like:
> IB> This option has no effect; it is present for compatibility
>
> Looks like the tool is completely different. I
This allows a remote helper using the 'export' protocol to specify that
it supports signed tags, changing the handing from 'warn-strip' to
'verbatim'.
Signed-off-by: John Keeping
---
Documentation/gitremote-helpers.txt | 4
git-remote-testgit | 1 +
t/t5801-remote-helpers
1 - 100 of 109 matches
Mail list logo
