* Re: [PATCH] pulling signed tag: add howto document
From: Marc Branchaud @ 2012-01-18 22:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1uqwmyt6.fsf@alter.siamese.dyndns.org>
On 12-01-18 05:27 PM, Junio C Hamano wrote:
> Marc Branchaud <marcnarc@xiplink.com> writes:
>
>> It might be better to just move the footnote to the end of the next sentence.
>
> Ok. How does this version look? The highlights are:
>
> * remove footnotes and spell them out inline, like "Note that..."
>
> * "a single liner" -> "a one-liner"
IMO "one-liner" should be "one-line", but toMAYto toMAHto...
The rest looks good.
M.
^ permalink raw reply
* Re: [PATCH] pulling signed tag: add howto document
From: Junio C Hamano @ 2012-01-18 22:27 UTC (permalink / raw)
To: Marc Branchaud; +Cc: Junio C Hamano, git
In-Reply-To: <4F173C5D.7000802@xiplink.com>
Marc Branchaud <marcnarc@xiplink.com> writes:
> It might be better to just move the footnote to the end of the next sentence.
Ok. How does this version look? The highlights are:
* remove footnotes and spell them out inline, like "Note that..."
* "a single liner" -> "a one-liner"
* "publishing repository" -> "public repository". I often use the former
when I want to differenciate a repository used to publish the work by a
single owner from a shared public repository, so technically the wording
could stay as-is, but I think it is clear that we mean publishing one
not a shared one from the context of this document.
* Drop the attempt to say "you would see these 'Good signature from...'
if and only if the signature verifies OK" altogether. It is clear from
the example that the signature was good.
* Replace the paragraph that explains there is no need to keep and
transfer signed tags for auditors with your version.
Thanks.
.../howto/using-signed-tag-in-pull-request.txt | 60 +++++++++----------
1 files changed, 28 insertions(+), 32 deletions(-)
diff --git a/Documentation/howto/using-signed-tag-in-pull-request.txt b/Documentation/howto/using-signed-tag-in-pull-request.txt
index efac088..a1351c5 100644
--- a/Documentation/howto/using-signed-tag-in-pull-request.txt
+++ b/Documentation/howto/using-signed-tag-in-pull-request.txt
@@ -58,7 +58,7 @@ A contributor or a lieutenant
-----------------------------
After preparing her work to be pulled, the contributor uses `git tag -s`
-to create a signed tag [*1*]:
+to create a signed tag:
------------
$ git checkout work
@@ -66,14 +66,27 @@ to create a signed tag [*1*]:
$ git tag -s -m "Completed frotz feature" frotz-for-xyzzy work
------------
-and pushes the tag out to her publishing repository [*2*]. There is no
-need to push the `work` branch or anything else:
+Note that this example uses the `-m` option to create a signed tag with
+just a one-liner message, but this is for illustration purposes only. It
+is advisable to compose a well-written explanation of what the topic does
+to justify why it is worthwhile for the integrator to pull it, as this
+message will eventually become part of the final history after the
+integrator responds to the pull request (as we will see later).
+
+Then she pushes the tag out to her public repository:
------------
$ git push example.com:/git/froboz.git/ +frotz-for-xyzzy
------------
-Then the contributor prepares a message to request a "pull":
+There is no need to push the `work` branch or anything else.
+
+Note that the above command line used a plus sign at the beginning of
+`+frotz-for-xyzzy` to allow forcing the update of a tag, as the same
+contributor may want to reuse a signed tag with the same name after the
+previous pull request has already been responded to.
+
+The contributor then prepares a message to request a "pull":
------------
$ git request-pull v3.2 example.com:/git/froboz.git/ frotz-for-xyzzy >msg.txt
@@ -148,22 +161,21 @@ In the editor, the integrator will see something like this:
# gpg: Good signature from "Con Tributor <nitfol@example.com>"
------------
-provided if the signature in the signed tag verifies correctly. Notice
-that the message recorded in the signed tag "Completed frotz feature"
-appears here, and again that is why it is important for the contributor
-to explain her work well when creating the signed tag.
+Notice that the message recorded in the signed tag "Completed frotz
+feature" appears here, and again that is why it is important for the
+contributor to explain her work well when creating the signed tag.
As usual, the lines commented with `#` are stripped out. The resulting
commit records the signed tag used for this validation in a hidden field
so that it can later be used by others to audit the history. There is no
need for the integrator to keep a separate copy of the tag in his
-repository (i.e. `git tag -l` won't list frotz-for-xyzzy tag in the above
-example), and there is no need to publish the tag to his public
+repository (i.e. `git tag -l` won't list the `frotz-for-xyzzy` tag in the
+above example), and there is no need to publish the tag to his public
repository, either.
After the integrator responds to the pull request and her work becomes
-part of the permanent history, the contributor can remove the tag from the
-publishing repository, if she chooses, in order to keep the tag namespace
+part of the permanent history, the contributor can remove the tag from
+her public repository, if she chooses, in order to keep the tag namespace
of her public repository clean, with:
------------
@@ -199,23 +211,7 @@ A typical output from `git show --show-signature` may look like this:
...
------------
-There is no need to fetch and keep a signed tag like `frotz-for-xyzzy`
-that is used for frequent "pull" exchange in the long term just for such
-auditing purposes, as the signature is recorded as part of the merge
-commit.
-
-
-Footnotes
----------
-
-*1* This example uses the `-m` option to create a signed tag with just a
-single liner message, but this is for illustration purposes only. It is
-advisable to compose a well-written explanation of what the topic does to
-justify why it is worthwhile for the integrator to pull it, as this
-message will eventually become part of the final history after the
-integrator responds to the pull request.
-
-*2* The example uses plus at the beginning of `+frotz-for-xyzzy` to allow
-forcing the update of a tag, as the same contributor may want to reuse a
-signed tag with the same name after the previous pull request has already
-been responded to.
+There is no need for the auditor to explicitly fetch the contributor's
+signature, or to even be aware of what tag(s) the contributor and integrator
+used to communicate the signature. All the required information is recorded
+as part of the merge commit.
^ permalink raw reply related
* [PATCH] git-add: allow --ignore-missing always, not just in dry run
From: Dieter Plaetinck @ 2012-01-18 21:52 UTC (permalink / raw)
To: git; +Cc: Dieter Plaetinck
There is no need to restrict use of --ignore-missing to dry runs,
it can be useful to ignore missing files during normal operation as
well.
Signed-off-by: Dieter Plaetinck <dieter@plaetinck.be>
---
Documentation/git-add.txt | 9 +++++----
builtin/add.c | 4 +---
2 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 9c1d395..c6fae9f 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -138,10 +138,11 @@ subdirectories.
true to make this the default behaviour.
--ignore-missing::
- This option can only be used together with --dry-run. By using
- this option the user can check if any of the given files would
- be ignored, no matter if they are already present in the work
- tree or not.
+ If some files could not be added because they are missing,
+ do not raise any error but continue adding the others.
+ By using this option with --dry-run the user can check if
+ any of the given files would be ignored,
+ no matter if they are already present in the work tree or not.
\--::
This option can be used to separate command-line options from
diff --git a/builtin/add.c b/builtin/add.c
index 1c42900..e702714 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -326,7 +326,7 @@ static struct option builtin_add_options[] = {
OPT_BOOLEAN('A', "all", &addremove, "add changes from all tracked and untracked files"),
OPT_BOOLEAN( 0 , "refresh", &refresh_only, "don't add, only refresh the index"),
OPT_BOOLEAN( 0 , "ignore-errors", &ignore_add_errors, "just skip files which cannot be added because of errors"),
- OPT_BOOLEAN( 0 , "ignore-missing", &ignore_missing, "check if - even missing - files are ignored in dry run"),
+ OPT_BOOLEAN( 0 , "ignore-missing", &ignore_missing, "just skip files which do not exist"),
OPT_END(),
};
@@ -388,8 +388,6 @@ int cmd_add(int argc, const char **argv, const char *prefix)
if (addremove && take_worktree_changes)
die(_("-A and -u are mutually incompatible"));
- if (!show_only && ignore_missing)
- die(_("Option --ignore-missing can only be used together with --dry-run"));
if ((addremove || take_worktree_changes) && !argc) {
static const char *here[2] = { ".", NULL };
argc = 1;
--
1.7.8.3
^ permalink raw reply related
* Re: modifying the commits before push
From: Andreas Schwab @ 2012-01-18 22:01 UTC (permalink / raw)
To: Dirk Süsserott; +Cc: git
In-Reply-To: <87sjjc3cpj.fsf@gnu.org>
Sam Steingold <sds@gnu.org> writes:
> alas, I could not push because the remote tree was modified in the
> meantime, I pulled and now:
>
> # On branch master
> # Your branch is ahead of 'origin/master' by 23 commits.
What exactly did you do to get the additional 19 commits?
> is there a way for me to get back my original 4 patches, reset my tree
> (maybe by rm-rf+clone) and then re-apply them?
You can find them in the reflog (git log -g).
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: modifying the commits before push
From: Sam Steingold @ 2012-01-18 21:47 UTC (permalink / raw)
To: Dirk Süsserott; +Cc: git
In-Reply-To: <4F17291A.8020600@dirk.my1.cc>
Hi Dirk,
> * Dirk Süsserott <arjfyrggre@qvex.zl1.pp> [2012-01-18 21:18:34 +0100]:
> Am 18.01.2012 18:49 schrieb Sam Steingold:
>
> to modify the last 4 commits you can use git filter-branch (see the
> manpage):
>
> $ git checkout master
> $ git filter-branch --env-filter \
> 'GIT_COMMITTER_EMAIL="sds@gnu.org" \
> GIT_COMMITTER_NAME="Sam Steingold"' \
> HEAD~4..HEAD
>
> It should tell you that it rewrites 4 commits.
I did this; I got a few messages which scrolled very quickly.
status code was 0, apparently, I was successful.
> The original tree is saved under original/refs/heads/master.
where is that?
> If sth. went wrong, reset your master to that point (easiest with
> gitk, it's steel blue). If it worked, you can delete the
> original/refs/heads/master like so:
>
> $ git for-each-ref --format="%(refname)" \
> refs/original/ | xargs -n 1 git update-ref -d
>
> Note: Whether it worked or not, remove the original refs afterwards,
> because a second run of git filter-branch will fail if there's already
> an "original" tree.
alas, I could not push because the remote tree was modified in the
meantime, I pulled and now:
# On branch master
# Your branch is ahead of 'origin/master' by 23 commits.
#
nothing to commit (working directory clean)
so, what do I do now?
is there a way for me to get back my original 4 patches, reset my tree
(maybe by rm-rf+clone) and then re-apply them?
thanks!
--
Sam Steingold (http://sds.podval.org/) on Ubuntu 11.10 (oneiric) X 11.0.11004000
http://jihadwatch.org http://memri.org http://thereligionofpeace.com
http://www.PetitionOnline.com/tap12009/ http://palestinefacts.org
I don't have an attitude problem. You have a perception problem.
^ permalink raw reply
* Re: [PATCH] pulling signed tag: add howto document
From: Marc Branchaud @ 2012-01-18 21:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v62g8n1tq.fsf@alter.siamese.dyndns.org>
On 12-01-18 04:22 PM, Junio C Hamano wrote:
> Marc Branchaud <marcnarc@xiplink.com> writes:
>>> +
>>> +------------
>>> + $ git checkout work
>>> + $ ... "git pull" from sublieutenants, "git commit" your own work ...
>>> + $ git tag -s -m "Completed frotz feature" frotz-for-xyzzy work
>>> +------------
>>> +
>>> +and pushes the tag out to her publishing repository [*2*]. There is no
>>
>> This footnote speaks of the example using a +, but the example does no such
>> thing.
>>
>>> +need to push the `work` branch or anything else:
>>> +
>>> +------------
>>> + $ git push example.com:/git/froboz.git/ +frotz-for-xyzzy
>>> +------------
>
> Do you not see the plus in front of +'frotz-for-xyzzy' above, or am I
> missing something?
Oops, I was tripped up because the footnote is attached to a sentence that my
addled mind associates with the previous "git tag" example.
It might be better to just move the footnote to the end of the next sentence.
M.
^ permalink raw reply
* Re: [PATCH] pulling signed tag: add howto document
From: Junio C Hamano @ 2012-01-18 21:22 UTC (permalink / raw)
To: Marc Branchaud; +Cc: git
In-Reply-To: <4F16E228.5050203@xiplink.com>
Marc Branchaud <marcnarc@xiplink.com> writes:
>> +A contributor or a lieutenant
>> +-----------------------------
>> +
>> +After preparing her work to be pulled, the contributor uses `git tag -s`
>> +to create a signed tag [*1*]:
>
> Given that the rest of the text refers to the gist of this footnote, I think
> it'd be better to put the note's text here instead of as a footnote.
Hmm, I'll try to see how well it reads after moving the text here. Thanks.
>> +
>> +------------
>> + $ git checkout work
>> + $ ... "git pull" from sublieutenants, "git commit" your own work ...
>> + $ git tag -s -m "Completed frotz feature" frotz-for-xyzzy work
>> +------------
>> +
>> +and pushes the tag out to her publishing repository [*2*]. There is no
>
> This footnote speaks of the example using a +, but the example does no such
> thing.
>
>> +need to push the `work` branch or anything else:
>> +
>> +------------
>> + $ git push example.com:/git/froboz.git/ +frotz-for-xyzzy
>> +------------
Do you not see the plus in front of +'frotz-for-xyzzy' above, or am I
missing something?
>> +In the editor, the integrator will see something like this:
>> +
>> +------------
>> + Merge tag 'frotz-for-xyzzy' of example.com:/git/froboz.git/
>> +
>> + Completed frotz feature
>> + # gpg: Signature made Fri 02 Dec 2011 10:03:01 AM PST using RSA key ID 96AFE6CB
>> + # gpg: Good signature from "Con Tributor <nitfol@example.com>"
>> +------------
>> +
>> +provided if the signature in the signed tag verifies correctly. Notice
>
> s/if //
Noted.
>> +repository (i.e. `git tag -l` won't list frotz-for-xyzzy tag in the above
>
> s/list/list the/
Noted.
>> +There is no need to fetch and keep a signed tag like `frotz-for-xyzzy`
>> +that is used for frequent "pull" exchange in the long term just for such
>> +auditing purposes, as the signature is recorded as part of the merge
>> +commit.
>
> I had trouble parsing this sentence. I think part of the problem is that
> it's comparing the actual implementation to an earlier proposed design that
> was rejected. So it's trying to sell the reader on a feature of the
> implemented design, but the reader doesn't care.
>
> How about this instead:
>
> There is no need for the auditor to explicitly fetch the contributor's
> signature, or to even be aware of what tag(s) the contributor and integrator
> used to communicate the signature. All the required information is recorded
> as part of the merge commit.
Ok, that is much easier to read.
>> +
>> +
>> +Footnotes
>> +---------
>> +
>> +*1* This example uses the `-m` option to create a signed tag with just a
>> +single liner message, but this is for illustration purposes only. It is
>
> s/single liner/single-line/
Noted.
Thanks.
^ permalink raw reply
* Re: Interactive rebase with submodules
From: Jens Lehmann @ 2012-01-18 20:38 UTC (permalink / raw)
To: John Keeping; +Cc: git
In-Reply-To: <4F16AB2E.30706@metanate.com>
Am 18.01.2012 12:21, schrieb John Keeping:
> On 17/01/12 21:29, Jens Lehmann wrote:
>> Am 17.01.2012 19:47, schrieb John Keeping:
>>> This appears to be because the git-rebase--interactive script inspects whether there is anything to commit when `rebase --continue` is invoked by running:
>>>
>>> git diff-index --cached --quiet --ignore-submodules HEAD --
>>
>>> Is there a reason for the `--ignore-submodules` in this command? Removing that option results in the expected behaviour.
>>
>> Yes, removing it will help your use case but break others. The reason
>> for that is that because submodules are not updated during a rebase
>> it doesn't make sense to compare their HEAD to what is recorded in
>> the superproject, as that might have been changed by an earlier
>> commit. And as the submodules HEAD hasn't been updated back then,
>> it is stale and will always show up as modified (even if it wasn't).
>
> Is this worse than the current behaviour?
If we break established behavior that would be worse unless we have
a *very* good reason to do so. But please see below ...
> If I perform a rebase where there is a (non-submodule) conflict in a commit where a submodule changes I can see something like:
>
> # Changes to be committed:
> # modified: path/to/submodule
> #
> # Unmerged paths:
> # both modified: path/to/file
> #
> # Changes not staged for commit:
> # modified: path/to/submodule (new commits)
>
> This occurs if a later commit in the rebase will modify the submodule. In this case, `rebase --continue` correctly recreates the commit once I have resolved the conflict in the file, ignoring the unstaged submodule changes.
Yeah, as rebase doesn't touch the submodules, that is expected.
>>> I can understand not updating submodules while running the rebase, but I expected that having resolved a conflict and added my change to the index it would be applied by `git rebase --continue`, as indeed it is if there happen to be other (non-submodule) changes in the same commit.
>>
>> The irony is that you would have to update submodules (or at least
>> their HEAD and use "--ignore-submodules=dirty") while running rebase
>> to make that work in all cases ;-)
>
> I don't this this is the case, since diff-tree is being invoked with --cached won't it ignore changes in the work tree anyway?
Right, thanks for nudging me with the clue bat ...
I missed the "--cached" option and did not question if the code does
what the commit message of 6848d58c6 (where the --ignore-submodules
option was introduced) said:
Ignore dirty submodule states during rebase and stash
When rebasing or stashing, chances are that you do not care about
dirty submodules, since they are not updated by those actions anyway.
So ignore the submodules' states.
Note: the submodule states -- as committed in the superproject --
will still be stashed and rebased, it is _just_ the state of the
submodule in the working tree which is ignored.
I think this logic misses the case when only submodule changes are left
in a commit.
>> But just updating the HEAD would be dangerous as you would have to be
>> very careful to restore the submodules HEAD after the rebase, or the
>> submodule's work tree will be out of sync.
>
> Just updating HEAD in the submodule without touching its work tree doesn't seem like a good idea. I think it will cause a lot more confusion when running `git status` which will show unexpected modified content for the submodule.
Yes, we agree here.
> Since I did not expect rebase to perform a submodule update, I was not surprised to see unstaged submodule changes when rebasing, but I did expect rebase to commit anything I had added to the index.
Right.
I'll have to add some tests for that case, but I doubt I'll manage that
today. Until I can provide a complete patch, this diff should fix your
problem (no, I did not test if that change is enough to fix the problem,
but at least it does not break the test suite ;-):
---------------8<--------------
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 5812222..4546749 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -672,7 +672,7 @@ rearrange_squash () {
case "$action" in
continue)
# do we have anything to commit?
- if git diff-index --cached --quiet --ignore-submodules HEAD --
+ if git diff-index --cached --quiet HEAD --
then
: Nothing to commit -- skip this
else
^ permalink raw reply related
* Re: modifying the commits before push
From: Dirk Süsserott @ 2012-01-18 20:18 UTC (permalink / raw)
To: git, sds
In-Reply-To: <87wr8o3nq0.fsf@gnu.org>
Am 18.01.2012 18:49 schrieb Sam Steingold:
> Hi,
> I am trying to push:
> $ git status
> # On branch master
> # Your branch is ahead of 'origin/master' by 4 commits.
> #
> nothing to commit (working directory clean)
> $
> but `git push` fails with this:
>
> remote: ERROR: Rejecting update because this commit email is not from ZZZ
>
> What I need to do is
> - modify the 4 commits with a different e-mail and do `git push` again
> - make sure that all my commits in this repo are done with the correct e-mail
>
> how do I do this?
>
> thanks!
>
Hi Sam,
to modify the last 4 commits you can use git filter-branch (see the
manpage):
$ git checkout master
$ git filter-branch --env-filter \
'GIT_COMMITTER_EMAIL="sds@gnu.org" \
GIT_COMMITTER_NAME="Sam Steingold"' \
HEAD~4..HEAD
It should tell you that it rewrites 4 commits. The original tree is
saved under original/refs/heads/master. If sth. went wrong, reset your
master to that point (easiest with gitk, it's steel blue). If it worked,
you can delete the original/refs/heads/master like so:
$ git for-each-ref --format="%(refname)" \
refs/original/ | xargs -n 1 git update-ref -d
Note: Whether it worked or not, remove the original refs afterwards,
because a second run of git filter-branch will fail if there's already
an "original" tree.
To change your address for future commits configure it in .gitconfig in
your $HOME (--global) or on a per repo basis in .git/config (--local):
$ git config --global user.email "sds@gnu.org"
$ git config --global user.name "Sam Steingold"
Or use git gui for this step (Edit -> Options).
HTH
Dirk
^ permalink raw reply
* [PATCH] i18n: disable i18n for shell scripts if NO_GETTEXT defined
From: Alex Riesen @ 2012-01-18 19:54 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, Ævar Arnfjörð Bjarmason
In-Reply-To: <7vfwfervt9.fsf@alter.siamese.dyndns.org>
Otherwise the i18n is used in the scripts even with NO_GETTEXT set.
It is very unexpected.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Junio C Hamano, Tue, Jan 17, 2012 20:08:34 +0100:
> Alex Riesen <raa.lkml@gmail.com> writes:
> > Otherwise the i18n is used in the scripts even with NO_GETTEXT set.
> > It is very unexpected.
> >
...
>
> But the result of the patch looks almost unreadable. could we restructure
> the script like this instead?
> ...
Done. I simplified the commentary on "poison" a little.
Makefile | 1 +
git-sh-i18n.sh | 102 +++++++++++++++++++++++++++-----------------------------
2 files changed, 50 insertions(+), 53 deletions(-)
diff --git a/Makefile b/Makefile
index a782409..d82ea6a 100644
--- a/Makefile
+++ b/Makefile
@@ -1887,6 +1887,7 @@ sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
-e 's|@@LOCALEDIR@@|$(localedir_SQ)|g' \
-e 's/@@NO_CURL@@/$(NO_CURL)/g' \
+ -e 's/@@NO_GETTEXT@@/$(NO_GETTEXT)/g' \
-e $(BROKEN_PATH_FIX) \
$@.sh >$@+
endef
diff --git a/git-sh-i18n.sh b/git-sh-i18n.sh
index b4575fb..1902fb1 100644
--- a/git-sh-i18n.sh
+++ b/git-sh-i18n.sh
@@ -16,61 +16,44 @@ else
fi
export TEXTDOMAINDIR
-if test -z "$GIT_GETTEXT_POISON"
+GIT_INTERNAL_GETTEXT_SH_SCHEME=fallthrough
+if test -n "@@NO_GETTEXT@@$GIT_INTERNAL_GETTEXT_TEST_FALLBACKS"
+then
+ : no probing necessary
+elif test -n "$GIT_GETTEXT_POISON"
then
- if test -z "$GIT_INTERNAL_GETTEXT_TEST_FALLBACKS" && type gettext.sh >/dev/null 2>&1
- then
- # This is GNU libintl's gettext.sh, we don't need to do anything
- # else than setting up the environment and loading gettext.sh
- GIT_INTERNAL_GETTEXT_SH_SCHEME=gnu
- export GIT_INTERNAL_GETTEXT_SH_SCHEME
-
- # Try to use libintl's gettext.sh, or fall back to English if we
- # can't.
- . gettext.sh
-
- elif test -z "$GIT_INTERNAL_GETTEXT_TEST_FALLBACKS" && test "$(gettext -h 2>&1)" = "-h"
- then
- # We don't have gettext.sh, but there's a gettext binary in our
- # path. This is probably Solaris or something like it which has a
- # gettext implementation that isn't GNU libintl.
- GIT_INTERNAL_GETTEXT_SH_SCHEME=solaris
- export GIT_INTERNAL_GETTEXT_SH_SCHEME
-
- # Solaris has a gettext(1) but no eval_gettext(1)
- eval_gettext () {
- gettext "$1" | (
- export PATH $(git sh-i18n--envsubst --variables "$1");
- git sh-i18n--envsubst "$1"
- )
- }
-
- else
- # Since gettext.sh isn't available we'll have to define our own
- # dummy pass-through functions.
-
- # Tell our tests that we don't have the real gettext.sh
- GIT_INTERNAL_GETTEXT_SH_SCHEME=fallthrough
- export GIT_INTERNAL_GETTEXT_SH_SCHEME
-
- gettext () {
- printf "%s" "$1"
- }
-
- eval_gettext () {
- printf "%s" "$1" | (
- export PATH $(git sh-i18n--envsubst --variables "$1");
- git sh-i18n--envsubst "$1"
- )
- }
- fi
-else
- # Emit garbage under GETTEXT_POISON=YesPlease. Unlike the C tests
- # this relies on an environment variable
-
GIT_INTERNAL_GETTEXT_SH_SCHEME=poison
- export GIT_INTERNAL_GETTEXT_SH_SCHEME
+elif test -n type gettext.sh >/dev/null 2>&1
+then
+ # This is GNU libintl's gettext.sh, we don't need to do anything
+ # else than setting up the environment and loading gettext.sh
+ GIT_INTERNAL_GETTEXT_SH_SCHEME=gnu
+elif test "$(gettext -h 2>&1)" = "-h"
+then
+ # We don't have gettext.sh, but there's a gettext binary in our
+ # path. This is probably Solaris or something like it which has a
+ # gettext implementation that isn't GNU libintl.
+ GIT_INTERNAL_GETTEXT_SH_SCHEME=solaris
+fi
+export GIT_INTERNAL_GETTEXT_SH_SCHEME
+case "$GIT_INTERNAL_GETTEXT_SH_SCHEME" in
+gnu)
+ # Try to use libintl's gettext.sh, or fall back to English if we
+ # can't.
+ . gettext.sh
+ ;;
+solaris)
+ # Solaris has a gettext(1) but no eval_gettext(1)
+ eval_gettext () {
+ gettext "$1" | (
+ export PATH $(git sh-i18n--envsubst --variables "$1");
+ git sh-i18n--envsubst "$1"
+ )
+ }
+ ;;
+poison)
+ # Used in tests
gettext () {
printf "%s" "# GETTEXT POISON #"
}
@@ -78,7 +61,20 @@ else
eval_gettext () {
printf "%s" "# GETTEXT POISON #"
}
-fi
+ ;;
+*)
+ gettext () {
+ printf "%s" "$1"
+ }
+
+ eval_gettext () {
+ printf "%s" "$1" | (
+ export PATH $(git sh-i18n--envsubst --variables "$1");
+ git sh-i18n--envsubst "$1"
+ )
+ }
+ ;;
+esac
# Git-specific wrapper functions
gettextln () {
--
1.7.9.rc0.84.g0aa6c
^ permalink raw reply related
* Checking out orphans with -f
From: Martin Fick @ 2012-01-18 19:07 UTC (permalink / raw)
To: git
I am trying to write some scripts which do various things to
a git repo and I have run into a issue where I think that
git behavior with respect to orphan branches is potentially
undesirable. If I type:
git checkout --orphan a
I cannot easily abandon this state by simply typing:
git check -f --orphan b
Is there a better simpler way to abandon a that I am not
aware of? Am I miss understanding what -f is supposed to
do? It seems like it should allow me to abandon the a
orphan and continue to checkout the b orphan?
Thanks for any insights,
-Martin
--
Employee of Qualcomm Innovation Center, Inc. which is a
member of Code Aurora Forum
^ permalink raw reply
* Re: [PATCH] i18n: disable i18n for shell scripts if NO_GETTEXT defined
From: Alex Riesen @ 2012-01-18 18:57 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <CACBZZX4TsL-tj04PmUwGNWjXO+JY-8unAv-aRKOGvgB71qdYCg@mail.gmail.com>
On Wed, Jan 18, 2012 at 16:22, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
> On Tue, Jan 17, 2012 at 14:42, Alex Riesen <raa.lkml@gmail.com> wrote:
>> Otherwise the i18n is used in the scripts even with NO_GETTEXT set.
>> It is very unexpected.
>
> So the reason it's like that is that I was assuming that gettext.sh
> wouldn't be FUBAR anywhere, but the translations shouldn't kick in
> since we haven't installed them during "make install".
>
> But I wonder if this negatively affects some systems, now we now:
>
> * Don't use gettext.sh, which means that we're using our fallback
> shell function instead of the binary gettext(1), which is probably
> faster.
>
> * Use our own eval_gettext() instead of using the system one, which
> uses the GNU binary which is more likely to be in the FS cache
> already since other programs are probably using it.
>
> Which is why I didn't do something like this to begin with.
Well, if I say NO_GETTEXT, I kind of want none of local gettext,
whether it works, or not.
^ permalink raw reply
* Re: post-update to stash after push to non-bare current branch
From: Neal Kreitzinger @ 2012-01-18 18:51 UTC (permalink / raw)
Cc: Neal Kreitzinger, git
In-Reply-To: <4F171088.4080006@gmail.com>
On 1/18/2012 12:33 PM, Neal Kreitzinger wrote:
> On 1/18/2012 11:53 AM, Neal Kreitzinger wrote:
>> We use the worktree of git-repos as the webroot for virtual hosts
>> assigned
>> to ports so we can directly test changes to dev and test git-repos. We
>> have
>> some developers who want to develop offline on laptops and push to these
>> non-bare repos so they can test their changes. My plan is to set
>> receive.denyCurrentBranch = warn, and then use the post-update hook on
>> the
>> remote non-bare to do a stash of the worktree and index. My assumption is
>> that post-update hook only executes after a successful push. Correct? I
>> only want to stash the non-bare remote work-tree and index after a
>> successful push to it (effectively doing a git-reset --hard, but also
>> keeping any changes to the worktree/index of the non-bare remote as a
>> safety
>> in case someone does directly make uncommitted changes on the non-bare
>> remote.)
>>
> If I manually run git-stash on the non-bare remote after pushing to it
> from a clone (receive.denyCurrentBranch=warn) it works as expected and
> leaves the worktree and index matching the new HEAD. However, when
> post-update runs the git-stash is leaves the worktree dirty. (git 1.7.1)
>
hooks/post-update was:
git stash save
echo "worktree+index of non-bare remote current branch stashed for safety"
it created the stash and echoed the message. However, as stated earlier,
the worktree is still dirty. I then manually run git-reset --hard and
that makes it clean (worktree, index, HEAD match). However, if I add
that to the hook it still leaves dirty worktree (index matches HEAD, but
worktree doesn't match index)
hooks/post-update is:
git stash save
echo "worktree+index of non-bare remote current branch stashed for safety"
git reset --hard
echo "git-reset --hard on current remote branch to ensure clean state"
message is echoed, but git-reset --hard does not appear to have really
worked. (git 1.7.1)
v/r,
neal
^ permalink raw reply
* Re: How to migrate a complex directory structure from SVN to GIT?
From: Jehan Bing @ 2012-01-18 18:47 UTC (permalink / raw)
To: git
In-Reply-To: <1326828837924-7197567.post@n2.nabble.com>
On 2012-01-17 11:33, Asuka wrote:
> I would like to migrate all branches and tags .. but unfortunately sometimes
> I have just a trunk directory and no branches or tags directory. Sometimes
> the branches are in a subdirectory, sometimes in a subsubdirectory. So how
> can migrate my svn in an efficient way?
From the look of your example, each project is either a trunk, or have
subdirectories for trunk/branches/tags so I don't think it's a problem.
If you don't have branches or tags, just don't specify them when you
clone your subversion repository.
If however you have a more complex layout, you can use "git svn init",
then edit .git/config to suit your needs, then run "git svn fetch".
And by "suit your needs", I mean you can add multiple "fetch=..." lines.
In my case, I ended up having one "fetch=..." for each trunk, branch and
tag.
It was not efficient, it took 2 weeks to convert <30k revisions, ~200
branches/project, ~80 projects, but it works well enough for me.
Jehan
^ permalink raw reply
* Re: post-update to stash after push to non-bare current branch
From: Neal Kreitzinger @ 2012-01-18 18:33 UTC (permalink / raw)
To: Neal Kreitzinger; +Cc: git
In-Reply-To: <jf70vc$kol$1@dough.gmane.org>
On 1/18/2012 11:53 AM, Neal Kreitzinger wrote:
> We use the worktree of git-repos as the webroot for virtual hosts assigned
> to ports so we can directly test changes to dev and test git-repos. We have
> some developers who want to develop offline on laptops and push to these
> non-bare repos so they can test their changes. My plan is to set
> receive.denyCurrentBranch = warn, and then use the post-update hook on the
> remote non-bare to do a stash of the worktree and index. My assumption is
> that post-update hook only executes after a successful push. Correct? I
> only want to stash the non-bare remote work-tree and index after a
> successful push to it (effectively doing a git-reset --hard, but also
> keeping any changes to the worktree/index of the non-bare remote as a safety
> in case someone does directly make uncommitted changes on the non-bare
> remote.)
>
If I manually run git-stash on the non-bare remote after pushing to it
from a clone (receive.denyCurrentBranch=warn) it works as expected and
leaves the worktree and index matching the new HEAD. However, when
post-update runs the git-stash is leaves the worktree dirty. (git 1.7.1)
v/r,
neal
^ permalink raw reply
* Re: Cannot push a commit
From: Matthias Fechner @ 2012-01-18 18:25 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <4F1524DB.2080009@fechner.net>
Am 17.01.2012 08:35, schrieb Matthias Fechner:
> So the problem has something to do with windows as client. I will do
> some additional test this evening.
>
> Where can we continue to search?
the problem seems to be located in the ssh.exe which comes with git.
(location in the standard windows install is:
C:\Program Files (x86)\Git\bin
)
I downloaded plink.exe from the putty project and copied it into a
directory where the PATH variable points to.
Then I opened the git bash and inserted:
export GIT_SSH=plink.exe
git push
Counting objects: 4, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 91.63 KiB | 123 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To idefix@fechner.net:git-test
8020989..6ea6180 master -> master
The currently installed version is OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb
2007.
Maybe an updated openssh version in the git bin folder will solve the
problem?
Bye
Matthias
--
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the universe trying to
produce bigger and better idiots. So far, the universe is winning." --
Rich Cook
^ permalink raw reply
* modifying the commits before push
From: Sam Steingold @ 2012-01-18 17:49 UTC (permalink / raw)
To: git
Hi,
I am trying to push:
$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 4 commits.
#
nothing to commit (working directory clean)
$
but `git push` fails with this:
remote: ERROR: Rejecting update because this commit email is not from ZZZ
What I need to do is
- modify the 4 commits with a different e-mail and do `git push` again
- make sure that all my commits in this repo are done with the correct e-mail
how do I do this?
thanks!
--
Sam Steingold (http://sds.podval.org/) on Ubuntu 11.10 (oneiric) X 11.0.11004000
http://pmw.org.il http://jihadwatch.org http://thereligionofpeace.com
http://openvotingconsortium.org http://ffii.org http://camera.org
Let us remember that ours is a nation of lawyers and order.
^ permalink raw reply
* post-update to stash after push to non-bare current branch
From: Neal Kreitzinger @ 2012-01-18 17:53 UTC (permalink / raw)
To: git
We use the worktree of git-repos as the webroot for virtual hosts assigned
to ports so we can directly test changes to dev and test git-repos. We have
some developers who want to develop offline on laptops and push to these
non-bare repos so they can test their changes. My plan is to set
receive.denyCurrentBranch = warn, and then use the post-update hook on the
remote non-bare to do a stash of the worktree and index. My assumption is
that post-update hook only executes after a successful push. Correct? I
only want to stash the non-bare remote work-tree and index after a
successful push to it (effectively doing a git-reset --hard, but also
keeping any changes to the worktree/index of the non-bare remote as a safety
in case someone does directly make uncommitted changes on the non-bare
remote.)
v/r,
neal
^ permalink raw reply
* Re: [PATCH] i18n: disable i18n for shell scripts if NO_GETTEXT defined
From: Ævar Arnfjörð Bjarmason @ 2012-01-18 15:22 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <CALxABCZME-g++HxMsD4Nrn1J6s27vN7M_KQSVT3PeLWBqP7qJg@mail.gmail.com>
On Tue, Jan 17, 2012 at 14:42, Alex Riesen <raa.lkml@gmail.com> wrote:
> Otherwise the i18n is used in the scripts even with NO_GETTEXT set.
> It is very unexpected.
So the reason it's like that is that I was assuming that gettext.sh
wouldn't be FUBAR anywhere, but the translations shouldn't kick in
since we haven't installed them during "make install".
But I wonder if this negatively affects some systems, now we now:
* Don't use gettext.sh, which means that we're using our fallback
shell function instead of the binary gettext(1), which is probably
faster.
* Use our own eval_gettext() instead of using the system one, which
uses the GNU binary which is more likely to be in the FS cache
already since other programs are probably using it.
Which is why I didn't do something like this to begin with.
^ permalink raw reply
* Re: [PATCH] pulling signed tag: add howto document
From: Marc Branchaud @ 2012-01-18 15:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v62g9q55f.fsf@alter.siamese.dyndns.org>
Overall a very understandable doc! I've just a few linguistic comments:
On 12-01-17 06:29 PM, Junio C Hamano wrote:
> This time in a proper patch format...
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> * We may want to update Documentation/Makefile in such a way that we
> do not have to manually maintain a subset of howto/ files that need to
> be added to SP_ARTICLES list (i.e. asciidoc formatted). They are all
> marked with "Content-type: text/asciidoc" so a trivial $(shell grep -l)
> might be all it takes. Hint, hint...
>
> Documentation/Makefile | 5 +-
> .../howto/using-signed-tag-in-pull-request.txt | 221 ++++++++++++++++++++
> 2 files changed, 225 insertions(+), 1 deletions(-)
> create mode 100644 Documentation/howto/using-signed-tag-in-pull-request.txt
>
> diff --git a/Documentation/Makefile b/Documentation/Makefile
> index 116f175..d40e211 100644
> --- a/Documentation/Makefile
> +++ b/Documentation/Makefile
> @@ -20,7 +20,10 @@ ARTICLES += everyday
> ARTICLES += git-tools
> ARTICLES += git-bisect-lk2009
> # with their own formatting rules.
> -SP_ARTICLES = howto/revert-branch-rebase howto/using-merge-subtree user-manual
> +SP_ARTICLES = user-manual
> +SP_ARTICLES += howto/revert-branch-rebase
> +SP_ARTICLES += howto/using-merge-subtree
> +SP_ARTICLES += howto/using-signed-tag-in-pull-request
> API_DOCS = $(patsubst %.txt,%,$(filter-out technical/api-index-skel.txt technical/api-index.txt, $(wildcard technical/api-*.txt)))
> SP_ARTICLES += $(API_DOCS)
> SP_ARTICLES += technical/api-index
> diff --git a/Documentation/howto/using-signed-tag-in-pull-request.txt b/Documentation/howto/using-signed-tag-in-pull-request.txt
> new file mode 100644
> index 0000000..a057f9a
> --- /dev/null
> +++ b/Documentation/howto/using-signed-tag-in-pull-request.txt
> @@ -0,0 +1,221 @@
> +From: Junio C Hamano <gitster@pobox.com>
> +Date: Tue, 17 Jan 2011 13:00:00 -0800
> +Subject: Using signed tag in pull requests
> +Abstract: Beginning v1.7.9, a contributor can push a signed tag to her
> + publishing repository and ask her integrator to pull it. This assures the
> + integrator that the pulled history is authentic and allows others to
> + later validate it.
> +Content-type: text/asciidoc
> +
> +Using signed tag in pull requests
> +=================================
> +
> +A typical distributed workflow using Git is for a contributor to fork a
> +project, build on it, publish the result to her public repository, and ask
> +the "upstream" person (often the owner of the project where she forked
> +from) to pull from her public repository. Requesting such a "pull" is made
> +easy by the `git request-pull` command.
> +
> +Earlier, a typical pull request may have started like this:
> +
> +------------
> + The following changes since commit 406da78032179...:
> +
> + Froboz 3.2 (2011-09-30 14:20:57 -0700)
> +
> + are available in the git repository at:
> +
> + example.com:/git/froboz.git for-xyzzy
> +------------
> +
> +followed by a shortlog of the changes and a diffstat.
> +
> +The request was for a branch name (e.g. `for-xyzzy`) in the public
> +repository of the contributor, and even though it stated where the
> +contributor forked her work from, the message did not say anything about
> +the commit to expect at the tip of the for-xyzzy branch. If the site that
> +hosts the public repository of the contributor cannot be fully trusted, it
> +was unnecessarily hard to make sure what was pulled by the integrator was
> +genuinely what the contributor had produced for the project. Also there
> +was no easy way for third-party auditors to later verify the resulting
> +history.
> +
> +Starting from Git release v1.7.9, a contributor can add a signed tag to
> +the commit at the tip of the history and ask the integrator to pull that
> +signed tag. When the integrator runs `git pull`, the signed tag is
> +automatically verified to assure that the history is not tampered with.
> +In addition, the resulting merge commit records the content of the signed
> +tag, so that other people can verify that the branch merged by the
> +contributor was signed by the contributor, without fetching the signed tag
> +used to validate the pull request separately and keeping it in the refs
> +namespace.
> +
> +This document describes the workflow between the contributor and the
> +integrator, using Git v1.7.9 or later.
> +
> +
> +A contributor or a lieutenant
> +-----------------------------
> +
> +After preparing her work to be pulled, the contributor uses `git tag -s`
> +to create a signed tag [*1*]:
Given that the rest of the text refers to the gist of this footnote, I think
it'd be better to put the note's text here instead of as a footnote.
> +
> +------------
> + $ git checkout work
> + $ ... "git pull" from sublieutenants, "git commit" your own work ...
> + $ git tag -s -m "Completed frotz feature" frotz-for-xyzzy work
> +------------
> +
> +and pushes the tag out to her publishing repository [*2*]. There is no
This footnote speaks of the example using a +, but the example does no such
thing.
> +need to push the `work` branch or anything else:
> +
> +------------
> + $ git push example.com:/git/froboz.git/ +frotz-for-xyzzy
> +------------
> +
> +Then the contributor prepares a message to request a "pull":
> +
> +------------
> + $ git request-pull v3.2 example.com:/git/froboz.git/ frotz-for-xyzzy >msg.txt
> +------------
> +
> +The arguments are:
> +
> +. the version of the integrator's commit the contributor based her work on;
> +. the URL of the repository, to which the contributor has pushed what she
> + wants to get pulled; and
> +. the name of the tag the contributor wants to get pulled (earlier, she could
> + write only a branch name here).
> +
> +The resulting msg.txt file begins like so:
> +
> +------------
> + The following changes since commit 406da78032179...:
> +
> + Froboz 3.2 (2011-09-30 14:20:57 -0700)
> +
> + are available in the git repository at:
> +
> + example.com:/git/froboz.git frotz-for-xyzzy
> +
> + for you to fetch changes up to 703f05ad5835c...:
> +
> + Add tests and documentation for frotz (2011-12-02 10:02:52 -0800)
> +
> + -----------------------------------------------
> + Completed frotz feature
> + -----------------------------------------------
> +------------
> +
> +followed by a shortlog of the changes and a diffstat. Comparing this with
> +the earlier illustration of the output from the traditional `git request-pull`
> +command, the reader should notice that:
> +
> +. The tip commit to expect is shown to the integrator; and
> +. The signed tag message is shown prominently between the dashed lines
> + before the shortlog.
> +
> +The latter is why the contributor would want to justify why pulling her
> +work is worthwhile when creating the signed tag. The contributor then
> +opens her favorite MUA, reads msg.txt, edits and sends it to her upstream
> +integrator.
> +
> +
> +Integrator
> +----------
> +
> +After receiving such a pull request message, the integrator fetches and
> +integrates the tag named in the request, with:
> +
> +------------
> + $ git pull example.com:/git/froboz.git/ frotz-for-xyzzy
> +------------
> +
> +This operation will always open an editor to allow the integrator to fine
> +tune the commit log message when merging a signed tag. Also, pulling a
> +signed tag will always create a merge commit even when the integrator does
> +not have any new commits since the contributor's work forked (i.e. 'fast
> +forward'), so that the integrator can properly explain what the merge is
> +about and why it was made.
> +
> +In the editor, the integrator will see something like this:
> +
> +------------
> + Merge tag 'frotz-for-xyzzy' of example.com:/git/froboz.git/
> +
> + Completed frotz feature
> + # gpg: Signature made Fri 02 Dec 2011 10:03:01 AM PST using RSA key ID 96AFE6CB
> + # gpg: Good signature from "Con Tributor <nitfol@example.com>"
> +------------
> +
> +provided if the signature in the signed tag verifies correctly. Notice
s/if //
> +that the message recorded in the signed tag "Completed frotz feature"
> +appears here, and again that is why it is important for the contributor
> +to explain her work well when creating the signed tag.
> +
> +As usual, the lines commented with `#` are stripped out. The resulting
> +commit records the signed tag used for this validation in a hidden field
> +so that it can later be used by others to audit the history. There is no
> +need for the integrator to keep a separate copy of the tag in his
> +repository (i.e. `git tag -l` won't list frotz-for-xyzzy tag in the above
s/list/list the/
> +example), and there is no need to publish the tag to his public
> +repository, either.
> +
> +After the integrator responds to the pull request and her work becomes
> +part of the permanent history, the contributor can remove the tag from the
> +publishing repository, if she chooses, in order to keep the tag namespace
> +of her public repository clean, with:
> +
> +------------
> + $ git push example.com:/git/froboz.git :frotz-for-xyzzy
> +------------
> +
> +
> +Auditors
> +--------
> +
> +The `--show-signature` option can be given to `git log` or `git show` and
> +shows the verification status of the embedded signed tag in merge commits
> +created when the integrator responded to a pull request of a signed tag.
> +
> +A typical output from `git show --show-signature` may look like this:
> +
> +------------
> + $ git show --show-signature
> + commit 02306ef6a3498a39118aef9df7975bdb50091585
> + merged tag 'frotz-for-xyzzy'
> + gpg: Signature made Fri 06 Jan 2012 12:41:49 PM PST using RSA key ID 96AFE6CB
> + gpg: Good signature from "Con Tributor <nitfol@example.com>"
> + Merge: 406da78 703f05a
> + Author: Inte Grator <xyzzy@example.com>
> + Date: Tue Jan 17 13:49:41 2012 -0800
> +
> + Merge tag 'frotz-for-xyzzy'
> +
> + Completed frotz feature
> +
> + * tag 'frotz-for-xyzzy' (100 commits)
> + Add tests and documentation for frotz
> + ...
> +------------
> +
> +There is no need to fetch and keep a signed tag like `frotz-for-xyzzy`
> +that is used for frequent "pull" exchange in the long term just for such
> +auditing purposes, as the signature is recorded as part of the merge
> +commit.
I had trouble parsing this sentence. I think part of the problem is that
it's comparing the actual implementation to an earlier proposed design that
was rejected. So it's trying to sell the reader on a feature of the
implemented design, but the reader doesn't care.
How about this instead:
There is no need for the auditor to explicitly fetch the contributor's
signature, or to even be aware of what tag(s) the contributor and integrator
used to communicate the signature. All the required information is recorded
as part of the merge commit.
> +
> +
> +Footnotes
> +---------
> +
> +*1* This example uses the `-m` option to create a signed tag with just a
> +single liner message, but this is for illustration purposes only. It is
s/single liner/single-line/
> +advisable to compose a well-written explanation of what the topic does to
> +justify why it is worthwhile for the integrator to pull it, as this
> +message will eventually become part of the final history after the
> +integrator responds to the pull request.
> +
> +*2* The example uses plus at the beginning of `+frotz-for-xyzzy` to allow
> +forcing the update of a tag, as the same contributor may want to reuse a
> +signed tag with the same name after the previous pull request has already
> +been responded to.
M.
^ permalink raw reply
* Re: [PATCH] i18n: disable i18n for shell scripts if NO_GETTEXT defined
From: Alex Riesen @ 2012-01-18 14:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Ævar Arnfjörð
In-Reply-To: <7vfwfervt9.fsf@alter.siamese.dyndns.org>
On Tue, Jan 17, 2012 at 20:08, Junio C Hamano <gitster@pobox.com> wrote:
> Alex Riesen <raa.lkml@gmail.com> writes:
> Thanks for spotting. I agree that we should honor NO_GETTEXT here.
>
> But the result of the patch looks almost unreadable. could we restructure
> the script like this instead?
>
> # Decide what to do...
> GIT_INTERNAL_GETTEXT_SH_SCHEME=fallthrough
> if test -n "@@NO_GETTEXT@@$GIT_INTERNAL_GETTEXT_TEST_FALLBACKS"
> then
Oh, it is much nicer indeed. I shall redo the patch as soon as I get off
this crappy winxp computer.
^ permalink raw reply
* Looking for speakers on DVCS
From: Chris Westin @ 2012-01-18 13:57 UTC (permalink / raw)
To: git@vger.kernel.org
I organize the speakers for the Bay Area Large-Scale Production Engineering
meetup (http://www.meetup.com/SF-Bay-Area-Large-Scale-Production-Engineering/ ;
take a look at the "PAST" tab to see the kinds of events we've had).
For our February event, on Thursday February 16th
(http://www.meetup.com/SF-Bay-Area-Large-Scale-Production-Engineering/events/40058152/), I'm putting together an evening of talks on distributed version control systems, and am looking for speakers. I usually try to arrange three
20-25 minute talks around a single topic or theme -- this time it would be DVCSes.
If you're going to be in the Bay Area on that date, and could give a talk,
please contact me through that meetup, or at cwestin (at) yahoo (dot) com.
Thanks!
Chris Westin
^ permalink raw reply
* Re: Interactive rebase with submodules
From: John Keeping @ 2012-01-18 11:21 UTC (permalink / raw)
To: Jens Lehmann; +Cc: git
In-Reply-To: <4F15E83D.10509@web.de>
On 17/01/12 21:29, Jens Lehmann wrote:
> Am 17.01.2012 19:47, schrieb John Keeping:
>> This appears to be because the git-rebase--interactive script inspects whether there is anything to commit when `rebase --continue` is invoked by running:
>>
>> git diff-index --cached --quiet --ignore-submodules HEAD --
>
>> Is there a reason for the `--ignore-submodules` in this command? Removing that option results in the expected behaviour.
>
> Yes, removing it will help your use case but break others. The reason
> for that is that because submodules are not updated during a rebase
> it doesn't make sense to compare their HEAD to what is recorded in
> the superproject, as that might have been changed by an earlier
> commit. And as the submodules HEAD hasn't been updated back then,
> it is stale and will always show up as modified (even if it wasn't).
Is this worse than the current behaviour? If I perform a rebase where
there is a (non-submodule) conflict in a commit where a submodule
changes I can see something like:
# Changes to be committed:
# modified: path/to/submodule
#
# Unmerged paths:
# both modified: path/to/file
#
# Changes not staged for commit:
# modified: path/to/submodule (new commits)
This occurs if a later commit in the rebase will modify the submodule.
In this case, `rebase --continue` correctly recreates the commit once I
have resolved the conflict in the file, ignoring the unstaged submodule
changes.
>> I can understand not updating submodules while running the rebase, but I expected that having resolved a conflict and added my change to the index it would be applied by `git rebase --continue`, as indeed it is if there happen to be other (non-submodule) changes in the same commit.
>
> The irony is that you would have to update submodules (or at least
> their HEAD and use "--ignore-submodules=dirty") while running rebase
> to make that work in all cases ;-)
I don't this this is the case, since diff-tree is being invoked with
--cached won't it ignore changes in the work tree anyway?
> But just updating the HEAD would be dangerous as you would have to be
> very careful to restore the submodules HEAD after the rebase, or the
> submodule's work tree will be out of sync.
Just updating HEAD in the submodule without touching its work tree
doesn't seem like a good idea. I think it will cause a lot more
confusion when running `git status` which will show unexpected modified
content for the submodule.
Since I did not expect rebase to perform a submodule update, I was not
surprised to see unstaged submodule changes when rebasing, but I did
expect rebase to commit anything I had added to the index.
--
John
^ permalink raw reply
* Re: How to migrate a complex directory structure from SVN to GIT?
From: Michael Haggerty @ 2012-01-18 10:43 UTC (permalink / raw)
To: Asuka; +Cc: git
In-Reply-To: <1326828837924-7197567.post@n2.nabble.com>
On 01/17/2012 08:33 PM, Asuka wrote:
> I would like to migrate my svn repository to git. The structure looks like
> the following:
>
> svn
> |_Project1
> |_subproject1
> |_branches
> |_branch1
> |_branch2
> |_trunk
> |_tags
> |_tagv1
> |_Non-JavaProject
> |_subproject
> |_Project2
> |_AnotherSubproject
> |_SubSubproject
> |_Subproject2
> |_branches
> |_tags
> |_Subproject3
> |_trunk
> |_Subproject4
> |_Subsubproject
> |_branches
> |_tags
> |_trunk
>
> I would like to migrate all branches and tags
This can be confusing because Subversion confounds the namespace for
lines of development (trunk, branches, and tags) with those of filename
paths. The basic rule is: normally each trunk/branches/tag triplet
corresponds to a single project, and each project should be converted
into a separate git repository.
In your case it is hard to tell where the project boundaries are without
more information.
If some projects don't have branches or tags, that is OK; you can
configure git-svn pretty flexibly.
If some have branches and/or tags but not trunk, give it a try; I'm not
sure whether git-svn can handle it.
If some subprojects (including their trunk/branches/tags directories)
are nested within the source code of the enclosing projects (thus
entangling the namespaces), then you have chaos even in the Subversion
world. Such a mess can probably also be rescued, but it will be more
involved. For example, you might use svndumpfilter to strip
improperly-nested projects out of (copies of) your Subversion repository
*before* converting the enclosing project, or play some kind of
git-filter-branch tricks *after* the conversion.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: found some code...
From: Holger Hellmuth @ 2012-01-18 9:56 UTC (permalink / raw)
To: Ron Eggler; +Cc: Andrew Ardill, git
In-Reply-To: <2918969.0SyTOLELv0@reg-desktop>
On 18.01.2012 03:49, Ron Eggler wrote:
> On January 18, 2012 12:16:49 PM Andrew Ardill wrote:
>> Hi Ron,
>>
>> On 18 January 2012 12:02, Ron Eggler<ron.eggler@gmail.com> wrote:
>>> Hi There,
>>>
>>> Some mishap had happened with my project:
>>> I found a piece of code that is the most recent one that never got
>>> commited to the repository. It is dated December 5th and it definitely
>>> is the most recent piece of code.
>>> Now in the mean time I switched computers so I had to reinstall git and
>>> get create new local folders. Now this directory with the most recent
>>> code, shows every file as unversioned which should not be true.
>>> Only a couple, maybe 3 files had changed with that last change. Now when
>>> I commit this now, is that gonna mess up my old repo or can I safely
>>> gio ahead and commit that most recent code (even tho it might commit
>>> the whole folder) - it almost seems like it forgot which files
>>> were in the repo vs. which files were in my local folder...
Try "git update-index --refresh", more info in this recent thread
"http://comments.gmane.org/gmane.comp.version-control.git/188291"
If this doesn't help:
Human language is very ambiguous. What do you mean by "found a piece of
code"? Somewhere outside the repository, in a branch inside the
repository, in a subdirectory?
What do you mean by "get create new local folders"? Do you mean a folder
where you copied the repository or do you mean folders inside your
repository where you created new files with your editor?
^ 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