On Tue, Jun 23, 2015 at 4:47 AM, Jeff King wrote:
>
> One of the problems we've had with large-ref repos is that the reflog
> storage is quite inefficient.
Yup. We ran into this with Gerrit Code Review years ago. The
refs/changes/... namespace created by Gerrit Code Review is 1 ref per
snapshot p
Theodore Ts'o writes:
> The main issue is that non-expert users might not realize that they
> really need to run "git fsck" after a crash; otherwise, what might
> happen is that although git is only appending, that you might have
> some zero-length (or partially written) git object or pack files,
Jeff King writes:
> I had always assumed this was fine on ext4 with data=ordered (i.e.,
> either the rename and its pointed-to content will go through, or not; so
> you either get your update or the old state, but not a garbage or empty
> file). But it sounds from what Ted wrote in:
>
> http://
On Tue, Jun 23, 2015 at 9:50 AM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> - pos = cache_name_pos(name, strlen(name));
>> + pos = exists_in_cache(name, strlen(name));
>
> Something that is named as if it would return yes/no that returns a
> real value is not a very welcom
On Tue, Jun 23, 2015 at 02:57:23PM -0700, Stefan Beller wrote:
> Linus Torvalds started a discussion[1] if we want to play rather safe
> than use defaults which make sense only for the most power users of Git:
>
> > So git is "safe" in the sense that you won't really lose any data,
> > but you ma
Hi all,
"git name-rev" does not accept abbreviated SHAs if --stdin is used,
though it works when the SHA is given directly on the command line:
$ git version
git version 2.4.3
$ git name-rev --tags d73f544
d73f544 tags/v3.6.3~29
$ git name-rev --tags --stdin <<< d73f544
d7
On Wed, Jun 24, 2015 at 4:57 AM, Stefan Beller wrote:
> Linus Torvalds started a discussion[1] if we want to play rather safe
> than use defaults which make sense only for the most power users of Git:
>
>> So git is "safe" in the sense that you won't really lose any data,
>> but you may well be in
The main issue is that non-expert users might not realize that they
really need to run "git fsck" after a crash; otherwise, what might
happen is that although git is only appending, that you might have
some zero-length (or partially written) git object or pack files, and
while you might not notice
Stefan Beller writes:
> Linus Torvalds started a discussion[1] if we want to play rather safe
> than use defaults which make sense only for the most power users of Git:
>
>> So git is "safe" in the sense that you won't really lose any data,
>> but you may well be inconvenienced. The "fsync each
Linus Torvalds started a discussion[1] if we want to play rather safe
than use defaults which make sense only for the most power users of Git:
> So git is "safe" in the sense that you won't really lose any data,
> but you may well be inconvenienced. The "fsync each object" config
> option is ther
David Turner writes:
> On Tue, 2015-06-23 at 15:53 -0400, David Turner wrote:
>> > * Regarding MERGE_HEAD: you take the point of view that it must continue
>> > to be stored as a file. And yet it must also behave somewhat like a
>> > reference; for example, `git rev-parse MERGE_HEAD` works today.
On Tue, 2015-06-23 at 15:53 -0400, David Turner wrote:
> > * Regarding MERGE_HEAD: you take the point of view that it must continue
> > to be stored as a file. And yet it must also behave somewhat like a
> > reference; for example, `git rev-parse MERGE_HEAD` works today.
> > MERGE_HEAD is also used
On Tue, 2015-06-23 at 06:54 -0400, Jeff King wrote:
> + mkconfig 1 preciousObjects >.git/config &&
nit: I think it's better to use git config rather than manually writing
config files. git config is more future-proof if we up switching config
backends; it's also more composable with other con
On 06/23/2015 09:53 PM, David Turner wrote:
> On Tue, 2015-06-23 at 17:51 +0200, Michael Haggerty wrote:
> [...]
>> * I don't like the fact that you have replaced `struct ref_transaction
>> *` with `void *` in the public interface. On a practical level, I like
>> the bit of type-safety that comes w
Jeff King writes:
> This extension does not change git's behavior at all. It is useful only
> for testing format-1 compatibility.
> +
> +`preciousObjects`
> +~
> +
> +When the config key `extensions.preciousObjects` is set to `true`,
> +objects in the repository MUST NOT be dele
Matthieu Moy writes:
> Your git send-email does not seem to like PATCHes 08-10/10 ;-).
>
> Up to PATCH 07, the series looks good.
Yes, I get "Too many recipients" error... If I specify
--no-signoff-by-cc then this is also aborted but I get no error (at
least I've not seen it last time...). If I
Johannes Schindelin writes:
> Hi Junio,
>
> On 2015-06-23 00:49, Junio C Hamano wrote:
>
>> * js/rebase-i-clean-up-upon-continue-to-skip (2015-06-18) 3 commits
>> - rebase -i: do not leave a CHERRY_PICK_HEAD file behind
>> - SQUASH: test_must_fail is a shell function
>> - t3404: demonstrate CH
Junio C Hamano writes:
> Matthieu Moy writes:
>
> > Remi Galan Alfonso writes:
> >
> >> I think that the indentation on its own is enough to avoid confusion
> >>> test_rebase_end () {
> >>> test_when_finished "git checkout master &&
> >>> git branch -D $1 &&
> >>>
Remi Lespinet writes:
> Helped-by: Remi Lespinet
This is funny in a patch sent by the same Remi Lespinet ;-).
Anyway, the whole series looks good to me now (I finally got all up to
10/10).
Cheers,
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the li
Remove leading and trailing whitespaces in from field before
interepreting it to improve consistency with other options. The
split_addrs function already take care of trailing and leading
whitespaces for to, cc and bcc fields.
The from option now:
- has the same behavior when passing arguments l
Accept a list of emails separated by commas in flags --cc, --to and
--bcc. Multiple addresses can already be given by using these options
multiple times, but it is more convenient to allow cutting-and-pasting
a list of addresses from the header of an existing e-mail message,
which already lists th
Do not consider quote inside a recipient name as character when
they are not escaped. This interprets:
"Jane" "Doe"
as:
"Jane Doe"
instead of:
"Jane\" \"Doe"
Signed-off-by: Remi Lespinet
---
git-send-email.perl | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
Matthieu Moy writes:
> Remi Galan Alfonso writes:
>
>> I think that the indentation on its own is enough to avoid confusion
>>> test_rebase_end () {
>>> test_when_finished "git checkout master &&
>>> git branch -D $1 &&
>>> test_might_fail git rebase --abort" &&
>>>
Your git send-email does not seem to like PATCHes 08-10/10 ;-).
Up to PATCH 07, the series looks good.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Junio C Hamano writes:
> Galan Rémi writes:
>
>> +test_rebase_end () {
>> +test_when_finished "git checkout master &&
>> +git branch -D $1 &&
>
> Is this one guaranteed to succeed? Do we want to consider it a
> failure to remove "$1" (e.g. dropTest)?
>
> $ git branch -D no-such-bra
Matthieu Moy writes:
>> It is somewhat confusing to see v3 yesterday and then this v7 next
>> day. How did I miss v4 thru v6?
>
> Oops, I pattern-matched the wrong part when reading [PATCH v3 6/6].
> Indeed, this should have been numberred v4, I should have s/v6/v3/ in my
> sentence above.
OK.
Junio C Hamano writes:
> Galan Rémi writes:
>
> > I used:
> >read -r command sha1 rest < >$line
> >EOF
> > because
> >printf '%s' "$line" | read -r command sha1 rest
> > doesn't work (the 3 variables have no value as a result).
> > There might be a better way to do this, but
parse_address_line had not the same behavior whether the user had
Mail::Address or not. Teach parse_address_line to behave like
Mail::Address.
When the user input is correct, this implementation behaves
exactly like Mail::Address except when there are quotes
inside the name:
"Jane Do"e
In thi
Interpret aliases in:
- Header fields of patches generated by git format-patch
(using --to, --cc, --add-header for example) or
manually modified. Example of fields in header:
To: alias1
Cc: alias2
Cc: alias3
- Outputs of command scripts specified by --cc-cmd and
Simplify code by creating a function which transform a list of strings
containing email addresses (separated by commas, comporting aliases)
into a clean list of valid email addresses.
Signed-off-by: Remi Lespinet
---
git-send-email.perl | 22 --
1 file changed, 12 insertions(
Aliases were expanded before considering the From field of the
--compose option. This is inconsistent with other fields
(To, Cc, ...) which already support aliases.
Signed-off-by: Remi Lespinet
---
git-send-email.perl | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-se
Group expressions in a single if statement. This avoid checking
multiple time if the variable $sender is defined.
Signed-off-by: Remi Lespinet
---
git-send-email.perl | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index f61449d
Create a function which replaces Date, Message-Id and
X-Mailer lines generated by git-send-email by a specific string:
Date:.*$ -> Date: DATE-STRING
Message-Id:.*$ -> Message-Id: MESSAGE-ID-STRING
X-Mailer:.*$ -> X-Mailer: X-MAILER-STRING
Signed-off-by: Remi Lespinet
---
t/t9001-send-ema
Move the creation of the scripts used in to-cmd and cc-cmd tests
in a setup test to make them available for later tests.
Signed-off-by: Remi Lespinet
---
t/t9001-send-email.sh | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/t/t9001-send-email.sh b/t/t9001-send
> -Original Message-
> From: git-ow...@vger.kernel.org [mailto:git-ow...@vger.kernel.org] On
> Behalf Of David Turner
> Sent: June 23, 2015 4:22 PM
> To: Randall S. Becker
> Cc: 'Stefan Beller'; 'git mailing list'; 'ronnie sahlberg'
> Subject: Re: RFC/Pull Request: Refs db backend
>
> > Ju
Remi Galan Alfonso writes:
> Matthieu Moy writes:
>> Signed-off-by: Matthieu Moy
>> Signed-off-by: Matthieu Moy
>
> Sounds like you went all out with this patch.
Ah, the first line was in the original patch, and the second is added by
send-email -s ... Both me and myself agree that one of the
Remi Galan Alfonso writes:
> I think that the indentation on its own is enough to avoid confusion
>> test_rebase_end () {
>> test_when_finished "git checkout master &&
>> git branch -D $1 &&
>> test_might_fail git rebase --abort" &&
>> git checkout -b $1 master
> Just to beg a request: LMDB is not available on some MPP architectures to
> which git has been ported. If it comes up, I beg you not to add this as a
> dependency to base git components.
My changes make `configure` check for the presence of liblmdb. The LMDB
code is only built if liblmdb is pr
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> I fixed a few minor issues in v6. Patch between my version and v6 is
>> below. I also pushed my branch here:
>>
>> https://github.com/moy/git/tree/bisect-terms
>
> It is somewhat confusing to see v3 yesterday and then this v7 next
> day. How
Matthieu Moy writes:
> > We can redirect todo_output to a variable but I've not found better...
> > (Maybe someone has the solution here ?). Also there's no summary at
> > the end of the test (as with other perl tests).
>
> You can get the 1..44 at the end with
>
> printf "1..%d\n", Test::More->
> -Original Message-
> From: git-ow...@vger.kernel.org [mailto:git-ow...@vger.kernel.org] On
> Behalf Of David Turner
> Sent: June 23, 2015 4:05 PM
> To: Stefan Beller
> Cc: git mailing list; ronnie sahlberg
> Subject: Re: RFC/Pull Request: Refs db backend
>
> On Tue, 2015-06-23 at 10:16 -
Junio C Hamano writes:
> > Galan Rémi writes:
> >
> > > +test_rebase_end () {
> > > +test_when_finished "git checkout master &&
> > > +git branch -D $1 &&
> >
> > Is this one guaranteed to succeed? Do we want to consider it a
> > failure to remove "$1" (e.g. dropTest)?
> >
>
On Tue, 2015-06-23 at 10:16 -0700, Stefan Beller wrote:
> > The db backend code was added in the penultimate commit; the rest is
> > just code rearrangement and minor changes to make alternate backends
> > possible. There ended up being a fair amount of this
> > rearrangement, but the end result
On Tue, 2015-06-23 at 17:51 +0200, Michael Haggerty wrote:
> On 06/23/2015 02:50 AM, David Turner wrote:
> > 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 hav
Galan Rémi writes:
> I used:
>read -r command sha1 rest <$line
>EOF
> because
>printf '%s' "$line" | read -r command sha1 rest
> doesn't work (the 3 variables have no value as a result).
> There might be a better way to do this, but I don't have it right now.
while r
Hi,
I recently realized that I could use a "git status" syntax like this:
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
(use "git add ..." to update what will be committed)
(use "git checkout -- ..." to discard changes in working directory)
Galan Rémi writes:
> +test_rebase_end () {
> + test_when_finished "git checkout master &&
> + git branch -D $1 &&
Is this one guaranteed to succeed? Do we want to consider it a
failure to remove "$1" (e.g. dropTest)?
$ git branch -D no-such-branch ; echo $?
error: branch 'no-s
Matthieu Moy writes:
> Signed-off-by: Matthieu Moy
> Signed-off-by: Matthieu Moy
Sounds like you went all out with this patch.
Rémi
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel
On Tue, Jun 23, 2015 at 3:01 PM, Remi Galan Alfonso
wrote:
> Eric Sunshine writes:
>> > +test_rebase_end () {
>> > + test_when_finished "git checkout master &&
>> > + git branch -D $1 &&
>> > + test_might_fail git rebase --abort" &&
>> > + git checkout -b $1 master
>> > +}
Matthieu Moy writes:
> Remi Galan Alfonso writes:
>
> > Eric Sunshine writes:
> >> > +test_rebase_end () {
> >> > + test_when_finished "git checkout master &&
> >> > + git branch -D $1 &&
> >> > + test_might_fail git rebase --abort" &&
> >> > + git checkout -b $1 master
Remi Galan Alfonso writes:
> Eric Sunshine writes:
>> > +test_rebase_end () {
>> > + test_when_finished "git checkout master &&
>> > + git branch -D $1 &&
>> > + test_might_fail git rebase --abort" &&
>> > + git checkout -b $1 master
>> > +}
>>
>> The way this is indente
Matthieu Moy writes:
> I fixed a few minor issues in v6. Patch between my version and v6 is
> below. I also pushed my branch here:
>
> https://github.com/moy/git/tree/bisect-terms
It is somewhat confusing to see v3 yesterday and then this v7 next
day. How did I miss v4 thru v6?
> Not visible
Eric Sunshine writes:
> > +test_rebase_end () {
> > + test_when_finished "git checkout master &&
> > + git branch -D $1 &&
> > + test_might_fail git rebase --abort" &&
> > + git checkout -b $1 master
> > +}
>
> The way this is indented makes it difficult to see that lines
If neither git-submodule nor git-subtree is palatable to you, here are
a couple of alternatives you might try:
* https://github.com/ingydotnet/git-subrepo
* https://github.com/tdd/git-stree
On Tue, Jun 23, 2015 at 1:36 PM Stefan Beller wrote:
>
> On Tue, Jun 23, 2015 at 1:52 AM, Jean Audiber
Matthieu Moy writes:
>Subject: Re: [PATCH v7 5/5] bisect: allows any terms set by user
s/allows/allow/;
> +Alternative terms: use your own terms
> +
Lengths of underline and the text must match.
--
To unsubscribe from this list: send the line "unsubs
On Tue, 2015-06-23 at 17:23 +0700, Duy Nguyen wrote:
> On Tue, Jun 23, 2015 at 7:50 AM, David Turner
wrote:
> > To test this backend's correctness, I hacked test-lib.sh and
> > test-lib-functions.sh to run all tests under the refs backend.
>
> Now we have two. split-index also benefits from runni
On Mon, Jun 22, 2015 at 5:42 PM, Galan Rémi
wrote:
> 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
Eric Sunshine writes:
> On Tue, Jun 23, 2015 at 8:54 AM, Matthieu Moy wrote:
>> + strbuf_addstr(&bisect_refs_buf, "refs/bisect/");
>> + strbuf_addstr(&bisect_refs_buf, name_bad);
>
> A single strbuf_addf() rather than two strbuf_addstr()s?
>> + bisect_refs_str = strbuf_detach
On Tue, 2015-06-23 at 07:47 -0400, Jeff King wrote:
> On Mon, Jun 22, 2015 at 08:50:56PM -0400, David Turner wrote:
>
> > The db backend runs git for-each-ref about 30% faster than the files
> > backend with fully-packed refs on a repo with ~120k refs. It's also
> > about 4x faster than using ful
On Tue, Jun 23, 2015 at 8:54 AM, Matthieu Moy wrote:
> diff --git a/revision.c b/revision.c
> index 3ff8723..f22923f 100644
> --- a/revision.c
> +++ b/revision.c
> @@ -2076,14 +2079,32 @@ void parse_revision_opt(struct rev_info *revs, struct
> parse_opt_ctx_t *ctx,
> ctx->argc -= n;
> }
Michael Haggerty writes:
> On 06/22/2015 11:06 PM, Junio C Hamano wrote:
> ...
>> What I am wondering is if we could turn the safety logic that appear
>> here (i.e. no existing refs must be assumed by the set of updates,
>> etc.) into an optimization cue and implement this as a special case
>> h
Junio C Hamano writes:
>> I think I'm opening a can of worms with d95d728
>
> I cannot offhand convince myself that "apply" is the only casualty;
> assuming it is, I think a reasonable way forward is to keep d95d728
> and adjust "apply" to the new world order. Otherwise, i.e. if there
> are
On Tue, Jun 23, 2015 at 1:52 AM, Jean Audibert wrote:
> Hi,
>
> Sorry to bother you with this question but I can't find any "official" answer
> or "strong opinion" from Git community.
>
> In my company we recently started to use Git and we wonder how to share code
> and manage dependencies with
From: Antoine Delaite
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 cert
From: Antoine Delaite
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
Signed-off-by: Matthieu Moy
---
Documentation/git-bisect.t
From: Antoine Delaite
Signed-off-by: Antoine Delaite
Signed-off-by: Matthieu Moy
---
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/bis
From: Antoine Delaite
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
From: Antoine Delaite
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
Co-authored-by: Louis Stuber
Tweaked-by: Matthieu Moy
Signe
Hi,
I fixed a few minor issues in v6. Patch between my version and v6 is
below. I also pushed my branch here:
https://github.com/moy/git/tree/bisect-terms
Not visible in the patch below: I squashed PATCH 5 into PATCH 3 to
avoid the pattern "break stuff and then repair it".
The first two patch
On Mon, 2015-06-22 at 22:36 -0700, Junio C Hamano wrote:
> 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
Hi Junio,
On 2015-06-23 00:49, Junio C Hamano wrote:
> * js/rebase-i-clean-up-upon-continue-to-skip (2015-06-18) 3 commits
> - rebase -i: do not leave a CHERRY_PICK_HEAD file behind
> - SQUASH: test_must_fail is a shell function
> - t3404: demonstrate CHERRY_PICK_HEAD bug
>
> Abandoning an a
[+, FYI]
On Mon, Jun 22, 2015 at 5:50 PM, David Turner wrote:
> I've revived and modified Ronnie Sahlberg's work on the refs db
> backend.
Awesome!
>
> 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,
On 23/06, Víctor Martín Hernández wrote:
Hi all.
Today I've had an unexpected behaviour that I'm not sure if is a bug or
I'm not doing git best practices... (surely the latest...)
The sequence of actions is :
1. create a new subfolder of my local repository branch
2. cd to this new folder, and c
Nguyễn Thái Ngọc Duy writes:
> Since d95d728 (diff-lib.c: adjust position of i-t-a entries in diff -
> 2015-03-16), a normal "git diff" on i-t-a entries would produce a diff
> that _adds_ those files, not just adding content to existing and empty
> files like before.
>
> This is correct. Unfortu
On 06/23/2015 02:50 AM, David Turner wrote:
> 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 f
Hi all.
Today I've had an unexpected behaviour that I'm not sure if is a bug or
I'm not doing git best practices... (surely the latest...)
The sequence of actions is :
1. create a new subfolder of my local repository branch
2. cd to this new folder, and create a new file
3. execute git status from
On Tue, Jun 23, 2015 at 6:47 PM, Jeff King wrote:
> I was thinking of actually moving to a log-structured ref storage.
> Something like:
>
> - any ref write puts a line at the end of a single logfile that
> contains the ref name, along with the normal reflog data
>
> - the logfile is the s
Since d95d728 (diff-lib.c: adjust position of i-t-a entries in diff -
2015-03-16), a normal "git diff" on i-t-a entries would produce a diff
that _adds_ those files, not just adding content to existing and empty
files like before.
This is correct. Unfortunately, applying such a patch on the same
r
On Tue, Jun 23, 2015 at 06:14:22PM +0700, Duy Nguyen wrote:
> > + if (delete_redundant && repository_format_precious_objects)
> > + die("cannot repack in a precious-objects repo");
> > +
> > if (pack_kept_objects < 0)
> > pack_kept_objects = write_bitmap
On Mon, Jun 22, 2015 at 08:50:56PM -0400, David Turner wrote:
> The db backend runs git for-each-ref about 30% faster than the files
> backend with fully-packed refs on a repo with ~120k refs. It's also
> about 4x faster than using fully-unpacked refs. In addition, and
> perhaps more importantly
On Tue, Jun 23, 2015 at 5:54 PM, Jeff King wrote:
> diff --git a/builtin/prune.c b/builtin/prune.c
> index 0c73246..fc0c8e8 100644
> --- a/builtin/prune.c
> +++ b/builtin/prune.c
> @@ -218,6 +218,9 @@ int cmd_prune(int argc, const char **argv, const char
> *prefix)
> return 0;
>
On Tue, Jun 23, 2015 at 4:11 AM, Eric Sunshine wrote:
>
> According to the documentation you added to the OPTIONS section, the
> object following --merged and --no-merged is optional. Therefore,
> shouldn't this be s//[]/ ?
>
> Also, in the OPTIONS section, you spelled it "commit" rather than "obj
If this extension is used in a repository, then no
operations should run which may drop objects from the object
storage. This can be useful if you are sharing that storage
with other repositories whose refs you cannot see.
For instance, if you do:
$ git clone -s parent child
$ git -C parent c
Normally we try to avoid bumps of the whole-repository
core.repositoryformatversion field. However, it is
unavoidable if we want to safely change certain aspects of
git in a backwards-incompatible way (e.g., modifying the set
of ref tips that we must traverse to generate a list of
unreachable, safe
On Tue, Jun 23, 2015 at 4:08 AM, Eric Sunshine wrote:
> 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 sa
We've managed to avoid bumping core.repositoryformatversion for the past
10 years, which is great. But I think there are some looming features
that are going to need it. The most obvious one is changing the ref
storage, where we need some way to tell older gits "no, please don't
think that taking '
On Tue, Jun 23, 2015 at 4:06 AM, Eric Sunshine wrote:
>
> s/a one/one/
>
Noted! Thanks
--
Regards,
Karthik Nayak
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.
On Tue, Jun 23, 2015 at 12:36 PM, Junio C Hamano wrote:
> "If there is interest"? Shut up and take my money ;-)
Yeah. This may be the next big thing since pack bitmap. It's even
better if it enters 'master' hand in hand with pack protocol v2, but I
think v2 needs more time.
On Tue, Jun 23, 2015
Hi Dennis,
On 2015-06-23 11:43, Dennis Kaarsemaker wrote:
> Since last friday between 10:39 and 10:50 UTC, mails to git@vger
> suddenly get an incomplete footer added.
>
> Instead of the normal footer:
>
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message
Since last friday between 10:39 and 10:50 UTC, mails to git@vger
suddenly get an incomplete footer added.
Instead of the normal footer:
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.o
Hi,
Sorry to bother you with this question but I can't find any "official" answer
or "strong opinion" from Git community.
In my company we recently started to use Git and we wonder how to share code
and manage dependencies with Git?
Use case: in project P we need to include lib-a and lib-b (lib
On 06/22/2015 11:06 PM, Junio C Hamano wrote:
> 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 l
92 matches
Mail list logo
