* Re: [PATCH 1/2] t/test-lib.sh: support Korn shell by converting GIT_EXIT_OK to GIT_EXIT_CODE
From: Junio C Hamano @ 2009-10-10 0:57 UTC (permalink / raw)
To: Brandon Casey; +Cc: Brandon Casey, git, drizzd, peff
In-Reply-To: <ee63ef30910091537i40a8cc68y2513f07c91fb35b@mail.gmail.com>
Brandon Casey <drafnel@gmail.com> writes:
> I'm away from a computer right now. Junio, if gmail is showing me the
> entirety of your workaround, then no, I don't think that will work.
> Your code will always exit non-zero, but there are cases where 'exit
> 0' is called and a '0' exit status is desired. e.g. when test_done is
> called.
Ah, of course you are right.
^ permalink raw reply
* Re: [PATCH v2] git-send-email.perl: fold multiple entry "Cc:" and multiple single line "RCPT TO:"s
From: Junio C Hamano @ 2009-10-10 0:57 UTC (permalink / raw)
To: Joe Perches; +Cc: git, Jay Soffian
In-Reply-To: <1255021406.2056.122.camel@Joe-Laptop.home>
This breaks t9001 since it expects an old (and probably incorrect) RCPT TO:
lines. I fixed them up.
^ permalink raw reply
* Re: [PATCH v2 (amend)] gitweb: Do not show 'patch' link for merge commits
From: Junio C Hamano @ 2009-10-10 0:56 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Jeff King, Junio Hamano
In-Reply-To: <200910091426.44976.jnareb@gmail.com>
Thanks.
^ permalink raw reply
* Re: [PATCHv4] git-log --format: Add %B tag with %B(n) option
From: Junio C Hamano @ 2009-10-10 0:57 UTC (permalink / raw)
To: Johannes Gilger; +Cc: Git Mailing List, Johannes Schindelin
In-Reply-To: <1253655038-20335-1-git-send-email-heipei@hackvalue.de>
Johannes Gilger <heipei@hackvalue.de> writes:
> diff --git a/pretty.c b/pretty.c
> index f5983f8..dafa8e0 100644
> --- a/pretty.c
> +++ b/pretty.c
> @@ -605,13 +605,17 @@ static size_t format_commit_item(struct strbuf *sb, const char *placeholder,
> int h1, h2;
>
> /* these are independent of the commit */
> +
> + const char *body = msg + c->body_off;
> + const char *end = NULL;
Unfortunately, c->body_off is not valid until you make a call to
parse_commit_message(). Obviously, body is used only after such a call is
made in the original, so I fixed this initialization into an explicit
assignment after the call.
^ permalink raw reply
* Re: [PATCH 1/8] imap-send: remove useless uid code
From: Junio C Hamano @ 2009-10-10 0:57 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Erik Faye-Lund, git, gitster, Jeff King, Erik Faye-Lund
In-Reply-To: <fabb9a1e0910090821n67c86d0kb4eef1b9ff4bdff1@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> Please include a cover letter for series as long as these (anything
> larger than 4 should have a cover letter IMHO). Doing so makes it
> easier for those that follow the series to see what changed (assuming
> you write down what changed in the cover letter). Also, it makes it
> easier for those that were not following the series to drop in at the
> current version (assuming you provide a short summary of what the
> series is about in the cover letter)..
Thanks.
^ permalink raw reply
* Re: Confusing git pull error message
From: Junio C Hamano @ 2009-10-10 0:57 UTC (permalink / raw)
To: Jeff King; +Cc: Nanako Shiraishi, Johannes Sixt, John Tapsell, Git List
In-Reply-To: <7vy6nl10fg.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Nanako Shiraishi <nanako3@lavabit.com> writes:
>
>> Quoting Jeff King <peff@peff.net>
>>
>>> Subject: [PATCH] pull: improve advice for unconfigured error case
>>> ...
>> Junio, may I ask what happened to this patch?
>
> Thanks for prodding. Unfortunately I lost track. Will look at it again
> but probably not tonight.
Applied the patch as-is, as it looked quite good.
Thanks.
^ permalink raw reply
* [PATCH] git-gui: Fixed _main window_ for screen height equal 600 px
From: Vietor Liu @ 2009-10-10 0:59 UTC (permalink / raw)
To: spearce; +Cc: git
When the screen height equal 600 px(e.g. Asus EeePC 1024x600), The
_main window_ should be hide the _Push button_ and _Status bar_.
Signed-off-by: Vietor Liu <vietor.liu@gmail.com>
---
git-gui.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index 09b2720..037a1f2 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -3083,7 +3083,7 @@ frame .vpane.lower.diff.body
set ui_diff .vpane.lower.diff.body.t
text $ui_diff -background white -foreground black \
-borderwidth 0 \
- -width 80 -height 15 -wrap none \
+ -width 80 -height 5 -wrap none \
-font font_diff \
-xscrollcommand {.vpane.lower.diff.body.sbx set} \
-yscrollcommand {.vpane.lower.diff.body.sby set} \
--
1.6.5.rc3
^ permalink raw reply related
* Re: [PATCH 9/9] racy-git.txt: explain nsec problem in more detail
From: Junio C Hamano @ 2009-10-10 0:56 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
In-Reply-To: <20091009102554.GI16558@progeny.tock>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Am I understanding the problem here correctly?
I think so ;-).
^ permalink raw reply
* Re: [PATCH 6/9] Documentation: branch: update --merged description
From: Junio C Hamano @ 2009-10-10 0:56 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
In-Reply-To: <20091009101858.GF16558@progeny.tock>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Update the documentation for --merged and --no-merged to explain
> the meaning of the optional parameter introduced in commit 049716b
> (branch --merged/--no-merged: allow specifying arbitrary commit,
> 2008-07-08).
>
> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Thanks.
I most often use --no-merged this way:
$ git branch --no-merged pu
to see topics that are queued but not merged anywhere. This is not about
"do not list", but "do show the ones that are not merged", so I reworded
the description of the latter in your patch.
> diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
> index aad71dc..e8b32a2 100644
> --- a/Documentation/git-branch.txt
> +++ b/Documentation/git-branch.txt
> @@ -134,11 +134,13 @@ start-point is either a local or remote branch.
> --contains <commit>::
> Only list branches which contain the specified commit.
>
> ---merged::
> - Only list branches which are fully contained by HEAD.
> +--merged [<commit>]::
> + Only list branches whose tips are reachable from the
> + specified commit (HEAD if not specified).
>
> ---no-merged::
> - Do not list branches which are fully contained by HEAD.
> +--no-merged [<commit>]::
> + Only list branches whose tips are not reachable from the
> + specified commit (HEAD if not specified).
>
> <branchname>::
> The name of the branch to create or delete.
> --
> 1.6.5.rc1.199.g596ec
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 5/9 v2] Documentation: clone: clarify discussion of initial branch
From: Jonathan Nieder @ 2009-10-09 23:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vskdsqlvh.fsf@alter.siamese.dyndns.org>
When saying the initial branch is equal to the currently active
remote branch, it is probably intended that the branch heads
point to the same commit. Maybe it would be more useful to a
new user to emphasize that the tree contents and history are the
same.
More important, probably, is that this new branch is set up so
that "git pull" merges changes from the corresponding remote
branch. The next paragraph addresses that directly. What the
reader needs to know to begin with is that (1) the initial branch
is your own; if you do not pull, it won't get updated, and that
(2) the initial branch starts out at the same commit as the
upstream.
Thanks to Junio C Hamano for the wording.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Junio C Hamano wrote:
> Perhaps
>
> ... creates and checks out an initial branch that is forked from the
> cloned repository's currently active branch.
>
> would convey that (1) the initial branch is your own; if you do not pull,
> you won't get updated, and that (2) the initial branch starts out at the
> same commit as the upstream.
That does work better. Explanation stolen for the commit message ---
I hope you don't mind.
Thanks,
Jonathan
Documentation/git-clone.txt | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index aacf4fd..5ebcba1 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -19,8 +19,9 @@ DESCRIPTION
Clones a repository into a newly created directory, creates
remote-tracking branches for each branch in the cloned repository
-(visible using `git branch -r`), and creates and checks out an initial
-branch equal to the cloned repository's currently active branch.
+(visible using `git branch -r`), and creates and checks out an
+initial branch that is forked from the cloned repository's
+currently active branch.
After the clone, a plain `git fetch` without arguments will update
all the remote-tracking branches, and a `git pull` without
--
1.6.5.rc1.199.g596ec
^ permalink raw reply related
* Re: [PATCH 1/2] t/test-lib.sh: support Korn shell by converting GIT_EXIT_OK to GIT_EXIT_CODE
From: Brandon Casey @ 2009-10-09 22:37 UTC (permalink / raw)
To: Junio C Hamano, Brandon Casey, git, drizzd, peff
In-Reply-To: <7vhbu8s151.fsf@alter.siamese.dyndns.org>
I'm away from a computer right now. Junio, if gmail is showing me the
entirety of your workaround, then no, I don't think that will work.
Your code will always exit non-zero, but there are cases where 'exit
0' is called and a '0' exit status is desired. e.g. when test_done is
called.
I'll look more closely at the suggestions when I get back to a computer.
-brandon
On 10/9/09, Junio C Hamano <gitster@pobox.com> wrote:
> Brandon Casey <casey@nrlssc.navy.mil> writes:
>
>> From: Brandon Casey <drafnel@gmail.com>
>>
>> Commit 6e7b5aaf introduced the concept of GIT_EXIT_OK as a way to indicate
>> to die(), the exit handler, whether the exit was initiated by the test
>> harness, or whether it was unexpected. die() expects $? to contain the
>> value passed to exit(), and when GIT_EXIT_OK is set, die() calls exit with
>> the value in $?. This works as expected when using the Bash shell. For
>> the Korn shell, $? has the value of the last executed statement _before_
>> the call to exit. If that statement completed successfully, then die()
>> would incorrectly exit with a successful status when GIT_EXIT_OK is set.
>
> That's somewhat unexpected, as I did not think this was an anomaly in
> bash. FWIW, dash seems to behave the same way.
>
> The environment in which the shell executes a trap on EXIT shall be
> identical to the environment immediately after the last command executed
> before the trap on EXIT was taken.
>
> If the trap action was triggered because somebody called "exit 13", $? is
> expected to contain that value, because that is the last command executed
> before the trap on EXIT was taken, no?
>
>> So, rather than relying on the behavior of Bash in order to get the exit
>> code from $? inside die(), change GIT_EXIT_OK into GIT_EXIT_CODE, and set
>> it to the code that we want to exit with. This allows the test suite to
>> be run with the Korn shell.
>
> I wonder if the attached is a more clear and contained workaround for this
> issue.
>
> ---
> t/test-lib.sh | 9 ++++++++-
> 1 files changed, 8 insertions(+), 1 deletions(-)
>
> diff --git a/t/test-lib.sh b/t/test-lib.sh
> index f2ca536..c47a295 100644
> --- a/t/test-lib.sh
> +++ b/t/test-lib.sh
> @@ -185,7 +185,14 @@ die () {
> code=$?
> if test -n "$GIT_EXIT_OK"
> then
> - exit $code
> + # Korn does not update $? when "exit 47" triggers
> + # the EXIT trap.
> + if test $code = 0
> + then
> + exit 1
> + else
> + exit $code
> + fi
> else
> echo >&5 "FATAL: Unexpected exit with code $code"
> exit 1
>
--
Sent from my mobile device
^ permalink raw reply
* Re: Merging non-git releases of a project
From: Avery Pennarun @ 2009-10-09 22:43 UTC (permalink / raw)
To: Howard Miller; +Cc: git
In-Reply-To: <26ae428a0910091433v2c959a70g9bfc6c54382f370d@mail.gmail.com>
On Fri, Oct 9, 2009 at 5:33 PM, Howard Miller
<howard@e-learndesign.co.uk> wrote:
> I'm missing the point here though. Where/when do I actually add the
> new pristine code? If I checkout, as you suggest, my initial commit I
> just have (say) v1.0 of the vendor's code. I can't just copy (say)
> version 1.2 on top as the files probably won't match one-one.
>
> Sorry - I'm probably completely failing to understand.
Try this:
cd mygitproject
git rm -rf .
cp -a /tmp/wherever/vendor-1.2/. .
git add .
git commit
Don't worry, git won't double-store files that are identical between
the old 1.0 and new 1.2 versions.
Avery
^ permalink raw reply
* Re: gitweb - bare repos integration - owner info in description file
From: Eugene Sajine @ 2009-10-09 22:32 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3ab00gr25.fsf@localhost.localdomain>
>
> RTFM (in this case gitweb/README). gitweb.owner and gitweb.description
> configuration variables in per-repository config.
>
Ok, my bad, didn't get there;)It is good to know there are places
where to keep the info. But it is not the point. The point is to
integrate gitweb with bare repo creation more than it is right now by
providing keys which will help filling out this info at the bare repo
creation stage.
shortly i'm talking about command like this (the key names are for sample only):
$ git clone --bare repo repo.git -desc "description" -gwowner
"gitwebowner@server.com" -cloneurl "git://host/repo.git"
seems to me quite comfy, and no headache...
> %
> "To be fair, there are uses for XML. On Halloween, for example."
>
> - Johannes Schindelin, on git@vger.kernel.org
> %
yeah, to show kids xml print outs as an answer to "trick or treat!".
Can save on candies;)
Thanks,
Eugene
^ permalink raw reply
* Re: [PATCH] bash: add support for 'git replace'
From: Shawn O. Pearce @ 2009-10-09 22:19 UTC (permalink / raw)
To: Bj??rn Gustavsson; +Cc: git
In-Reply-To: <4ACFA1C2.6020001@gmail.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
> +_git_replace ()
> +{
> + __gitcomp "$(__git_refs)"
> +}
> +
> _git_reset ()
> {
> __git_has_doubledash && return
> @@ -2162,6 +2167,7 @@ _git ()
> push) _git_push ;;
> rebase) _git_rebase ;;
> remote) _git_remote ;;
> + replace) _git_replace ;;
--
Shawn.
^ permalink raw reply
* Re: gitweb - bare repos integration - owner info in description file
From: Jakub Narebski @ 2009-10-09 22:07 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git
In-Reply-To: <76c5b8580910091350o5cd90d3dobe2a21c18fa56dfd@mail.gmail.com>
Eugene Sajine <euguess@gmail.com> writes:
> Here is another issue with gitweb integration which i think might be
> considered as a feature proposal:
>
> I have a central place where bare repos are. They're owned by the user
> under which we are serving them, let's say “git”. So, gitweb is going
> to show me
>
> Repo1 owner git etc…
>
> In order to show a real owner I have to rebuild gitweb.cgi, to tell it
> to use the file for GITWEB_LIST and edit the file… In fact I think
> gitweb shouldn’t carry this info, but bare repos should.
It is not gitweb that carries this info, but file with list of
repositories (GITWEB_LIST). And you can pre-generate this file using
gitweb.
>
> So my idea is:
>
> Either provide a key to
> $ git clone –bare –u “owner/email”
>
> or take the user.email parameter from .gitconfig.
>
> in both cases the info can go to description file of bare repo, so it
> can look like:
>
> $owner=owner@server.com
>
> $description=”very long description”
RTFM (in this case gitweb/README). gitweb.owner and gitweb.description
configuration variables in per-repository config.
>
> Or in xml form…
Aaaaaaaaaaaaaaaaaaaaaaaa...
%
"To be fair, there are uses for XML. On Halloween, for example."
- Johannes Schindelin, on git@vger.kernel.org
%
>
>
> Yes, description file might become a bit more complicated in its
> layout. But, the benefits are obvious:
>
> - No need to support multiple lists/files
> - Bare repo carries all info about itself (together with –d feature I
> described earlier).
>
> I this circumstances gitweb’s GITWEB_LIST will be only filter (only
> repo path is necessary to show/not show), and it seems that narrowed
> functionality here is a good thing...
GITWEB_LIST is meant for the case when you want to avoid scanning
filesystem for git repositories. And you can filter out repositories
without using GITWEB_LIST (see documentation).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: can't create a branch on remote
From: Jakub Narebski @ 2009-10-09 22:08 UTC (permalink / raw)
To: Auguste Mome; +Cc: git
In-Reply-To: <17cb70ee0910091435l4c4d1736hf4d403a2fe6331a2@mail.gmail.com>
Auguste Mome <augustmome@gmail.com> writes:
> Hi,
> I have two repositories /home/user/linux and /home/user/dev/linux,
> same user on same machine.
> Here is how I create a local branch at v2.6.21.7 in /home/user/dev/linux,
> #pwd
> /home/user/dev/linux
> # git remote add l2621
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.21.y.git
> # git fetch l2621
> # git branch mylocal26217 v2.6.21.7
>
> Now I would like to do the same from the other repository /home/user/linux:
> # pwd
> /home/user/linux
> # git remote add other /home/guerin/dev/git/linux-2.6
> # git fetch other
> # git push /home/user/dev/git/linux-2.6
> v2.6.21.7:refs/heads/new_feature_name26217
> Total 0 (delta 0), reused 0 (delta 0)
> error: Trying to write non-commit object
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 170684ef0557d4b711a86595d31dcbebcb9d4ba2 to branch
> refs/heads/new_feature_name26217
> To /home/user/dev/git/linux-2.6
> ! [remote rejected] v2.6.21.7 -> new_feature_name26217 (failed to write)
> error: failed to push some refs to '/home/user/dev/git/linux-2.6'
>
> Maybe something to configure to authorize the creation of branch?
You can't push tag to branch.
I'm not sure if what you are trying to do makes sense at all, but the
commit pointed by v2.6.21.7 is v2.6.21.7^{}
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: can't create a branch on remote
From: Björn Steinbrink @ 2009-10-09 21:54 UTC (permalink / raw)
To: Auguste Mome; +Cc: git
In-Reply-To: <17cb70ee0910091435l4c4d1736hf4d403a2fe6331a2@mail.gmail.com>
On 2009.10.09 23:35:03 +0200, Auguste Mome wrote:
> # git branch mylocal26217 v2.6.21.7
This automatically peels the v2.6.21.7 tag to get the commit object, and
creates the new branch head, referencing that commit.
> # git push /home/user/dev/git/linux-2.6
> v2.6.21.7:refs/heads/new_feature_name26217
> Total 0 (delta 0), reused 0 (delta 0)
> error: Trying to write non-commit object
> 170684ef0557d4b711a86595d31dcbebcb9d4ba2 to branch
> refs/heads/new_feature_name26217
This didn't peel the tag, because you might actually want the remote ref
to reference the tag, not the commit referenced by the tag. So you tried
to create a branch head that would reference a tag, and that is not
allowed. To peel the tag you can use:
v2.6.21.7^0
v2.6.21.7^{commit}
v2.6.21.7^{}
The first two ensure that you actually get a commit object or an error,
the last one just peels the tag until it finds a non-tag object.
So:
git push /home/user/dev/git/linux-2.6 \
v2.6.21.7^0:refs/heads/new_feature_name26217
should do the trick.
Though I don't see why you would create a branch like that. Usually, I'd
expect you to create new_feature_name26217 locally, work on it, and then
just push that branch head, instead of creating that rather pointless
branch head remotely.
Björn
^ permalink raw reply
* Re: [PATCH 5/9] Documentation: clone: clarify discussion of initial branch
From: Junio C Hamano @ 2009-10-09 21:48 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
In-Reply-To: <20091009101825.GE16558@progeny.tock>
Jonathan Nieder <jrnieder@gmail.com> writes:
> When saying the initial branch is equal to the currently active
> remote branch, it is probably intended that the branch heads
> point to the same commit. Maybe it would be more useful to a new
> user to emphasize that the tree contents and history are the
> same.
>
> More important, probably, is that this new branch is set up so
> that "git pull" merges changes from the corresponding remote
> branch.
All true, and "with the contents of" is dropping the "history" part.
Perhaps
... creates and checks out an initial branch that is forked from the
cloned repository's currently active branch.
would convey that (1) the initial branch is your own; if you do not pull,
you won't get updated, and that (2) the initial branch starts out at the
same commit as the upstream.
> clarifying the initial content of the branch should make it
> clearer why a pull is required at all (that local and remote
> branches each have their own history after the clone).
>
> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
> ---
> Documentation/git-clone.txt | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
> index aacf4fd..7cd06e2 100644
> --- a/Documentation/git-clone.txt
> +++ b/Documentation/git-clone.txt
> @@ -20,7 +20,8 @@ DESCRIPTION
> Clones a repository into a newly created directory, creates
> remote-tracking branches for each branch in the cloned repository
> (visible using `git branch -r`), and creates and checks out an initial
> -branch equal to the cloned repository's currently active branch.
> +branch with the contents of the cloned repository's currently active
> +branch.
>
> After the clone, a plain `git fetch` without arguments will update
> all the remote-tracking branches, and a `git pull` without
> --
> 1.6.5.rc1.199.g596ec
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* can't create a branch on remote
From: Auguste Mome @ 2009-10-09 21:35 UTC (permalink / raw)
To: git
Hi,
I have two repositories /home/user/linux and /home/user/dev/linux,
same user on same machine.
Here is how I create a local branch at v2.6.21.7 in /home/user/dev/linux,
#pwd
/home/user/dev/linux
# git remote add l2621
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.21.y.git
# git fetch l2621
# git branch mylocal26217 v2.6.21.7
Now I would like to do the same from the other repository /home/user/linux:
# pwd
/home/user/linux
# git remote add other /home/guerin/dev/git/linux-2.6
# git fetch other
# git push /home/user/dev/git/linux-2.6
v2.6.21.7:refs/heads/new_feature_name26217
Total 0 (delta 0), reused 0 (delta 0)
error: Trying to write non-commit object
170684ef0557d4b711a86595d31dcbebcb9d4ba2 to branch
refs/heads/new_feature_name26217
To /home/user/dev/git/linux-2.6
! [remote rejected] v2.6.21.7 -> new_feature_name26217 (failed to write)
error: failed to push some refs to '/home/user/dev/git/linux-2.6'
Maybe something to configure to authorize the creation of branch?
Thanks,
Auguste.
^ permalink raw reply
* Re: [PATCH 1/2] t/test-lib.sh: support Korn shell by converting GIT_EXIT_OK to GIT_EXIT_CODE
From: Junio C Hamano @ 2009-10-09 21:33 UTC (permalink / raw)
To: Brandon Casey; +Cc: git, drizzd, peff, Brandon Casey
In-Reply-To: <1eweIwf5YoFwmLPWwEFN69a2f-EUnj_kgiagVJoVQYfNQeLjlpm12U84RKxhzjh0NJv36SqO12lAX2c_x0WSgA@cipher.nrlssc.navy.mil>
Brandon Casey <casey@nrlssc.navy.mil> writes:
> From: Brandon Casey <drafnel@gmail.com>
>
> Commit 6e7b5aaf introduced the concept of GIT_EXIT_OK as a way to indicate
> to die(), the exit handler, whether the exit was initiated by the test
> harness, or whether it was unexpected. die() expects $? to contain the
> value passed to exit(), and when GIT_EXIT_OK is set, die() calls exit with
> the value in $?. This works as expected when using the Bash shell. For
> the Korn shell, $? has the value of the last executed statement _before_
> the call to exit. If that statement completed successfully, then die()
> would incorrectly exit with a successful status when GIT_EXIT_OK is set.
That's somewhat unexpected, as I did not think this was an anomaly in
bash. FWIW, dash seems to behave the same way.
The environment in which the shell executes a trap on EXIT shall be
identical to the environment immediately after the last command executed
before the trap on EXIT was taken.
If the trap action was triggered because somebody called "exit 13", $? is
expected to contain that value, because that is the last command executed
before the trap on EXIT was taken, no?
> So, rather than relying on the behavior of Bash in order to get the exit
> code from $? inside die(), change GIT_EXIT_OK into GIT_EXIT_CODE, and set
> it to the code that we want to exit with. This allows the test suite to
> be run with the Korn shell.
I wonder if the attached is a more clear and contained workaround for this
issue.
---
t/test-lib.sh | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index f2ca536..c47a295 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -185,7 +185,14 @@ die () {
code=$?
if test -n "$GIT_EXIT_OK"
then
- exit $code
+ # Korn does not update $? when "exit 47" triggers
+ # the EXIT trap.
+ if test $code = 0
+ then
+ exit 1
+ else
+ exit $code
+ fi
else
echo >&5 "FATAL: Unexpected exit with code $code"
exit 1
^ permalink raw reply related
* Re: Merging non-git releases of a project
From: Howard Miller @ 2009-10-09 21:33 UTC (permalink / raw)
To: Avery Pennarun; +Cc: git
In-Reply-To: <32541b130910091427i7c8a2426hb69a9914aabde8bc@mail.gmail.com>
Hi, Thanks!
I'm missing the point here though. Where/when do I actually add the
new pristine code? If I checkout, as you suggest, my initial commit I
just have (say) v1.0 of the vendor's code. I can't just copy (say)
version 1.2 on top as the files probably won't match one-one.
Sorry - I'm probably completely failing to understand.
2009/10/9 Avery Pennarun <apenwarr@gmail.com>:
> On Fri, Oct 9, 2009 at 5:11 PM, Howard Miller
> <howard@e-learndesign.co.uk> wrote:
>> Here's my dilemma.... I've used git extensively to track modifications
>> made to a reasonably large source tree. I do not have access to the
>> repository for that project, just a given release. I have now acquired
>> the latest version of that project and I want to 'merge' (not sure
>> that's the right word in this case) my changes into the new version.
>> Then I need to carry on using git for further changes. I think it
>> should be simple but I can't get my head around the best way to do
>> this.
>
> Find out the commitid of the first commit when you checked in the
> upstream project into git, and call it C1.
>
> git checkout -b vendor C1
>
> (replacing C1 with the commitid). This creates a branch called
> 'vendor' which is for checking in *only* the pristine code provided by
> the vendor. It also checks out this new branch.
>
> Next, import the new upstream version of the project and commit it to
> the 'vendor' branch.
>
> Now, switch back to your branch and merge in the vendor changes:
>
> git checkout master
> git merge vendor
>
> Or, if you want to produce a clean set of patches on top of the vendor
> version (ie. for submitting the individual patches upstream), you
> might want something like this instead:
>
> git rebase vendor
>
> But be careful, rebasing can make a mess of your history and you
> shouldn't do it unless you have a good reason.
>
> Good luck.
>
> Avery
>
^ permalink raw reply
* Re: Merging non-git releases of a project
From: Avery Pennarun @ 2009-10-09 21:27 UTC (permalink / raw)
To: Howard Miller; +Cc: git
In-Reply-To: <26ae428a0910091411i39a03650o51163f794b984524@mail.gmail.com>
On Fri, Oct 9, 2009 at 5:11 PM, Howard Miller
<howard@e-learndesign.co.uk> wrote:
> Here's my dilemma.... I've used git extensively to track modifications
> made to a reasonably large source tree. I do not have access to the
> repository for that project, just a given release. I have now acquired
> the latest version of that project and I want to 'merge' (not sure
> that's the right word in this case) my changes into the new version.
> Then I need to carry on using git for further changes. I think it
> should be simple but I can't get my head around the best way to do
> this.
Find out the commitid of the first commit when you checked in the
upstream project into git, and call it C1.
git checkout -b vendor C1
(replacing C1 with the commitid). This creates a branch called
'vendor' which is for checking in *only* the pristine code provided by
the vendor. It also checks out this new branch.
Next, import the new upstream version of the project and commit it to
the 'vendor' branch.
Now, switch back to your branch and merge in the vendor changes:
git checkout master
git merge vendor
Or, if you want to produce a clean set of patches on top of the vendor
version (ie. for submitting the individual patches upstream), you
might want something like this instead:
git rebase vendor
But be careful, rebasing can make a mess of your history and you
shouldn't do it unless you have a good reason.
Good luck.
Avery
^ permalink raw reply
* Merging non-git releases of a project
From: Howard Miller @ 2009-10-09 21:11 UTC (permalink / raw)
To: git
Here's my dilemma.... I've used git extensively to track modifications
made to a reasonably large source tree. I do not have access to the
repository for that project, just a given release. I have now acquired
the latest version of that project and I want to 'merge' (not sure
that's the right word in this case) my changes into the new version.
Then I need to carry on using git for further changes. I think it
should be simple but I can't get my head around the best way to do
this.
Any pointers appreciated!
^ permalink raw reply
* gitweb - bare repos integration - owner info in description file
From: Eugene Sajine @ 2009-10-09 20:50 UTC (permalink / raw)
To: git
Hi,
Here is another issue with gitweb integration which i think might be
considered as a feature proposal:
I have a central place where bare repos are. They're owned by the user
under which we are serving them, let's say “git”. So, gitweb is going
to show me
Repo1 owner git etc…
In order to show a real owner I have to rebuild gitweb.cgi, to tell it
to use the file for GITWEB_LIST and edit the file… In fact I think
gitweb shouldn’t carry this info, but bare repos should.
So my idea is:
Either provide a key to
$ git clone –bare –u “owner/email”
or take the user.email parameter from .gitconfig.
in both cases the info can go to description file of bare repo, so it
can look like:
$owner=owner@server.com
$description=”very long description”
Or in xml form…
Yes, description file might become a bit more complicated in its
layout. But, the benefits are obvious:
- No need to support multiple lists/files
- Bare repo carries all info about itself (together with –d feature I
described earlier).
I this circumstances gitweb’s GITWEB_LIST will be only filter (only
repo path is necessary to show/not show), and it seems that narrowed
functionality here is a good thing...
Your thoughts?
Thanks,
Eugene
^ permalink raw reply
* [PATCH] bash: add support for 'git replace'
From: Björn Gustavsson @ 2009-10-09 20:49 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
---
contrib/completion/git-completion.bash | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 88b1b3c..60009c5 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1794,6 +1794,11 @@ _git_remote ()
esac
}
+_git_replace ()
+{
+ __gitcomp "$(__git_refs)"
+}
+
_git_reset ()
{
__git_has_doubledash && return
@@ -2162,6 +2167,7 @@ _git ()
push) _git_push ;;
rebase) _git_rebase ;;
remote) _git_remote ;;
+ replace) _git_replace ;;
reset) _git_reset ;;
revert) _git_revert ;;
rm) _git_rm ;;
--
1.6.5.rc3.2.g9b675
^ permalink raw reply related
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