* Re: RFC: display dirty submodule working directory in git gui and gitk
From: Jens Lehmann @ 2010-01-04 18:40 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Johannes Schindelin, Git Mailing List, Junio C Hamano,
Shawn O. Pearce, Paul Mackerras, Heiko Voigt, Lars Hjemli
In-Reply-To: <fcaeb9bf1001040951r3f797750o5ebd25e93c0272ea@mail.gmail.com>
Am 04.01.2010 18:51, schrieb Nguyen Thai Ngoc Duy:
> Incidentally I was just drafting git-super.sh it see how far it goes.
> The goal was to implement some cross-module operations over time. "git
> super status", "git super commit" and others could be handy.
Hm, i'm not sure if this will really help us. I would rather see "git
status" and friends do the right thing for submodules too. Maybe this
has to be configurable but i think the separate commands that one has
to use for submodules now are part of the usability problems we are
seeing.
IMHO putting the functionality of "git submodule summary" into "git
diff" was a step in the right direction. This thread is about adding a
line to the diff output when diffing against the working directory and
a submodule has a dirty working directory too. Then you can ask "git
diff" and it tells you anything you need to know about the submodule
before committing or checking out in the supermodule (And IMO later on
"git status" should give us this information too).
^ permalink raw reply
* "git add -i" with path gives "Argument list too long"
From: Wincent Colaiuta @ 2010-01-04 18:43 UTC (permalink / raw)
To: git
Just ran "git add -i <path>" with "<path>" pointing to a subdirectory
which happens to have a bunch of files in it (about 7k) and it barfed
thusly:
Can't exec "git": Argument list too long at /usr/local/libexec/git-
core/git-add--interactive line 158.
Died at /usr/local/libexec/git-core/git-add--interactive line 158.
I see that what it's trying to do under the hood is:
git diff-index --cached --numstat --summary HEAD -- <7,000+ paths...>
Sure, we could divide the paths into smaller groups, run multiple
invocations of "git diff-index", and concatenate the results. But it
would be nicer if there was some other way that we could get at the
same information without having to pass 7,000 paths explicitly on the
command line; is there any which I am overlooking?
The enormous file list is the result of passing <path> into "git ls-
files -- <path>". Would it be worth:
- either, modifying "git diff-index" to accept a list of paths over
stdin so that we could at least pipe the output from "git ls-files"
into "git diff-index"
- or, preferably, teach "git diff index" to recurse into directories
rather than expect a list of paths-of-blobs (possibly with a command
line switch to activate the behaviour if it were deemed a dangerous
default)
This is one piece of plumbing that I've never dabbled with, so forgive
me if my questions are a little dumb.
Cheers,
Wincent
^ permalink raw reply
* Re: RFC: display dirty submodule working directory in git gui and gitk
From: Junio C Hamano @ 2010-01-04 19:05 UTC (permalink / raw)
To: Jens Lehmann
Cc: Nguyen Thai Ngoc Duy, Johannes Schindelin, Git Mailing List,
Shawn O. Pearce, Paul Mackerras, Heiko Voigt, Lars Hjemli
In-Reply-To: <4B423633.6090603@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
> Am 04.01.2010 18:51, schrieb Nguyen Thai Ngoc Duy:
>> Incidentally I was just drafting git-super.sh it see how far it goes.
>> The goal was to implement some cross-module operations over time. "git
>> super status", "git super commit" and others could be handy.
>
> Hm, i'm not sure if this will really help us. I would rather see "git
> status" and friends do the right thing for submodules too. Maybe this
> has to be configurable but i think the separate commands that one has
> to use for submodules now are part of the usability problems we are
> seeing.
>
> IMHO putting the functionality of "git submodule summary" into "git
> diff" was a step in the right direction. This thread is about adding a
> line to the diff output when diffing against the working directory and
> a submodule has a dirty working directory too. Then you can ask "git
> diff" and it tells you anything you need to know about the submodule
> before committing or checking out in the supermodule (And IMO later on
> "git status" should give us this information too).
Both will be valid approaches to work toward the same goal. A separate
prototype implementation can be a way to easily figure out what the
desired features are.
If "git super status" does turns out to be consistent with what "git
status" is supposed to do, you can decide to fold that into the latter at
that point. On the other hand, information people may want from "git
super status" could be different from what people want "git status" from,
in which case it might be better to either become a new option to "git
status", or become a new subcommand to "git submodule".
You start the prototype by changing "git status" and later decide that the
end result either needs to become an optional behaviour, or maybe even a
separate command. Either way the end result will be the same---a good
feature to help people is placed at the most logical place.
For the past 12 months, you and Johan Herland were the people who had more
than one patches with substance to git-submodule.sh and I would really
appreciate and at the same time want to encourage experimentation by
people like you who are heavy users with need for a better submodule
support.
Thanks.
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2010, #01; Mon, 04)
From: Junio C Hamano @ 2010-01-04 19:10 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqaawtyh99.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> * mm/diag-path-in-treeish (2009-12-07) 1 commit
>> - Detailed diagnosis when parsing an object name fails.
>
> This one has been there for quite some time and shouldn't be
> controversial. Do I need anything to push it into next?
Prodding like this ;-)
I wanted to stagger and spread the merge into 'next' over a few rounds.
Thanks.
^ permalink raw reply
* Re: submodules, was Re: RFC: display dirty submodule working directory in git gui and gitk
From: Jens Lehmann @ 2010-01-04 19:14 UTC (permalink / raw)
To: Avery Pennarun
Cc: Johannes Schindelin, Heiko Voigt, Git Mailing List,
Junio C Hamano, Shawn O. Pearce, Paul Mackerras, Lars Hjemli
In-Reply-To: <32541b131001041029t5adc535bt9681d33174042871@mail.gmail.com>
Am 04.01.2010 19:29, schrieb Avery Pennarun:
> For me one big problem comes down to producing accurate output for
> 'git log'. git submodules assume that the history inside the module
> is entirely separate (you need to run multiple 'git log' instances to
> see the full history); git-subtree assumes that it's entirely
> integrated. In that sense, git-subtree is somewhat more in line with
> the core principle of git (we track the history of "the content", not
> any particular file or subdir). Unfortunately, it also exposes a
> problem with that core principle: taken to its extreme, "the content"
> includes all data in the universe. And while git could branch and
> merge the universe very efficiently in about O(log n) time, 'git log'
> output gets less useful about O(n) with the size of the tree.
>
> Neither git-subtree nor git submodules seem to help with this "log
> pollution" problem very much - but I don't know what to do that would
> be better.
I think this depends extremely on the use case and may even differ
from submodule to submodule. It might be desirable to be able to
specify which submodule logs you want to see, because only the user
knows what is important for him. But you should be able to ask "git
log" directly without forking it in every submodule you care about,
no?
There has been a thread between Junio and Heiko about group mappings
for submodules. Maybe the configuration could be extended to contain
information about what submodule should add to the superprojects log?
http://thread.gmane.org/gmane.comp.version-control.git/130928/
> Outside of this, my major problem with submodules is they use separate
> work trees and repositories, and thus require lots of extra
> housekeeping to get anything done. I'd be much happier if submodules
> would share the same objects/packs/.gitdir/refs/indexfile as the
> superproject, and the *only* thing special about them would be that
> the superproject's tree points at a commit object instead of a tree
> object. In other words, I think the actual repo format is correct
> as-is, but the tools surrounding it cause a lot of confusion.
I don't care deeply where the objects live but agree about the repo
format and the confusion ;-)
> Imagine if cloning a superproject also checked out the subproject
> transparently,
That would be great (at least at checkout time, after clone you
might wanna decide which submodules to initialize first - unless
group mappings are working). Right now we use post-checkout hooks
to do that.
> and committing dirty data inside the subproject's tree
> created a new commit object for the subproject, then tacked that
> commit object into the superproject's index for a later commit
> (exactly as changing a subdir creates a new tree object that the
> parent directory can refer to).
That would be a nice feature.
> This doesn't solve some use cases, however, such as ones where people
> really don't want to check out (or even fetch) the contents of some
> submodules, even when they check out the superproject. The current
> implementation *does* handle that situation. I'm not sure how many
> people rely on that behaviour, though. (And maybe the correct
> solution to *that* is proper support for sparse clone/checkout
> regardless of submodules.)
We do rely on this behavior. But sparse clone or group mappings
could replace that need.
^ permalink raw reply
* Re: RFC: display dirty submodule working directory in git gui and gitk
From: Jens Lehmann @ 2010-01-04 19:21 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nguyen Thai Ngoc Duy, Johannes Schindelin, Git Mailing List,
Shawn O. Pearce, Paul Mackerras, Heiko Voigt, Lars Hjemli
In-Reply-To: <7viqbhelmh.fsf@alter.siamese.dyndns.org>
Am 04.01.2010 20:05, schrieb Junio C Hamano:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
>
>> Am 04.01.2010 18:51, schrieb Nguyen Thai Ngoc Duy:
>>> Incidentally I was just drafting git-super.sh it see how far it goes.
>>> The goal was to implement some cross-module operations over time. "git
>>> super status", "git super commit" and others could be handy.
>>
>> Hm, i'm not sure if this will really help us. I would rather see "git
>> status" and friends do the right thing for submodules too. Maybe this
>> has to be configurable but i think the separate commands that one has
>> to use for submodules now are part of the usability problems we are
>> seeing.
> Both will be valid approaches to work toward the same goal. A separate
> prototype implementation can be a way to easily figure out what the
> desired features are.
> For the past 12 months, you and Johan Herland were the people who had more
> than one patches with substance to git-submodule.sh and I would really
> appreciate and at the same time want to encourage experimentation by
> people like you who are heavy users with need for a better submodule
> support.
Right. It was not my intention to discourage such experimentations with
my reply. I'm sorry if my email made this impression.
^ permalink raw reply
* Re: A question about changing remote repo name
From: Miklos Vajna @ 2010-01-04 20:09 UTC (permalink / raw)
To: Dongas; +Cc: git
In-Reply-To: <60ce8d251001032245n4e0267b1o1ecc796f324f8179@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 258 bytes --]
On Mon, Jan 04, 2010 at 02:45:09PM +0800, Dongas <dongas86@gmail.com> wrote:
> I'm running ubuntu 9.04 and the git coming along with it doesn't
> support git remote rename command.
It first appeared in v1.6.1, about a year ago. What does 'git version'
say?
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* edit Author/Date metadata as part of 'git commit' $EDITOR invocation?
From: Adam Megacz @ 2010-01-03 23:32 UTC (permalink / raw)
To: git
Hi, folks.
>From the output of 'git show', it appears that a commit has a few fields
of metadata associated with it in addition to the comment. These fields
seem to include Author, AuthorDate, Committer, and CommitDate.
1. Are there other fields aside from these four?
2. When I invoke 'git commit' without the '-m' argument I'm dropped
into the cozy $EDITOR of my choice and given the opportunity to
edit the commit message. Is there any way to include the metadata
fields in this editing session? That way I could both sanity-check
them as I perform the commit (important) and modify them if they're
wrong (less important).
I've been having problems lately with running git on machines where
I forgot to set up my .gitconfig; I wind up with patches that have
committers like root@mymachine and so forth. Being automatically
shown the committer/author when I make the commit would help me
avoid these situations.
Thanks,
- a
^ permalink raw reply
* Re: edit Author/Date metadata as part of 'git commit' $EDITOR invocation?
From: Sverre Rabbelier @ 2010-01-04 20:32 UTC (permalink / raw)
To: Adam Megacz; +Cc: git
In-Reply-To: <xuu2fx6m4vdi.fsf@nowhere.com>
Heya,
On Sun, Jan 3, 2010 at 18:32, Adam Megacz <adam@megacz.com> wrote:
> I've been having problems lately with running git on machines where
> I forgot to set up my .gitconfig; I wind up with patches that have
> committers like root@mymachine and so forth. Being automatically
> shown the committer/author when I make the commit would help me
> avoid these situations.
At the very least it should be easy to include these fields as
comments in the message template. But of course you would still be
bitten if you used "git commit -m" :(.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: edit Author/Date metadata as part of 'git commit' $EDITOR invocation?
From: Adam Megacz @ 2010-01-04 21:08 UTC (permalink / raw)
To: git
In-Reply-To: <fabb9a1e1001041232h4e5827d1pb5c648b33ecfb5ce@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> On Sun, Jan 3, 2010 at 18:32, Adam Megacz <adam@megacz.com> wrote:
>> I've been having problems lately with running git on machines where
>> I forgot to set up my .gitconfig; I wind up with patches that have
>> committers like root@mymachine and so forth. Being automatically
>> shown the committer/author when I make the commit would help me
>> avoid these situations.
>
> At the very least it should be easy to include these fields as
> comments in the message template.
That would be great.
> But of course you would still be bitten if you used "git commit -m"
> :(.
Perhaps a preference (off by default) demanding that they be set
explicitly when "git commit -m" is used?
Some people care more than others about the metadata; this is for the
folks to whom it matters a lot.
- a
^ permalink raw reply
* submodules' shortcomings, was Re: RFC: display dirty submodule working directory in git gui and gitk
From: Johannes Schindelin @ 2010-01-04 22:29 UTC (permalink / raw)
To: Jens Lehmann
Cc: Git Mailing List, Junio C Hamano, Shawn O. Pearce, Paul Mackerras,
Heiko Voigt, Lars Hjemli
In-Reply-To: <4B421F90.4090402@web.de>
Hi,
On Mon, 4 Jan 2010, Jens Lehmann wrote:
> Am 04.01.2010 10:44, schrieb Johannes Schindelin:
> > The real problem is that submodules in the current form are not very
> > well designed.
>
> IMVHO using the tree sha1 for a submodule seems to be the 'natural' way
> to include another git repo. And it gives the reproducibility i expect
> from a scm. Or am i missing something?
You do remember the discussion at the Alles wird Git about the need for
Subversion external-like behavior, right?
> It looks to me as most shortcomings come from the fact that most git
> commands tend to ignore submodules (and if they don't, like git gui and
> gitk do now, they e.g. only show certain aspects of their state).
It is not only ignoring. It is not being able to cope with the state only
submodules can be in (see below).
> Submodules are in heavy use in our company since last year. Virtually
> every patch i submitted for submodules came from that experience and
> scratched an itch i or one of my colleagues had (and the situation did
> already improve noticeably by the few things we changed). We are still
> convinced that using submodules was the right decision. But some work
> has still to be done to be able to use them easily and to get rid of
> some pitfalls.
Submodules may be the best way you have in Git for your workflow ATM.
But that does not mean that the submodule design is in any way
thought-through.
Just a few shortcomings that do show up in my main project (and to a
small extent in msysGit, as you are probably aware):
- submodules were designed with a strong emphasis on not being forced to
check them out. But Git makes it very unconvenient to actually check
submodules out, let alone check them out at clone-time. And it is
outright impossible to _enforce_ a submodule to be checked out.
- among other use cases, submodules are recommended for sharing content
between two different repositories. But it is part of the design that it
is _very_ easy to forget to commit, or push the changes in the submodule
that are required for the integrity of the superproject.
- that use case -- sharing content between different repositories -- is
not really supported by submodules, but rather an afterthought. This is
all too obvious when you look at the restriction that the shared content
must be in a single subdirectory.
- submodules would be a perfect way to provide a fast-forward-only media
subdirectory that is written to by different people (artists) than to
the superproject (developers). But there is no mechanism to enforce
shallow fetches, which means that this use case cannot be handled
efficiently using Git.
- related are the use cases where it is desired not to have a fixed
submodule tip committed to the superproject, but always to update to the
current, say, master (like Subversion's externals). This use case has
been wished away by the people who implemented submodules in Git. But
reality has this nasty habit of ignoring your wishes, does it not?
- there have been patches supporting rebasing submodules, i.e.
submodules where a "git submodule update" rebases the current branch to
the revision committed to the superproject rather than detaching the
HEAD, which everybody who ever contributed to a project with submodules
should agree is a useful thing. But the patches only have been discussed
to death, to the point where the discussion's information content was
converging to zero, yet the patches did not make it into Git. (FWIW
this is one reason why I refuse to write patches to git-submodule.sh: I
refuse to let my time to be wasted like that.)
- working directories with GIT_DIRs are a very different beast from single
files. That alone leads to a _lot_ of problems. The original design of
Git had only a couple of states for named content (AKA files): clean,
added, removed, modified. The states that are possible with submodules
are for the most part not handled _at all_ by most Git commands (and it
is sometimes very hard to decide what would be the best way to handle
those states, either). Just think of a submodule at a different
revision than committed in the superproject, with uncommitted changes,
ignored and unignored files, a few custom hooks, a bit of additional
metadata in the .git/config, and just for fun, a few temporary files in
.git/ which are used by the hooks.
- while it might be called clever that the submodules' metadata are stored
in .gitmodules in the superproject (and are therefore naturally tracked
with Git), the synchronization with .git/config is performed exactly
once -- when you initialize the submodule. You are likely to miss out
on _every_ change you pulled into the superproject.
All in all, submodules are very clumsy to work with, and you are literally
forced to provide scripts in the superproject to actually work with the
submodules.
> > In ths short run, we can paper over the shortcomings of the submodules
> > by introducing a command line option "--include-submodules" to
> > update-refresh, diff-files and diff-index, though.
>
> Maybe this is the way to go for now (and hopefully we can turn this
> option on by default later because we did the right thing ;-).
I do not think that --include-submodules is a good default. It is just
too expensive in terms of I/O even to check the status in a superproject
with a lot of submodules.
Besides, as long as there is enough reason to have out-of-Git alternative
solutions such as repo, submodules deserve to be 2nd-class citizens.
Ciao,
Dscho
^ permalink raw reply
* Re: submodules' shortcomings, was Re: RFC: display dirty submodule working directory in git gui and gitk
From: Shawn O. Pearce @ 2010-01-04 22:27 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jens Lehmann, Git Mailing List, Junio C Hamano, Paul Mackerras,
Heiko Voigt, Lars Hjemli
In-Reply-To: <alpine.DEB.1.00.1001042217370.4985@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Besides, as long as there is enough reason to have out-of-Git alternative
> solutions such as repo, submodules deserve to be 2nd-class citizens.
If I didn't think I'd be shot by current submodule users, I'd offer
to write a full replacement based around the current in repository
format, but with sane features like we have in repo.
Actually, that's why repo happened. I felt like submodules was
already too frozen to accept a different approach. And another
guy here thought XML might be a solution to a problem... :-|
--
Shawn.
^ permalink raw reply
* Re: submodules' shortcomings, was Re: RFC: display dirty submodule working directory in git gui and gitk
From: Avery Pennarun @ 2010-01-04 22:35 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Johannes Schindelin, Jens Lehmann, Git Mailing List,
Junio C Hamano, Paul Mackerras, Heiko Voigt, Lars Hjemli
In-Reply-To: <20100104222701.GE22872@spearce.org>
On Mon, Jan 4, 2010 at 5:27 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>> Besides, as long as there is enough reason to have out-of-Git alternative
>> solutions such as repo, submodules deserve to be 2nd-class citizens.
>
> If I didn't think I'd be shot by current submodule users, I'd offer
> to write a full replacement based around the current in repository
> format, but with sane features like we have in repo.
Perhaps write it and call it 'git sub' or something. Put them both
in, and let users decide which they want to use. Or, like git
subtree, maintain it separately.
Personally, I've avoided tools like repo because they seem to try to
kidnap my *entire* git experience, most of which is already fine.
It's just submodules that are crazy. I think it's probably similar
for other people.
Avery
^ permalink raw reply
* Re: edit Author/Date metadata as part of 'git commit' $EDITOR invocation?
From: Sverre Rabbelier @ 2010-01-04 22:52 UTC (permalink / raw)
To: Adam Megacz; +Cc: git
In-Reply-To: <xuu2zl4tfuij.fsf@nowhere.com>
Heya,
On Mon, Jan 4, 2010 at 16:08, Adam Megacz <adam@megacz.com> wrote:
> Perhaps a preference (off by default) demanding that they be set
> explicitly when "git commit -m" is used?
Heh, what use would that be? On a different/new box you would have
neither that setting nor the email set, so that doens't solve the
problem methinks :P.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: submodules' shortcomings, was Re: RFC: display dirty submodule working directory in git gui and gitk
From: Avery Pennarun @ 2010-01-04 22:53 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jens Lehmann, Git Mailing List, Junio C Hamano, Shawn O. Pearce,
Paul Mackerras, Heiko Voigt, Lars Hjemli
In-Reply-To: <alpine.DEB.1.00.1001042217370.4985@pacific.mpi-cbg.de>
On Mon, Jan 4, 2010 at 5:29 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> On Mon, 4 Jan 2010, Jens Lehmann wrote:
>> IMVHO using the tree sha1 for a submodule seems to be the 'natural' way
>> to include another git repo. And it gives the reproducibility i expect
>> from a scm. Or am i missing something?
>
> You do remember the discussion at the Alles wird Git about the need for
> Subversion external-like behavior, right?
I'm not sure why this is such an issue. Basically, non-version-locked
submodules are about the easiest thing in the world; that's why CVS
and SVN supported them first. (SVN later added version-locking like
git has.)
All you need is a .gitignore entry and a trivial script that checks
out the external. If you want to be fancy, this operation could be
part of git, but it's such a totally different case (and an easy one,
no less) that I think it ought to be treated totally seperately.
> - among other use cases, submodules are recommended for sharing content
> between two different repositories. But it is part of the design that it
> is _very_ easy to forget to commit, or push the changes in the submodule
> that are required for the integrity of the superproject.
[...]
> - working directories with GIT_DIRs are a very different beast from single
> files. That alone leads to a _lot_ of problems. The original design of
> Git had only a couple of states for named content (AKA files): clean,
> added, removed, modified. The states that are possible with submodules
> are for the most part not handled _at all_ by most Git commands (and it
> is sometimes very hard to decide what would be the best way to handle
> those states, either). Just think of a submodule at a different
> revision than committed in the superproject, with uncommitted changes,
> ignored and unignored files, a few custom hooks, a bit of additional
> metadata in the .git/config, and just for fun, a few temporary files in
> .git/ which are used by the hooks.
I think this is primarily because checked-out submodules currently
have their own .git directories (with their own config, index, etc).
If they were considered *part* of the subproject's repo checkout, and
updated upon switching branches, etc, this whole class of problems
would go away.
> - that use case -- sharing content between different repositories -- is
> not really supported by submodules, but rather an afterthought. This is
> all too obvious when you look at the restriction that the shared content
> must be in a single subdirectory.
I haven't found the subdir requirement to be much of an issue, at
least on Unix where I can simply work around it using symlinks from
the superproject into the subproject. It's obviously more gross on
Windows, but I've worked around it there too. This one isn't a daily
aggravation for me, though maybe it is for others. And any cure I can
think of sounds rather worse than the disease.
> - submodules would be a perfect way to provide a fast-forward-only media
> subdirectory that is written to by different people (artists) than to
> the superproject (developers). But there is no mechanism to enforce
> shallow fetches, which means that this use case cannot be handled
> efficiently using Git.
I doubt you want to "enforce" shallow fetches. And if you just want
to "allow" shallow fetches, or default to shallow fetches, I'd think
it would be pretty easy to add. This hasn't been important to me
either. (It seems to be not too important to git users in general, or
git's support *in general* for shallow repositories would be more
featureful.)
> - while it might be called clever that the submodules' metadata are stored
> in .gitmodules in the superproject (and are therefore naturally tracked
> with Git), the synchronization with .git/config is performed exactly
> once -- when you initialize the submodule. You are likely to miss out
> on _every_ change you pulled into the superproject.
This could be fixed too, though I gave up on git-submodule before I
bothered to fix it myself.
The correct solution here is simply to not ever copy the settings from
.gitmodules into .git/config. Instead, git-submodule should read
.gitmodules as defaults, and then override those defaults with
anything in .git/config. 99% of users will probably not need to ever
put any of their settings in .git/config, and so this problem
disappears.
> All in all, submodules are very clumsy to work with, and you are literally
> forced to provide scripts in the superproject to actually work with the
> submodules.
Agreed; I do this in every project which uses git-submodule. (And
from doing so, I learned that the value-added of git-submodule is
nearly zero. My script does most of the work, and it could just as
easily check out the submodule as a git repo too. I could even choose
to version-lock or not version-lock the checked-out submodule: just
hardcode the commitid into my script!)
> I do not think that --include-submodules is a good default. It is just
> too expensive in terms of I/O even to check the status in a superproject
> with a lot of submodules.
I've thought about this a lot, and I think having a special case for
submodules here is the wrong line of thinking. A big project
*without* submodules has this same problem. The "real" solution is to
just make status checks faster.
(This is actually possible to do: in the extreme case, you just have a
daemon running with inotify or the Windows equivalent. TortoiseSvn
reputedly does something like this. I've thought of writing such a
daemon myself to just twiddle --assume-{un,}changed flags at the right
times, particularly since status checks in Windows are so ridiculously
slow. But I got frustrated when it was *still* slow even after
setting --assume-unchanged on all the files in the index. git still
scans directories to detect *unknown* files, and there seems to be no
way to turn it off or, moreover, to provide the list of unknown files
from some other source.)
Have fun,
Avery
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2010, #01; Mon, 04)
From: Junio C Hamano @ 2010-01-05 1:35 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4B421766.4040506@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
> Junio C Hamano schrieb:
>> * jk/run-command-use-shell (2010-01-01) 8 commits
>> - t4030, t4031: work around bogus MSYS bash path conversion
>> - t0021: use $SHELL_PATH for the filter script
>> - diff: run external diff helper with shell
>> - textconv: use shell to run helper
>> - editor: use run_command's shell feature
>> - run-command: optimize out useless shell calls
>> - run-command: convert simple callsites to use_shell
>> - run-command: add "use shell" option
>
> Two notes about this:
>
> 1. My patch "t0021:..." contains an unrelated change to t4030 (it
> changes a /bin/sh to $SHELL_PATH) that is not necessary. I included it
> in my first version of the patch, but later noticed that we already
> have many similar uses of /bin/sh instead of $SHELL_PATH in test
> scriptlets and decided to remove the change, but I only changed the
> commit message and forgot to unstage t4030.
While you are technically correct that the change you made in t4030 is not
justified by the commit log message in the sense that the "hexdump" script
will go through run_command() interface and is not subject to the special
rules filter writers need to keep in mind, the patch text itself is a good
change, isn't it? Do you want me to split the commit into two (one with
the current message with a patch only to t0021, and another to t4030 with
a justification like "SHELL_PATH is what the user told us to use")?
> 2. If you intend to merge the early part of the topic to master early
> and hold "diff:..." and "textconv:..." in next a bit longer (as
> proposed by Jeff), then you should move "t0021:..." after
> "run-command: optimize out useless shell calls".
As "run-command: convert simple callsites to use_shell" is the one that
changes the filter_buffer(), do you want to have t0021 patch before that
one, to prepare the test for the coming change?
^ permalink raw reply
* Re: A question about changing remote repo name
From: Dongas @ 2010-01-05 1:53 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20100104200908.GS29803@genesis.frugalware.org>
2010/1/5 Miklos Vajna <vmiklos@frugalware.org>:
> On Mon, Jan 04, 2010 at 02:45:09PM +0800, Dongas <dongas86@gmail.com> wrote:
>> I'm running ubuntu 9.04 and the git coming along with it doesn't
>> support git remote rename command.
>
> It first appeared in v1.6.1, about a year ago. What does 'git version'
> say?
Thanks a lot for your reply.
# git --version
git version 1.6.0.4
It seems the ubuntu9.04 doesn't have the repo source to update to a
higher git version than 1.6.0.4,
i'd like to know if there's a manual way to rename the git remote name
with this version.
Regards
Dongas
^ permalink raw reply
* cannot remove remote branch name
From: SungHyun Nam @ 2010-01-05 1:57 UTC (permalink / raw)
To: git
Hello,
How I can remove remote branch name if it already removed
in remote side?
$ git branch -a
* master
remotes/origin/HEAD -> origin/master
remotes/origin/master
remotes/origin/test
$ git branch -D -r test
error: remote branch 'test' not found.
$ git branch -D -r remotes/origin/test
error: remote branch 'remotes/origin/test' not found.
$ git branch -D remotes/origin/test
error: branch 'remotes/origin/test' not found.
The 'remotes/origin/test' was removed in remote side.
Thanks,
namsh
^ permalink raw reply
* Re: A question about changing remote repo name
From: Erik Faye-Lund @ 2010-01-05 1:57 UTC (permalink / raw)
To: Dongas; +Cc: Miklos Vajna, git
In-Reply-To: <60ce8d251001041753y5fe37b9do8d4cffc477e58198@mail.gmail.com>
On Tue, Jan 5, 2010 at 2:53 AM, Dongas <dongas86@gmail.com> wrote:
> 2010/1/5 Miklos Vajna <vmiklos@frugalware.org>:
>> On Mon, Jan 04, 2010 at 02:45:09PM +0800, Dongas <dongas86@gmail.com> wrote:
>>> I'm running ubuntu 9.04 and the git coming along with it doesn't
>>> support git remote rename command.
>>
>> It first appeared in v1.6.1, about a year ago. What does 'git version'
>> say?
>
> Thanks a lot for your reply.
>
> # git --version
> git version 1.6.0.4
>
> It seems the ubuntu9.04 doesn't have the repo source to update to a
> higher git version than 1.6.0.4,
> i'd like to know if there's a manual way to rename the git remote name
> with this version.
>
I know this isn't REALLY answering your question, but you should
seriously consider upgrading. 1.6.0.4 is ancient.
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: cannot remove remote branch name
From: Erik Faye-Lund @ 2010-01-05 1:59 UTC (permalink / raw)
To: SungHyun Nam; +Cc: git
In-Reply-To: <hhu694$3v9$1@ger.gmane.org>
On Tue, Jan 5, 2010 at 2:57 AM, SungHyun Nam <goweol@gmail.com> wrote:
> Hello,
>
> How I can remove remote branch name if it already removed
> in remote side?
>
> $ git branch -a
> * master
> remotes/origin/HEAD -> origin/master
> remotes/origin/master
> remotes/origin/test
> $ git branch -D -r test
> error: remote branch 'test' not found.
> $ git branch -D -r remotes/origin/test
> error: remote branch 'remotes/origin/test' not found.
> $ git branch -D remotes/origin/test
> error: branch 'remotes/origin/test' not found.
>
> The 'remotes/origin/test' was removed in remote side.
>
$ git remote prune origin
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: cannot remove remote branch name
From: Junio C Hamano @ 2010-01-05 2:18 UTC (permalink / raw)
To: SungHyun Nam; +Cc: git
In-Reply-To: <hhu694$3v9$1@ger.gmane.org>
SungHyun Nam <goweol@gmail.com> writes:
> How I can remove remote branch name if it already removed
> in remote side?
>
> $ git branch -a
> * master
> remotes/origin/HEAD -> origin/master
> remotes/origin/master
> remotes/origin/test
> $ git branch -D -r test
> error: remote branch 'test' not found.
> $ git branch -D -r remotes/origin/test
> error: remote branch 'remotes/origin/test' not found.
> $ git branch -D remotes/origin/test
> error: branch 'remotes/origin/test' not found.
Hmm, you tried "test" and then "remotes/origin/test"?
The way I would have guessed what to give the command is:
1. "branch -D -r test" wouldn't make sense, as git wouldn't know 'test'
of which remote I am trying to remove;
2. "-r" already tells git that I am talking about remote, so perhaps
"branch -D -r origin/test" would work without me saying "remotes/".
"git branch -[dD]" doesn't go over the network, so it doesn't matter if it
is already removed on the remote side or not.
^ permalink raw reply
* Re: A question about changing remote repo name
From: Dongas @ 2010-01-05 2:25 UTC (permalink / raw)
To: kusmabite; +Cc: Miklos Vajna, git
In-Reply-To: <40aa078e1001041757q137c9d1erf8f6793016d6a2c2@mail.gmail.com>
2010/1/5 Erik Faye-Lund <kusmabite@googlemail.com>:
> On Tue, Jan 5, 2010 at 2:53 AM, Dongas <dongas86@gmail.com> wrote:
>> 2010/1/5 Miklos Vajna <vmiklos@frugalware.org>:
>>> On Mon, Jan 04, 2010 at 02:45:09PM +0800, Dongas <dongas86@gmail.com> wrote:
>>>> I'm running ubuntu 9.04 and the git coming along with it doesn't
>>>> support git remote rename command.
>>>
>>> It first appeared in v1.6.1, about a year ago. What does 'git version'
>>> say?
>>
>> Thanks a lot for your reply.
>>
>> # git --version
>> git version 1.6.0.4
>>
>> It seems the ubuntu9.04 doesn't have the repo source to update to a
>> higher git version than 1.6.0.4,
>> i'd like to know if there's a manual way to rename the git remote name
>> with this version.
>>
>
> I know this isn't REALLY answering your question, but you should
> seriously consider upgrading. 1.6.0.4 is ancient.
>
Thanks a lot for your advices.
Unfortunately, all my team members are running ubuntu 9.04.
If i could find a easy way to upgrade it, it will take it.
Regards
Dongas
^ permalink raw reply
* Re: A question about changing remote repo name
From: Russell Steicke @ 2010-01-05 2:52 UTC (permalink / raw)
To: Dongas; +Cc: git
In-Reply-To: <60ce8d251001032245n4e0267b1o1ecc796f324f8179@mail.gmail.com>
On Mon, Jan 4, 2010 at 2:45 PM, Dongas <dongas86@gmail.com> wrote:
> So i need to change the remote name manually.
>
> I tried modifying the .git/config file locally but it didn't work.
>
> Could someone help tell how to do it?
After editing .git/config, do this:
$ mv .git/refs/remotes/OLDNAME .git/refs/remotes/NEWNAME
and optionally:
$ mv .git/logs/refs/remotes/OLDNAME .git/logs/refs/remotes/NEWNAME
Remember to rename the remote in any tracking branches in .git/config,
as well as the name in the [remote "OLDNAME"] section, and the name in
any fetch and push lines. ie
[remote "OLDNAME"]
url = something
fetch = +refs/heads/*:refs/remotes/OLDNAME/*
[branch "master"]
remote = OLDNAME
merge = refs/heads/master
Becomes
[remote "NEWNAME"]
url = something
fetch = +refs/heads/*:refs/remotes/NEWNAME/*
[branch "master"]
remote = NEWNAME
merge = refs/heads/master
--
Virus found in this message.
^ permalink raw reply
* Re: "git add -i" with path gives "Argument list too long"
From: Jeff King @ 2010-01-05 4:14 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Junio C Hamano, git
In-Reply-To: <36FEB8A0-968D-4B43-AEFB-9B0E227A1F88@wincent.com>
[cc'd Junio: there is a question of path limiters versus pathspecs near
the bottom].
On Mon, Jan 04, 2010 at 07:43:10PM +0100, Wincent Colaiuta wrote:
> Just ran "git add -i <path>" with "<path>" pointing to a subdirectory
> which happens to have a bunch of files in it (about 7k) and it barfed
> thusly:
>
> Can't exec "git": Argument list too long at /usr/local/libexec/git-
> core/git-add--interactive line 158.
> Died at /usr/local/libexec/git-core/git-add--interactive line 158.
>
> I see that what it's trying to do under the hood is:
>
> git diff-index --cached --numstat --summary HEAD -- <7,000+ paths...>
Yep, and there is a similar diff-files call after that.
> Sure, we could divide the paths into smaller groups, run multiple
> invocations of "git diff-index", and concatenate the results. But it
> would be nicer if there was some other way that we could get at the
> same information without having to pass 7,000 paths explicitly on the
> command line; is there any which I am overlooking?
No, I don't think there is way to do it with the current code short of
breaking up the output.
> The enormous file list is the result of passing <path> into "git ls-
> files -- <path>". Would it be worth:
>
> - either, modifying "git diff-index" to accept a list of paths over
> stdin so that we could at least pipe the output from "git ls-files"
> into "git diff-index"
We could do that. It would also need a patch for diff-files. And
unfortunately it makes their interface somewhat inconsistent then with
diff-tree, which already has a --stdin but uses it for a list of
tree-ishes.
> - or, preferably, teach "git diff index" to recurse into directories
> rather than expect a list of paths-of-blobs (possibly with a command
> line switch to activate the behaviour if it were deemed a dangerous
> default)
Doesn't it already do this? If I say "git diff index subdir" it
will limit the diff only to things inside subdir/.
In fact, it is tempting to do this:
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index bfd1003..a8b3e30 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -275,15 +275,6 @@ sub list_modified {
my ($only) = @_;
my (%data, @return);
my ($add, $del, $adddel, $file);
- my @tracked = ();
-
- if (@ARGV) {
- @tracked = map {
- chomp $_;
- unquote_path($_);
- } run_cmd_pipe(qw(git ls-files --), @ARGV);
- return if (!@tracked);
- }
my $reference;
if (defined $patch_mode_revision and $patch_mode_revision ne 'HEAD') {
@@ -295,7 +286,7 @@ sub list_modified {
}
for (run_cmd_pipe(qw(git diff-index --cached
--numstat --summary), $reference,
- '--', @tracked)) {
+ '--', @ARGV)) {
if (($add, $del, $file) =
/^([-\d]+) ([-\d]+) (.*)/) {
my ($change, $bin);
@@ -320,7 +311,7 @@ sub list_modified {
}
}
- for (run_cmd_pipe(qw(git diff-files --numstat --summary --), @tracked)) {
+ for (run_cmd_pipe(qw(git diff-files --numstat --summary --), @ARGV)) {
if (($add, $del, $file) =
/^([-\d]+) ([-\d]+) (.*)/) {
$file = unquote_path($file);
but note that the pathspecs given to ls-files and the path limiters
given to diff are not quite the same. So "git add -i '*.c'" will
currently find "subdir/foo.c", but would not with the above patch. Is
that what you meant when you said "recurse into directories"?
I seem to recall Junio noting in the past the inconsistencies in git
about what is a path and what is a pathspec. Is this one of those
inconsistencies, and would it be a positive thing to fix it?
-Peff
^ permalink raw reply related
* Re: What's cooking in git.git (Jan 2010, #01; Mon, 04)
From: Jeff King @ 2010-01-05 4:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <7vhbr1bagk.fsf@alter.siamese.dyndns.org>
On Mon, Jan 04, 2010 at 05:35:07PM -0800, Junio C Hamano wrote:
> > 1. My patch "t0021:..." contains an unrelated change to t4030 (it
> > changes a /bin/sh to $SHELL_PATH) that is not necessary. I included it
> > in my first version of the patch, but later noticed that we already
> > have many similar uses of /bin/sh instead of $SHELL_PATH in test
> > scriptlets and decided to remove the change, but I only changed the
> > commit message and forgot to unstage t4030.
>
> While you are technically correct that the change you made in t4030 is not
> justified by the commit log message in the sense that the "hexdump" script
> will go through run_command() interface and is not subject to the special
> rules filter writers need to keep in mind, the patch text itself is a good
> change, isn't it? Do you want me to split the commit into two (one with
> the current message with a patch only to t0021, and another to t4030 with
> a justification like "SHELL_PATH is what the user told us to use")?
If we are going to do the t4030 change, there are a ton of other spots
that use /bin/sh directly (I counted 38 with
grep -n /bin/sh * | grep -v :1:
). Should we be changing all of them?
It is slightly just code churn, because the scripts are so simple that
even broken shells like Solaris /bin/sh run them just fine. The only
real advantage is that it slightly future-proofs them against somebody
making them more complex.
-Peff
^ 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