* Re: [RFC] Introduce .git/BRANCH to point to the current branch
From: Junio C Hamano @ 2007-12-04 20:46 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Matthieu Moy, Salikh Zakirov, Git Mailing List
In-Reply-To: <m34peyur8r.fsf@roke.D-201>
Jakub Narebski <jnareb@gmail.com> writes:
>> Currently, I can do:
>>
>> # Oh, what did this look like two commits ago?
>> $ git checkout HEAD^^
>> # Ah, OK, let's go back to the tip
>> $ git checkout branch-name
>> ^^^^^^^^^^^
>> But I have to remember and re-type the branch name.
>
> No, you don't have. You can use
> $ git checkout ORIG_HEAD
> or
> $ git checkout HEAD@{1}
But the point is he wants to go back to the branch he came from. He
does not want to detach HEAD at the original commit.
Having said that, I am not sympathetic to "I have to remember".
^ permalink raw reply
* Re: [RFC] Introduce .git/BRANCH to point to the current branch
From: Matthieu Moy @ 2007-12-04 21:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, Salikh Zakirov, Git Mailing List
In-Reply-To: <7vir3e428i.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Having said that, I am not sympathetic to "I have to remember".
That's definitely not an important point, but I find it conveinient,
for example in hg, to be able to just "hg update" to get to the tip of
a branch.
A use-case (which joins the one of Salikh actually) is to publish both
a repository and a working tree (I do that for my collegues which may
or (usually) may not use git). Making a hook to update the working
tree after a push is a terrible hack in git, and just "hg update" in
Mercurial.
(once again, that's one point in favor of base separate from current
branch, but it doesn't cancel the possible drawbacks. It seems
the thread "Reverting the whole index-base series" at
http://thread.gmane.org/gmane.comp.version-control.git/44360/focus=44525
is interesting to read, I'll dig a bit more.
As you mention in the thread, detaching head when pushing to a
checked-out branch would probably be an interesting option)
--
Matthieu
^ permalink raw reply
* Re: [RFC] Introduce .git/BRANCH to point to the current branch
From: Junio C Hamano @ 2007-12-04 21:48 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Jakub Narebski, Salikh Zakirov, Git Mailing List
In-Reply-To: <vpq4peyjgd7.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Having said that, I am not sympathetic to "I have to remember".
>
> That's definitely not an important point, but I find it conveinient,
> for example in hg, to be able to just "hg update" to get to the tip of
> a branch.
>
> A use-case (which joins the one of Salikh actually) is to publish both
> a repository and a working tree (I do that for my collegues which may
> or (usually) may not use git). Making a hook to update the working
> tree after a push is a terrible hack in git, and just "hg update" in
> Mercurial.
That's a different issue. The reason push-into-a-live-tree works that
way in Hg is because they have this implicit notion of unmerged heads
that is merged with the next "hg update". We don't.
Instead, we are more explicit. If you want to emulate that workflow in
git, you would prepare a reception branch, and have people push into it
(see gitfaq and look for "sync out of a firewalled host". In the FAQ
entry, pretend as if machineA is such a live work tree you are working
in, and allow people to push into --- that B/master is the reception
branch, although the FAQ entry is about your private use and written as
if only you from a satellite machine can push into it, it can easily be
a shared branch).
Instead of saying "hg update", you (the person working in such a live
work tree that allows others to push into) merge that reception branch.
^ permalink raw reply
* Re: [RFC] Introduce .git/BRANCH to point to the current branch
From: Salikh Zakirov @ 2007-12-04 21:57 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Matthieu Moy, Git Mailing List
In-Reply-To: <m34peyur8r.fsf@roke.D-201>
Jakub Narebski wrote:
>> Salikh Zakirov <salikh@gmail.com> writes:
>>> This combination leads to the confusing user experience
>>> if the branch changes independently of the working directory.
>>> This can happen in following cases:
>
> All those cases are cases of not recommended workflows.
I guess those cases are not recommended exactly because
there are prone to causing confusion with current git.
I use multiple workdirs quite often, and by now learned
not to check out the same branch in different workdirs,
but it would very convenient if it would not be necessary to remember it.
> Please search the archives for idea of BASE extension to index
> (instead of your separate file under .git/refs), and why it is
> not in current git.
I never realized this idea has been already tried. Thanks for the pointer!
I would try to use BASE extension.
> BTW. how in your proposal would you detach HEAD?
Deleting .git/BRANCH should be enough.
But I cannot see the workflow that would need it.
If one checks out older state of the branch, there is no harm in maintaining
the BRANCH pointer, as commits done in this state need to be manually merged in order
to get into the branch, in the same way as detached head works currently.
^ permalink raw reply
* Re: [PATCH] Set OLD_ICONV on Cygwin.
From: Junio C Hamano @ 2007-12-04 21:59 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Pascal Obry, Pascal Obry, Pascal Obry, git
In-Reply-To: <7v63ze5osn.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Andreas Ericsson <ae@op5.se> writes:
>
>> Nice. If my suspicions are correct and he missed your patch the first time
>> around, you should probably resend it though.
>
> I still have it in my mailbox.
>
> I saw the patch but saw nobody else said about the patch being helpful
> to his installation, nor more importantly, "Good, this won't hurt for me
> who run a different vintage of Cygwin", and I was waiting for such
> confirmations.
>
> Then nobody responded, so I forgot.
>
> That was what happened the first time Pascal's patch was posted.
I think the patch is fine; I just checked with my copy of Cygwin that I
haven't fired for some time (it was a pain waiting for it to update to
the latest set of git sources).
I am at work and will be busy for the rest of the afternoon, so won't be
applying it until this evening, though.
^ permalink raw reply
* [PATCH] git-checkout --push/--pop
From: Nanako Shiraishi @ 2007-12-04 22:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthieu Moy, Salikh Zakirov, git
In-Reply-To: <7vir3e428i.fsf@gitster.siamese.dyndns.org>
This introduces a branch-stack mechanism to record branch switching in $GIT_DIR/BRANCH_STACK file. If you are switching to another branch and plan to come back to the original branch soon, add '--push' option to record your current branch.
When you want to come back, 'git checkout --pop' will switch back to the branch recorded at the top of the stack, while popping it.
Signed-off-by: しらいしななこ <nanako3@bluebottle.com>
---
git-checkout.sh | 42 +++++++++++++++++++++++++++++++++++++++++-
1 files changed, 41 insertions(+), 1 deletions(-)
diff --git a/git-checkout.sh b/git-checkout.sh
index f6d58ac..b53aea6 100755
--- a/git-checkout.sh
+++ b/git-checkout.sh
@@ -8,8 +8,10 @@ b= create a new branch started at <branch>
l create the new branchs reflog
track tells if the new branch should track the remote branch
f proceed even if the index or working tree is not HEAD
-m performa three-way merge on local modifications if needed
+m perform a three-way merge on local modifications if needed
q,quiet be quiet
+push push the current branch to branch stack
+pop come back to the previous branch by poping from branch stack
"
SUBDIRECTORY_OK=Sometimes
. git-sh-setup
@@ -27,6 +29,8 @@ newbranch=
newbranch_log=
merge=
quiet=
+push=
+pop=
v=-v
LF='
'
@@ -49,6 +53,12 @@ while test $# != 0; do
--track|--no-track)
track="$1"
;;
+ --push)
+ push=1
+ ;;
+ --pop)
+ pop=1
+ ;;
-f)
force=1
;;
@@ -70,6 +80,27 @@ while test $# != 0; do
shift
done
+if test -n "$pop"
+then
+ if test $# != 0
+ then
+ die "git checkout: --pop is incompatible with branch name"
+ fi
+ if test -n "$push"
+ then
+ die "git checkout: --pop and --push are incompatible"
+ fi
+ last=$(tail -n 1 "$GIT_DIR/BRANCH_STACK")
+ if test -z "$last"
+ then
+ die "git checkout: empty branch stack"
+ fi
+ sed -e '$d' <"$GIT_DIR/BRANCH_STACK" >"$GIT_DIR/BRANCH_STACK.new"
+ mv "$GIT_DIR/BRANCH_STACK.new" "$GIT_DIR/BRANCH_STACK"
+ set x "$last"
+ shift
+fi
+
arg="$1"
if rev=$(git rev-parse --verify "$arg^0" 2>/dev/null)
then
@@ -113,6 +144,11 @@ esac
if test "$#" -ge 1
then
+ # Checking out a path out of the index or a commit
+ if test -n "$push"
+ then
+ die "git checkout: --push while not switching branches"
+ fi
hint=
if test "$#" -eq 1
then
@@ -276,6 +312,10 @@ if [ "$?" -eq 0 ]; then
else
echo >&2 "Switched to${newbranch:+ a new} branch \"$branch\""
fi
+ if test -n "$push"
+ then
+ echo "$old_branch_name" >>"$GIT_DIR/BRANCH_STACK"
+ fi
elif test -n "$detached"
then
old_branch_name=`expr "z$oldbranch" : 'zrefs/heads/\(.*\)'`
--
1.5.3.6
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
----------------------------------------------------------------------
Get a free email account with anti spam protection.
http://www.bluebottle.com/tag/2
^ permalink raw reply related
* Re: [RFC] Introduce .git/BRANCH to point to the current branch
From: Junio C Hamano @ 2007-12-04 22:06 UTC (permalink / raw)
To: Salikh Zakirov; +Cc: Jakub Narebski, Matthieu Moy, Git Mailing List
In-Reply-To: <4755CD32.7040204@gmail.com>
Salikh Zakirov <salikh@gmail.com> writes:
> Jakub Narebski wrote:
> ...
>> Please search the archives for idea of BASE extension to index
>> (instead of your separate file under .git/refs), and why it is
>> not in current git.
>
> I never realized this idea has been already tried. Thanks for the pointer!
> I would try to use BASE extension.
Start reading from here.
http://thread.gmane.org/gmane.comp.version-control.git/44360/focus=44508
All of the articles in that thread is worth a read to understand why the
idea did not quite pan out and the whole series was reverted.
052737e33a898af8eb4f1bd97be046e05ecb9bea reverts the series from 'next'.
309202782399878a2d7973e21e6e62ba3b9fde50 was the last of the index-base
series.
^ permalink raw reply
* Re: [PATCH] Make Git accept absolute path names for files within the work tree
From: Jeff King @ 2007-12-04 22:08 UTC (permalink / raw)
To: Linus Torvalds
Cc: Johannes Schindelin, Robin Rosenberg, Junio C Hamano,
Anatol Pomozov, git
In-Reply-To: <alpine.LFD.0.9999.0712040756370.2981@woody.linux-foundation.org>
On Tue, Dec 04, 2007 at 07:59:43AM -0800, Linus Torvalds wrote:
> > I do remember the hassles I went through with get_relative_cwd() until I
> > broke down and used chdir() two times (ugly).
>
> It really is a pretty heavy and complex operation in UNIX in general (and
> open to various races too), which is why I'd generally suggest avoiding it
> if you at all can.
It is more expensive, though we will be doing it once per user-supplied
pathspec, so I don't know that it will actually have an impact.
I am concerned that not supporting symlinks will make this feature
unusably annoying for some users. I used to have a home directory that
had a symlink in it, and I frequently ran into these sorts of path
comparison issues ($HOME was /home/peff, so typing ~/repo/file pointed
there, but /home was a symlink to /mnt/data/home, so any routines that
normalize the cwd used /mnt/data/home/repo, and the two never matched
up).
Hrm. Looks like somebody has already helpfully implemented
make_absolute_path, so it would just require calling that on each
argument. Something like this on top of Robin's patch:
diff --git a/setup.c b/setup.c
index 4ee8024..e76c83c 100644
--- a/setup.c
+++ b/setup.c
@@ -58,7 +58,8 @@ const char *prefix_path(const char *prefix, int len, const char *path)
{
const char *orig = path;
if (is_absolute_path(path))
- path = strip_work_tree_path(prefix, len, path);
+ path = strip_work_tree_path(prefix, len,
+ xstrdup(make_absolute_path(path)));
for (;;) {
char c;
-Peff
^ permalink raw reply related
* Re: [RFC] Introduce .git/BRANCH to point to the current branch
From: Jakub Narebski @ 2007-12-04 22:08 UTC (permalink / raw)
To: Salikh Zakirov; +Cc: Matthieu Moy, Git Mailing List
In-Reply-To: <4755CD32.7040204@gmail.com>
On Tue, 4 Dec 2007, Salikh Zakirov wrote:
> Jakub Narebski wrote:
>>> Salikh Zakirov <salikh@gmail.com> writes:
>>>> This combination leads to the confusing user experience
>>>> if the branch changes independently of the working directory.
>>>> This can happen in following cases:
>>
>> All those cases are cases of not recommended workflows.
>
> I guess those cases are not recommended exactly because
> there are prone to causing confusion with current git.
BTW. I think for each such workflow there is alternative
in git, which does not cause those problems.
> I use multiple workdirs quite often, and by now learned
> not to check out the same branch in different workdirs,
> but it would very convenient if it would not be necessary
> to remember it.
Those cases are not recommended because they would _always_ cause
confusion, whether the user is informed that somehow working copy
or current branch has changed while he/she was working or not.
Currently git tries to follow "merge when ready" (i.e. you
explicitely ask to merge or rebase), not "merge when needed"
(like in old, broken CVS workflow where 'cvs update' might have
_forced_ a merge before being allowed to save his/her finished
work).
>> BTW. how in your proposal would you detach HEAD?
>
> Deleting .git/BRANCH should be enough.
Hmmm...
> But I cannot see the workflow that would need it.
Checking out tag. Checking out remote-tracking branch. You cannot
commit on top of either (immovable) tag, or (externally controlled)
remote-tracking branch.
Besides rebase now uses detached HEAD, and I guess that bisect would
too.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Set OLD_ICONV on Cygwin.
From: Pascal Obry @ 2007-12-04 22:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Ericsson, Pascal Obry, Pascal Obry, git
In-Reply-To: <7vaboq3yuy.fsf@gitster.siamese.dyndns.org>
Junio C Hamano a écrit :
> I am at work and will be busy for the rest of the afternoon, so won't be
> applying it until this evening, though.
Ok, thanks. No urgency with this patch anyway.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: git guidance
From: Phillip Susi @ 2007-12-04 22:21 UTC (permalink / raw)
To: Al Boldi; +Cc: Linus Torvalds, Jing Xue, linux-kernel, git
In-Reply-To: <200712010950.15628.a1426z@gawab.com>
Al Boldi wrote:
> Judging an idea, based on a flawed implementation, doesn't prove that the
> idea itself is flawed.
It isn't the implementation that is flawed, it is the idea. The entire
point of a change control system is that you explicitly define change
sets and add comments to the set. The filesystem was designed to allow
changes to be made willy-nilly. If your goal is to perform change
control only with filesystem semantics, then you have a non starter as
their goals are opposing. Requiring an explicit command command is
hardly burdensome, and otherwise, a git tree is perfectly transparent to
non git aware tools.
> Sure, you wouldn't want to change the git-engine update semantics, as that
> sits on the server and handles all users. But what the git model is
> currently missing is a client manager. Right now, this is being worked
> around by replicating the git tree on the client, which still doesn't
> provide the required transparency.
It isn't missing a client manager, it was explicitly designed to not
have one, at least not as a distinct entity from a server, because it
does not use a client/server architecture. This is very much by design,
not a work around.
What transparency are you requiring here? You can transparently read
your git tree with all non git aware tools, what other meaning of
transparency is there?
> IOW, git currently only implements the server-side use-case, but fails to
> deliver on the client-side. By introducing a git-client manager that
> handles the transparency needs of a single user, it should be possible to
> clearly isolate update semantics for both the client and the server, each
> handling their specific use-case.
Any talk of client or server makes no sense since git does not use a
client/server model. If you wish to use a centralized repository, then
git can be set up to transparently push/pull to/from said repository if
you wish via hooks or cron jobs.
^ permalink raw reply
* Re: Building git-1.5.3.7 on HP-UX 11.00
From: H.Merijn Brand @ 2007-12-04 22:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Andreas Ericsson, git, Sam Vilain
In-Reply-To: <7vve7e49or.fsf@gitster.siamese.dyndns.org>
On Tue, 04 Dec 2007 10:05:40 -0800, Junio C Hamano <gitster@pobox.com> wrote:
> "H.Merijn Brand" <h.m.brand@xs4all.nl> writes:
>
> > On Tue, 4 Dec 2007 15:39:47 +0000 (GMT), Johannes Schindelin
> > ...
> > I found it! unset returns false
> > ...
> > I must leave now.
>
> Thanks, you two.
>
> I do not see "unset VAR... &&" outside t0001 test, but there are
> instances of "unset VAR... &&" in git-submodule implementations as well.
>
> In short, not too many places to fix.
Going from there ....
# make test
:
:
:
*** t1300-repo-config.sh ***
* ok 1: initial
* ok 2: mixed case
* ok 3: similar section
* ok 4: similar section
* ok 5: replace with non-match
* ok 6: replace with non-match (actually matching)
* ok 7: non-match result
* ok 8: multiple unset
* ok 9: multiple unset is correct
* ok 10: --replace-all
* ok 11: all replaced
* ok 12: really mean test
* ok 13: really really mean test
* ok 14: get value
* ok 15: unset
* ok 16: multivar
* FAIL 17: non-match
git config --get nextsection.nonewline !for
* FAIL 18: non-match value
test wow = $(git config --get nextsection.nonewline !for)
* ok 19: ambiguous get
* ok 20: get multivar
* ok 21: multivar replace
* ok 22: ambiguous value
* ok 23: ambiguous unset
* ok 24: invalid unset
* ok 25: multivar unset
* ok 26: invalid key
* ok 27: correct key
* ok 28: hierarchical section
* ok 29: hierarchical section value
* ok 30: working --list
* ok 31: --get-regexp
* ok 32: --add
* ok 33: get variable with no value
* ok 34: get-regexp variable with no value
* ok 35: no arguments, but no crash
* ok 36: new section is partial match of another
* ok 37: new variable inserts into proper section
* ok 38: alternative GIT_CONFIG (non-existing file should fail)
* ok 39: alternative GIT_CONFIG
* ok 40: alternative GIT_CONFIG (--file)
* ok 41: --set in alternative GIT_CONFIG
* ok 42: rename section
* ok 43: rename succeeded
* ok 44: rename non-existing section
* ok 45: rename succeeded
* ok 46: rename another section
* ok 47: rename succeeded
* ok 48: remove section
* ok 49: section was removed properly
* ok 50: section ending
* ok 51: numbers
* ok 52: bool
* ok 53: invalid bool (--get)
* ok 54: invalid bool (set)
* ok 55: set --bool
* ok 56: set --int
* ok 57: quoting
* ok 58: key with newline
* ok 59: value with newline
* ok 60: value continued on next line
* FAIL 61: --null --list
cmp result expect
* FAIL 62: --null --get-regexp
cmp result expect
* ok 63: symlinked configuration
* failed 4 among 63 test(s)
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using & porting perl 5.6.2, 5.8.x, 5.10.x on HP-UX 10.20, 11.00, 11.11,
& 11.23, SuSE 10.1 & 10.2, AIX 5.2, and Cygwin. http://qa.perl.org
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org
http://www.goldmark.org/jeff/stupid-disclaimers/
^ permalink raw reply
* [PATCH] Do not rely on the exit status of "unset" for unset variables
From: Johannes Schindelin @ 2007-12-04 22:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: H.Merijn Brand, Andreas Ericsson, git, Sam Vilain
In-Reply-To: <7vve7e49or.fsf@gitster.siamese.dyndns.org>
From: H.Merijn Brand <h.m.brand@xs4all.nl>
POSIX says that exit status "0" means that "unset" successfully unset
the variable. However, it is kind of ambiguous if an environment
variable which was not set could be successfully unset.
At least the default shell on HP-UX insists on reporting an error in
such a case, so just ignore the exit status of "unset".
[Dscho: extended the patch to git-submodule.sh, as Junio realized that
this is the only other place where we check the exit status of "unset".]
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Tue, 4 Dec 2007, Junio C Hamano wrote:
> "H.Merijn Brand" <h.m.brand@xs4all.nl> writes:
>
> > On Tue, 4 Dec 2007 15:39:47 +0000 (GMT), Johannes Schindelin
> > ...
> > I found it! unset returns false
> > ...
> > I must leave now.
>
> Thanks, you two.
>
> I do not see "unset VAR... &&" outside t0001 test, but there are
> instances of "unset VAR... &&" in git-submodule implementations
> as well.
>
> In short, not too many places to fix.
You're right. I grepped for "unset" in t/*.sh, but that catches
only false positives other than t0001.
Merijn, maybe you want to have your sign-off in the commit
message?
git-submodule.sh | 10 +++++-----
t/t0001-init.sh | 16 ++++++++--------
2 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 82ac28f..ad9fe62 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -158,7 +158,7 @@ module_add()
die "'$path' already exists in the index"
module_clone "$path" "$realrepo" || exit
- (unset GIT_DIR && cd "$path" && git checkout -q ${branch:+-b "$branch" "origin/$branch"}) ||
+ (unset GIT_DIR; cd "$path" && git checkout -q ${branch:+-b "$branch" "origin/$branch"}) ||
die "Unable to checkout submodule '$path'"
git add "$path" ||
die "Failed to add submodule '$path'"
@@ -228,14 +228,14 @@ modules_update()
module_clone "$path" "$url" || exit
subsha1=
else
- subsha1=$(unset GIT_DIR && cd "$path" &&
+ subsha1=$(unset GIT_DIR; cd "$path" &&
git rev-parse --verify HEAD) ||
die "Unable to find current revision in submodule path '$path'"
fi
if test "$subsha1" != "$sha1"
then
- (unset GIT_DIR && cd "$path" && git-fetch &&
+ (unset GIT_DIR; cd "$path" && git-fetch &&
git-checkout -q "$sha1") ||
die "Unable to checkout '$sha1' in submodule path '$path'"
@@ -246,7 +246,7 @@ modules_update()
set_name_rev () {
revname=$( (
- unset GIT_DIR &&
+ unset GIT_DIR
cd "$1" && {
git describe "$2" 2>/dev/null ||
git describe --tags "$2" 2>/dev/null ||
@@ -285,7 +285,7 @@ modules_list()
else
if test -z "$cached"
then
- sha1=$(unset GIT_DIR && cd "$path" && git rev-parse --verify HEAD)
+ sha1=$(unset GIT_DIR; cd "$path" && git rev-parse --verify HEAD)
set_name_rev "$path" "$sha1"
fi
say "+$sha1 $path$revname"
diff --git a/t/t0001-init.sh b/t/t0001-init.sh
index b14b3ec..c015405 100755
--- a/t/t0001-init.sh
+++ b/t/t0001-init.sh
@@ -25,7 +25,7 @@ check_config () {
test_expect_success 'plain' '
(
- unset GIT_DIR GIT_WORK_TREE &&
+ unset GIT_DIR GIT_WORK_TREE
mkdir plain &&
cd plain &&
git init
@@ -35,7 +35,7 @@ test_expect_success 'plain' '
test_expect_success 'plain with GIT_WORK_TREE' '
if (
- unset GIT_DIR &&
+ unset GIT_DIR
mkdir plain-wt &&
cd plain-wt &&
GIT_WORK_TREE=$(pwd) git init
@@ -48,7 +48,7 @@ test_expect_success 'plain with GIT_WORK_TREE' '
test_expect_success 'plain bare' '
(
- unset GIT_DIR GIT_WORK_TREE GIT_CONFIG &&
+ unset GIT_DIR GIT_WORK_TREE GIT_CONFIG
mkdir plain-bare-1 &&
cd plain-bare-1 &&
git --bare init
@@ -58,7 +58,7 @@ test_expect_success 'plain bare' '
test_expect_success 'plain bare with GIT_WORK_TREE' '
if (
- unset GIT_DIR GIT_CONFIG &&
+ unset GIT_DIR GIT_CONFIG
mkdir plain-bare-2 &&
cd plain-bare-2 &&
GIT_WORK_TREE=$(pwd) git --bare init
@@ -72,7 +72,7 @@ test_expect_success 'plain bare with GIT_WORK_TREE' '
test_expect_success 'GIT_DIR bare' '
(
- unset GIT_CONFIG &&
+ unset GIT_CONFIG
mkdir git-dir-bare.git &&
GIT_DIR=git-dir-bare.git git init
) &&
@@ -82,7 +82,7 @@ test_expect_success 'GIT_DIR bare' '
test_expect_success 'GIT_DIR non-bare' '
(
- unset GIT_CONFIG &&
+ unset GIT_CONFIG
mkdir non-bare &&
cd non-bare &&
GIT_DIR=.git git init
@@ -93,7 +93,7 @@ test_expect_success 'GIT_DIR non-bare' '
test_expect_success 'GIT_DIR & GIT_WORK_TREE (1)' '
(
- unset GIT_CONFIG &&
+ unset GIT_CONFIG
mkdir git-dir-wt-1.git &&
GIT_WORK_TREE=$(pwd) GIT_DIR=git-dir-wt-1.git git init
) &&
@@ -103,7 +103,7 @@ test_expect_success 'GIT_DIR & GIT_WORK_TREE (1)' '
test_expect_success 'GIT_DIR & GIT_WORK_TREE (2)' '
if (
- unset GIT_CONFIG &&
+ unset GIT_CONFIG
mkdir git-dir-wt-2.git &&
GIT_WORK_TREE=$(pwd) GIT_DIR=git-dir-wt-2.git git --bare init
)
--
1.5.3.7.2139.g2a5a3
^ permalink raw reply related
* Re: Building git-1.5.3.7 on HP-UX 11.00
From: Johannes Schindelin @ 2007-12-04 22:46 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: Junio C Hamano, Andreas Ericsson, git, Sam Vilain
In-Reply-To: <20071204232542.425d2ead@pc09.procura.nl>
Hi,
On Tue, 4 Dec 2007, H.Merijn Brand wrote:
> * FAIL 17: non-match
> git config --get nextsection.nonewline !for
> * FAIL 18: non-match value
> test wow = $(git config --get nextsection.nonewline !for)
Can you investigate further with "-i -v" and/or "-x"? Could be the
exclamation mark...
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Make Git accept absolute path names for files within the work tree
From: Linus Torvalds @ 2007-12-04 22:52 UTC (permalink / raw)
To: Jeff King
Cc: Johannes Schindelin, Robin Rosenberg, Junio C Hamano,
Anatol Pomozov, git
In-Reply-To: <20071204220840.GA3340@coredump.intra.peff.net>
On Tue, 4 Dec 2007, Jeff King wrote:
>
> It is more expensive, though we will be doing it once per user-supplied
> pathspec, so I don't know that it will actually have an impact.
Well, I'm more worried about just bugs, actually.
Doing this right is actually rather hard. For example, our current
"make_absolute_path()" is simply not very good, and it's almost impossible
to *make* it very good.
Why? It relies on being able to get the current cwd, which isn't always
even possible on all systems. What about unreadable directories? What
about just so *deep* directories, that the cwd doesn't fit in the 1kB
allocated for it? Both do happen (people use executable but non-readable
directories for security sometimes). I'm also almost certain that you can
confuse it by renaming directories while that thing is running, etc etc.
IOW, that whole thing is simply a bug waiting to happen. The fact that it
apparently *always* runs whether needed or not just seems to make it worse
(ie if we already know our cwd, and the absolute path we have already has
that as a prefix, just strip it off, don't try to do anything complex, and
leave the complex and fragile cases for the odd-ball when the simple
approach doesn't work)
Linus
^ permalink raw reply
* Re: [PATCH] t9600: require cvsps 2.1 to perform tests
From: Jeff King @ 2007-12-05 1:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: gitzilla, Johannes Schindelin, git
In-Reply-To: <7vhciy5pg0.fsf@gitster.siamese.dyndns.org>
On Tue, Dec 04, 2007 at 09:39:59AM -0800, Junio C Hamano wrote:
> You are right about "we may be depending on what 2.1 has other than
> -A". Will apply as-is.
>
> Thanks, both.
>
> The primary reason I asked about '\[-A\]' was what will happen if
> somebody uses 2.2.
Yes, it would be nice to be able to easily check >2.1. GNU expr seems to
handle this ok:
$ expr 2.2 '>' 2.1
1
$ expr 2.0 '>' 2.1
0
but POSIX seems to mention only integers and string comparison (though
if all are of the form "x.y", string comparison works). I have no idea
how portable this is.
-Peff
^ permalink raw reply
* Re: Some git performance measurements..
From: Federico Mena Quintero @ 2007-12-05 1:04 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jakub Narebski, Nicolas Pitre, Git Mailing List
In-Reply-To: <alpine.LFD.0.9999.0711291836230.8458@woody.linux-foundation.org>
On Thu, 2007-11-29 at 18:54 -0800, Linus Torvalds wrote:
> Jakub pointed out, the cold-cache numbers do fluctuate a lot, and while
You may want to try iogrind:
http://live.gnome.org/iogrind
It's a valgrind skin to record I/O operations (including "implicit" ones
like touching mmap()ed pages), plus a graphical tool to visualize the
logs, similar to kcachegrind.
Federico
^ permalink raw reply
* [PATCH] Fix spelling mistakes in user manual
From: Shawn Bohrer @ 2007-12-05 4:25 UTC (permalink / raw)
To: git; +Cc: gitster, Shawn Bohrer
Signed-off-by: Shawn Bohrer <shawn.bohrer@gmail.com>
---
Documentation/user-manual.txt | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 93a47b4..f2b4206 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1994,7 +1994,7 @@ $ git push ssh://yourserver.com/~you/proj.git +master
-------------------------------------------------
Normally whenever a branch head in a public repository is modified, it
-is modified to point to a descendent of the commit that it pointed to
+is modified to point to a descendant of the commit that it pointed to
before. By forcing a push in this situation, you break that convention.
(See <<problems-with-rewriting-history>>.)
@@ -2921,7 +2921,7 @@ As you can see, a commit is defined by:
- a tree: The SHA1 name of a tree object (as defined below), representing
the contents of a directory at a certain point in time.
- parent(s): The SHA1 name of some number of commits which represent the
- immediately prevoius step(s) in the history of the project. The
+ immediately previous step(s) in the history of the project. The
example above has one parent; merge commits may have more than
one. A commit with no parents is called a "root" commit, and
represents the initial revision of a project. Each project must have
@@ -3242,7 +3242,7 @@ to replace them by hand. Back up your repository before attempting this
in case you corrupt things even more in the process.
We'll assume that the problem is a single missing or corrupted blob,
-which is sometimes a solveable problem. (Recovering missing trees and
+which is sometimes a solvable problem. (Recovering missing trees and
especially commits is *much* harder).
Before starting, verify that there is corruption, and figure out where
--
1.5.3.6
^ permalink raw reply related
* [PATCH] Documentation: describe -w/--web option to "git-help".
From: Christian Couder @ 2007-12-05 5:09 UTC (permalink / raw)
To: Junio Hamano; +Cc: git
Also explain that "git instaweb" may use "web.browser" config
variable.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git-help.txt | 21 +++++++++++++++++++--
Documentation/git-instaweb.txt | 3 +++
2 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-help.txt b/Documentation/git-help.txt
index c94e27b..ac9e15d 100644
--- a/Documentation/git-help.txt
+++ b/Documentation/git-help.txt
@@ -7,7 +7,7 @@ git-help - display help information about git
SYNOPSIS
--------
-'git help' [-a|--all|-i|--info] [COMMAND]
+'git help' [-a|--all|-i|--info|-w|--web] [COMMAND]
DESCRIPTION
-----------
@@ -29,7 +29,6 @@ former is internally converted into the latter.
OPTIONS
-------
-a|--all::
-
Prints all the available commands on the standard output. This
option superseeds any other option.
@@ -37,6 +36,24 @@ OPTIONS
Use the 'info' program to display the manual page, instead of
the 'man' program that is used by default.
+-w|--web::
+ Use a web browser to display the HTML manual page, instead of
+ the 'man' program that is used by default.
++
+The web browser can be specified using the configuration variable
+'help.browser', or 'web.browser' if the former is not set. If none of
+these config variables is set, the 'git-browse-help' script (called by
+'git-help') will pick a suitable default.
++
+You can explicitly provide a full path to your prefered browser by
+setting the configuration variable 'browser.<tool>.path'. For example,
+you can configure the absolute path to firefox by setting
+'browser.firefox.path'. Otherwise, 'git-browse-help' assumes the tool
+is available in PATH.
++
+Note that the script tries, as much as possible, to display the HTML
+page in a new tab on an already opened browser.
+
Author
------
Written by Junio C Hamano <gitster@pobox.com> and the git-list
diff --git a/Documentation/git-instaweb.txt b/Documentation/git-instaweb.txt
index 735008c..d2ce779 100644
--- a/Documentation/git-instaweb.txt
+++ b/Documentation/git-instaweb.txt
@@ -71,6 +71,9 @@ You may specify configuration in your .git/config
-----------------------------------------------------------------------
+If the configuration variable 'instaweb.browser' is not set,
+'web.browser' will be used instead if it is defined.
+
Author
------
Written by Eric Wong <normalperson@yhbt.net>
--
1.5.3.6.1993.g154f-dirty
^ permalink raw reply related
* Re: [PATCH] t9600: require cvsps 2.1 to perform tests
From: Junio C Hamano @ 2007-12-05 5:44 UTC (permalink / raw)
To: Jeff King; +Cc: gitzilla, Johannes Schindelin, git
In-Reply-To: <20071205010202.GA4713@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Dec 04, 2007 at 09:39:59AM -0800, Junio C Hamano wrote:
>
>> You are right about "we may be depending on what 2.1 has other than
>> -A". Will apply as-is.
>>
>> Thanks, both.
>>
>> The primary reason I asked about '\[-A\]' was what will happen if
>> somebody uses 2.2.
>
> Yes, it would be nice to be able to easily check >2.1. GNU expr seems to
> handle this ok:
>
> $ expr 2.2 '>' 2.1
> 1
> $ expr 2.0 '>' 2.1
> 0
>
> but POSIX seems to mention only integers and string comparison (though
> if all are of the form "x.y", string comparison works). I have no idea
> how portable this is.
Yeah, but it is the same thing -- we know 2.1 works, we do not know if
2.2 will break things for us ;-)
We'll worry about it when somebody with 2.2 complains.
^ permalink raw reply
* How to jump between two repositories ...
From: g2 @ 2007-12-05 5:59 UTC (permalink / raw)
To: git
Hello all,
I am currently working on some code at the office that I also want to
work with at home. Seems like a good candidate for git. So I created a
repository at work and did a "git clone" at home. I've run into some
strange behaviour that I don't understand and would appreciate if
someone can clarify for me.
Imagine this scenario. At work:
git init
edit test.c
git add test.c
git commit
Then at home:
git clone <work git url>
edit test.c
git commit -a
git push
At this point, I wanted to push my changes back to my work repository
so I can continue work the next day. So at home, I did a git push. I
expect that my work repository has the newest material, but I find
that when I do "git status" at work the next day, it tells me that my
test.c is "modified" and has already staged it for commit. I need to
do a "git reset" followed by "git checkout" to update my work folder
to the latest stuff.
Totally different from my expectation of the repository knowing that
it is out of date and then kindly suggesting that I should do a "git
update" of some sort. What piece of understanding am I missing to
properly "get" what is going on here, and how am I supposed to
properly work with this setup?
Thanks for any help.
Gerald.
^ permalink raw reply
* Re: How to jump between two repositories ...
From: Shawn O. Pearce @ 2007-12-05 6:11 UTC (permalink / raw)
To: g2; +Cc: git
In-Reply-To: <C6AF7922-B2F7-42EB-B5DD-25353BC0AF2A@gmail.com>
g2 <gerald.gutierrez@gmail.com> wrote:
> At this point, I wanted to push my changes back to my work repository
> so I can continue work the next day. So at home, I did a git push. I
> expect that my work repository has the newest material, but I find
> that when I do "git status" at work the next day, it tells me that my
> test.c is "modified" and has already staged it for commit. I need to
> do a "git reset" followed by "git checkout" to update my work folder
> to the latest stuff.
Oddly enough, this question is asked so frequently that it is
answered in the GitFaq on the GitWiki:
http://git.or.cz/gitwiki/GitFaq#head-b96f48bc9c925074be9f95c0fce69bcece5f6e73
--
Shawn.
^ permalink raw reply
* Re: How to jump between two repositories ...
From: J. Bruce Fields @ 2007-12-05 6:14 UTC (permalink / raw)
To: g2; +Cc: git
In-Reply-To: <C6AF7922-B2F7-42EB-B5DD-25353BC0AF2A@gmail.com>
On Tue, Dec 04, 2007 at 09:59:57PM -0800, g2 wrote:
> Hello all,
>
> I am currently working on some code at the office that I also want to work
> with at home. Seems like a good candidate for git. So I created a
> repository at work and did a "git clone" at home. I've run into some
> strange behaviour that I don't understand and would appreciate if someone
> can clarify for me.
>
> Imagine this scenario. At work:
> git init
> edit test.c
> git add test.c
> git commit
>
> Then at home:
> git clone <work git url>
> edit test.c
> git commit -a
> git push
You'll be much happier at this point if you ssh into work and then git
pull from home....
> At this point, I wanted to push my changes back to my work repository so I
> can continue work the next day. So at home, I did a git push. I expect that
> my work repository has the newest material, but I find that when I do "git
> status" at work the next day, it tells me that my test.c is "modified" and
> has already staged it for commit. I need to do a "git reset" followed by
> "git checkout" to update my work folder to the latest stuff.
>
> Totally different from my expectation of the repository knowing that it is
> out of date and then kindly suggesting that I should do a "git update" of
> some sort. What piece of understanding am I missing to properly "get" what
> is going on here, and how am I supposed to properly work with this setup?
Git doesn't support pushing to any branch that's checked out somewhere.
--b.
^ permalink raw reply
* Re: How to jump between two repositories ...
From: Väinö Järvelä @ 2007-12-05 6:20 UTC (permalink / raw)
To: g2; +Cc: git
In-Reply-To: <C6AF7922-B2F7-42EB-B5DD-25353BC0AF2A@gmail.com>
On Dec 5, 2007, at 07:59, g2 wrote:
> I am currently working on some code at the office that I also want
> to work with at home. Seems like a good candidate for git. So I
> created a repository at work and did a "git clone" at home. I've run
> into some strange behaviour that I don't understand and would
> appreciate if someone can clarify for me.
>
> Imagine this scenario. At work:
> git init
> edit test.c
> git add test.c
> git commit
>
> Then at home:
> git clone <work git url>
> edit test.c
> git commit -a
> git push
>
> At this point, I wanted to push my changes back to my work
> repository so I can continue work the next day. So at home, I did a
> git push. I expect that my work repository has the newest material,
> but I find that when I do "git status" at work the next day, it
> tells me that my test.c is "modified" and has already staged it for
> commit. I need to do a "git reset" followed by "git checkout" to
> update my work folder to the latest stuff.
Did you clone a bare repository and push to it?
Here is an excerpt from Git User's Manual:
"Note that the target of a "push" is normally a bare repository. You
can also push to a repository that has a checked-out working tree, but
the working tree will not be updated by the push. This may lead to
unexpected results if the branch you push to is the currently checked-
out branch!"
So to push to your work repository, you should create an intermediary
repository between the work and home repositories. You can create it
by running:
$ git clone --bare /git/work/ /git/work.git/
Then you clone normally from the bare repository and pushing to it
works fine. After you have pushed your changes to the bare repository,
you'll have to pull them to the work repository to get the updates,
just like you would do with any public repository.
Another option would be to pull from your home repository to the work
repository, if you can access your home computer from the work computer.
--
Väinö
^ permalink raw reply
* Re: How to jump between two repositories ...
From: g2 @ 2007-12-05 6:44 UTC (permalink / raw)
To: Väinö Järvelä; +Cc: git
In-Reply-To: <3DD4D3BA-67B3-4AFC-AD24-799384D54408@pp.inet.fi>
What I am gathering from this is that I can use git in two ways: 1) as
"just another svn" bare git repository, or 2) only pull and don't
push, because push causes confusion. I'd be happy to only ever use
pull, but I have one machine behind a firewall and can't pull. I can
push to a bare git repository like the svn model, but then I would
just use svn. What's the value of "push" then?
On 4-Dec-07, at 10:20 PM, Väinö Järvelä wrote:
> On Dec 5, 2007, at 07:59, g2 wrote:
>
>> I am currently working on some code at the office that I also want
>> to work with at home. Seems like a good candidate for git. So I
>> created a repository at work and did a "git clone" at home. I've
>> run into some strange behaviour that I don't understand and would
>> appreciate if someone can clarify for me.
>>
>> Imagine this scenario. At work:
>> git init
>> edit test.c
>> git add test.c
>> git commit
>>
>> Then at home:
>> git clone <work git url>
>> edit test.c
>> git commit -a
>> git push
>>
>> At this point, I wanted to push my changes back to my work
>> repository so I can continue work the next day. So at home, I did a
>> git push. I expect that my work repository has the newest material,
>> but I find that when I do "git status" at work the next day, it
>> tells me that my test.c is "modified" and has already staged it for
>> commit. I need to do a "git reset" followed by "git checkout" to
>> update my work folder to the latest stuff.
>
> Did you clone a bare repository and push to it?
>
> Here is an excerpt from Git User's Manual:
> "Note that the target of a "push" is normally a bare repository. You
> can also push to a repository that has a checked-out working tree,
> but the working tree will not be updated by the push. This may lead
> to unexpected results if the branch you push to is the currently
> checked-out branch!"
>
> So to push to your work repository, you should create an
> intermediary repository between the work and home repositories. You
> can create it by running:
> $ git clone --bare /git/work/ /git/work.git/
>
> Then you clone normally from the bare repository and pushing to it
> works fine. After you have pushed your changes to the bare
> repository, you'll have to pull them to the work repository to get
> the updates, just like you would do with any public repository.
>
> Another option would be to pull from your home repository to the
> work repository, if you can access your home computer from the work
> computer.
>
> --
> Väinö
>
^ 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