* Re: Considering teaching plumbing to users harmful
From: Kevin Ballard @ 2008-07-17 20:42 UTC (permalink / raw)
To: Jakub Narebski; +Cc: David Kastrup, git
In-Reply-To: <200807172234.19146.jnareb@gmail.com>
On Jul 17, 2008, at 1:34 PM, Jakub Narebski wrote:
> On Thu, 17 July 2008, Kevin Ballard wrote:
>> On Jul 17, 2008, at 1:04 PM, Jakub Narebski wrote:
>>
>>> Git submodules are roughly equivalent to svn:externals with peg
>>> revisions; I mean here that they refer not to some branch in some
>>> external repository, but to specific revision. This is the only
>>> sane
>>> design, as it assures that when checking out some historical
>>> revision,
>>> the state that is checked out will be the same for everybody.
>>>
>>> Please take into account however that submodules are quite new
>>> feature, and while underlying engine is solid, interface (UI) needs
>>> some polishing (and use cases).
>>
>> There is one facet of submodules that annoys me, because it prevents
>> me from using them as a replacement for svn:externals. Namely, the
>> submodule refers to a specific repository, but not a path within that
>> repository. I work with svn repos that use svn:externals to peg
>> revisions (as is appropriate) but they all refer to various paths
>> within the other repositories, and the only way I can deal with that
>> is to throw symlinks everywhere.
>
> I don't quite understand. At the lowest, "gitlink" level submodule
> entry is just having _commit_ object in place of directory. And of
> course this commit object refers to top tree (top directory) in
> a subproject.
>
> If you have subproject B with the following file structure
>
> B/foo
> B/bar/baz
>
> and you have (super)project A, which contains B as subproject at path
> sub-b, and has some files itself, the directory sytucture would look
> like this:
>
> A/quux
> A/sub-b/foo
> A/sub-b/bar/baz
>
>
> What you want, I guess, is some a bit weird for me mixture of
> submodule
> and partial (subtree) checkout... and the latter is not implemented
> yet
> (I say "yet" because there was some preliminary implementation of
> subtree checkout on git mailing list).
It seems you understand what I'm saying. The only way I can mimic it
is to make the submodules actually live in some hidden directory .foo
and then scatter symlinks everywhere.
-Kevin Ballard
--
Kevin Ballard
http://kevin.sb.org
kevin@sb.org
http://www.tildesoft.com
^ permalink raw reply
* Re: Considering teaching plumbing to users harmful
From: Kevin Ballard @ 2008-07-17 20:40 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jakub Narebski, David Kastrup, git
In-Reply-To: <20080717202609.GA32184@machine.or.cz>
On Jul 17, 2008, at 1:26 PM, Petr Baudis wrote:
> On Thu, Jul 17, 2008 at 01:12:57PM -0700, Kevin Ballard wrote:
>> There is one facet of submodules that annoys me, because it
>> prevents me
>> from using them as a replacement for svn:externals. Namely, the
>> submodule
>> refers to a specific repository, but not a path within that
>> repository. I
>> work with svn repos that use svn:externals to peg revisions (as is
>> appropriate) but they all refer to various paths within the other
>> repositories, and the only way I can deal with that is to throw
>> symlinks
>> everywhere.
>
> Actually, is this a big problem? Git can track symlinks and without
> adding support for overall partial checkouts, adding this would feel
> like too huge a hack to me.
>
> Also, when converting to a different VCS, it might be sensible to
> adjust
> your modules setup a bit as well - the requirement to include only
> particular subdirectory of a submodule sounds rather strange to me.
The problem is right now I maintain a bunch of git-svn mirrors of
internal svn repos, but the company isn't willing to switch to git.
And we use subtree externals links to do things like pull in the
models from one rails app into another, or pull in various
subdirectories of the "support" repository.
-Kevin Ballard
--
Kevin Ballard
http://kevin.sb.org
kevin@sb.org
http://www.tildesoft.com
^ permalink raw reply
* Re: Considering teaching plumbing to users harmful
From: Jakub Narebski @ 2008-07-17 20:34 UTC (permalink / raw)
To: Kevin Ballard; +Cc: David Kastrup, git
In-Reply-To: <38486DD8-B4D8-4AAC-9B5F-0A8035D894DD@sb.org>
On Thu, 17 July 2008, Kevin Ballard wrote:
> On Jul 17, 2008, at 1:04 PM, Jakub Narebski wrote:
>
>> Git submodules are roughly equivalent to svn:externals with peg
>> revisions; I mean here that they refer not to some branch in some
>> external repository, but to specific revision. This is the only sane
>> design, as it assures that when checking out some historical revision,
>> the state that is checked out will be the same for everybody.
>>
>> Please take into account however that submodules are quite new
>> feature, and while underlying engine is solid, interface (UI) needs
>> some polishing (and use cases).
>
> There is one facet of submodules that annoys me, because it prevents
> me from using them as a replacement for svn:externals. Namely, the
> submodule refers to a specific repository, but not a path within that
> repository. I work with svn repos that use svn:externals to peg
> revisions (as is appropriate) but they all refer to various paths
> within the other repositories, and the only way I can deal with that
> is to throw symlinks everywhere.
I don't quite understand. At the lowest, "gitlink" level submodule
entry is just having _commit_ object in place of directory. And of
course this commit object refers to top tree (top directory) in
a subproject.
If you have subproject B with the following file structure
B/foo
B/bar/baz
and you have (super)project A, which contains B as subproject at path
sub-b, and has some files itself, the directory sytucture would look
like this:
A/quux
A/sub-b/foo
A/sub-b/bar/baz
What you want, I guess, is some a bit weird for me mixture of submodule
and partial (subtree) checkout... and the latter is not implemented yet
(I say "yet" because there was some preliminary implementation of
subtree checkout on git mailing list).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Considering teaching plumbing to users harmful
From: Petr Baudis @ 2008-07-17 20:26 UTC (permalink / raw)
To: Kevin Ballard; +Cc: Jakub Narebski, David Kastrup, git
In-Reply-To: <38486DD8-B4D8-4AAC-9B5F-0A8035D894DD@sb.org>
On Thu, Jul 17, 2008 at 01:12:57PM -0700, Kevin Ballard wrote:
> There is one facet of submodules that annoys me, because it prevents me
> from using them as a replacement for svn:externals. Namely, the submodule
> refers to a specific repository, but not a path within that repository. I
> work with svn repos that use svn:externals to peg revisions (as is
> appropriate) but they all refer to various paths within the other
> repositories, and the only way I can deal with that is to throw symlinks
> everywhere.
Actually, is this a big problem? Git can track symlinks and without
adding support for overall partial checkouts, adding this would feel
like too huge a hack to me.
Also, when converting to a different VCS, it might be sensible to adjust
your modules setup a bit as well - the requirement to include only
particular subdirectory of a submodule sounds rather strange to me.
--
Petr "Pasky" Baudis
GNU, n. An animal of South Africa, which in its domesticated state
resembles a horse, a buffalo and a stag. In its wild condition it is
something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce
^ permalink raw reply
* Re: [PATCH] Documentation/git-submodule.txt: Further clarify the description
From: Junio C Hamano @ 2008-07-17 20:24 UTC (permalink / raw)
To: Petr Baudis; +Cc: gitster, git, Heikki Orsila
In-Reply-To: <20080717122911.32334.73465.stgit@localhost>
Petr Baudis <pasky@suse.cz> writes:
> This patch rewrites the general description yet again, first clarifying
> the high-level concept, mentioning the difference to remotes and using
> the subtree merge strategy, then getting to the details about tree
> entries and .gitmodules file.
>
> The patch also makes few smallar grammar fixups of the rest of the
> description and clarifies how does 'init' relate to 'update --init'.
>
> Cc: Heikki Orsila <shdl@zakalwe.fi>
> Signed-off-by: Petr Baudis <pasky@suse.cz>
> ---
>
> Documentation/git-submodule.txt | 39 +++++++++++++++++++++++++++------------
> 1 files changed, 27 insertions(+), 12 deletions(-)
>
> diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
> index bb4e6fb..01d0d91 100644
> --- a/Documentation/git-submodule.txt
> +++ b/Documentation/git-submodule.txt
> @@ -18,24 +18,35 @@ SYNOPSIS
>
> DESCRIPTION
> -----------
> +Submodules allow foreign repositories to be embedded within a dedicated
> +subdirectory of the source tree, always pointed at a particular commit.
> +They are not to be confused with remotes, which are meant mainly for branches
> +of the same project; submodules are meant for different projects you would like
Your lines are getting overlong to be easily quoted and commented...
> +.... In case you want to merge the project
> +histories, possibly make local modifications within the tree, but also do not
> +mind that your repository will bulk up with all the contents of the other
> +project, consider adding a remote for the other project and using the 'subtree'
> +merge strategy instead of setting up a submodule.
I'd suggest rephrasing "do not mind" to something a lot less nagative.
The user decides to merge because both histories *are* relevant and at
that point there is no _minding_ anymore. If you want to have them, you
not only "do not mind to have" them but you positively "want" them.
On the other hand, a situation where you would want to use submodules is
when not necessarily all users of the superproject would want to have all
submodules cloned nor checked out. This needs to be stressed with equal
weight as the above sentence in this "contrasting merged histories and
submodules" paragraph. With that explained clearly upfront, it would
become easier for the readers to understand why you can choose not to even
update nor fetch submodules you are not interested in.
> +Submodules are composed from a special kind of tree entry (so-called `gitlink`)
> +in the main repository that refers to a particular commit object within
Do we have to say "special"? Is a gitlink any more special than blob and
tree entries are? It tends to be rarer, it came later, but I do not think
there is anything special from the end user's point of view.
> checked out and at appropriate revision in your working tree. You can inspect
> the current status of your submodules using the 'submodule' subcommand and get
> +an overview of the changes 'update' would perform using the 'summary'
> +subcommand.
Sorry, cannot parse the last three lines...
^ permalink raw reply
* Re: Considering teaching plumbing to users harmful
From: Kevin Ballard @ 2008-07-17 20:15 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86k5fk1ooq.fsf@lola.quinscape.zz>
On Jul 17, 2008, at 9:05 AM, David Kastrup wrote:
>> Distinguishing between branch part of directory name by _convention_
>> is design mistake; the fact that the tool doesn't help to ensure that
>> (a) tags lie on branch (b) tags _doesn't change_ is an example of
>> this
>> stupidity.
>
> How much have you worked with Subversion so far? I am doing quite a
> bit
> of work with it, and the do-everything-via-copying paradigm does not
> get
> in my hair. It actually means that I have to remember fewer commands.
> And it is pretty easy to understand.
Sure, it's simpler, but the overhead in creating and using a branch is
much larger. I have to extract the URL from the repository (since
naturally I only have trunk checked out), issue a command to copy by
URL, then issue an `svn switch` command, and then I have to remember
that I have a switched repository. Switching between branches is a
pain, especially if you have uncommitted work. There's a reason I
never bothered to use branches when I used subversion.
-Kevin Ballard
--
Kevin Ballard
http://kevin.sb.org
kevin@sb.org
http://www.tildesoft.com
^ permalink raw reply
* Re: Considering teaching plumbing to users harmful
From: Kevin Ballard @ 2008-07-17 20:12 UTC (permalink / raw)
To: Jakub Narebski; +Cc: David Kastrup, git
In-Reply-To: <m3k5fks2et.fsf@localhost.localdomain>
On Jul 17, 2008, at 1:04 PM, Jakub Narebski wrote:
>> Granted, particularly concerning the external property. OTOH, it
>> makes
>> the equivalent of git submodules rather cheap (and I actually still
>> have
>> no idea how git submodules properly work and what implications they
>> have).
>
> Git submodules are roughly equivalent to svn:externals with peg
> revisions; I mean here that they refer not to some branch in some
> external repository, but to specific revision. This is the only sane
> design, as it assures that when checking out some historical revision,
> the state that is checked out will be the same for everybody.
>
> Please take into account however that submodules are quite new
> feature, and while underlying engine is solid, interface (UI) needs
> some polishing (and use cases).
There is one facet of submodules that annoys me, because it prevents
me from using them as a replacement for svn:externals. Namely, the
submodule refers to a specific repository, but not a path within that
repository. I work with svn repos that use svn:externals to peg
revisions (as is appropriate) but they all refer to various paths
within the other repositories, and the only way I can deal with that
is to throw symlinks everywhere.
-Kevin Ballard
--
Kevin Ballard
http://kevin.sb.org
kevin@sb.org
http://www.tildesoft.com
^ permalink raw reply
* Re: Considering teaching plumbing to users harmful
From: Jakub Narebski @ 2008-07-17 20:04 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86k5fk1ooq.fsf@lola.quinscape.zz>
[I'm sorry about turning this subthread into Subversion vs. Git rant]
David Kastrup <dak@gnu.org> writes:
> Jakub Narebski <jnareb@gmail.com> writes:
>> David Kastrup <dak@gnu.org> writes:
>>> Daniel Barkalow <barkalow@iabervon.org> writes:
>>>> SVN branches are incredible confusing because they fail to
>>>> distinguish the directory structure of the project's source tree
>>>> from the arrangement of available latest versions.
>>>
>>> That is because there _is_ no difference. You just store different
>>> versions in different places. What they are named is a convention,
>>> nothing more, nothing less.
>>
>> Branching by copying (!) and tagging by copying (!!!) is abuse
>> of the fact that copying in Subversion is cheap.
>
> Uh, no. A lot of work has been invested into ensuring that copying in
> Subversion in cheap _exactly_ because of the design decision to
> implement branching and tagging via copying.
>
> It is not an accident that copying is cheap.
I guess that idea of implementing cheap tree copying and idea of
implementing branches and tags as "full-copies" went hand in hand.
My feeling is that it looks like designing around implementation,
instead of implementing design.
Implementing branches as copies, or in general as directory in
filesystem hierarchy is not that bad idea... provided that one
can flawlessly distinguish between branch and path in project,
can detect where branch name ends and in-project path begins
(perhaps with project/module name in the middle).
Neverheless designing around idea of graph of revisions is, IMVHO,
much superior design :-)
>> Distinguishing between branch part of directory name by _convention_
>> is design mistake; the fact that the tool doesn't help to ensure that
>> (a) tags lie on branch (b) tags _doesn't change_ is an example of this
>> stupidity.
>
> How much have you worked with Subversion so far? I am doing quite a bit
> of work with it, and the do-everything-via-copying paradigm does not get
> in my hair. It actually means that I have to remember fewer commands.
> And it is pretty easy to understand.
If you know what you are doing, and have good established workflow...
I was talking there about possibility of mistake (either accident,
or invalid workflow) of either having tag which is not on a branch,
or changing the tag (treating it as branch).
Branches and tags _are_ different. And should be, IMHO, treated
differently (well, up to a point) by SCM.
>>> Really, Subversion is rather simple to understand. But it is not a
>>> DVCS. Moving a history from one repository to another is not really
>>> feasible unless you are doing straight mirroring.
>>
>> Subversion is simple if you are limited to simple things; but the
>> same is true with Git. I find for example the whole 'properties'
>> mechanism and its use seriously not simple.
>
> Granted, particularly concerning the external property. OTOH, it makes
> the equivalent of git submodules rather cheap (and I actually still have
> no idea how git submodules properly work and what implications they
> have).
Git submodules are roughly equivalent to svn:externals with peg
revisions; I mean here that they refer not to some branch in some
external repository, but to specific revision. This is the only sane
design, as it assures that when checking out some historical revision,
the state that is checked out will be the same for everybody.
Please take into account however that submodules are quite new
feature, and while underlying engine is solid, interface (UI) needs
some polishing (and use cases).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Documentation/git-merge.txt: Expand the How Merge Works section
From: Junio C Hamano @ 2008-07-17 19:34 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20080717185451.GJ10151@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> I'm not sure if I should resend the updated patch, or if you already
> included your comments yourself.
When I send my review comments out, I generally expect an updated version,
unless I explicitly say "will apply with tweaks, no need to resend". I am
way too lazy to munge patches myself ;-) but more importantly, unlike
Linus, I am not perfect. My comments are _not_ "I'll show you the right
way", but more often are "Here is what I think is better, but I may well
be wrong, in which case I want you to defend your position better so that
even I can understand why you are right".
>> > +So in the above two "failed merge" case, you do not have to
>> > +worry about loss of data --- you simply were not ready to do
>> > +a merge, so no merge happened at all. You may want to finish
>> > +whatever you were in the middle of doing, and retry the same
>> > +pull after you are done and ready.
>>
>> I am not sure what two cases we were describing. It could be that this
>> paragraph was taken from a mailing list message responding to a question
>> (e.g. "I got this merge failure message and my tree is screwed up. Please
>> help me get back to a good state, I am lost...") without copying the
>> original sample failure scenario.
>
> Yes, I got confused by this too. I would perhaps simply drop this
> paragraph altogether.
I agree this does not belong to the same "advanced details" section that
talks about a theoretical corner case where the user:
- has a perfect foresight,
- applies (but not commits yet) a patch and stages the change,
- keeps the working tree and the index dirty, and then
- pulls from somewhere else in that dirty state,
knowing what will be merged has that exact same patch to trigger that
corner case logic (yes, I am strongly hinting to drop that description; it
is not even remotely interesting).
However, I think we may want to talk about "How to tell if your merge did
not even touch your index nor working tree" somewhere in the manual.
"When there are conflicts, these things happen" part talks about how to
resolve conflicts, but when merge refuses to avoid losing local changes,
the instruction in that part does not apply.
^ permalink raw reply
* Re: Considering teaching plumbing to users harmful
From: Junio C Hamano @ 2008-07-17 19:10 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: J. Bruce Fields, git
In-Reply-To: <alpine.DEB.1.00.0807171940160.8986@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Thu, 17 Jul 2008, Junio C Hamano wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>> >> Is there a way to commit the contents of a tarball without using
>> >> plumbing? I occasionally want to track an upstream that I know only
>> >> as a series of tarballs, so I do something like:
>> >>
>> >> cd repo/
>> >> git checkout upstream
>> >> rm -rf *
>> >> tar -xzvf ../new-version.tar.gz
>> >
>> > How about "git add -u" and "git add ."?
>>
>> It would work only if new version never removes files.
>
> You made me doubt for a second there. But "git add -u" updates the index
> when a tracked files was deleted. So after "rm -rf *", "git add -u" would
> empty the index.
I thought everybody would react to my message like so after sending it ;-)
What I failed to say was that the main uneasiness about the above command
sequence Bruce or anybody would have felt would be that "rm -fr *" step,
which in itself look scary and does not remove .frotz that came from older
version.
^ permalink raw reply
* Re: Considering teaching plumbing to users harmful
From: Daniel Barkalow @ 2008-07-17 19:00 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <861w1sn4id.fsf@lola.quinscape.zz>
On Thu, 17 Jul 2008, David Kastrup wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > You're simply wrong. A ref isn't a name for a commit (the point of
> > having a ref is that it doesn't persist in naming the same commit). A
> > commit isn't a blob. If you start telling people complicated and wrong
> > things, they're surely going to be confused.
> >
> > Git maintains history as a directed graph, with each commit pointing
> > back at its history. Refs are the what holds the newest commits that
> > nothing else points back to. If directed graphs aren't in your users'
> > experience, you can put it this way: git maintains history like
> > knitting, where each new stitch holds on to one or more previous
> > stitches, and refs are the knitting needles that hold the ends where
> > you're working (except that knitting is a lot wider than software
> > development). gitk --all even provides the diagram you want to explain
> > it.
>
> Complicated and right things are not much less confusing...
>
> > SVN branches are incredible confusing because they fail to distinguish
> > the directory structure of the project's source tree from the
> > arrangement of available latest versions.
>
> That is because there _is_ no difference. You just store different
> versions in different places. What they are named is a convention,
> nothing more, nothing less.
No, there's a difference. When you get a tarball of a project that uses
SVN, the root of the tarball isn't the root of the repository. It's the
root of some directory within the repository. And if you ask for a tarball
of some branch, it's from some different directory in the repository.
Projects are not at all unaware that there are particular subdirectories
in the repository structure which contain roots of versions, and above
that, the directory structure doesn't refer to the structure of a project
snapshot.
Because SVN lacks a vital concept (graph-structured history), it uses the
same implementation for two qualitatively different concepts. This is
extremely confusing, and much more confusing than having a clean
separation between the two concepts like git does.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] Documentation/git-merge.txt: Expand the How Merge Works section
From: Petr Baudis @ 2008-07-17 18:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3am8gytp.fsf@gitster.siamese.dyndns.org>
Hi,
I'm not sure if I should resend the updated patch, or if you already
included your comments yourself.
On Thu, Jul 17, 2008 at 11:17:22AM -0700, Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
> > +* `HEAD` is already contained in the merged commit. This is the
> > + most common case especially when involved through 'git pull':
> > + you are tracking an upstream repository, committed no local
> > + changes and now you want to update to a newer upstream revision.
> > + So-called "fast-forward merge" is performed, simply repointing
> > + your `HEAD` (and index) to the merged commit; no extra merge
> > + commit is created.
>
> I'd suggest rewording the last three lines:
>
> Your `HEAD` (and the index) is updated to point the merged
^ at
> commit, without creating an extra merge commit. This is
> called "Fast-forward".
Yes, that is better.
> > +Pre-flight requirements note
> > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > +In certain special cases, your index is
> > +allowed to be different from the tree of the `HEAD` commit.
>
> Now this paragraph is moved far away from the original context that said
> "your index must be clean before you start your merge", you would need to
> re-introduce that in this sentenece:
>
> ... tree of the `HEAD` before you run 'git-merge'.
Done.
I have to admit that I didn't even carefully read the rest of this
subsection, but I agree that we might as well update it when moving it
around already.
> > +... Also, your index entries
> > +may have differences from your `HEAD` commit that match
> > +the result of a trivial merge (e.g. you received the same patch
> > +from an external source to produce the same result as what you are
> > +merging). For example, if a path did not exist in the common
> > +ancestor and your head commit but exists in the tree you are
> > +merging into your repository, and if you already happen to have
> > +that path exactly in your index, the merge does not have to
> > +fail.
>
> I originally wrote the above paragraph purely for completeness, but I
> wonder if this happens a lot in practice. This is not something the user
> can easily anticipate anyway, so we might want to drop this.
I think that we can expect only users that have real interest in these
details to read through this, so I would keep it for the completeness.
> > +So in the above two "failed merge" case, you do not have to
> > +worry about loss of data --- you simply were not ready to do
> > +a merge, so no merge happened at all. You may want to finish
> > +whatever you were in the middle of doing, and retry the same
> > +pull after you are done and ready.
>
> I am not sure what two cases we were describing. It could be that this
> paragraph was taken from a mailing list message responding to a question
> (e.g. "I got this merge failure message and my tree is screwed up. Please
> help me get back to a good state, I am lost...") without copying the
> original sample failure scenario.
Yes, I got confused by this too. I would perhaps simply drop this
paragraph altogether.
--
Petr "Pasky" Baudis
GNU, n. An animal of South Africa, which in its domesticated state
resembles a horse, a buffalo and a stag. In its wild condition it is
something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce
^ permalink raw reply
* Re: Considering teaching plumbing to users harmful
From: Johannes Schindelin @ 2008-07-17 18:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: J. Bruce Fields, git
In-Reply-To: <7vtzeofjpi.fsf@gitster.siamese.dyndns.org>
Hi,
On Thu, 17 Jul 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> Is there a way to commit the contents of a tarball without using
> >> plumbing? I occasionally want to track an upstream that I know only
> >> as a series of tarballs, so I do something like:
> >>
> >> cd repo/
> >> git checkout upstream
> >> rm -rf *
> >> tar -xzvf ../new-version.tar.gz
> >
> > How about "git add -u" and "git add ."?
>
> It would work only if new version never removes files.
You made me doubt for a second there. But "git add -u" updates the index
when a tracked files was deleted. So after "rm -rf *", "git add -u" would
empty the index.
AFAICT this has been a part of "git add -u" ever since dfdac5d(git-add -u:
match the index with working tree.), i.e. ever since the "-u" option was
added.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH/rfc] git-svn.perl: workaround assertions in svn library 1.5.0
From: Dmitry Potapov @ 2008-07-17 18:37 UTC (permalink / raw)
To: Gerrit Pape; +Cc: git, Eric Wong
In-Reply-To: <20080717140856.10213.qmail@c0f13986110104.315fe32.mid.smarden.org>
On Thu, Jul 17, 2008 at 6:08 PM, Gerrit Pape <pape@smarden.org> wrote:
>
> Hi, while this commit fixed the selftests, it unfortunately is a
> regression
>
> http://thread.gmane.org/gmane.comp.version-control.git/87822/
> http://bugs.debian.org/490400
This particular breakage is easy to fix:
diff --git a/git-svn.perl b/git-svn.perl
index 3750e47..a5a5b1b 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -1226,7 +1226,7 @@ sub linearize_history {
sub find_file_type_and_diff_status {
my ($path) = @_;
- return ('dir', '') if $path eq '.';
+ return ('dir', '') if $path eq '';
my $diff_output =
command_oneline(qw(diff --cached --name-status --), $path) || "";
but it could be some other places in git-svn that may need correction too.
>
> I'm still not sure whether this is a git-svn problem, or actually a
> problem in subversion 1.5.0
Accordingly to SVN developers you do not use SVN API correctly,
therefore you got assert. So, the problem in git-svn.
http://svn.haxx.se/dev/archive-2008-01/0425.shtml
Dmitry
^ permalink raw reply related
* Re: Considering teaching plumbing to users harmful
From: Junio C Hamano @ 2008-07-17 18:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: J. Bruce Fields, git
In-Reply-To: <alpine.DEB.1.00.0807171915420.8986@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> Is there a way to commit the contents of a tarball without using
>> plumbing? I occasionally want to track an upstream that I know only as
>> a series of tarballs, so I do something like:
>>
>> cd repo/
>> git checkout upstream
>> rm -rf *
>> tar -xzvf ../new-version.tar.gz
>
> How about "git add -u" and "git add ."?
It would work only if new version never removes files.
^ permalink raw reply
* Re: [PATCH] Documentation/gitignore.txt: Clarify gitignore vs tracked files
From: Petr Baudis @ 2008-07-17 18:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vabgggyuc.fsf@gitster.siamese.dyndns.org>
Hi,
On Thu, Jul 17, 2008 at 11:16:59AM -0700, Junio C Hamano wrote:
> I'd suggest dropping everything after ';'.
I think the part after ';' is the main benefit of this patch,
actually. Without suggesting an alternative, the users are left puzzled
"so how do I do that?"
> - If you want to keep local changes without ever checking in, you can do
> so by making partial commits.
Yes, that's a rather obvious solution but the user probably wants
something nicer than that if he starts looking already.
> - You could mark these paths "assume unchanged".
I really think this is worth mentioning in the gitignore manpage;
it is not _directly_ on-topic, but there is no other obvious place where
to teach users about it and all the interested people will check the
gitignore manpage first. Perhaps a small section at the end might be
acceptable? ;-)
--
Petr "Pasky" Baudis
GNU, n. An animal of South Africa, which in its domesticated state
resembles a horse, a buffalo and a stag. In its wild condition it is
something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce
^ permalink raw reply
* Re: [PATCH] Teach git submodule update to use distributed repositories
From: Petr Baudis @ 2008-07-17 18:22 UTC (permalink / raw)
To: Nigel Magnay; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <320075ff0807170807l1537e34ev510deda537e4d11e@mail.gmail.com>
On Thu, Jul 17, 2008 at 04:07:11PM +0100, Nigel Magnay wrote:
> And it works, but
>
> $ git pull fred
> $ git submodule update
>
> Can leave you with problems, because if a submodule wasn't pushed to
> origin, you won't have it available. This is because the commands are
> equivalent to
>
> $ git pull fred
> for each submodule()
> cd submodule
> git fetch origin
> git checkout <sha1>
Oh! So, only after replying to most of your mail, I have realized what
are you talking about all the time - _just_ this particular failure
mode:
"Someone pushed out a repository repointing submodules to
invalid commits, and instead of waiting for the person to fix
this breakage, we want to do a one-off fetch of all submodules
from a different repository."
There's nothing else you're trying to solve by this, right?
Now, I think that this is a completely wrong problem to solve. Your
gitweb is going to be broken, everyone has to jump through hoops because
of this, and that all just because of a single mistake. It shouldn't
have _happenned_ in the first place.
So the proper solution for this should be to make an update hook that
will simply not _let_ you push out a tree that's broken like this.
Something like this (completely untested):
die() { echo "$@"; exit 1; }
git rev-list ^$2 $3 | while read commit; do
git show $commit:.gitmodules >/tmp/gm$$
git config -f /tmp/gm$$ --get-regexp 'submodule\..*\.path' |
cut -d ' ' -f 1 |
sed 's/^.*\.//; s/\..*$//;' |
while read submodule; do
path=$(git config -f /tmp/gm$$ "submodule.$submodule.path")
url=$(git config -f /tmp/gm$$ "submodule.$submodule.url")
entry=$(git ls-tree $commit "$path")
[ -n "$entry" ] || die "submodule $submodule points at a non-existing path"
[ "$(echo "$entry" | cut -d ' ' -f 1)" = "160000" ] || die "submodule $submodule does not point to a gitlink entry"
subcommit="$(echo "$entry" | cut -d ' ' -f 2)"
urlhash="$(echo "$url" | sha1sum | cut -d ' ' -f 1)"
# We keep local copies of submodule repositories
# for commit existence checking
echo "Please wait, updating $url cache..."
if [ -d /tmp/ucache/$urlhash ]; then
(cd /tmp/ucache/$urlhash && git fetch)
else
git clone --bare "$url" /tmp/ucache/$urlhash
fi
[ "$(git --git-dir=/tmp/ucache/$urlhash cat-file -t "$subcommit" 2>/dev/null)" = "commit" ] || die "submodule $submodule does not point at an existing commit"
done
done
Comments? If it seems good, it might be worth including in
contrib/hooks/. Maybe even in the default update hook, controlled by
a config option.
All the troubles here stem from the fact that normally, Git will not let
you push any invalid state to the server. This is not completely true in
this case, but we should prevent this behaviour instead of inventing
hacks to work it around.
> Unless each submodule had a [remote] specified for "fred", you'd be
> stuffed. But what you could do is either by passing the right URL, or
> looking at the superproject [remote] for "fred" - i.e: If in the
> superproject you have
>
> [remote "fred"]
> url = ssh://git@fred.local/pub/scm/git/workspace/thing/.git
> [submodule "module"]
> url = ssh://git@repo/pub/scm/git/module.git
>
> Then the submodule "module" on fred, if it's a working-copy, can be calculated
> ssh://git@fred.local/pub/scm/git/workspace/thing/module/.git
>
> If it isn't a WC then you'd have to have a [remote "fred"] in that
> submodule, but I'm thinking that'd be a rare case.
This is ultra-evil. I think assuming things like this is extremely dirty
and not reasonable for a universal code, _unless_ we explicitly decide
that this is a new convention you want to introduce as a recommendation.
But you should've been very clear about this upfront.
_If_ you still insist on the one-off fetches for some reason, I think
it's reasonable to provide your own simple script for your users that
will autogenerate these URLs appropriately for your particular setup.
I don't think there is any real need for a more generic solution.
> I'd assumed (possibly wrongly?) that there was resistance to putting
> any of the submodule logic in things other than git-submodules.
Are you following the thread about submodule support for git mv, git rm?
--
Petr "Pasky" Baudis
GNU, n. An animal of South Africa, which in its domesticated state
resembles a horse, a buffalo and a stag. In its wild condition it is
something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce
^ permalink raw reply
* Re: [PATCH] Documentation/git-merge.txt: Expand the How Merge Works section
From: Junio C Hamano @ 2008-07-17 18:17 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20080717162922.12081.96582.stgit@localhost>
Petr Baudis <pasky@suse.cz> writes:
> The git-merge documentation's "HOW MERGE WORKS" section is confusingly
> composed and actually omits the most interesting part, the merging of
> the arguments into HEAD itself, surprisingly not actually mentioning
> the fast-forward merge anywhere.
Thanks.
> +Three kinds of merge can happen:
>
> +* The merged commit is already contained in `HEAD`. This is the
> + simplest case and only "Already up-to-date" is printed.
Let's introduce and define terms here, because I think the readers will be
harmed by being given a weak "this _might_ be called" in later paragraph.
I.e.:
... This is the simplest case and called "Already up-to-date".
> +* `HEAD` is already contained in the merged commit. This is the
> + most common case especially when involved through 'git pull':
> + you are tracking an upstream repository, committed no local
> + changes and now you want to update to a newer upstream revision.
> + So-called "fast-forward merge" is performed, simply repointing
> + your `HEAD` (and index) to the merged commit; no extra merge
> + commit is created.
I'd suggest rewording the last three lines:
Your `HEAD` (and the index) is updated to point the merged
commit, without creating an extra merge commit. This is
called "Fast-forward".
> +* Both merged commit and `HEAD` are independent and must be
> + "tied together" by a merge commit, having them both as its parents;
> + this might be called a "true merge" and is described in the rest
> + of this section.
And this becomes:
... both as its parents. The rest of this section describes this
"True merge" case.
> +Pre-flight requirements note
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +In certain special cases, your index is
> +allowed to be different from the tree of the `HEAD` commit.
Now this paragraph is moved far away from the original context that said
"your index must be clean before you start your merge", you would need to
re-introduce that in this sentenece:
... tree of the `HEAD` before you run 'git-merge'.
> +... The most
> +notable case is when your `HEAD` commit is already ahead of what
> +is being merged, in which case your index can have arbitrary
> +differences from your `HEAD` commit.
Thanks to your re-organization, we now have established terminology when
the reader reads this part, so we can just say:
When the merge will be "Already-up-to-date", your index can have
...
> +... Also, your index entries
> +may have differences from your `HEAD` commit that match
> +the result of a trivial merge (e.g. you received the same patch
> +from an external source to produce the same result as what you are
> +merging). For example, if a path did not exist in the common
> +ancestor and your head commit but exists in the tree you are
> +merging into your repository, and if you already happen to have
> +that path exactly in your index, the merge does not have to
> +fail.
I originally wrote the above paragraph purely for completeness, but I
wonder if this happens a lot in practice. This is not something the user
can easily anticipate anyway, so we might want to drop this.
> +Other than that, merge will refuse to do any harm to your repository
My initial reaction to this "Other than that" was "Huh? so the special
case we just saw allows merge to do harm to my repository?". The original
"Otherwise" wasn't any better, either.
In all other cases, your index must match the `HEAD` commit, even
though you can have local changes in your working tree, as
described below. Merge will avoid doing any harm to your working
tree state and your repository by refusing to work if such local
changes conflict with the merged result, though.
> +So in the above two "failed merge" case, you do not have to
> +worry about loss of data --- you simply were not ready to do
> +a merge, so no merge happened at all. You may want to finish
> +whatever you were in the middle of doing, and retry the same
> +pull after you are done and ready.
I am not sure what two cases we were describing. It could be that this
paragraph was taken from a mailing list message responding to a question
(e.g. "I got this merge failure message and my tree is screwed up. Please
help me get back to a good state, I am lost...") without copying the
original sample failure scenario.
^ permalink raw reply
* Re: [PATCH] Documentation/gitignore.txt: Clarify gitignore vs tracked files
From: Junio C Hamano @ 2008-07-17 18:16 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20080717163622.12592.29919.stgit@localhost>
Petr Baudis <pasky@suse.cz> writes:
> -git should ignore. Each line in a `gitignore` file specifies a
> -pattern.
> +git should ignore.
> +Note that all the `gitignore` files really concern only files
> +that are not already tracked by git; there is no direct mechanism
> +to make git ignore your local modifications in already tracked files.
Thanks.
I'd suggest dropping everything after ';'.
- If you want to keep local changes without ever checking in, you can do
so by making partial commits.
- You could mark these paths "assume unchanged".
^ permalink raw reply
* Re: Considering teaching plumbing to users harmful
From: Johannes Schindelin @ 2008-07-17 18:16 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Junio C Hamano, git
In-Reply-To: <20080717155538.GE11759@fieldses.org>
Hi,
On Thu, 17 Jul 2008, J. Bruce Fields wrote:
> On Wed, Jul 16, 2008 at 01:51:31PM -0700, Junio C Hamano wrote:
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> > > Am I the only one who deems teaching plumbing to users ("I like it raw!
> > > So I teach it the same way!") harmful?
> >
> > I think that justification is harmful.
> >
> > More productive way to think about it is to identify cases where we _need_
> > to go down to combination of the plumbing commands in our daily workflow,
> > with today's command set. That would give us a good indication that some
> > Porcelain may need to be enhanced.
>
> Is there a way to commit the contents of a tarball without using
> plumbing? I occasionally want to track an upstream that I know only as
> a series of tarballs, so I do something like:
>
> cd repo/
> git checkout upstream
> rm -rf *
> tar -xzvf ../new-version.tar.gz
How about "git add -u" and "git add ."?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Testsuite: Unset CVS_SERVER
From: Jeff King @ 2008-07-17 17:53 UTC (permalink / raw)
To: Lars Noschinski; +Cc: git, fabian.emmes
In-Reply-To: <1216288877-12140-2-git-send-email-lars@public.noschinski.de>
On Thu, Jul 17, 2008 at 12:01:13PM +0200, Lars Noschinski wrote:
> The CVS_SERVER environment variable cane cause some of the cvsimport tests
> to fail. So unset this variable at the beginning of the test script.
This is definitely an improvement. However, the cvs manual lists a
number of CVS* variables. Perhaps it would be better to simply scrub the
environment of any variable matching that pattern? I don't know how
commonly used some of the other ones are.
-Peff
^ permalink raw reply
* Re: [PATCH] Documentation/RelNotes-1.6.0.txt: Expand on the incompatible packfiles
From: Petr Baudis @ 2008-07-17 17:45 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200807171940.06288.jnareb@gmail.com>
On Thu, Jul 17, 2008 at 07:40:06PM +0200, Jakub Narebski wrote:
> Petr Baudis wrote:
> > I'm unclear about the 'or'-'and' question, though.
>
> If you want to be backwards compatibile with pre v1.4.4.5 clients,
> do you have to set either option, or both options, or what? The
> same with pre v1.5.2 client...
If you want to be backwards compatible with _either_ pre-v1.4.4 or
pre-v1.5.2, you will set _either_ (a) or (b). Setting (a) implies you
want to set (b) too, though. :-)
Petr "Pasky" Baudis
^ permalink raw reply
* Re: [PATCH] Documentation/RelNotes-1.6.0.txt: Expand on the incompatible packfiles
From: Jakub Narebski @ 2008-07-17 17:40 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20080717172051.GY32184@machine.or.cz>
Petr Baudis wrote:
> On Thu, Jul 17, 2008 at 07:10:32PM +0200, Jakub Narebski wrote:
> > Petr Baudis wrote:
> >
> > > +introduced in v1.5.2 and v1.4.4.5. If you want to keep your repositories
> > > +backwards compatible past these versions, set repack.useDeltaBaseOffset
> > > +to false or pack.indexVersion to 1, respectively.
> >
> > 'or'? Not 'and'?
> >
> > You shouldn't have, I think, this "respectively" here. You need it only
> > if you are writing "a, b, c, then a', b', c', respectively".
>
> The "respectively" means that the two options relate each to one of the
> two new features.
Sorry, I have forgot that "respectively" might refer to the context
which I don't see in a patch.
> I'm unclear about the 'or'-'and' question, though.
If you want to be backwards compatibile with pre v1.4.4.5 clients,
do you have to set either option, or both options, or what? The
same with pre v1.5.2 client...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Subversion is actually not so simple (was RE: Considering teaching plumbing to users harmful)
From: Jakub Narebski @ 2008-07-17 17:37 UTC (permalink / raw)
To: Craig L. Ching; +Cc: David Kastrup, git
In-Reply-To: <63BEA5E623E09F4D92233FB12A9F79430238A167@emailmn.mqsoftware.com>
On Thu, 17 July 2008, Craig L. Ching wrote:
> For instance, SVN has a history of having to invent concepts that just
> shouldn't need to be invented. Their latest release includes something
> they call "merge tracking", but it falls on the floor in the face of
> what they call "reflective merging." [1] I don't find "merge tracking"
> and "reflective merges" concepts that I should *have* to understand when
> it comes to working with a VCS, the VCS should just *do* those things.
> Those concepts just don't exist in Git. Frankly, I don't find
> Subversion to be easier to use than Git at all and this is coming from a
> very long-time CVS user. I do find, however, that Git has a very large
> vocabulary and that does take some time to learn, but I'd argue that
> this is due to it's inherent flexibility than it is due to any inherent
> flaws.
>
> [1] -- http://blogs.open.collab.net/svn/2008/07/subversion-merg.html
WTF!?!
Without merge tracking (which at minimum means that commits which are
result of [true] merging contain information about which commits were
merged) you can't really display and reconstruct history. Without new
svn:mergeinfo one had to rely on third party extensions (SVK or svnmerge)
or on information contained in commit message to get this info. It is
very good that at last Subversion 1.5 finally does include merge
information.
But, if I understand correctly, and if information in mentioned blog
is correct, then Subversion _fails_ to use this information fully.
Instead of finding merge bases (see http://revctrl.org ... errr, it
is now full of spam, and there is no easy way to revert to some older
version, so you would have to browse history), and doing 3-way merge[1],
it requires of user to explicitly request automatical merge:
$ svn merge --reintegrate url://feature-branch .
and from the blog it looks like Subversion just generates patch and
applies it. Or do I understand it incorrectly?
[1] CVS did it, even Bram Cohen of Codeville agrees now[2] that 3-way
merge is a correct way to go
[2] http://bramcohen.livejournal.com/52148.html
"3. Use 3-way merge"
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Documentation/RelNotes-1.6.0.txt: Expand on the incompatible packfiles
From: Petr Baudis @ 2008-07-17 17:20 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <g5nue6$3ek$1@ger.gmane.org>
On Thu, Jul 17, 2008 at 07:10:32PM +0200, Jakub Narebski wrote:
> Petr Baudis wrote:
>
> > +introduced in v1.5.2 and v1.4.4.5. If you want to keep your repositories
> > +backwards compatible past these versions, set repack.useDeltaBaseOffset
> > +to false or pack.indexVersion to 1, respectively.
>
> 'or'? Not 'and'?
>
> You shouldn't have, I think, this "respectively" here. You need it only
> if you are writing "a, b, c, then a', b', c', respectively".
The "respectively" means that the two options relate each to one of the
two new features. I'm unclear about the 'or'-'and' question, though.
Petr "Pasky" Baudis
^ 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