* Re: [PATCH 2/3] entry.c: checkout available submodules
From: Sven Verdoolaege @ 2007-05-25 21:42 UTC (permalink / raw)
To: Martin Waitz; +Cc: git, Junio C Hamano, Alex Riesen
In-Reply-To: <20070525213103.GA8361@admingilde.org>
On Fri, May 25, 2007 at 11:31:03PM +0200, Martin Waitz wrote:
> I think the list tends to prefer subproject over submodule.
Does it? It seems that everyone writing code is use submodule
instead of subproject. Either way, I don't really care.
> > @@ -193,9 +220,8 @@ int checkout_entry(struct cache_entry *ce, const struct checkout *state, char *t
> > */
> > unlink(path);
> > if (S_ISDIR(st.st_mode)) {
> > - /* If it is a gitlink, leave it alone! */
> > if (S_ISGITLINK(ntohl(ce->ce_mode)))
> > - return 0;
> > + return checkout_submodule(ce, path, state);
> > if (!state->force)
> > return error("%s is a directory", path);
> > remove_subtree(path);
>
> I think the call to checkout_submodule should be moved to write_entry,
> to keep it in line with the other mode types.
Well, like your patch, this only deals with cases where the submodule
is already available. In write_entry you could potentially clone
submodules based on some criteria, but I'm not doing this just yet
since some people apparently prefer to get these things in pieces.
Also, it seems that some people would like this to be a step
that is separated from git-checkout (see Lars' patch).
skimo
^ permalink raw reply
* Re: [PATCH] Add git-submodule command
From: Lars Hjemli @ 2007-05-25 22:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git, Linus Torvalds
In-Reply-To: <7v4pm0r5ga.fsf@assigned-by-dhcp.cox.net>
[This thread is starting to get long, sorry for even more noise about
the submodule stuff]
On 5/25/07, Junio C Hamano <junkio@cox.net> wrote:
> "Lars Hjemli" <hjemli@gmail.com> writes:
>
> > On 5/25/07, Junio C Hamano <junkio@cox.net> wrote:
> > ...
> >> I really do not want that (mis)conception that .gitmodules
> >> specify the default and .git/config the override. I really
> >> think we should use the .git/config as _the_ only authority to
> >> get URL, but keyed with the three-level scheme, with URL in
> >> .gitmodules used _solely_ as a hint when setting up the URL in
> >> the .git/config file.
> >>
> >> cf. $gmane/47502, 47548, 47621
> >>
> >
> > I've read these articles, but I think much of the concerns about
> > trusting the url supplied by upstream goes away when the submodule
> > clone/checkout isn't an integrated part of the superproject
> > clone/checkout. Besides, if you trust your upstream enough to clone
> > their repository (the superproject), why wouldn't you trust the data
> > (.gitmodules) in that very repository?
>
> It's not about trusting. You would need to support the mapping
> for network connectivity reasons, and you would also need to
> notice and reconfirm when the suggested URL in .gitmodules
> changes (perhaps because the upstream relocated from sf.net to
> repo.or.cz ;-), you would need something like what I described
> in order to keep track of user preference for each submodule in
> .git/config anyway. If that "mapping" ends up to be ident
> mapping for most people, that is fine. At least by always doing
> the three-level mapping we would not have any special case in
> the code, and this is not the performance critical part of the
> system.
>
> I think the response to the case when upstream repository
> relocates from the ".gitmodule for default, .git/config for
> override" camp would be "you asked to override in .git/config,
> so it is your job to notice the change in .gitmodules and adjust
> your override URL". That is a serious mistake in usability
> point of view. Repository relocation would (hopefully) seldom
> happen, but when it does happen, things either would break
> (which is easier to diagnose and manually fix up), or things
> clone fine but we reach a wrong repository (which is harder to
> notice, as "fetch" may succeed -- it just would not fetch the
> right commit). Being able to notice when upstream repository
> relocates and to ask for confirmation when that happens would
> eliminate a lot of confusion from that.
Basically, I'd say that as long as the superproject names the sha1 of
the submodule commit, nothing else matters.
If you track a submodule, you would easily notice it if the submodule
has the 'wrong' commit checked out (git diff, git status, git
submodule status). And 'git submodule update' would synchronize the
submodules you have decided to track, or error out with a message like
"Unable to checkout '$sha1' in submodule '$path'".
This is when the ugly sides of submodules raises its head (the
'official' repo has moved, my local repo is out of date, whatever). I
just don't see the need for solving those problems now. The 'git
submodule' command would make the common cases easier. Hopefully(?)
that would encourage more people to test/use submodules, and the
problems that actually _needs_ solving will then show up in due time.
> > Another possibility is simply doing the submodule clone/checkout by
> > hand (i.e. do 'git clone preferred-url path', don't do 'git submodule
> > init path').
>
> But that is what this patch is trying to help the users, isn't
> it? It reduces the attractiveness of this new tool greatly if
> you give up there.
Well, I happen to think that the average user of submodules wouldn't
care the slightest bit where the submodule was cloned from, as long as
the sha1 matches. So no, the patch was more about the lack of
submodule porcelain and less about completeness.
> >>When the name of the commit object in the
> >> superproject tree and/or index is 0{40}, it would be a good
> >> extension to use "whatever commit that happens to be at the tip
> >> of this branch" taken from the .gitmodules file.
> >
> > I really can't imagine what kind of superproject would have such a
> > setup. Why would this be needed?
>
> "We would work with any working version of Linux 2.6 kernel"
> would be a sensible thing to say, I would think.
Maybe. I wouldn't want to automatically track the tip of _any_ branch,
since I would have no way of knowing if what works today will also
work tomorrow (or even compile).
> It's purely optional, and as you seem to agree always detaching
> HEAD is easier to explain, you do not need "module.$path.branch"
> at all. I just mentioned 0{40} as a possible use case for that
> configuration variable.
Ok.
I'll redo the patch, removing the branch-specific things, and try to shut up :)
--
larsh
^ permalink raw reply
* Re: [PATCH 07/16] git-read-tree: take --submodules option
From: Junio C Hamano @ 2007-05-25 22:11 UTC (permalink / raw)
To: Steven Grimm; +Cc: Jan Hudec, Martin Waitz, skimo, Alex Riesen, git
In-Reply-To: <46575220.2070604@midwinter.com>
Steven Grimm <koreth@midwinter.com> writes:
> Junio C Hamano wrote:
>> If you were doing an efficient cgi script that renders history
>> of git managed projects, binding git as its subproject, and that
>> system can be built with either 'maint' (i.e. 1.5.2 series) or
>> 'master' (i.e. ultrastable WIP towards 1.5.3), even though they
>> both might come from git://git.kernel.org/pub/scm/git/git.git/,
>> I think they should be registered as two separate logical
>> subprojects.
>
> I agree strongly with this, and it's another good reason that we have
> to be able to use something other than the URL as the key to look up a
> subproject's repository location. If you use the URL it is impossible
> to differentiate the two subprojects in this case.
Heh, you do not have to rub it in ;-) I already agreed that
your three-level arrangement is easier to work with.
^ permalink raw reply
* Re: [PATCH 2/3] entry.c: checkout available submodules
From: Martin Waitz @ 2007-05-25 22:19 UTC (permalink / raw)
To: skimo; +Cc: git, Junio C Hamano, Alex Riesen
In-Reply-To: <20070525214205.GJ942MdfPADPa@greensroom.kotnet.org>
[-- Attachment #1: Type: text/plain, Size: 1985 bytes --]
hoi :)
On Fri, May 25, 2007 at 11:42:05PM +0200, Sven Verdoolaege wrote:
> On Fri, May 25, 2007 at 11:31:03PM +0200, Martin Waitz wrote:
> > I think the list tends to prefer subproject over submodule.
>
> Does it? It seems that everyone writing code is use submodule
> instead of subproject. Either way, I don't really care.
I got that impression from my small poll.
> > > @@ -193,9 +220,8 @@ int checkout_entry(struct cache_entry *ce, const struct checkout *state, char *t
> > > */
> > > unlink(path);
> > > if (S_ISDIR(st.st_mode)) {
> > > - /* If it is a gitlink, leave it alone! */
> > > if (S_ISGITLINK(ntohl(ce->ce_mode)))
> > > - return 0;
> > > + return checkout_submodule(ce, path, state);
> > > if (!state->force)
> > > return error("%s is a directory", path);
> > > remove_subtree(path);
> >
> > I think the call to checkout_submodule should be moved to write_entry,
> > to keep it in line with the other mode types.
>
> Well, like your patch, this only deals with cases where the submodule
> is already available. In write_entry you could potentially clone
> submodules based on some criteria, but I'm not doing this just yet
> since some people apparently prefer to get these things in pieces.
yes, first we need checkout and then can add more building blocks on
top.
Up to now the quoted code block above only handles cleaning the
tree from conflicting / old entries and write_entry creates the
real content.
For subprojects we first have to remove any non-subproject content
in that location and then later call write_subproject or similiar
in write_entry to update the subproject (or create some empty dummy
directory).
But we can also leave those details for later when we are clear about
the complete semantics. At the moment it is important to reach a
common base everybody agrees on and which is enough to experiment with
all the high level tools.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH 1/3] Documentation: Clean up links in GIT Glossary
From: Jakub Narebski @ 2007-05-25 22:37 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
Ensure that the same link is not repeated in single glossary entry,
and that there is no self-link i.e. link to current entry.
Add links to other definitions in git glossary.
Remove inappropriate (nonsense) links, or change link to link to
correct definition (to correct term).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
While updating http://git.or.cz/gitwiki/GitGlossary to modern
Documentation/glossary.txt version, I have noticed few places
where GIT Glossary can be improved.
Documentation/glossary.txt | 58 ++++++++++++++++++++++----------------------
1 files changed, 29 insertions(+), 29 deletions(-)
diff --git a/Documentation/glossary.txt b/Documentation/glossary.txt
index 489c3e9..ba52618 100644
--- a/Documentation/glossary.txt
+++ b/Documentation/glossary.txt
@@ -10,7 +10,7 @@ GIT Glossary
A bare repository is normally an appropriately
named <<def_directory,directory>> with a `.git` suffix that does not
have a locally checked-out copy of any of the files under
- <<def_revision,revision>> control. That is, all of the `git`
+ 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,
@@ -37,7 +37,7 @@ GIT Glossary
[[def_chain]]chain::
A list of objects, where each <<def_object,object>> in the list contains
a reference to its successor (for example, the successor of a
- <<def_commit,commit>> could be one of its parents).
+ <<def_commit,commit>> could be one of its <<def_parent,parents>>).
[[def_changeset]]changeset::
BitKeeper/cvsps speak for "<<def_commit,commit>>". Since git does not
@@ -77,10 +77,10 @@ to point at the new commit.
[[def_commit_object]]commit object::
An <<def_object,object>> which contains the information about a
- particular <<def_revision,revision>>, such as parents, committer,
+ particular <<def_revision,revision>>, such as <<def_parent,parents>>, committer,
author, date and the <<def_tree_object,tree object>> which corresponds
to the top <<def_directory,directory>> of the stored
- <<def_revision,revision>>.
+ revision.
[[def_core_git]]core git::
Fundamental data structures and utilities of git. Exposes only limited
@@ -101,19 +101,19 @@ to point at the new commit.
[[def_detached_HEAD]]detached HEAD::
Normally the <<def_HEAD,HEAD>> stores the name of a
- <<def_branch,branch>>. However, git also allows you to check
- out an arbitrary commit that isn't necessarily the tip of any
+ <<def_branch,branch>>. However, git also allows you to <<def_checkout,check out>>
+ an arbitrary <<def_commit,commit>> that isn't necessarily the tip of any
particular branch. In this case HEAD is said to be "detached".
[[def_dircache]]dircache::
- You are *waaaaay* behind.
+ You are *waaaaay* behind. See <<def_index,index>>.
[[def_directory]]directory::
The list you get with "ls" :-)
[[def_dirty]]dirty::
A <<def_working_tree,working tree>> is said to be "dirty" if
- it contains modifications which have not been committed to the current
+ it contains modifications which have not been <<def_commit,committed>> to the current
<<def_branch,branch>>.
[[def_ent]]ent::
@@ -149,7 +149,7 @@ to point at the new commit.
[[def_grafts]]grafts::
Grafts enables two otherwise different lines of development to be joined
together by recording fake ancestry information for commits. This way
- you can make git pretend the set of parents a <<def_commit,commit>> has
+ you can make git pretend the set of <<def_parent,parents>> a <<def_commit,commit>> has
is different from what was recorded when the commit was
created. Configured via the `.git/info/grafts` file.
@@ -157,13 +157,13 @@ to point at the new commit.
In git's context, synonym to <<def_object_name,object name>>.
[[def_head]]head::
- A named reference to the <<def_commit,commit>> at the tip of a
+ A <<def_ref,named reference>> to the <<def_commit,commit>> at the tip of a
<<def_branch,branch>>. Heads are stored in
`$GIT_DIR/refs/heads/`, except when using packed refs. (See
gitlink:git-pack-refs[1].)
[[def_HEAD]]HEAD::
- The current branch. In more detail: Your <<def_working_tree,
+ The current <<def_branch,branch>>. In more detail: Your <<def_working_tree,
working tree>> is normally derived from the state of the tree
referred to by HEAD. HEAD is a reference to one of the
<<def_head,heads>> in your repository, except when using a
@@ -179,15 +179,15 @@ to point at the new commit.
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/` <<def_directory,directory>>, and are enabled by simply
+ `$GIT_DIR/hooks/` directory, and are enabled by simply
making them executable.
[[def_index]]index::
A collection of files with stat information, whose contents are stored
- as objects. The index is a stored version of your working
- <<def_tree,tree>>. Truth be told, it can also contain a second, and even
- a third version of a <<def_working_tree,working tree>>, which are used
- when merging.
+ as objects. The index is a stored version of your
+ <<def_working_tree,working tree>>. Truth be told, it can also contain a second, and even
+ a third version of a working tree, which are used
+ when <<def_merge,merging>>.
[[def_index_entry]]index entry::
The information regarding a particular file, stored in the
@@ -249,16 +249,16 @@ This commit is referred to as a "merge commit", or sometimes just a
describing the type of an <<def_object,object>>.
[[def_octopus]]octopus::
- To <<def_merge,merge>> more than two branches. Also denotes an
+ To <<def_merge,merge>> more than two <<def_branch,branches>>. Also denotes an
intelligent predator.
[[def_origin]]origin::
The default upstream <<def_repository,repository>>. 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 remote tracking branches named
+ will be fetched into remote <<def_tracking_branch,tracking branches>> named
origin/name-of-upstream-branch, which you can see using
- "git <<def_branch,branch>> -r".
+ "`git branch -r`".
[[def_pack]]pack::
A set of objects which have been compressed into one file (to save space
@@ -327,7 +327,7 @@ This commit is referred to as a "merge commit", or sometimes just a
`$GIT_DIR/refs/`.
[[def_refspec]]refspec::
- A <<def_refspec,refspec>> is used by <<def_fetch,fetch>> and
+ A "refspec" is used by <<def_fetch,fetch>> and
<<def_push,push>> to describe the mapping between remote
<<def_ref,ref>> and local ref. They are combined with a colon in
the format <src>:<dst>, preceded by an optional plus sign, +.
@@ -340,11 +340,12 @@ This commit is referred to as a "merge commit", or sometimes just a
gitlink:git-push[1]
[[def_repository]]repository::
- A collection of refs together with an
+ A collection of <<def_ref,refs>> together with an
<<def_object_database,object database>> containing all objects
which are <<def_reachable,reachable>> from the refs, possibly
- accompanied by meta data from one or more porcelains. A
- repository can share an object database with other repositories.
+ accompanied by meta data from one or more <<def_porcelain,porcelains>>. A
+ repository can share an object database with other repositories
+ via <<def_alternate_object_database,alternates mechanism>>.
[[def_resolve]]resolve::
The action of fixing up manually what a failed automatic
@@ -366,8 +367,8 @@ This commit is referred to as a "merge commit", or sometimes just a
Synonym for <<def_object_name,object name>>.
[[def_shallow_repository]]shallow repository::
- A shallow repository has an incomplete
- history some of whose commits have parents cauterized away (in other
+ A shallow <<def_repository,repository>> has an incomplete
+ history some of whose <<def_commit,commits>> have <<def_parent,parents>> cauterized away (in other
words, git is told to pretend that these commits do not have the
parents, even though they are recorded in the <<def_commit_object,commit
object>>). This is sometimes useful when you are interested only in the
@@ -385,7 +386,7 @@ This commit is referred to as a "merge commit", or sometimes just a
command.
[[def_tag]]tag::
- A <<def_ref,ref>> pointing to a tag or
+ A <<def_ref,ref>> pointing to a <<def_tag_object,tag>> or
<<def_commit_object,commit object>>. In contrast to a <<def_head,head>>,
a tag is not changed by a <<def_commit,commit>>. Tags (not
<<def_tag_object,tag objects>>) are stored in `$GIT_DIR/refs/tags/`. A
@@ -398,8 +399,7 @@ This commit is referred to as a "merge commit", or sometimes just a
An <<def_object,object>> containing a <<def_ref,ref>> pointing to
another object, which can contain a message just like a
<<def_commit_object,commit object>>. It can also contain a (PGP)
- signature, in which case it is called a "signed <<def_tag_object,tag
- object>>".
+ signature, in which case it is called a "signed tag object".
[[def_topic_branch]]topic branch::
A regular git <<def_branch,branch>> that is used by a developer to
@@ -418,7 +418,7 @@ This commit is referred to as a "merge commit", or sometimes just a
[[def_tree]]tree::
Either a <<def_working_tree,working tree>>, or a <<def_tree_object,tree
- object>> together with the dependent blob and tree objects
+ object>> together with the dependent <<def_blob_object,blob>> and tree objects
(i.e. a stored representation of a working tree).
[[def_tree_object]]tree object::
--
1.5.2
^ permalink raw reply related
* [PATCH 3/3] Replace the last 'dircache's by 'index'
From: Jakub Narebski @ 2007-05-25 22:37 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <1180132662719-git-send-email-jnareb@gmail.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Documentation/git-ls-files.txt | 2 +-
diff.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
index 076cebc..43e0d22 100644
--- a/Documentation/git-ls-files.txt
+++ b/Documentation/git-ls-files.txt
@@ -124,7 +124,7 @@ which case it outputs:
detailed information on unmerged paths.
For an unmerged path, instead of recording a single mode/SHA1 pair,
-the dircache records up to three such pairs; one from tree O in stage
+the index records up to three such pairs; one from tree O in stage
1, A in stage 2, and B in stage 3. This information can be used by
the user (or the porcelain) to see what should eventually be recorded at the
path. (see git-read-tree for more information on state)
diff --git a/diff.c b/diff.c
index 0e26049..508bc51 100644
--- a/diff.c
+++ b/diff.c
@@ -1349,7 +1349,7 @@ void fill_filespec(struct diff_filespec *spec, const unsigned char *sha1,
}
/*
- * Given a name and sha1 pair, if the dircache tells us the file in
+ * Given a name and sha1 pair, if the index tells us the file in
* the work tree has that object contents, return true, so that
* prepare_temp_file() does not have to inflate and extract.
*/
--
1.5.2
^ permalink raw reply related
* [PATCH 2/3] Documentation: Add definition of "evil merge" to GIT Glossary
From: Jakub Narebski @ 2007-05-25 22:37 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <11801326601014-git-send-email-jnareb@gmail.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Applies cleanly to 'master' branch 18bece43675ea0dc9022a7868865e02808b7af7f
Documentation/glossary.txt | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/Documentation/glossary.txt b/Documentation/glossary.txt
index ba52618..e903abf 100644
--- a/Documentation/glossary.txt
+++ b/Documentation/glossary.txt
@@ -121,6 +121,10 @@ to point at the new commit.
`http://en.wikipedia.org/wiki/Ent_(Middle-earth)` for an in-depth
explanation. Avoid this term, not to confuse people.
+[[def_evil_merge]]evil merge::
+ An evil merge is a <<def_merge,merge>> that introduces changes that
+ do not appear in any <<def_parent,parent>>.
+
[[def_fast_forward]]fast forward::
A fast-forward is a special type of <<def_merge,merge>> where you have a
<<def_revision,revision>> and you are "merging" another
--
1.5.2
^ permalink raw reply related
* Re: [PATCH] Add git-submodule command
From: Lars Hjemli @ 2007-05-25 22:33 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0705251924280.4648@racer.site>
On 5/25/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> [* many usefull comments about the docs *]
Thanks, will fix
> > +USAGE='[--init | --update | --cached] [--quiet] [--] [<path>...]'
> > +. git-sh-setup
> > +require_work_tree
>
> Maybe
>
> test -f "$GIT_DIR"/.gitmodules || die "Not a superproject"
>
> Hmm?
Yeah, maybe. But the command will only touch entries with mode 160000
anyway, so it might not be a big deal.
>
> > + rmdir "$path" 2>/dev/null ||
>
> Just out of curiousity: is rmdir portable? I always used "rm -r"...
I have no idea, really. But the reason for using rmdir was this
section of the man page:
NAME
rmdir - remove empty directories
I do not want to delete an unempty directory. But there is probably
some better way to do this?
--
larsh
^ permalink raw reply
* Re: [PATCH 2/3] entry.c: checkout available submodules
From: Junio C Hamano @ 2007-05-25 23:06 UTC (permalink / raw)
To: Martin Waitz; +Cc: skimo, git, Alex Riesen
In-Reply-To: <20070525221913.GB8361@admingilde.org>
Martin Waitz <tali@admingilde.org> writes:
> But we can also leave those details for later when we are clear about
> the complete semantics. At the moment it is important to reach a
> common base everybody agrees on and which is enough to experiment with
> all the high level tools.
Overall I am reasonably happy with the direction these "smaller"
patches take us, although I suspect the semantics implemented by
this series _might_ need to be scrapped when we start talking
about switching between branches that has and does not have a
subproject at that path, and other corner cases we do not forsee
right now.
I think we are Ok, as long as we make it is clear that we
currently do not support switching from a commit that has a
submodule at one path to another commit that does not (in which
case with a naive implementation we would end up having to nuke
the submodule, and we need to have a way to save it, which we
discussed yesterday, with .git/subproject/$name.git/ being the
stashed away mirror to either quick-clone from, or symlink to).
And more importantly, we would need to make it crystal clear
that the superproject support by the Porcelain layer is still
experimental and is subject to change in potentially backward
incompatible way. We haven't had enough experience to decide
the best semantics from day one, and experience cannot be gained
without playing with something small like this series anyway.
We may come up with a much superior design after gaining the
experience, and if that is incompatible with the layout this
series assumes, so be it. We'd have a big feature release that
changes the semantics and that will incur some transition pain,
but overall we would be better off with the final result.
A clear separation of the superproject and the projects it uses
as its submodules helps us here. At the worst case, migrating
to the updated layout in the future would involve moving .git
directories around in the checked out tree and perhaps making
symlinks and/or setting up various .git/config files by hand to
imitate what the final toolset would have done for the user,
which should be manageable.
^ permalink raw reply
* Re: [PATCH 1/3] Documentation: Clean up links in GIT Glossary
From: J. Bruce Fields @ 2007-05-25 23:50 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <11801326601014-git-send-email-jnareb@gmail.com>
On Sat, May 26, 2007 at 12:37:38AM +0200, Jakub Narebski wrote:
> Ensure that the same link is not repeated in single glossary entry,
> and that there is no self-link i.e. link to current entry.
>
> Add links to other definitions in git glossary.
>
> Remove inappropriate (nonsense) links, or change link to link to
> correct definition (to correct term).
>
> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Those look good to me!
--b.
^ permalink raw reply
* Re: [PATCH 2/3] Documentation: Add definition of "evil merge" to GIT Glossary
From: J. Bruce Fields @ 2007-05-26 0:14 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <1180132662719-git-send-email-jnareb@gmail.com>
On Sat, May 26, 2007 at 12:37:39AM +0200, Jakub Narebski wrote:
> +[[def_evil_merge]]evil merge::
> + An evil merge is a <<def_merge,merge>> that introduces changes that
> + do not appear in any <<def_parent,parent>>.
> +
I'm a little skeptical. This term doesn't appear to be used anywhere in
the current documentation, for example--are you sure it's worth
including at this point? I don't know--I just don't want to end up with
an entry for every piece of cute jargon that's been used as shorthand on
the mailing list a few times. But if you think it's sufficiently useful
and well-established, then OK.
--b.
^ permalink raw reply
* [PATCH] Add git-submodule command
From: Lars Hjemli @ 2007-05-26 0:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Linus Torvalds, git
In-Reply-To: <8c5c35580705251501u6346c27by1d133efc3d157bf2@mail.gmail.com>
This command can be used to initialize, update and inspect submodules. It
uses a .gitmodules file, readable by git-config, in the top level directory
of the 'superproject' to specify a mapping between submodule paths and
repository url. There is currently no way to override the mappings in the
.gitmodules file, except by manually creating the subproject repository.
Example .gitmodules layout:
[module "git"]
url = git://git.kernel.org/pub/scm/git/git.git
With this entry in .gitmodules (and a commit reference in the index entry for
the path "git"), the command 'git submodule init' will clone the repository
at kernel.org into the directory "git".
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
On 5/26/07, Lars Hjemli <hjemli@gmail.com> wrote:
> I'll redo the patch, removing the branch-specific things, and try to
> shut up :)
This is my final uttering ;-)
.gitignore | 1 +
Documentation/git-submodule.txt | 65 +++++++++++++++
Makefile | 2 +-
git-submodule.sh | 172 +++++++++++++++++++++++++++++++++++++++
4 files changed, 239 insertions(+), 1 deletions(-)
create mode 100644 Documentation/git-submodule.txt
create mode 100755 git-submodule.sh
diff --git a/.gitignore b/.gitignore
index 4dc0c39..8fc4923 100644
--- a/.gitignore
+++ b/.gitignore
@@ -126,6 +126,7 @@ git-ssh-push
git-ssh-upload
git-status
git-stripspace
+git-submodule
git-svn
git-svnimport
git-symbolic-ref
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
new file mode 100644
index 0000000..2135331
--- /dev/null
+++ b/Documentation/git-submodule.txt
@@ -0,0 +1,65 @@
+git-submodule(1)
+================
+
+NAME
+----
+git-submodule - Initialize, update or inspect submodules
+
+
+SYNOPSIS
+--------
+'git-submodule' [--quiet] [--cached] [status|init|update] [--] [<path>...]
+
+
+COMMANDS
+--------
+status::
+ Show the status of the submodules. This will print the sha1 of the
+ currently checked out commit for each submodule, along with the
+ submodule path and the output of gitlink:git-describe[1] for the
+ sha1. Each sha1 will be prefixed with '-' if the submodule is not
+ initialized and '+' if the currently checked out submodule commit
+ does not match the sha1 found in the index of the containing
+ repository. This command is the default command for git-submodule.
+
+init::
+ Initialize the submodules, i.e. clone the git repositories specified
+ in the .gitmodules file and checkout the submodule commits specified
+ in the index of the containing repository. This will make the
+ submodules HEAD be detached.
+
+update::
+ Update the initialized submodules, i.e. checkout the submodule commits
+ specified in the index of the containing repository. This will make
+ the submodules HEAD be detached.
+
+
+OPTIONS
+-------
+-q, --quiet::
+ Only print error messages.
+
+--cached::
+ Display the sha1 stored in the index, not the sha1 of the currently
+ checked out submodule commit. This option is only valid for the
+ status command.
+
+<path>::
+ Path to submodule(s). When specified this will restrict the command
+ to only operate on the submodules found at the specified paths.
+
+FILES
+-----
+When cloning submodules, a .gitmodules file in the top-level directory
+of the containing repository is used to find the url of each submodule.
+This file should be formatted in the same way as $GIR_DIR/config. The key
+to each submodule url is "module.$path.url".
+
+
+AUTHOR
+------
+Written by Lars Hjemli <hjemli@gmail.com>
+
+GIT
+---
+Part of the gitlink:git[7] suite
diff --git a/Makefile b/Makefile
index 29243c6..5cf2169 100644
--- a/Makefile
+++ b/Makefile
@@ -209,7 +209,7 @@ SCRIPT_SH = \
git-applymbox.sh git-applypatch.sh git-am.sh \
git-merge.sh git-merge-stupid.sh git-merge-octopus.sh \
git-merge-resolve.sh git-merge-ours.sh \
- git-lost-found.sh git-quiltimport.sh
+ git-lost-found.sh git-quiltimport.sh git-submodule.sh
SCRIPT_PERL = \
git-add--interactive.perl \
diff --git a/git-submodule.sh b/git-submodule.sh
new file mode 100755
index 0000000..247b1ee
--- /dev/null
+++ b/git-submodule.sh
@@ -0,0 +1,172 @@
+#!/bin/sh
+#
+# git-submodules.sh: init, update or list git submodules
+#
+# Copyright (c) 2007 Lars Hjemli
+
+USAGE='[--quiet] [--cached] [status|init|update] [--] [<path>...]'
+. git-sh-setup
+require_work_tree
+
+init=
+update=
+status=
+quiet=
+cached=
+
+#
+# print stuff on stdout unless -q was specified
+#
+say()
+{
+ if test -z "$quiet"
+ then
+ echo -e "$@"
+ fi
+}
+
+#
+# Run clone + checkout on missing submodules
+#
+# $@ = requested paths (default to all)
+#
+modules_init()
+{
+ git ls-files --stage -- $@ | grep -e '^160000 ' |
+ while read mode sha1 stage path
+ do
+ test -d "$path/.git" && continue
+
+ if test -d "$path"
+ then
+ rmdir "$path" 2>/dev/null ||
+ die "Directory '$path' exist, but not as a submodule"
+ fi
+
+ test -e "$path" &&
+ die "A file already exist at path '$path'"
+
+ url=$(GIT_CONFIG=.gitmodules git-config module."$path".url)
+ test -z "$url" &&
+ die "No url found for submodule '$path' in .gitmodules"
+
+ git-clone "$url" "$path" ||
+ die "Clone of submodule '$path' failed"
+
+ $(unset GIT_DIR && cd "$path" && git-checkout -q "$sha1") ||
+ die "Checkout of submodule '$path' failed"
+
+ say "Submodule '$path' initialized"
+ done
+}
+
+#
+# Checkout correct revision of each initialized submodule
+#
+# $@ = requested paths (default to all)
+#
+modules_update()
+{
+ git ls-files --stage -- $@ | grep -e '^160000 ' |
+ while read mode sha1 stage path
+ do
+ if ! test -d "$path/.git"
+ then
+ say "Submodule '$path' not initialized"
+ continue;
+ fi
+ subsha1=$(unset GIT_DIR && cd "$path" &&
+ git-rev-parse --verify HEAD) ||
+ die "Unable to find current revision of submodule '$path'"
+
+ if test "$subsha1" != "$sha1"
+ then
+ $(unset GIT_DIR && cd "$path" && git-fetch &&
+ git-checkout -q "$sha1") ||
+ die "Unable to checkout '$sha1' in submodule '$path'"
+
+ say "Submodule '$path': checked out '$sha1'"
+ fi
+ done
+}
+
+#
+# List all registered submodules, prefixed with:
+# - submodule not initialized
+# + different revision checked out
+#
+# If --cached was specified the revision in the index will be printed
+# instead of the currently checked out revision.
+#
+# $@ = requested paths (default to all)
+#
+modules_list()
+{
+ git ls-files --stage -- $@ | grep -e '^160000 ' |
+ while read mode sha1 stage path
+ do
+ if ! test -d "$path/.git"
+ then
+ say "-$sha1 $path"
+ continue;
+ fi
+ revname=$(unset GIT_DIR && cd "$path" && git-describe $sha1)
+ if git diff-files --quiet -- "$path"
+ then
+ say " $sha1 $path\t($revname)"
+ else
+ if test -z "$cached"
+ then
+ sha1=$(unset GIT_DIR && cd "$path" && git-rev-parse --verify HEAD)
+ revname=$(unset GIT_DIR && cd "$path" && git-describe $sha1)
+ fi
+ say "+$sha1 $path\t($revname)"
+ fi
+ done
+}
+
+while case "$#" in 0) break ;; esac
+do
+ case "$1" in
+ init)
+ init=1
+ ;;
+ update)
+ update=1
+ ;;
+ status)
+ status=1
+ ;;
+ -q|--quiet)
+ quiet=1
+ ;;
+ --cached)
+ cached=1
+ ;;
+ --)
+ break
+ ;;
+ -*)
+ usage
+ ;;
+ *)
+ break
+ ;;
+ esac
+ shift
+done
+
+case "$init,$update,$status,$cached" in
+1,,,)
+ modules_init $@
+ ;;
+,1,,)
+ modules_update $@
+ ;;
+,,*,*)
+ modules_list $@
+ ;;
+*)
+ usage
+ ;;
+esac
--
1.5.2.74.ga303
^ permalink raw reply related
* Re: [PATCH 2/3] Documentation: Add definition of "evil merge" to GIT Glossary
From: Jakub Narebski @ 2007-05-26 0:34 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git
In-Reply-To: <20070526001423.GF32073@fieldses.org>
J. Bruce Fields wrote:
> On Sat, May 26, 2007 at 12:37:39AM +0200, Jakub Narebski wrote:
>> +[[def_evil_merge]]evil merge::
>> + An evil merge is a <<def_merge,merge>> that introduces changes that
>> + do not appear in any <<def_parent,parent>>.
>> +
>
> I'm a little skeptical. This term doesn't appear to be used anywhere in
> the current documentation, for example--are you sure it's worth
> including at this point? I don't know--I just don't want to end up with
> an entry for every piece of cute jargon that's been used as shorthand on
> the mailing list a few times. But if you think it's sufficiently useful
> and well-established, then OK.
Currently only t/annotate-tests.sh uses "evil merge" term, but it is
I think quite commonly used in discussion.
Feel free to skip this patch, if you think it is not worth it, Junio.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Bug: git-rebase goofs up \n in commit messages
From: Jeff King @ 2007-05-26 0:40 UTC (permalink / raw)
To: Szekeres Istvan; +Cc: herbert, git
In-Reply-To: <465750FE.9000406@iii.hu>
On Fri, May 25, 2007 at 11:11:26PM +0200, Szekeres Istvan wrote:
> while playing with git I found the following bug: if a commit message
> contains "\n" (as a string, not as a character), git-rebase changes this
> string into a literal newline character.
Hmm. The culprit seems to be git-am.sh, line 313:
SUBJECT="$(sed -n '/^Subject/ s/Subject: //p' "$dotest/info")"
and even more exciting, it seems to be a bash vs dash thing. Try this:
$ cat >content-with-escapes <<'EOF'
foo \n bar
EOF
$ bash
bash$ test=$(cat content-with-escapes)
bash$ echo $test
foo \n bar
$ dash
dash$ test=$(cat content-with-escapes)
dash$ echo $test
foo
bar
Hmm. It even happens with this:
bash$ export test=$(echo foo \\n bar)
bash$ dash
dash$ echo $test
foo
bar
I'm not sure what the best workaround is. I am cc'ing Herbert Xu to see
if he has any helpful comments.
-Peff
^ permalink raw reply
* Re: [PATCH] Add git-submodule command
From: Johannes Schindelin @ 2007-05-26 0:48 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Junio C Hamano, Linus Torvalds, git
In-Reply-To: <11801386283399-git-send-email-hjemli@gmail.com>
Hi,
On Sat, 26 May 2007, Lars Hjemli wrote:
> On 5/26/07, Lars Hjemli <hjemli@gmail.com> wrote:
> > I'll redo the patch, removing the branch-specific things, and try to
> > shut up :)
>
> This is my final uttering ;-)
Don't be so shy. We're really making progress here, methinks.
Your version looks good to me.
Ciao,
Dscho "awaiting with impatience the test cases"
^ permalink raw reply
* Re: [PATCH 2/3] Documentation: Add definition of "evil merge" to GIT Glossary
From: Johannes Schindelin @ 2007-05-26 0:52 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <1180132662719-git-send-email-jnareb@gmail.com>
Hi,
On Sat, 26 May 2007, Jakub Narebski wrote:
> +[[def_evil_merge]]evil merge::
> + An evil merge is a <<def_merge,merge>> that introduces changes that
> + do not appear in any <<def_parent,parent>>.
Funny. For me, an evil merge is an octopus.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/3] Documentation: Add definition of "evil merge" to GIT Glossary
From: Shawn O. Pearce @ 2007-05-26 1:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0705260151320.4648@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> On Sat, 26 May 2007, Jakub Narebski wrote:
>
> > +[[def_evil_merge]]evil merge::
> > + An evil merge is a <<def_merge,merge>> that introduces changes that
> > + do not appear in any <<def_parent,parent>>.
>
> Funny. For me, an evil merge is an octopus.
Funny, for me an evil merge is 30 commits in a straight row, all
branch merges, when an octopus would be easier to read in gitk,
and easier to execute... ;-)
Actually, my definition of evil merge matches Jakub's definition.
--
Shawn.
^ permalink raw reply
* Re: Bug: git-rebase goofs up \n in commit messages
From: Herbert Xu @ 2007-05-26 1:10 UTC (permalink / raw)
To: Jeff King; +Cc: Szekeres Istvan, git
In-Reply-To: <20070526004028.GA8940@sigill.intra.peff.net>
On Fri, May 25, 2007 at 08:40:28PM -0400, Jeff King wrote:
>
> Hmm. It even happens with this:
>
> bash$ export test=$(echo foo \\n bar)
> bash$ dash
> dash$ echo $test
> foo
> bar
>
> I'm not sure what the best workaround is. I am cc'ing Herbert Xu to see
> if he has any helpful comments.
If you need to echo something that may have escapes in it, the portable
way to do it is
printf '%s\n' "$test"
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] Add git-submodule command
From: Junio C Hamano @ 2007-05-26 1:23 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Johannes Schindelin, Linus Torvalds, git
In-Reply-To: <11801386283399-git-send-email-hjemli@gmail.com>
Lars Hjemli <hjemli@gmail.com> writes:
> With this entry in .gitmodules (and a commit reference in the index entry for
> the path "git"), the command 'git submodule init' will clone the repository
> at kernel.org into the directory "git".
>
> Signed-off-by: Lars Hjemli <hjemli@gmail.com>
> ---
>
> On 5/26/07, Lars Hjemli <hjemli@gmail.com> wrote:
>> I'll redo the patch, removing the branch-specific things, and try to
>> shut up :)
Hey, don't shut up. Starting small and covering corner cases
incrementally is really the right approach.
> +status::
> + Show the status of the submodules. This will print the sha1 of the
> + currently checked out commit for each submodule, along with the
> + submodule path and the output of gitlink:git-describe[1] for the
> + sha1. Each sha1 will be prefixed with '-' if the submodule is not
> + initialized and '+' if the currently checked out submodule commit
> + does not match the sha1 found in the index of the containing
> + repository. This command is the default command for git-submodule.
(markup) probably you would want `` there for typewriter face.
(wording) didn't we have "the name of the hash function is
SHA-1" patch earlier? I'd personally prefer calling them
"object names", though...
Other than that, the command description is very nicely done,
which means the design of the command set hence the semantics is
cleanly done. Good job.
> diff --git a/git-submodule.sh b/git-submodule.sh
> new file mode 100755
> index 0000000..247b1ee
> --- /dev/null
> +++ b/git-submodule.sh
> @@ -0,0 +1,172 @@
> ...
> +#
> +# print stuff on stdout unless -q was specified
> +#
> +say()
> +{
> + if test -z "$quiet"
> + then
> + echo -e "$@"
> + fi
> +}
We tend to avoid "echo -e" (not POSIX). I do not see any string
you feed to this function that you would _want_ backslash
escaped sequences (actually I would suspect you would not want
them).
> +
> +#
> +# Run clone + checkout on missing submodules
> +#
> +# $@ = requested paths (default to all)
> +#
> +modules_init()
> +{
> + git ls-files --stage -- $@ | grep -e '^160000 ' |
Did you mean "$@", i.e. inside double-quotes?
Because this pattern would appear a lot in superproject support,
it might be a good idea to give a new option, --subprojects, to
git-ls-files to limit its output to 160000 entries, but that is
a minor detail.
> + while read mode sha1 stage path
> + do
We would need to undo the shell-safety "quoted" output of paths
here. I suspect it would be much easier to code this in Perl or
Python, do the "grep -e" part above in the script, when we start
caring about unwrapping c-quoting of path (or "ls-files -z").
But that is a minor detail we could fix up later.
> + test -d "$path/.git" && continue
> +
> + if test -d "$path"
> + then
> + rmdir "$path" 2>/dev/null ||
> + die "Directory '$path' exist, but not as a submodule"
> + fi
Could the currently checked-out $path be a symlink to another
directory, and what does the code do in such a case?
> +
> + test -e "$path" &&
> + die "A file already exist at path '$path'"
"test -e" is a relatively new invention and I tended to stay
away from it, but it should be safe to use these days...
> + url=$(GIT_CONFIG=.gitmodules git-config module."$path".url)
> + test -z "$url" &&
> + die "No url found for submodule '$path' in .gitmodules"
> +
> + git-clone "$url" "$path" ||
> + die "Clone of submodule '$path' failed"
"git-clone -n" please, as you will checkout something different
in the next step anyway.
> +
> + $(unset GIT_DIR && cd "$path" && git-checkout -q "$sha1") ||
> + die "Checkout of submodule '$path' failed"
Lose $() around this, as it is not producing a string which is
the name of the command to run. You do want a subshell here
because of chdir, so instead of losing $(), replace them with
().
> ...
> +modules_update()
> +{
>...
> + if test "$subsha1" != "$sha1"
> + then
> + $(unset GIT_DIR && cd "$path" && git-fetch &&
> + git-checkout -q "$sha1") ||
> + die "Unable to checkout '$sha1' in submodule '$path'"
Likewise.
^ permalink raw reply
* [PATCH] improve delta long block matching with big files
From: Nicolas Pitre @ 2007-05-26 1:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Martin Koegler noted that create_delta() performs a new hash lookup
after every block copy encoding which are currently limited to 64KB.
In case of larger identical blocks, the next hash lookup would normally
point to the next 64KB block in the reference buffer and multiple block
copy operations will be consecutively encoded.
It is however possible that the reference buffer be sparsely indexed if
hash buckets have been trimmed down in create_delta_index() when hashing
of the reference buffer isn't well balanced. In that case the hash
lookup following a block copy might fail to match anything and the fact
that the reference buffer still matches beyond the previous 64KB block
will be missed.
Let's rework the code so that buffer comparison isn't bounded to 64KB
anymore. The match size should be as large as possible up front and
only then should multiple block copy be encoded to cover it all.
Also, fewer hash lookups will be performed in the end.
According to Martin, this patch should reduce his 92MB pack down to 75MB
with the dataset he has.
Tests performed on the Linux kernel repo show a slightly smaller pack and
a slightly faster repack.
Signed-off-by: Nicolas Pitre <nico@cam.org>
diff --git a/diff-delta.c b/diff-delta.c
index 9f998d0..09e6bcd 100644
--- a/diff-delta.c
+++ b/diff-delta.c
@@ -246,7 +246,7 @@ create_delta(const struct delta_index *index,
const void *trg_buf, unsigned long trg_size,
unsigned long *delta_size, unsigned long max_size)
{
- unsigned int i, outpos, outsize, val;
+ unsigned int i, outpos, outsize, moff, msize, val;
int inscnt;
const unsigned char *ref_data, *ref_top, *data, *top;
unsigned char *out;
@@ -291,30 +291,33 @@ create_delta(const struct delta_index *index,
}
inscnt = i;
+ moff = 0;
+ msize = 0;
while (data < top) {
- unsigned int moff = 0, msize = 0;
- struct index_entry *entry;
- val ^= U[data[-RABIN_WINDOW]];
- val = ((val << 8) | *data) ^ T[val >> RABIN_SHIFT];
- i = val & index->hash_mask;
- for (entry = index->hash[i]; entry; entry = entry->next) {
- const unsigned char *ref = entry->ptr;
- const unsigned char *src = data;
- unsigned int ref_size = ref_top - ref;
- if (entry->val != val)
- continue;
- if (ref_size > top - src)
- ref_size = top - src;
- if (ref_size > 0x10000)
- ref_size = 0x10000;
- if (ref_size <= msize)
- break;
- while (ref_size-- && *src++ == *ref)
- ref++;
- if (msize < ref - entry->ptr) {
- /* this is our best match so far */
- msize = ref - entry->ptr;
- moff = entry->ptr - ref_data;
+ if (msize < 4096) {
+ struct index_entry *entry;
+ val ^= U[data[-RABIN_WINDOW]];
+ val = ((val << 8) | *data) ^ T[val >> RABIN_SHIFT];
+ i = val & index->hash_mask;
+ for (entry = index->hash[i]; entry; entry = entry->next) {
+ const unsigned char *ref = entry->ptr;
+ const unsigned char *src = data;
+ unsigned int ref_size = ref_top - ref;
+ if (entry->val != val)
+ continue;
+ if (ref_size > top - src)
+ ref_size = top - src;
+ if (ref_size <= msize)
+ break;
+ while (ref_size-- && *src++ == *ref)
+ ref++;
+ if (msize < ref - entry->ptr) {
+ /* this is our best match so far */
+ msize = ref - entry->ptr;
+ moff = entry->ptr - ref_data;
+ if (msize >= 4096) /* good enough */
+ break;
+ }
}
}
@@ -327,27 +330,13 @@ create_delta(const struct delta_index *index,
out[outpos - inscnt - 1] = inscnt;
inscnt = 0;
}
+ msize = 0;
} else {
+ unsigned int left;
unsigned char *op;
- if (msize >= RABIN_WINDOW) {
- const unsigned char *sk;
- sk = data + msize - RABIN_WINDOW;
- val = 0;
- for (i = 0; i < RABIN_WINDOW; i++)
- val = ((val << 8) | *sk++) ^ T[val >> RABIN_SHIFT];
- } else {
- const unsigned char *sk = data + 1;
- for (i = 1; i < msize; i++) {
- val ^= U[sk[-RABIN_WINDOW]];
- val = ((val << 8) | *sk++) ^ T[val >> RABIN_SHIFT];
- }
- }
-
if (inscnt) {
while (moff && ref_data[moff-1] == data[-1]) {
- if (msize == 0x10000)
- break;
/* we can match one byte back */
msize++;
moff--;
@@ -363,23 +352,40 @@ create_delta(const struct delta_index *index,
inscnt = 0;
}
- data += msize;
+ /* A copy op is currently limited to 64KB (pack v2) */
+ left = (msize < 0x10000) ? 0 : (msize - 0x10000);
+ msize -= left;
+
op = out + outpos++;
i = 0x80;
- if (moff & 0xff) { out[outpos++] = moff; i |= 0x01; }
- moff >>= 8;
- if (moff & 0xff) { out[outpos++] = moff; i |= 0x02; }
- moff >>= 8;
- if (moff & 0xff) { out[outpos++] = moff; i |= 0x04; }
- moff >>= 8;
- if (moff & 0xff) { out[outpos++] = moff; i |= 0x08; }
+ if (moff & 0x000000ff)
+ out[outpos++] = moff >> 0, i |= 0x01;
+ if (moff & 0x0000ff00)
+ out[outpos++] = moff >> 8, i |= 0x02;
+ if (moff & 0x00ff0000)
+ out[outpos++] = moff >> 16, i |= 0x04;
+ if (moff & 0xff000000)
+ out[outpos++] = moff >> 24, i |= 0x08;
- if (msize & 0xff) { out[outpos++] = msize; i |= 0x10; }
- msize >>= 8;
- if (msize & 0xff) { out[outpos++] = msize; i |= 0x20; }
+ if (msize & 0x00ff)
+ out[outpos++] = msize >> 0, i |= 0x10;
+ if (msize & 0xff00)
+ out[outpos++] = msize >> 8, i |= 0x20;
*op = i;
+
+ data += msize;
+ moff += msize;
+ msize = left;
+
+ if (msize < 4096) {
+ int j;
+ val = 0;
+ for (j = -RABIN_WINDOW; j < 0; j++)
+ val = ((val << 8) | data[j])
+ ^ T[val >> RABIN_SHIFT];
+ }
}
if (outpos >= outsize - MAX_OP_SIZE) {
^ permalink raw reply related
* [PATCH] update diff-delta.c copyright
From: Nicolas Pitre @ 2007-05-26 2:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
There is actually nothing left from the original LibXDiff code I used
over 2 years ago, and even the GIT implementation has diverged quite a
bit from LibXDiff's at this point. Let's update the copyright notice
to better reflect that fact.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
diff --git a/diff-delta.c b/diff-delta.c
index 09e6bcd..72b53d8 100644
--- a/diff-delta.c
+++ b/diff-delta.c
@@ -1,21 +1,14 @@
/*
* diff-delta.c: generate a delta between two buffers
*
- * Many parts of this file have been lifted from LibXDiff version 0.10.
- * http://www.xmailserver.org/xdiff-lib.html
+ * This code was greatly inspired by parts of LibXDiff from Davide Libenzi
+ * http://www.xmailserver.org/xdiff-lib.html
*
- * LibXDiff was written by Davide Libenzi <davidel@xmailserver.org>
- * Copyright (C) 2003 Davide Libenzi
+ * Rewritten for GIT by Nicolas Pitre <nico@cam.org>, (C) 2005-2007
*
- * Many mods for GIT usage by Nicolas Pitre <nico@cam.org>, (C) 2005.
- *
- * This file is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation; either
- * version 2.1 of the License, or (at your option) any later version.
- *
- * Use of this within git automatically means that the LGPL
- * licensing gets turned into GPLv2 within this project.
+ * This code is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
*/
#include "git-compat-util.h"
^ permalink raw reply related
* Re: git-svn and SVK mirror between two repositories
From: Vinubalaji Gopal @ 2007-05-26 3:26 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <4656464B.7010101@vilain.net>
Hi Sam,
On 5/24/07, Sam Vilain <sam@vilain.net> wrote:
> However, you are in a relatively obscure use case, most projects
> wouldn't do this. Note also that the merge tickets SVK would use are
hm I am not looking for a complete bidirectional flow. I have a
project (say my great open source project) in svn for which I have
only read access. Since I don't have a write access, I have a
personal svn sandbox for which I have complete read-write access and I
branch the trunk into this svn sandbox. I commit all my changes to my
sandbox so that I don't loose all my data in case my system fails! I
also setup a local branch to which I can commit when I don't have a
network access.
With Svk it has been (skipping the local branch step for now)
svk mirror <myproject_svn_url>/trunk //trunk
svk mirror <myproject_svn_sandbox_url>/mybranch //mybranch
svk smerge --baseless //trunk //mybranch -m 'first merge'
I also have a local branch in svk: (local branch setup)
svk copy //mybranch //localbranch -m 'local svk branch'
and occasionally enter the following commands to get the latest in trunk:
svk smerge //trunk //mybranch
or
svk smerge //mybranch //localbranch
>the UUID and revision numbers in the property will not refer to revisions in
>svn://svn.paris.fr/ but to the (private) SVN repository in the SVK depot.
that is scary since I am not sure if I still have that local repository now.
I would look into your patch suggestion for sure, but also open for
other suggestions . I am thinking if I should host the project in a
different public git server (for now) instead of my svn sandbox and
it will be easier :).
--
Vinu
In a world without fences who needs Gates?
^ permalink raw reply
* [PATCH] fixes to output of git-verify-pack -v
From: Nicolas Pitre @ 2007-05-26 3:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Now that the default delta depth is 50, it is a good idea to also bump
MAX_CHAIN to 50.
While at it, make the display a bit prettier by making the MAX_CHAIN
limit inclusive, and display the number of deltas that are above that
limit at the end instead of the beginning.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
diff --git a/pack-check.c b/pack-check.c
index d04536b..c168642 100644
--- a/pack-check.c
+++ b/pack-check.c
@@ -73,12 +73,11 @@ static int verify_packfile(struct packed_git *p,
}
-#define MAX_CHAIN 40
+#define MAX_CHAIN 50
static void show_pack_info(struct packed_git *p)
{
- uint32_t nr_objects, i, chain_histogram[MAX_CHAIN];
-
+ uint32_t nr_objects, i, chain_histogram[MAX_CHAIN+1];
nr_objects = p->num_objects;
memset(chain_histogram, 0, sizeof(chain_histogram));
@@ -109,22 +108,22 @@ static void show_pack_info(struct packed_git *p)
printf("%-6s %lu %"PRIuMAX" %u %s\n",
type, size, (uintmax_t)offset,
delta_chain_length, sha1_to_hex(base_sha1));
- if (delta_chain_length < MAX_CHAIN)
+ if (delta_chain_length <= MAX_CHAIN)
chain_histogram[delta_chain_length]++;
else
chain_histogram[0]++;
}
}
- for (i = 0; i < MAX_CHAIN; i++) {
+ for (i = 0; i <= MAX_CHAIN; i++) {
if (!chain_histogram[i])
continue;
- printf("chain length %s %d: %d object%s\n",
- i ? "=" : ">=",
- i ? i : MAX_CHAIN,
- chain_histogram[i],
- 1 < chain_histogram[i] ? "s" : "");
+ printf("chain length = %d: %d object%s\n", i,
+ chain_histogram[i], chain_histogram[i] > 1 ? "s" : "");
}
+ if (chain_histogram[0])
+ printf("chain length > %d: %d object%s\n", MAX_CHAIN,
+ chain_histogram[0], chain_histogram[0] > 1 ? "s" : "");
}
int verify_pack(struct packed_git *p, int verbose)
^ permalink raw reply related
* Re: Bug: git-rebase goofs up \n in commit messages
From: Jeff King @ 2007-05-26 3:42 UTC (permalink / raw)
To: Herbert Xu; +Cc: Junio C Hamano, Szekeres Istvan, git
In-Reply-To: <20070526011036.GA4169@gondor.apana.org.au>
On Sat, May 26, 2007 at 11:10:36AM +1000, Herbert Xu wrote:
> If you need to echo something that may have escapes in it, the portable
> way to do it is
>
> printf '%s\n' "$test"
Ah, I see. I had thought the problem was coming from some dash
interpolation magic, but yes, it's just echo doing the conversion. And
POSIX is very clear that this is an implementation defined behavior.
Thanks very much for the response, Herbert.
Junio, patch is below. I have no idea how prevalent this issue is within
our scripts, but this at least fixes the reported bug.
-- >8 --
git-am: use printf instead of echo on user-supplied strings
Under some implementations of echo (such as that provided by
dash), backslash escapes are recognized without any other
options. This means that echo-ing user-supplied strings may
cause any backslash sequences in them to be converted. Using
printf resolves the ambiguity.
This bug can be seen when using git-am to apply a patch
whose subject contains the character sequence "\n"; the
characters are converted to a literal newline. Noticed by
Szekeres Istvan.
Signed-off-by: Jeff King <peff@peff.net>
---
git-am.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index c9f66e2..543efd0 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -331,7 +331,7 @@ do
ADD_SIGNOFF=
fi
{
- echo "$SUBJECT"
+ printf '%s\n' "$SUBJECT"
if test -s "$dotest/msg-clean"
then
echo
@@ -394,7 +394,7 @@ do
fi
echo
- echo "Applying '$SUBJECT'"
+ printf 'Applying %s\n' "$SUBJECT"
echo
case "$resolved" in
--
1.5.2.818.g9b59-dirty
^ permalink raw reply related
* Re: Bug: git-rebase goofs up \n in commit messages
From: Junio C Hamano @ 2007-05-26 3:59 UTC (permalink / raw)
To: Jeff King; +Cc: Herbert Xu, Szekeres Istvan, git
In-Reply-To: <20070526034236.GA18169@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sat, May 26, 2007 at 11:10:36AM +1000, Herbert Xu wrote:
>
>> If you need to echo something that may have escapes in it, the portable
>> way to do it is
>>
>> printf '%s\n' "$test"
>
> Ah, I see. I had thought the problem was coming from some dash
> interpolation magic, but yes, it's just echo doing the conversion. And
> POSIX is very clear that this is an implementation defined behavior.
> Thanks very much for the response, Herbert.
>
> Junio, patch is below. I have no idea how prevalent this issue is within
> our scripts, but this at least fixes the reported bug.
Gaah. Ok, dash uses "echo -e" behaviour by default.
I guess we need to hunt allmost all "echo", as I suspect most of
them (except the ones we use to do "echo $SHA1") have user
strings somewhere.
What a mess, but that is not your fault nor Herbert's.
Thanks.
^ 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