David Turner writes:
> I've revived and modified Ronnie Sahlberg's work on the refs db
> backend.
>
> The work is on top of be3c13e5564, Junio's "First batch for 2.5 cycle".
> I recognize that there have been changes to the refs code since then,
> and that there are some further changes in-flig
On Tue, Jun 23, 2015 at 1:31 AM, Greg Ledger wrote:
> after adding git config ‹global user.name Greg Ledger and git config
> ‹global user.email gled...@glcdelivers.com, when I run:
> source ~/.gitconfig
The ~/.gitconfig file is not a shell script. You should not source it.
It is a text file that
I've revived and modified Ronnie Sahlberg's work on the refs db
backend.
The work is on top of be3c13e5564, Junio's "First batch for 2.5 cycle".
I recognize that there have been changes to the refs code since then,
and that there are some further changes in-flight from e.g. Michael
Haggerty. If
after adding git config ‹global user.name Greg Ledger and git config
‹global user.email gled...@glcdelivers.com, when I run:
source ~/.gitconfig I get
-bash: [user]: command not found
-bash: name: command not found
-bash: email: command not found
-bash: [color]: command not found
-bash: ui: comman
On Mon, Jun 22, 2015 at 02:50:10PM -0700, Junio C Hamano wrote:
> > We may want to take patch 1 separately for the maint-track, as it is
> > really a bug-fix (albeit one that I do not think actually affects anyone
> > in practice right now).
>
> Hmph, add_unseen_recent_objects_to_traversal() is t
On Mon, Jun 22, 2015 at 11:03:50PM +0100, Charles Bailey wrote:
> > The patch below does the sort/de-dup. I'd probably just squash it into
> > patch 7, though.
>
> Woah, 8 out of 7! Did you get a chance to measure the performance hit of
> the sort? If not, I may test it out when I next get the ch
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
Some of the topics in flight have overlaps with each other and have
been excluded from 'pu'; most notably, I think the remainder of
bc/object-id
On Mon, Jun 22, 2015 at 9:53 AM, Charles Bailey wrote:
> contrib/subtree: Use tabs consitently for indentation in tests
s/consitently/consistently/
> Although subtrees tests uses more spaces for indentation than tabs,
> there are still quite a lot of lines indented with tabs. As tabs conform
> w
> On 22 Jun 2015, at 23:09, Junio C Hamano wrote:
>
> Charles Bailey writes:
>>
>> - marginally improved the opterror message on failed parses
>
> I'd queue with "s/a integer/a non-negative integer/".
Ha! That's what I had before I submitted, but then the source line got quite
long (which c
On Sun, Jun 21, 2015 at 4:48 PM, Karthik Nayak wrote:
> Add the '--merged' and '--no-merged' options provided by 'ref-filter'.
> The '--merged' option lets the user to only list refs merged into the
> named commit. The '--no-merged' option lets the user to only list refs
> not merged into the name
On Sun, Jun 21, 2015 at 4:48 PM, Karthik Nayak wrote:
> Add the '--points-at' option provided by 'ref-filter'. The
> option lets the user to pick only refs which point to a particular
> commit.
>
> Add documentation and tests for the same.
>
> Based-on-patch-by: Jeff King
> Mentored-by: Christian
On Sun, Jun 21, 2015 at 4:48 PM, Karthik Nayak wrote:
> In 'tag -l' we have '--points-at' option which lets users
> list only tags which point to a particular commit. Implement
> this option in 'ref-filter.{c,h}' so that other commands can
> benefit from this.
>
> This is duplicated from tag.c, we
Charles Bailey writes:
> This is a re-roll of the first two patches in my previous series which used to
> include "filter-objects" which is now a separate topic.
>
> [PATCH 1/2] Correct test-parse-options to handle negative ints
>
> The first one has changed only in that I've moved the additional
Charles Bailey writes:
> From: Charles Bailey
>
> The unsigned long option parsing (including 'k'/'m'/'g' suffix parsing)
> is more widely applicable. Add support for OPT_MAGNITUDE to
> parse-options.h and change pack-objects.c use this support.
>
> The error behavior on parse errors follows tha
On Mon, Jun 22, 2015 at 07:06:32AM -0400, Jeff King wrote:
> On Mon, Jun 22, 2015 at 06:33:21AM -0400, Jeff King wrote:
>
> > By the way, in addition to not showing objects in order,
> > list-all-objects (and my cat-file option) may show duplicates. Do we
> > want to "sort -u" for the user? It mig
Charles Bailey writes:
> On Sun, Jun 21, 2015 at 07:25:44PM +0100, Charles Bailey wrote:
>> From: Charles Bailey
>>
>> diff --git a/parse-options.c b/parse-options.c
>> index 80106c0..101b649 100644
>> --- a/parse-options.c
>> +++ b/parse-options.c
>> @@ -180,6 +180,23 @@ static int get_value(s
Jeff King writes:
> On Mon, Jun 22, 2015 at 04:38:22AM -0400, Jeff King wrote:
>
>> > + prepare_packed_git();
>> > + for (p = packed_git; p; p = p->next) {
>> > + open_pack_index(p);
>> > + }
>>
>> Yikes. The fact that you need to do this means that
>> for_each_packed_object is buggy
On Mon, Jun 22, 2015 at 06:33:21AM -0400, Jeff King wrote:
> On Mon, Jun 22, 2015 at 04:38:22AM -0400, Jeff King wrote:
>
> > > + prepare_packed_git();
> > > + for (p = packed_git; p; p = p->next) {
> > > + open_pack_index(p);
> > > + }
> >
> > Yikes. The fact that you need to do this mea
Check before the start of the rebasing if the commands exists, and for
the commands expecting a SHA-1, check if the SHA-1 is present and
corresponds to a commit. In case of error, print the error, stop git
rebase and prompt the user to fix with 'git rebase --edit-todo' or to
abort.
This allows to
Instead of removing a line to remove the commit, you can use the
command "drop" (just like "pick" or "edit"). It has the same effect as
deleting the line (removing the commit) except that you keep a visual
trace of your actions, allowing a better control and reducing the
possibility of removing a c
Check if commits were removed (i.e. a line was deleted) and print
warnings or stop git rebase depending on the value of the
configuration variable rebase.missingCommitsCheck.
This patch gives the user the possibility to avoid silent loss of
information (losing a commit through deleting the line in
Hi Junio,
On 2015-06-22 20:04, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
>> +git --git-dir=dst/.git branch -D bogus &&
>> +git --git-dir=dst/.git config --add \
>> +receive.fsck.missingEmail ignore &&
>> +git --git-dir=dst/.git config --add \
>> +
Michael Haggerty writes:
> The ref_transaction_update() family of functions use the following
> convention for their old_sha1 parameters:
>
> * old_sha1 == NULL: Don't check the old value at all.
> * is_null_sha1(old_sha1): Ensure that the reference didn't exist
> before the transaction.
> * ot
Hi Junio,
On 2015-06-22 20:02, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
>> Changes since v6:
>>
>> - camelCased message IDs
>>
>> - multiple author checking now as suggested by Junio
>>
>> - renamed `--quick` to `--connectivity-only`, better commit message
>>
>> - `fsck.skipList` is
Michael Haggerty writes:
> Error out if the ref_transaction includes more than one update for any
> refname.
>
> Signed-off-by: Michael Haggerty
> ---
> refs.c | 11 +++
> 1 file changed, 11 insertions(+)
This somehow feels like "ehh, I now know better and this function
should have bee
Hi Junio,
On 2015-06-22 19:37, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
>> diff --git a/fsck.c b/fsck.c
>> index 1a3f7ce..e81a342 100644
>> --- a/fsck.c
>> +++ b/fsck.c
>> @@ -64,30 +64,29 @@ enum fsck_msg_id {
>> #undef MSG_ID
>>
>> #define STR(x) #x
>> -#define MSG_ID(id, msg_ty
Introduction of the git bisect terms function.
The user can set its own terms.
It will work exactly like before. The terms must be set
before the start.
Signed-off-by: Antoine Delaite
Signed-off-by: Louis Stuber
---
Documentation/git-bisect.txt | 19
git-bisect.sh
From: Louis Stuber
Calling git rev-list --bisect when an old/new mode bisection was started
shows the help notice. This has been fixed by reading BISECT_TERMS in
revision.c to find the correct bisect refs path (which was always
refs/bisect/bad (or good) before and can be refs/bisect/new (old) now
When not looking for a regression during a bisect but for a fix or a
change in another given property, it can be confusing to use 'good'
and 'bad'.
This patch introduce `git bisect new` and `git bisect old` as an
alternative to 'bad' and good': the commits which have a certain
property must be mar
We create a file BISECT_TERMS in the repository .git to be read during a
bisection. The fonctions to be changed if we add new terms are quite
few.
In git-bisect.sh :
check_and_set_terms
bisect_voc
Signed-off-by: Antoine Delaite
Signed-off-by: Louis Stuber
Signed-off-by: Valentin
To add new tags like old/new and have keywords less confusing, the
first step is to avoid hardcoding the keywords.
The default mode is still bad/good.
Signed-off-by: Antoine Delaite
Signed-off-by: Louis Stuber
Signed-off-by: Valentin Duperray
Signed-off-by: Franck Jonas
Signed-off-by: Lucien
Signed-off-by: Antoine Delaite
---
bisect.c|2 +-
t/t6030-bisect-porcelain.sh |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/bisect.c b/bisect.c
index 03d5cd9..5b8357d 100644
--- a/bisect.c
+++ b/bisect.c
@@ -743,7 +743,7 @@ static void handle_ba
Junio C Hamano writes:
>> I have a slight preference for keeping the pairs not squashed. This way,
>> we have a clear separation "write reusable library code" / "use it". But
>> I'm fine with squashing if others prefer.
>
> As I cannot firmly say that "copy & paste first and then later
> clean-up
Jeff King writes:
> ...
> So my conclusions are:
>
> 1. Yes, the pipe/parsing overhead of a separate processor really is
> measurable. That's hidden in the wall-clock time if you have
> multiple cores, but you may care more about CPU time. I still think
> the flexibility is worth
On Tue, Jun 23, 2015 at 12:54 AM, Junio C Hamano wrote:
> Matthieu Moy writes:
>
>> Karthik Nayak writes:
>>
>>> On Mon, Jun 22, 2015 at 6:15 AM, Junio C Hamano wrote:
3 & 4 as a single patch may make more sense, if we were to tolerate the
"let's copy & paste first and then later rem
Matthieu Moy writes:
> Karthik Nayak writes:
>
>> On Mon, Jun 22, 2015 at 6:15 AM, Junio C Hamano wrote:
>>> 3 & 4 as a single patch may make more sense, if we were to tolerate the
>>> "let's copy & paste first and then later remove the duplicate" as a way to
>>> postpone touching "tag.c" side
Karthik Nayak writes:
> On Mon, Jun 22, 2015 at 6:15 AM, Junio C Hamano wrote:
>> 3 & 4 as a single patch may make more sense, if we were to tolerate the
>> "let's copy & paste first and then later remove the duplicate" as a way to
>> postpone touching "tag.c" side in order to first concentrate
On Mon, Jun 22, 2015 at 6:15 AM, Junio C Hamano wrote:
> 3 & 4 as a single patch may make more sense, if we were to tolerate the
> "let's copy & paste first and then later remove the duplicate" as a way to
> postpone touching "tag.c" side in order to first concentrate on for-each-ref.
>
> I have
On Mon, Jun 22, 2015 at 6:25 AM, Junio C Hamano wrote:
>
> Why SHOUT here?
>
Just used to typing "macros" in caps. Will change!
>> This is copied from 'builtin/branch.c' which will eventually be removed
>> when we port 'branch.c' to use ref-filter APIs.
>
> Hmph. I somehow thought Matthieu's ins
Johannes Schindelin writes:
> + git --git-dir=dst/.git branch -D bogus &&
> + git --git-dir=dst/.git config --add \
> + receive.fsck.missingEmail ignore &&
> + git --git-dir=dst/.git config --add \
> + receive.fsck.badDate warn &&
Funny double-SP (will local
Johannes Schindelin writes:
> Changes since v6:
>
> - camelCased message IDs
>
> - multiple author checking now as suggested by Junio
>
> - renamed `--quick` to `--connectivity-only`, better commit message
>
> - `fsck.skipList` is now handled correctly (and not mistaken for a message
> type se
Johannes Schindelin writes:
> diff --git a/fsck.c b/fsck.c
> index 1a3f7ce..e81a342 100644
> --- a/fsck.c
> +++ b/fsck.c
> @@ -64,30 +64,29 @@ enum fsck_msg_id {
> #undef MSG_ID
>
> #define STR(x) #x
> -#define MSG_ID(id, msg_type) { STR(id), FSCK_##msg_type },
> +#define MSG_ID(id, msg_type)
Duy Nguyen writes:
> On Mon, Jun 22, 2015 at 9:29 PM, Patrick Higgins wrote:
>> I like to use git to remove trailing whitespace from my files. I use
>> the following ~/.gitconfig to make this convenient:
>>
>> [alias]
>> wsadd = "!sh -c 'git diff -- \"$@\" | git apply --cached
>> --white
On Mon, Jun 22, 2015 at 9:57 PM, Junio C Hamano wrote:
> On Mon, Jun 22, 2015 at 8:38 AM, Karthik Nayak wrote:
>> On Mon, Jun 22, 2015 at 6:34 AM, Junio C Hamano wrote:
>>> On Sun, Jun 21, 2015 at 1:48 PM, Karthik Nayak
>>> wrote:
Rename parse_opt_with_commit() to parse_opt_commit_object_
On Mon, Jun 22, 2015 at 8:38 AM, Karthik Nayak wrote:
> On Mon, Jun 22, 2015 at 6:34 AM, Junio C Hamano wrote:
>> On Sun, Jun 21, 2015 at 1:48 PM, Karthik Nayak wrote:
>>> Rename parse_opt_with_commit() to parse_opt_commit_object_name()
>>> to show that it can be used to obtain a list of commits
Matthieu Moy writes:
> Junio C Hamano writes:
>
>>> This is copied from 'builtin/branch.c' which will eventually be removed
>>> when we port 'branch.c' to use ref-filter APIs.
>>
>> Hmph. I somehow thought Matthieu's instruction was to finish tag.c
>> side first
>
> I would call in "advice" rath
Le 22/06/2015 17:04, Charles Bailey a écrit :
> Note that these aren't "decomposed" (in the unicode decomposition
> sense) but are merely octal escaped representations of the utf-8
> encoded file names.
Thanks, I had read that term in similar context (German umlaut) and
thought it was correctly de
Torsten Bögershausen writes:
> eol=lf or eol=crlf are the only useful settings.
> Everything else is ignored because it does not make sense.
>
> See convert.c:
> static enum eol git_path_check_eol()
That makes me wonder...
The original reasoning behind the current behaviour that we ignore
unkno
On 22/06, Jamie Archibald wrote:
fatal: unable to access
'http://http://path/to/submodule/MySubmodule.git/': The requested URL
returned error: 502
Did you copy this error verbatim?
--
Sincerely,
Johannes Löthberg
PGP Key ID: 0x50FB9B273A9D0BB5
https://theos.kyriasis.com/~kyrias/
signatur
On Mon, Jun 22, 2015 at 6:34 AM, Junio C Hamano wrote:
> On Sun, Jun 21, 2015 at 1:48 PM, Karthik Nayak wrote:
>> Rename parse_opt_with_commit() to parse_opt_commit_object_name()
>> to show that it can be used to obtain a list of commits and is
>> not constricted to usage of '--contains' option.
An fsck issue in a legacy repository might be so common that one would
like not to bother the user with mentioning it at all. With this change,
that is possible by setting the respective message type to "ignore".
This change "abuses" the missingEmail=warn test to verify that "ignore"
is also accep
The 'invalid tag name' and 'missing tagger entry' warnings can now be
upgraded to errors by specifying `invalidTagName` and
`missingTaggerEntry` in the receive.fsck. config setting.
Incidentally, the missing tagger warning is now really shown as a warning
(as opposed to being reported with the "er
Some kinds of errors are intrinsically unrecoverable (e.g. errors while
uncompressing objects). It does not make sense to allow demoting them to
mere warnings.
Signed-off-by: Johannes Schindelin
---
fsck.c | 13 +++--
t/t5504-fetch-receive-strict.sh | 11
Some legacy code has objects with non-fatal fsck issues; To enable the
user to ignore those issues, let's print out the ID (e.g. when
encountering "missingEmail", the user might want to call `git config
--add receive.fsck.missingEmail=warn`).
Signed-off-by: Johannes Schindelin
---
fsck.c
Signed-off-by: Johannes Schindelin
---
Documentation/config.txt | 14 ++
1 file changed, 14 insertions(+)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 3e37b93..4e5fbea 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -2205,6 +2205,20 @
We already have support in `git receive-pack` to deal with some legacy
repositories which have non-fatal issues.
Let's make `git fsck` itself useful with such repositories, too, by
allowing users to ignore known issues, or at least demote those issues
to mere warnings.
Example: `git -c fsck.missi
When fsck_tag() identifies a problem with the commit, it should try
to make it possible to continue checking the commit object, in case the
user wants to demote the detected errors to mere warnings.
Just like fsck_commit(), there are certain problems that could hide other
issues with the same tag
Signed-off-by: Johannes Schindelin
---
t/t5504-fetch-receive-strict.sh | 21 +
1 file changed, 21 insertions(+)
diff --git a/t/t5504-fetch-receive-strict.sh b/t/t5504-fetch-receive-strict.sh
index 69ee13c..36024fc 100755
--- a/t/t5504-fetch-receive-strict.sh
+++ b/t/t5504-fet
When fsck_commit() identifies a problem with the commit, it should try
to make it possible to continue checking the commit object, in case the
user wants to demote the detected errors to mere warnings.
Note that some problems are too problematic to simply ignore. For
example, when the header lines
When fsck_ident() identifies a problem with the ident, it should still
advance the pointer to the next line so that fsck can continue in the
case of a mere warning.
Signed-off-by: Johannes Schindelin
---
fsck.c | 49 +++--
1 file changed, 27 insertions
Identical to support in `git receive-pack for the config option
`receive.fsck.skiplist`, we now support ignoring given objects in
`git fsck` via `fsck.skiplist` altogether.
This is extremely handy in case of legacy repositories where it would
cause more pain to change incorrect objects than to liv
This option avoids unpacking each and all blob objects, and just
verifies the connectivity. In particular with large repositories, this
speeds up the operation, at the expense of missing corrupt blobs,
ignoring unreachable objects and other fsck issues, if any.
Signed-off-by: Johannes Schindelin
The optional new config option `receive.fsck.skipList` specifies the path
to a file listing the names, i.e. SHA-1s, one per line, of objects that
are to be ignored by `git receive-pack` when `receive.fsckObjects = true`.
This is extremely handy in case of legacy repositories where it would
cause m
This problem has been detected in the wild, and is the primary reason
to introduce an option to demote certain fsck errors to warnings. Let's
offer to ignore this particular problem specifically.
Technically, we could handle such repositories by setting
receive.fsck. to missingCommitter=warn, but
Instead of specifying whether a message by the fsck machinery constitutes
an error or a warning, let's specify an identifier relating to the
concrete problem that was encountered. This is necessary for upcoming
support to be able to demote certain errors to warnings.
In the process, simplify the r
At the moment, the git-fsck's integrity checks are targeted toward the
end user, i.e. the error messages are really just messages, intended for
human consumption.
Under certain circumstances, some of those errors should be allowed to
be turned into mere warnings, though, because the cost of fixing
There are legacy repositories out there whose older commits and tags
have issues that prevent pushing them when 'receive.fsckObjects' is set.
One real-life example is a commit object that has been hand-crafted to
list two authors.
Often, it is not possible to fix those issues without disrupting th
For example, missing emails in commit and tag objects can be demoted to
mere warnings with
git config receive.fsck.missingemail=warn
The value is actually a comma-separated list.
In case that the same key is listed in multiple receive.fsck.
lines in the config, the latter configuration w
Just like the diff machinery, we are about to introduce more settings,
therefore it makes sense to carry them around as a (pointer to a) struct
containing all of them.
Signed-off-by: Johannes Schindelin
---
builtin/fsck.c | 20 +--
builtin/index-pack.c | 9 +--
builtin/unpac
These functions will be used in the next commits to allow the user to
ask fsck to handle specific problems differently, e.g. demoting certain
errors to warnings. The upcoming `fsck_set_msg_types()` function has to
handle partial strings because we would like to be able to parse, say,
'missingemail=
Hi Junio,
On 2015-06-19 21:26, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
>> +static inline int substrcmp(const char *string, int len, const char *match)
>> +{
>> +int match_len = strlen(match);
>> +if (match_len != len)
>> +return -1;
>> +return memcmp(string,
On Mon, Jun 22, 2015 at 6:30 AM, Junio C Hamano wrote:
> On Sun, Jun 21, 2015 at 1:48 PM, Karthik Nayak wrote:
>> +static void do_merge_filter(struct ref_filter_cbdata *ref_cbdata)
>> +{
>> + struct rev_info revs;
>> + int i, old_nr;
>> + struct ref_filter *filter = ref_cbdata->
On Mon, Jun 22, 2015 at 03:17:40PM +0200, Bastien Traverse wrote:
> test case:
> $ mkdir accent-test && cd !$
> $ git init
> $ touch rêve réunion
> $ git status
> On branch master
>
> Initial commit
>
> Untracked files:
> (use "git add ..." to include in what will be committed)
>
> "r\30
>
> Just FYI, you can "git format-patch -11 my-work~8" or something like that
> and get 01/11 to 11/11 even if you have more commits that are not yet ready
> near the tip.
I usually do a `git format-patch a..b` but I missed out the b it seems ;-)
Thanks!
--
Regards,
Karthik Nayak
--
To unsubscr
I am behind a proxy at work and I've setup a git repo with a submodule.
Here are the commands I'm executing.
$ mkdir MyProject
$ cd MyProject
$ git init
$ git remote add origin http://path/to/repo/MyProject.git
$ git config —add remote.origin.proxy ""
$ git pull origin master
MyProject has a
On Mon, Jun 22, 2015 at 9:29 PM, Patrick Higgins wrote:
> I like to use git to remove trailing whitespace from my files. I use
> the following ~/.gitconfig to make this convenient:
>
> [alias]
> wsadd = "!sh -c 'git diff -- \"$@\" | git apply --cached
> --whitespace=fix;\
>
https://github.com/git-for-windows/git/issues/218#issuecomment-114085764
--
To unsubscribe from this list: send the line "unsubscribe git" in
I like to use git to remove trailing whitespace from my files. I use
the following ~/.gitconfig to make this convenient:
[alias]
wsadd = "!sh -c 'git diff -- \"$@\" | git apply --cached
--whitespace=fix;\
git checkout -- ${1-.} \"$@\"' -"
The wsadd alias doesn't work with
Signed-off-by: Michael Haggerty
---
builtin/remote.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/builtin/remote.c b/builtin/remote.c
index f4a6ec9..53b8e13 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -756,8 +756,7 @@ static int remove_branches(struct string_l
"git clone" uses shortcuts when creating the initial set of
references:
* It writes them directly to packed-refs.
* It doesn't lock the individual references (though it does lock the
packed-refs file).
* It doesn't check for refname conflicts between two new references or
between one new ref
It is no longer called from outside of the refs module. Also move its
docstring and change it to imperative voice.
Signed-off-by: Michael Haggerty
---
refs.c | 9 -
refs.h | 11 ---
2 files changed, 8 insertions(+), 12 deletions(-)
diff --git a/refs.c b/refs.c
index 19afc4d..b2
Restructure the code to avoid clearing oldsha1 when oldval is unset.
It's value is not needed in that case, so this change makes it more
obvious that its initialization is consistent with its later use.
Signed-off-by: Michael Haggerty
---
builtin/update-ref.c | 13 ++---
1 file changed,
Make it clear that this function does not overwrite its first
argument.
Signed-off-by: Michael Haggerty
---
builtin/branch.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index b42e5b6..47e3eb9 100644
--- a/builtin/branch.c
+++ b/builtin/
In initial_ref_transaction_commit(), check for D/F conflicts (i.e.,
the type of conflict that exists between "refs/foo" and
"refs/foo/bar") among the references being created and between the
references being created and any hypothetical existing references.
Ideally, there shouldn't *be* any existi
delete_ref() uses a different convention for its old_sha1 parameter
than, say, ref_transaction_delete(): NULL_SHA1 means not to check the
old value. Make this fact a little bit clearer in the code by handling
it in explicit, commented code rather than burying it in a conditional
expression.
Signed
This is v3 of the series. I think I have addressed all of the feedback
from v1 [1] and v2 [2]. Thanks to Stefan, Junio, and Peff for their
feedback about v2.
There are three significant changes since v2:
* Add a patch
delete_refs(): bail early if the packed-refs file cannot be rewritten
The old version just looped over the references to delete, calling
delete_ref() on each one. But that has quadratic behavior, because
each call to delete_ref() might have to rewrite the packed-refs file.
This can be very expensive in a repository with a large number of
references. In some (admitted
This slightly changes how errors are reported. The old and new code
both report errors that come from repack_without_refs() the same way.
But if an error occurs within delete_ref(), the old version only
emitted an error within delete_ref() without further comment. The new
version (in delete_refs())
If we are deleting the reference, then we don't need to read the
reference's old value. It doesn't provide any race safety, because the
value read just before the delete is no "better" than the value that
would be read under lock during the delete. And even if the reference
previously didn't exist,
Error out if the ref_transaction includes more than one update for any
refname.
Signed-off-by: Michael Haggerty
---
refs.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/refs.c b/refs.c
index 31661c7..53d9e45 100644
--- a/refs.c
+++ b/refs.c
@@ -4087,12 +4087,22 @@ int initial_
Some functions from the refs module were still declared in cache.h.
Move them to refs.h.
Signed-off-by: Michael Haggerty
---
archive.c | 1 +
builtin/blame.c | 1 +
builtin/fast-export.c | 1 +
builtin/fmt-merge-msg.c | 1 +
builtin/init-db.c | 1 +
builti
The ref_transaction_update() family of functions use the following
convention for their old_sha1 parameters:
* old_sha1 == NULL: Don't check the old value at all.
* is_null_sha1(old_sha1): Ensure that the reference didn't exist
before the transaction.
* otherwise: Ensure that the reference had t
Change the error message from
Could not remove branch %s
to
could not remove reference %s
First of all, the old error message referred to "branch
refs/remotes/origin/foo", which was awkward even for the existing
caller. Normally we would refer to a reference like that as either
"remote-
Signed-off-by: Michael Haggerty
---
refs.h | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/refs.h b/refs.h
index b22e308..c9596ea 100644
--- a/refs.h
+++ b/refs.h
@@ -62,7 +62,7 @@ extern int read_ref_full(const char *refname, int
resolve_flags,
If we fail to delete the doomed references from the packed-refs file,
then it is unsafe to delete their loose references, because doing so
might expose a value from the packed-refs file that is obsolete and
perhaps even points at an object that has been garbage collected.
So if repack_without_refs
The following functions are no longer used from outside the refs
module:
* lock_packed_refs()
* add_packed_ref()
* commit_packed_refs()
* rollback_packed_refs()
So make these functions private.
This is an important step, because it means that nobody outside of the
refs module needs to know the d
Move the function remove_branches() from builtin/remote.c to refs.c,
rename it to delete_refs(), and make it public.
Signed-off-by: Michael Haggerty
---
builtin/remote.c | 21 +
refs.c | 19 +++
refs.h | 7 +++
3 files changed, 27 inse
Also
* Add a docstring
* Rename the second parameter to "old_sha1", to be consistent with the
convention used elsewhere in the refs module
Signed-off-by: Michael Haggerty
---
cache.h | 2 --
refs.c | 5 +++--
refs.h | 10 ++
3 files changed, 13 insertions(+), 4 deletions(-)
diff
From: Charles Bailey
There's no need to switch branches to parse another branch's ancestry.
Signed-off-by: Charles Bailey
---
contrib/subtree/t/t7900-subtree.sh | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/contrib/subtree/t/t7900-subtree.sh
b/contrib/subtree/t/t7900-
From: Charles Bailey
Although subtrees tests uses more spaces for indentation than tabs,
there are still quite a lot of lines indented with tabs. As tabs conform
with Git coding guidelines resolve the inconsistency in favour of tabs.
Signed-off-by: Charles Bailey
---
contrib/subtree/t/t7900-su
1 - 100 of 123 matches
Mail list logo
