* Re: possible bug in git apply?
From: Junio C Hamano @ 2007-08-04 20:00 UTC (permalink / raw)
To: david; +Cc: git, rob
In-Reply-To: <Pine.LNX.4.64.0708041243070.6905@asgard.lang.hm>
david@lang.hm writes:
> since git doesn't track directories, only content (per the big
> discussion recently) I beleive that doing a checkout would leave Rob
> without the directories that he emptied out, so shouldn't git apply
> also clear the directories to end up in the same state?
It should and it does, unless you have untracked files in that
directory that you haven't told git about. Then removing the
directory along with these files will lose the files there,
which is a wrong thing to do.
A simple "rm -fr this/directory/is/no/longer/interesting/to/me"
would be all that is needed.
^ permalink raw reply
* Re: possible bug in git apply?
From: David Kastrup @ 2007-08-04 20:08 UTC (permalink / raw)
To: david; +Cc: git, rob
In-Reply-To: <Pine.LNX.4.64.0708041243070.6905@asgard.lang.hm>
david@lang.hm writes:
> On Saturday 04 August 2007 2:03:59 pm Rob Landley wrote:
>> Signed-off-by: Rob Landley <rob@landley.net>
>> Amiga part Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
>>
>> Move architecture-specific Documentation into a common subdirectory.
>
> I really, really, really hate git.
>
> Ok, on my laptop I just noticed that "git apply" of the patch didn't
> complain but it also left the empty subdirectories it moved stuff
> out of. (I don't believe this happened on the version of git I was
> using on my previous laptop, which ate itself a month and change
> ago, but obviously I can't check.)
>
> There is no "git rmdir". "git rm" refuses to delete the directory
> without -r. "git rm -r Documentation/x86_64" listed (as just deleted) all
> the files that the patch already moved out of the directory.
>
> Am I missing something obvious here?
Committing the change?
> since git doesn't track directories, only content (per the big
> discussion recently) I beleive that doing a checkout would leave Rob
> without the directories that he emptied out, so shouldn't git apply
> also clear the directories to end up in the same state?
Yes, once he commits. As long as git keeps files tracked in that
directory, there is no reason for it to delete it.
I agree that it is hard to come up with a good logic for this sort of
thing. git-add checks the _current_ state of a file into the index.
git-rm can actually do the same only by actually _deleting_ the
working copy. So when should git try deleting the directory?
Probably when the directory becomes empty in the index, for
consistency. Too bad that the index does not contain any information
about directories at all, so there is no good way to figure this
particular point in time out efficiently.
I guess that git rather attempts deleting the directory when the tree
in the _repository_ rather than the index becomes empty. And for that
you need to commit.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: rc4 - make quick-install-doc is broken
From: René Scharfe @ 2007-08-04 20:19 UTC (permalink / raw)
To: Mark Levedahl; +Cc: Johannes Schindelin, Junio C Hamano, Git Mailing List
In-Reply-To: <46B4A2B0.9080208@gmail.com>
Mark Levedahl schrieb:
> git>git bisect good
> 6490a3383f1d0d96c122069e510ef1af1d019fbb is first bad commit
I've started a bisect run myself and ended up at a different commit,
viz. e90fdc39b6903502192b2dd11e5503cea721a1ad ("Clean up work-tree
handling"). Hmm. I guess this candidate has a greater chance of
actually being the culprit than yours. ;-)
I can't offer a fix, but I think I've captured install-doc-quick.sh's
problem in a test script (see below). It fails with e90fdc3 (and
master) but succeeds with e90fdc3^.
Apparently checkout-index (and ls-files, but this is not used by the
install script) can now be confused by running it from inside an
untracked directory.
Johannes, does this help you in finding out what's going on here?
René
diff --git a/dev/null b/t/t1502-untracked.sh
new file mode 100755
index 0000000..3fbdb02
--- /dev/null
+++ b/t/t1502-untracked.sh
@@ -0,0 +1,36 @@
+#!/bin/sh
+
+test_description='accessing the index from an untracked directory'
+. ./test-lib.sh
+
+pwd=$(pwd)
+GIT_DIR=$pwd/.git
+export GIT_DIR
+
+test_expect_success 'setup' '
+ git init &&
+ echo some file content >some_file &&
+ git add some_file &&
+ git commit -m "added a file" some_file &&
+ mkdir untracked
+'
+
+test_expect_success 'test read-tree from an untracked directory' '
+ ( GIT_INDEX_FILE=$pwd/idx-a git read-tree HEAD) &&
+ (cd untracked && GIT_INDEX_FILE=$pwd/idx-b git read-tree HEAD) &&
+ git diff --binary idx-a idx-b
+'
+
+test_expect_success 'test checkout-index from an untracked directory' '
+ ( git checkout-index -a --prefix=$pwd/a/) &&
+ (cd untracked && git checkout-index -a --prefix=$pwd/b/) &&
+ git diff a/ b/
+'
+
+test_expect_success 'test ls-files from an untracked directory' '
+ ( git ls-files) >ls-files-a &&
+ (cd untracked && git ls-files) >ls-files-b &&
+ git diff ls-files-a ls-files-b
+'
+
+test_done
^ permalink raw reply related
* Re: rc4 - make quick-install-doc is broken
From: Johannes Schindelin @ 2007-08-04 20:21 UTC (permalink / raw)
To: René Scharfe; +Cc: Mark Levedahl, Junio C Hamano, Git Mailing List
In-Reply-To: <46B4DF39.2070506@lsrfire.ath.cx>
Hi,
On Sat, 4 Aug 2007, Ren? Scharfe wrote:
> Mark Levedahl schrieb:
> > git>git bisect good
> > 6490a3383f1d0d96c122069e510ef1af1d019fbb is first bad commit
>
> I've started a bisect run myself and ended up at a different commit,
> viz. e90fdc39b6903502192b2dd11e5503cea721a1ad ("Clean up work-tree
> handling"). Hmm. I guess this candidate has a greater chance of
> actually being the culprit than yours. ;-)
>
> I can't offer a fix, but I think I've captured install-doc-quick.sh's
> problem in a test script (see below). It fails with e90fdc3 (and
> master) but succeeds with e90fdc3^.
>
> Apparently checkout-index (and ls-files, but this is not used by the
> install script) can now be confused by running it from inside an
> untracked directory.
>
> Johannes, does this help you in finding out what's going on here?
Thanks for doing this. I will work on this in a few minutes; at the
moment I am occupied with msysGit...
Ciao,
Dscho
^ permalink raw reply
* Re: Shell script cleanups/style changes?
From: Robert Schiele @ 2007-08-04 20:32 UTC (permalink / raw)
To: Florian Weimer; +Cc: git
In-Reply-To: <873ayzojw7.fsf@mid.deneb.enyo.de>
[-- Attachment #1: Type: text/plain, Size: 883 bytes --]
On Sat, Aug 04, 2007 at 09:10:00AM +0200, Florian Weimer wrote:
> * Robert Schiele:
>
> >> Sure. What about the git-rebase line using $(($end - $msgnum)) ?
> >
> > Bad on Solaris:
> >
> > $ uname -a
> > SunOS solaris10-x64 5.10 Generic i86pc i386 i86pc
> > $ end=1
> > $ msgnum=5
> > $ echo $(($end - $msgnum))
> > syntax error: `(' unexpected
> > $
>
> Is this with /usr/xpg4/bin/sh or /bin/sh? The latter is not POSIX and
> should not be used by GIT, IMHO, otherwise there will be endless
> issues in less-well-tested code paths. Is rewriting the shebang lines
> to use the POSIX shell an option for GIT?
Hi Florian,
I recommend you read the other mails in this thread. This issue is already
completely resolved.
Robert
--
Robert Schiele
Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com
"Quidquid latine dictum sit, altum sonatur."
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Shell script cleanups/style changes?
From: Junio C Hamano @ 2007-08-04 20:39 UTC (permalink / raw)
To: Robert Schiele; +Cc: Florian Weimer, git
In-Reply-To: <20070804203220.GZ29424@schiele.dyndns.org>
Robert Schiele <rschiele@gmail.com> writes:
> Hi Florian,
>
> I recommend you read the other mails in this thread. This issue is already
> completely resolved.
To be a bit more helpful, a short summary is:
* SHELL_PATH in Makefile lets you munge installed scripts;
* /bin/ksh is usable on Solaris and xpg4 is fine too;
* We need to draw a line somewhere, and the current rule is
that we cannot afford to support a shell that does not
understand $(cmd) substitution, as we haven't seen a shell
that supports ${parameter#word} but not $(cmd).
^ permalink raw reply
* Re: rc4 - make quick-install-doc is broken
From: Mark Levedahl @ 2007-08-04 20:45 UTC (permalink / raw)
To: René Scharfe; +Cc: Johannes Schindelin, Junio C Hamano, Git Mailing List
In-Reply-To: <46B4DF39.2070506@lsrfire.ath.cx>
René Scharfe wrote:
> Mark Levedahl schrieb:
>
>> git>git bisect good
>> 6490a3383f1d0d96c122069e510ef1af1d019fbb is first bad commit
>>
>
> I've started a bisect run myself and ended up at a different commit,
> viz. e90fdc39b6903502192b2dd11e5503cea721a1ad ("Clean up work-tree
> handling"). Hmm. I guess this candidate has a greater chance of
> actually being the culprit than yours. ;-)
>
Nak - at commit e90fdc... it works fine for me here. However, one
problem is the following lines in setup.c/set_work_tree() that appear
until 6490a3
strncpy(dir_buffer, dir, len - postfix_len);
/* are we inside the default work tree? */
rel = get_relative_cwd(buffer, sizeof(buffer), dir_buffer);
Note that dir_buffer is not null terminated in the above code, that bug
has been around for a while, and you certainly could run into a
different problem than I did as the results are essentially undefined
here because of that bug.. The key innovation for the current discussion
in commit 6490a33 is that dir_buffer is null terminated after the copy,
causing a different but repeatable result from get_relative_cwd.
I think this ultimately exposes a bug in
builtin-checkout-index/checkout_all wherein the latter does not
explicitly honor the given --prefix option that is passed along in
state. Specifically, on each pass the following test passes
if (prefix && *prefix &&
(ce_namelen(ce) <= prefix_length ||
memcmp(prefix, ce->name, prefix_length)))
continue;
so the code never attempts to write the file out. I cannot fathom what
this test is trying to discern and have to leave it to others more
familiar with the design to figure out the right course. For this
particular use, the passed in prefix is irrelevant, the correct path to
write to is in state.
Mark
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: J. Bruce Fields @ 2007-08-04 21:27 UTC (permalink / raw)
To: David Kastrup
Cc: Linus Torvalds, Steven Grimm, Sam Ravnborg, Junio C Hamano,
Ismail D?nmez, git
In-Reply-To: <85bqdndqgr.fsf@lola.goethe.zz>
On Sat, Aug 04, 2007 at 09:55:48PM +0200, David Kastrup wrote:
> The problem is that html, not even now, offers useful standardized
> structural navigation information,
Actually html is able to represent that kind of information, though
browsers don't seem to take advantage of it. E.g. install something
like this firefox extension:
http://www.christophm.de/software/firefox/cmSiteNavigation/
and then look at
http://www.gnu.org/software/libc/manual/html_node/index.html
Doesn't seem to have keyboard shortcuts, but it's mildly useful.
--b.
^ permalink raw reply
* Re: [RFC/PATCH] update-index: Add a --refresh-only option to refresh specified files.
From: Alexandre Julliard @ 2007-08-04 21:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlkcrgnd1.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> Makes me wonder why it is not like:
>
> $ git update-index --refresh Documentation/
>
> That is:
>
> - why a new option?
It was to avoid breaking backwards compatibility, since passing files
with --refresh currently has a different meaning. But if you think we
can change that, then sure, it would be much nicer.
> - why not a pathspec or glob, similar to what ls-files gets?
I'm not sure, would this really belong in update-index since it
currently always requires explicit pathnames? Or should it be in a
higher-level command like git-add --refresh?
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply
* [PATCH] Fix quick-install-doc
From: Johannes Schindelin @ 2007-08-04 21:32 UTC (permalink / raw)
To: Mark Levedahl; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <46B4BDCF.9060809@gmail.com>
The recent work-tree cleanups exposed that the install-doc-quick
script was relying on a strange behaviour predating the work-tree
series: when setting a GIT_DIR, it was assumed that the current
working directory is the root of the working tree.
The recent work-tree series changed that behaviour: now that you can
set the work tree explicitely, the work tree root defaults to
$GIT_DIR/.. if $GIT_DIR has a /.git suffix when that is a parent
directory of the current working directory.
Noticed by Mark Levedahl. Diagnosed by Junio Hamano.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Junio, I did it slightly differently from what I said on IRC:
setting the work-tree with "--work-tree" does not work as
expected. Will fix.
Documentation/install-doc-quick.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/install-doc-quick.sh b/Documentation/install-doc-quick.sh
index e6601bd..5c8b604 100755
--- a/Documentation/install-doc-quick.sh
+++ b/Documentation/install-doc-quick.sh
@@ -19,7 +19,7 @@ GIT_INDEX_FILE=`pwd`/.quick-doc.index
export GIT_INDEX_FILE
rm -f "$GIT_INDEX_FILE"
git read-tree $head
-git checkout-index -a -f --prefix="$mandir"/
+(cd "$mandir"; git checkout-index -a -f)
if test -n "$GZ"; then
cd "$mandir"
--
1.5.3.rc4.1.g7805
^ permalink raw reply related
* Re: rc4 - make quick-install-doc is broken
From: Johannes Schindelin @ 2007-08-04 21:33 UTC (permalink / raw)
To: René Scharfe; +Cc: Mark Levedahl, Junio C Hamano, Git Mailing List
In-Reply-To: <46B4DF39.2070506@lsrfire.ath.cx>
Hi,
On Sat, 4 Aug 2007, Ren? Scharfe wrote:
> I can't offer a fix, but I think I've captured install-doc-quick.sh's
> problem in a test script (see below). It fails with e90fdc3 (and
> master) but succeeds with e90fdc3^.
It succeeds here... (without the patch I sent out, of course.)
Ciao,
Dscho
^ permalink raw reply
* Re: Some ideas for StGIT
From: Josef Sipek @ 2007-08-04 21:35 UTC (permalink / raw)
To: Theodore Tso; +Cc: Pavel Roskin, Catalin Marinas, git
In-Reply-To: <20070804063858.GA13758@thunk.org>
On Sat, Aug 04, 2007 at 02:38:58AM -0400, Theodore Tso wrote:
> On Fri, Aug 03, 2007 at 01:50:10PM -0400, Pavel Roskin wrote:
> > Hello!
> >
> > I was recently disappointed to learn that one of the Linux drivers
> > (bcm43xx_mac80211, to be precise) switched from git to quilt. I asked
> > whether StGIT was considered, a discussion followed, and I think the key
> > points need to be shared with StGIT developers. I'll add some of my
> > ideas to the mix.
>
> You might also ask them if they considered "guilt", which uses
> text-based patches. It's a lot easier to use, and if they really want
> quilt-like functionality, "guilt" will provide it.
I guess I should chime in.
The goal behind guilt is to be very simple yet powerful enough to do what is
necessary to maintain a piece of kernel code (read: to scratch my own itch).
> And because it's so stupid simple, it's much rarer that something goes
> seriously wrong that requires me to use a recovery procedure in the
> first place.
Thanks! :)
> Editing patch headers are also a lot easier with guilt; you can just
> go ahead and edit them all, and then you can fresh them in git by
> doing a "guilt pop -a; guilt push -a". Since it's not using a
> git-based storage, it doesn't have to rewrite the whole patch stack
> when you modify a single patch header; you can edit a whole bunch of
> text headers and then refresh the git commit series just once.
FYI: v0.27 allows you to edit the patch headers with: guilt header -e
Pavel, if you have any questions, you know where to ask :)
Josef 'Jeff' Sipek.
--
Don't drink and derive. Alcohol and algebra don't mix.
^ permalink raw reply
* Re: [PATCH] Fix quick-install-doc
From: René Scharfe @ 2007-08-04 22:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Mark Levedahl, Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0708042229130.14781@racer.site>
Johannes Schindelin schrieb:
> The recent work-tree cleanups exposed that the install-doc-quick
> script was relying on a strange behaviour predating the work-tree
> series: when setting a GIT_DIR, it was assumed that the current
> working directory is the root of the working tree.
>
> The recent work-tree series changed that behaviour: now that you can
> set the work tree explicitely, the work tree root defaults to
> $GIT_DIR/.. if $GIT_DIR has a /.git suffix when that is a parent
> directory of the current working directory.
> -git checkout-index -a -f --prefix="$mandir"/
> +(cd "$mandir"; git checkout-index -a -f)
That won't work if $mandir doesn't exist, which can happen if you
install the manpages for the first time. Simply add a mkdir:
(mkdir -p "$mandir" && cd "$mandir" && git checkout-index -a -f)
René
^ permalink raw reply
* Re: rc4 - make quick-install-doc is broken
From: René Scharfe @ 2007-08-04 22:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Mark Levedahl, Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0708042232390.14781@racer.site>
Johannes Schindelin schrieb:
> Hi,
>
> On Sat, 4 Aug 2007, Ren? Scharfe wrote:
>
>> I can't offer a fix, but I think I've captured install-doc-quick.sh's
>> problem in a test script (see below). It fails with e90fdc3 (and
>> master) but succeeds with e90fdc3^.
>
> It succeeds here... (without the patch I sent out, of course.)
I assume you tested e90fdc3 and e90fdc3^; what about 4f8f03d (current HEAD)?
Thanks,
René
^ permalink raw reply
* [PATCH] checkout-index needs a working tree
From: Johannes Schindelin @ 2007-08-04 22:20 UTC (permalink / raw)
To: gitster, git
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
This fixes "git --work-tree=/some/where/else checkout-index".
git.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/git.c b/git.c
index 25b8274..f8c4545 100644
--- a/git.c
+++ b/git.c
@@ -315,7 +315,8 @@ static void handle_internal_command(int argc, const char **argv)
{ "branch", cmd_branch, RUN_SETUP },
{ "bundle", cmd_bundle },
{ "cat-file", cmd_cat_file, RUN_SETUP },
- { "checkout-index", cmd_checkout_index, RUN_SETUP },
+ { "checkout-index", cmd_checkout_index,
+ RUN_SETUP | NEED_WORK_TREE},
{ "check-ref-format", cmd_check_ref_format },
{ "check-attr", cmd_check_attr, RUN_SETUP | NEED_WORK_TREE },
{ "cherry", cmd_cherry, RUN_SETUP },
--
1.5.3.rc4.1.g7805
^ permalink raw reply related
* Re: rc4 - make quick-install-doc is broken
From: Johannes Schindelin @ 2007-08-04 22:25 UTC (permalink / raw)
To: René Scharfe; +Cc: Mark Levedahl, Junio C Hamano, Git Mailing List
In-Reply-To: <46B4F923.3090604@lsrfire.ath.cx>
Hi,
On Sun, 5 Aug 2007, Ren? Scharfe wrote:
> Johannes Schindelin schrieb:
>
> > On Sat, 4 Aug 2007, Ren? Scharfe wrote:
> >
> >> I can't offer a fix, but I think I've captured install-doc-quick.sh's
> >> problem in a test script (see below). It fails with e90fdc3 (and
> >> master) but succeeds with e90fdc3^.
> >
> > It succeeds here... (without the patch I sent out, of course.)
>
> I assume you tested e90fdc3 and e90fdc3^; what about 4f8f03d (current
> HEAD)?
I thought I tested on master + --new-workdir... But I did not.
And indeed, it fails.
Sorry,
Dscho
^ permalink raw reply
* Re: rc4 - make quick-install-doc is broken
From: Johannes Schindelin @ 2007-08-04 22:37 UTC (permalink / raw)
To: René Scharfe; +Cc: Mark Levedahl, Junio C Hamano, Git Mailing List
In-Reply-To: <46B4F923.3090604@lsrfire.ath.cx>
Hi,
your test script is slightly wrong...
First you "git init", with GIT_DIR in $(pwd)/.git, i.e. the default. But
then, you need not do this, test scripts are called when git init was
already called.
Then you make an untracked directory called untracked/. Tradition
dictates that when we're in that directory, we get the prefix
"untracked/", because we might add a file, or reference a file in another
branch, where that directory is _not_ untracked.
So it is expected that checkout-index and ls-files behave differently
in a subdirectory (even if that is currently untracked).
It seems a bit counterintuitive that read-tree succeeds, but really,
read-tree is only a commit -> index operation, which should not care about
the current prefix. So it is fine.
Checkout-index, instead, is an index -> working tree operation, and for
most of these, we care about the current prefix (so that you can say git
checkout-index file1, where file1 is in the current directory, which is
_not_ the working tree root).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] checkout-index needs a working tree
From: Junio C Hamano @ 2007-08-04 22:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0708042319470.14781@racer.site>
Hmmph. I was trying to come up with a better commit log message
for this change.
Paths given from the command line of checkout-index name
files relative to the cwd, whose implication is that it
is relative to where you are in relation with the top of
the working tree. For doing that, you need to have the
work tree to begin with.
Does this mean that any command that uses its prefix parameter
to cmd_xxx() needs NEED_WORK_TREE?
I wonder if it would help us to catch similar breakages if we
change git.c::run_command() so that we do not pass prefix (or
pass a bogus pointer ((const char *)1)) for commands that do not
ask for NEED_WORK_TREE.
^ permalink raw reply
* Re: Terminology question about remote branches.
From: Theodore Tso @ 2007-08-04 22:56 UTC (permalink / raw)
To: David Kastrup; +Cc: Julian Phillips, Lars Hjemli, Jeff King, git
In-Reply-To: <85hcnfdvtr.fsf@lola.goethe.zz>
On Sat, Aug 04, 2007 at 08:00:00PM +0200, David Kastrup wrote:
>
> I think I am going to cry. So I need to rebase my branches, pull out
> the resulting patch sets, scrap my repository, clone it new from
> upstream, reapply my branches, in order to have a system where the
> documentation is somewhat in synch with the actual behavior?
... or you can you use "git remote" to create the remote tracking
branches. The important thing to realize is that 99% of what "git
remote" does is purely by editing the config file. (The last 1% is
running "git fetch" if you specify the -f option.) So understanding
what gets placed in the .git/config file after doing an initial clone
from a URL for a pre-1.5 git and what gets placed in .git/config file
and how the branches are set up post 1.5 is key to understanding what
is going on.
> No, it would seem that I can just
> git-clone -l
> my repository and be set up in the new order of things. Nice.
Be careful, not really. A git-clone -l will set up a new repository
where origin/master is your original repository, i.e.:
[remote "origin"]
url = /usr/projects/e2fsprogs/base
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
In contrast, if you had done a git-clone of remote repository, you
might see something like this instead:
[remote "origin"]
url = git://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
In contrast, if you are using git 1.4, after a clone, "origin" and
"master" are by default set to the "master" branch in the source
repository, and in git 1.4 (and in git 1.5 if you don't have any of
the above configuration opions in your .git/config file), the "origin"
branch is magical and works like the remote tracking branch of
origin/master of git 1.5 for the purposes of "git fetch", and then the
implied merge done by "git pull" merges from "origin" branch to the
"master" branch.
> However, it would appear from my experiments up to now that the
> --track option _can't_ be made to work with a 1.4 repository. I think
> that is worth mentioning in the docs.
Well, there really is no such thing as a "1.4 repository". The only
real difference is the default configuration which is dropped into the
.config file when you do a "git clone", and whether the head of the
master branch created after the "git clone" is called "origin", with
some magic special casing so that works like a remote tracking branch
of the remote repo's master branch, or whether it is called
"origin/master", with explicit configuration rules in .git/config.
The real issue is that a "1.4 repository" (that is a repository
created by "git clone" from git 1.4 and where the config file hasn't
been updated either by hand-editing the config file or by use of "git
config" or "git remote" to have remote branches) doesn't have any
remote branches, and git branch -track only has significance if you
are creating a new (local) branch from a remote tracking branch.
Regards,
- Ted
^ permalink raw reply
* Re: rc4 - make quick-install-doc is broken
From: René Scharfe @ 2007-08-04 23:03 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Mark Levedahl, Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0708042328000.14781@racer.site>
Johannes Schindelin schrieb:
> Then you make an untracked directory called untracked/. Tradition
> dictates that when we're in that directory, we get the prefix
> "untracked/", because we might add a file, or reference a file in another
> branch, where that directory is _not_ untracked.
The test is modelled after the install script; Documentation/ (the CWD
during 'make quick-install-doc') is not tracked in branch origin/man.
> So it is expected that checkout-index and ls-files behave differently
> in a subdirectory (even if that is currently untracked).
>
> It seems a bit counterintuitive that read-tree succeeds, but really,
> read-tree is only a commit -> index operation, which should not care about
> the current prefix. So it is fine.
>
> Checkout-index, instead, is an index -> working tree operation, and for
> most of these, we care about the current prefix (so that you can say git
> checkout-index file1, where file1 is in the current directory, which is
> _not_ the working tree root).
OK, makes sense.
Thanks,
René
^ permalink raw reply
* Re: Some ideas for StGIT
From: Pavel Roskin @ 2007-08-05 0:08 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Andy Parkins, git, Catalin Marinas
In-Reply-To: <20070804055110.GP20052@spearce.org>
On Sat, 2007-08-04 at 01:51 -0400, Shawn O. Pearce wrote:
> I agree with Andy. Aside from the performance issues that I
> am currently having with a 55 patch series, "rebase -i" (and its
> predecessor script from Dscho) have been a major part of my toolkit,
> to the point that I really don't need something like StGIT on
> my system.
>
> (Regarding the performance, cherry-picking 55 patches is
> slow, especially when many of them would apply trivially with
> git-diff|git-apply --index. Be nice to improve that in 1.5.4.)
I understand that "git-rebase -i" is good for keeping local changes
up-to-date, but the real issue is managing the local patches so that
they can be enhanced to the point that they are ready for submission.
That includes such things as moving chunks between patches, editing
descriptions, joining patches together, sorting patches into groups by
their urgency and so on. Keeping the patches up-to-date is just one
aspect.
Anyway, I'm going to give "git-rebase -i" a try.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: Some ideas for StGIT
From: Pavel Roskin @ 2007-08-05 0:12 UTC (permalink / raw)
To: Josef Sipek; +Cc: Theodore Tso, Catalin Marinas, git
In-Reply-To: <20070804213549.GA1967@filer.fsl.cs.sunysb.edu>
On Sat, 2007-08-04 at 17:35 -0400, Josef Sipek wrote:
> FYI: v0.27 allows you to edit the patch headers with: guilt header -e
> Pavel, if you have any questions, you know where to ask :)
Thanks everybody. guilt and "git-rebase -i" are on my list of things to
try.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: Some ideas for StGIT
From: Jakub Narebski @ 2007-08-05 0:17 UTC (permalink / raw)
To: git
In-Reply-To: <20070804055110.GP20052@spearce.org>
Shawn O. Pearce wrote:
> (Regarding the performance, cherry-picking 55 patches is
> slow, especially when many of them would apply trivially with
> git-diff|git-apply --index. Be nice to improve that in 1.5.4.)
Perhaps in the future you would be able to use -i/--interactive mode
in merge driven git-rebase (git rebase --merge -i <base>), which I think
should be faster.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] checkout-index needs a working tree
From: Johannes Schindelin @ 2007-08-05 1:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvebuj4nw.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sat, 4 Aug 2007, Junio C Hamano wrote:
> I wonder if it would help us to catch similar breakages if we change
> git.c::run_command() so that we do not pass prefix (or pass a bogus
> pointer ((const char *)1)) for commands that do not ask for
> NEED_WORK_TREE.
I tried that, but we have some places where we ask "if (prefix &&
*prefix)", for example in ls-tree. It does not _require_ a work tree, but
it certainly uses it when it is available -- which is fine.
Other users are more tricky, such as ls-files and update-index, which need
a working tree only in some cases.
I'll probably write a patch on Monday (if nobody else is faster) to
provide a function "require_work_tree()" in environment.c, which does the
obvious (with caching). Then comes the tedious part: identifying all
those options that need a working tree...
Ciao,
Dscho
^ permalink raw reply
* Re: Some ideas for StGIT
From: Shawn O. Pearce @ 2007-08-05 2:31 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <f934ve$3oi$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> wrote:
> Shawn O. Pearce wrote:
>
> > (Regarding the performance, cherry-picking 55 patches is
> > slow, especially when many of them would apply trivially with
> > git-diff|git-apply --index. Be nice to improve that in 1.5.4.)
>
> Perhaps in the future you would be able to use -i/--interactive mode
> in merge driven git-rebase (git rebase --merge -i <base>), which I think
> should be faster.
Heh. You're talking to someone who actually knows what he is talking
about here, and was actually involved in some of these tools...
Let me fill the reader in on what's really happening...
`git-rebase` (non -i, non -m) uses `format-patch|am` to apply the
changes of each commit it is rebasing. This is insanely fast as
builtin diff and apply routines are quite efficient. It sometimes
fails due to patches not applying cleanly. In those cases you
have to either hand edit the patch, apply and continue the rebase,
or abort the rebase and restart with the -m flag so it uses a full
three-way file merge.
`git-rebase -m` (aka --merge) uses git-merge-recursive to apply the
changes of each commit it is rebasing. (That's the merge part!)
However merge-recursive usually takes longer to run then the above
`format-patch|am` pipeline, and that is why -m is not the default.
But it does handle cases `format-patch|am` cannot do automatically.
For quite a long time now both `git-revert` and `git-cherry-pick`
(which are actually the same program!) have also been using
git-merge-recursive as their implementation to revert or apply the
commit's change. This allows them to perform changes that also
involve renames, as well as to apply some changes that might fail
as a patch but succeed when done as a three-way file merge.
So really `revert`, `cherry-pick`, `rebase -m` (and also `am -3`
as it also uses merge-recursive) are all the same underlying
implementation. The major differences between them is what they
do *after* the changes have been applied, and which direction the
change goes (e.g. revert undoes the change).
Now the new `git-rebase -i` is really just a complicated loop around
`cherry-pick`. Really. Go look at the code, it never calls anything
except cherry-pick. So `rebase -i` is actually `rebase --merge -i`.
That's why its sluggish.
Why is merge-recursive sluggish? It does rename detection.
It does full three-way file merges, rather than just applying
a patch. It also tries to do a three-way read-tree before doing
file level merges. git-apply does none of these things, and is
faster because of it.
So that future you speak of above is today. Its also not faster,
its slower. Faster would be to do something like `format-patch|am -3`
so that merge-recursive is only invoked if git-apply was unable to
apply the patch automatically. Except we'd want to save the original
tree data so we can do proper rename detection when merge-recursive
is fired up.
--
Shawn.
^ 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