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 further
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
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
On Tue, Jun 23, 2015 at 6:47 PM, Jeff King p...@peff.net 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
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
Michael Haggerty mhag...@alum.mit.edu 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
Nguyễn Thái Ngọc Duy pclo...@gmail.com 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
On Tue, Jun 23, 2015 at 1:52 AM, Jean Audibert jaudib...@euronext.com 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
On Mon, 2015-06-22 at 22:36 -0700, Junio C Hamano wrote:
David Turner dtur...@twopensource.com 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
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
From: Antoine Delaite antoine.dela...@ensimag.grenoble-inp.fr
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 antoine.dela...@ensimag.grenoble-inp.fr
From: Antoine Delaite antoine.dela...@ensimag.grenoble-inp.fr
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 antoine.dela...@ensimag.grenoble-inp.fr
From: Antoine Delaite antoine.dela...@ensimag.grenoble-inp.fr
Signed-off-by: Antoine Delaite antoine.dela...@ensimag.grenoble-inp.fr
Signed-off-by: Matthieu Moy matthieu@imag.fr
---
bisect.c| 2 +-
t/t6030-bisect-porcelain.sh | 2 +-
2 files changed, 2 insertions(+), 2
From: Antoine Delaite antoine.dela...@ensimag.grenoble-inp.fr
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'
From: Antoine Delaite antoine.dela...@ensimag.grenoble-inp.fr
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
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
Junio C Hamano gits...@pobox.com 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
On Tue, Jun 23, 2015 at 8:54 AM, Matthieu Moy matthieu@imag.fr 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,
[+ronniesahlb...@gmail.com, FYI]
On Mon, Jun 22, 2015 at 5:50 PM, David Turner dtur...@twopensource.com 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
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
Eric Sunshine sunsh...@sunshineco.com writes:
On Tue, Jun 23, 2015 at 8:54 AM, Matthieu Moy matthieu@imag.fr 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?
+
On Mon, Jun 22, 2015 at 5:42 PM, Galan Rémi
remi.galan-alfo...@ensimag.grenoble-inp.fr 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
On Tue, 2015-06-23 at 17:23 +0700, Duy Nguyen wrote:
On Tue, Jun 23, 2015 at 7:50 AM, David Turner
dtur...@twopensource.com 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
Eric Sunshine sunsh...@sunshineco.com 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
Galan Rémi remi.galan-alfo...@ensimag.grenoble-inp.fr 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
Matthieu Moy matthieu@grenoble-inp.fr writes:
Remi Galan Alfonso remi.galan-alfo...@ensimag.grenoble-inp.fr writes:
Eric Sunshine sunsh...@sunshineco.com writes:
+test_rebase_end () {
+ test_when_finished git checkout master
+ git branch -D $1
+
Galan Rémi remi.galan-alfo...@ensimag.grenoble-inp.fr writes:
I used:
read -r command sha1 rest EOF
$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
Remi Galan Alfonso remi.galan-alfo...@ensimag.grenoble-inp.fr writes:
Eric Sunshine sunsh...@sunshineco.com writes:
+test_rebase_end () {
+ test_when_finished git checkout master
+ git branch -D $1
+ test_might_fail git rebase --abort
+ git checkout -b $1
Matthieu Moy matthieu@imag.fr writes:
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
Signed-off-by: Matthieu Moy matthieu@imag.fr
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
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 sbel...@google.com wrote:
On Tue, Jun 23, 2015 at 1:52
On Tue, Jun 23, 2015 at 3:01 PM, Remi Galan Alfonso
remi.galan-alfo...@ensimag.grenoble-inp.fr wrote:
Eric Sunshine sunsh...@sunshineco.com writes:
+test_rebase_end () {
+ test_when_finished git checkout master
+ git branch -D $1
+ test_might_fail git rebase --abort
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 have been
Matthieu Moy matthieu@imag.fr 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:
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 file... to update what will be committed)
(use git checkout -- file... to discard changes in working directory)
Matthieu Moy matthieu@imag.fr 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
-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
Just to beg
Matthieu Moy matthieu@grenoble-inp.fr writes:
Remi Galan Alfonso remi.galan-alfo...@ensimag.grenoble-inp.fr 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
Junio C Hamano gits...@pobox.com writes:
Matthieu Moy matthieu@grenoble-inp.fr writes:
Remi Galan Alfonso remi.galan-alfo...@ensimag.grenoble-inp.fr writes:
I think that the indentation on its own is enough to avoid confusion
test_rebase_end () {
test_when_finished git
David Turner dtur...@twopensource.com 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
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 is
-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 -0700,
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 remi.lespi...@ensimag.grenoble-inp.fr
---
t/t9001-send-email.sh | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git
Group expressions in a single if statement. This avoid checking
multiple time if the variable $sender is defined.
Signed-off-by: Remi Lespinet remi.lespi...@ensimag.grenoble-inp.fr
---
git-send-email.perl | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
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 remi.lespi...@ensimag.grenoble-inp.fr
---
git-send-email.perl | 22
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 Doe
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
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
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 remi.lespi...@ensimag.grenoble-inp.fr
---
git-send-email.perl | 4 ++--
1 file changed, 2
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
Do not consider quote inside a recipient name as character when
they are not escaped. This interprets:
Jane Doe j...@example.com
as:
Jane Doe j...@example.com
instead of:
Jane\ \Doe j...@example.com
Signed-off-by: Remi Lespinet remi.lespi...@ensimag.grenoble-inp.fr
---
Johannes Schindelin johannes.schinde...@gmx.de 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:
Junio C Hamano gits...@pobox.com writes:
Matthieu Moy matthieu@imag.fr 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
Junio C Hamano gits...@pobox.com writes:
Galan Rémi remi.galan-alfo...@ensimag.grenoble-inp.fr writes:
I used:
read -r command sha1 rest EOF
$line
EOF
because
printf '%s' $line | read -r command sha1 rest
doesn't work (the 3 variables have no value as a result).
Junio C Hamano gits...@pobox.com writes:
Galan Rémi remi.galan-alfo...@ensimag.grenoble-inp.fr 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.
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
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
Matthieu Moy matthieu@grenoble-inp.fr 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
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 with the
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
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 there in
Junio C Hamano gits...@pobox.com writes:
Galan Rémi remi.galan-alfo...@ensimag.grenoble-inp.fr 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
Remi Lespinet remi.lespi...@ensimag.grenoble-inp.fr writes:
Helped-by: Remi Lespinet remi.lespi...@ensimag.grenoble-inp.fr
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
Jeff King p...@peff.net 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
Matthieu Moy matthieu@grenoble-inp.fr 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
Remi Galan Alfonso remi.galan-alfo...@ensimag.grenoble-inp.fr 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
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
Remi Galan Alfonso remi.galan-alfo...@ensimag.grenoble-inp.fr writes:
Matthieu Moy matthieu@imag.fr writes:
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
Signed-off-by: Matthieu Moy matthieu@imag.fr
Sounds like you went all out with this patch.
Ah, the first line was in
Matthieu Moy matthieu@grenoble-inp.fr 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
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 for
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 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_bitmaps;
I know
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
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 may well
Jeff King p...@peff.net 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:
Theodore Ts'o ty...@mit.edu 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
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
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 to
On 06/22/2015 11:06 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
Error out if the ref_transaction includes more than one update for any
refname.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
refs.c | 11 +++
1 file changed, 11 insertions(+)
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
On Tue, Jun 23, 2015 at 5:54 PM, Jeff King p...@peff.net 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
On Tue, Jun 23, 2015 at 12:36 PM, Junio C Hamano gits...@pobox.com 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
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:08 AM, Eric Sunshine sunsh...@sunshineco.com wrote:
On Sun, Jun 21, 2015 at 4:48 PM, Karthik Nayak karthik@gmail.com 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
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
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,
On Tue, Jun 23, 2015 at 4:06 AM, Eric Sunshine sunsh...@sunshineco.com 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
On Tue, Jun 23, 2015 at 4:11 AM, Eric Sunshine sunsh...@sunshineco.com 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/object/[object]/ ?
Also, in the OPTIONS section, you
On Tue, Jun 23, 2015 at 9:50 AM, Junio C Hamano gits...@pobox.com wrote:
Nguyễn Thái Ngọc Duy pclo...@gmail.com 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
On Wed, Jun 24, 2015 at 4:57 AM, Stefan Beller sbel...@google.com 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
Stefan Beller sbel...@google.com 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
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
91 matches
Mail list logo
