* Re: Git clone - head not pointing to master
From: Konstantin Khomoutov @ 2011-12-30 12:40 UTC (permalink / raw)
To: Vibin Nair; +Cc: git
In-Reply-To: <4EFD9F11.5030309@volitionlabs.com>
On Fri, 30 Dec 2011 16:52:57 +0530
Vibin Nair <vibin@volitionlabs.com> wrote:
> I am a Git beginner. Recently i started working on a codebase (that
> is checked in to a git repository) of our client, who is not very
> aware about how git works.
> The repository has multiple branches such as
>
> origin/user1
> origin/master
> origin/user2
>
> Now when i take a clone of this repository : git clone <repo-url>, a
> clone of the repo is created on my machine.
>
> But when i do a : "git branch" it shows
>
> user1 *
>
> which means that the "head" is pointing to the "user1" branch.
>
> The client told me that all the recent code were being merged into
> the "master" branch and hence the "user1" branch has code which is
> older than "master" branch.
>
> I had 2 queries :
>
> 1. Is it possible to make the "head" of the remote point to "master"
> instead of "user1", so that other members of my team get the latest
> code when they try to clone the repository.
`git clone` checks out the branch which the HEAD ref in the remote repo
points to. You can use `git symbolic-ref` to retarget HEAD if it's a
bare repository. If the repository is non-bare HEAD tracks what's
checked out, so it can be changed by doing `git checkout`.
Note that you can pass the "-b <branch>" command-line option to `git
clone` to make it create a local tracking branch and check it out for
an arbitrary remote branch <branch>.
> 2. Is there any way to safely merge "user1" to "master".
This question has little sense because it heavily depends on what you
mean by "safely". The correct way to state a question like this is to
think whether merging user1 to master has sense from the project's
development standpoint.
^ permalink raw reply
* Git - server mediator
From: gruziak89 @ 2011-12-30 12:43 UTC (permalink / raw)
To: git
Hi,
We have a project on githubie. On our server is the server git (gitosi). Our
server needs to mediate in communication. namely:
People from our team clone the repository from our server. And all four
changes are sending him. When done work in the evening every day someone
comes through ssh to a server and sends on github to change once it gets (so
someone can modify the contents of githubie). We collect these changes on us
from the server.
So the question is how do pośrednczące repository that will work at all push
/ pull from github and at the same time will be from the local computer, it
should work for push / pull.
Thanks for the reply.
--
View this message in context: http://git.661346.n2.nabble.com/Git-server-mediator-tp7138036p7138036.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 2/2] git-svn, perl/Git.pm: extend and use Git->prompt method for querying users
From: Jeff King @ 2011-12-30 13:54 UTC (permalink / raw)
To: Sven Strickroth; +Cc: git, Junio C Hamano, Jakub Narebski
In-Reply-To: <4EFD40CF.8000801@tu-clausthal.de>
On Fri, Dec 30, 2011 at 05:40:47AM +0100, Sven Strickroth wrote:
> >> git-core also asks for username using *_ASKPASS, this is the reason why
> >> I implemented it this way. I noticed it when I tried to push to google
> >> code (using https).
> >
> > I thought that was updated with Peff's series recently?
>
> So, was this changed? git-core doesn't ask for a username using
> *_ASKPASS helpers anymore?
No, it will. It's only that we will echo characters when using the
terminal prompt. In theory we could have an ASKPASS-style interface that
would would echo characters, but there's no such interface in common
use (i.e., we would have to invent it).
> I talked off-list with Junio and he proposed to use another environment
> variable (e.g. GIT_DIALOG for a different tool) to solve these issues.
>
> A good way could be to define the GIT_DIALOG-tools to have two
> parameters. First (pass|text|filename|...) with fallback to text, this
> way one can implement a password field, a text field, a file chooser (on
> type filename) and it is still extendable for e.g. directory choosers
> (if we might need that)...
Yes, like that. I think some windowing toolkits already have programs to
provide dialogs from shell scripts. You might look at them for
inspiration on the interface.
For credentials, it would be nice to be able to create a multi-field
dialog, like:
Username: <text input>
Password: <text input>
Remember password? [checkbox]
I was planning to do something custom for credentials as an extension to
the credential helper protocol, but this could also fall under the
heading of a general prompt helper.
-Peff
^ permalink raw reply
* Re: What's the best way to push/fetch replace refs?
From: Christian Couder @ 2011-12-30 14:51 UTC (permalink / raw)
To: Slawomir Testowy; +Cc: git
In-Reply-To: <CAA61mJgCjt0O5LE5OQ=aNbtUHCZeZdZ=3dXYTNv_AhFi7JXwkA@mail.gmail.com>
On Fri, Dec 30, 2011 at 12:59 PM, Slawomir Testowy
<slawomir.testowy@gmail.com> wrote:
>
> # I also added "fetch = +refs/replace/*:refs/replace/*" to [remote
> "origin"] in "b" and this also seems to work.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Yeah, the simplest is probably to just add "fetch =
+refs/replace/*:refs/replace/*" to the remote(s) you want to get the
replace refs from, and "push = +refs/replace/*:refs/replace/*" to the
remote(s) you want to push the replace refs to.
Regards,
Christian.
^ permalink raw reply
* Re: [PATCH 2/2] git-svn, perl/Git.pm: extend and use Git->prompt method for querying users
From: Sven Strickroth @ 2011-12-30 14:53 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano, Jakub Narebski
In-Reply-To: <20111230135423.GA1684@sigill.intra.peff.net>
Am 30.12.2011 14:54 schrieb Jeff King:
>>> I thought that was updated with Peff's series recently?
>>
>> So, was this changed? git-core doesn't ask for a username using
>> *_ASKPASS helpers anymore?
>
> No, it will. It's only that we will echo characters when using the
> terminal prompt. In theory we could have an ASKPASS-style interface that
> would would echo characters, but there's no such interface in common
> use (i.e., we would have to invent it).
I also updated the _ASKPASS helper of TortoiseGit so that it only shows
asterisks if "pass" is not contained in the prompt.
> For credentials, it would be nice to be able to create a multi-field
> dialog, like:
>
> Username: <text input>
> Password: <text input>
> Remember password? [checkbox]
>
> I was planning to do something custom for credentials as an extension to
> the credential helper protocol, but this could also fall under the
> heading of a general prompt helper.
This might be problematic, because (for git-svn) username and password
are not requested together.
--
Best regards,
Sven Strickroth
ClamAV, a GPL anti-virus toolkit http://www.clamav.net
PGP key id F5A9D4C4 @ any key-server
^ permalink raw reply
* Re: [PATCH 1/3] expanded hook api with stdio support
From: Joey Hess @ 2011-12-30 17:13 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4EFD88CB.3050403@kdbg.org>
[-- Attachment #1: Type: text/plain, Size: 3162 bytes --]
Johannes Sixt wrote:
> IMHO, this is overengineered. I don't think that we need something like
> this in the foreseeable future, particularly because such a pipeline or
> multi-hook infrastructure can easily be constructed by the (single) hook
> script itself.
Junio seemed to think this was a good direction to move in and gave some
examples in <7vlipz930t.fsf@alter.siamese.dyndns.org>
Anyway, the minimum cases for run_hook_complex() to support are:
* no stdin, no stdout
* only stdin
* stdin and stdout (needed for tweak-fetch)
* only stdout (perhaps)
The generator and reader members of struct hook allow the caller to
easily specify which of these cases applies to a hook, and also provides
a natural separation of the caller's stdin generation and stdout parsing
code.
That leaves the feeder and data members of struct hook as possible
overengineering. See below regarding the feeder. The data member could
be eliminated and global variables used by callers that need that,
but I prefer designs that don't require global variables.
> > +`run_hook_complex`::
> > +
> > + Run a hook, with the caller providing its stdin and/or parsing its
> > + stdout.
> > + Takes a pointer to a `struct hook` that specifies the details,
> > + including the name of the hook, any parameters to pass to it,
> > + and how to handle the stdin and stdout. (See below.)
> > + If the hook does not exist or is not executable, the return value
> > + will be zero.
> > + If it is executable, the hook will be executed and the exit
> > + status of the hook is returned.
>
> What is the rationale for these error modes? It is as if a non-existent
> or non-executable hook counts as 'success'. (I'm not saying that this
> would be wrong, I'm just asking.)
They are identical to how run_hook already works.
A non-existant/non-executable hook *is* a valid configuration,
indeed it's the most likely configuration.
> > +/* A feeder that ensures the hook consumes all its stdin. */
> > +int feed_hook_in_full(int handle, struct strbuf *buf, struct hook *hook)
> > +{
> > + if (write_in_full(handle, buf->buf, buf->len) != buf->len) {
> > + warning("%s hook failed to consume all its input", hook->name);
>
> Really? Could there not be any other error condition? The warning would
> be correct only if errno == EPIPE, and this error will be returned only
> if SIGPIPE is ignored. Does this happen anywhere?
>
> Futhermore, if all data was written to the pipe successfully, there is
> no way to know whether the reader consumed everything.
>
> IOW, I don't it is worth to make the distinction. However, I do think
> that the parent process must be protected against SIGPIPE.
Yes, this was not thought through, I missed that a write to a pipe can
succeed (due to buffering) despite not being fully consumed.
Dealing with the hook SIGPIPE issue is complicated as Jeff explains in
<20111205214351.GA15029@sigill.intra.peff.net>, and I don't feel I'm the
one to do it. I'm feeling like ripping the "feeder" stuff out of my
patch, and not having my patch change the status quo on this issue.
--
see shy jo
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] expanded hook api with stdio support
From: Johannes Sixt @ 2011-12-30 18:04 UTC (permalink / raw)
To: Joey Hess; +Cc: git
In-Reply-To: <20111230171344.GA9667@gnu.kitenet.net>
Am 30.12.2011 18:13, schrieb Joey Hess:
> Johannes Sixt wrote:
>> IMHO, this is overengineered. I don't think that we need something like
>> this in the foreseeable future, particularly because such a pipeline or
>> multi-hook infrastructure can easily be constructed by the (single) hook
>> script itself.
>
> Junio seemed to think this was a good direction to move in and gave some
> examples in <7vlipz930t.fsf@alter.siamese.dyndns.org>
>
> Anyway, the minimum cases for run_hook_complex() to support are:
>
> * no stdin, no stdout
> * only stdin
> * stdin and stdout (needed for tweak-fetch)
> * only stdout (perhaps)
>
> The generator and reader members of struct hook allow the caller to
> easily specify which of these cases applies to a hook, and also provides
> a natural separation of the caller's stdin generation and stdout parsing
> code.
But as long as the generator only needs to generate a strbuf *and* only
one hook is run, there is no value to have it as a callback; the caller
can just specify the strbuf itself, run_hook_* does not need to care how
it was generated.
I can see some value in a reader callback to avoid allocating yet
another strbuf.
> ... The data member could
> be eliminated and global variables used by callers that need that,
> but I prefer designs that don't require global variables.
Absolutely.
>>> + If the hook does not exist or is not executable, the return value
>>> + will be zero.
>>> + If it is executable, the hook will be executed and the exit
>>> + status of the hook is returned.
>>
>> What is the rationale for these error modes? It is as if a non-existent
>> or non-executable hook counts as 'success'. (I'm not saying that this
>> would be wrong, I'm just asking.)
>
> They are identical to how run_hook already works.
> A non-existant/non-executable hook *is* a valid configuration,
> indeed it's the most likely configuration.
So, it is so that the caller does not itself have to check whether a
hook exists. That may be worth a word in the API documentation.
-- Hannes
^ permalink raw reply
* Re: Git clone - head not pointing to master
From: Jakub Narebski @ 2011-12-30 18:45 UTC (permalink / raw)
To: Vibin Nair; +Cc: git
In-Reply-To: <4EFD9F11.5030309@volitionlabs.com>
Vibin Nair <vibin@volitionlabs.com> writes:
> Hi,
> I am a Git beginner. Recently i started working on a codebase (that
> is checked in to a git repository) of our client, who is not very
> aware about how git works.
> The repository has multiple branches such as
>
> origin/user1
> origin/master
> origin/user2
>
> Now when i take a clone of this repository : git clone <repo-url>, a
> clone of the repo is created on my machine.
>
> But when i do a : "git branch" it shows
>
> user1 *
>
> which means that the "HEAD" is pointing to the "user1" branch.
Where do you do "git branch"? In clone or in original repository?
> The client told me that all the recent code were being merged into the
> "master" branch and hence the "user1" branch has code which is older
> than "master" branch.
>
> I had 2 queries :
>
> 1. Is it possible to make the "HEAD" of the remote point to "master"
> instead of "user1", so that other members of my team get the latest
> code when they try to clone the repository.
If you want "origin/HEAD" to point to "origin/master" remote-tracking
branch, so that "origin" as a branch means "origin/master", you can
use (with modern Git)
clone$ git remote set-head origin master
or
clone$ git remote set-head origin
if "master" is now current branch on remote.
If you want to change HEAD i.e. current branch on server (on remote),
you can use
server$ git checkout master
if it is non-bare repository (not recommended setup), or
server$ git symbolic-ref HEAD refs/heads/master
or equivalently
server$ git update-ref --no-deref HEAD refs/heads/master
> 2. Is there any way to safely merge "user1" to "master".
You can check if 'user1' can be fast-forwarded to 'master'
with
$ git checkout user1
$ git merge --ff-only master
This would update 'user1' to 'master', but only if 'master' is just
straight advancement of 'user1'.
HTH (Hope That Helps).
--
Jakub Narebski
^ permalink raw reply
* 1.7.7.3 wishlist: add --verbose option to git-tag
From: Jari Aalto @ 2011-12-30 23:32 UTC (permalink / raw)
To: git
In scripts it would be useful if "git tag" would provide option:
--verbose
As in script:
git tag --verbose -m "Initial import" upstream/1.0
It would also help if all commands would use similar interface. In "git
tag" case, this would meen relocating:
-v => -g, --verify-gpg
And reserve these:
-v, --verbose
Jari
^ permalink raw reply
* Re: [PATCH] stash: Don't fail if work dir contains file named 'HEAD'
From: Jonathon Mah @ 2011-12-31 0:01 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Junio C Hamano
In-Reply-To: <8739c28iwh.fsf@thomas.inf.ethz.ch>
Thanks for the feedback, Thomas. I should note, this bug initially came up on #git several days ago.
I've tried to take on all your suggestions; patch v2 imminent.
On 2011-12-30, at 02:15, Thomas Rast wrote:
> Jonathon Mah <me@JonathonMah.com> writes:
>> diff --git a/t/t3904-stash-patch.sh b/t/t3904-stash-patch.sh
> [...]
>
> Other reviewers may want to read these hunks in word diff mode, where it
> is far easier to verify that the functionality tested is a superset:
>
> test_expect_success PERL 'saying "n" does nothing' '
> {+set_state HEAD HEADfile_work HEADfile_index &&+}
> set_state dir/foo work index &&
> (echo n; echo {+n; echo+} n) | test_must_fail git stash save -p &&
> verify_state [-dir/foo work index-]{+HEAD HEADfile_work HEADfile_index+} &&
> verify_saved_state bar {+&&+}
> {+ verify_state dir/foo work index+}
> '
I added a note to the message: In t3904, checks and operations on each file are in the order they'll appear when interactively staging.
That is, "echo y/n; echo y/n; ..." for the three files corresponds to the surrounding checks.
Jonathon Mah
me@JonathonMah.com
^ permalink raw reply
* [PATCHv2] stash: Don't fail if work dir contains file named 'HEAD'
From: Jonathon Mah @ 2011-12-31 0:14 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Thomas Rast
When performing a plain "git stash" (without --patch), git-diff would fail
with "fatal: ambiguous argument 'HEAD': both revision and filename". The
output was piped into git-update-index, masking the failed exit status.
The output is now sent to a temporary file (which is cleaned up by
existing code), and the exit status is checked. The "HEAD" arg to the
git-diff invocation has been disambiguated too, of course.
In patch mode, "git stash -p" would fail harmlessly, leaving the working
dir untouched. Interactive adding is fine, but the resulting tree was
diffed with an ambiguous 'HEAD' argument.
Use >foo (no space) when redirecting output.
In t3904, checks and operations on each file are in the order they'll
appear when interactively staging.
In t3905, fix a bug in "stash save --include-untracked -q is quiet": The
redirected stdout file was considered untracked, and so was removed from
the working directory. Use test path helper functions where appropriate.
Signed-off-by: Jonathon Mah <me@JonathonMah.com>
Acked-by: Thomas Rast <trast@student.ethz.ch>
---
Also contains several fixes / changes for tests. Let me know if these
would better belong separately.
git-stash.sh | 7 +++--
t/t3903-stash.sh | 24 ++++++++++++++++++
t/t3904-stash-patch.sh | 47 ++++++++++++++++++++++-------------
t/t3905-stash-include-untracked.sh | 33 +++++++++++++++++-------
4 files changed, 80 insertions(+), 31 deletions(-)
diff --git a/git-stash.sh b/git-stash.sh
index c766692..fe4ab28 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -115,7 +115,8 @@ create_stash () {
git read-tree --index-output="$TMPindex" -m $i_tree &&
GIT_INDEX_FILE="$TMPindex" &&
export GIT_INDEX_FILE &&
- git diff --name-only -z HEAD | git update-index -z --add --remove --stdin &&
+ git diff --name-only -z HEAD -- >"$TMP-stagenames" &&
+ git update-index -z --add --remove --stdin <"$TMP-stagenames" &&
git write-tree &&
rm -f "$TMPindex"
) ) ||
@@ -134,7 +135,7 @@ create_stash () {
w_tree=$(GIT_INDEX_FILE="$TMP-index" git write-tree) ||
die "$(gettext "Cannot save the current worktree state")"
- git diff-tree -p HEAD $w_tree > "$TMP-patch" &&
+ git diff-tree -p HEAD $w_tree -- >"$TMP-patch" &&
test -s "$TMP-patch" ||
die "$(gettext "No changes selected")"
@@ -491,7 +492,7 @@ drop_stash () {
die "$(eval_gettext "\${REV}: Could not drop stash entry")"
# clear_stash if we just dropped the last stash entry
- git rev-parse --verify "$ref_stash@{0}" > /dev/null 2>&1 || clear_stash
+ git rev-parse --verify "$ref_stash@{0}" >/dev/null 2>&1 || clear_stash
}
apply_to_branch () {
diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index fcdb182..dbe2ac1 100755
--- a/t/t3903-stash.sh
+++ b/t/t3903-stash.sh
@@ -601,4 +601,28 @@ test_expect_success 'stash apply shows status same as git status (relative to cu
test_cmp expect actual
'
+cat > expect << EOF
+diff --git a/HEAD b/HEAD
+new file mode 100644
+index 0000000..fe0cbee
+--- /dev/null
++++ b/HEAD
+@@ -0,0 +1 @@
++file-not-a-ref
+EOF
+
+test_expect_success 'stash where working directory contains "HEAD" file' '
+ git stash clear &&
+ git reset --hard &&
+ echo file-not-a-ref > HEAD &&
+ git add HEAD &&
+ test_tick &&
+ git stash &&
+ git diff-files --quiet &&
+ git diff-index --cached --quiet HEAD &&
+ test "$(git rev-parse stash^)" = "$(git rev-parse HEAD)" &&
+ git diff stash^..stash > output &&
+ test_cmp output expect
+'
+
test_done
diff --git a/t/t3904-stash-patch.sh b/t/t3904-stash-patch.sh
index 781fd71..70655c1 100755
--- a/t/t3904-stash-patch.sh
+++ b/t/t3904-stash-patch.sh
@@ -7,7 +7,8 @@ test_expect_success PERL 'setup' '
mkdir dir &&
echo parent > dir/foo &&
echo dummy > bar &&
- git add bar dir/foo &&
+ echo committed > HEAD &&
+ git add bar dir/foo HEAD &&
git commit -m initial &&
test_tick &&
test_commit second dir/foo head &&
@@ -17,47 +18,57 @@ test_expect_success PERL 'setup' '
save_head
'
-# note: bar sorts before dir, so the first 'n' is always to skip 'bar'
+# note: order of files with unstaged changes: HEAD bar dir/foo
test_expect_success PERL 'saying "n" does nothing' '
+ set_state HEAD HEADfile_work HEADfile_index &&
set_state dir/foo work index &&
- (echo n; echo n) | test_must_fail git stash save -p &&
- verify_state dir/foo work index &&
- verify_saved_state bar
+ (echo n; echo n; echo n) | test_must_fail git stash save -p &&
+ verify_state HEAD HEADfile_work HEADfile_index &&
+ verify_saved_state bar &&
+ verify_state dir/foo work index
'
test_expect_success PERL 'git stash -p' '
- (echo n; echo y) | git stash save -p &&
- verify_state dir/foo head index &&
+ (echo y; echo n; echo y) | git stash save -p &&
+ verify_state HEAD committed HEADfile_index &&
verify_saved_state bar &&
+ verify_state dir/foo head index &&
git reset --hard &&
git stash apply &&
- verify_state dir/foo work head &&
- verify_state bar dummy dummy
+ verify_state HEAD HEADfile_work committed &&
+ verify_state bar dummy dummy &&
+ verify_state dir/foo work head
'
test_expect_success PERL 'git stash -p --no-keep-index' '
- set_state dir/foo work index &&
+ set_state HEAD HEADfile_work HEADfile_index &&
set_state bar bar_work bar_index &&
- (echo n; echo y) | git stash save -p --no-keep-index &&
- verify_state dir/foo head head &&
+ set_state dir/foo work index &&
+ (echo y; echo n; echo y) | git stash save -p --no-keep-index &&
+ verify_state HEAD committed committed &&
verify_state bar bar_work dummy &&
+ verify_state dir/foo head head &&
git reset --hard &&
git stash apply --index &&
- verify_state dir/foo work index &&
- verify_state bar dummy bar_index
+ verify_state HEAD HEADfile_work HEADfile_index &&
+ verify_state bar dummy bar_index &&
+ verify_state dir/foo work index
'
test_expect_success PERL 'git stash --no-keep-index -p' '
- set_state dir/foo work index &&
+ set_state HEAD HEADfile_work HEADfile_index &&
set_state bar bar_work bar_index &&
- (echo n; echo y) | git stash save --no-keep-index -p &&
+ set_state dir/foo work index &&
+ (echo y; echo n; echo y) | git stash save --no-keep-index -p &&
+ verify_state HEAD committed committed &&
verify_state dir/foo head head &&
verify_state bar bar_work dummy &&
git reset --hard &&
git stash apply --index &&
- verify_state dir/foo work index &&
- verify_state bar dummy bar_index
+ verify_state HEAD HEADfile_work HEADfile_index &&
+ verify_state bar dummy bar_index &&
+ verify_state dir/foo work index
'
test_expect_success PERL 'none of this moved HEAD' '
diff --git a/t/t3905-stash-include-untracked.sh b/t/t3905-stash-include-untracked.sh
index ef44fb2..a5e7e6b 100755
--- a/t/t3905-stash-include-untracked.sh
+++ b/t/t3905-stash-include-untracked.sh
@@ -17,6 +17,7 @@ test_expect_success 'stash save --include-untracked some dirty working directory
echo 3 > file &&
test_tick &&
echo 1 > file2 &&
+ echo 1 > HEAD &&
mkdir untracked &&
echo untracked >untracked/untracked &&
git stash --include-untracked &&
@@ -35,6 +36,13 @@ test_expect_success 'stash save --include-untracked cleaned the untracked files'
'
cat > expect.diff <<EOF
+diff --git a/HEAD b/HEAD
+new file mode 100644
+index 0000000..d00491f
+--- /dev/null
++++ b/HEAD
+@@ -0,0 +1 @@
++1
diff --git a/file2 b/file2
new file mode 100644
index 0000000..d00491f
@@ -51,14 +59,16 @@ index 0000000..5a72eb2
+untracked
EOF
cat > expect.lstree <<EOF
+HEAD
file2
untracked
EOF
test_expect_success 'stash save --include-untracked stashed the untracked files' '
- test "!" -f file2 &&
- test ! -e untracked &&
- git diff HEAD stash^3 -- file2 untracked >actual &&
+ test_path_is_missing file2 &&
+ test_path_is_missing untracked &&
+ test_path_is_missing HEAD &&
+ git diff HEAD stash^3 -- HEAD file2 untracked >actual &&
test_cmp expect.diff actual &&
git ls-tree --name-only stash^3: >actual &&
test_cmp expect.lstree actual
@@ -75,6 +85,7 @@ git clean --force --quiet
cat > expect <<EOF
M file
+?? HEAD
?? actual
?? expect
?? file2
@@ -116,10 +127,12 @@ test_expect_success 'stash save --include-untracked dirty index got stashed' '
git reset > /dev/null
+# Must direct output somewhere where it won't be considered an untracked file
test_expect_success 'stash save --include-untracked -q is quiet' '
echo 1 > file5 &&
- git stash save --include-untracked --quiet > output.out 2>&1 &&
- test ! -s output.out
+ git stash save --include-untracked --quiet > .git/stash-output.out 2>&1 &&
+ test_line_count = 0 .git/stash-output.out &&
+ rm -f .git/stash-output.out
'
test_expect_success 'stash save --include-untracked removed files' '
@@ -133,7 +146,7 @@ rm -f expect
test_expect_success 'stash save --include-untracked removed files got stashed' '
git stash pop &&
- test ! -f file
+ test_path_is_missing file
'
cat > .gitignore <<EOF
@@ -155,14 +168,14 @@ test_expect_success 'stash save --include-untracked respects .gitignore' '
test_expect_success 'stash save -u can stash with only untracked files different' '
echo 4 > file4 &&
git stash -u &&
- test "!" -f file4
+ test_path_is_missing file4
'
test_expect_success 'stash save --all does not respect .gitignore' '
git stash -a &&
- test "!" -f ignored &&
- test "!" -e ignored.d &&
- test "!" -f .gitignore
+ test_path_is_missing ignored &&
+ test_path_is_missing ignored.d &&
+ test_path_is_missing .gitignore
'
test_expect_success 'stash save --all is stash poppable' '
--
1.7.8
Jonathon Mah
me@JonathonMah.com
^ permalink raw reply related
* [PATCH] Documentation: read-tree --prefix works with existing subtrees
From: Clemens Buchacher @ 2011-12-31 11:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Since 34110cd4 (Make 'unpack_trees()' have a separate source and
destination index) it is no longer true that a subdirectory with
the same prefix must not exist.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
---
Documentation/git-read-tree.txt | 9 ++++-----
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-read-tree.txt b/Documentation/git-read-tree.txt
index 5375549..a43e874 100644
--- a/Documentation/git-read-tree.txt
+++ b/Documentation/git-read-tree.txt
@@ -83,11 +83,10 @@ OPTIONS
--prefix=<prefix>/::
Keep the current index contents, and read the contents
- of the named tree-ish under the directory at `<prefix>`. The
- original index file cannot have anything at the path
- `<prefix>` itself, nor anything in the `<prefix>/`
- directory. Note that the `<prefix>/` value must end
- with a slash.
+ of the named tree-ish under the directory at `<prefix>`.
+ The command will refuse to overwrite entries that already
+ existed in the original index file. Note that the `<prefix>/`
+ value must end with a slash.
--exclude-per-directory=<gitignore>::
When running the command with `-u` and `-m` options, the
--
1.7.8
^ permalink raw reply related
* [PATCH] Work around sed portability issue in t8006-blame-textconv
From: Ben Walton @ 2011-12-31 13:44 UTC (permalink / raw)
To: git, gitster; +Cc: Ben Walton
In test 'blame --textconv with local changes' of t8006-blame-textconv,
using /usr/xpg4/bin/sed on Solaris as set by SANE_TOOL_PATH, an
additional newline was added to the output from the 'helper' script
driven by git attributes.
This was noted by sed with a message such as:
sed: Missing newline at end of file zero.bin.
In turn, this was triggering a fatal error from git blame:
fatal: unable to read files to diff
The git blame --textconv stdout was empty as a result of the error
condition above. This caused the test to fail because the output
value differed from the expected result.
Use perl -p -e instead of sed -e to work around this portability issue
as it will not insert the newline. This allows the git blame call to
complete at which point the output comparison is successful.
Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
---
t/t8006-blame-textconv.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t8006-blame-textconv.sh b/t/t8006-blame-textconv.sh
index 4ee42f1..c3c22f7 100755
--- a/t/t8006-blame-textconv.sh
+++ b/t/t8006-blame-textconv.sh
@@ -10,7 +10,7 @@ find_blame() {
cat >helper <<'EOF'
#!/bin/sh
grep -q '^bin: ' "$1" || { echo "E: $1 is not \"binary\" file" 1>&2; exit 1; }
-sed 's/^bin: /converted: /' "$1"
+perl -p -e 's/^bin: /converted: /' "$1"
EOF
chmod +x helper
--
1.7.4.1
^ permalink raw reply related
* How to deal with historic tar-balls
From: nn6eumtr @ 2011-12-31 19:04 UTC (permalink / raw)
To: git
I have a number of older projects that I want to bring into a git
repository. They predate a lot of the popular scm systems, so they are
primarily a collection of tarballs today.
I'm fairly new to git so I have a couple questions related to this:
- What is the best approach for bringing them in? Do I just create a
repository, then unpack the files, commit them, clean out the directory
unpack the next tarball, and repeat until everything is loaded?
- Do I need to pay special attention to files that are renamed/removed
from version to version?
- If the timestamps change on a file but the actual content does not,
will git treat it as a non-change once it realizes the content hasn't
changed?
- Last, if after loading the repository I find another version of the
files that predates those I've loaded, or are intermediate between two
commits I've already loaded, is there a way to go say that commit B is
actually the ancestor of commit C? (i.e. a->c becomes a->b->c if you
were to visualize the commit timeline or do diffs) Or do I just reload
the tarballs in order to achieve this?
All replies appreciated!
^ permalink raw reply
* Re: [PATCH] Submodules always use a relative path to gitdir
From: Phil Hord @ 2011-12-31 20:31 UTC (permalink / raw)
To: Antony Male; +Cc: git, gitster, iveqy
In-Reply-To: <1325192426-10103-1-git-send-email-antony.male@gmail.com>
On Thu, Dec 29, 2011 at 4:00 PM, Antony Male <antony.male@gmail.com> wrote:
> This fixes a problem where moving a git repository with checked-out
> submodules would cause a fatal error when commands such as 'git
> submodule update' were run.
Thanks. I noticed this itch when looking at git-files a few months
ago. It bothered me, but not enough to fix it; just enough to note
it as a problem area to avoid in the future.
> An alternative patch would teach git-clone an option to control whether
> an absolute or relative path is used when --separate-git-dir is passed.
I think I like this option better. Did you look at what it would take?
Phil
^ permalink raw reply
* Re: [PATCH] Submodules always use a relative path to gitdir
From: Phil Hord @ 2011-12-31 21:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Antony Male, git, iveqy
In-Reply-To: <7vsjk3vw67.fsf@alter.siamese.dyndns.org>
On Thu, Dec 29, 2011 at 5:40 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Antony Male <antony.male@gmail.com> writes:
>
>> Git submoule clone uses git clone --separate-git-dir to checkout a
>> submodule's git repository into <supermodule>/.git/modules,...
>
> This is misleading. The <superproject>/.git/modules/<name> is the location
> of the $GIT_DIR for the submodule <name>, not the location of its checkout
> at <superproject>/<path> that is outside <superproject>/.git/modules/
> hierarchy.
Yes, so I think a simple s/checkout/clone/ should fix it.
[...]
>> In the submodules scenario, neither the git repository nor the working
>> copy will be moved relative to each other. However, the supermodule may
>> be moved,...
>
> Again, who said that you are allowed to move the superproject directory in
> the first place? I would understand that it might be nicer if it could be
> moved but I haven't thought this through thoroughly yet---there may be
> other side effects from doing so, other than the relativeness of "gitdir".
Previously it was accepted practice to clone a local repo with rsync.
This method continues to work well even with submodules before
git-files became the norm. But now it breaks because of the absolute
paths.
Similarly, clones on network mounts and portable drives where absolute
paths may change from time to time or machine to machine will also
break now but worked before.
So, who said you were NOT allowed to move the superproject directory
directory in the first place? It seems natural that you should be
able to do so, especially since the submodules are all contained
within the superproject path.
>> Previously, if git submodule clone was called when the submodule's git
>> repository already existed in <supermodule>/.git/modules, it would
>> simply re-create the submodule's .git file, using a relative path.
>
> ... "to point at the existing <superproject>/.git/modules/<name>".
>
> Overall, I think I can agree with the goal, but the tone of the proposed
> commit log message rubs the reader in a wrong way to see clearly what this
> patch is proposing to do and where its merit lies. It is probably not a
> big deal, and perhaps it may be just the order of explanation.
>
> I would probably explain the goal like this if I were doing this patch,
> without triggering any need for revisionist history bias.
>
> Recent versions of "git submodule" maintain the submodule <name> at
> <path> in the superproject using a "separate git-dir" mechanism. The
> repository data for the submodule is stored in ".git/modules/<name>/"
> directory of the superproject, and its working tree is created at
> "<path>/" directory, with "<path>/.git" file pointing at the
> ".git/modules/<name>/" directory.
>
> This is so that we can check out an older version of the superproject
> that does not yet have the submodule <name> anywhere without losing
> (and later having to re-clone) the submodule repository. Removing
Revisionism nit: the real danger here is that you lose local commits.
> "<path>" won't lose ".git/modules/<name>", and a different branch that
> has the submodule at different location in the superproject, say
> "<path2>", can create "<path2>/" and ".git" in it to point at the same
> ".git/modules/<name>".
This doesn't explain why one path is absolute and one is relative.
But I don't suppose this is the place for historical documentation
anyway.
> When instantiating such a submodule, if ".git/modules/<name>/" does
> not exist in the superproject, the submodule repository needs to be
> cloned there first. Then we only need to create "<path>" directory,
> point ".git/modules/<name>/" in the superproject with "<path>/.git",
> and check out the working tree.
>
> However, the current code is not structured that way. The codepath to
> deal with newly cloned submodules uses "git clone --separate-git-dir"
> and creates "<path>" and "<path>/.git". This can make the resulting
> submodule working tree at "<path>" different from the codepath for
> existing submodules. An example of such differences is that this
> codepath prepares "<path>/.git" with an absolute path, while the
> normal codepath uses a relative path.
I had to read this three times before I understood it. There are some
minor grammatical nits in it, but also the use of nearness and use of
"path" and "codepath" to mean two unrelated things was misleading me.
Here's my attempt to clean it up:
However, the current code is not structured that way. The code to
deal with newly cloned submodules is different from the code to
checkout a workdir for existing submodules. The "newly cloned
submodule" code uses "git clone --separate-git-dir" to create
"<path>" and "<path>/.git". The "existing submodules" code
simply creates the "<path>/.git" internally, using a relative path.
This makes the resulting submodule working tree at "<path>" different
depending on which code is used. An example of such differences
is that the "newly cloned submodule" code prepares "<path>/.git"
with an absolute path, while the "existing submodules" code
prepares the same file using a relative path.
> When explained this way, the remedy is quite clear, and the change is more
> forward-looking, isn't it? If we later start doing more in the codepath
> to deal with existing submodules, your patch may break without having
> extra code to cover the "newly cloned" case, too.
> I further wonder if we can get away without using separate-git-dir option
> in this codepath, though. IOW using
>
> git clone $quiet -bare ${reference:+"$reference"} "$url" "$gitdir"
>
> might be a better solution.
You may be right about this one. I still think the addition of a
--relative-path option to 'git-checkout --separate-work-dir' could be
useful and also easier to maintain/describe.
> For example (this relates to the point I mumbled "haven't thought this
> through thoroughly yet"), doesn't the newly cloned repository have
> core.worktree that points at the working tree that records the <path>,
> which would become meaningless when a commit in the superproject that
> binds the submodule at different path <path2>?
Ooh, yes it does. Maybe that should be fixed in this case too.
Because submodule cloning with a separate work-dir is a special case
of git-files and work-dirs because we know that each is relative
(subordinate) to the superproject path. Therefore, I think in this
special-case version of the "separate work-dir" scenario, we should
use super-project-relative paths for both cases.
How do we codify this so this functionality is reliably retained by
future developers? I think moving the code into someplace more
explicit would help, but I haven't looked too deeply at the code.
> git-submodule.sh | 21 ++++++++-------------
> 1 files changed, 8 insertions(+), 13 deletions(-)
>
> diff --git a/git-submodule.sh b/git-submodule.sh
> index 3adab93..9a23e9d 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -156,21 +156,16 @@ module_clone()
> ;;
> esac
>
> - if test -d "$gitdir"
> + if ! test -d "$gitdir"
> then
> - mkdir -p "$path"
> - echo "gitdir: $rel_gitdir" >"$path/.git"
> - rm -f "$gitdir/index"
> - else
> - mkdir -p "$gitdir_base"
> - if test -n "$reference"
> - then
> - git-clone $quiet "$reference" -n "$url" "$path" --separate-git-dir "$gitdir"
> - else
> - git-clone $quiet -n "$url" "$path" --separate-git-dir "$gitdir"
> - fi ||
> - die "$(eval_gettext "Clone of '\$url' into submodule path '\$path' failed")"
> + git clone $quiet -n ${reference:+"$reference"} \
> + --separate-git-dir "$gitdir" "$url" "$path" ||
> + die "$(eval_gettext "Clone of '\$url' for submodule '\$name' failed")
> fi
> +
> + mkdir -p "$path"
> + echo "gitdir: $rel_gitdir" >"$path/.git"
> + rm -f "$gitdir/index"
> }
Doesn't this avoid creating core.worktree in the first place? I'm ok
with that because I assume it's never used in the submodule scenario,
but I also suspect that assumption could be wrong. Any concerns?
Phil
^ permalink raw reply
* Re: git alias question
From: Michael Horowitz @ 2011-12-31 21:31 UTC (permalink / raw)
To: David Aguilar; +Cc: Dave Borowitz, git, Junio C Hamano
In-Reply-To: <CAJDDKr5a8TB82h4ULWtamLOVu_4Fv+cGw1YfEL987gM3yM4TMg@mail.gmail.com>
The log operation does seem to make the most sense as the mechanism to
search for the results. Making it work with difftool would work...
Not sure if "--log" to difftool or some other options as suggested in
the other thread would be most consistent UI-wise as stated, but
either would work for me.
On a separate note, some environment variable like GIT_PREFIX with the
CWD would make the alias functionality more flexible.
Mike
On Thu, Dec 29, 2011 at 8:59 PM, David Aguilar <davvid@gmail.com> wrote:
>
> On Thu, Dec 29, 2011 at 9:08 AM, Dave Borowitz <dborowitz@google.com> wrote:
> > On Wed, Dec 28, 2011 at 17:27, Michael Horowitz
> > <michael.horowitz@ieee.org> wrote:
> >> ldiff = "!git diff `git rev-list --reverse -n 2 HEAD -- $1` -- $1"
> >
> > FWIW, you can also do this as:
> > ldiff = log -p -1 --format=format: --
> >
> >> ldifft = "!git difftool `git rev-list --reverse -n 2 HEAD -- $1` -- $1"
> >
> > I don't know that you can do something equivalent with difftool. I
> > suppose you could do the above with "GIT_EXTERNAL_DIFF=<some difftool
> > wrapper> git ldiff", but that's not very helpful.
>
> difftool cannot be driven by log right now. It is something we
> thought would be helpful in the past:
>
> http://thread.gmane.org/gmane.comp.version-control.git/114269/focus=114367
>
> On 2009-03-23 Junio C Hamano <gitster <at> pobox.com> wrote:
> > Perhaps we would want a convenient way for "log -p" or "show -p" to drive
> > difftool as a backend?
>
> I think that's exactly it. difftool wraps diff; a log equivalent
> would be quite helpful.
>
> One idea is for difftool to learn a "--log" option to make it wrap log
> instead. I don't know if a diff-like command having a "--log" option
> is ideal from a consistency-of-user-interface POV so I'm open to
> ideas. It is convenient, though. It does seem like difftool would be
> a good place to expose this feature.
>
> I'd be interested in the "teach log / show -p about GIT_EXTERNAL_DIFF"
> route, if that sounds like a good idea.
> --
> David
^ permalink raw reply
* Re: git alias question
From: Jakub Narebski @ 2011-12-31 23:30 UTC (permalink / raw)
To: Michael Horowitz; +Cc: David Aguilar, Dave Borowitz, git, Junio C Hamano
In-Reply-To: <CAFLRborAuoWKxOeHtPRujSYbQPk67RCxTiVBavtWDeh-Byfa2w@mail.gmail.com>
Michael Horowitz <michael.horowitz@ieee.org> writes:
> The log operation does seem to make the most sense as the mechanism to
> search for the results. Making it work with difftool would work...
> Not sure if "--log" to difftool or some other options as suggested in
> the other thread would be most consistent UI-wise as stated, but
> either would work for me.
>
> On a separate note, some environment variable like GIT_PREFIX with the
> CWD would make the alias functionality more flexible.
1f5d271 (setup: Provide GIT_PREFIX to built-ins, 2011-05-25) is
present in v1.7.7; 7cf16a1 (handle_alias: provide GIT_PREFIX to
!alias, 2011-04-27) is in 1.7.6
--
Jakub Narebski
^ permalink raw reply
* Re: How to deal with historic tar-balls
From: Tomas Carnecky @ 2012-01-01 0:27 UTC (permalink / raw)
To: nn6eumtr; +Cc: git
In-Reply-To: <4EFF5CDA.5050809@gmail.com>
On 12/31/11 8:04 PM, nn6eumtr wrote:
> I have a number of older projects that I want to bring into a git
> repository. They predate a lot of the popular scm systems, so they are
> primarily a collection of tarballs today.
>
> I'm fairly new to git so I have a couple questions related to this:
>
> - What is the best approach for bringing them in? Do I just create a
> repository, then unpack the files, commit them, clean out the
> directory unpack the next tarball, and repeat until everything is loaded?
>
> - Do I need to pay special attention to files that are renamed/removed
> from version to version?
>
> - If the timestamps change on a file but the actual content does not,
> will git treat it as a non-change once it realizes the content hasn't
> changed?
>
> - Last, if after loading the repository I find another version of the
> files that predates those I've loaded, or are intermediate between two
> commits I've already loaded, is there a way to go say that commit B is
> actually the ancestor of commit C? (i.e. a->c becomes a->b->c if you
> were to visualize the commit timeline or do diffs) Or do I just reload
> the tarballs in order to achieve this?
There is a script which will import sources from multiple tarballs,
creating a commit with the contents of each tarball. It's in the git
repository under contrib/fast-import/import-tars.perl.
tom
^ permalink raw reply
* Re: [PATCH 2/2] git-svn, perl/Git.pm: extend and use Git->prompt method for querying users
From: Junio C Hamano @ 2012-01-01 9:11 UTC (permalink / raw)
To: Sven Strickroth; +Cc: Jeff King, git, Jakub Narebski
In-Reply-To: <4EFDD06A.3010708@tu-clausthal.de>
Sven Strickroth <sven.strickroth@tu-clausthal.de> writes:
> Am 30.12.2011 14:54 schrieb Jeff King:
> ...
>> Username: <text input>
>> Password: <text input>
>> Remember password? [checkbox]
>>
>> I was planning to do something custom for credentials as an extension to
>> the credential helper protocol, but this could also fall under the
>> heading of a general prompt helper.
>
> This might be problematic, because (for git-svn) username and password
> are not requested together.
I do not think Peff means the dialog must ask these three items at the
same time. The point is that other codepaths know they need to ask them
and would benefit if they can instruct the dialog external helper to ask
them in a single interaction. So if your callsite does not ask them
together, it is OK. You can keep asking them separately in two dialog
interactions.
^ permalink raw reply
* git exit with error code 1
From: ashish @ 2012-01-01 14:41 UTC (permalink / raw)
To: git
Ant script to run clone
<target name="clone" description="get the latest files">
<delete includeemptydirs="true">
<filesetdir="/opt/cruisecontrol-bin-2.8.4/projects/Mss/copyExample/local_copy/Mss"
defaultexcludes="false">
<include name="**/*" />
</fileset>
</delete>
<exec executable="git"
dir="/opt/cruisecontrol-bin-2.8.4/projects/Mss/copyExample/local_copy/Mss">
<arg line="clone -o fl ssh://git@ipaddress/git/run.git Mss" />
</exec>
</target>
In my current CruiseControl setup I am running the following target:
<modificationsetquietperiod="60">
<git
localworkingcopy="${projects.dir}/${project.name}/local_copy/${project.name}/"/>
</modificationset>
Running cruisecontrol gives git exit with error code 1. I guess
modificationset is not able to find git local working copy.
Any help would be welcome and greatly appreciable .
--
View this message in context: http://git.661346.n2.nabble.com/git-exit-with-error-code-1-tp7142041p7142041.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] Submodules always use a relative path to gitdir
From: Jens Lehmann @ 2012-01-01 14:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Antony Male, git, iveqy
In-Reply-To: <7vsjk3vw67.fsf@alter.siamese.dyndns.org>
Am 29.12.2011 23:40, schrieb Junio C Hamano:
> Antony Male <antony.male@gmail.com> writes:
> I further wonder if we can get away without using separate-git-dir option
> in this codepath, though. IOW using
>
> git clone $quiet -bare ${reference:+"$reference"} "$url" "$gitdir"
>
> might be a better solution.
A quick test shows that using a bare repo won't fly because without the
core.worktree setting commands that operate on the work tree can't be
run anymore inside submodules (starting with the initial checkout). If
we could teach setup to take the directory where the gitfile was found
as first guess for the git work tree it looks like we can make that
approach work. I'll see if I can come up with something here ...
> For example (this relates to the point I mumbled "haven't thought this
> through thoroughly yet"), doesn't the newly cloned repository have
> core.worktree that points at the working tree that records the <path>,
> which would become meaningless when a commit in the superproject that
> binds the submodule at different path <path2>?
Yes, and the core.worktree setting also contains an absolute path. So
we must either make that relative too and rewrite it on every "git
submodule add" to record the possibly changed path there or make the
bare clone work with a work tree (which sounds a bit strange ;-).
> git-submodule.sh | 21 ++++++++-------------
> 1 files changed, 8 insertions(+), 13 deletions(-)
>
> diff --git a/git-submodule.sh b/git-submodule.sh
> index 3adab93..9a23e9d 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -156,21 +156,16 @@ module_clone()
> ;;
> esac
>
> - if test -d "$gitdir"
> + if ! test -d "$gitdir"
> then
> - mkdir -p "$path"
> - echo "gitdir: $rel_gitdir" >"$path/.git"
> - rm -f "$gitdir/index"
> - else
> - mkdir -p "$gitdir_base"
> - if test -n "$reference"
> - then
> - git-clone $quiet "$reference" -n "$url" "$path" --separate-git-dir "$gitdir"
> - else
> - git-clone $quiet -n "$url" "$path" --separate-git-dir "$gitdir"
> - fi ||
> - die "$(eval_gettext "Clone of '\$url' into submodule path '\$path' failed")"
> + git clone $quiet -n ${reference:+"$reference"} \
> + --separate-git-dir "$gitdir" "$url" "$path" ||
> + die "$(eval_gettext "Clone of '\$url' for submodule '\$name' failed")
> fi
> +
> + mkdir -p "$path"
> + echo "gitdir: $rel_gitdir" >"$path/.git"
> + rm -f "$gitdir/index"
> }
>
> #
That broke quite some tests for me (even though I really liked
to get rid of that if ;-)
Here is a patch that solves the first part of the absolute paths
problem (passes all tests; parts of the commit message shamelessly
copied from your proposal). Then another patch can tackle the
core.worktree config setting problem to make superprojects
relocatable gain.
---------8<--------
Subject: [PATCH] submodules: always use a relative path to gitdir
Recent versions of "git submodule" maintain the submodule <name> at
<path> in the superproject using a "separate git-dir" mechanism. The
repository data for the submodule is stored in ".git/modules/<name>/"
directory of the superproject, and its working tree is created at
"<path>/" directory, with "<path>/.git" file pointing at the
".git/modules/<name>/" directory.
This is so that we can check out an older version of the superproject
that does not yet have the submodule <name> anywhere without losing
(and later having to re-clone) the submodule repository. Removing
"<path>" won't lose ".git/modules/<name>", and a different branch that
has the submodule at different location in the superproject, say
"<path2>", can create "<path2>/" and ".git" in it to point at the same
".git/modules/<name>".
When instantiating such a submodule, if ".git/modules/<name>/" does
not exist in the superproject, the submodule repository needs to be
cloned there first. Then we only need to create "<path>" directory,
point ".git/modules/<name>/" in the superproject with "<path>/.git",
and check out the working tree.
However, the current code is not structured that way. The codepath to
deal with newly cloned submodules uses "git clone --separate-git-dir"
and creates "<path>" and "<path>/.git". This can make the resulting
submodule working tree at "<path>" different from the codepath for
existing submodules. An example of such differences is that this
codepath prepares "<path>/.git" with an absolute path, while the
normal codepath uses a relative path.
Fix the latter by always writing the relative path to the git directory
in "<path>/.git". To make that work, the 'name' variable has to be set to
the value of the 'path' variable for newly added submodules.
This is only the first step to make superprojects movable again like they
were before the separate-git-dir approach was introduced. The second step
must be to either use a relative path in core.worktree too or to get rid
of that setting by using a bare repo in "./git/modules/<name>".
While at it also replace an if/else construct evaluating the presence
of the 'reference' option with a single line of bash code.
Reported-by: Antony Male <antony.male@gmail.com>
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
git-submodule.sh | 12 +++++-------
1 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 3adab93..2a93c61 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -131,6 +131,7 @@ module_clone()
gitdir=
gitdir_base=
name=$(module_name "$path" 2>/dev/null)
+ test -n "$name" || name="$path"
base_path=$(dirname "$path")
gitdir=$(git rev-parse --git-dir)
@@ -159,18 +160,15 @@ module_clone()
if test -d "$gitdir"
then
mkdir -p "$path"
- echo "gitdir: $rel_gitdir" >"$path/.git"
rm -f "$gitdir/index"
else
mkdir -p "$gitdir_base"
- if test -n "$reference"
- then
- git-clone $quiet "$reference" -n "$url" "$path" --separate-git-dir "$gitdir"
- else
- git-clone $quiet -n "$url" "$path" --separate-git-dir "$gitdir"
- fi ||
+ git clone $quiet -n ${reference:+"$reference"} \
+ --separate-git-dir "$gitdir" "$url" "$path" ||
die "$(eval_gettext "Clone of '\$url' into submodule path '\$path' failed")"
fi
+
+ echo "gitdir: $rel_gitdir" >"$path/.git"
}
#
--
1.7.8.2.303.g78a27
^ permalink raw reply related
* Re: Possible submodule or submodule documentation issue
From: Jens Lehmann @ 2012-01-01 15:13 UTC (permalink / raw)
To: Bill Zaumen; +Cc: git, Junio C Hamano
In-Reply-To: <1325127030.1681.35.camel@yos>
Am 29.12.2011 03:50, schrieb Bill Zaumen:
> On Wed, 2011-12-28 at 20:47 +0100, Jens Lehmann wrote:
>> Am 27.12.2011 20:24, schrieb Bill Zaumen:
>> Hmm, the documentation says "the location relative to the
>> superproject’s origin repository", not the directory containing
>> it. This means you have to use ".." first to get out of the
>> repository itself, no?
>
> The problem is that the documentation also says that "<repository>
> is the URL of the new submodule's origin repository" and the wording
> would not make sense if the superproject's origin repository was not
> also named by a URL. The rules for resolving relative URIs (a URL is
> a specific type of URI) are given in
> http://tools.ietf.org/html/rfc3986#section-5.4
> which has some examples: if you resolve ./g against http://a/b/c/d;p?q
> you get http://a/b/c/g (the rules are purely syntactic and the syntax
> does not indicate that ".../foo.git" is a directory, and even the
> slashes do not definitively indicate directories in the sense of a
> file-system directory although they often do).
Thanks for that pointer, now I understand what you expected and why.
But as this behavior is in Git since September 2007 (f31a522a2d), I
suppose changing the behavior is a no-go. So what about clarifying
the docs:
---------8<-----------
[PATCH] docs: describe behavior of relative submodule URLs
Since the relative submodule URLs have been introduced in f31a522a2d, they
do not conform to the rules for resolving relative URIs but rather to
those of relative directories.
Document that behavior.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
Documentation/git-submodule.txt | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 6ec3fef..b729649 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -79,7 +79,12 @@ to exist in the superproject. If <path> is not given, the
<repository> is the URL of the new submodule's origin repository.
This may be either an absolute URL, or (if it begins with ./
or ../), the location relative to the superproject's origin
-repository. If the superproject doesn't have an origin configured
+repository (Please note that to specify a repository 'foo.git'
+which is located right next to a superproject 'bar.git', you'll
+have to use '../foo.git' instead of './foo.git' - as one might expect
+when following the rules for relative URLs - because the evaluation
+of relative URLs in Git is identical to that of relative directories).
+If the superproject doesn't have an origin configured
the superproject is its own authoritative upstream and the current
working directory is used instead.
+
--
1.7.8.GIT
^ permalink raw reply related
* Re: Question about commit message wrapping
From: Drew Northup @ 2012-01-01 16:03 UTC (permalink / raw)
To: Sidney San Martín
Cc: Michael Haggerty, Frans Klaver, Holger Hellmuth, Andrew Ardill,
JakubNarebski, git@vger.kernel.org
In-Reply-To: <3BFBBBF6-878E-4B98-A1BB-16F841B6773D@sidneysm.com>
FWIW, I'm leaving text in this email as my mail client found it (and not
reflowing as I usually do). You can clearly see the effect of one mail
client assuming that the end display is doing all of the wrapping (I'll
not name names). When I first read the mail it looked fine because my
mail client IGNORED the inconsistencies in line wrap modes.
On Wed, 2011-12-14 at 16:04 -0500, Sidney San Martín wrote:
> On Dec 12, 2011, at 10:14 PM, Michael Haggerty wrote:
>
> > FWIW I think automatic wrapping of commit messages is a bad idea. I
> > wrap my commit messages deliberately to make them look the way I want
> > them to look. The assumption of an 80-character display has historical
> > reasons, but it is also a relatively comfortable line-width to read
> > (even on wider displays).
>
> A lot of Git repos live in heterogeneous environments. I played a little with some of the popular Git interfaces I can use on my computer. The majority of them…
>
> - compose and show commit messages in a proportional font (where the width of and formatting in "80 characters" means nothing),
In virtually all modern tools the default font is the "system default"
font, which is typically variable width. In some places I've even seen
variable pitch font rendering (I know there's a more technical term for
it, but I'm not taking the time to look it up right now) used, which is
distinct in that it makes the text easier to read when there are
potentially overlapping descenders and ascenders on adjoining lines
while leaving text without that feature unchanged in line spacing and
kerning. Try rendering ASCII-ART with that enabled!
However, it is a rare GUI tool that does not allow the user to change
the font to something more appropriate (I use fixed-width fonts for most
programming and scripting, but they are not any more helpful for reading
log messages for instance). Text-based programming tools usually just
use the console font, whatever it is--and woe be to the programmer who
switches their "console" font to something variable width. (Doing so
makes any application written with curses/ncurses in mind look very very
odd as well.)
> - don’t insert line breaks when you write a commit message (and don't provide a way to do so automatically),
Most of the "tools" I have seen that ignore all user-entered line breaks
are actually poorly written applications attempting to protect some sort
of backing database from an injection attack. Given that, many WIKI
systems typically ignore single line breaks when rendering (double line
breaks are taken to be paragraph breaks in those cases I am aware of),
so any argument about that quickly becomes moot as well. If somebody is
writing a tool that does not allow me to force multiple line breaks when
desired then so far as I am concerned their tool is broken. I don't see
a point in changing GIT as a whole because somebody writes a broken GUI
implementation.
> - do wrap commit messages when showing them.
>
> Jakub, you said that education was the answer to getting some consistency in line wrapping, but I have trouble imagining the makers of new tools using fixed-width text for anything other than code.
Remember, as soon as you think you've idiot-proofed something somebody
builds a better idiot. That's why Jakub (and many others of us) would
prefer just to tell people about the way things are intended to work and
then get out of the way and let people make their own mistakes.
> > And given that commit messages sometimes
> > contain "flowable" paragraph text, sometimes code snippets, sometimes
> > ASCII art, etc, no automatic wrapping will work correctly unless
> > everybody agrees that commit messages must be written in some specific
> > form of markup (or lightweight markup). And I can't imagine such a
> > thing ever happening.
>
> The two biggest websites I know of for talking about code, GitHub and Stack Overflow, both adopted flavors of Markdown. It is basically the formatting syntax already used for commit messages in the Git project itself (this email too), so can be formatted to look good in a specific environment (i.e. proportional fonts) and looks good by itself.
>
> (Actually, as far as I can tell commit messages are the only place GitHub doesn’t currently render user-entered text as Markdown.)
>
> I think, now and in the future, consistency will be found most easily in in Markdown-like formatting and least in 80 columns of fixed-width text.
Given that there is little consensus even between Markdown-like
formatting methods (which have in some cases been around since the
advent of movable type presses, so far as I am aware) I have to agree
with Michael here.
--
-Drew Northup
________________________________________________
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* Re: [PATCH resend] Do not create commits whose message contains NUL
From: Drew Northup @ 2012-01-01 16:27 UTC (permalink / raw)
To: Jeff King; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <20111213175932.GA1663@sigill.intra.peff.net>
On Tue, 2011-12-13 at 12:59 -0500, Jeff King wrote:
> It looks like we already have a check for is_utf8, and this is not
> failing that check. I guess because is_utf8 takes a NUL-terminated
> buffer, so it simply sees the truncated result (i.e., depending on
> endianness, "foo" in utf16 is something like "f\0o\0o\0", so we check
> only "f"). We could make is_utf8 take a length parameter to be more
> accurate, and then it would catch this.
>
> However, I think that's not quite what we want. We only check is_utf8 if
> the encoding field is not set. And really, we want to reject NULs no
> matter _which_ encoding they've set, because git simply doesn't handle
> them properly.
I had already started experimenting with automatically detecting decent
UTF-16 a long while back so that compatible platforms could handle it
appropriately in terms of creating diffs and dealing with newline
munging between platforms. There is no 100% sure-fire check for UTF-16
if you don't already suspect it is possibly UTF-16. If we really want to
check for possible UTF-16 specifically I can scrape out the check I
wrote up and send it along.
The is_utf8 check was not written to detect 100% valid UTF-8 per-se. It
seems to me that it was written as part of the "is this a binary or not"
check in the add/commit path. I have thought for some time that
specifying buffer length in that whole code path would be a good idea
(but I thought that somebody else had taken up that battle while I was
busy dealing with other problems elsewhere), if for no other reason it
would force it to deal with NULs more intelligently.
--
-Drew Northup
________________________________________________
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox