* 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
* 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
* 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
* 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: 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: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: [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
* 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
* [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
* 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
* 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: [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: [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: 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: 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
* [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: [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
* 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: post-update to stash after push to non-bare current branch
From: Junio C Hamano @ 2012-01-18 22:38 UTC (permalink / raw)
To: Neal Kreitzinger; +Cc: Neal Kreitzinger, git
In-Reply-To: <4F1714AD.4090706@gmail.com>
Neal Kreitzinger <nkreitzinger@gmail.com> writes:
> 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)
Have you checked where in the filesystem hierarchy that script is run
(hint: pwd)?
Also it is unclear why you keep saying "stash". What kind of changes are
you expecting to be saved to the stash? Will they be changes that are not
source controlled that you would rather not to see? In other words, after
running "stash" every time somebody pushes and having accumulated many
stash entries, when do you plan to pop these stashed changes?
I would have expect that such a repository to reject a push if the working
tree is dirty, and run checkout in post-update, though.
^ permalink raw reply
* Re: Checking out orphans with -f
From: Junio C Hamano @ 2012-01-18 22:40 UTC (permalink / raw)
To: Martin Fick; +Cc: git
In-Reply-To: <201201181207.05967.mfick@codeaurora.org>
Martin Fick <mfick@codeaurora.org> writes:
> 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
What do you mean by "abandon"?
If you want to remove a branch "a" because you do not need it, you can
check out some other branch and say "git branch -D a", no?
^ permalink raw reply
* Re: Checking out orphans with -f
From: Martin Fick @ 2012-01-18 22:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsjjcljmj.fsf@alter.siamese.dyndns.org>
On Wednesday, January 18, 2012 03:40:36 pm Junio C Hamano
wrote:
> Martin Fick <mfick@codeaurora.org> writes:
> > 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
>
> What do you mean by "abandon"?
>
> If you want to remove a branch "a" because you do not
> need it, you can check out some other branch and say
> "git branch -D a", no?
By abandon, I simply mean to check out another branch, which
as you point, I can almost do. I just can't do it by
checking out another orphaned branch! Why not, this seems
inconsistent? In both cases I loose what the original
orphaned branch (a) is, so why prevent me from doing it in
the one case and not the other?
-Martin
--
Employee of Qualcomm Innovation Center, Inc. which is a
member of Code Aurora Forum
^ permalink raw reply
* Re: found some code...
From: Holger Hellmuth @ 2012-01-18 22:45 UTC (permalink / raw)
To: Ron Eggler; +Cc: Andrew Ardill, git
In-Reply-To: <CAHxBh_QiZzJP2jS6rMpC1c=P8uXSbFWumbcnHj3ArkQB4sXyPQ@mail.gmail.com>
Mmh, your reply here didn't make it to the mailing list, maybe because
it was multipart with html(??) or it just got lost.
Am 18.01.2012 18:57, schrieb Ron Eggler:
> Try "git update-index --refresh", more info in this recent thread
> "http://comments.gmane.org/__gmane.comp.version-control.__git/188291
> <http://comments.gmane.org/gmane.comp.version-control.git/188291>"
>
>
> I got this outputand nothing really changed(generally using TortoiseGit
> on Windows but did this in the provided bash shell):
> $ git update-index --refresh
> MCU2.COF.txt: needs update
> MCU2.bak: needs update
> MCU2.c: needs update
> MCU2.esym: needs update
> MCU2.h: needs update
> MCU2.hex: needs update
> MCU2.lst: needs update
> MCU2.mcp: needs update
[...]
Ok, "needs update" seems to be the non-porcelain version of 'M' (why 'M'
is more porcelain than "needs update" is a mystery to me ;-) respective
"Changes not staged for commit" in git status.
Well, what does it say when you do "git diff MCU2.h" ? There are 2
possibilities:
1) You see code differences. In that case you should be able to
recognize where and when these changes were comitted or not.
2) You see no difference or every line is listed as different even
though they seem to be equal. Possible reason is a mixup of line endings
as git on windows has to convert \r\n line endings to \n line endings
when it checks data in. This is controlled by config variables, and
maybe your config is slightly wrong.
In that case I would create a new repo with git init in bash (not
tortoise git!), and look at .git/config. Compare that with .git/config
of your mixed up repo. Also compare with .git/config of the repo on your
usb stick. As far as I know you should have core.autocrlf set to true on
Windows.
Alternatively or for a complete picture you could do "git config -l"
which gives you also global and system configuration variables if they
exist.
Another possible reason would be file names with same name but different
case. I mention this because there is a parallel thread on this mailing
list with a problem with tortoise git and windows. See
http://git.661346.n2.nabble.com/Bug-Git-checkout-fails-with-a-wrong-error-message-td7181244.html.
As suggested in that thread you should have the option core.ignorecase set.
> Ok ,let's see:
> I "found" the piece of code on my thumbdrive and it ultimately is copied
> from my "old" working directory from the computer i don't have
> anymore... "get create new local folders" means that I actually created
> a new folder on my new machine and cloned the repo from git into it so
> this would be my new working directory... now i have the code that
> should be in there seperatetely in the directory from the thumb drive....
> Does that make any more ssense?
>
^ permalink raw reply
* Re: Checking out orphans with -f
From: Martin Fick @ 2012-01-18 22:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsjjcljmj.fsf@alter.siamese.dyndns.org>
On Wednesday, January 18, 2012 03:40:36 pm Junio C Hamano
wrote:
> Martin Fick <mfick@codeaurora.org> writes:
> > 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
>
> What do you mean by "abandon"?
>
> If you want to remove a branch "a" because you do not
> need it, you can check out some other branch and say
> "git branch -D a", no?
Actually, no I can't. I can check out some other branch
(assuming I have one), but I cannot then delete a, it
appears to already be deleted by virtue of checking out
another branch. I like that since I never checked it in,
better to clean up the garbage, but why can't I then
checkout another orphan to do the same thing?
-Martin
--
Employee of Qualcomm Innovation Center, Inc. which is a
member of Code Aurora Forum
^ permalink raw reply
* Re: [PATCH] git-add: allow --ignore-missing always, not just in dry run
From: Junio C Hamano @ 2012-01-18 22:56 UTC (permalink / raw)
To: Dieter Plaetinck; +Cc: git
In-Reply-To: <1326923544-8287-1-git-send-email-dieter@plaetinck.be>
Dieter Plaetinck <dieter@plaetinck.be> writes:
> 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>
Sorry, but for this kind of change, we would want to see a justification
that is much better than that. The default around here is not to change an
established behaviour without a good reason.
Have you dug into the list archive to see _why_ we decided not to allow
this option in the real run in the first place? You would need to find "By
letting the command ignore missing paths, the user can get into X and Y
situations and we would want to avoid it. We however need to give users a
way to see if there is something missing, hence we add it when we are
under dry-run option." and refute that previous justification, arguing why
X and Y is something we should _not_ be worrying about, to make a good
case for this change.
In this particular case, my gut feeling is that this might a change in the
good direction (but I strongly suspect that I am not recalling the real
reason why we didn't allow it when we introduced this option).
If somebody is writing a script using "git add" (which is not recommended
to begin with), it is tempting to say 'git add $list_of_possible_files' in
such a script when the script _knows_ that the list it is giving to "git
add" may contain a path that does not exist, and wants to ignore missing
ones.
But then the script could easily filter what does not exist before
compiling such a list, so that is not a very strong reason to advocate
it.
^ permalink raw reply
* Interesting behavior in git mergetool with no BASE revision
From: Jason Wenger @ 2012-01-18 23:05 UTC (permalink / raw)
To: git
Doing a git merge on 1.7.4.3, on a case where both branches have a
file created, and the base does not. Per git-mergetool:
"the configured command line will be invoked with $BASE set to the
name of a temporary file containing the common base for the merge, if
available;"
So testing in this case, I set my mergetool cmd as "echo $MERGED
$LOCAL $REMOTE $BASE", and I get the following:
cio/.cproject ./cio/.cproject.LOCAL.9029.cproject
./cio/.cproject.REMOTE.9029.cproject
./cio/.cproject.BASE.9029.cproject
ls -a cio shows the following files:
.cproject
.cproject.LOCAL.9325.cproject
.cproject.BACKUP.9325.cproject
.cproject.REMOTE.9325.cproject
So the lack of base file makes sense -- There is no base to start
from. However, $BASE evaluates to ./cio/.cproject.BASE.9029.cproject,
which is a nonexistent file. This makes my actual mergetool upset to
no end. Intuitively from documents, I would expect $BASE to evaluate
to an empty string in this case.
Is this intended behavior?
--Jason C. Wenger
^ 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