* Re: possible bug in git apply?
From: Junio C Hamano @ 2007-08-05 5:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: david, git, rob
In-Reply-To: <alpine.LFD.0.999.0708042141510.5037@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> It should. I thought we did that, but maybe there's some bug there.
>
> See "remove_file()" in builtin-apply.c.
>
> But yeah, it seems that the file *rename* ends up not triggering that
> logic! Very annoying.
>
> Does this fix it? Totally untested, but it _looks_ obvious enough..
That would regress the fix made in aea19457, I am afraid. If
you are in a subdirectory and the rename patch moves away the
last file in your current directory, the shell session you ran
the git-apply from will end up in an unlinked directory.
Maybe that is a pilot error, and we can revert aea19457
altogether?
^ permalink raw reply
* [PATCH] Add 'test-absolute-path' to .gitignore
From: Johannes Schindelin @ 2007-08-05 5:14 UTC (permalink / raw)
To: gitster, git
Noticed by Randal Schwartz.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
.gitignore | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/.gitignore b/.gitignore
index 20ee642..63c918c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -148,6 +148,7 @@ git-write-tree
git-core-*/?*
gitk-wish
gitweb/gitweb.cgi
+test-absolute-path
test-chmtime
test-date
test-delta
--
1.5.3.rc4.1.g7805
^ permalink raw reply related
* Re: way to automatically add untracked files?
From: Junio C Hamano @ 2007-08-05 5:14 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Miles Bader, git
In-Reply-To: <alpine.LFD.0.999.0708042157150.5037@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> ... (except, as we found out last week, we've had a huge
> performance regression, so that's actually a really slow way to do it, and
> so it's actually faster to do
>
> git ls-files -o | git update-index --add --stdin
> git commit -a
>
> instead...
Is it still the case after the fix in rc4? Other than the
theoretical "on multi-core, ls-files and update-index can run in
parallel" performance boost potential, I thought the fixed
"git-add ." would be the same...
^ permalink raw reply
* Re: way to automatically add untracked files?
From: Miles Bader @ 2007-08-05 5:17 UTC (permalink / raw)
To: git
In-Reply-To: <7vzm16h8qw.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> I highly suspect that we will be hated by most of our users if we
> changed "git add -u" to add everything in sight for this reason, and I
> also suspect they will feel that "git add-remove --all" will be code
> bloat for little gain.
I agree that a change to "git-add -u" would be silly... :-)
I was just looking for a convenient way to reduce my typing on those
occasions when I do have a bunch of added/removed/renamed files;
"git-add -u; git add ." seems to do the trick (of course I always
check what git-status says first!).
Thanks,
-Miles
--
The automobile has not merely taken over the street, it has dissolved the
living tissue of the city. Its appetite for space is absolutely insatiable;
moving and parked, it devours urban land, leaving the buildings as mere islands
of habitable space in a sea of dangerous and ugly traffic.
[James Marston Fitch, New York Times, 1 May 1960]
^ permalink raw reply
* [PATCH] Fixed git-push manpage
From: Jyotirmoy Bhattacharya @ 2007-08-05 5:22 UTC (permalink / raw)
To: git; +Cc: Jyotirmoy Bhattacharya
In git-push it is the remote repository and not the
local repository which is fast forwarded. The description
of the -f option in the git-push manpage gets it the other
way round.
Signed-off-by: Jyotirmoy Bhattacharya <jyotirmoy@jyotirmoy.net>
---
Documentation/git-push.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 74a0da1..0dd9caf 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -79,7 +79,7 @@ the remote repository.
-f, \--force::
Usually, the command refuses to update a remote ref that is
- not a descendant of the local ref used to overwrite it.
+ not an ancestor of the local ref used to overwrite it.
This flag disables the check. This can cause the
remote repository to lose commits; use it with care.
--
1.5.2.4
^ permalink raw reply related
* Re: way to automatically add untracked files?
From: Johannes Schindelin @ 2007-08-05 5:23 UTC (permalink / raw)
To: Miles Bader; +Cc: git
In-Reply-To: <87y7gqk1ac.fsf@catnip.gol.com>
Hi,
On Sun, 5 Aug 2007, Miles Bader wrote:
> I was just looking for a convenient way to reduce my typing on those
> occasions when I do have a bunch of added/removed/renamed files;
Why didn't you say so? You can always create an alias. Problem solved.
Ciao,
Dscho
^ permalink raw reply
* Re: way to automatically add untracked files?
From: Miles Bader @ 2007-08-05 5:27 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0708050623040.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> I was just looking for a convenient way to reduce my typing on those
>> occasions when I do have a bunch of added/removed/renamed files;
>
> Why didn't you say so?
I did, I thought... :-)
-Miles
--
Somebody has to do something, and it's just incredibly pathetic that it
has to be us. -- Jerry Garcia
^ permalink raw reply
* Re: [PATCH] Fixed git-push manpage
From: Junio C Hamano @ 2007-08-05 5:35 UTC (permalink / raw)
To: Jyotirmoy Bhattacharya; +Cc: git
In-Reply-To: <11862913353314-git-send-email-jyotirmoy@jyotirmoy.net>
That indeed is an embarrasing thinko. Thanks!
^ permalink raw reply
* Re: [PATCH] unpack-trees.c: assume submodules are clean during check-out
From: Junio C Hamano @ 2007-08-05 6:02 UTC (permalink / raw)
To: Lars Hjemli; +Cc: skimo, Sven Verdoolaege, git, Eran Tromer
In-Reply-To: <8c5c35580708040441ue1c3ef8qc022912a5af4883e@mail.gmail.com>
"Lars Hjemli" <hjemli@gmail.com> writes:
> On 8/4/07, Junio C Hamano <gitster@pobox.com> wrote:
>> As we explicitly allow
>> submodule checkout to drift from the supermodule index entry,
>> the check should say "Ok, for submodules, not matching is the
>> norm" for now. Later when we have the ability to mark "I care
>> about this submodule to be always in sync with the superproject"
>> (thereby implementing automatic recursive checkout and perhaps
>> diff, among other things), we should check if the submodule in
>> question is marked as such and perform the current test.
>
> Yes, this sounds like a sane plan (and a good explanation of the
> current semantics: maybe something to include in the release notes for
> 1.5.3?)
The submodule Porcelain is a new thing in 1.5.3, so we would
need a good description of what the current rules are and what
our vision for future enhancement will be.
I am not certain however the above is the accurate description
of the current design and the direction we would want to go,
though. Somebody needs to sanity check me.
^ permalink raw reply
* Re: [PATCH] unpack-trees.c: assume submodules are clean during check-out
From: Junio C Hamano @ 2007-08-05 6:12 UTC (permalink / raw)
To: Eran Tromer; +Cc: skimo, Sven Verdoolaege, git
In-Reply-To: <46B4A350.9060806@tromer.org>
Eran Tromer <git2eran@tromer.org> writes:
> Another approach is for pull, checkout etc. to automatically update the
> submodule' head ref, but no more. In this case the supermodule always
> sees a consistent state with traditional semantics, but the *submodule*
> ends up with a dirty working tree and a head referring to a
> possibly-missing commit; "git submodule update" would need to clean that up.
That however would introduce the same problem as "pushing into
live repository to update its HEAD while the index and working
tree are looking the other way". We would need to somehow make
it possible for the subdirectory to remember which commit the
index and the working tree are derived from, so that the local
changes can be merged back to the revision the submodule HEAD
points at.
^ permalink raw reply
* Re: Terminology question about remote branches.
From: David Kastrup @ 2007-08-05 7:06 UTC (permalink / raw)
To: Theodore Tso; +Cc: Julian Phillips, Lars Hjemli, Jeff King, git
In-Reply-To: <20070804225655.GD11150@thunk.org>
Theodore Tso <tytso@mit.edu> writes:
> On Sat, Aug 04, 2007 at 08:00:00PM +0200, David Kastrup wrote:
>
>> 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:
Yes, I noticed. I can do a
git-clone -l --reference /my/local/rep git://the/remote/repo
instead. That's still very fast, but I miss out on my local changes...
> [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
>
>> 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.
>
> 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.
An error message might be nice, though. I find git hard to understand
at times.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* [PATCH] Fix install-doc-quick target
From: Junio C Hamano @ 2007-08-05 7:07 UTC (permalink / raw)
To: René Scharfe; +Cc: Johannes Schindelin, Mark Levedahl, Git Mailing List
In-Reply-To: <46B4F91D.1070907@lsrfire.ath.cx>
The script starts in a subdirectory of the source directory to
muck with a branch whose structure does not have anything to
do with the actual work tree. Go up to the top to make it clear
that we operate on the whole tree.
It also exported GIT_DIR without any good reason. Remove it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* I am getting the impression that the semantics of the updated
work-tree support is as broken as the original, although the
code that implements it is easier to read.
Admittedly, this is an unorthodox corner case usage, that
deals with a tree structure that does not have any relation
with the current project state, and the script is started
with a subdirectory of the current project. What is needed
is a way to tell git that "we may be in a subdirectory but
the tree structure we are dealing with does not have anything
to do with the current work tree structure -- ignore the fact
that we are not at the toplevel", and exporting of GIT_DIR
was the way to do so in the old world order.
Another way to do this in the new world order would be to
pass "--work-tree=.", but this has its own problems it
seems. You can try commenting out cd_to_toplevel this patch
introduces, then rewrite checkout-index part with:
git --git-dir="$GIT_DIR" --work-tree=. checkout-index -a...
which seems to work, but if you drop --git-dir="$GIT_DIR"
from the above (without reintroducing the export of GIT_DIR),
you get "fatal: Could not switch to '.git'" which seems quite
bogus. If you say:
git --work-tree=. foo
without saying anything about GIT_DIR, shouldn't we run the
usual .git/ discovery, going up the directories?
Documentation/install-doc-quick.sh | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/Documentation/install-doc-quick.sh b/Documentation/install-doc-quick.sh
index e6601bd..07d227f 100755
--- a/Documentation/install-doc-quick.sh
+++ b/Documentation/install-doc-quick.sh
@@ -7,7 +7,7 @@ mandir="$2"
SUBDIRECTORY_OK=t
USAGE='<refname> <target directory>'
. git-sh-setup
-export GIT_DIR
+cd_to_toplevel
test -z "$mandir" && usage
if ! git rev-parse --verify "$head^0" >/dev/null; then
@@ -18,6 +18,8 @@ fi
GIT_INDEX_FILE=`pwd`/.quick-doc.index
export GIT_INDEX_FILE
rm -f "$GIT_INDEX_FILE"
+trap 'rm -f "$GIT_INDEX_FILE"' 0
+
git read-tree $head
git checkout-index -a -f --prefix="$mandir"/
--
1.5.3.rc4.8.ga120
^ permalink raw reply related
* Re: Terminology question about remote branches.
From: Junio C Hamano @ 2007-08-05 7:31 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <854pjfin68.fsf@lola.goethe.zz>
David Kastrup <dak@gnu.org> writes:
> I am trying to dig through man-pages and user manual and trying to
> match them with reality. I seem to have a hard time. My current
> understanding (which definitely differs from the documented state) is
> that there are two types of branches, local and remote branches, and
> both types of branches can be remote-tracking (it may not be possible
> to have a non-remote-tracking remote branch, though).
I think we have a brief discussion on #git before you brought
this up ;-)
- local branches -- we know what they are.
- remote tracking branches -- refs that appear in refs/remotes/
in the current world order; they are updated only by copying
the corresponding local branches at the remote site, and are
meant to "keep track of what _they_ are doing". In olden
days before 1.5.0 with non separate remote layout,
'refs/heads/origin' branch, and all the non default branches,
were treated this way as well. You were not supposed to make
commit on them (because of the above "keep track of" reason),
and having them under refs/heads were too confusing, which
was the reason the separate remote layout was invented.
You can have a local branch that is created by forking off of a
remote tracking branch, with the intention to "build on top" of
the corresponding remote tracking brach. You can create such a
branch and mark it as such with --track option introduced in
v1.5.1 timeperiod. This is a relatively new concept, but many
people find it useful. We do not have the official term to call
this concept, and some people have misused the term "remote
tracking branches" to describe this, which made things very
confusing.
We would need an official terminology for it.
^ permalink raw reply
* Re: way to automatically add untracked files?
From: David Kastrup @ 2007-08-05 7:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Miles Bader, git
In-Reply-To: <7vr6mih8a8.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
>> ... (except, as we found out last week, we've had a huge
>> performance regression, so that's actually a really slow way to do it, and
>> so it's actually faster to do
>>
>> git ls-files -o | git update-index --add --stdin
>> git commit -a
>>
>> instead...
>
> Is it still the case after the fix in rc4? Other than the
> theoretical "on multi-core, ls-files and update-index can run in
> parallel" performance boost potential,
When I did my apprenticeship, one thing I learnt was that to
accomplish a repetitive task comprised of several steps, you organize
it in a way that does not require you to change the tool you are
holding/using until you have finished using it.
What's good for the user is good for the computer: even on single core
systems, working off a complete pipeline buffer before switching
context again will help keeping disk positioning and cache poisoning
down. However, it will depend on the scheduler: if it never allows
pipes to even slighly fill up (which has been the normal behavior of
the Linux scheduler for years in spite of complaints I voiced several
times), you don't get the advantages from this sort of processing.
CFS could conceivably help in many use cases since then the context
switch depends on more than just "pipe has some minimal content?"
which is pretty much the worst choice for context switches in batch
processing. However, as long as we are talking buffered I/O (FILE*
and block buffering), we are losing some parallelism potential and
gaining some blocking advantage.
> I thought the fixed "git-add ." would be the same...
Possibly. After all, there _is_ overhead associated with pipes, and
currently released kernels' scheduling behavior reaps no cache
poisoning gains. Whatever. I think I'll do a large test.
Speculation is not everything.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: way to automatically add untracked files?
From: Miles Bader @ 2007-08-05 7:34 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LFD.0.999.0708042157150.5037@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> But git certainly has the capability. "git commit -a" will notice all the
> files that went away and automatically remove them, so
>
> git add .
> git commit -a
>
> will do what you want (except, as we found out last week, we've had a huge
> performance regression, so that's actually a really slow way to do it, and
> so it's actually faster to do
>
> git ls-files -o | git update-index --add --stdin
> git commit -a
I notice that "git ls-files -o" doesn't do normal ignore-processing, so
for instance all my .o and editor backup files show up in the output...
Is that expected or is it a bug (I tried versions "1.5.2.4" and
"1.5.3.rc3.91.g5c75-dirty")?
If I do:
git-ls-files -o --exclude-per-directory=.gitignore --exclude-from=$HOME/.gitignore
it works more like I'd expect.
Thanks,
-Miles
--
`The suburb is an obsolete and contradictory form of human settlement'
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: David Kastrup @ 2007-08-05 7:51 UTC (permalink / raw)
To: Linus Torvalds
Cc: Steven Grimm, Sam Ravnborg, Junio C Hamano, Ismail D?nmez, git
In-Reply-To: <alpine.LFD.0.999.0708042127160.5037@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Sat, 4 Aug 2007, David Kastrup wrote:
>> >
>> > None that any normal user would want to use.
>>
>> Linus, do you really think that the editor _you_ use is used by more
>> people than Emacs? Think again.
>
> No.
>
> But I'm also not confused enough to think that people should use
> micro-emacs for reading man-pages.
Could you refrain from using name-calling on everybody that does not
share your preferences? It is annoying to hear you talk all the time
about "normal", "sane", "confused" and so on.
> The UNIX philosophy is "do one thing, and do it well".
And Emacs does text, and does it well. It is just that very much
information can ultimately be viewed as text. For example, I can run
grep or locate inside of Emacs. Nothing exciting. And then I can
click on the lines those put out, and get moved to the corresponding
line in the source code, in my editor. Again, nothing exciting, but
it does not work with disconnected tools without the glue Emacs
provides. There are other IDEs providing that sort of thing, but
usually they work just with output they produced themselves.
Using Emacs to read man-pages means that I can grab manpage content
easily with my accustomed editing commands and paste them into a mail
I am composing. Without having to use a mouse or GUI.
It enables workflows that are not possible outside of it. It is ok if
you don't find the tradeoff appealing, but that does not make you
"normal" and other people "confused" and "insane".
So please get a grip and focus on what we were actually talking
about. Not Emacs, but rather documentation formats.
> Man-pages with man.
Actually, Emacs "woman" does a pretty good job with those, offers
convenient man page name completion and works on Windows and similar
platforms without needing
> html with a web browser. And edit stuff with an editor.
>
> Why the *hell* do you confuse my choice of editor with my choice of
> man-page format? I didn't.
Why the hell do you keep changing the topic and go off on sideline
rants.
> That whole "do everything in emacs" is a disease. And then emacs
> users think that it's "sane".
Focus. How do you propose to manage documention of a hundred pages an
more conveniently, finding information easily by text, index,
hyperlinks? A single large HTML page? A documentation directory full
of *.txt files which you can grep through (not that Emacs would not be
useful for that, too)?
How do you find all information pertaining to "remote tracking
branches" in the git documentation? Explain your workflow with that,
and explain why a sane person would prefer that over typing
info git
i remote TAB RET , , ,
and being taken to the respective text locations in turn.
Standalone info _is_ a single application doing a single job:
navigating large hyperlinked plain text documentation efficiently. It
may be an _ugly_ application, but instead of saying what you use
instead in your daily workflow, you revert to name-calling.
If you have a _working_ solution to offer for that task, try
presenting it instead of calling people using other tools names.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: possible bug in git apply?
From: David Kastrup @ 2007-08-05 7:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, david, git, rob
In-Reply-To: <7vvebuh8g8.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
>> It should. I thought we did that, but maybe there's some bug there.
>>
>> See "remove_file()" in builtin-apply.c.
>>
>> But yeah, it seems that the file *rename* ends up not triggering that
>> logic! Very annoying.
>>
>> Does this fix it? Totally untested, but it _looks_ obvious enough..
>
> That would regress the fix made in aea19457, I am afraid. If
> you are in a subdirectory and the rename patch moves away the
> last file in your current directory, the shell session you ran
> the git-apply from will end up in an unlinked directory.
>
> Maybe that is a pilot error, and we can revert aea19457
> altogether?
I'd call it pilot error. We can't really have git's behavior depend
on where somebody might point his cwd. If we do that, we may never
remove any directory. Once git tracks directories, it will be harder
to make this particular pilot error (git rm ../mycwd is more obviously
having this effect than git rm *), but a pilot error it is in my book.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: cvs2svn conversion directly to git ready for experimentation
From: Oswald Buddenhagen @ 2007-08-05 7:58 UTC (permalink / raw)
To: Jon Smirl; +Cc: Michael Haggerty, Steffen Prohaska, git, users
In-Reply-To: <9e4733910708021659y6e9bb7ddk58817b4de3df26a0@mail.gmail.com>
On Thu, Aug 02, 2007 at 07:59:41PM -0400, Jon Smirl wrote:
> I seem to recall discussing an algorithm to fix this on the cvs2svn
> mailing list. There was a somewhat simple way to correlate the
> "unlabeled-1.2.4" in one file might be the same as "unlabeled-1.2.6"
> problem.
>
yes, name them after the first symbol that appears on them. like
unlabeled-1.2.4 being named __KDE_3_5_RELEASE because of such tag
(without the underscores, obviously) appearing on it.
the naive per-file implementation doesn't get you that far, though.
again, one'd have to collect data from all files first, correlate
it and make a "majority vote". very similar to your favorite symbol
source problem. ;)
--
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.
^ permalink raw reply
* Re: [PATCH] git-clone: use cpio's --quiet flag
From: Jeff King @ 2007-08-05 8:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vps23gnpj.fsf@assigned-by-dhcp.cox.net>
On Sat, Aug 04, 2007 at 11:27:04AM -0700, Junio C Hamano wrote:
> Try cloning across filesystem boundaries so that you do not get
> a hardlink -- you will get block count of the copy ;-)
I see, though the hardlink warning is a bit much.
$ git-clone /path/on/fs/one /path/on/fs/two
Initialized empty Git repository in /path/on/fs/two/.git/
Warning: -l asked but cannot hardlink to /path/on/fs/one/.git
36634 blocks
-Peff
^ permalink raw reply
* Re: [PATCH] git-clone: use cpio's --quiet flag
From: Junio C Hamano @ 2007-08-05 8:36 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, git
In-Reply-To: <20070805080651.GB10863@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sat, Aug 04, 2007 at 11:27:04AM -0700, Junio C Hamano wrote:
>
>> Try cloning across filesystem boundaries so that you do not get
>> a hardlink -- you will get block count of the copy ;-)
>
> I see, though the hardlink warning is a bit much.
>
> $ git-clone /path/on/fs/one /path/on/fs/two
> Initialized empty Git repository in /path/on/fs/two/.git/
> Warning: -l asked but cannot hardlink to /path/on/fs/one/.git
> 36634 blocks
True; -l is not given explicitly in your example. Should be
trivial to fix.
^ permalink raw reply
* Bug in update-index?
From: David Kastrup @ 2007-08-05 8:42 UTC (permalink / raw)
To: git
Hi, the following bombs out:
time git --work-tree=/usr/local/texlive/2007/texmf-dist ls-files -z -m -o .|git --work-tree=/usr/local/texlive/2007/texmf-dist update-index --add -z --stdin
error: bibtex/bib/IEEEtran/IEEEabrv.bib: does not exist and --remove not passed
fatal: Unable to process path bibtex/bib/IEEEtran/IEEEabrv.bib
It would appear that update-index is not finding the listed file in
spite of the --work-tree argument.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Terminology question about remote branches.
From: Jeff King @ 2007-08-05 9:21 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <85tzrfh3yg.fsf@lola.goethe.zz>
On Sat, Aug 04, 2007 at 02:36:07PM +0200, David Kastrup wrote:
> And it's actually worse after your explanations. Previously I
> imagined to have a chance to figure this out on my own, by trying to
> abstract from what I see happening when using the various commands.
>
> Now I think that I basically have no chance figuring this out on my
> own sufficiently well to be able to improve the documentation.
I see that Lars and others have provided some explanations in my
absence, but let me try to lay it out from basics, and hopefully between
all of our writing it will make sense. I'm going to try to be as basic
as possible, so if I am telling you something you already know, it's not
because I think you're stupid, but because I'm trying to be thorough.
Git history is a directed graph of commit objects, with each commit
object pointing to its parent (or parents if it is a merge). We have
human-readable names pointing into the history as well, which we call
refs, and generally store under the "refs/" hierarchy (with a few
exceptions, which I will mention in a minute).
There are a few different types of pointers (refs) that are useful to
us. They are differentiated by the types of things we want to do with
them.
1. refs that track our ongoing commits. This process involves making
a new commit object whose parent is the previous value of the ref,
and then pointing the ref at the new commit. We generally call
these refs "heads", "local branches", or just "branches", and they
are stored in "refs/heads/".
2. refs that point to a single commit and aren't changed. These refs
are "tags", and we store them in "refs/tags/".
3. refs that represent a remote repository's local branch. These are
updated by git-fetch, which simply writes the new value of the
pointer into our local copy, throwing out the old value. These are
called "remote tracking branches" and are stored in
"refs/remotes/<remote>/<branch>".
4. Temporary pointers to help out some multi-step operation that we're
in the middle of. These include FETCH_HEAD and MERGE_HEAD.
There is an order of ref lookup which goes like:
.git/<name>
.git/refs/<name>
.git/refs/tags/<name>
.git/refs/heads/<name>
.git/refs/remotes/<name>
It used to be the case (prior to git 1.5) that remote tracking branches
and local branches were stored in the same hierarchy (under
refs/heads/). This turned out to be problematic for many users, because
the operations that you perform on them don't play well together.
For example, let's say you have a branch "origin" representing Junio's
"master" branch. You check it out and make a commit. This rewrites the
"origin" ref, but it's safe because the new commit points to the old
value. Now you want to fetch more work from Junio, so you run
"git-fetch". But the value of Junio's ref doesn't ever reference your
work. If git-fetch copies the value of Junio's new ref into your
"origin", then it will throw away the work that you were done (i.e., no
ref will be pointing to it, or to any commit that references it). But if
git-fetch doesn't copy the value of Junio's new ref, then how will you
get to see his new work?
So it is a mistake to create commits on top of a remote tracking branch.
The new strategy is therefore to store them in refs/remotes, which is an
indicator that they are purely for remote tracking. If you attempt to
git-checkout a branch in refs/remotes, you will get a detached HEAD
rather than actually checking out that branch.
Normally "HEAD" is a pointer to a ref in refs/heads/ (which is itself a
pointer to a commit object) representing "the current branch." When HEAD
becomes detached, we mean that instead of pointing to a branch ref, it
points directly to a commit object. So when you do "git-checkout
origin/master" (which, unless you have a local branch named
"origin/master" will end up looking in refs/remotes/origin/master), it
doesn't put "refs/remotes/origin/master" in your HEAD, but rather the
_value_ of that ref.
The implication here is that commits you create on a detached HEAD are
not stored by any ref except HEAD, and will be lost when you move
the HEAD elsewhere (i.e., when you check out a different branch).
Tags are in a similar situation. You don't want to make commits on tags;
instead, you want to simply set them to a pre-existing commit. Thus when
you check out a tag, you get a detached HEAD (and we know it's a tag
because it's in refs/tags, not refs/heads).
So hopefully at this point you understand "local branch" and "remote
tracking branch."
To get to the final concept you mentioned, let's take a look at what
fetch and pull do.
Let's say you run:
git-fetch git://git.kernel.org/pub/scm/git/git.git
That stores the value of Junio's current branch (which tends to be
"master") into your local FETCH_HEAD (stored in ".git/FETCH_HEAD").
And if you run:
git-fetch git://git.kernel.org/pub/scm/git/git.git next
Then we store the value of Junio's next branch into your FETCH_HEAD.
And finally, if you run:
git-fetch \
git://git.kernel.org/pub/scm/git/git.git \
next:refs/remotes/junio/next
then we store Junio's next branch in our FETCH_HEAD, but _also_ store it
in the remote tracking branch refs/remotes/junio/next.
The second argument to fetch is called a "refspec", and you can have
several of them. Because all of that gets tedious to type, we have the
concept of configured remotes, which are a shorthand for a URL and
associated refspecs. When you use "git-clone", it creates the following
config:
[remote "origin"]
url = git://git.kernel.org/pub/scm/git/git.git
fetch = +refs/heads/*:refs/remotes/origin/*
The refspec in this case uses a wildcard to get _all_ of Junio's
branches, and store them by name under refs/remotes/origin. So we can
just say "git-fetch origin" and it will populate our FETCH_HEAD as well
as the refs/remotes/origin directory.
If we call "git-fetch" without any arguments, it will look up the
default remote in our configuration. git-clone also creates the
following config:
[branch "master"]
remote = origin
merge = refs/heads/master
which means "if we are on the master branch, default fetches to the
remote 'origin'". I will explain the merge line in a minute.
So now we look at git-pull. Recall that a pull is basically a fetch
followed by a merge. If you run:
git-pull git://git.kernel.org/pub/scm/git/git.git
it will do a git-fetch of that URL (grabbing the current branch),
followed by a git-merge of FETCH_HEAD.
If you run:
git-pull origin master
it will fetch the "origin" remote, putting all branches into the
FETCH_HEAD (and storing them in refs/remotes/origin as a side effect).
Then it will pick the branch named 'master' out of FETCH_HEAD, and
merge it.
If you run:
git-pull origin
it will fetch origin as usual, but which branch gets merged? The answer
is the value of the "merge" field in the 'branch "master"' section of
your config (which is generally created by git-clone).
And of course, if you run:
git-pull
it will look up the remote to fetch in the config (just as "git-fetch"
would), and then find the branch to merge in the config.
So how do we this configuration set up? There are three ways:
1. Edit your .git/config by hand. :)
2. git-clone sets up a master/origin relationship, adding both the
"remote" and "branch" sections.
3a. Using git-remote, you can add new "remote" sections easily.
3b. Using the --track option to git-branch, you can set up the
"branch" section automatically.
What you had called a "remote-tracking branch" is really a branch for
which the 'branch "<name>"' config section has been set up (which could
come about in several ways). I haven't really seen a term such as
"remote-tracking branch" for this in use in the documentation (and I
think we both agree that is not the right term because of its confusing
similarity to remote tracking branches, discussed above).
I know that was a pretty long email, but hopefully you understand the
context of the terms a bit more, and I didn't bore you too much. ;)
Feel free to ask questions if there are parts that are unclear.
-Peff
^ permalink raw reply
* Re: Terminology question about remote branches.
From: Jeff King @ 2007-08-05 9:24 UTC (permalink / raw)
To: David Kastrup; +Cc: Lars Hjemli, git
In-Reply-To: <85odhnfiau.fsf@lola.goethe.zz>
On Sat, Aug 04, 2007 at 05:09:13PM +0200, David Kastrup wrote:
> Ok, so a remote tracking branch is a forcefully merged branch, so we
> put it into a separate category where we won't get tempted to have a
> branch head which will get overwritten.
I would hesitate to use the word "merge" here at all. You really are
just throwing away the old value, and overwriting it with the new value.
See my other email for more details.
> This whole "remote tracking" appears to be more a matter of _policy_
> rather than inherent design. It would appear that local and remote
> tracking branches have no fundamental differences, they just get
> different defaults which make it less likely for the first to lose
> local changes, and less likely for the second to miss remote changes
> (in particular where those involve messing up the history).
Yes, I think that's fair to say.
> But it would be easy to create chimeras when working outside of the
> porcelain, right?
Sure, but then you are responsible for the mess it creates. :)
-Peff
^ permalink raw reply
* Re: Terminology question about remote branches.
From: David Kastrup @ 2007-08-05 9:29 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20070805092115.GA12507@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
[...]
> I know that was a pretty long email, but hopefully you understand
> the context of the terms a bit more, and I didn't bore you too
> much. ;) Feel free to ask questions if there are parts that are
> unclear.
The main question is why I can't find this explained in this manner in
the documentation. Are you going to put it in yourself, or should I
attempt doing it?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [RFC (take 3)] Git User's Survey 2007
From: Asger Ottar Alstrup @ 2007-08-05 9:30 UTC (permalink / raw)
To: git
In-Reply-To: <200708040250.55180.jnareb@gmail.com>
Jakub Narebski wrote:
> Open forum
>
> 1. What other comments or suggestions do you have that are not
> covered by the questions above?
I believe there is a need for hosting services of Git repositories for
commercial use.
With the Windows Git installer coming along, I know that I'd like to
switch our company from a SVN hosted at cvsdude.com or svnrepository.com
to a Git hosting service.
Maybe you could include a question about this?
Regards,
Asger Ottar Alstrup
^ 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