* git stash save --keep-index
From: Sverre Rabbelier @ 2008-07-15 12:31 UTC (permalink / raw)
To: Git Mailinglist
Heya,
I have switched to using next/ recently and have had the chance to try
out the new '--keep-index' option to 'git stash'. I must say that 'git
stash save --keep-index' in combination with 'git add -p' followed by
'e' allows for a really nice workflow where I can split up patches
very easily, and test them before committing anything. IIUC the
'--keep-index' option was added as a response to the request to
support a workflow something like this:
<hack hack hack>
$ git add # or -i / -p
$ git stash save --keep-index
<test if staged changes are ready to be commited>
$ git commit
$ git stash pop
<lather, rinse, repeat>
But what happens if in the testing phase you detect that the commit is
not ready yet, or even, some of the changes you staged should have
been kept? It would make sense to 'undo' the stash the usual way:
$ git stash pop
But alas, it is not possible to apply on a dirty working directory, so
one has to resort to:
$ git commit -m "tmp"
$ git stash pop
$ git reset HEAD^
Nothing too bad surely, but I thought that the '--keep-index' option
was exactly to prevent having to do:
<hack hack hack>
$ git add # or -i / -p
$ git commit -m "tmp"
$ git stash save
<test if now committed changes were indeed ready to be comitted>
So the '--keep-index' option eliminates the need for such a temporary
commit in the (hopefully) common case where the selected changes were
indeed good, but we still need it in the case that the changes were
not ready / need something from the stashed changes.
Am I missing something here? Or is the only/best solution here to just
alias 'git commit -m "tmp" && git stash pop && git reset HEAD^' to
'git undo-stash'?
PS: It'd be nice if I could do 'git stash --keep-index' since I"m used
to 'git stash' automagically defaulting to 'git stash save'.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 1/4] Allow e-mails to be sent with the Unix sendmail tool
From: Karl Hasselström @ 2008-07-15 12:34 UTC (permalink / raw)
To: Mark Brown; +Cc: Catalin Marinas, git
In-Reply-To: <20080715122203.GN25448@sirena.org.uk>
On 2008-07-15 13:22:20 +0100, Mark Brown wrote:
> On Sun, Jul 13, 2008 at 12:40:26PM +0100, Catalin Marinas wrote:
>
> > If the stgit.smtpserver configuration option does not have a
> > host:port format, it is assumed to be an external tool. For
> > example, to use sendmail just set this variable to
> > "/usr/sbin/sendmail -t -i" (see the examples/gitconfig file).
>
> I'd really expect to be able to just specify the hostname alone if
> using the standard SMTP port. Perhaps checking for a / in the server
> might be less surprising?
This is actually what the code does, and what the documentation claims
it should do. It's just the commit message that's confused. Catalin?
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH 1/4] Allow e-mails to be sent with the Unix sendmail tool
From: Mark Brown @ 2008-07-15 12:22 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Karl Hasselstr??m, git
In-Reply-To: <20080713114026.18845.77979.stgit@localhost.localdomain>
On Sun, Jul 13, 2008 at 12:40:26PM +0100, Catalin Marinas wrote:
> If the stgit.smtpserver configuration option does not have a host:port
> format, it is assumed to be an external tool. For example, to use
> sendmail just set this variable to "/usr/sbin/sendmail -t -i" (see the
> examples/gitconfig file).
I'd really expect to be able to just specify the hostname alone if using
the standard SMTP port. Perhaps checking for a / in the server might be
less surprising?
--
"You grabbed my hand and we fell into it, like a daydream - or a fever."
^ permalink raw reply
* Re: [PATCH] Documentation/git-submodule.txt: Add Description section
From: Junio C Hamano @ 2008-07-15 14:06 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20080715102119.26321.78530.stgit@localhost>
Petr Baudis <pasky@suse.cz> writes:
> Figuring out how submodules work conceptually is quite a bumpy
> ride for a newcomer; the user manual helps (if one knows to actually
> look into it), but the reference documentation should provide good
> quick intro as well. This patch attempts to do that.
Good discussion starter, I think. There seem to be a few technical
inaccuracies though.
I'll wait until the people interested in submodules on the list form
consensus on the wording and contents.
^ permalink raw reply
* git-rev-parse --show-cdup returns a relative path instead of absolute (problem with git pull --rebase not finding the git dir)
From: Yves Orton @ 2008-07-15 14:13 UTC (permalink / raw)
To: git
Hi,
Im reporting this based on a conversation I had in the #git channel on
freenode.
I have a setup where various subdirectories of a number of git repos are
symlinked into a common directory tree. Something like what the
following would create but with more repositories involved:
cd ~; mkdir foo; chdir foo; git init; mkdir bar; git add bar ; git
commit -m'add bar' ; cd ~; ln -s foo/bar bar ; cd bar;
[try various git commands, not all will work]
Most git command seem perfectly happy to work on the correct repos from
this symlinked tree. However at least one doesnt, git pull --rebase, in
particular.
Doing a
git-rev-parse --git-dir
seems to behave correctly (always finding the correct location) and
git-rev-parse --is-inside-work-dir
reports true. However git-pull --rebase responds with lots of "fatal:
Not a git repository" messages. Example is below.
During discussion about this on #git it was suggested this was because
git-rev-parse --show-cdup
returns a relative path. (../).
Im not on list so id appreciate it if anyone replying to this could cc
me on the mail.
Oh, i am aware of submodules but i have to work with what i have now.
Cheers,
yves
Example of git pull --rebase failing yet git commit working:
[dmq@somewhere apps]$ echo test > test.txt
[dmq@somewhere apps]$ git add test.txt
[dmq@somewhere apps]$ git commit -m'add a test file -- will remove next
commit'
Created commit 45ab725: add a test file -- will remove next commit
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 apps/test.txt
[dmq@somewhere apps]$ git rm test.txt
rm 'apps/test.txt'
[dmq@somewhere apps]$ git commit -m'removed test file'
Created commit 2768e6d: removed test file
1 files changed, 0 insertions(+), 1 deletions(-)
delete mode 100644 apps/test.txt
[dmq@somewhere apps]$ git pull --rebase
fatal: Not a git repository
fatal: Not a git repository
fatal: Not a git repository
fatal: Not a git repository
^ permalink raw reply
* Re: git stash save --keep-index
From: SZEDER Gábor @ 2008-07-15 14:26 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Git Mailinglist
In-Reply-To: <bd6139dc0807150531k4f0a1a4yee2c8ec2b98ee39c@mail.gmail.com>
Hi Sverre,
On Tue, Jul 15, 2008 at 02:31:54PM +0200, Sverre Rabbelier wrote:
> <hack hack hack>
> $ git add # or -i / -p
> $ git stash save --keep-index
> <test if staged changes are ready to be commited>
> $ git commit
> $ git stash pop
> <lather, rinse, repeat>
>
> But what happens if in the testing phase you detect that the commit is
> not ready yet, or even, some of the changes you staged should have
> been kept? It would make sense to 'undo' the stash the usual way:
> $ git stash pop
> But alas, it is not possible to apply on a dirty working directory, so
> one has to resort to:
> $ git commit -m "tmp"
> $ git stash pop
> $ git reset HEAD^
If there are unstaged changes in the worktree, then yes, 'git stash
apply/pop' will error out complaining about dirty state. However, if
there are changes in the index, but no unstaged changes in the
worktree, then apply/pop should work (assuming there are no conflicts,
of course).
So, you won't need that temporary commit, if you have not modified
anything or have added all changes to the index since 'git stash
save --keep-index'.
Gábor
^ permalink raw reply
* Re: Standard "git svn init ; git svn fetch" behavior
From: Peter Harris @ 2008-07-15 14:37 UTC (permalink / raw)
To: Peter Valdemar Mørch (Lists); +Cc: git
In-Reply-To: <487C88D0.30609@sneakemail.com>
On Tue, Jul 15, 2008 at 7:24 AM, "Peter Valdemar Mørch (Lists)" wrote:
>
> 1) It seems the svn tags were converted into git branches such as
> "tags/mytag". Is that normal?
Yes.
Subversion doesn't really have tags. They're just branches with 'tag'
in the name. git-svn wants them to be branches on the git side so that
it can track future commits to the 'tag'.
> Re: 2) Why does master end up being off of tags/mytag instead of off of
> trunk?
>
> I would have expected, that "master" ended up tracking "trunk", and not
> tags/mytag. Why track an obscure tag instead of trunk?
Some projects work on trunk and keep a maint branch. Some projects
work on branches, and only merge bug fixes to trunk. To facilitate
this model, git-svn tries to guess which branch is your working
branch, and picks that one to be master.
In this case, you were unlucky enough to have the most recent commit
be on a tag-branch.
> Is there a smarter way to find out what branchpoint was used to create
> "master"? (I'm new to git, and find it difficult to see what my branches
> were "made from")
Git doesn't know what any particular branch was "made from", as the
branch point in question may be an ancestor of any number of other
branches.
git-svn does keep track of the subversion branch you are working on.
"git svn info"
Peter Harris
^ permalink raw reply
* git config oddity
From: Sverre Rabbelier @ 2008-07-15 14:44 UTC (permalink / raw)
To: Git Mailinglist
Heya,
I noticed today that when unsetting the last value in a group git
config leaves the empty group header. I was somewhat surprised here,
but I am guessing it has a purpose? Anyway, I also noticed (and this
threw my manual config parser off) that when later on an option is set
to that empty group, a new group is created with the same name. Is
this something I have to deal with in my parser (e.g., should I keep
scanning the file for occurrences of my header and allow for empty
groups, or is this a bug in git config? Either is fine with me, was
just wondering :).
-----------------
sverre@Laptop-Sverre:~/code$ mkdir config-oddity
sverre@Laptop-Sverre:~/code$ cd config-oddity/
sverre@Laptop-Sverre:~/code/config-oddity$ git init
Initialized empty Git repository in /home/sverre/code/config-oddity/.git/
sverre@Laptop-Sverre:~/code/config-oddity$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
sverre@Laptop-Sverre:~/code/config-oddity$ git config foo.bar spam
sverre@Laptop-Sverre:~/code/config-oddity$ cat .git/config # as expected
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[foo]
bar = spam
sverre@Laptop-Sverre:~/code/config-oddity$ git config --unset foo.bar
sverre@Laptop-Sverre:~/code/config-oddity$ cat .git/config # dubious,
but acceptable
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[foo]
sverre@Laptop-Sverre:~/code/config-oddity$ git config foo.bar eggs
sverre@Laptop-Sverre:~/code/config-oddity$ cat .git/config # errr? two
[foo] headers?
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[foo]
[foo]
bar = eggs
sverre@Laptop-Sverre:~/code/config-oddity$
-----------------
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: git stash save --keep-index
From: Sverre Rabbelier @ 2008-07-15 14:50 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Git Mailinglist
In-Reply-To: <20080715142615.GI8224@neumann>
On Tue, Jul 15, 2008 at 4:26 PM, SZEDER Gábor <szeder@ira.uka.de> wrote:
> If there are unstaged changes in the worktree, then yes, 'git stash
> apply/pop' will error out complaining about dirty state. However, if
> there are changes in the index, but no unstaged changes in the
> worktree, then apply/pop should work (assuming there are no conflicts,
> of course).
>
> So, you won't need that temporary commit, if you have not modified
> anything or have added all changes to the index since 'git stash
> save --keep-index'.
Mhhh, ok, I can live with that, thanks!
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* [PATCH] git rev-parse: Fix --show-cdup inside symlinked directory
From: Petr Baudis @ 2008-07-15 14:59 UTC (permalink / raw)
To: gitster; +Cc: git
In-Reply-To: <1216131208.19334.171.camel@gemini>
Consider the scenario when someone makes a symlink into a working tree
subdirectory at an unrelated place, then attempts to work inside the
symlinked directory. The scenario is a bit unwieldly, but most of
the Git will handle it fine - except git rev-parse --show-cdup. That
will output a sequence of ../ which will work wrong inside the symlink
using shell cd builtin.
This patch changes --show-cdup to always show absolute workdir path
instead. I think this should hopefully cause no compatibility problems;
the testsuite is passing fine, at least. The patch also adds
a --show-cdup check and this particular scenartio to the t1500 test.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Documentation/git-rev-parse.txt | 4 ++--
builtin-rev-parse.c | 15 +++++----------
t/t1500-rev-parse.sh | 18 ++++++++++++++++--
3 files changed, 23 insertions(+), 14 deletions(-)
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index 088f971..4c289d0 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -103,8 +103,8 @@ OPTIONS
--show-cdup::
When the command is invoked from a subdirectory, show the
- path of the top-level directory relative to the current
- directory (typically a sequence of "../", or an empty string).
+ path of the top-level directory, or an empty string if the
+ current directory is the top-level directory.
--git-dir::
Show `$GIT_DIR` if defined else show the path to the .git directory.
diff --git a/builtin-rev-parse.c b/builtin-rev-parse.c
index a7860ed..011d16c 100644
--- a/builtin-rev-parse.c
+++ b/builtin-rev-parse.c
@@ -500,22 +500,17 @@ int cmd_rev_parse(int argc, const char **argv, const char *prefix)
continue;
}
if (!strcmp(arg, "--show-cdup")) {
- const char *pfx = prefix;
- if (!is_inside_work_tree()) {
+ if (prefix) {
+ /* We are not at the top level yet */
const char *work_tree =
get_git_work_tree();
if (work_tree)
printf("%s\n", work_tree);
continue;
+ } else {
+ /* Backwards compatibility */
+ putchar('\n');
}
- while (pfx) {
- pfx = strchr(pfx, '/');
- if (pfx) {
- pfx++;
- printf("../");
- }
- }
- putchar('\n');
continue;
}
if (!strcmp(arg, "--git-dir")) {
diff --git a/t/t1500-rev-parse.sh b/t/t1500-rev-parse.sh
index 85da4ca..2f0bf15 100755
--- a/t/t1500-rev-parse.sh
+++ b/t/t1500-rev-parse.sh
@@ -26,9 +26,14 @@ test_rev_parse() {
"test '$1' = \"\$(git rev-parse --show-prefix)\""
shift
[ $# -eq 0 ] && return
+
+ test_expect_success "$name: cdup" \
+ "test '$1' = \"\$(git rev-parse --show-cdup)\""
+ shift
+ [ $# -eq 0 ] && return
}
-# label is-bare is-inside-git is-inside-work prefix
+# label is-bare is-inside-git is-inside-work prefix cdup
test_rev_parse toplevel false false true ''
@@ -38,11 +43,20 @@ cd objects || exit 1
test_rev_parse .git/objects/ false true false ''
cd ../.. || exit 1
+basedir=$(pwd)
mkdir -p sub/dir || exit 1
cd sub/dir || exit 1
-test_rev_parse subdirectory false false true sub/dir/
+test_rev_parse subdirectory false false true sub/dir/ "$basedir"
cd ../.. || exit 1
+# Scenario: Working within a subdirectory symlinked out of the working tree
+mkdir -p maindir || exit 1
+(mv .git maindir && mkdir -p maindir/sub2 && ln -s maindir/sub2 .) || exit 1
+cd sub2 || exit 1
+test_rev_parse 'symlinked subdirectory' false false true sub2/ "$basedir"/maindir
+cd .. || exit 1
+(rm sub2 && mv maindir/.git . && rm -r maindir) || exit 1
+
git config core.bare true
test_rev_parse 'core.bare = true' true false false
^ permalink raw reply related
* Re: git config oddity
From: Johannes Schindelin @ 2008-07-15 15:02 UTC (permalink / raw)
To: sverre; +Cc: Git Mailinglist
In-Reply-To: <bd6139dc0807150744l78eb8d54ld167d3a9a5a600f@mail.gmail.com>
Hi,
On Tue, 15 Jul 2008, Sverre Rabbelier wrote:
> I noticed today that when unsetting the last value in a group git
> config leaves the empty group header.
That is on purpose. As .git/config was always meant as a user-editable
file, you can put comments into that section. Or comment out some values.
So "git config" does not remove the section, even if no variable is there
at the moment.
It is somewhat unfortunate that setting a variable does not find the
section; the reason is that it sees sections only when a variable is set
(to avoid having to do the parsing itself).
Hth,
Dscho
^ permalink raw reply
* Re: Closing the merge window for 1.6.0
From: Dmitry Potapov @ 2008-07-15 15:06 UTC (permalink / raw)
To: Petr Baudis
Cc: Junio C Hamano, Nicolas Pitre, Gerrit Pape, Johannes Schindelin,
git
In-Reply-To: <20080715092023.GO10151@machine.or.cz>
On Tue, Jul 15, 2008 at 11:20:23AM +0200, Petr Baudis wrote:
>
> (iii) Most importantly, this is not about waiting another few
> years for Debian to catch up, since the next stable release
> should really be upcoming rather soon:
>
> http://debian-community.org/LennyReleaseSchedule/
Even if Lenny will be released right on the scheduler (which I seriously
doubt), Etch will be around for another year. In fact, the last release
of oldstable (sarge) happened on April 12 this year. Thus delaying of
indexversion=2 does not help much here. Anyone who is more or less
seriously about using Git grabs it from backports. The downside of
delaying is that any incompatible changes are much less welcome by users
during minor releases than major ones. People tend to read release notes
during major releases more carefully and think whether they prefer new
features or backward compatibility. This choice will not be the same for
anyone, but changing default settings on the major release is much more
appropriate than during minor ones.
>
> (iv) These problems do not concern people who are currently
> _actively_ _working_ with Git; these people hopefully do not
> use 1.4 willingly and already use Git from backports.org.
> This is about user experience for casual users who are quite
> possibly interested only in read-only tracking of upstream
> using Git - these people will likely use default Debian Git
> version and that is okay, because frankly, for them, the
> 1.5 improvements do not really matter much. This is also
> large class of prospective future real Git users and we might
> not want to ruin Git's reputation in their eyes.
I disagree. It is not Git does not support the old format, but it
switches on the new one as default on the next major release, which
is a sensible thing to do. Those repos that think that access for
Git 1.4 users is important for them can set indexformat=1. As to
prospective future real Git users, anyone who is trying to use Git
1.4 is going to hit by many usability issues that were resolved in
1.5; and there is no community support for Git 1.4 either -- you can
ask about any problem with Git 1.4 on this list, and the only answer
you'll get is that you should upgrade your Git. So, there is no way
for newcommers to start using Git 1.4 and be satisfied with it.
Finally, 18 months since 1.4.4 may not appear as a long time ago for
other projects that are being developed for many years, but for Git,
which was only 21 months when Git 1.4.4 was released, 18 months is
really very *long* time ago.
Dmitry
^ permalink raw reply
* Re: [PATCH] git rev-parse: Fix --show-cdup inside symlinked directory
From: Johannes Schindelin @ 2008-07-15 15:19 UTC (permalink / raw)
To: Petr Baudis; +Cc: gitster, git
In-Reply-To: <20080715145920.13529.25603.stgit@localhost>
Hi,
On Tue, 15 Jul 2008, Petr Baudis wrote:
> Consider the scenario when someone makes a symlink into a working tree
> subdirectory at an unrelated place, then attempts to work inside the
> symlinked directory. The scenario is a bit unwieldly, but most of
> the Git will handle it fine - except git rev-parse --show-cdup. That
> will output a sequence of ../ which will work wrong inside the symlink
> using shell cd builtin.
Short version: do not use symlinks in the working directory, if you do not
want to track the _symlink_.
Long version: there are a lot of problems with that, and --show-cdup is
the least of the problems. A checkout, for example, is able to kill the
symlink and check out a fresh copy of the subdirectory.
AFAICT this is a concious decision: If you want to track a symlink, track
a symlink, but if you want to track a subdirectory, you will have to track
a subdirectory, and it cannot be a symlink.
> This patch changes --show-cdup to always show absolute workdir path
> instead. I think this should hopefully cause no compatibility problems;
> the testsuite is passing fine, at least.
See the thread where I proposed a change like this, back with the infamous
worktree desaster, and Junio NACKed; or the thread where Linus rightfully
insists that git_dir should be relative if possible, for performance
reasons.
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH 0/6] archive: refactor and cleanup
From: Junio C Hamano @ 2008-07-15 15:21 UTC (permalink / raw)
To: René Scharfe; +Cc: git
In-Reply-To: <487C568F.6030705@lsrfire.ath.cx>
René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> Lea Wiemann schrieb:
> ...
>> Feel free to ping me on IRC (lea_w in #git) if you need help.
>
> I've slacked long enough to become a complete noob again. Oh, well.
Lol ;-)
The series looks good. Thanks.
^ permalink raw reply
* Re: [PATCH] git-rebase.sh: Display error output from git-checkout when detaching HEAD fails.
From: Junio C Hamano @ 2008-07-15 15:22 UTC (permalink / raw)
To: Rob Shearman; +Cc: git
In-Reply-To: <1096648c0807141257i76f70322p5a16c86c1c826a66@mail.gmail.com>
"Rob Shearman" <robertshearman@gmail.com> writes:
> 2008/7/11 Junio C Hamano <gitster@pobox.com>:
> ...
>> I think this very much is done deliberately by somebody who knows the
>> shell to discard everything.
>
> Why wasn't "git checkout "$onto^0" &> /dev/null" used then? Then only
> reason I can come up with would be portability,...
Yes, we are quite old fashioned when it comes to shell scripting.
>> ... Perhaps you can replace the line with
>>
>> git checkout -q "$onto^0"
>>
>> and be done with it. I haven't tested it, though.
>
> I just tested it and it solves the original issue whilst not
> displaying unnecessary messages during a rebase. For reference, the
> attached script reproduces the issue that I was trying to solve.
>
> Should I resend the patch (like the following) now that it is
> effectively completely your work?
Your choice.
The issues you might want to consider when making that choice are:
- Resending something that is trivial may seem waste of time on your
part;
- Bringing the issue up is more than half of solving it, and you deserve
the credit. By resending with a clear commit log message you assure
this;
- I am handling many patches for git.git that are readily applicable
immediately after I read them in my mbox, while creating a commit out
of this discussion is something I need to "work on". When I get around
to do some git work tonight, I may not even recall this dialogue, and
the solution may be forgotten.
- I am lazy and may forget to pass --author="Rob Shearman <your@email>"
even if I remember this conversation and when I make a commit myself;
I just made a commit out of this discussion before I forget, so no need to
resend for this one, but in general I'd appreciate a resend in general ;-)
-- >8 --
From: Junio C Hamano <gitster@pobox.com>
Date: Mon, 14 Jul 2008 14:05:35 -0700
Subject: [PATCH] git-rebase: report checkout failure
When detaching the HEAD to the base commit, the "git checkout" command
could fail if, for example, upstream contains a file that would overrwrite
a local, untracked file. Unconditionally discarding the standard error
stream was done to squelch the progress and notices back when checkout
did not have -q option, but there is no reason to keep doing it anymore.
Noticed by Robert Shearman.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git-rebase.sh | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index e2d85ee..7825f88 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -376,9 +376,7 @@ fi
# Detach HEAD and reset the tree
echo "First, rewinding head to replay your work on top of it..."
-git checkout "$onto^0" >/dev/null 2>&1 ||
- die "could not detach HEAD"
-# git reset --hard "$onto^0"
+git checkout -q "$onto^0" || die "could not detach HEAD"
# If the $onto is a proper descendant of the tip of the branch, then
# we just fast forwarded.
--
1.5.6.3.473.gc658e
^ permalink raw reply related
* Re: Closing the merge window for 1.6.0
From: Johannes Schindelin @ 2008-07-15 15:27 UTC (permalink / raw)
To: Dmitry Potapov
Cc: Petr Baudis, Junio C Hamano, Nicolas Pitre, Gerrit Pape, git
In-Reply-To: <20080715150626.GA2925@dpotapov.dyndns.org>
Hi,
On Tue, 15 Jul 2008, Dmitry Potapov wrote:
> Those repos that think that access for Git 1.4 users is important for
> them can set indexformat=1.
Unfortunately, you place quite a high maintenance burden on the repository
maintainers here.
>From the time balance sheet, it does not look good at all: a few minutes
for Junio to change and commit, up to a few hours (because they missed it
in the release notes) for probably more than hundred repository
maintainers that are not subscribed to the Git mailing list.
And I absolutely agree with Pasky that this does _nothing_ in the vague
direction of wielding a reputation of being easy to use.
Sure, we can make it easy on ourselves. And it is just as easy to make it
hard on others. If you're okay with that, I am not.
Ciao,
Dscho
^ permalink raw reply
* Re: git config oddity
From: Sverre Rabbelier @ 2008-07-15 15:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailinglist
In-Reply-To: <alpine.DEB.1.00.0807151600170.8950@racer>
On Tue, Jul 15, 2008 at 5:02 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>> I noticed today that when unsetting the last value in a group git
>> config leaves the empty group header.
>
> That is on purpose. As .git/config was always meant as a user-editable
> file, you can put comments into that section. Or comment out some values.
Ok, this makes sense :). I agree that I would be unhappily surprised
if I found that git removed a section that I had put some comments in
when I unset a variable.
> It is somewhat unfortunate that setting a variable does not find the
> section; the reason is that it sees sections only when a variable is set
> (to avoid having to do the parsing itself).
Ah, unfortunate indeed. I'm not sure I understand why it does not see
the existing header? I had a look at config.c but I couldn't really
make out why it doesn't. Would it be difficult to add that?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: git config oddity
From: Johannes Schindelin @ 2008-07-15 15:33 UTC (permalink / raw)
To: sverre; +Cc: Git Mailinglist
In-Reply-To: <bd6139dc0807150829n2b3c88d7p18c203e93cd4e0c1@mail.gmail.com>
Hi,
On Tue, 15 Jul 2008, Sverre Rabbelier wrote:
> On Tue, Jul 15, 2008 at 5:02 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>
> > It is somewhat unfortunate that setting a variable does not find the
> > section; the reason is that it sees sections only when a variable is
> > set (to avoid having to do the parsing itself).
>
> Ah, unfortunate indeed. I'm not sure I understand why it does not see
> the existing header? I had a look at config.c but I couldn't really make
> out why it doesn't.
The config writing uses the config parser to determine where the locations
of the config variables (and therefore, sections) are by using the parser,
and remembering the position in the file.
> Would it be difficult to add that?
Yes.
Ciao,
Dscho
^ permalink raw reply
* Re: git config oddity
From: Sverre Rabbelier @ 2008-07-15 15:35 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailinglist
In-Reply-To: <alpine.DEB.1.00.0807151631520.8950@racer>
On Tue, Jul 15, 2008 at 5:33 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> The config writing uses the config parser to determine where the locations
> of the config variables (and therefore, sections) are by using the parser,
> and remembering the position in the file.
Ok, thanks for the explanation, I'll add a workaround in my code.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* --username wrong or ignored for git-svn
From: Stephen Sinclair @ 2008-07-15 15:37 UTC (permalink / raw)
To: Git Mailing List
Hello,
Just now I attempted to commit some changes that a coworker had made
to our subversion repository using git-svn. Since it was his work, we
attempted to commit it using his username, though it was done in a git
repository that I'd previously used with my username. So I did:
git-svn dcommit --username <name>
But it ignored --username and the commit is now attributed to me.
Is it because I'd previously done dcommit in my own username?
There was no warning that it wouldn't do what I expected.
Admittedly it's was a weird thing to have him make a change in my
local repository but we didn't think it would be a problem if we
carefully used --username.
thanks,
Steve
^ permalink raw reply
* Re: [PATCH] git rev-parse: Fix --show-cdup inside symlinked directory
From: Petr Baudis @ 2008-07-15 15:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: gitster, git, yves.orton
In-Reply-To: <alpine.DEB.1.00.0807151614510.8950@racer>
Hi,
On Tue, Jul 15, 2008 at 04:19:30PM +0100, Johannes Schindelin wrote:
> On Tue, 15 Jul 2008, Petr Baudis wrote:
>
> > Consider the scenario when someone makes a symlink into a working tree
> > subdirectory at an unrelated place, then attempts to work inside the
> > symlinked directory. The scenario is a bit unwieldly, but most of
> > the Git will handle it fine - except git rev-parse --show-cdup. That
> > will output a sequence of ../ which will work wrong inside the symlink
> > using shell cd builtin.
>
> Short version: do not use symlinks in the working directory, if you do not
> want to track the _symlink_.
>
> Long version: there are a lot of problems with that, and --show-cdup is
> the least of the problems. A checkout, for example, is able to kill the
> symlink and check out a fresh copy of the subdirectory.
>
> AFAICT this is a concious decision: If you want to track a symlink, track
> a symlink, but if you want to track a subdirectory, you will have to track
> a subdirectory, and it cannot be a symlink.
no, no, this is for the scenario other way around: you have a normal
subdirectory in the working tree, and point a symlink _at_ it from
$somewhere_else. Then you try to work in $somewhere_else/symlink.
> > This patch changes --show-cdup to always show absolute workdir path
> > instead. I think this should hopefully cause no compatibility problems;
> > the testsuite is passing fine, at least.
>
> See the thread where I proposed a change like this, back with the infamous
> worktree desaster, and Junio NACKed; or the thread where Linus rightfully
> insists that git_dir should be relative if possible, for performance
> reasons.
I see, <7vk5sly3h9.fsf@assigned-by-dhcp.cox.net>. But noone was aware
of this possible user case. Performance reasons sound reasonable, though
I'm not really sure if for cdup in particular this ever matters.
P.S.: Either way, there is a possible workaround to tell git about the
working directory manually using git --work-tree=... that I missed to
mention on IRC, Yves.
--
Petr "Pasky" Baudis
GNU, n. An animal of South Africa, which in its domesticated state
resembles a horse, a buffalo and a stag. In its wild condition it is
something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce
^ permalink raw reply
* Re: Closing the merge window for 1.6.0
From: Avery Pennarun @ 2008-07-15 15:51 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Dmitry Potapov, Petr Baudis, Junio C Hamano, Nicolas Pitre,
Gerrit Pape, git
In-Reply-To: <alpine.DEB.1.00.0807151623120.8950@racer>
On 7/15/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Tue, 15 Jul 2008, Dmitry Potapov wrote:
> > Those repos that think that access for Git 1.4 users is important for
> > them can set indexformat=1.
>
> Unfortunately, you place quite a high maintenance burden on the repository
> maintainers here.
>
> From the time balance sheet, it does not look good at all: a few minutes
> for Junio to change and commit, up to a few hours (because they missed it
> in the release notes) for probably more than hundred repository
> maintainers that are not subscribed to the Git mailing list.
To take this in a slightly different direction, what exactly is the
benefit of the new feature? Apparently my git doesn't have it enabled
by default, and git works fine for me. Am I missing out on something
that I should feel inferior about if my non-debian-etch running
friends(*) found out about it? :)
Have fun,
Avery
(*) Actually I compile my own git from source anyway. I never want to
live without "git rebase -i" and "git add -p" ever again. Life is too
short! :)
^ permalink raw reply
* Re: Increased maintainer work during Summer of Code
From: Junio C Hamano @ 2008-07-15 15:52 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Christian Couder, Daniel Barkalow, Johannes Schindelin, J.H.,
Sam Vilain, git
In-Reply-To: <20080715060427.GB3337@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Junio, I know you have been working extra hard lately with the
> merge of builtin merge, and now gitweb and the sequencer are also
> being looked at in much greater detail.
I do not currently perceive much problem. If they are being looked at in
much greater detail, that is good.
> What can we do to smooth out this workload better? Its awesome
> that we were so fortunate to get these great students this year,
> and have so much contributed in so little time, but we also do
> not want to see maintainer burn-out. We also want to avoid a
> huge backlog of patches.
For GSoC participants, it might be of utmost importance that their patches
are looked at, reviewed and integrated. To me, there is no reason to give
any preferential treatment for GSoC students. Students may need to learn
how to cope with busy, overloaded, and/or grumpy maintainer. It is a
necessary skill to work effectively in an open source project they need to
acquire.
When there are more urgent issues than their projects, patches from GSoC
students may drop through the crack in the floor just like any other
submitters', and more importantly, the urgency is determined solely by
judging how important the issue is for git.git project, not GSoC. Usually
when patches are dropped, its the original submitters job to remind,
resend, or make it easier for the maintainer to take any corrective
measure (e.g. host her own tree to be pulled from) --- GSoC students
should learn to do the same, and their mentors would help them with this.
The community has matured to the point that there are a few areas with
trustworthy area experts, and I do not have to look at certain patches
very deeply myself. To name only a few, I just apply patches to git-svn
that are either from Eric or acked by him without looking at them (I may
spot obvious typos by accident and fix them up, though); patches to
"archive" from René are the same way.
People can help widen areas that are covered like so. I admit that I am
hesitant to let go of certain areas, e.g. sha1_file.c layer, even though I
know Nico and you are as competent and knowledgeable in that area as I am
if not more, simply because such a very core part of the system really
matters. I expect there will always be areas in which I have to look at
all changes for my own peace of mind, but even in these areas I do not
have to be the only person to look at and review the patches.
^ permalink raw reply
* Re: Closing the merge window for 1.6.0
From: Nicolas Pitre @ 2008-07-15 16:26 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Dmitry Potapov, Petr Baudis, Junio C Hamano, Gerrit Pape, git
In-Reply-To: <alpine.DEB.1.00.0807151623120.8950@racer>
On Tue, 15 Jul 2008, Johannes Schindelin wrote:
> And I absolutely agree with Pasky that this does _nothing_ in the vague
> direction of wielding a reputation of being easy to use.
Staying with git versions prior 1.5 isn't either. In fact, git had a
much harder time with its usability reputation in those days. In other
words, if some user of Debian is rebutted by the upgrade path for a later
git version, then the awkwardness of git 1.4.4 UI will be even worse.
Anyway this is all hand waving until someone can come with some evidence
that git 1.4.4 is actually used by a significant amount of people, and
that those people depend on dumb transfer protocols.
Nicolas
^ permalink raw reply
* Re: [PATCH] git rev-parse: Fix --show-cdup inside symlinked directory
From: Yves Orton @ 2008-07-15 16:41 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes Schindelin, gitster, git
In-Reply-To: <20080715154036.GR10151@machine.or.cz>
On Tue, 2008-07-15 at 17:40 +0200, Petr Baudis wrote:
> no, no, this is for the scenario other way around: you have a normal
> subdirectory in the working tree, and point a symlink _at_ it from
> $somewhere_else. Then you try to work in $somewhere_else/symlink.
Yes correct. We have a number of different repositories like so:
banana.git/apps
banana.git/lib
orange.git/config
kiwi.git/refdata
and its convenient for many of our existing apps to be able to symlink
them all together into a common tree
joined/apps -> banana.git/apps
joined/lib -> banana.git/lib
joined/config -> orange.git/config
joined/refdata -> kiwi.git/refdata
this way for instance we can swap bits around easily on the fly and say,
restart a webserver or whatever.
Currently we can do this and all our other stuff works, and you
can /mostly/ work with git from the "joined" tree, with the exception of
git pull --rebase and apparently anything else that relies on
--show-cdup
> > > This patch changes --show-cdup to always show absolute workdir path
> > > instead. I think this should hopefully cause no compatibility problems;
> > > the testsuite is passing fine, at least.
> >
> > See the thread where I proposed a change like this, back with the infamous
> > worktree desaster, and Junio NACKed; or the thread where Linus rightfully
> > insists that git_dir should be relative if possible, for performance
> > reasons.
>
> I see, <7vk5sly3h9.fsf@assigned-by-dhcp.cox.net>. But noone was aware
> of this possible user case. Performance reasons sound reasonable, though
> I'm not really sure if for cdup in particular this ever matters.
Would it be so bad to detect if the show-cdup actually resolves to the
right place, and if it doesnt go absolute?
>
> P.S.: Either way, there is a possible workaround to tell git about the
> working directory manually using git --work-tree=... that I missed to
> mention on IRC, Yves.
Hmm, am i using it wrong then?
[dmq@somewhere apps]$ git-rev-parse --git-dir
/home/dmq/git_tree/main/.git
[dmq@somewhere apps]$ git --work-tree="$(git-rev-parse --git-dir)" pull
--rebase
/usr/bin/git-sh-setup: line 139: cd: .git: No such file or directory
Unable to determine absolute path of git directory
cheers,
yves
ps: not on list, please cc me on replies (sorry for the hassle)
^ 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