On Wed, 2013-12-04 at 12:28 -0800, Junio C Hamano wrote:
Martin Langhoff martin.langh...@gmail.com writes:
On Wed, Dec 4, 2013 at 10:46 AM, Krzesimir Nowak krzesi...@endocode.com
wrote:
On Wed, 2013-12-04 at 16:11 +0100, Jakub Narębski wrote:
On Wed, Dec 4, 2013 at 2:42 PM, Krzesimir
On Wed, 2013-12-04 at 12:31 -0800, Junio C Hamano wrote:
Krzesimir Nowak krzesi...@endocode.com writes:
This check will be used in more than one place later.
Signed-off-by: Krzesimir Nowak krzesi...@endocode.com
Reviewed-by: Junio C Hamano gits...@pobox.com
Again, I do not think I
On Wed, 2013-12-04 at 16:56 +0100, Jakub Narębski wrote:
On Wed, Dec 4, 2013 at 2:43 PM, Krzesimir Nowak krzesi...@endocode.com
wrote:
This check will be used in more than one place later.
Signed-off-by: Krzesimir Nowak krzesi...@endocode.com
Reviewed-by: Junio C Hamano
On Wed, 2013-12-04 at 17:07 +0100, Jakub Narębski wrote:
On Wed, Dec 4, 2013 at 2:43 PM, Krzesimir Nowak krzesi...@endocode.com
wrote:
Users of validate_* passing 0 might get failures on correct name
because of coercion of 0 to false in code like:
die_error(500, invalid ref) unless
On Wed, 2013-12-04 at 19:06 +0100, Jakub Narębski wrote:
On Wed, Dec 4, 2013 at 2:43 PM, Krzesimir Nowak krzesi...@endocode.com
wrote:
Allow extra-branch-refs feature to tell gitweb to show refs from
additional hierarchies in addition to branches in the list-of-branches
view.
$ git rev-parse foobar --
foobar
fatal: ambiguous argument 'foobar': unknown revision or path not in
the working tree.
Use '--' to separate paths from revisions, like this:
'git command [revision...] -- [file...]'
I already put -- there. So it should shut up.
--
Duy
--
To unsubscribe from this
On Thu, Dec 5, 2013 at 11:00 AM, Krzesimir Nowak krzesi...@endocode.com wrote:
On Wed, 2013-12-04 at 19:06 +0100, Jakub Narębski wrote:
On Wed, Dec 4, 2013 at 2:43 PM, Krzesimir Nowak krzesi...@endocode.com
wrote:
+The gitweb.extrabranchrefs is actually a multi-valued configuration
This is very urgent from Western Union, our Operation manager has sent your
1st
payment of $5000.00 out of your total amount of $1.5million dollar and we
needed this from you to complete the ransfer, You’ re Name,Address, ID CARD
and
Telephone No: Noted That Only Fee Request from You Is for
No callers pass a non-empty pointer as shallow_points at this
stage. As a result, all clients still refuse to talk to shallow
repository on the other end.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/fetch-pack.c | 2 +-
builtin/send-pack.c | 2 +-
connect.c|
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
commit.h | 8 +---
fetch-pack.c | 5 +++--
shallow.c | 20 +++-
upload-pack.c | 2 +-
4 files changed, 24 insertions(+), 11 deletions(-)
diff --git a/commit.h b/commit.h
index a879526..1faf717 100644
---
If we borrow objects from another repository, we should also pay
attention to their $GIT_DIR/shallow (and even info/grafts). But
current alternates code does not.
Reject alternate repos that are shallow because we do not do it
right. In future the alternate code may be updated to check
If either receive-pack or upload-pack is called on a shallow
repository, shallow commits (*) will be sent after the ref
advertisement (but before the packet flush), so that the receiver has
the full shape of the sender's commit graph. This will be needed for
the receiver to update its .git/shallow
The latter can do everything the former can and is used in many more
places.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/send-pack.c | 5 ++---
connect.c | 12 +++-
remote.h| 7 ++-
send-pack.c | 7 ---
send-pack.h |
This reroll should fix all comments I have received in v3. I reordered
the shallow checks a bit so in common case it should be as cheap as
a normal fetch or push. See 08/28 and 20/28 for the big picture. I'm not
entirely happy with the hook issue in 20/28, but it looks good enough
for me. There
send-pack can send a pack with loose ends to the server. receive-pack
before 6d4bb38 (fetch: verify we have everything we need before
updating our ref - 2011-09-01) does not detect this and keeps the pack
anyway, which corrupts the repository, at least from fsck point of
view.
send-pack will
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
transport.h | 6 --
1 file changed, 6 deletions(-)
diff --git a/transport.h b/transport.h
index 8f96bed..b3679bb 100644
--- a/transport.h
+++ b/transport.h
@@ -193,10 +193,4 @@ void transport_print_push_status(const char *dest, struct
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
fetch-pack.h | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/fetch-pack.h b/fetch-pack.h
index 461cbf3..9b08388 100644
--- a/fetch-pack.h
+++ b/fetch-pack.h
@@ -8,18 +8,18 @@ struct
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
commit.h | 3 +
shallow.c | 295 ++
2 files changed, 298 insertions(+)
diff --git a/commit.h b/commit.h
index 9ead93b..69bca3e 100644
--- a/commit.h
+++ b/commit.h
@@ -223,6
Cloning from a shallow repository does not follow the 8 steps for new
.git/shallow because if it does we need to get through step 6 for all
refs. That means commit walking down to the bottom.
Instead the rule to create .git/shallow is simpler and, more
importantly, cheap: if a shallow commit is
Suppose a fetch or push is requested between two shallow repositories
(with no history deepening or shortening). A pack that contains
necessary objects is transferred over together with .git/shallow of
the sender. The receiver has to determine whether it needs to update
.git/shallow if new refs
When fetch --depth=N where N exceeds the longest chain of history in
the source repo, usually we just send an unshallow line to the
client so full history is obtained.
When the source repo is shallow we need to make sure to unshallow
the current shallow point _and_ shallow again when the commit
The same steps are done as in when --update-shallow is not given. The
only difference is we now add all shallow commits in ours and
theirs to .git/shallow (aka step 8).
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/fetch-options.txt | 6 ++
builtin/fetch.c
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
fetch-pack.c | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/fetch-pack.c b/fetch-pack.c
index 0e7483e..35d097e 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -925,6 +925,18 @@ static int
This patch just put together pieces from the 8 steps patch. We stop at
step 7 and reject refs that require new shallow commits.
Note that, by rejecting refs that require new shallow commits, we
leave dangling objects in the repo, which become object islands by
the next git fetch of the same
This is the preparation for adding --shallow-file to both
unpack-objects and index-pack. To sum up:
- struct argv_array used instead of const char **
- status/code, ip/child, unpacker/keeper are moved out to function
top level
- successful flow now ends at the end of the function
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/technical/pack-protocol.txt | 4 +-
builtin/receive-pack.c| 78 +++
builtin/send-pack.c | 2 +-
send-pack.c | 3 ++
This may be needed when a hook is run after a new shallow pack is
received, but .git/shallow is not settled yet. A temporary shallow
file to plug all loose ends should be used instead. GIT_SHALLOW_FILE
is overriden by --shallow-file.
--shallow-file does not work in this case because the hook may
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
connected.c | 42 ++
connected.h | 2 ++
2 files changed, 36 insertions(+), 8 deletions(-)
diff --git a/connected.c b/connected.c
index fae8d64..427389d 100644
--- a/connected.c
+++ b/connected.c
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/send-pack.c | 4 +++-
t/t5537-push-shallow.sh | 38 ++
transport.c | 5 ++---
3 files changed, 43 insertions(+), 4 deletions(-)
diff --git a/builtin/send-pack.c
clone_local() does not handle $SRC/shallow. It could be made so, but
it's simpler to use fetch-pack/upload-pack instead.
This used to be caught by the check in upload-pack, which is triggered
by transport_get_remote_refs(), even in local clone case. The check is
now gone and
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/receive-pack.c | 3 ---
t/t5537-push-shallow.sh | 35 +++
2 files changed, 35 insertions(+), 3 deletions(-)
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index 5c85bb4..78fe8ee
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/gitremote-helpers.txt | 7 +++
builtin/fetch-pack.c| 16 +---
remote-curl.c | 31 +--
t/t5536-fetch-shallow.sh| 27
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/send-pack.c | 3 ---
send-pack.c | 19 +--
t/t5537-push-shallow.sh | 25 +
3 files changed, 42 insertions(+), 5 deletions(-)
diff --git a/builtin/send-pack.c
The basic 8 steps to update .git/shallow does not fully apply here
because the user may choose to accept just a few refs (while fetch
always accepts all refs). The steps are modified a bit.
1-6. same as before. After calling assign_shallow_commits_to_refs at
step 6, each shallow commit has a
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/fetch-pack.c | 7 +++
remote-curl.c| 3 ++-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/builtin/fetch-pack.c b/builtin/fetch-pack.c
index 927424b..aa6e596 100644
--- a/builtin/fetch-pack.c
+++
This patch teaches prune to remove shallow roots that are no longer
reachable from any refs (e.g. when the relevant refs are removed).
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/git-prune.txt | 2 ++
builtin/gc.c| 1 +
builtin/prune.c |
Now that git supports data transfer from or to a shallow clone, these
limitations are not true anymore.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/git-clone.txt | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/Documentation/git-clone.txt
This discussion has mostly been about letting small Git servers delegate
the work of an initial clone to a beefier server. I haven't seen any
explicit mention of the inverse:
Suppose a company has a central Git server that is meant to be the
single source of truth, but has worldwide offices and
On Thu, Dec 5, 2013 at 5:21 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
This discussion has mostly been about letting small Git servers delegate
the work of an initial clone to a beefier server. I haven't seen any
explicit mention of the inverse:
Suppose a company has a central Git
http://goo.gl/N47wYu проститесь с расплывчатым очертанием В телевизоре
N▀╖╡ФЛr╦⌡yЗХ ьb╡X╛╤г╖vь^√)ч╨{.nг+┴╥═┼ь╖╤⌡║э╗}╘·╡ф═zзj:+v┴╗╬╚▒ЙГzZ+─й+zfё╒╥h
┬╖~├╜├шiЪШЮz╧ ╝w╔╒╦?≥╗Х╜з╒)ъ╒f
Good Day,
This mail is to make an inquiry on the below Questions.
Do you Ship oversea or do intend to start Shipping oversea? (though we already
know of a Freight Forwarder that will pick our packages from you and deliver to
us Australia.
PAYMENT MODE...CREDIT CARD
Kindly send
On Wed, Dec 04, 2013 at 10:50:27PM -0800, Shawn Pearce wrote:
I wasn't thinking about using a well known blob for this.
Jonathan, Dave, Colby and I were kicking this idea around on Monday
during lunch. If the initial ref advertisement included a mirrors
capability the client could respond
On Thu, Dec 05, 2013 at 02:21:09PM +0100, Michael Haggerty wrote:
A better alternative would be to ask users to clone from the central
server. In this case, the central server would want to tell the clients
to grab what they can from their local bootstrap mirror and then come
back to the
Jeff King p...@peff.net writes:
Right, I think that's the most critical one (though you could also just
use the convention of .bundle in the URL). I think we may want to
leave room for more metadata, though.
Good. I like this line of thinking.
Heck, remote.origin.url might already
be a
Christian Couder christian.cou...@gmail.com writes:
Tell me if I can do something.
I think the tip of 'pu' with cc/starts-n-ends-with-endgame is in
fairly a good shape. The evil merge there may need to be updated
over time, but I think I can manage.
--
To unsubscribe from this list: send the
Krzesimir Nowak krzesi...@endocode.com writes:
On Wed, 2013-12-04 at 17:07 +0100, Jakub Narębski wrote:
The only change that needs to be doe is replacing
return $input;
with
return 1;
I prefer to use zeros instead of undefs - one might wonder if that undef
is
Duy Nguyen pclo...@gmail.com writes:
On Thu, Dec 5, 2013 at 8:23 AM, Junio C Hamano gits...@pobox.com wrote:
* aa/transport-non-positive-depth-only (2013-11-26) 1 commit
(merged to 'next' on 2013-11-27 at b01f05b)
+ transport: catch non positive --depth option value
Will merge to
On Wed, Dec 4, 2013 at 6:01 PM, Martin Langhoff
martin.langh...@gmail.com wrote:
Is there a reasonable approach to scripting this?
Found my answers.
The 'subtree' merge strategy is smart enough to mostly help here.
However, it does not handle new files created in the subdirectory.
My workflow
On Thu, Dec 05, 2013 at 10:01:28AM -0800, Junio C Hamano wrote:
You could have a git-advertise-upstream that generates a mirror blob
from your remotes config and pushes it to your publishing point. That
may be overkill, but I don't think it's possible with a
.git/config-based solution.
On Thu, Dec 5, 2013 at 7:16 PM, Junio C Hamano gits...@pobox.com wrote:
Krzesimir Nowak krzesi...@endocode.com writes:
On Wed, 2013-12-04 at 17:07 +0100, Jakub Narębski wrote:
The only change that needs to be done is replacing
return $input;
with
return 1;
I
On Thu, Dec 05, 2013 at 05:07:31PM +0700, Duy Nguyen wrote:
$ git rev-parse foobar --
foobar
fatal: ambiguous argument 'foobar': unknown revision or path not in
the working tree.
Use '--' to separate paths from revisions, like this:
'git command [revision...] -- [file...]'
I already put
Am 05.12.2013 00:01, schrieb Martin Langhoff:
Hi folks.
currently working on a project based on Moodle (the LMS that got me
into git in the first place). This is a highly modular software, and I
would like to maintain a bunch of out of tree modules in a single
repository, and be able to
On Thu, Dec 5, 2013 at 2:18 PM, Jens Lehmann jens.lehm...@web.de wrote:
Without knowing more I can't think of a reason why submodules should
not suit your use case (but you'd have to script branching and tagging
yourself until these commands learn to recurse into submodules too).
The
When using the '-v' option of git commit the diff added to the commit
message temporarily for editing is stripped off after the user exited the
editor by searching for \ndiff --git and truncating the commmit message
there if it is found.
But this approach has two problems:
- when the commit
Nick Townsend nick.towns...@mac.com writes:
Interplay between paths specified in three ways now tested:
* After a : in the tree-ish,
* As a pathspec in the command,
* By virtue of the current working directory
Note that these tests are based on the behaviours
as found in 1.8.5. They may
Am 05.12.2013 20:27, schrieb Martin Langhoff:
On Thu, Dec 5, 2013 at 2:18 PM, Jens Lehmann jens.lehm...@web.de wrote:
Without knowing more I can't think of a reason why submodules should
not suit your use case (but you'd have to script branching and tagging
yourself until these commands learn
Jeff King p...@peff.net writes:
$ foobar
$ git rev-parse foobar --
foobar
--
fatal: bad flag '--' used after filename
That's not right.
Hmph, it looks like it is following the usual zero-or-more dashed
options, zero-or-more revs and then zero-or-one double-dash and then
Jakub Narębski jna...@gmail.com writes:
But I am not against return 0; on validation error (would putting
it in separate patch make review easier, or just pointlessly proliferate
patches?).
OK.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
On Thu, Dec 05, 2013 at 12:00:16PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
$ foobar
$ git rev-parse foobar --
foobar
--
fatal: bad flag '--' used after filename
That's not right.
Hmph, it looks like it is following the usual zero-or-more dashed
Jens Lehmann jens.lehm...@web.de writes:
When using the '-v' option of git commit the diff added to the commit
message temporarily for editing is stripped off after the user exited the
editor by searching for \ndiff --git and truncating the commmit message
there if it is found.
But this
Jeff King p...@peff.net writes:
On Thu, Dec 05, 2013 at 12:00:16PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
$ foobar
$ git rev-parse foobar --
foobar
--
fatal: bad flag '--' used after filename
That's not right.
Hmph, it looks like it is
On Thu, Dec 05, 2013 at 11:04:18AM -0500, Jeff King wrote:
Yes. And this is why the packfile name algorithm is horribly flawed. I
keep saying we should change it to name the pack using the last 20
bytes of the file but ... nobody has written the patch for that? :-)
Totally agree. I
Am 05.12.2013 00:19, schrieb Heiko Voigt:
On Wed, Dec 04, 2013 at 02:32:46PM -0800, Junio C Hamano wrote:
This series tries to achieve the following goals for the
submodule.name.ignore=all configuration or the --ignore-submodules=all
command line switch.
Thanks for the summary.
* Make git
On Thu, Dec 05, 2013 at 12:15:07PM -0800, Junio C Hamano wrote:
Hmph, it looks like it is following the usual zero-or-more dashed
options, zero-or-more revs and then zero-or-one double-dash and then
zero-or-more paths rule to parse the thing. foobar is a file and
not a rev, so -- should
On Thu, Dec 05, 2013 at 04:00:00PM -0500, Jeff King wrote:
Yes, I do expect an error. But it should not be -- after filename. It
should be foobar is not a revision.
[...]
It would be nice to get the error messages right, though. I do not see
any reason why it could not follow the same steps
Jeff King p...@peff.net writes:
BTW, the raw looping to find -- made me wonder how we handle:
git log --grep -- HEAD
I'd expect it to be equivalent to:
git log --grep=-- HEAD
but it's not; we truncate the arguments and complain that --grep is
missing its argument. Which is probably
On Thu, Dec 5, 2013 at 12:28 PM, Jeff King p...@peff.net wrote:
Subject: pack-objects: name pack files after trailer hash
Our current scheme for naming packfiles is to calculate the
sha1 hash of the sorted list of objects contained in the
packfile. This gives us a unique name, so we are
On Thu, Dec 5, 2013 at 2:54 PM, Jens Lehmann jens.lehm...@web.de wrote:
Am 05.12.2013 20:27, schrieb Martin Langhoff:
On Thu, Dec 5, 2013 at 2:18 PM, Jens Lehmann jens.lehm...@web.de wrote:
Without knowing more I can't think of a reason why submodules should
not suit your use case (but you'd
Jeff King p...@peff.net writes:
The second half would be to simplify git-repack. The current behavior is
to replace the old packfile with a tricky rename dance. Which is still
correct, but overly complicated. We should be able to just drop the new
packfile, since we know the bytes are
Jens Lehmann jens.lehm...@web.de writes:
+ fprintf(s-fp, %c %s, comment_line_char, cut_line);
+ strbuf_add_commented_lines(buf, explanation,
strlen(explanation));
+ fprintf(s-fp, buf.buf);
This is better done with:
fputs(buf.buf, s-fp);
Already
When --prompt option is set, git-difftool displays a prompt for each modified
file to be viewed in an external diff program. At that point it could be useful
to display a counter and the total number of files in the diff queue.
Below is the current difftool prompt for the first of 5 modified
... instead of 1.8.6 (which would have been the name if we were on
auto-pilot), so that the version that comes after it will logically
be 2.0. Distro people may want to make sure that they are not
hardcoding three-dewey-decimal are feature releases,
four-dewey-decimal are maintenance releases
On Wed, Dec 4, 2013 at 11:11 PM, SCHILZ MANFRED manfred.sch...@bgl.lu wrote:
Hello,
We are using git on windows7(git-version 1.8.1; see below) and we get the
following problem in using the command 'git --git-dir='
C:\UserTemp\git\appli3git --git-dir=C:\UserTemp\git\appli3 tag
fatal: Not a
On Fri, Dec 6, 2013 at 4:28 AM, Jeff King p...@peff.net wrote:
BTW, the raw looping to find -- made me wonder how we handle:
git log --grep -- HEAD
I'd expect it to be equivalent to:
git log --grep=-- HEAD
but it's not; we truncate the arguments and complain that --grep is
missing
On 06/12/2013 08:07, Duy Nguyen wrote:
On Wed, Dec 4, 2013 at 11:11 PM, SCHILZ MANFRED manfred.sch...@bgl.lu wrote:
Hello,
We are using git on windows7(git-version 1.8.1; see below) and we get the
following problem in using the command 'git --git-dir='
C:\UserTemp\git\appli3git
Until now, HEAD could be used with git-push to push the current
branch. Now @ is a shortcut to HEAD, but it didn't work when
pushing branches. It fails with:
fatal: remote part of refspec is not a valid name in @
Reinterpret all branch names from argv in order for @ to be used
when pushing
From: Anders Waldenborg and...@0x63.nu
diff.orderfile acts as a default for the -O command line option.
[sb: fixed testcases revised docs based on Jonathan Nieder's suggestions]
Signed-off-by: Anders Waldenborg and...@0x63.nu
Thanks-to: Jonathan Nieder jrnie...@gmail.com
Signed-off-by: Samuel
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/glossary-content.txt | 29 -
1 file changed, 12 insertions(+), 17 deletions(-)
diff --git a/Documentation/glossary-content.txt
b/Documentation/glossary-content.txt
index aa1c888..b7e7ab5 100644
A WIP patch [1] was posted a while ago. This is the polished version
with tests and stuff. '!' is used as the shortcut instead of '-'. You
can now say select this path except this subpath... for nearly all
commands that take pathspec.
[1]
Back in 233c3e6 (parse_pathspec: preserve prefix length via
PATHSPEC_PREFIX_ORIGIN - 2013-07-14), parse_pathspec() is taught to
save prefix length as a dynamic magic. This is needed when the
pathspec is passed to another process and and prefix lenght would be
lost.
Back then we support two cases.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/glossary-content.txt | 5 +
builtin/add.c| 5 +-
dir.c| 47 +++--
pathspec.c | 9 +-
pathspec.h | 4 +-
81 matches
Mail list logo
