* Re: Unresolved issues #2
From: Petr Baudis @ 2006-05-04 9:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, mj
In-Reply-To: <7v4q065hq0.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Thu, May 04, 2006 at 10:15:03AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> * Message-ID: <1143856098.3555.48.camel@dv>
> Per branch property, esp. where to merge from (Pavel Roskin)
>
> This involves user-level "world model" design, which is more
> Porcelainish than Plumbing, and as people know I do not do
> Porcelain well; interested parties need to come up with what
> they want and how they want to use it.
Oh, my holey memory. In Cogito, I have just implemented a solution
suggested by Martin Mares, which is pretty simple, non-obtrusive
and will work equally fine with remotes as well as remote branches:
if [ $branch != master ] && [ -s .git/branches/$branch-origin ]
origin=.git/branches/$branch-origin
else
origin=.git/branches/origin
fi
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Re: Unresolved issues #2
From: Jakub Narebski @ 2006-05-04 9:26 UTC (permalink / raw)
To: git
In-Reply-To: <7vwtd240e0.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>>> I am beginning to think using "graft" to cauterize history
>>> for this, while it technically would work, would not be so
>>> helpful to users, so the design needs to be worked out again.
>>
>> Perhaps use comment for marking graft as cauterizing history?
>
> ?
For example:
# begin shallow clone
<sha1 of commit 1> # no parents... - cut-off commit
<sha1 of commit 2>
...
<sha1 of commmit n>
# end shallow clone
I don't think it is very good idea, though...
>> There was also talk about proposed git-splithist, which would move some
>> of the history to other (historical, archive) repository.
>
> I stayed out from that discussion, but my impression was that
> you could essentially do the same thing as what Linus did when
> he started the recent kernel history since v2.6.12-rc2 without
> any tool support.
>
> The older kernel history from BKCVS was resurrected later by
> independent parties and Linus's history can be grafted onto it,
> but if you have an existing history stored in git, you could do:
> (1) take a snapshot of the tip of your development with "git
> tar-tree HEAD"; (2) extract it into an empty repository and
> start a new history; (3) build on top of the truncated history;
> and (4) graft that onto the history that stopped at (1), which
> you tentatively abandoned, as needed.
I have thought about splitting not at current tip(s), but for example at 1
year ago. Current repository would have history cautherized using grafts
(although it would be nice to have option to omit grafts and reach to
historic repository), and archive/history repository ending with commits up
to (but not including) the cut-off (cauterization) points.
IIRC the problem with 'shallow clone' was telling which commits the clone
has, and how to join commits and recauterize history.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: Unresolved issues #2
From: Junio C Hamano @ 2006-05-04 9:14 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e3ce4j$chl$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
>> I am beginning to think using "graft" to cauterize history
>> for this, while it technically would work, would not be so
>> helpful to users, so the design needs to be worked out again.
>
> Perhaps use comment for marking graft as cauterizing history?
?
> There was also talk about proposed git-splithist, which would move some of
> the history to other (historical, archive) repository.
I stayed out from that discussion, but my impression was that
you could essentially do the same thing as what Linus did when
he started the recent kernel history since v2.6.12-rc2 without
any tool support.
The older kernel history from BKCVS was resurrected later by
independent parties and Linus's history can be grafted onto it,
but if you have an existing history stored in git, you could do:
(1) take a snapshot of the tip of your development with "git
tar-tree HEAD"; (2) extract it into an empty repository and
start a new history; (3) build on top of the truncated history;
and (4) graft that onto the history that stopped at (1), which
you tentatively abandoned, as needed.
^ permalink raw reply
* Re: What's in git.git
From: Petr Baudis @ 2006-05-04 9:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, linux-kernel
In-Reply-To: <7vbque5hq9.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Thu, May 04, 2006 at 10:14:54AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> - core.prefersymlinkrefs can be given to use symlink HEAD;
> this may be needed to bisect kernel history before January
> 2006 whose setlocalversion script depended on HEAD being a
> symlink.
Oh, I expected this to end up in 1.3.2, actually. :-)
Shouldn't this belong to the maint branch? It is "physically" a new
feature but I would consider "cannot bisect kernel before January" a bug
certainly worth fixing and the feature is pretty tiny. (It seems to be
backwards-incompatible but that only means you should provide some
transition path, I think. ;)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Re: segfault bug in internal git grep from next (fixed)
From: Marco Roeland @ 2006-05-04 8:44 UTC (permalink / raw)
To: git
In-Reply-To: <20060503083229.GA15579@fiberbit.xs4all.nl>
On Wednesday May 3rd 2006 Marco Roeland wrote:
> I'm using the next branch as of commit 6a40327d242dac9f85c6d63c94d537b45ba86e89
>
> A segfault occurs in using the new builtin grep when using it on a
> binary file, so no regular \n endings.
Fixed by Junio in commit 7ed36f56e33bd838d06521a37a916516397e9e8b.
I really use git grep a lot. It is very powerful, and the builtin version
makes even more possible. Thanks very much,
--
Marco Roeland
^ permalink raw reply
* Re: Unresolved issues #2
From: Jakub Narebski @ 2006-05-04 8:32 UTC (permalink / raw)
To: git
In-Reply-To: <7v4q065hq0.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> * #irc 2006-04-10
> Shallow clones (Carl Worth).
>
> The experiment last round did not work out very well, but as
> existing repositories get bigger, and more projects being
> migrated from foreign SCM systems, this would become a
> must-have from would-be-nice-to-have.
>
> I am beginning to think using "graft" to cauterize history
> for this, while it technically would work, would not be so
> helpful to users, so the design needs to be worked out again.
Perhaps use comment for marking graft as cauterizing history?
There was also talk about proposed git-splithist, which would move some of
the history to other (historical, archive) repository.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Unresolved issues #2
From: Junio C Hamano @ 2006-05-04 8:15 UTC (permalink / raw)
To: git
In-Reply-To: <7v64lcqz9j.fsf@assigned-by-dhcp.cox.net>
Here is a list of topics in the recent git traffic that I feel
inadequately addressed. I've commented on some of them to give
people a feel for what my priorities are. Somebody might want
to rehash the ones low on my priority list to conclusion with a
concrete proposal if they cared about them enough.
The list is *not* ordered in any way, except that the entries
kept from the previous issue of this message have been pushed
down to the bottom. I will probably start dropping some entries
that did not get any reaction from the list in future issues of
this message, but for now I kept all of them from the first one.
* Message-ID: <4fb292fa0604290630r19edd7ejf88642e33b350d1d@mail.gmail.com>
Content-type charset for send-email (Bertrand Jacquin)
The output from format-patch by default is unmarked, which
means the commit message part is UTF-8 (by strong convention),
and the contents of the diff is whatever the contents of the
file is encoded in.
David Woodhouse did a patch to allow specifying charset on the
command line (and default to UTF-8) which is a move in the
right direction, but Bertrand's system seems to have trouble
with it.
I think if we were to do this we probably need to teach
format-patch to optionally do multi-part. We may not
necessarily want to mark the payload to be in the same
encoding as the commit message (not that git-apply cares -- to
it, the payload is just 8-bit unencoded text, but we would
want to protect it from getting mangled by e-mail transport).
* Message-ID: <Pine.LNX.4.64.0604291006270.3701@g5.osdl.org>
Perhaps "note" field in commit objects are useful?
* Message-ID: <Pine.LNX.4.63.0604301524080.2646@wbgn013.biozentrum.uni-wuerzburg.de>
An optional "git fetch --store newname URL refspecs..." to
create an equivalent of remotes file so newname can then be
used as a short-hand. I still have somewhat negative reaction
to it, but I am willing to apply it if there are enough people
who want this.
-- carried over from the first issue of this list.
* Message-ID: <Pine.LNX.4.64.0604050855080.2550@localhost.localdomain>
Binary diff output? (Nicolas Pitre)
I do not think this is needed for our primary audience (the
kernel project), but I am sure it would be helpful for some
other projects if we allowed them to exchange patches that
describe binary file changes via e-mail, so I am not
dismissing this.
* #irc 2006-04-10
Shallow clones (Carl Worth).
The experiment last round did not work out very well, but as
existing repositories get bigger, and more projects being
migrated from foreign SCM systems, this would become a
must-have from would-be-nice-to-have.
I am beginning to think using "graft" to cauterize history
for this, while it technically would work, would not be so
helpful to users, so the design needs to be worked out again.
* Message-ID: <E1FMH3o-0001B5-Dw@jdl.com>
git status does not distinguish contents changes and mode
changes; it just says "modified" (Jon Loeliger).
Unconditionally changing the status letter would break
Porcelains so we would need an extra option to do this.
An outline patch has been already prepared -- this perhaps has
to wait until we sort out the "option parsing" one.
* Message-ID: <tnxmzf9sh7k.fsf@arm.com>
git could use diff3 instead of merge which is a wrapper around
diff3. (Catalin Marinas)
If having "diff3" is a lot more common than having "merge", I
do not have problem with this; "merge" being a wrapper to
"diff3", people who have been happy with the current code
would certainly have "diff3" installed so changing to "diff3"
would not break them.
* Message-ID: <81b0412b0603020649u99a2035i3b8adde8ddce9410@mail.gmail.com>
Windows problems summary (Alex Riesen)
A good list to keep in mind.
* Message-ID: <Pine.LNX.4.64.0604030730040.3781@g5.osdl.org>
Huge packfiles (Linus Torvalds)
Because I do not think asking users to break up packs to
manageable and mmap()able size is too much to ask, I would not
be advocating for updating the pack idx to 64-bit offset and
mmap()ing parts of a packfile, at least too strongly.
However, we currently lack tool support or recepe for users
with such a repository to easily break up packs.
* Message-ID: <1143856098.3555.48.camel@dv>
Per branch property, esp. where to merge from (Pavel Roskin)
This involves user-level "world model" design, which is more
Porcelainish than Plumbing, and as people know I do not do
Porcelain well; interested parties need to come up with what
they want and how they want to use it.
^ permalink raw reply
* What's in git.git
From: Junio C Hamano @ 2006-05-04 8:14 UTC (permalink / raw)
To: git; +Cc: linux-kernel
* Latest maintenance release 1.3.2 is out from the 'maint' branch.
* The 'master' branch has these since the last announcement, not
counting what is in v1.3.2.
- blame path-pruning fix (Fredrik Kuivinen)
- built-in push (Linus, Johannes Schindelin)
- beginning of "put remotes/ info in config file" (Johannes Schindelin)
- repo-config updates and fixes (Johannes Schindelin)
- built-in count-objects and diff
- core.prefersymlinkrefs can be given to use symlink HEAD;
this may be needed to bisect kernel history before January
2006 whose setlocalversion script depended on HEAD being a
symlink.
- "git-log --parents" fix (Linus)
- use rev-list instead of log in git-cvsserver (Martin Langhoff)
- sha1_to_hex() usage cleanup (Linus)
- Document update-index --unresolve (Matthias Kestenholz)
* The 'next' branch, in addition, has these.
- "put remotes/ info in config file" for fetch side (Johannes Schindelin)
- built-in grep
It now knows all the common grep options I personally use,
including -l, -w, -E, -i, -[ABC]<n>, -v; I am planning to
push this out perhaps mid next week.
- built-in format-patch WIP
I really should resume working on this again...
- cache-tree
Fixed a rather nasty bug; should be safe again to use it now.
- get_sha1(): :path and :[0-3]:path to extract from index.
- diff-delta enhancements (Nicolas Pitre)
* The 'pu' branch, in addition, has these.
- partial tree reading/writing with --prefix option.
- Transitively read alternatives (Martin Waitz)
^ permalink raw reply
* [ANNOUNCE] GIT 1.3.2
From: Junio C Hamano @ 2006-05-04 8:01 UTC (permalink / raw)
To: git; +Cc: linux-kernel
The latest maintenance release GIT 1.3.2 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.3.2.tar.{gz,bz2} (tarball)
RPMS/$arch/git-*-1.3.2-1.$arch.rpm (RPM)
Mostly documentation and usability fixes, with no exciting new
features, as the maintenance series ought to be.
----------------------------------------------------------------
Changes since v1.3.1 are as follows:
Huw Davies:
git-format-patch: Use rfc2822 compliant date.
Jon Loeliger:
Alphabetize the glossary.
Added definitions for a few words:
Add a few more words to the glossary.
Junio C Hamano:
rebase: typofix.
commit-tree.c: check_valid() microoptimization.
verify-pack: check integrity in a saner order.
git-am --resolved: more usable error message.
Linus Torvalds:
Fix filename verification when in a subdirectory
Martin Langhoff:
git-send-email: fix version string to be valid perl
Matthias Kestenholz:
annotate: fix warning about uninitialized scalar
annotate: display usage information if no filename was given
fix various typos in documentation
Robert Shearman:
give "what now" hint to users upon git-am failure.
Sean Estabrooks:
Update the git-branch man page to include the "-r" option,
Fix up remaining man pages that use asciidoc "callouts".
Properly render asciidoc "callouts" in git man pages.
Fix trivial typo in git-log man page.
^ permalink raw reply
* Re: [PATCH 3/3] Add a few more words to the glossary.
From: Junio C Hamano @ 2006-05-04 5:58 UTC (permalink / raw)
To: Jon Loeliger; +Cc: git
In-Reply-To: <E1FbVJi-0004UJ-59@jdl.com>
Jon Loeliger <jdl@jdl.com> writes:
> ref::
> - A 40-byte hex representation of a SHA1 pointing to a particular
> - object. These may be stored in `$GIT_DIR/refs/`.
> + A 40-byte hex representation of a SHA1 or a name that denotes
> + a particular object. These may be stored in `$GIT_DIR/refs/`.
>
> +symbolic ref::
> + See "ref".
Uum. Not very clear. Do we use that word that often?
I think I used that term to differenciate between HEAD symlink
pointing at refs/heads/master and HEAD being a regular file that
stores a line "ref: refs/heads/master\n"; the latter is the
modern style "textual symref", so in that context it is not
about 40-byte hex at all. And at that level it is really a
jargon to talk about one small implementation detail of HEAD, so
I am not sure it deserves to be in the glossary.
> tracking branch::
> - A regular git branch that is used to follow changes from
> + A regular git branch that is used to follow changes frompointing
> another repository. A tracking branch should not contain
I think this is a typo?
^ permalink raw reply
* Re: [PATCH 1/3] Alphabetize the glossary.
From: Junio C Hamano @ 2006-05-04 5:46 UTC (permalink / raw)
To: Jon Loeliger; +Cc: git
In-Reply-To: <E1FbVFi-0004Tt-Aw@jdl.com>
Jon Loeliger <jdl@jdl.com> writes:
> Signed-off-by: Jon Loeliger <jdl@jdl.com>
>
> ---
>
> Yeah, there is a script that also alphabetize the glossary.
> But let's just be explicit and complete here.
You alphabetized, _and_ added reference to "dirty" from clean,
without adding a corresponding reference to "clean" from dirty,
which is probably OK.
^ permalink raw reply
* Re: git-feed-mail-list.sh
From: Junio C Hamano @ 2006-05-04 5:16 UTC (permalink / raw)
Cc: git
In-Reply-To: <7vmzdy9zl2.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> David Woodhouse <dwmw2@infradead.org> writes:
>
>> # $FROM specifies the From: header used in the mails. It'll default
>> # to GIT_COMMITTER_EMAIL if that exists, or to `whoami`@`hostname`
>
> I am not sure if this part is tested..
>
>> # Unless configured otherwise, just cat it instead of mailing.
>> if [ -z "$FROM" ]; then
>> if [ -z "$GIT_COMMITTER_EMAIL" ]; then
>> FROM="$GIT_COMMITTER_EMAIL"
>> else
>> FROM=`whoami`@`hostname`
>> fi
>> fi
>
> Maybe you meant 'if test -n "$GIT_COMMITTER_EMAIL"' here?
>
>> # takes an object and generates the object's parent(s)
>> createmail () {
>> local commit
>
> If you were to do bashism local, don't you want to also localize
> other variables like key, SUBHEX, NEWSUB,...?
>
> It may make sense to enhance format-patch to do the Q encoding,
> so that you do not have to do this part by hand...
>
>> git-diff -B $parent $commit > $TMPCM
>> diffstat -p1 $TMPCM 2>/dev/null
>
> With GIT 1.3.0 and later:
>
> git diff --patch-with-stat $parent..$commit
>
> would be simpler here.
Or at least lose "diffstat -p1" and replace it with
git-apply --stat --status
which would be more pleasant.
>> if [ -z $2 ]; then
>> lastmail=`cat $MAILTAG`
>> else
>> lastmail=$(git-rev-parse $2)
>> fi
>
> lastmail=`git rev-parse --default "$MAILTAG" ${2+"$2"}`
As I wrote it this is broken, sorry.
This assumes you stop doing "MAILTAG=.git/refs/tags/MailDone"
by hand and lose "do we have GIT_DIR" logic as well.
Instead define MAILTAG=tags/MailDone or maybe refs/tags/MailDone
and let "git rev-parse --default refs/tags/MailDone" figure out
what to do when GIT_DIR is set or unset.
^ permalink raw reply
* Re: git-feed-mail-list.sh
From: Junio C Hamano @ 2006-05-04 4:35 UTC (permalink / raw)
To: David Woodhouse; +Cc: git
In-Reply-To: <1146678513.20773.45.camel@pmac.infradead.org>
David Woodhouse <dwmw2@infradead.org> writes:
> # $FROM specifies the From: header used in the mails. It'll default
> # to GIT_COMMITTER_EMAIL if that exists, or to `whoami`@`hostname`
I am not sure if this part is tested..
> # Unless configured otherwise, just cat it instead of mailing.
> if [ -z "$FROM" ]; then
> if [ -z "$GIT_COMMITTER_EMAIL" ]; then
> FROM="$GIT_COMMITTER_EMAIL"
> else
> FROM=`whoami`@`hostname`
> fi
> fi
Maybe you meant 'if test -n "$GIT_COMMITTER_EMAIL"' here?
> # takes an object and generates the object's parent(s)
> createmail () {
> local commit
If you were to do bashism local, don't you want to also localize
other variables like key, SUBHEX, NEWSUB,...?
It may make sense to enhance format-patch to do the Q encoding,
so that you do not have to do this part by hand...
> git-diff -B $parent $commit > $TMPCM
> diffstat -p1 $TMPCM 2>/dev/null
With GIT 1.3.0 and later:
git diff --patch-with-stat $parent..$commit
would be simpler here.
> base=$(git-rev-parse $1)
>
> if [ -z $2 ]; then
> lastmail=`cat $MAILTAG`
> else
> lastmail=$(git-rev-parse $2)
> fi
lastmail=`git rev-parse --default "$MAILTAG" ${2+"$2"}`
> if [ -z $1 ]; then
> base=$(git-rev-parse HEAD) || exit 1
> else
> base=$(git-rev-parse $1) || exit 1
> fi
I am not sure if earlier base=$(git-rev-parse $1) is needed if
you do this here...
^ permalink raw reply
* [PATCH 3/3] Add a few more words to the glossary.
From: Jon Loeliger @ 2006-05-04 4:19 UTC (permalink / raw)
To: git
Clean up a few entries and fix typos.
bare repository
cherry-picking
hook
symbolic ref
topic branch
Signed-off-by: Jon Loeliger <jdl@jdl.com>
---
Documentation/glossary.txt | 68 ++++++++++++++++++++++++++++++++++++--------
1 files changed, 55 insertions(+), 13 deletions(-)
b7524dc93e17807a3657f017adcbe129e16c4b94
diff --git a/Documentation/glossary.txt b/Documentation/glossary.txt
index 86196c4..f166d4f 100644
--- a/Documentation/glossary.txt
+++ b/Documentation/glossary.txt
@@ -3,6 +3,17 @@ alternate object database::
object database from another object database, which is called
"alternate".
+bare repository::
+ A bare repository is normally an appropriately named
+ directory with a `.git` suffix that does not have a
+ locally checked-out copy of any of the files under revision
+ control. That is, all of the `git` administrative and
+ control files that would normally be present in the
+ hidden `.git` sub-directory are directly present in
+ the `repository.git` directory instead, and no other files
+ are present and checked out. Usually publishers of public
+ repositories make bare repositories available.
+
blob object::
Untyped object, e.g. the contents of a file.
@@ -28,6 +39,15 @@ checkout::
The action of updating the working tree to a revision which was
stored in the object database.
+cherry-picking::
+ In SCM jargon, "cherry pick" means to choose a subset of
+ changes out of a series of changes (typically commits)
+ and record them as a new series of changes on top of
+ different codebase. In GIT, this is performed by
+ "git cherry-pick" command to extract the change
+ introduced by an existing commit and to record it based
+ on the tip of the current branch as a new commit.
+
clean::
A working tree is clean, if it corresponds to the revision
referenced by the current head. Also see "dirty".
@@ -100,6 +120,16 @@ head ref::
A ref pointing to a head. Often, this is abbreviated to "head".
Head refs are stored in `$GIT_DIR/refs/heads/`.
+hook::
+ During the normal execution of several git commands,
+ call-outs are made to optional scripts that allow
+ a developer to add functionality or checking.
+ Typically, the hooks allow for a command to be pre-verified
+ and potentially aborted, and allow for a post-notification
+ after the operation is done.
+ The hook scripts are found in the `$GIT_DIR/hooks/` directory,
+ and are enabled by simply making them executable.
+
index::
A collection of files with stat information, whose contents are
stored as objects. The index is a stored version of your working
@@ -113,10 +143,10 @@ index entry::
that file).
master::
- The default branch. Whenever you create a git repository, a branch
- named "master" is created, and becomes the active branch. In most
- cases, this contains the local development.
-
+ The default development branch. Whenever you create a git
+ repository, a branch named "master" is created, and becomes
+ the active branch. In most cases, this contains the local
+ development, though that is purely conventional and not required.
merge::
To merge branches means to try to accumulate the changes since a
@@ -151,10 +181,11 @@ octopus::
predator.
origin::
- The default upstream branch. Most projects have one upstream
- project which they track, and by default 'origin' is used for
- that purpose. New updates from upstream will be fetched into
- this branch; you should never commit to it yourself.
+ The default upstream tracking branch. Most projects have at
+ least one upstream project which they track. By default
+ 'origin' is used for that purpose. New upstream updates
+ will be fetched into this branch; you should never commit
+ to it yourself.
pack::
A set of objects which have been compressed into one file (to save
@@ -168,7 +199,8 @@ parent::
A commit object contains a (possibly empty) list of the logical
predecessor(s) in the line of development, i.e. its parents.
-pickaxe:: The term pickaxe refers to an option to the diffcore routines
+pickaxe::
+ The term pickaxe refers to an option to the diffcore routines
that help select changes that add or delete a given text string.
With the --pickaxe-all option, it can be used to view the
full changeset that introduced or removed, say, a particular
@@ -204,8 +236,8 @@ rebase::
changes from that branch.
ref::
- A 40-byte hex representation of a SHA1 pointing to a particular
- object. These may be stored in `$GIT_DIR/refs/`.
+ A 40-byte hex representation of a SHA1 or a name that denotes
+ a particular object. These may be stored in `$GIT_DIR/refs/`.
refspec::
A refspec is used by fetch and push to describe the mapping
@@ -243,10 +275,20 @@ SCM::
SHA1::
Synonym for object name.
+symbolic ref::
+ See "ref".
+
+topic branch::
+ A regular git branch that is used by a developer to
+ identify a conceptual line of development. Since branches
+ are very easy and inexpensive, it is often desirable to
+ have several small branches that each contain very well
+ defined concepts or small incremental yet related changes.
+
tracking branch::
- A regular git branch that is used to follow changes from
+ A regular git branch that is used to follow changes frompointing
another repository. A tracking branch should not contain
- direct modifications or made commits made locally.
+ direct modifications or have local commits made to it.
A tracking branch can usually be identified as the
right-hand-side ref in a Pull: refspec.
--
1.3.1.g3d990
^ permalink raw reply related
* [PATCH 2/3] Added definitions for a few words:
From: Jon Loeliger @ 2006-05-04 4:18 UTC (permalink / raw)
To: git
fast forward
pickaxe
refspec
tracking branch
Wild hack allows "link:git-" prefix to reference commands too.
Signed-off-by: Jon Loeliger <jdl@jdl.com>
---
Yep, this pickaxe entry is b0rked.
Apply the next patch too.
Documentation/glossary.txt | 33 +++++++++++++++++++++++++++++++++
Documentation/sort_glossary.pl | 2 +-
2 files changed, 34 insertions(+), 1 deletions(-)
b63f925f5f88549581324257d3b2030163389a98
diff --git a/Documentation/glossary.txt b/Documentation/glossary.txt
index 075c078..86196c4 100644
--- a/Documentation/glossary.txt
+++ b/Documentation/glossary.txt
@@ -68,6 +68,14 @@ ent::
`http://en.wikipedia.org/wiki/Ent_(Middle-earth)` for an in-depth
explanation.
+fast forward::
+ A fast-forward is a special type of merge where you have
+ a revision and you are "merging" another branch's changes
+ that happen to be a descendant of what you have.
+ In such these cases, you do not make a new merge commit but
+ instead just update to his revision. This will happen
+ frequently on a tracking branch of a remote repository.
+
fetch::
Fetching a branch means to get the branch's head ref from a
remote repository, to find out which objects are missing from
@@ -160,6 +168,12 @@ parent::
A commit object contains a (possibly empty) list of the logical
predecessor(s) in the line of development, i.e. its parents.
+pickaxe:: The term pickaxe refers to an option to the diffcore routines
+ that help select changes that add or delete a given text string.
+ With the --pickaxe-all option, it can be used to view the
+ full changeset that introduced or removed, say, a particular
+ line of text. See gitlink:git-diff[1].
+
plumbing::
Cute name for core git.
@@ -193,6 +207,18 @@ ref::
A 40-byte hex representation of a SHA1 pointing to a particular
object. These may be stored in `$GIT_DIR/refs/`.
+refspec::
+ A refspec is used by fetch and push to describe the mapping
+ between remote ref and local ref. They are combined with
+ a colon in the format <src>:<dst>, preceded by an optional
+ plus sign, +. For example:
+ `git fetch $URL refs/heads/master:refs/heads/origin`
+ means "grab the master branch head from the $URL and store
+ it as my origin branch head".
+ And `git push $URL refs/heads/master:refs/heads/to-upstream`
+ means "publish my master branch head as to-upstream master head
+ at $URL". See also gitlink:git-push[1]
+
repository::
A collection of refs together with an object database containing
all objects, which are reachable from the refs, possibly accompanied
@@ -217,6 +243,13 @@ SCM::
SHA1::
Synonym for object name.
+tracking branch::
+ A regular git branch that is used to follow changes from
+ another repository. A tracking branch should not contain
+ direct modifications or made commits made locally.
+ A tracking branch can usually be identified as the
+ right-hand-side ref in a Pull: refspec.
+
tree object::
An object containing a list of file names and modes along with refs
to the associated blob and/or tree objects. A tree is equivalent
diff --git a/Documentation/sort_glossary.pl b/Documentation/sort_glossary.pl
index e57dc78..e0bc552 100644
--- a/Documentation/sort_glossary.pl
+++ b/Documentation/sort_glossary.pl
@@ -48,7 +48,7 @@ This list is sorted alphabetically:
';
@keys=sort {uc($a) cmp uc($b)} keys %terms;
-$pattern='(\b'.join('\b|\b',reverse @keys).'\b)';
+$pattern='(\b(?<!link:git-)'.join('\b|\b(?<!link:git-)',reverse @keys).'\b)';
foreach $key (@keys) {
$terms{$key}=~s/$pattern/sprintf "<<ref_".no_spaces($1).",$1>>";/eg;
print '[[ref_'.no_spaces($key).']]'.$key."::\n"
--
1.3.1.g3d990
^ permalink raw reply related
* [PATCH 1/3] Alphabetize the glossary.
From: Jon Loeliger @ 2006-05-04 4:15 UTC (permalink / raw)
To: git
Signed-off-by: Jon Loeliger <jdl@jdl.com>
---
Yeah, there is a script that also alphabetize the glossary.
But let's just be explicit and complete here.
Documentation/glossary.txt | 339 ++++++++++++++++++++++----------------------
1 files changed, 170 insertions(+), 169 deletions(-)
374314abaefe3509c6016eb811b09e115ec4f2a8
diff --git a/Documentation/glossary.txt b/Documentation/glossary.txt
index 02a9d9c..075c078 100644
--- a/Documentation/glossary.txt
+++ b/Documentation/glossary.txt
@@ -1,79 +1,37 @@
-object::
- The unit of storage in git. It is uniquely identified by
- the SHA1 of its contents. Consequently, an object can not
- be changed.
-
-object name::
- The unique identifier of an object. The hash of the object's contents
- using the Secure Hash Algorithm 1 and usually represented by the 40
- character hexadecimal encoding of the hash of the object (possibly
- followed by a white space).
-
-SHA1::
- Synonym for object name.
-
-object identifier::
- Synonym for object name.
-
-hash::
- In git's context, synonym to object name.
-
-object database::
- Stores a set of "objects", and an individual object is identified
- by its object name. The objects usually live in `$GIT_DIR/objects/`.
+alternate object database::
+ Via the alternates mechanism, a repository can inherit part of its
+ object database from another object database, which is called
+ "alternate".
blob object::
Untyped object, e.g. the contents of a file.
-tree object::
- An object containing a list of file names and modes along with refs
- to the associated blob and/or tree objects. A tree is equivalent
- to a directory.
-
-tree::
- Either a working tree, or a tree object together with the
- dependent blob and tree objects (i.e. a stored representation
- of a working tree).
-
-DAG::
- Directed acyclic graph. The commit objects form a directed acyclic
- graph, because they have parents (directed), and the graph of commit
- objects is acyclic (there is no chain which begins and ends with the
- same object).
-
-index::
- A collection of files with stat information, whose contents are
- stored as objects. The index is a stored version of your working
- tree. Truth be told, it can also contain a second, and even a third
- version of a working tree, which are used when merging.
-
-index entry::
- The information regarding a particular file, stored in the index.
- An index entry can be unmerged, if a merge was started, but not
- yet finished (i.e. if the index contains multiple versions of
- that file).
-
-unmerged index:
- An index which contains unmerged index entries.
+branch::
+ A non-cyclical graph of revisions, i.e. the complete history of
+ a particular revision, which is called the branch head. The
+ branch heads are stored in `$GIT_DIR/refs/heads/`.
cache::
Obsolete for: index.
-working tree::
- The set of files and directories currently being worked on,
- i.e. you can work in your working tree without using git at all.
-
-directory::
- The list you get with "ls" :-)
+chain::
+ A list of objects, where each object in the list contains a
+ reference to its successor (for example, the successor of a commit
+ could be one of its parents).
-revision::
- A particular state of files and directories which was stored in
- the object database. It is referenced by a commit object.
+changeset::
+ BitKeeper/cvsps speak for "commit". Since git does not store
+ changes, but states, it really does not make sense to use
+ the term "changesets" with git.
checkout::
The action of updating the working tree to a revision which was
stored in the object database.
+clean::
+ A working tree is clean, if it corresponds to the revision
+ referenced by the current head. Also see "dirty".
+
commit::
As a verb: The action of storing the current state of the index in the
object database. The result is a revision.
@@ -85,73 +43,72 @@ commit object::
tree object which corresponds to the top directory of the
stored revision.
-parent::
- A commit object contains a (possibly empty) list of the logical
- predecessor(s) in the line of development, i.e. its parents.
+core git::
+ Fundamental data structures and utilities of git. Exposes only
+ limited source code management tools.
-changeset::
- BitKeeper/cvsps speak for "commit". Since git does not store
- changes, but states, it really does not make sense to use
- the term "changesets" with git.
+DAG::
+ Directed acyclic graph. The commit objects form a directed acyclic
+ graph, because they have parents (directed), and the graph of commit
+ objects is acyclic (there is no chain which begins and ends with the
+ same object).
-clean::
- A working tree is clean, if it corresponds to the revision
- referenced by the current head.
+dircache::
+ You are *waaaaay* behind.
dirty::
A working tree is said to be dirty if it contains modifications
which have not been committed to the current branch.
-head::
- The top of a branch. It contains a ref to the corresponding
- commit object.
+directory::
+ The list you get with "ls" :-)
-branch::
- A non-cyclical graph of revisions, i.e. the complete history of
- a particular revision, which is called the branch head. The
- branch heads are stored in `$GIT_DIR/refs/heads/`.
+ent::
+ Favorite synonym to "tree-ish" by some total geeks. See
+ `http://en.wikipedia.org/wiki/Ent_(Middle-earth)` for an in-depth
+ explanation.
-master::
- The default branch. Whenever you create a git repository, a branch
- named "master" is created, and becomes the active branch. In most
- cases, this contains the local development.
+fetch::
+ Fetching a branch means to get the branch's head ref from a
+ remote repository, to find out which objects are missing from
+ the local object database, and to get them, too.
-origin::
- The default upstream branch. Most projects have one upstream
- project which they track, and by default 'origin' is used for
- that purpose. New updates from upstream will be fetched into
- this branch; you should never commit to it yourself.
+file system::
+ Linus Torvalds originally designed git to be a user space file
+ system, i.e. the infrastructure to hold files and directories.
+ That ensured the efficiency and speed of git.
-ref::
- A 40-byte hex representation of a SHA1 pointing to a particular
- object. These may be stored in `$GIT_DIR/refs/`.
+git archive::
+ Synonym for repository (for arch people).
+
+hash::
+ In git's context, synonym to object name.
+
+head::
+ The top of a branch. It contains a ref to the corresponding
+ commit object.
head ref::
A ref pointing to a head. Often, this is abbreviated to "head".
Head refs are stored in `$GIT_DIR/refs/heads/`.
-tree-ish::
- A ref pointing to either a commit object, a tree object, or a
- tag object pointing to a tag or commit or tree object.
+index::
+ A collection of files with stat information, whose contents are
+ stored as objects. The index is a stored version of your working
+ tree. Truth be told, it can also contain a second, and even a third
+ version of a working tree, which are used when merging.
-ent::
- Favorite synonym to "tree-ish" by some total geeks. See
- `http://en.wikipedia.org/wiki/Ent_(Middle-earth)` for an in-depth
- explanation.
+index entry::
+ The information regarding a particular file, stored in the index.
+ An index entry can be unmerged, if a merge was started, but not
+ yet finished (i.e. if the index contains multiple versions of
+ that file).
-tag object::
- An object containing a ref pointing to another object, which can
- contain a message just like a commit object. It can also
- contain a (PGP) signature, in which case it is called a "signed
- tag object".
+master::
+ The default branch. Whenever you create a git repository, a branch
+ named "master" is created, and becomes the active branch. In most
+ cases, this contains the local development.
-tag::
- A ref pointing to a tag or commit object. In contrast to a head,
- a tag is not changed by a commit. Tags (not tag objects) are
- stored in `$GIT_DIR/refs/tags/`. A git tag has nothing to do with
- a Lisp tag (which is called object type in git's context).
- A tag is most typically used to mark a particular point in the
- commit ancestry chain.
merge::
To merge branches means to try to accumulate the changes since a
@@ -159,55 +116,57 @@ merge::
merge uses heuristics to accomplish that. Evidently, an automatic
merge can fail.
-octopus::
- To merge more than two branches. Also denotes an intelligent
- predator.
+object::
+ The unit of storage in git. It is uniquely identified by
+ the SHA1 of its contents. Consequently, an object can not
+ be changed.
-resolve::
- The action of fixing up manually what a failed automatic merge
- left behind.
+object database::
+ Stores a set of "objects", and an individual object is identified
+ by its object name. The objects usually live in `$GIT_DIR/objects/`.
-rewind::
- To throw away part of the development, i.e. to assign the head to
- an earlier revision.
+object identifier::
+ Synonym for object name.
-rebase::
- To clean a branch by starting from the head of the main line of
- development ("master"), and reapply the (possibly cherry-picked)
- changes from that branch.
+object name::
+ The unique identifier of an object. The hash of the object's contents
+ using the Secure Hash Algorithm 1 and usually represented by the 40
+ character hexadecimal encoding of the hash of the object (possibly
+ followed by a white space).
-repository::
- A collection of refs together with an object database containing
- all objects, which are reachable from the refs, possibly accompanied
- by meta data from one or more porcelains. A repository can
- share an object database with other repositories.
+object type:
+ One of the identifiers "commit","tree","tag" and "blob" describing
+ the type of an object.
-git archive::
- Synonym for repository (for arch people).
+octopus::
+ To merge more than two branches. Also denotes an intelligent
+ predator.
-file system::
- Linus Torvalds originally designed git to be a user space file
- system, i.e. the infrastructure to hold files and directories.
- That ensured the efficiency and speed of git.
+origin::
+ The default upstream branch. Most projects have one upstream
+ project which they track, and by default 'origin' is used for
+ that purpose. New updates from upstream will be fetched into
+ this branch; you should never commit to it yourself.
-alternate object database::
- Via the alternates mechanism, a repository can inherit part of its
- object database from another object database, which is called
- "alternate".
+pack::
+ A set of objects which have been compressed into one file (to save
+ space or to transmit them efficiently).
-reachable::
- An object is reachable from a ref/commit/tree/tag, if there is a
- chain leading from the latter to the former.
+pack index::
+ The list of identifiers, and other information, of the objects in a
+ pack, to assist in efficiently accessing the contents of a pack.
-chain::
- A list of objects, where each object in the list contains a
- reference to its successor (for example, the successor of a commit
- could be one of its parents).
+parent::
+ A commit object contains a (possibly empty) list of the logical
+ predecessor(s) in the line of development, i.e. its parents.
-fetch::
- Fetching a branch means to get the branch's head ref from a
- remote repository, to find out which objects are missing from
- the local object database, and to get them, too.
+plumbing::
+ Cute name for core git.
+
+porcelain::
+ Cute name for programs and program suites depending on core git,
+ presenting a high level access to core git. Porcelains expose
+ more of a SCM interface than the plumbing.
pull::
Pulling a branch means to fetch it and merge it.
@@ -221,33 +180,75 @@ push::
the remote head ref. If the remote head is not an ancestor to the
local head, the push fails.
-pack::
- A set of objects which have been compressed into one file (to save
- space or to transmit them efficiently).
+reachable::
+ An object is reachable from a ref/commit/tree/tag, if there is a
+ chain leading from the latter to the former.
-pack index::
- The list of identifiers, and other information, of the objects in a
- pack, to assist in efficiently accessing the contents of a pack.
+rebase::
+ To clean a branch by starting from the head of the main line of
+ development ("master"), and reapply the (possibly cherry-picked)
+ changes from that branch.
-core git::
- Fundamental data structures and utilities of git. Exposes only
- limited source code management tools.
+ref::
+ A 40-byte hex representation of a SHA1 pointing to a particular
+ object. These may be stored in `$GIT_DIR/refs/`.
-plumbing::
- Cute name for core git.
+repository::
+ A collection of refs together with an object database containing
+ all objects, which are reachable from the refs, possibly accompanied
+ by meta data from one or more porcelains. A repository can
+ share an object database with other repositories.
-porcelain::
- Cute name for programs and program suites depending on core git,
- presenting a high level access to core git. Porcelains expose
- more of a SCM interface than the plumbing.
+resolve::
+ The action of fixing up manually what a failed automatic merge
+ left behind.
-object type:
- One of the identifiers "commit","tree","tag" and "blob" describing
- the type of an object.
+revision::
+ A particular state of files and directories which was stored in
+ the object database. It is referenced by a commit object.
+
+rewind::
+ To throw away part of the development, i.e. to assign the head to
+ an earlier revision.
SCM::
Source code management (tool).
-dircache::
- You are *waaaaay* behind.
+SHA1::
+ Synonym for object name.
+
+tree object::
+ An object containing a list of file names and modes along with refs
+ to the associated blob and/or tree objects. A tree is equivalent
+ to a directory.
+
+tree::
+ Either a working tree, or a tree object together with the
+ dependent blob and tree objects (i.e. a stored representation
+ of a working tree).
+
+tree-ish::
+ A ref pointing to either a commit object, a tree object, or a
+ tag object pointing to a tag or commit or tree object.
+
+tag object::
+ An object containing a ref pointing to another object, which can
+ contain a message just like a commit object. It can also
+ contain a (PGP) signature, in which case it is called a "signed
+ tag object".
+
+tag::
+ A ref pointing to a tag or commit object. In contrast to a head,
+ a tag is not changed by a commit. Tags (not tag objects) are
+ stored in `$GIT_DIR/refs/tags/`. A git tag has nothing to do with
+ a Lisp tag (which is called object type in git's context).
+ A tag is most typically used to mark a particular point in the
+ commit ancestry chain.
+
+unmerged index:
+ An index which contains unmerged index entries.
+
+working tree::
+ The set of files and directories currently being worked on,
+ i.e. you can work in your working tree without using git at all.
--
1.3.1.g3d990
^ permalink raw reply related
* Re: sha1_to_hex() usage cleanup
From: Linus Torvalds @ 2006-05-04 1:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wvabp7a.fsf@assigned-by-dhcp.cox.net>
On Wed, 3 May 2006, Junio C Hamano wrote:
>
> Makes sort of sense in that the callers still need to be aware
> of the magic 4 limit but as long as they are they do not have to
> worry about allocation/deallocation/copying. But is that kind
> of cheat maintainable? I dunno.
If we just tell people that the rule is that it's still a statically
allocated buffer, but that you can magically use two "sha1_to_hex()" calls
in the same printf(), we'll probably get a good mix of "usable and safe".
Linus
^ permalink raw reply
* Re: [ANNOUNCE] Revamped Git homepage
From: Petr Baudis @ 2006-05-04 1:23 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e3bjnb$72o$1@sea.gmane.org>
Dear diary, on Thu, May 04, 2006 at 03:01:33AM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> Very nice, although earlier version had the advantage of having everything
> on one page. I hope that no information was lost.
Perhaps few bits but I think they were insignificant or just confusing.
:) (Like Cogito/StGit commands for cloning Git repository).
> What it lacks is the link in menu bar to Home (or News),
> i.e. http://git.or.cz/ or http://git.or.cz/index.html page.
You could get there clicking on the Git logo, but I agree that this
wasn't very intuitive. I've added a link.
> About Download page (http://git.or.cz/download.html) - it would be nice to
> have in comments about firewalls told which port git uses for git://
> protocol.
Good idea, added.
By the way, it has been suggested on #git that it might be worth sharing
the same color scheme between gitweb and the homepage. I have tried it
out but the gitweb's color scheme might be a bit too dull for the
homepage, dunno (I might also just already get too used to the bluish
theme). Opinions welcome. It's the "Gitweb gray" stylesheet (in Firefox,
View -> Page style).
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Re: Fetching a tree from a remote server
From: Daniel Barkalow @ 2006-05-04 1:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0605040247460.24675@wbgn013.biozentrum.uni-wuerzburg.de>
On Thu, 4 May 2006, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 3 May 2006, Daniel Barkalow wrote:
>
> > Is there something to do the opposite of git clone -n? That is, I want to
> > fill a directory with a treeish ref, and I don't care about any history or
> > bookkeeping.
>
> Is git-tar-tree your friend or what?
The problem is that I'm on the build machine, and the repository is on the
remote server. I suppose I could do "(ssh server
GIT_DIR=/repo.git git-tar-tree HEAD) | tar -xf -", but that's not quite
the most clear thing, and I'd have to split up the URLs. Also, it wouldn't
work with only git: access to the repository.
(On the other hand, it does work for my actual application, I'm doing it
from a Makefile, and it's blazingly fast, so I guess I'm set.)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [ANNOUNCE] Revamped Git homepage
From: Jakub Narebski @ 2006-05-04 1:01 UTC (permalink / raw)
To: git
In-Reply-To: <20060504003518.GT27689@pasky.or.cz>
Petr Baudis wrote:
> Well, here we go, I've just uploaded a new version of the Git homepage;
> I wonder how you feel about it now.
>
> Obviously, it still feels rather empty and I'm certainly not much of
> a webmaster myself, but I take patches and pull requests; see
> http://git.or.cz/community.html for the Git homepage git repository
> information.
>
> I've borrowed Jonas Fonseca's ELinks homepage design first, but the
> contents ended up almost entirely rewritten as well (except the Related
> Tools section, which stayed mostly as it was). Git now poses as a real
> version control system and the plumbing stuff is mentioned only in the
> bottom paragraphs. ;-)
Very nice, although earlier version had the advantage of having everything
on one page. I hope that no information was lost.
What it lacks is the link in menu bar to Home (or News),
i.e. http://git.or.cz/ or http://git.or.cz/index.html page.
About Download page (http://git.or.cz/download.html) - it would be nice to
have in comments about firewalls told which port git uses for git://
protocol.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [ANNOUNCE] Git wiki
From: Daniel Barkalow @ 2006-05-04 0:53 UTC (permalink / raw)
To: Petr Baudis; +Cc: David Lang, Jakub Narebski, git
In-Reply-To: <20060503193013.GN27689@pasky.or.cz>
On Wed, 3 May 2006, Petr Baudis wrote:
> Dear diary, on Wed, May 03, 2006 at 09:21:54PM CEST, I got a letter
> where David Lang <dlang@digitalinsight.com> said that...
> > On Wed, 3 May 2006, Jakub Narebski wrote:
> >
> > >As to content, we could I think use material found at Wikipedia Git page,
> > >and on External Links in Wikipedia Git_(software) article, not repeating of
> > >course what is in official Git Documentation/
> >
> > please go ahead and put a lot of the info that is in the GIT
> > Documentation/ on the wiki. it's far easier to go to one site and browse
> > around to find things then to run into issues where you have to go
> > somewhere else (with different tools) to find the info.
> >
> > even if you just put all the documentation files there, as-is (as text
> > files even, no hyperlinks in them) they should still be there.
>
> Then who will keep it in sync (BOTH ways)? That would be quite a lot of
> work, I think.
>
> That said, having the documentation in a wiki is not a bad idea per se,
> but you need to keep things consistent and converging. And I believe
> (and hope) that killing Documentation/ directory is no option - I hate
> it when documentation of software I installed just tells me "look at
> this URI" (which documents a different version anyway, and it's all very
> useful when I'm sitting in a train with my notebook).
Clearly the solution is a wiki with a git backend and asciidoc for the
formatting language. Then the wiki just has to pull from kernel.org
occasionally, and Junio can pull from the wiki's repository when there are
good changes there.
I'm actually only somewhat joking; I wrote a Python CGI for this at one
point, and got as far as having it basically work, but then I couldn't
come up with a way to safely use asciidoc to format an attacker's file.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Fetching a tree from a remote server
From: Johannes Schindelin @ 2006-05-04 0:48 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605032026070.6713@iabervon.org>
Hi,
On Wed, 3 May 2006, Daniel Barkalow wrote:
> Is there something to do the opposite of git clone -n? That is, I want to
> fill a directory with a treeish ref, and I don't care about any history or
> bookkeeping.
Is git-tar-tree your friend or what?
Ciao,
Dscho
^ permalink raw reply
* Re: [WARNING] please stop using git.git "next" for now
From: Junio C Hamano @ 2006-05-04 0:46 UTC (permalink / raw)
To: git
In-Reply-To: <7vejzabt2b.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
>> I will be working on a fix now, but in the meantime please do
>> not use the "next" branch for real work. Sorry for the
>> breakage.
>
> Two-way merge by read-tree forgot to invalidate the directories
> a new element was added underneath. The fix is simple and will
> be in the "next" I'll push out tonight.
OK, done. Will be looking into "binary grep segfault" problem
next.
^ permalink raw reply
* Fetching a tree from a remote server
From: Daniel Barkalow @ 2006-05-04 0:41 UTC (permalink / raw)
To: git
Is there something to do the opposite of git clone -n? That is, I want to
fill a directory with a treeish ref, and I don't care about any history or
bookkeeping. I'm doing automated builds of things stored on a slow
machine, so I'd really benefit from not getting the history. As it is,
it's only twice as fast as arch, when it really ought to be hundreds of
times faster.
Also, git-archimport in 1.2.4 seems to leave master as the initial import,
rather than either not having it or having it at the end, which is a bit
confusing.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: sha1_to_hex() usage cleanup
From: Junio C Hamano @ 2006-05-04 0:36 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0605031717190.4086@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Somebody on the #git channel complained that the sha1_to_hex() thing uses
> a static buffer which caused an error message to show the same hex output
> twice instead of showing two different ones.
>
> That's pretty easily rectified by making it uses a simple LRU of a few
> buffers, which also allows some other users (that were aware of the buffer
> re-use) to be written in a more straightforward manner.
>
> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
> ---
>
> This is another throw-away patch of mine. Not a big deal, but since I
> tried it, I might as well try to submit it and see if Junio agrees..
Makes sort of sense in that the callers still need to be aware
of the magic 4 limit but as long as they are they do not have to
worry about allocation/deallocation/copying. But is that kind
of cheat maintainable? I dunno.
^ 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