* Re: [ANNOUNCE] gitfs pre-release 0.04
From: Jakub Narebski @ 2006-12-04 19:40 UTC (permalink / raw)
To: git
In-Reply-To: <20061204194011.GW47959@gaz.sfgoth.com>
Mitchell Blank Jr wrote:
> * At the top of each tree there's now a synthetic ".git" directory
> which includes some symlinks and a "HEAD" file that points to
> the currently viewed root. The idea is to allow some simple git
> commands to work inside of a gitfs directory. Unfortunately this doesn't
> work yet since git no longer recognizes a non-symbolic ref in "HEAD".
> I'll try to work around this soon.
Not true. Symlink HEAD still works, and we have even core.preferSymlinkRefs
configuration variable.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH 2/3] git-fetch: do not use "*" for fetching multiple refs
From: Michael Loeffler @ 2006-12-04 19:38 UTC (permalink / raw)
To: git
The trailing / is enough to decide if this should map everything under
refs/heads/ to refs/somewhere/.
The "*" should be reserved for the use as regex operator.
Signed-off-by: Michael Loeffler <zvpunry@zvpunry.de>
---
I want to use regular expressions to match remote refs, so I try to
implement this. But the current globfetch syntax needs the '*'.
Maybe it is not to late to change the syntax to this:
Pull: refs/heads/:refs/remotes/origin/
What do you think?
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index da064a5..38af4cb 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -101,13 +101,13 @@ expand_refs_wildcard () {
do
lref=${ref#'+'}
# a non glob pattern is given back as-is.
- expr "z$lref" : 'zrefs/.*/\*:refs/.*/\*$' >/dev/null || {
+ expr "z$lref" : 'zrefs/.*/:refs/.*/$' >/dev/null || {
echo "$ref"
continue
}
- from=`expr "z$lref" : 'z\(refs/.*/\)\*:refs/.*/\*$'`
- to=`expr "z$lref" : 'zrefs/.*/\*:\(refs/.*/\)\*$'`
+ from=`expr "z$lref" : 'z\(refs/.*/\):refs/.*/$'`
+ to=`expr "z$lref" : 'zrefs/.*/:\(refs/.*/\)$'`
local_force=
test "z$lref" = "z$ref" || local_force='+'
echo "$ls_remote_result" |
--
1.4.4
^ permalink raw reply related
* Re: latest update to git-svn blows up for me
From: Randal L. Schwartz @ 2006-12-04 19:36 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20061204181241.GA27342@soma>
>>>>> "Eric" == Eric Wong <normalperson@yhbt.net> writes:
Eric> "Randal L. Schwartz" <merlyn@stonehenge.com> wrote:
>> >>>>> "Eric" == Eric Wong <normalperson@yhbt.net> writes:
>>
Eric> "Randal L. Schwartz" <merlyn@stonehenge.com> wrote:
>> >>
>> >> Does this ring a bell?
>>
Eric> Nope.
>>
Eric> This is on r15941 of https://svn.perl.org/parrot/trunk ? I can't seem
Eric> to reproduce this with git svn fetch -r15940:15941
>>
>> No, and that worked for me as well. Apparently, I might have corrupted my
>> metadata because I updated git-svn while I was using it. Is there any way to
>> reset the metadata without having to re-fetch 15000 revisions?
Eric> rm .git/refs/remotes/$GIT_SVN_ID .git/svn/$GIT_SVN_ID/.rev_db
Eric> git svn -i $GIT_SVN_ID rebuild
That's not working:
localhost.local:..RROR/parrot-GITSVN % git-svn -i git-svn rebuild
fatal: 'origin': unable to chdir or not a git archive
fatal: unexpected EOF
Failed to find remote refs
256 at /opt/git/bin/git-svn line 2151
main::safe_qx('git-ls-remote', 'origin', 'refs/remotes/git-svn') called at /opt/git/bin/git-svn line 3404
main::copy_remote_ref() called at /opt/git/bin/git-svn line 226
main::rebuild() called at /opt/git/bin/git-svn line 187
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
^ permalink raw reply
* Re: Re: Moving a directory into another fails
From: Jakub Narebski @ 2006-12-04 19:37 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0612042009590.28348@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> On Mon, 4 Dec 2006, Jakub Narebski wrote:
>
>> Johannes Schindelin wrote:
>>
>>> On Mon, 4 Dec 2006, Jakub Narebski wrote:
>>>
>>>> [...] git should acquire core.filesystemEncoding configuration variable
>>>> which would encode from filesystem encoding used in working directory
>>>> and perhaps index to UTF-8 encoding used in repository (in tree objects)
>>>> and perhaps index.
>>>
>>> So, you want to pull in all thinkable encodings? Of course, you could rely
>>> on libiconv, adding yet another dependency to git. (Yes, I know, mailinfo
>>> uses it already. But I never use mailinfo, so I do not need libiconv.)
>>
>> A conditional dependency. If you don't have libiconv, this feature wouldn't
>> be available.
>
> You are speaking as somebody compiling git from source. We are a minority.
Usually iconv is in libc.
# Define NEEDS_LIBICONV if linking with libc is not enough (Darwin).
Hmm... perhaps not that usually. The uname based configuration in Makefile
(not the test based configuration provided by autoconf generated
./configure script) sets NEEDS_LIBICONV for: Darwin, SunOS 5.8, Cygwin,
FreeBSD and OpenBSD, some versions of NetBSD, AIX.
And HFS+ is on MacOS X / Darwin, without iconv in libc...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH 1/3] git-fetch: ignore dereferenced tags in expand_refs_wildcard
From: Michael Loeffler @ 2006-12-04 19:34 UTC (permalink / raw)
To: git
There was a little bug in the brace expansion which should remove
the ^{} from the tagname. It used ${name#'^{}'} instead of $(name%'^{}'},
the difference is that '#' will remove the given pattern only from the
beginning of a string and '%' only from the end of a string.
Signed-off-by: Michael Loeffler <zvpunry@zvpunry.de>
---
git-parse-remote.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index 19bc385..da064a5 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -116,7 +116,7 @@ expand_refs_wildcard () {
while read sha1 name
do
mapped=${name#"$from"}
- if test "z$name" != "z${name#'^{}'}" ||
+ if test "z$name" != "z${name%'^{}'}" ||
test "z$name" = "z$mapped"
then
continue
--
1.4.4
^ permalink raw reply related
* [ANNOUNCE] gitfs pre-release 0.04
From: Mitchell Blank Jr @ 2006-12-04 19:40 UTC (permalink / raw)
To: git
I've uploaded another pre-release of my gitfs tool. I haven't had much time
to work on it lately, so not much has changed since the last release a
year ago:
http://www.gelato.unsw.edu.au/archives/git/0511/12617.html
However that version no longer works (or even compiles against :-) the
FUSE API in recent linux kernels so I figured a fresh tarball would
be nice.
Changes:
* Added a configuration subsystem. Isn't used for much yet
* At the top of each tree there's now a synthetic ".git" directory
which includes some symlinks and a "HEAD" file that points to
the currently viewed root. The idea is to allow some simple git
commands to work inside of a gitfs directory. Unfortunately this doesn't
work yet since git no longer recognizes a non-symbolic ref in "HEAD".
I'll try to work around this soon.
* Various bug-fixes, etc
As usual tarballs are available at:
http://www.sfgoth.com/~mitch/linux/gitfs/
Sorry, I still haven't set up a git repository for it yet.
^ permalink raw reply
* Re: Re: Moving a directory into another fails
From: Johannes Schindelin @ 2006-12-04 19:10 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <el1rmm$bca$2@sea.gmane.org>
Hi,
On Mon, 4 Dec 2006, Jakub Narebski wrote:
> Johannes Schindelin wrote:
>
> > On Mon, 4 Dec 2006, Jakub Narebski wrote:
> >
> >> [...] git should acquire core.filesystemEncoding configuration variable
> >> which would encode from filesystem encoding used in working directory
> >> and perhaps index to UTF-8 encoding used in repository (in tree objects)
> >> and perhaps index.
> >
> > So, you want to pull in all thinkable encodings? Of course, you could rely
> > on libiconv, adding yet another dependency to git. (Yes, I know, mailinfo
> > uses it already. But I never use mailinfo, so I do not need libiconv.)
>
> A conditional dependency. If you don't have libiconv, this feature wouldn't
> be available.
You are speaking as somebody compiling git from source. We are a minority.
Ciao,
Dscho
^ permalink raw reply
* [RFC] Two conceptually distinct commit commands
From: Carl Worth @ 2006-12-04 19:08 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 10990 bytes --]
[
I think the proposal below is original, and more correctly captures
the essence of the "commit interface wart" than any previous
proposal I've made. This proposal is also based entirely on what is
useful for all git users, and what I perceive git's conceptual
models to be. That is, this proposal concerns what _I_, (as a fairly
experienced git user), actually want, without any bias for any
assumptions about what an imagined "new user" might want. Notably,
it does not try to satisfy naive (and likely incorrect) assumptions
about git's model.
Finally, this proposal intentionally uses ludicrously long command
names. This is because a discussion of realistically short names
triggers the two loaded issues of "muscle memory" and which concepts
get blessed as "defaults". In previous threads, those issues have
muddied the conceptual issues I'd like to focus on here. Let's talk
about the concepts first, and save discussions of naming for later
if necessary.
]
Proposal
-------
Here are the two commit commands I would like to see in git:
commit-index-content [paths...]
Commits the content of the index for the given paths, (or all
paths in the index). The index content can be manipulated with
"git add", "git rm", "git mv", and "git update-index".
commit-working-tree-content [paths...]
Commits the content of the working tree for the given paths, (or
all tracked paths). Untracked files can be committed for the first
time by specifying their names on the command-line or by using
"git add" to add them just prior to the commit. Any rename or
removal of a tracked file will be detected and committed
automatically.
Rationale summary
-----------------
These two commands capture a distinct conceptual split that is useful
for what users want to do with git. The split is necessary and
sufficient to provide access to four different useful pieces of commit
machinery. This is more functionality than in current git, and is
provided with more clarity.
The semantics of the two commands above are distinct enough that any
given tutorial introduction to git could outline a complete work-flow
by using only one or the other of the two commands, (or by presenting
one first and then expanding to the other).
The conceptual split here is necessary. In general, neither of the two
commands can be defined in terms of the other. This is independent of
the fact that commit-index-content is more core and provides shared
machinery for commit-working-tree-content. It is also independent of
the fact that commit-working-tree-content _can_ be defined in terms of
commit-index-content in the special case of the "all tracked paths"
form.
The two-way split here is also sufficient. It provides access to four
different, and useful, pieces of commit machinery. Of the four, only
three of these pieces currently exist in git. The new behavior is that
of "commit-index-content paths..." and is actually quite useful as
described in the detailed rationale below.
Finally, the two-way split here is simpler and more clear than the
three different commit commands currently provided by git, ("commit",
"commit paths...", and "commit -a"). The improved clarity comes from
taking advantage of the following standard command-line convention:
If optional arguments are omitted from a command, the command
is semantically equivalent to some default argument being
provided.
This convention is standard across many unix commands and is prevalent
in git itself, (such as commands like git-log defaulting to HEAD when
no revision specifier is provided). Note that this convention is not
followed by the current git-commit. The behavior of "git commit" and
"git commit paths..." involve distinct semantics. It is not the case
that "git commit" is equivalent to "git commit paths..." with some
default argument supplied. Violating this command-line convention is
unkind in general, but it also steals "space" from the command-line
for implementing the semantics of "git commit" with the application of
a <paths...> limit. This is discussed in more detail below.
So, by cleanly separating the two different useful git-commit
behaviors, and applying a standard command-line convention, we end up
with more functionality and less to teach. What's not to love? All
that would be missing is to come up with names for the two
commands. As I promised above, I'm going to avoid proposing any
binding of the concepts to realistic names here, but I will point out
that one of the "names" might very well be a command-line option
alteration of the other command.
Rationale details
-----------------
Although the conceptual split is only two commands, the actual
implementation of this functionality breaks down into four separate
internal behaviors, (based on whether doing "given paths" or "all
tracked paths"). Three of the four exist in git already, while the
fourth is new, (and also useful). Let's review each of the four along
with the names that git currently provides for them:
1. commit-index-content # all paths in the index
This functionality currently exists as "git commit" and is the
oldest and definitely the "most core" git commit command. Until
fairly recently, all other git commit commands could easily be
described as a variation of this functionality.
2. commit-index-content paths...
This functionality does not currently exist in any git commit
command, as far as I know. The behavior is to commit only a
(path-based) subset of the content that has been staged into the
index.
I was originally just going to say that this functionality "might
be useful in some cases", but coincidentally Alan Chandler
happened to request it just yesterday on the list:
I have been editing a set of files to make a commit, and after editing each
one had done a git update-index.
At this point I am just about to commit when I realise that one of the files
has changes in it that really ought to be a separate commit.
So effectively, I want to do one of three things
a) git-commit <that-file>
It's interesting to note that either of the two solutions
suggested in response to Alan might not work in general. For
example, "git reset", would not be a satisfactory solution if the
user had dirty content in any of the affected files compared to
what was staged in the index. Similarly, just removing the
safety-valve on the existing "git commit <that-file>" would commit
the wrong content if the working-tree contents of <that-file> were
dirty with respect to the index.
Now, it might still sound far-fetched to imagine wanting to commit
a subset of something staged in the index while also having dirty
content, but it occurs to me that I would actually _love_ to have
this capability. The case I would use it for is fairly common,
(and something that I think will speak to Junio who often brings
up a similar scenario).
Here's where I would like this functionality:
I receive a patch while I'm in the middle of doing other work,
(but with a clean index compared to HEAD, which is what I've
usually). The patch looks good, so I want to commit it right
away, but I do want to separate it into two or more pieces,
(commonly this is because I want to separate the "add a test
case demonstrating a bug" part from the "fix the bug"
part). So, if I could do:
git apply --index
git commit-index-content <files that add the test case>
git commit-index-content
Then this would do exactly what I want. I wouldn't even have
to think about whether my local modifications are to any of
the same paths as touched by the patch.
Today, in this scenario, what I have to do is to create a
temporary branch with a clean working tree, and then use the index
to stage the commit there. That process involves a few annoyances,
(stashing my dirty work, inventing a free name for the temporary
branch (which usually involves "git branch -D tmp"), switching back
when I'm done, and trying to remember to clean up the branch). The
new capability would let me skip _all_ of that overhead and
instead I could just delight in the beauty and power of the
index. Woo-hoo!
3. commit-working-tree-content # all tracked files
This functionality currently exists as "git commit -a" and, while
not _really_ old in git's history, its invention predates my
initial exposure to git. It has almost always been described in
terms of its implementation, ("first update the index for all
paths in the index, then commit that index").
One benefit of this description is that it forces the user to
learn about the index up front, (and gain a better understanding
of git's model). One cost is that the user is forced to learn a
two-stage implementation for a single-step process, (commit my
changes). I won't try to weigh the costs/benefits here, but
compare this to the description in (4) below.
4. commit-working-tree-content paths...
This functionality currently exists as "git commit paths..." and
is the newest variant of any git-commit command described here.
I think the evolution of what the semantics of the "git commit
paths..." command-line has been is very instructive. There was a
time when this command could be described in terms of a two-stage
manipulation of "the" index just like "commit -a" is described
today. That is:
Old: first update the index for all specified paths, then
commit the index".
But then the semantics were changed and the new description does
not involve the index at all:
New: Commit only the files specified on the command line.
The old behavior is still available with the --include option, but
nobody has ever come out in favor of that being a useful command,
(I agree it is not useful at all). Meanwhile, the new (default)
behavior as been strongly identified by Linus as extremely
useful. Junio has recently noticed that the old --index behavior
is more conceptually consistent with the classic, commit-the-index
definition of the core "git commit", but that's not sufficient
justification for promoting functionality that would never be
useful.
So the evolution of the current "commit paths..." shows utility of
functionality being a primary concern in defining the semantics of
git commands. And that's wonderful.
In my opinion, what has happened with the evolution of "commit paths"
and "commit -a" is that a new conceptual commit behavior has been
invented, (what I've termed commit-working-tree-content), but it
hasn't been recognized yet as separate from the core
commit-index-content nature of "git commit". And there's some muddling
in that simply adding a <paths..> argument to "git commit" completely
changes its semantics, (which violates the command-line convention I
described above).
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Re: Moving a directory into another fails
From: Jakub Narebski @ 2006-12-04 19:10 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0612042001320.28348@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> On Mon, 4 Dec 2006, Jakub Narebski wrote:
>
>> [...] git should acquire core.filesystemEncoding configuration variable
>> which would encode from filesystem encoding used in working directory
>> and perhaps index to UTF-8 encoding used in repository (in tree objects)
>> and perhaps index.
>
> So, you want to pull in all thinkable encodings? Of course, you could rely
> on libiconv, adding yet another dependency to git. (Yes, I know, mailinfo
> uses it already. But I never use mailinfo, so I do not need libiconv.)
A conditional dependency. If you don't have libiconv, this feature wouldn't
be available.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Re: Moving a directory into another fails
From: Johannes Schindelin @ 2006-12-04 19:03 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <el1qtr$bca$1@sea.gmane.org>
Hi,
On Mon, 4 Dec 2006, Jakub Narebski wrote:
> [...] git should acquire core.filesystemEncoding configuration variable
> which would encode from filesystem encoding used in working directory
> and perhaps index to UTF-8 encoding used in repository (in tree objects)
> and perhaps index.
So, you want to pull in all thinkable encodings? Of course, you could rely
on libiconv, adding yet another dependency to git. (Yes, I know, mailinfo
uses it already. But I never use mailinfo, so I do not need libiconv.)
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Michael K. Edwards @ 2006-12-04 18:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Josef Weidendorfer, sf, git, Martin Waitz
In-Reply-To: <Pine.LNX.4.64.0612011621380.3695@woody.osdl.org>
(I wrote most of this a couple of days ago, so it's not at the tip of
the conversational tree, so to speak. But it's effectively a response
to Linus's "what do you want to do with submodules" question, with
some thoughts on implementation. Sorry it's so long; like Blaise
Pascal, "I would have written a shorter letter, but I did not have the
time.")
The supermodule concept, implemented right, could really improve
cooperation among embedded platform integrators, boutique distro
publishers, and other editorial contributors to sprawling metaprojects
who don't want to run kernel.org-scale mirrors. To make this work,
you need sparse repositories (conserving resources when fetching, by
omitting the bulk of currently un-needed submodules that can reliably
be obtained later from elsewhere) and shallow cloning (conserving
resources when publishing, by referring cloners to a third-party
repository for universally available content).
For instance, it would be a wonderful thing if the pile-o-patches
nightmare that is PTXdist (and crosstool and buildtool and every other
approach I have seen for ongoing maintenance of embedded toolchains
and userlands) were obsoleted by a git supermodule. Its submodules
would mostly track external projects, but would also logically contain
the fix-up patches worked out during platform integration, checked in
to branches anchored at each upstream release point. The supermodule
would contain all of the build automation, log auditing, and remote
unit testing stuff, as well as the metadata for each submodule
involved in this platform build cycle.
At a content level, the sparsely populated / shallowly published
supermodule wouldn't be much different from today's PTXdist. But the
pay-off comes when you merge forward to a new release of some base
component (compiler, library, etc.) and discover that some of your
fix-ups have been adopted or obsoleted upstream, and new fix-ups are
needed for components that depend on the updated bit, and the set of
configurables has changed (for which you need to compensate in the
meta-configurator). Instead of piling up versioned patch directories,
you commit fix-ups to the sub-modules, which other integration
branches can ignore (if they aren't affected), merge, or cherry-pick.
As I understand it, in today's git, every content object is a patch to
the _data_ of one and only one git repository, containing the label of
the preceding _data_ state plus a diff of file contents and
attributes. Assuming this model is retained, any clean state of a
"leaf" module (one with no submodules) can be reached by replaying a
series of patches, starting from the repository's root node (an empty
directory with the hopefully unique label generated by init-db). The
label (SHA1) of the last patch is therefore a perfectly good label for
this _data_ state.
If all we were trying to do with supermodules was to capture and track
various states of the submodules' data, we could extend the format of
content objects to include "state X of submodule with init-db label
Y". That would have the effect of capturing submodule states as
_data_ in non-"leaf" modules. We would have to help cloners find a
place from which to pull these states, of course; and it's easy to get
sidetracked onto that part of the problem. But that's not where the
bang for the buck is in supermodules.
The whole model of distributed supermodules, with references to
slightly diverging submodules whose content should mostly be fetched
from external sources, smells to me just like LVM. The external
sources (like an LVM volume of which you have taken a "snapshot") make
up the bulk of the content pool. They also give you a window into
developments on the submodule's own branches (like being able to peek
forward and merge changes from the original volume). The supermodule
(the snapshot volume) provides most of the interesting refs (submodule
commits referenced by supermodule tags and branch heads), along with
enough "journaled" content to replay forward from some checkpoint
guaranteed to be available in each external source to any of these
refs.
The implication here is that submodule states are not just SHA1 labels
to be embedded within supermodule data diffs. One ought to be able to
clone a supermodule without immediately cloning full copies of any of
its submodules. This ought to populate the clone's content database
with all of the quanta of submodule content that aren't guaranteed to
be available from any not-too-stale submodule mirror. When cloning,
you don't want to have to inspect every supermodule state for
submodule states that are outside the global subset. So the
supermodule needs to maintain a set of supplemental refs from which
all referenced submodule states can be reached. This allows you to
traverse the portion of the pool of submodule content that can't be
reached from true submodule branch heads.
On 12/1/06, Linus Torvalds <torvalds@osdl.org> wrote:
> Yes, you do need to have a list of submodules somewhere, and you'd need to
> maintain that separately. One of the results of having the submodules be
> independent from the supermodule is that it's not all "automatically
> integrated", and thus the supermodule does end up having to have things
> like that maintained separately.
This is not a defect; it's a virtue. It's important for every commit
to the supermodule to contain the information of which submodule
branches you're currently on and how far along them you've crawled.
Any particular supermodule commit point is likely to reflect an
integration milestone visible only to the person working at the
supermodule level. No content object should ever cross a submodule
boundary, because then you wouldn't be able to apply it to the
submodule in isolation (or in another supermodule state) or identify
it when it is applied upstream and propagates back to you in a pull.
But the supermodule can also contain supplemental refs (heads and
tags) that don't exist in the submodule (and shouldn't necessarily be
pushed to it); the commits they refer to are localized to the
submodule but may not be reachable from any of the submodule's branch
heads.
> And yes, if you screw that up, you wouldn't be able to fetch submodules
> properly etc, even if you see the supermodule, and yes, this sounds more
> like the CVS "Entries" kind of file that is more "tacked on" than really
> deeply integrated. But I think the separation is _more_ than worth the
> fact that you can see things being separate.
There is an opportunity for useful deep integration here. The same
algorithm that does reachability analysis for "git prune" can dig from
supermodule down to submodules, copying objects into the supermodule
database until it hits a commit that is advertised as "global" by the
submodule. "git clone" of the supermodule can then pull the bulk of
the submodules (a superset of the "global" subset) from (a mirror of)
the canonical place for each, and use the supermodule object database
as an alternate source for commits that don't exist in the "canonical"
submodule.
> In fact, I'm very much arguing for keeping things as separate as possible,
> while just integrating to the smallest possible degree (just _barely_
> enough that you can do things like "git clone" and it will fetch multiple
> repositories and put them all in the right places, and "git diff" and
> friends will do reasonably sane things).
>
> Keep it simple, stupid.
As simple as possible; but no simpler. The "alternates" / "git clone
--reference" model is already almost powerful enough for the
supermodule to contain a "journal" of submodule commits that haven't
yet been retired to the canonical subset (guaranteed present in each
mirror). The only difference is that the supermodule should be
considered a "weak alternates" source. Commit objects in the
supermodule's database should be visible to submodule-level operations
(so that commits which are accepted upstream get flowed in nicely
during "git pull").
But if a commit becomes reachable from a ref that is really in the
submodule (not just one of the supermodule's "supplemental refs",
which should _not_ be visible to submodule operations), then it should
be copied into the submodule's object database. (The refs internal to
the submodule should retain their integrity even if the supermodule is
inaccessible.) The existing "strong alternates" mechanism should be
reserved for repos which are at least as public and persistent as the
submodule, and supermodules don't qualify (e. g., Linus's transmeta
scenario).
> On Sat, 2 Dec 2006, Josef Weidendorfer wrote:
> > The thing I wanted to discuss is whether such names would need to be globally
> > unique in the project containing submodles, or not.
>
> My preference would be for it to be "local", just because (as I
> mentioned), with mirroring etc, it might well be that you want to fetch
> things from the _closest_ repository. That's really not a global decision,
> it's a local one.
I think "global resource, local provider" is the way to go, with each
provider advertising what checkpoints of what resources it can supply.
When I clone or pull, I should be able to consult a local mapping of
submodule URIs to "mirrors" (which may well be local repositories
containing content and branches that aren't in the "official"
upstream). The only thing that may need "global" agreement is the
boundaries of the "global" subset for each submodule, i. e., the set
of commit objects that can reliably be obtained from any mirror of the
"official" upstream repository. That doesn't need to be terribly
clever; "at least three days old on a globally published branch" would
probably be a perfectly good heuristic.
> > If yes, it IMHO makes a lot of sense to introduce "submodule objects" which contain
> > these submodule names, and which are used as pointers to submodule commits in
> > supermodule trees.
>
> You could do it that way, and then it would be global. It would work, and
> in many ways it would probably be "simpler" on a supermodule level.
I think the implication of "submodule objects" is that supermodule
diffs would say "roll submodule X from commit-id A to commit-id B". I
don't think that would work very well for pulls/merges in the sparsely
populated scenario, because you want to be able to pull the
non-canonical subset of the individual diffs between states A and B
into the supermodule's object pool. When you decide later to flesh
out submodule X, you should only have to clone some canonical mirror
and then fast-forward to state B using objects you already have in the
supermodule pool.
The merge case is even clearer. Suppose I pull updates from two
remote branches of the supermodule onto my master branch. Each remote
branch has added the same submodule, cloned from third-party
repositories whose clone history goes back to the same origin. (The
example I have in mind is when some project switches to git from some
other SCM, and the maintainers of the remote branches port their
integration patches over from their git-svn tracker submodule to a
clone of upstream's new git repo.) I should be able to postpone the
merge effort, come back later and clone the upstream repo, then merge
the non-canonical commits that were pulled earlier.
I might want to decide at supermodule pull time to postpone pulling
the bodies of the submodule commits; but I want the full sequence of
submodule commit IDs in the supermodule commit object. So it's not so
much the supermodule _state_ that has a hierarchical structure; it's
the supermodule _diffs_ and _object_pool_ that become hierarchical.
> The advantage of a global namespace is that you can much more easily
> update it - "git fetch" will just fetch the new file(s) that describe the
> subprojects very naturally if they are all global. Putting them in a local
> .git/config file has it's advantages (see above), but it also makes it
> very hard to version them, and to update the list - it would have to
> become manual.
I think the only global-to-local-namespace mapping applies to the
different labels for the "empty repository" state generated at init-db
time. Given the init-db SHA1 of the linux kernel repository, I should
be able to choose any mirror or clone of that repository as a source
for objects in its "global set". I expect this provider not to
scribble on globally published branches, but that isn't even all that
critical; anything outside the canonical set is kept in the
supermodule's object pool, so I can always blow the submodule away and
regenerate it from a different mirror.
> There are possibly combinations of the two approaches: have a "global
> namespace" that describes the canonical place to get the subprojects, but
> have some way to add local "translation" of the canonical names into
> locally preferred versions (eg you could just have a way to say "this is
> the local mirror for that global canonical place")
>
> Maybe that would work?
Sure. But all you really need from the canonical place is its init-db
SHA1 (permanent) and its list of globally published branches
(monotonically expanding). A URL for it is a convenient shorthand but
doesn't have to be persistent.
Cheers,
^ permalink raw reply
* Re: Re: Moving a directory into another fails
From: Jakub Narebski @ 2006-12-04 18:56 UTC (permalink / raw)
To: git
In-Reply-To: <f3d7535d0612041019q4bda01a1k9938b056d51f8a78@mail.gmail.com>
Stefan Pfetzing wrote:
> 2006/7/28, Petr Baudis <pasky@suse.cz>:
>>>
>>> mv: cannot stat `"gitweb/test/M\\303\\244rchen"': No such file or directory
>>>
> since when is this file in the official git.git tree?
Since merging in gitweb, Sat Jun 10, 2006.
> Its quite problematic when used on HFS+ because it uses UTF-16 internally IMHO.
>
> Git always thinks there is a new file in my git.git clone.
That is the problem that git tries to be content agnostict, and it
includes being coding agnostic.
I personally think that because the same repository might be deployed
on different systems with different file name encoding (and this is not
something you have control over, contrary to commit/tag message encoding,
and encoding in files), git should acquire core.filesystemEncoding
configuration variable which would encode from filesystem encoding used
in working directory and perhaps index to UTF-8 encoding used in repository
(in tree objects) and perhaps index.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Print progress message to stderr, not stdout
From: Marco Costalba @ 2006-12-04 18:34 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Catalin Marinas, git
In-Reply-To: <20061204153705.GA8644@diana.vm.bytemark.co.uk>
On 12/4/06, Karl Hasselström <kha@treskal.com> wrote:
> On 2006-12-04 09:17:16 +0000, Catalin Marinas wrote:
>
> > On 02/12/06, Marco Costalba <mcostalba@gmail.com> wrote:
> >
> > > On 11/11/06, Karl Hasselström <kha@treskal.com> wrote:
> > >
> > > > Printing progress messages to stdout causes them to get mixed up
> > > > with the actual output of the program. Using stderr is much
> > > > better, since the user can then redirect the two components
> > > > separately.
> > >
> > > This patch breaks qgit.
> >
> > Since there are other tools relying on a clean stderr, I think I
> > would revert it and add a verbose flag and/or config option. Karl,
> > any thoughts on this (since you sent the patch)?
>
> I introduced this since I wanted to divert the output to a file, and
> the progress message had no business being written to that file. But a
> command line option to suppress progress messages would work just as
> well if that's what git does.
>
If you don't mind I would prefer a command line option to _enable_
progress messages, something like -v or --verbose so to keep back
compatibility with current versions of tools that do not expect stderr
messages.
Thanks
^ permalink raw reply
* Re: egit/jgit wishlist
From: Shawn Pearce @ 2006-12-04 18:29 UTC (permalink / raw)
To: Grzegorz Kulewski; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0612041841280.14187@alpha.polcom.net>
Grzegorz Kulewski <kangur@polcom.net> wrote:
> I think that doing it in 100% pure Java is ok in long run but I wonder if
> you couldn't make "wrapper" plugin for a start (that would call the real C
> git for every operation) and make it usable (with full pure Java SWT UI
> support) and then try to implement feature by feature in pure Java (with
> config options telling what should be called by wrapper and what by pure
> implementation)?
Several people have proposed doing exactly that, but thus far
myself and Robin Rosenburg have been the only two to step forward
with code. I personally want to avoid calling external programs
as much as possible here, and that means staying with a 100% pure
Java implementation. Hence the desire to not build a wrapper plugin.
We have the core repository reading and writing working. We can
write out trees. We can create commits (we just lack UI for it).
So we're part of the way there...
--
^ permalink raw reply
* [PATCH] gitweb: Better symbolic link support in "tree" view
From: Jakub Narebsmi @ 2006-12-04 18:26 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
From: Jakub Narebski <jnareb@gmail.com>
In "tree" view (git_print_tree_entry subroutine), add for symbolic
links after file name " -> link_target", a la "ls -l". Use
git_get_link_target_html to escape target name and make it into
hyperlink if possible.
Target of link is made into hyperlink when:
* hash_base is provided (otherwise we cannot find hash of link
target)
* link is relative
* in no place link goes out of root tree (top dir)
* target of link exists for hash_base
Full path of symlink target from the root dir is provided in the title
attribute of hyperlink. If symlink target is a directory, '/' is added
to end of path in title attribute.
Currently symbolic link name uses ordinary file style (hidden
hyperlink), while the hyperlink to symlink target uses default
hyperlink style.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 91 +++++++++++++++++++++++++++++++++++++++++++++++----
1 files changed, 83 insertions(+), 8 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index ffe8ce1..3c1b75d 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1989,12 +1989,83 @@ sub git_print_log ($;%) {
}
}
+# print link tree entry (name of what link points to, possibly hyperlink)
+sub git_get_link_target_html {
+ my ($t, $basedir, $hash_base) = @_;
+
+ my $fd;
+ my %target = ();
+
+ # read link
+ open $fd, "-|", git_cmd(), "cat-file", "blob", $t->{'hash'};
+ {
+ local $/;
+ $target{'orig'} = <$fd>;
+ }
+ close $fd;
+
+ # we can make hyperlink out of link target only if $hash_base is provided
+ return esc_path($target{'orig'})
+ unless $hash_base;
+
+ # absolute links are returned as is, no hyperlink
+ if (substr($target{'orig'}, 0, 1) eq '/') {
+ return esc_path($target{'orig'});
+ }
+
+ # normalize link target to path from top (root) tree (dir)
+ if ($basedir) {
+ $target{'path'} = $basedir . '/' . $target{'orig'};
+ } else {
+ # we are in top (root) tree (dir)
+ $target{'path'} = $target{'orig'};
+ }
+ $target{'parts'} = [ ];
+ foreach my $part (split('/', $target{'path'})) {
+ # discard '.' and ''
+ next if (!$part || $part eq '.');
+ # handle '..'
+ if ($part eq '..') {
+ if (@{$target{'parts'}}) {
+ pop @{$target{'parts'}};
+ } else {
+ # link leads outside repository
+ return esc_path($target{'orig'});
+ }
+ } else {
+ push @{$target{'parts'}}, $part;
+ }
+ }
+ $target{'path'} = join('/', @{$target{'parts'}});
+
+ # check if path exists
+ open $fd, "-|", git_cmd(), "ls-tree", $hash_base, "--", $target{'path'}
+ or return esc_path($target{'orig'});
+ my $line = <$fd>;
+ close $fd
+ or return esc_path($target{'orig'});
+ return esc_path($target{'orig'}) unless $line;
+
+ # parse ls-tree line to get type and hash of target of link
+ (undef, $target{'type'}, $target{'hash'}) =
+ ($line =~ m/^([0-9]+) (.+) ([0-9a-fA-F]{40})\t/);
+
+ # make a link if path exists
+ return $cgi->a({-href => href(action => $target{'type'},
+ hash => $target{'hash'},
+ file_name => $target{'path'},
+ hash_base => $hash_base),
+ -title => $target{'path'} .
+ ($target{'type'} eq "tree" ? '/' : '')},
+ esc_path($target{'orig'}));
+}
+
# print tree entry (row of git_tree), but without encompassing <tr> element
sub git_print_tree_entry {
my ($t, $basedir, $hash_base, $have_blame) = @_;
my %base_key = ();
- $base_key{hash_base} = $hash_base if defined $hash_base;
+ $base_key{'hash_base'} = $hash_base if defined $hash_base;
# The format of a table row is: mode list link. Where mode is
# the mode of the entry, list is the name of the entry, an href,
@@ -2005,16 +2076,20 @@ sub git_print_tree_entry {
print "<td class=\"list\">" .
$cgi->a({-href => href(action=>"blob", hash=>$t->{'hash'},
file_name=>"$basedir$t->{'name'}", %base_key),
- -class => "list"}, esc_path($t->{'name'})) . "</td>\n";
+ -class => "list"}, esc_path($t->{'name'}));
+ if (S_ISLNK(oct $t->{'mode'})) {
+ print " -> " . git_get_link_target_html($t, $basedir, $hash_base);
+ }
+ print "</td>\n";
print "<td class=\"link\">";
print $cgi->a({-href => href(action=>"blob", hash=>$t->{'hash'},
- file_name=>"$basedir$t->{'name'}", %base_key)},
- "blob");
+ file_name=>"$basedir$t->{'name'}", %base_key)},
+ "blob");
if ($have_blame) {
print " | " .
$cgi->a({-href => href(action=>"blame", hash=>$t->{'hash'},
- file_name=>"$basedir$t->{'name'}", %base_key)},
- "blame");
+ file_name=>"$basedir$t->{'name'}", %base_key)},
+ "blame");
}
if (defined $hash_base) {
print " | " .
@@ -2036,8 +2111,8 @@ sub git_print_tree_entry {
print "</td>\n";
print "<td class=\"link\">";
print $cgi->a({-href => href(action=>"tree", hash=>$t->{'hash'},
- file_name=>"$basedir$t->{'name'}", %base_key)},
- "tree");
+ file_name=>"$basedir$t->{'name'}", %base_key)},
+ "tree");
if (defined $hash_base) {
print " | " .
$cgi->a({-href => href(action=>"history", hash_base=>$hash_base,
--
1.4.4.1
^ permalink raw reply related
* Re: Re: Moving a directory into another fails
From: Stefan Pfetzing @ 2006-12-04 18:19 UTC (permalink / raw)
To: git
In-Reply-To: <20060728014350.GI13776@pasky.or.cz>
Hi Folks,
2006/7/28, Petr Baudis <pasky@suse.cz>:
> > mv: cannot stat `"gitweb/test/M\\303\\244rchen"': No such file or directory
since when is this file in the official git.git tree?
Its quite problematic when used on HFS+ because it uses UTF-16 internally IMHO.
Git always thinks there is a new file in my git.git clone.
--- snip ---
dreamind@paris:~/src/git% git status
# Untracked files:
# (use "git add" to add to commit)
#
# gitweb/test/MaÌrchen
nothing to commit
--- snap ---
bye
dreamind
--
http://www.dreamind.de/
^ permalink raw reply
* Re: egit/jgit wishlist
From: Grzegorz Kulewski @ 2006-12-04 18:16 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061204172836.GB6011@spearce.org>
On Mon, 4 Dec 2006, Shawn Pearce wrote:
> I've started a wishlist:
>
> http://git.or.cz/gitwiki/EclipsePluginWishlist
>
> My idea is to work through these in the order shown on the page.
> I'm looking for comments from those who may be interested in this
> plugin, to see what they want/need to make it useful.
>
> There's many months worth of work listed there, especially with
> the amount of time that I have available for jgit/egit. So I'm of
> course also hoping that others might see something there and try
> to implement it themselves. :-)
Hi,
I am interested in seeing GIT support in Eclipse.
I think that doing it in 100% pure Java is ok in long run but I wonder if
you couldn't make "wrapper" plugin for a start (that would call the real C
git for every operation) and make it usable (with full pure Java SWT UI
support) and then try to implement feature by feature in pure Java (with
config options telling what should be called by wrapper and what by pure
implementation)?
This way we could probably rather fast (basic versions of other GIT UIs
were created rather fast IIRC) have basic support for GIT (preferably
with GIT Java wrapper library for other projects) that would be usable for
most users and this way you could gain more interest in the project. Also
testing new pure implementation would be a lot easier (changing one line
in config file to enable some pure Java feature and of course having an
option to come back to wrapped version of this feature if new pure
implementation was wrong).
What do you think about it?
Thanks,
Grzegorz Kulewski
^ permalink raw reply
* Re: egit/jgit wishlist
From: Shawn Pearce @ 2006-12-04 18:05 UTC (permalink / raw)
To: Steven Grimm; +Cc: git
In-Reply-To: <457461BF.6080706@midwinter.com>
Steven Grimm <koreth@midwinter.com> wrote:
> My usual git working style is to not switch branches with a dirty
> working directory; I always commit to the current branch before
> switching to a new one. I mention that because I assume it'll be easier
> to implement that workflow first; once you have commit capability, you
> can do that style of branch switching (either preventing the switch or
> doing an implicit commit when the working directory is dirty) without
> having to worry about merging.
It is easier to code. :-)
But users have come to expect the three-way merge during branch
switches. I actually get ticked when it fails, because that is
usually when I need it most. Anyway, I also know a number of
Eclipse users who also use Git that would prefer it if the switch
fails on a dirty working tree, as that usually just means they
forgot to commit their changes first.
> And finally, it would be swell -- but put it at the bottom of your
> priority list -- to have git-svn interoperability; sadly most of my git
> usage at the moment is in cloned svn repositories and it would be great
> if egit could do the right thing when the current git repo is cloned
> from svn. What "the right thing" is, exactly, is debatable, but I
> suppose some kind of integration with the Subclipse plugin is one
> possibility (and if nothing else, that plugin probably has code that can
> be reused.) I'd like to be able to update from and commit to the parent
> svn repository.
SVN integration is probably out of scope for the plugin (at least
right now) but I won't reject any reasonable patches! (hint hint)
:-)
--
^ permalink raw reply
* Re: selective git-update-index per diff(1) chunks
From: Jakub Narebski @ 2006-12-04 18:05 UTC (permalink / raw)
To: git
In-Reply-To: <20061204173318.GG940MdfPADPa@greensroom.kotnet.org>
Sven Verdoolaege wrote:
> On Fri, Dec 01, 2006 at 02:23:14PM +0300, Alexey Dobriyan wrote:
>> Has anyone thought about aggregating this into git-update-index or
>> somewhere?
>>
>> git-update-index -C1,3 #chunks 1, 3
>> git commit
>> git-update-index -C1,3 # chunks 2,5 in original numbering
>> git commit
>>
>> Relying on diff(1) definition of chunks is sorta hacky, though... I admit
>> it.
>
> Paul Mackerras modified his dirdiff tool to do something like this.
> I have a couple of patches on top of his version from way back at
> http://www.liacs.nl/~sverdool/gitweb.cgi?p=dirdiff.git;a=summary
>
> I don't know if he has continued working on this.
If this has support for git, could you add it to GitWiki:
http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
And perhaps also update related page
http://git.or.cz/gitwiki/InterfacesFrontendsAndToolsWishlist
Thanks in advance.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: egit/jgit wishlist
From: Steven Grimm @ 2006-12-04 17:58 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061204172836.GB6011@spearce.org>
I am definitely looking forward to a usable Eclipse plugin! A few comments:
My usual git working style is to not switch branches with a dirty
working directory; I always commit to the current branch before
switching to a new one. I mention that because I assume it'll be easier
to implement that workflow first; once you have commit capability, you
can do that style of branch switching (either preventing the switch or
doing an implicit commit when the working directory is dirty) without
having to worry about merging.
And finally, it would be swell -- but put it at the bottom of your
priority list -- to have git-svn interoperability; sadly most of my git
usage at the moment is in cloned svn repositories and it would be great
if egit could do the right thing when the current git repo is cloned
from svn. What "the right thing" is, exactly, is debatable, but I
suppose some kind of integration with the Subclipse plugin is one
possibility (and if nothing else, that plugin probably has code that can
be reused.) I'd like to be able to update from and commit to the parent
svn repository.
-Steve
^ permalink raw reply
* Re: [PATCH]: Pass -M to diff in request-pull
From: David Miller @ 2006-12-04 17:49 UTC (permalink / raw)
To: torvalds; +Cc: junkio, git
In-Reply-To: <Pine.LNX.4.64.0612040843540.3476@woody.osdl.org>
From: Linus Torvalds <torvalds@osdl.org>
Date: Mon, 4 Dec 2006 08:45:28 -0800 (PST)
> On Mon, 4 Dec 2006, Junio C Hamano wrote:
> > David Miller <davem@davemloft.net> writes:
> > >
> > > Linus recommended this, otherwise any renames cause the
> > > diffstate output to be rediculious in some circumstances :)
> >
> > Thanks, but "rediculious"?
>
> Kernel dewalopers can't speel. We all knew that.
>
> At least we don't do 1337-sp33k.
^ permalink raw reply
* Re: Seeing added and removed files between two tree states
From: Shawn Pearce @ 2006-12-04 17:33 UTC (permalink / raw)
To: Alex Bennee; +Cc: git
In-Reply-To: <1165253146.32764.3.camel@okra.transitives.com>
Alex Bennee <kernel-hacker@bennee.com> wrote:
> In there a way to see just what files where added between two points in
> the tree? I want something better than parsing the diffstat.
[spearce@pb15 git]$ git diff-tree -r --abbrev --diff-filter=A next build
:000000 100644 0000000... 3d53d17... A shallow.c
:000000 100644 0000000... 1fe7a1b... A xdiff/xmerge.c
?
--
^ permalink raw reply
* Re: selective git-update-index per diff(1) chunks
From: Sven Verdoolaege @ 2006-12-04 17:33 UTC (permalink / raw)
To: Alexey Dobriyan; +Cc: git, Paul Mackerras
In-Reply-To: <b6fcc0a0612010323x7554e47m5e6bdafe85fc8224@mail.gmail.com>
On Fri, Dec 01, 2006 at 02:23:14PM +0300, Alexey Dobriyan wrote:
> Has anyone thought about aggregating this into git-update-index or
> somewhere?
>
> git-update-index -C1,3 #chunks 1, 3
> git commit
> git-update-index -C1,3 # chunks 2,5 in original numbering
> git commit
>
> Relying on diff(1) definition of chunks is sorta hacky, though... I admit
> it.
Paul Mackerras modified his dirdiff tool to do something like this.
I have a couple of patches on top of his version from way back at
http://www.liacs.nl/~sverdool/gitweb.cgi?p=dirdiff.git;a=summary
I don't know if he has continued working on this.
^ permalink raw reply
* egit/jgit wishlist
From: Shawn Pearce @ 2006-12-04 17:28 UTC (permalink / raw)
To: git
I've started a wishlist:
http://git.or.cz/gitwiki/EclipsePluginWishlist
My idea is to work through these in the order shown on the page.
I'm looking for comments from those who may be interested in this
plugin, to see what they want/need to make it useful.
There's many months worth of work listed there, especially with
the amount of time that I have available for jgit/egit. So I'm of
course also hoping that others might see something there and try
to implement it themselves. :-)
--
^ permalink raw reply
* Seeing added and removed files between two tree states
From: Alex Bennee @ 2006-12-04 17:25 UTC (permalink / raw)
To: git
In there a way to see just what files where added between two points in
the tree? I want something better than parsing the diffstat.
I thought git-ls-files -ad comittish..comitishb would do the trick but
it seems not.
--
Alex, homepage: http://www.bennee.com/~alex/
... at least I thought I was dancing, 'til somebody stepped on my hand.
-- J. B. White
^ 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