After the initial posting here:
http://news.gmane.org/group/gmane.comp.version-control.git/thread=233061
This is a repost plus the basic read side working, at least to validate
the write side and the pack format itself. And many many bug fixes.
This can also be fetched here:
Because the path dictionary table is located right after the name
dictionary table, we currently need to load the later to find the
former.
Signed-off-by: Nicolas Pitre n...@fluxnic.net
---
cache.h| 2 ++
packv4-parse.c | 36
2 files changed, 38
Signed-off-by: Nicolas Pitre n...@fluxnic.net
---
packv4-parse.c | 77 ++
1 file changed, 77 insertions(+)
diff --git a/packv4-parse.c b/packv4-parse.c
index 299fc48..26894bc 100644
--- a/packv4-parse.c
+++ b/packv4-parse.c
@@ -28,3 +28,80
There is only one type of delta with pack v4. The base reference
encoding already handles either an offset (via the pack index) or a
literal SHA1.
We assume in the literal SHA1 case that the object lives in the same
pack, just like with previous pack versions.
Signed-off-by: Nicolas Pitre
Signed-off-by: Nicolas Pitre n...@fluxnic.net
---
Makefile | 1 +
packv4-parse.c | 1 +
packv4-parse.h | 7 +++
sha1_file.c| 10 ++
4 files changed, 19 insertions(+)
create mode 100644 packv4-parse.h
diff --git a/Makefile b/Makefile
index ba6cafc..22fc276 100644
---
Because there is no delta object cache for tree objects yet, walking
tree entries may result in a lot of recursion.
Let's add --min-tree-copy=N where N is the minimum number of copied
entries in a single copy sequence allowed for encoding tree deltas.
The default is 1. Specifying 0 disables tree
For now we recreate the whole tree object in its canonical form.
Eventually, the core code should grow some ability to walk packv4 tree
entries directly which would be way more efficient. Not only would that
avoid double tree entry parsing, but the pack v4 encoding allows for
getting at child
... replacing the equivalent open coded loop.
Signed-off-by: Nicolas Pitre n...@fluxnic.net
---
sha1_file.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index a298933..67eb903 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1687,20
The name dictionary is loaded if not already done. We know it is
located right after the SHA1 table (20 bytes per object) which is
itself right after the 12-byte header.
Then the index is parsed from the input buffer and a pointer to the
corresponding entry is returned.
Signed-off-by: Nicolas
If the path or name index is zero, this means the entry data is to be
found inline rather than being located in the dictionary table. This is
there to allow easy completion of thin packs without having to add new
table entries which would have required a full rewrite of the pack data.
Signed-off-by: Nicolas Pitre n...@fluxnic.net
---
packv4-parse.c | 25 +
packv4-parse.h | 2 ++
sha1_file.c| 2 +-
3 files changed, 28 insertions(+), 1 deletion(-)
diff --git a/packv4-parse.c b/packv4-parse.c
index 04eab46..4c218d2 100644
--- a/packv4-parse.c
+++
This goes as follows:
- Tree reference: either variable length encoding of the index
into the SHA1 table or the literal SHA1 prefixed by 0 (see
encode_sha1ref()).
- Parent count: variable length encoding of the number of parents.
This is normally going to occupy a single byte but doesn't
Signed-off-by: Nicolas Pitre n...@fluxnic.net
---
packv4-create.c | 137
1 file changed, 137 insertions(+)
create mode 100644 packv4-create.c
diff --git a/packv4-create.c b/packv4-create.c
new file mode 100644
index 000..2de6d41
---
This is a minor change over pack index v2. Since pack v4 already contains
the sorted SHA1 table, it is therefore ommitted from the index file.
Signed-off-by: Nicolas Pitre n...@fluxnic.net
---
pack-write.c| 6 +-
packv4-create.c | 10 +-
2 files changed, 14 insertions(+), 2
Signed-off-by: Nicolas Pitre n...@fluxnic.net
---
packv4-create.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/packv4-create.c b/packv4-create.c
index c8d3053..45f8427 100644
--- a/packv4-create.c
+++ b/packv4-create.c
@@ -16,6 +16,7 @@
#include varint.h
+static
At least commit af25e94d4dcfb9608846242fabdd4e6014e5c9f0 in the Linux
kernel repository has author 1120285620 -0700
Signed-off-by: Nicolas Pitre n...@fluxnic.net
---
packv4-create.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/packv4-create.c b/packv4-create.c
In pack v4 the object size and type is encoded differently from pack v3.
The object size uses the same efficient variable length number encoding
already used elsewhere.
The object type has 4 bits allocated to it compared to 3 bits in pack v3.
This should be quite sufficient for the foreseeable
Let's read a pack to feed our dictionary with all the path strings
contained in all the tree objects.
Dump the resulting dictionary sorted by frequency to stdout.
Signed-off-by: Nicolas Pitre n...@fluxnic.net
---
Makefile| 1 +
packv4-create.c | 137
This adds the missing code to finally be able to produce a complete
pack file version 4. We trap commit and tree objects as those have
a completely new encoding. Other object types are copied almost
unchanged.
As we go the pack index entries are updated in place to store the new
object offsets
Let's create a struct pack_idx_entry list with sorted sha1 which will
be useful later. The offset sorted list is now a separate indirect
list.
Signed-off-by: Nicolas Pitre n...@fluxnic.net
---
packv4-create.c | 72 +
1 file changed, 42
Augment dict entries with a 16-bit prefix in order to store the file
mode value of tree entries.
Signed-off-by: Nicolas Pitre n...@fluxnic.net
---
packv4-create.c | 56
1 file changed, 36 insertions(+), 20 deletions(-)
diff --git
For this we need the pack version. However only open_packed_git_1() has
been audited for pack v4 so far, hence the version validation is not
added to pack_version_ok() just yet.
Signed-off-by: Nicolas Pitre n...@fluxnic.net
---
cache.h | 1 +
sha1_file.c | 14 --
2 files
Signed-off-by: Nicolas Pitre n...@fluxnic.net
---
packv4-create.c | 73 +++--
1 file changed, 34 insertions(+), 39 deletions(-)
diff --git a/packv4-create.c b/packv4-create.c
index 22cdf8e..c23c791 100644
--- a/packv4-create.c
+++
The SHA1 reference is either an index into a SHA1 table using the variable
length number encoding, or the literal 20 bytes SHA1 prefixed with a 0.
The index 0 discriminates between an actual index value or the literal
SHA1. Therefore when the index is used its value must be increased by 1.
In order to be able to quickly walk tree objects, let's encode their
delta as a range of entries into another tree object.
In order to discriminate between a copy sequence from a regular entry,
the entry index LSB is reserved to indicate a copy sequence. Therefore
the actual index of a path
Let's actually open the destination pack file and write the header and
the tables.
The header isn't much different from pack v3, except for the pack version
number of course.
The first table is the sorted SHA1 table normally found in the pack index
file. With pack v4 we write this table in the
Signed-off-by: Nicolas Pitre n...@fluxnic.net
---
cache.h | 1 +
sha1_file.c | 4 ++--
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/cache.h b/cache.h
index 85b544f..b6634c4 100644
--- a/cache.h
+++ b/cache.h
@@ -1160,6 +1160,7 @@ struct object_info {
} u;
};
extern
This is like get_sha1_hex() but stricter in accepting lowercase letters
only.
Signed-off-by: Nicolas Pitre n...@fluxnic.net
---
cache.h | 3 +++
hex.c | 11 +++
2 files changed, 14 insertions(+)
diff --git a/cache.h b/cache.h
index b6634c4..4231dfa 100644
--- a/cache.h
+++ b/cache.h
Let's start actually parsing pack v4 data. Here's the first item.
Signed-off-by: Nicolas Pitre n...@fluxnic.net
---
Makefile | 1 +
packv4-parse.c | 30 ++
2 files changed, 31 insertions(+)
create mode 100644 packv4-parse.c
diff --git a/Makefile b/Makefile
The SHA1 of the base object is retrieved and the corresponding object
is loaded in memory for pv4_encode_tree() to look at. Simple but
effective. Obviously this relies on the delta matching already performed
during the pack v3 delta search. Some native delta search for pack v4
could be
Let's create another dictionary table to hold the author and committer
entries. We use the same table format used for tree entries where the
16 bit data prefix is conveniently used to store the timezone value.
In order to copy straight from a commit object buffer, dict_add_entry()
is modified to
Blob and tag objects have no particular changes except for their object
header.
Delta objects are also copied as is, except for their delta base reference
which is converted to the new way as used elsewhere in pack v4 encoding
i.e. an index into the SHA1 table or a literal SHA1 prefixed by 0 if
A bit crud but good enough for now.
Signed-off-by: Nicolas Pitre n...@fluxnic.net
---
cache.h | 1 +
pack-check.c| 4 +++-
pack-revindex.c | 7 ---
sha1_file.c | 56 ++--
4 files changed, 58 insertions(+), 10 deletions(-)
Make sure the copy sequence is smaller than the list of tree entries it
is meant to replace. We do so by encoding tree entries in parallel with
the delta entry comparison, and then comparing the length of both
sequences.
Signed-off-by: Nicolas Pitre n...@fluxnic.net
---
packv4-create.c | 65
Usage of snprintf() is possibly not the most efficient approach.
For example we could simply copy the needed strings and generate
the SHA1 hex strings directly into the destination buffer. But
such optimizations may come later.
Signed-off-by: Nicolas Pitre n...@fluxnic.net
---
packv4-parse.c |
This goes as follows:
- Number of tree entries: variable length encoded.
Then for each tree entry:
- Path component reference: variable length encoded index into the path
dictionary table which also covers the entry mode. To make the overall
encoding efficient, the path table is already
Signed-off-by: Nicolas Pitre n...@fluxnic.net
---
packv4-create.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/packv4-create.c b/packv4-create.c
index c23c791..fd16222 100644
--- a/packv4-create.c
+++ b/packv4-create.c
@@ -13,6 +13,7 @@
#include tree-walk.h
#include pack.h
Signed-off-by: Nicolas Pitre n...@fluxnic.net
---
packv4-create.c | 58 +++--
1 file changed, 44 insertions(+), 14 deletions(-)
diff --git a/packv4-create.c b/packv4-create.c
index 5c08871..20d97a4 100644
--- a/packv4-create.c
+++
Jens Lehmann jens.lehm...@web.de writes:
Am 04.09.2013 21:19, schrieb Junio C Hamano:
Matthieu Moy matthieu@grenoble-inp.fr writes:
Junio C Hamano gits...@pobox.com writes:
* mm/status-without-comment-char (2013-08-29) 5 commits
- status: introduce status.displayCommentChar to
Jens Lehmann jens.lehm...@web.de writes:
Am 04.09.2013 08:31, schrieb Matthieu Moy:
brian m. carlson sand...@crustytoothpaste.net writes:
Tests are included which verify that this change has no effect on git
submodule
summary without the --for-status option.
I still don't understand
Am 9/2/2013 10:54, schrieb Joergen Edelbo:
Changes done:
Remove selection of branches to push - push always HEAD.
This can be justified by the fact that this far the most
common thing to do.
What are your plans to support a topic-based workflow? Far the most
common thing to happen is that
On Thu, Sep 05, 2013 at 02:19:54AM -0400, Nicolas Pitre wrote:
... replacing the equivalent open coded loop.
Signed-off-by: Nicolas Pitre n...@fluxnic.net
---
sha1_file.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index
2013/9/4 Junio C Hamano gits...@pobox.com:
kazuki saitoh ksaitoh...@gmail.com writes:
Currently, git p4 does not support many of the view wildcards,
such as * and %%n. It only knows the common ... mapping, and
exclusions.
Redo the entire wildcard code around the idea of
directly querying
On Wed, Sep 04, 2013 at 03:59:18PM -0700, Junio C Hamano wrote:
Are there cases where you do not want to either rebase nor merge?
If so what do you want to do after git pull fetches from the other
side? Nothing?
One other thing that I can see being useful occasionally is:
git rebase
Matthieu Moy matthieu@grenoble-inp.fr writes:
Jens Lehmann jens.lehm...@web.de writes:
Fine by me, what would you propose to clarify that? (Though I have the
suspicion that the explanation will be three years late ;-)
I have no idea, as I do not understand the reason myself yet. I'm not
-Original Message-
From: Johannes Sixt [mailto:j.s...@viscovery.net]
Sent: 5. september 2013 10:57
Please do not top-post.
Am 9/5/2013 10:29, schrieb Jørgen Edelbo:
-Original Message- From: Johannes Sixt
Am 9/2/2013 10:54, schrieb Joergen Edelbo:
Changes done:
Am 9/5/2013 11:18, schrieb Jørgen Edelbo:
Forgetting to push something that you have just
completed is very far from what I am used to.
Forgetting to push is just one of many reasons why a branch that is not
equal to HEAD is not yet pushed... The new restriction is just too tight.
-- Hannes
No behavior change, but two slight code reorganization: argv_array_push
doesn't accept NULL strings, and duplicates its argument hence
summary_limit must be written to before being inserted into argv.
Signed-off-by: Matthieu Moy matthieu@imag.fr
Signed-off-by: Junio C Hamano gits...@pobox.com
The previous commit set status.oldStyle file-wide in t7060-wtstatus.sh
and t7508-status.sh to make the patch small. However, now that
status.oldStyle is not the default, it is better to disable it in tests
so that the most common situation is also the most tested.
While we're there, move the cat
Compared to v2, this changes essentially:
* The prefix is actually disabled by default in this version. As a
consequence, the option is renamed to status.oldStyle.
* Since this is the default, the tests are updated to test the new
defaults. In a first patch, I'm setting status.oldStyle=true
On Thu, Sep 05, 2013 at 07:01:03AM -0400, John Szakmeister wrote:
On Wed, Sep 4, 2013 at 6:59 PM, Junio C Hamano gits...@pobox.com wrote:
[snip]
When git pull stops because what was fetched in FETCH_HEAD does
not fast-forward, then what did _you_ do (and with the knowledge you
currently
Oops, this series forgot to update t7512-status-help.sh, which now
fails.
I'll send a reroll that updates it later (patch below).
diff --git a/t/t7512-status-help.sh b/t/t7512-status-help.sh
index 31a798f..0688d58 100755
--- a/t/t7512-status-help.sh
+++ b/t/t7512-status-help.sh
@@ -25,18 +25,18
On Wed, Sep 4, 2013 at 10:44 PM, Junio C Hamano gits...@pobox.com wrote:
Christian Couder chrisc...@tuxfamily.org writes:
If -f option, which means '--force', is used, we can allow an object
to be replaced with one of a different type, as the user should know
what (s)he is doing.
On Wed, Sep 4, 2013 at 10:45 PM, Junio C Hamano gits...@pobox.com wrote:
Christian Couder chrisc...@tuxfamily.org writes:
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
Documentation/git-replace.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git
Junio C Hamano gits...@pobox.com writes:
Peff already covered (1)---it is highly doubtful that a merge is
almost always wrong. In fact, if that _were_ the case, we should
simply be defaulting to rebase, not failing the command and asking
between merge and rebase like jc/pull-training-wheel
I went to clone a repository from GitHub today and discovered
something interesting:
:: git clone https://github.com/liebke/incanter.git
Cloning into 'incanter'...
remote: Counting objects: 10457, done.
remote: Compressing objects: 100% (3018/3018), done.
error: object
- abbreviation is handy for cherry-pick like checkout and merge.
It's also good for uniformity that a - stands as
the name of the previous branch where a branch name is
accepted and it could not mean any other things like stdin.
Signed-off-by: Hiroshige Umino hiroshig...@gmail.com
---
On 2013-09-04 18:59, Junio C Hamano wrote:
Philip Oakley philipoak...@iee.org writes:
From: Junio C Hamano gits...@pobox.com
John Keeping j...@keeping.me.uk writes:
I think there are two distinct uses for pull, which boil down to:
(1) git pull
...
Peff already covered (1)---it is
You need at least four dashes in a line to have it recognized as listing
block delimiter by asciidoc.
Signed-off-by: Andreas Schwab sch...@linux-m68k.org
---
Documentation/git-merge.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-merge.txt
On Thu, Sep 05, 2013 at 10:00:39AM -0400, John Szakmeister wrote:
I went to clone a repository from GitHub today and discovered
something interesting:
:: git clone https://github.com/liebke/incanter.git
Cloning into 'incanter'...
remote: Counting objects: 10457, done.
On Thu, Sep 5, 2013 at 10:36 PM, Jeff King p...@peff.net wrote:
This is going to screw up pack v4 (yes, someday I'll have the
time to make it real).
I don't know if this is still true, but given that patches are
being sent out about it, I thought it relevant.
I haven't looked carefully at
check-ignore currently shows how .gitignore rules would treat untracked
paths. Tracked paths do not generate useful output. This prevents
debugging of why a path became tracked unexpectedly unless that path is
first removed from the index with `git rm --cached path`.
This option (-i, --no-index)
On 09/05/2013 11:36 AM, Jeff King wrote:
[...]
I haven't looked carefully at the pack v4 patches yet, but I suspect
that yes, it's still a problem. The premise of pack v4 is that we can do
better by not storing the raw git object bytes, but rather storing
specialized representations of the
On Thu, Sep 05, 2013 at 11:18:24PM +0700, Nguyen Thai Ngoc Duy wrote:
There are basically two solutions:
1. Add a single-bit flag for I am 0-padded in the real data. We
could probably even squeeze it into the same integer.
2. Have a classic section of the pack that stores the
On Thu, Sep 5, 2013 at 11:36 AM, Jeff King p...@peff.net wrote:
On Thu, Sep 05, 2013 at 10:00:39AM -0400, John Szakmeister wrote:
I went to clone a repository from GitHub today and discovered
something interesting:
:: git clone https://github.com/liebke/incanter.git
Cloning into
On Thu, 5 Sep 2013, Duy Nguyen wrote:
On Thu, Sep 5, 2013 at 12:39 PM, Nicolas Pitre n...@fluxnic.net wrote:
Now the pack index v3 probably needs to be improved a little, again to
accommodate completion of thin packs. Given that the main SHA1 table is
now in the main pack file, it should
On Thu, 5 Sep 2013, Jeff King wrote:
There are basically two solutions:
1. Add a single-bit flag for I am 0-padded in the real data. We
could probably even squeeze it into the same integer.
2. Have a classic section of the pack that stores the raw object
bytes. For objects
On Thu, Sep 5, 2013 at 12:39 PM, Nicolas Pitre n...@fluxnic.net wrote:
Now the pack index v3 probably needs to be improved a little, again to
accommodate completion of thin packs. Given that the main SHA1 table is
now in the main pack file, it should be possible to still carry a small
SHA1
On Thu, 5 Sep 2013, Jeff King wrote:
On Thu, Sep 05, 2013 at 11:18:24PM +0700, Nguyen Thai Ngoc Duy wrote:
There are basically two solutions:
1. Add a single-bit flag for I am 0-padded in the real data. We
could probably even squeeze it into the same integer.
2. Have
On Thu, 5 Sep 2013, SZEDER Gábor wrote:
Hi,
On Thu, Sep 05, 2013 at 02:19:28AM -0400, Nicolas Pitre wrote:
Let's create another dictionary table to hold the author and committer
entries. We use the same table format used for tree entries where the
16 bit data prefix is conveniently
Jørgen Edelbo j...@napatech.com writes:
You say I can only push HEAD. I understand this that I have to stop work on C
(perhaps commit or stash any unfinished work), then checkout A, push it,
checkout B, push it, checkout C and unstash the unfinished work. If my
understanding is correct, the
i have a business proposal for you, write me back for more info.
-Sent from my ipad.
--
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.html
Joergen Edelbo j...@napatech.com writes:
+proc get_remote_branch {} {
+ global push_branchtype push_branch push_new
+ set branch {}
+ switch -- $push_branchtype {
+ existing { set branch $push_branch }
+ create { set branch $push_new }
+ }
+ return $branch
+}
Thanks. It seems that this was broken from the beginning at
77c72780 (Documentation: merging a tag is a special case,
2013-03-21).
Will apply.
--
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
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
:(prefix) is in the long form. Suppose people pass :!foo with '!'
being the short form of magic 'bar', the code will happily turn it to
:(prefix..)!foo, which makes '!' part of the path and no longer a magic.
The correct form must be
Uli Heller uli.hel...@daemons-point.com writes:
When using git-svn in combination with serf-1.2.1 core dumps are
created on termination. This is caused by a bug in serf, a fix for
the bug exists (see https://code.google.com/p/serf/source/detail?r=2146).
Nevertheless, I think it makes sense to
On Thu, Sep 05, 2013 at 01:09:34PM -0400, Nicolas Pitre wrote:
On Thu, 5 Sep 2013, Jeff King wrote:
There are basically two solutions:
1. Add a single-bit flag for I am 0-padded in the real data. We
could probably even squeeze it into the same integer.
2. Have a classic
On Thu, 5 Sep 2013, Nicolas Pitre wrote:
If the path or name index is zero, this means the entry data is to be
found inline rather than being located in the dictionary table. This is
there to allow easy completion of thin packs without having to add new
table entries which would have required
On Thu, Sep 05, 2013 at 12:18:45PM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
On Wed, Sep 04, 2013 at 03:59:18PM -0700, Junio C Hamano wrote:
Are there cases where you do not want to either rebase nor merge?
If so what do you want to do after git pull fetches
John Keeping j...@keeping.me.uk writes:
On Wed, Sep 04, 2013 at 03:59:18PM -0700, Junio C Hamano wrote:
Are there cases where you do not want to either rebase nor merge?
If so what do you want to do after git pull fetches from the other
side? Nothing?
One other thing that I can see being
Matthieu Moy matthieu@imag.fr writes:
Compared to v2, this changes essentially:
* The prefix is actually disabled by default in this version. As a
consequence, the option is renamed to status.oldStyle.
* Since this is the default, the tests are updated to test the new
defaults. In
From: Junio C Hamano gits...@pobox.com
Christian Couder chrisc...@tuxfamily.org writes:
+test_expect_success 'replaced and replacement objects must be of the same
type' '
+test_must_fail git replace mytag $HASH1 2err
+grep mytag. points to a replaced object of type .tag err
+
On Thu, Sep 05, 2013 at 01:13:40PM -0400, John Szakmeister wrote:
Yep. These were mostly caused by a bug in Grit that is long-fixed. But
the objects remain in many histories. It would have painful to rewrite
them back then, and it would be even more painful now.
I guess there's still
Junio C Hamano gits...@pobox.com writes:
One caveat, though. The name oldStyle will become problematic,
when we want to remove some wart in the output format long after
this no comment prefix by default series lands. Some people may
expect setting oldStyle=true would give output from 1.8.4
Junio C Hamano gits...@pobox.com wrote:
Uli Heller uli.hel...@daemons-point.com writes:
Nevertheless, I think it makes sense to fix the issue within the
git perl module Ra.pm, too. The change frees the private copy of
the remote access object on termination which prevents the error
from
Nicolas Pitre n...@fluxnic.net writes:
On Thu, 5 Sep 2013, Duy Nguyen wrote:
On Thu, Sep 5, 2013 at 12:39 PM, Nicolas Pitre n...@fluxnic.net wrote:
Now the pack index v3 probably needs to be improved a little, again to
accommodate completion of thin packs. Given that the main SHA1 table
On 09/04/2013 05:27 PM, Junio C Hamano wrote:
I am not saying the above is the best format, but the point is that
the mode of the operation defines the structure
Great, thanks for your comments. Based on that I've prototyped a
new format. Rather than jumping straight to the patch, here is my
On Thu, 5 Sep 2013, Junio C Hamano wrote:
Nicolas Pitre n...@fluxnic.net writes:
On Thu, 5 Sep 2013, Duy Nguyen wrote:
On Thu, Sep 5, 2013 at 12:39 PM, Nicolas Pitre n...@fluxnic.net wrote:
Now the pack index v3 probably needs to be improved a little, again to
accommodate
On Thu, Sep 05, 2013 at 09:18:25AM +, Jørgen Edelbo wrote:
-Original Message-
From: Johannes Sixt [mailto:j.s...@viscovery.net]
Sent: 5. september 2013 10:57
Please do not top-post.
Am 9/5/2013 10:29, schrieb Jørgen Edelbo:
-Original Message- From: Johannes
Brad King brad.k...@kitware.com writes:
On 09/04/2013 05:27 PM, Junio C Hamano wrote:
I am not saying the above is the best format, but the point is that
the mode of the operation defines the structure
Great, thanks for your comments. Based on that I've prototyped a
new format. Rather
From: Junio C Hamano gits...@pobox.com
Philip Oakley philipoak...@iee.org writes:
From: Junio C Hamano gits...@pobox.com
John Keeping j...@keeping.me.uk writes:
I think there are two distinct uses for pull, which boil down to:
(1) git pull
...
Peff already covered (1)---it is highly
I hope it's not too inappropriate to send a random question your way, but I've
exhausted all other means and am quite lost at the moment..
I'm trying to setup a distributed development repository with a central
repository acting as the production copy. I'm doing so on a Windows file share
On Thu, 5 Sep 2013, Nicolas Pitre wrote:
On Thu, 5 Sep 2013, Nicolas Pitre wrote:
If the path or name index is zero, this means the entry data is to be
found inline rather than being located in the dictionary table. This is
there to allow easy completion of thin packs without having to
From: Philip Oakley philipoak...@iee.org
Sent: Saturday, August 31, 2013 11:16 PM
From: Christian Couder chrisc...@tuxfamily.org
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
Documentation/git-replace.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
Dave Williams d...@opensourcesolutions.co.uk writes:
check-ignore currently shows how .gitignore rules would treat untracked
paths. Tracked paths do not generate useful output. This prevents
debugging of why a path became tracked unexpectedly unless that path is
first removed from the index
Hiroshige Umino hiroshig...@gmail.com writes:
- abbreviation is handy for cherry-pick like checkout and merge.
It's also good for uniformity that a - stands as
the name of the previous branch where a branch name is
accepted and it could not mean any other things like stdin.
Signed-off-by:
Philip Oakley philipoak...@iee.org writes:
From: Philip Oakley philipoak...@iee.org
Sent: Saturday, August 31, 2013 11:16 PM
From: Christian Couder chrisc...@tuxfamily.org
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
Documentation/git-replace.txt | 4 +++-
1 file changed, 3
Eric Wong normalper...@yhbt.net writes:
Junio C Hamano gits...@pobox.com wrote:
Uli Heller uli.hel...@daemons-point.com writes:
Nevertheless, I think it makes sense to fix the issue within the
git perl module Ra.pm, too. The change frees the private copy of
the remote access object on
Matthieu Moy matthieu@grenoble-inp.fr writes:
Junio C Hamano gits...@pobox.com writes:
One caveat, though. The name oldStyle will become problematic,
when we want to remove some wart in the output format long after
this no comment prefix by default series lands. Some people may
expect
On Thu, Sep 05, 2013 at 09:36:47PM +0200, Matthieu Moy wrote:
Junio C Hamano gits...@pobox.com writes:
One caveat, though. The name oldStyle will become problematic,
when we want to remove some wart in the output format long after
this no comment prefix by default series lands. Some
1 - 100 of 123 matches
Mail list logo
