Re: What's cooking in git.git (Nov 2013, #05; Thu, 21)
On Fri, Nov 22, 2013 at 1:19 AM, Junio C Hamano gits...@pobox.com wrote: * rh/remote-hg-bzr-updates (2013-11-18) 9 commits (merged to 'next' on 2013-11-20 at a36f3c4) + remote-bzr, remote-hg: fix email address regular expression + test-hg.sh: help user correlate verbose output with email test + test-hg.sh: fix duplicate content strings in author tests + test-hg.sh: avoid obsolete 'test' syntax + test-hg.sh: eliminate 'local' bashism + test-bzr.sh, test-hg.sh: prepare for change to push.default=simple + test-bzr.sh, test-hg.sh: allow running from any dir + test-lib.sh: convert $TEST_DIRECTORY to an absolute path + remote-hg: don't decode UTF-8 paths into Unicode objects Can wait in 'next'. Would it be possible to merge the first commit of this series in master (and eventually in maint) ? My commit (11362653: remote-hg: unquote C-style paths when exporting) breaks the remote-hg tests since v1.8.4.3 (sorry about that), and is fixed by this commit. It would be nice to deliver 1.8.5 with working remote-helpers tests. Cheers, Antoine -- 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
[PATCH] remote-hg: fix hg sharedpath when git clone is moved
remote-hg is using a mercurial shared clone to store all remotes objects in one place. Unfortunately, the sharedpath is stored as an absolute path by mercurial, creating a dependency on the location of the git repository. Whenever the git repository is moved, the sharedpath must be updated to reflect the new absolute path. Check mercurial sharedpath file when getting the local hg repository, and update it manually with the new path if necessary. Signed-off-by: Antoine Pelisse apeli...@gmail.com --- contrib/remote-helpers/git-remote-hg | 4 contrib/remote-helpers/test-hg.sh| 11 +++ 2 files changed, 15 insertions(+) diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg index c6026b9..576f094 100755 --- a/contrib/remote-helpers/git-remote-hg +++ b/contrib/remote-helpers/git-remote-hg @@ -416,6 +416,10 @@ def get_repo(url, alias): local_path = os.path.join(dirname, 'clone') if not os.path.exists(local_path): hg.share(myui, shared_path, local_path, update=False) +else: +sharedpath_file = os.path.join(local_path, '.hg', 'sharedpath') +if hg_path != open(sharedpath_file, 'r').read(): +open(sharedpath_file, 'w').write(hg_path) repo = hg.repository(myui, local_path) try: diff --git a/contrib/remote-helpers/test-hg.sh b/contrib/remote-helpers/test-hg.sh index 72f745d..2477540 100755 --- a/contrib/remote-helpers/test-hg.sh +++ b/contrib/remote-helpers/test-hg.sh @@ -335,6 +335,17 @@ test_expect_success 'remote cloning' ' check gitrepo HEAD zero ' +test_expect_success 'moving remote clone' ' + test_when_finished rm -rf gitrepo* + + ( + git clone hg::hgrepo gitrepo + mv gitrepo gitrepo2 + cd gitrepo2 + git fetch + ) +' + test_expect_success 'remote update bookmark' ' test_when_finished rm -rf gitrepo* -- 1.8.5.rc1.30.g02973b8.dirty -- 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
Re: [PATCH] remote-hg: fix hg sharedpath when git clone is moved
On Sat, Nov 23, 2013 at 1:38 PM, Antoine Pelisse apeli...@gmail.com wrote: remote-hg is using a mercurial shared clone to store all remotes objects in one place. Unfortunately, the sharedpath is stored as an absolute path by mercurial, creating a dependency on the location of the git repository. Whenever the git repository is moved, the sharedpath must be updated to reflect the new absolute path. Check mercurial sharedpath file when getting the local hg repository, and update it manually with the new path if necessary. Signed-off-by: Antoine Pelisse apeli...@gmail.com --- By the way, this is the only link [1] I found about both relative path and updating the file. So it looks like there is no other way to update the path but to write the file manually. [1]: http://bz.selenic.com/show_bug.cgi?id=2006 -- 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
[PATCH] bash prompt: add option to disable for a repository
If bash.prompt is set to false, disable the prompt. This is useful
for huge repositories like the home directory.
Signed-off-by: Heikki Hokkanen h...@users.sf.net
---
git-prompt.sh performance seems to be quite bad for big repositories, so
without a way to disable it selectively for repositories, it becomes unusable
for people who have their homedir under git. This patch generalizes the problem
a bit by allowing the prompt to be disabled by setting bash.prompt to false in
any repository.
contrib/completion/git-prompt.sh | 8
1 file changed, 8 insertions(+)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 7b732d2..c982fde 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -84,6 +84,8 @@
# GIT_PS1_SHOWCOLORHINTS to a nonempty value. The colors are based on
# the colored output of git status -sb and are available only when
# using __git_ps1 for PROMPT_COMMAND or precmd.
+#
+# To disable prompt for a repository, run git config bash.prompt false
# check whether printf supports -v
__git_printf_supports_v=
@@ -304,6 +306,12 @@ __git_ps1 ()
return
fi
+ local prompt_setting
+ prompt_setting=$(git config --bool bash.prompt)
+ if [ -n $prompt_setting ] [ $prompt_setting == false ]; then
+ return
+ fi
+
local short_sha
if [ $rev_parse_exit_code = 0 ]; then
short_sha=${repo_info##*$'\n'}
--
1.8.4
--
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
Re: [PATCH] bash prompt: add option to disable for a repository
Am 23.11.2013 14:18, schrieb Heikki Hokkanen:
If bash.prompt is set to false, disable the prompt. This is useful
for huge repositories like the home directory.
Signed-off-by: Heikki Hokkanen h...@users.sf.net
---
git-prompt.sh performance seems to be quite bad for big repositories, so
without a way to disable it selectively for repositories, it becomes unusable
for people who have their homedir under git. This patch generalizes the
problem
a bit by allowing the prompt to be disabled by setting bash.prompt to false in
any repository.
contrib/completion/git-prompt.sh | 8
1 file changed, 8 insertions(+)
diff --git a/contrib/completion/git-prompt.sh
b/contrib/completion/git-prompt.sh
index 7b732d2..c982fde 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -84,6 +84,8 @@
# GIT_PS1_SHOWCOLORHINTS to a nonempty value. The colors are based on
# the colored output of git status -sb and are available only when
# using __git_ps1 for PROMPT_COMMAND or precmd.
+#
+# To disable prompt for a repository, run git config bash.prompt false
# check whether printf supports -v
__git_printf_supports_v=
@@ -304,6 +306,12 @@ __git_ps1 ()
return
fi
+ local prompt_setting
+ prompt_setting=$(git config --bool bash.prompt)
+ if [ -n $prompt_setting ] [ $prompt_setting == false ]; then
+ return
+ fi
+
Gah! This adds a fork+exec each time the prompt is shown. Not good,
particularly on Windows.
Since your intent is to disable the prompt in the home directory,
wouldn't that mean that most of the time you *don't* want the prompt?
Wouldn't you be better served with a method that *turns on* the prompt?
For example, a shell function that sets PS1 and another one that unsets
it? Or a wrapper that inspects a shell variable and calls __git_ps1 only
when you want a prompt.
local short_sha
if [ $rev_parse_exit_code = 0 ]; then
short_sha=${repo_info##*$'\n'}
-- Hannes
--
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
Re: [PATCH 0/2] thin-pack capability for send-pack/receive-pack
On Wed, 2013-11-06 at 15:42 -0800, Shawn Pearce wrote: On Wed, Nov 6, 2013 at 1:41 PM, Carlos Martín Nieto c...@elego.de wrote: On Wed, 2013-11-06 at 12:32 -0800, Junio C Hamano wrote: I'll queue these for now, but I doubt the wisdom of this series, given that the ship has already sailed long time ago. Currently, no third-party implementation of a receiving end can accept thin push, because thin push is not a capability that needs to be checked by the current clients. People will have to wait until the clients with 2/2 patch are widely deployed before starting to use such a receiving end that is incapable of thin push. Wouldn't the world be a better place if instead they used that time waiting to help such a third-party receiving end to implement thin push support? Support in the code isn't always enough. The particular case that brought this on is one where the index-pack implementation can deal with thin packs just fine. This particular service takes the pack which the client sent and does post-processing on it to store it elsewhere. During the receive-pack equivalent, there is no git object db that it can query for the missing base objects. I realise this is pretty a unusual situation. How... odd? At Google we have made effort to ensure servers can accept thin packs, even though its clearly easier to accept non-thin, because clients in the wild already send thin packs and changing the deployed clients is harder than implementing the existing protocol. It is harder, but IMO also more correct, as thin packs are an optimisation that was added somewhat later. Not to say it shouldn't be something you should attempt to do, but it's a trade-off between the complexity of the communication between the pieces and the potential amount of extra data you're willing to put up with. The Google (Code) servers don't just support thin packs, but for upload-pack, they force it upon the client, which is quite frustrating as it won't even tell you why it closes the connection but sends a 500 instead, but that's a different story. If the server can't complete the pack, I guess this also means the client cannot immediately fetch from the server it just pushed to? Not all the details have been worked out yet, but the new history should be converted into the target format before reporting success and closing the connection. The Git frontend/protocol is one way of putting data into the system, but that's not its native data storage format. The database where this is getting stored only has very limited knowledge of git. I'll reroll the series with no-thin as mentioned elsewhere in this thread. cmn -- 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
[PATCH] send-pack: don't send a thin pack to a server which doesn't support it
Up to now git has assumed that all servers are able to fix thin
packs. This is however not always the case.
Document the 'no-thin' capability and prevent send-pack from generating
a thin pack if the server advertises it.
---
This is a re-roll of the series I sent earlier this month, switching
it around by adding the no-thin
Documentation/technical/protocol-capabilities.txt | 20 +++-
send-pack.c | 2 ++
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/Documentation/technical/protocol-capabilities.txt
b/Documentation/technical/protocol-capabilities.txt
index fd8ffa5..3a75e79 100644
--- a/Documentation/technical/protocol-capabilities.txt
+++ b/Documentation/technical/protocol-capabilities.txt
@@ -72,15 +72,25 @@ interleaved with S-R-Q.
thin-pack
-
-This capability means that the server can send a 'thin' pack, a pack
-which does not contain base objects; if those base objects are available
-on client side. Client requests 'thin-pack' capability when it
-understands how to thicken it by adding required delta bases making
-it self-contained.
+A thin pack is one with deltas which reference base objects not
+contained within the pack (but are known to exist at the receiving
+end). This can reduce the network traffic significantly, but it
+requires the receiving end to know how to thicken these packs by
+adding the missing bases to the pack.
+
+The upload-pack server advertises 'thin-pack' when it can generate and
+send a thin pack. The receive-pack server advertises 'no-thin' if
+it does not know how to thicken the pack it receives.
+
+A client requests the 'thin-pack' capability when it understands how
+to thicken it.
Client MUST NOT request 'thin-pack' capability if it cannot turn a thin
pack into a self-contained pack.
+Client MUST NOT send a thin pack if the server advertises the
+'no-thin' capability.
+
side-band, side-band-64k
diff --git a/send-pack.c b/send-pack.c
index 7d172ef..9877eb9 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -205,6 +205,8 @@ int send_pack(struct send_pack_args *args,
quiet_supported = 1;
if (server_supports(agent))
agent_supported = 1;
+ if (server_supports(no-thin))
+ args-use_thin_pack = 0;
if (!remote_refs) {
fprintf(stderr, No refs in common and none specified; doing
nothing.\n
--
1.8.5.rc3.362.gdf10213
--
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
Re: [PATCH] send-pack: don't send a thin pack to a server which doesn't support it
On Sat, 2013-11-23 at 17:07 +0100, Carlos Martín Nieto wrote:
Up to now git has assumed that all servers are able to fix thin
packs. This is however not always the case.
Document the 'no-thin' capability and prevent send-pack from generating
a thin pack if the server advertises it.
Sorry,
Signed-off-by: Carlos Martín Nieto c...@elego.de
---
This is a re-roll of the series I sent earlier this month, switching
it around by adding the no-thin
Documentation/technical/protocol-capabilities.txt | 20 +++-
send-pack.c | 2 ++
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/Documentation/technical/protocol-capabilities.txt
b/Documentation/technical/protocol-capabilities.txt
index fd8ffa5..3a75e79 100644
--- a/Documentation/technical/protocol-capabilities.txt
+++ b/Documentation/technical/protocol-capabilities.txt
@@ -72,15 +72,25 @@ interleaved with S-R-Q.
thin-pack
-
-This capability means that the server can send a 'thin' pack, a pack
-which does not contain base objects; if those base objects are available
-on client side. Client requests 'thin-pack' capability when it
-understands how to thicken it by adding required delta bases making
-it self-contained.
+A thin pack is one with deltas which reference base objects not
+contained within the pack (but are known to exist at the receiving
+end). This can reduce the network traffic significantly, but it
+requires the receiving end to know how to thicken these packs by
+adding the missing bases to the pack.
+
+The upload-pack server advertises 'thin-pack' when it can generate and
+send a thin pack. The receive-pack server advertises 'no-thin' if
+it does not know how to thicken the pack it receives.
+
+A client requests the 'thin-pack' capability when it understands how
+to thicken it.
Client MUST NOT request 'thin-pack' capability if it cannot turn a thin
pack into a self-contained pack.
+Client MUST NOT send a thin pack if the server advertises the
+'no-thin' capability.
+
side-band, side-band-64k
diff --git a/send-pack.c b/send-pack.c
index 7d172ef..9877eb9 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -205,6 +205,8 @@ int send_pack(struct send_pack_args *args,
quiet_supported = 1;
if (server_supports(agent))
agent_supported = 1;
+ if (server_supports(no-thin))
+ args-use_thin_pack = 0;
if (!remote_refs) {
fprintf(stderr, No refs in common and none specified; doing
nothing.\n
--
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
Re: [PATCH] bash prompt: add option to disable for a repository
On Sat, Nov 23, 2013 at 4:42 PM, Johannes Sixt j...@kdbg.org wrote: Gah! This adds a fork+exec each time the prompt is shown. Not good, particularly on Windows. Since your intent is to disable the prompt in the home directory, wouldn't that mean that most of the time you *don't* want the prompt? Wouldn't you be better served with a method that *turns on* the prompt? For example, a shell function that sets PS1 and another one that unsets it? Or a wrapper that inspects a shell variable and calls __git_ps1 only when you want a prompt. Actually, I do want the prompt for all other git repositories. The problem with $HOME is that it's the default directory after logging in or opening a terminal, so if you have git prompt sourced and your $HOME under git, you get an unbearable delay every time you open a terminal, or type a command, anywhere, except for a separate git repository. And I do believe I'm not the only one putting $HOME under git, so I think some kind of generic solution to this problem would be nice. If running git config on each prompt seems too expensive, do you have any better ideas? Regards, -- Heikki Hokkanen -- 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
Re: [PATCH] remote-hg: fix hg sharedpath when git clone is moved
On Sat, Nov 23, 2013 at 6:38 AM, Antoine Pelisse apeli...@gmail.com wrote: remote-hg is using a mercurial shared clone to store all remotes objects in one place. Unfortunately, the sharedpath is stored as an absolute path by mercurial, creating a dependency on the location of the git repository. Whenever the git repository is moved, the sharedpath must be updated to reflect the new absolute path. Check mercurial sharedpath file when getting the local hg repository, and update it manually with the new path if necessary. Signed-off-by: Antoine Pelisse apeli...@gmail.com https://github.com/felipec/git/commit/270e7ff91a4a34e8bc27edb6bd7d7473b886f568 -- Felipe Contreras -- 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
Re: [PATCH] remote-hg: fix hg sharedpath when git clone is moved
On Sat, Nov 23, 2013 at 5:32 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Sat, Nov 23, 2013 at 6:38 AM, Antoine Pelisse apeli...@gmail.com wrote: remote-hg is using a mercurial shared clone to store all remotes objects in one place. Unfortunately, the sharedpath is stored as an absolute path by mercurial, creating a dependency on the location of the git repository. Whenever the git repository is moved, the sharedpath must be updated to reflect the new absolute path. Check mercurial sharedpath file when getting the local hg repository, and update it manually with the new path if necessary. Signed-off-by: Antoine Pelisse apeli...@gmail.com https://github.com/felipec/git/commit/270e7ff91a4a34e8bc27edb6bd7d7473b886f568 Or that, indeed :-) -- 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
Re: [PATCH] bash prompt: add option to disable for a repository
Hi,
On Sat, Nov 23, 2013 at 03:18:23PM +0200, Heikki Hokkanen wrote:
If bash.prompt is set to false, disable the prompt. This is useful
for huge repositories like the home directory.
Signed-off-by: Heikki Hokkanen h...@users.sf.net
---
git-prompt.sh performance seems to be quite bad for big repositories,
Hm, strange. I wonder what can cause performance problems in big
repositories.
Sure, there are status indicators that can be expensive, in particular
the indicators for dirty index/worktree, untracked files, and
divergence from upstream. However, these must be enabled globally by
environment variables and even then can already be disabled on a
per-repo basis by configuration variables. And the rest of the prompt
code should perform pretty much independently from the repository
size.
so
without a way to disable it selectively for repositories, it becomes unusable
for people who have their homedir under git. This patch generalizes the
problem
a bit by allowing the prompt to be disabled by setting bash.prompt to false in
any repository.
contrib/completion/git-prompt.sh | 8
1 file changed, 8 insertions(+)
No tests.
diff --git a/contrib/completion/git-prompt.sh
b/contrib/completion/git-prompt.sh
index 7b732d2..c982fde 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -84,6 +84,8 @@
# GIT_PS1_SHOWCOLORHINTS to a nonempty value. The colors are based on
# the colored output of git status -sb and are available only when
# using __git_ps1 for PROMPT_COMMAND or precmd.
+#
+# To disable prompt for a repository, run git config bash.prompt false
# check whether printf supports -v
__git_printf_supports_v=
@@ -304,6 +306,12 @@ __git_ps1 ()
return
fi
+ local prompt_setting
+ prompt_setting=$(git config --bool bash.prompt)
I spent quite some time eliminating fork()s and exec()s from the
prompt, so a fork() for the command substitution's subshell and a
fork()+exec() for running a git command in the main code path saddens
me deeply ;)
+ if [ -n $prompt_setting ] [ $prompt_setting == false ]; then
If $prompt_setting must be false, then checking its non-emptyness is
superfluous.
+ return
You can't just return from __git_ps1(), you must update PS1 in prompt
command mode. See the few lines just above this hunk.
+ fi
+
local short_sha
if [ $rev_parse_exit_code = 0 ]; then
short_sha=${repo_info##*$'\n'}
--
1.8.4
--
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
error: git-remote-https died of signal 13
Hi, Using the latest git version (1.8.5.rc3), I get this this warning/error: sb@sb:/tmp$ git clone https://github.com/Bertram25/ValyriaTear.git Cloning into 'ValyriaTear'... remote: Counting objects: 21346, done. remote: Compressing objects: 100% (6307/6307), done. remote: Total 21346 (delta 16463), reused 19820 (delta 15000) Receiving objects: 100% (21346/21346), 176.39 MiB | 445.00 KiB/s, done. Resolving deltas: 100% (16463/16463), done. Checking connectivity... done. error: git-remote-https died of signal 13 However the repository seems to be cloned fine. I can clone different repos from github and they are working fine without the error. Would that be an issue on my side or on githubs side? Stefan -- 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
Re: Git issues with submodules
Am 22.11.2013 23:09, schrieb Jonathan Nieder: Heiko Voigt wrote: After that we can discuss whether add should add submodules that are tracked but not shown. How about commit -a ? Should it also ignore the change? I am undecided here. There does not seem to be any good decision. From the users point of view we should probably not add it since its not visible in status. What do others think? I agree --- it should not add. I concur: adding a change that is hidden from the user during the process is not a good idea. That leaves the question of how to add explicitly. git add -f? git add --ignore-submodules=none? I suspect git add and git commit -a have to learn the --ignore-submodules option anyway if we go that route. There are points in time (e.g. releasing a new version or having run an expansive test successfully) where some users want to update the submodules that are normally ignored to record the exact versions involved. -- 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
[PATCH] subtree: add squash handling for split and push
From 2763be1fe68d07af60945762178b8494228eb45f Mon Sep 17 00:00:00 2001
From: Pierre Penninckx ibizapea...@gmail.com
Date: Sat, 23 Nov 2013 20:03:20 +0100
Subject: [PATCH] subtree: add squash handling for split and push
The documentation of subtree says that the --squash option can be used
for add, merge, split and push subtree commands but only add and merge
is implemented.
cmd_push() simply forwards the --squash argument to subtree split. All
the job is done by cmd_split().
cmd_split() first lets split do it's job: finding which commits need to
be extracted. Now we remember which commit is the parent of the first
extracted commit. When this step is done, cmd_split() generates a squash
of the new commits, starting from the aforementioned parent to the last
extracted commit. This new commit's sha1 is then used for the rest of
the script.
Tests verify that `git subtree split/push --squash` makes only one
commit where `git subtree split/push` without squash makes two.
---
contrib/subtree/git-subtree.sh | 20 ++-
contrib/subtree/t/t7900-subtree.sh | 40 ++
2 files changed, 59 insertions(+), 1 deletion(-)
diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
index 7d7af03..76eb136 100755
--- a/contrib/subtree/git-subtree.sh
+++ b/contrib/subtree/git-subtree.sh
@@ -183,6 +183,7 @@ cache_set()
newrev=$2
if [ $oldrev != latest_old \
-a $oldrev != latest_new \
+-a $oldrev != firstnewparents \
-a -e $cachedir/$oldrev ]; then
die cache for $oldrev already exists!
fi
@@ -603,6 +604,10 @@ cmd_split()
debug parents: $parents
newparents=$(cache_get $parents)
debug newparents: $newparents
+ if [ -z $(cache_get firstnewparents) ]; then
+ cache_set firstnewparents $newparents
+ debug firstnewparents: $(cache_get firstnewparents)
+ fi
tree=$(subtree_for_commit $rev $dir)
debug tree is: $tree
@@ -625,11 +630,18 @@ cmd_split()
cache_set latest_new $newrev
cache_set latest_old $rev
done || exit $?
+
latest_new=$(cache_get latest_new)
if [ -z $latest_new ]; then
die No new revisions were found
fi
+ if [ -n $squash ]; then
+ from=$(cache_get firstnewparents)
+ latest_new=$(new_squash_commit $from $from $latest_new)
|| exit $?
+ debug New squash commit: $latest_new
+ fi
+
if [ -n $rejoin ]; then
debug Merging split branch into HEAD...
latest_old=$(cache_get latest_old)
@@ -711,11 +723,17 @@ cmd_push()
if [ $# -ne 2 ]; then
die You must provide repository refspec
fi
+
+ squash_cmd=
+ if [ -n $squash ]; then
+ squash_cmd=--squash
+ fi
+
if [ -e $dir ]; then
repository=$1
refspec=$2
echo git push using: $repository $refspec
- localrev=$(git subtree split --prefix=$prefix) || die
+ localrev=$(git subtree split --prefix=$prefix $squash_cmd) || die
git push $repository $localrev:refs/heads/$refspec
else
die '$dir' must already exist. Try 'git subtree add'.
diff --git a/contrib/subtree/t/t7900-subtree.sh
b/contrib/subtree/t/t7900-subtree.sh
index 66ce4b0..04eea94 100755
--- a/contrib/subtree/t/t7900-subtree.sh
+++ b/contrib/subtree/t/t7900-subtree.sh
@@ -31,6 +31,16 @@ check_equal()
fi
}
+check_not_equal()
+{
+check_equal $1 $2
+if [ $? -eq 0 ]; then
+return 1
+else
+return 0
+fi
+}
+
fixnl()
{
t=
@@ -161,6 +171,36 @@ test_expect_success 'fetch new subproj history' '
git branch sub2 FETCH_HEAD
'
+test_expect_success 'check that split and split --squash produce different
commits' '
+split=$(git subtree split --prefix=subdir)
+split_squash=$(git subtree split --prefix=subdir --squash)
+check_not_equal $split $split_squash
+'
+
+test_expect_success 'check that split and split --squash produce same diff' '
+split=$(git subtree split --prefix=subdir)
+split_squash=$(git subtree split --prefix=subdir --squash)
+split_diff=$(git diff sub1 $split)
+split_squash_diff=$(git diff sub1 $split_squash)
+check_equal $split_diff $split_squash_diff
+'
+
+test_expect_success 'check that push introduces two commits in subproj' '
+git subtree push --prefix=subdir subproj mainline
+cd subproj
+check_equal $(git rev-parse mainline~2) $(git rev-parse sub1)
+git branch -D mainline
+cd ..
+'
+
+test_expect_success 'check that push --squash introduces only one commit in
subproj' '
+git subtree push
Re: Git issues with submodules
Am 22.11.2013 22:54, schrieb Heiko Voigt: What I think needs fixing here first is that the ignore setting should not apply to any diffs between HEAD and index. IMO, it should only apply to the diff between worktree and index. Not only that. It should also apply to diffs between commits/trees and work tree but not between commits/trees. The reason the ignore setting was added three years ago was to avoid expensive work tree operations when it was clear that either the information wasn't wanted or it took too much time to determine that. And I doubt you want to see modifications to submodules in your work tree when diffing against HEAD but not when diffing against the index. And this behavior happens to be just what the floating branch model needs too. I'm not sure there isn't a use case out there that also needs to silence diff friends regarding submodule changes between commits/trees and/or index too (even though I cannot come up with one at the moment). So I propose to add worktree as another value for the ignore option - which ignores submodule modifications in the work tree - and leave all as it is. -- 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
Re: Re: Git issues with submodules
Hi,
On Sat, Nov 23, 2013 at 09:10:44PM +0100, Jens Lehmann wrote:
Am 22.11.2013 23:09, schrieb Jonathan Nieder:
Heiko Voigt wrote:
After that we can discuss whether add should add submodules that are
tracked but not shown. How about commit -a ? Should it also ignore the
change? I am undecided here. There does not seem to be any good
decision. From the users point of view we should probably not add it
since its not visible in status. What do others think?
I agree --- it should not add.
I concur: adding a change that is hidden from the user during
the process is not a good idea.
Here is a patch achieving that. Still missing a test which I will add.
Cheers Heiko
---8
Subject: [PATCH] fix 'git add' to skip submodules configured as ignored
If submodules are configured as ignore=all they are not shown by status.
Lets also ignore them when adding files to the index. This avoids that
users accidentially add ignored submodules with: git add .
We achieve this by reading the submodule config and thus correctly
initializing the infrastructure to take the ignore decision.
Signed-off-by: Heiko Voigt hvo...@hvoigt.net
---
builtin/add.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/builtin/add.c b/builtin/add.c
index 226f758..2d0d2ef 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -15,6 +15,7 @@
#include diffcore.h
#include revision.h
#include bulk-checkin.h
+#include submodule.h
static const char * const builtin_add_usage[] = {
N_(git add [options] [--] pathspec...),
@@ -378,6 +379,10 @@ static int add_config(const char *var, const char *value,
void *cb)
ignore_add_errors = git_config_bool(var, value);
return 0;
}
+
+ if (!prefixcmp(var, submodule.))
+ return parse_submodule_config_option(var, value);
+
return git_default_config(var, value, cb);
}
@@ -415,6 +420,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)
int implicit_dot = 0;
struct update_callback_data update_data;
+ gitmodules_config();
git_config(add_config, NULL);
argc = parse_options(argc, argv, prefix, builtin_add_options,
--
1.8.5.rc3.1.gbe2a8c7
--
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
Re: Re: Git issues with submodules
On Sat, Nov 23, 2013 at 09:32:45PM +0100, Jens Lehmann wrote: Am 22.11.2013 22:54, schrieb Heiko Voigt: What I think needs fixing here first is that the ignore setting should not apply to any diffs between HEAD and index. IMO, it should only apply to the diff between worktree and index. Not only that. It should also apply to diffs between commits/trees and work tree but not between commits/trees. The reason the ignore setting was added three years ago was to avoid expensive work tree operations when it was clear that either the information wasn't wanted or it took too much time to determine that. And I doubt you want to see modifications to submodules in your work tree when diffing against HEAD but not when diffing against the index. And this behavior happens to be just what the floating branch model needs too. I'm not sure there isn't a use case out there that also needs to silence diff friends regarding submodule changes between commits/trees and/or index too (even though I cannot come up with one at the moment). So I propose to add worktree as another value for the ignore option - which ignores submodule modifications in the work tree - and leave all as it is. I am not so sure about that. Only finding out what has changed (commit wise) in a submodule is expensive. Just finding out whether a submodule sha1 has changed is not expensive. Maybe we should completely stop respecting the ignore=all setting for history and diff between index and HEAD. AFAIK, we do not have any other setting that instruct git to ignore specific parts of the history unless explicitly asked for by specifying a pathspec. And I think a user should never miss by accident that something has changed in the repository. Cheers Heiko -- 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
Re: [PATCH] send-pack: don't send a thin pack to a server which doesn't support it
On Sat, Nov 23, 2013 at 05:07:55PM +0100, Carlos Martín Nieto wrote: Up to now git has assumed that all servers are able to fix thin packs. This is however not always the case. Document the 'no-thin' capability and prevent send-pack from generating a thin pack if the server advertises it. --- This is a re-roll of the series I sent earlier this month, switching it around by adding the no-thin Thanks, I think this moves in the right direction. I wonder if we want to call it no-thin-pack just for consistency with the affirmative version in upload-pack. +The upload-pack server advertises 'thin-pack' when it can generate and +send a thin pack. The receive-pack server advertises 'no-thin' if +it does not know how to thicken the pack it receives. + +A client requests the 'thin-pack' capability when it understands how +to thicken it. Client MUST NOT request 'thin-pack' capability if it cannot turn a thin pack into a self-contained pack. +Client MUST NOT send a thin pack if the server advertises the +'no-thin' capability. As somebody who participated in the discussion, I know why one is in the affirmative and one is in the negative. But I think it might help a reader of the spec to emphasize the difference, and to put the client behavior for each alongside the server behavior, like: The upload-pack server advertises 'thin-pack' when it can generate and send a thin pack. A client requests the 'thin-pack' capability when it understands how to thicken it, notifying the server that it can receive such a pack. A client MUST NOT request the 'thin-pack' capability if it cannot turn a thin pack into a self-contained pack. Receive-pack, on the other hand, is assumed by default to be able to handle thin packs, but can ask the client not to use the feature by advertising the 'no-thin' capability. A client MUST NOT send a thin pack if the server advertises the 'no-thin' capability. The reasons for this asymmetry are historical. The receive-pack program did not exist until after the invention of thin packs, so historically the reference implementation of receive-pack always understood thin packs. Adding 'no-thin' later allowed receive-pack to disable the feature in a backwards-compatible manner. -Peff -- 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
Re: error: git-remote-https died of signal 13
On Sat, Nov 23, 2013 at 05:36:36PM +0100, Stefan Beller wrote: sb@sb:/tmp$ git clone https://github.com/Bertram25/ValyriaTear.git Cloning into 'ValyriaTear'... remote: Counting objects: 21346, done. remote: Compressing objects: 100% (6307/6307), done. remote: Total 21346 (delta 16463), reused 19820 (delta 15000) Receiving objects: 100% (21346/21346), 176.39 MiB | 445.00 KiB/s, done. Resolving deltas: 100% (16463/16463), done. Checking connectivity... done. error: git-remote-https died of signal 13 However the repository seems to be cloned fine. I can clone different repos from github and they are working fine without the error. Would that be an issue on my side or on githubs side? Almost certainly on your side. 13 is SIGPIPE, so git-remote-https is trying to write something but the other side of the pipe has hung up. This might be a race condition in the transport-helper protocol, where we've had similar problems before. It doesn't reproduce here for me. Can you reproduce it consistently on this repo? I would not be at all surprised if it is intermittent. If you can reproduce, it would be interesting to see the output with GIT_TRANSPORT_HELPER_DEBUG=1, or even with strace -f. That could at least tell us what it was trying to write (and to where) when it got the SIGPIPE. -Peff -- 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
