* Re: git file sharing/versioning.
From: Nicolas Sebrecht @ 2010-01-05 20:10 UTC (permalink / raw)
To: Bas Driessen; +Cc: git, Nicolas Sebrecht
In-Reply-To: <1262580426.9041.21.camel@ams.xobas.net>
The 04/01/10, Bas Driessen wrote:
> I have a project where I have 2 trees with several hundreds of files.
> Let's call them tree1 and tree2. Only a handful of files in tree2 are
> different. What is the best way to set this up in GIT? Basically most
> files in tree2 should act as a symbolic link to tree1. So if the file
> changes in tree 1, it automatically changes in tree 2. Obviously, I
> don't want to store everything double. Branching does not appear to be
> an option as changes in tree1 would not be visible in the tree2 branch.
Look at:
git merge --help
git rebase --help
git cherry-pick --help
--
Nicolas Sebrecht
^ permalink raw reply
* Re: submodules' shortcomings, was Re: RFC: display dirty submodule working directory in git gui and gitk
From: Jens Lehmann @ 2010-01-05 20:01 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Git Mailing List, Shawn O. Pearce,
Paul Mackerras, Heiko Voigt, Lars Hjemli, Avery Pennarun
In-Reply-To: <7vd41oz9mp.fsf@alter.siamese.dyndns.org>
Am 05.01.2010 19:31, schrieb Junio C Hamano:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
>> b) new unignored files
>> IMO these files should show up too (the superproject doesn't show
>> ignored files, the submodule state shouldn't do that either). But
>> OTOH i don't see a possibility for loss of data when this state is
>> not shown.
>
> I don't know if we are talking about the same scenario. What I had in
> mind was:
>
> cd sub
> edit new-file
> tests ok and be happy
> git commit
> cd ..
> git status
> git commit
>
> forgetting that only you have sub/new-file in the world. It is not loss
> of data, but still bad. Forgetting to add a new-file and committing in a
> project without submodule doesn't lose data, but the resulting commit will
> be seen as broken by other people.
I'm not quite sure, i was rather thinking about something like this:
cd sub
edit new-file
cd ..
<use sub/new-file here, test ok and be happy>
git status
git commit
git push
git status won't show you that sub has any new files and so you won't be
reminded that you still have to add, commit and push it in the submodule
before you should even commit, let alone push in the superproject.
It is a possible breakage for other people if sub/new-file stays unnoticed.
That's IMO a good point for showing these files too.
>> c) a detached HEAD not on any local *or* remote branch
>> This can be fatal when doing a reset, revert or checkout, so it
>> should be shown. Alternatively when applied on a submodule, forcing
>> could be disabled to let the command fail instead of throwing stuff
>> away.
>
> Sorry, I am lost. Are you worried about "reset/revert/checkout" in the
> superproject? What destructive things do these operations do that you
> consider "fatal"? I am especially puzzled by "revert", as "commit",
> "cherry-pick", and "merge" would have the same "fatal" effect as "revert",
> but I don't get what "fatality" you are talking about here.
Sorry, that was an incomplete description on my part.
My mind had already been warped into in the - hopefully not too distant -
future where these commands will be able to recurse into submodules too
(I ran into this issue recently while trying to teach git gui to revert
submodules). Right now we are blind for this state of the submodule unless
you go inside and use "git status" and friends there. And if you use e.g.
"git reset --hard" there, you can loose the commits on HEAD which aren't
on any branch.
>> d) a detached HEAD not on any remote branch
>> AFAICS this is only important for a push, and could just error out
>> there.
>
> Likewise.
This can be bad in the same way that new unignored files can be (and
there is no time travel involved this time ;-). With HEAD i meant the
submodule commit committed and about to be pushed in the supermodule
(which happens to be the HEAD of the submodule most of the time, but
not always). So you committed sub/new-file but didn't push it anywhere.
This can lead to breakage for other people even with current git. I
think push could check for this and error out, as pushing out a
referenced submodule commit which is not pushed anywhere makes no sense.
But right now i don't believe we would have to show that in the output
of git diff-files and git status, because it is only relevant at the
time when you actually want to push the superproject.
>> Yes, we can leave it that way for now (first "clone" and then "submodule
>> init <the submodules you need>"). We can migrate to the "group mapping"
>> functionality later (which would then allow to force certain submodules
>> to always be populated because they appear in every group).
>
> Even with group mapping, you need to clone the superproject first, before
> seeing the mapping (which I would assume comes in the superproject). And
> you need to see the mapping to decide what group you belong to. After
> that you can finally drive sub-clone to continue (e.g. I work in the
> documentation area, and the group mapping has 'docs' that lets me pull in
> submodules for doc/ and common/ directories, without src/ submodule --- I
> can only learn that the submodules I am interested in are called 'docs' by
> group name or doc/ and common/ subdirectories _after_ I get the clone of
> the superproject).
I think we agree here.
^ permalink raw reply
* Re: [PATCH/RFC] Add support for the google-chrome web browser
From: Junio C Hamano @ 2010-01-05 19:56 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Evan Farrer, git, Christian Couder
In-Reply-To: <32541b131001051056o5853b1d2xd57d75d9a62f9f1a@mail.gmail.com>
Avery Pennarun <apenwarr@gmail.com> writes:
> The current behaviour will barf right away (I think) because it
> doesn't know. If it instead had a default case that just assumed
> non-firefox behaviour, then it would fail *strangely* (instead of
> predictably) on browsers that needed special workarounds, such as an
> as-yet-unknown firefox derivative.
Ok, I can buy that.
I have a feeling that extensibility situation of this script is similar to
that of mergetool/difftool. Perhaps a similar approach to refactor and
then support browser-specific peculiarities by separate files, outlined in
http://thread.gmane.org/gmane.comp.version-control.git/134906/focus=135006
might work well, don't you think?
^ permalink raw reply
* Re: [PATCH/RFC] Add support for the google-chrome web browser
From: Avery Pennarun @ 2010-01-05 18:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Evan Farrer, git, Christian Couder
In-Reply-To: <7v8wccz99g.fsf@alter.siamese.dyndns.org>
On Tue, Jan 5, 2010 at 1:39 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Avery Pennarun <apenwarr@gmail.com> writes:
>> On Tue, Jan 5, 2010 at 12:40 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Then we don't even have to add any specific support for "google-chrome" or
>>> anything that takes "$command $path..." and opens the documents.
>>>
>>> Is there a downside in this approach?
>>
>> If someone has another firefox-derived browser installed with a
>> different name and tries to use it, this default wouldn't do the right
>> "firefoxy" thing, and would instead fail strangely. On the other
>> hand, right now it'll fail anyway, just not strangely.
>
> You probably didn't notice/understand why I singled out w3m/links/open and
> excluded firefox from the set. There is no question that the ones that
> need custom command line need custom support. But to support a new
> browser that takes a bog standard "command then args" command line, there
> is no reason to add cruft, every time somebody comes up with a new browser.
Yes, I'm probably missing something, that would be normal :)
My point is that, given a random browser name, you don't know whether
it's an easy one *or* if it needs to work more like firefox.
The current behaviour will barf right away (I think) because it
doesn't know. If it instead had a default case that just assumed
non-firefox behaviour, then it would fail *strangely* (instead of
predictably) on browsers that needed special workarounds, such as an
as-yet-unknown firefox derivative.
Maybe this isn't important though.
Avery
^ permalink raw reply
* Re: How to exclude files from "git diff"
From: Junio C Hamano @ 2010-01-05 18:41 UTC (permalink / raw)
To: H.J. Lu; +Cc: Dmitry Potapov, Jeff King, git
In-Reply-To: <6dc9ffc81001051015x3bebc994r3d475bdb59e12d39@mail.gmail.com>
"H.J. Lu" <hjl.tools@gmail.com> writes:
> On Tue, Jan 5, 2010 at 9:54 AM, Dmitry Potapov <dpotapov@gmail.com> wrote:
>> On Tue, Jan 5, 2010 at 5:20 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>
>>> Yes, I want those files in repository. They are for my personal use only.
>>
>> If you modified some file locally and do not want to see and commit
>> those modifications, you may want to use:
>>
>> git update-index --assume-unchanged foo
>>
>
> I added those files into my repository for bookkeeping purpose. It
> shouldn't go out at all.
Sounds like time to run "rm --cached" to me. IOW, keep it untracked.
^ permalink raw reply
* Re: [PATCH/RFC] Add support for the google-chrome web browser
From: Junio C Hamano @ 2010-01-05 18:39 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Evan Farrer, git, Christian Couder
In-Reply-To: <32541b131001050920j2a569ec8u8811f1b0358f21ef@mail.gmail.com>
Avery Pennarun <apenwarr@gmail.com> writes:
> On Tue, Jan 5, 2010 at 12:40 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Then we don't even have to add any specific support for "google-chrome" or
>> anything that takes "$command $path..." and opens the documents.
>>
>> Is there a downside in this approach?
>
> If someone has another firefox-derived browser installed with a
> different name and tries to use it, this default wouldn't do the right
> "firefoxy" thing, and would instead fail strangely. On the other
> hand, right now it'll fail anyway, just not strangely.
You probably didn't notice/understand why I singled out w3m/links/open and
excluded firefox from the set. There is no question that the ones that
need custom command line need custom support. But to support a new
browser that takes a bog standard "command then args" command line, there
is no reason to add cruft, every time somebody comes up with a new browser.
^ permalink raw reply
* Re: submodules' shortcomings, was Re: RFC: display dirty submodule working directory in git gui and gitk
From: Junio C Hamano @ 2010-01-05 18:31 UTC (permalink / raw)
To: Jens Lehmann
Cc: Johannes Schindelin, Git Mailing List, Shawn O. Pearce,
Paul Mackerras, Heiko Voigt, Lars Hjemli, Avery Pennarun
In-Reply-To: <4B43292C.5060106@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
> The only thing we show right now are the differences between submodule
> commits and what the superproject has in its index and in its commits.
> Missing are:
>
> a) modified files
> ...
> b) new unignored files
> IMO these files should show up too (the superproject doesn't show
> ignored files, the submodule state shouldn't do that either). But
> OTOH i don't see a possibility for loss of data when this state is
> not shown.
I don't know if we are talking about the same scenario. What I had in
mind was:
cd sub
edit new-file
tests ok and be happy
git commit
cd ..
git status
git commit
forgetting that only you have sub/new-file in the world. It is not loss
of data, but still bad. Forgetting to add a new-file and committing in a
project without submodule doesn't lose data, but the resulting commit will
be seen as broken by other people.
> c) a detached HEAD not on any local *or* remote branch
> This can be fatal when doing a reset, revert or checkout, so it
> should be shown. Alternatively when applied on a submodule, forcing
> could be disabled to let the command fail instead of throwing stuff
> away.
Sorry, I am lost. Are you worried about "reset/revert/checkout" in the
superproject? What destructive things do these operations do that you
consider "fatal"? I am especially puzzled by "revert", as "commit",
"cherry-pick", and "merge" would have the same "fatal" effect as "revert",
but I don't get what "fatality" you are talking about here.
> d) a detached HEAD not on any remote branch
> AFAICS this is only important for a push, and could just error out
> there.
Likewise.
>> I think "clone" has a chicken-and-egg problem. If all of your project
>> ...
>> what kind of participant you are. It has to become two-step process;
>> either "clone" going interactive in the middle, or you let the clone to
>> happen and then "submodule init" to express that information.
>
> Yes, we can leave it that way for now (first "clone" and then "submodule
> init <the submodules you need>"). We can migrate to the "group mapping"
> functionality later (which would then allow to force certain submodules
> to always be populated because they appear in every group).
Even with group mapping, you need to clone the superproject first, before
seeing the mapping (which I would assume comes in the superproject). And
you need to see the mapping to decide what group you belong to. After
that you can finally drive sub-clone to continue (e.g. I work in the
documentation area, and the group mapping has 'docs' that lets me pull in
submodules for doc/ and common/ directories, without src/ submodule --- I
can only learn that the submodules I am interested in are called 'docs' by
group name or doc/ and common/ subdirectories _after_ I get the clone of
the superproject).
I don't know if "this appears in all groups so let's always sub-clone it"
is very useful in practice, but some sort of mandatory clone/checkout
mechanism would be handy.
^ permalink raw reply
* Re: How to exclude files from "git diff"
From: Nguyen Thai Ngoc Duy @ 2010-01-05 18:31 UTC (permalink / raw)
To: H.J. Lu; +Cc: Dmitry Potapov, Jeff King, git
In-Reply-To: <6dc9ffc81001051015x3bebc994r3d475bdb59e12d39@mail.gmail.com>
On 1/6/10, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Tue, Jan 5, 2010 at 9:54 AM, Dmitry Potapov <dpotapov@gmail.com> wrote:
> > On Tue, Jan 5, 2010 at 5:20 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> >>
> >> Yes, I want those files in repository. They are for my personal use only.
> >
> > If you modified some file locally and do not want to see and commit
> > those modifications, you may want to use:
> >
> > git update-index --assume-unchanged foo
> >
>
>
> I added those files into my repository for bookkeeping purpose. It
> shouldn't go out at all.
That could be a way to simulate git diff --exclude="foo*.bar*":
git ls-files -- 'foo*bar*'|xargs git update-index --assume-unchanged
git diff
git ls-files -- 'foo*bar*'|xargs git update-index --no-assume-unchanged
assume that you don't use assume-unchanged for any other purposes
--
Duy
^ permalink raw reply
* checkout -m dumping core
From: Tomas Carnecky @ 2010-01-05 18:15 UTC (permalink / raw)
To: Git List
git version 1.6.6.78.gbd757c
HEAD points to a non-existent branch refs/heads/master. Normal checkout
origin fails with:
error: Entry '.cvsignore' would be overwritten by merge. Cannot merge.
(the working tree does indeed contain this file). So I tried checkout -m
and git crashed. Workaround for me was reset --hard origin; checkout
origin. I have the repository backed up in case someone wants to try
themselves.
$ gdb `which git`
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-pc-solaris2.11"...
(gdb) run checkout -m origin
Starting program: /export/home/tomc/local/git/bin/git checkout -m origin
warning: Lowest section in /lib/libpthread.so.1 is .dynamic at 00000074
Program received signal SIGSEGV, Segmentation fault.
0x080788fa in cmd_checkout (argc=0, argv=0x8047538, prefix=0x0) at
builtin-checkout.c:450
450 merge_trees(&o, new->commit->tree, work,
(gdb) list
445 ret = reset_tree(new->commit->tree,
opts, 1);
446 if (ret)
447 return ret;
448 o.branch1 = new->name;
449 o.branch2 = "local";
450 merge_trees(&o, new->commit->tree, work,
451 old->commit->tree, &result);
452 ret = reset_tree(new->commit->tree,
opts, 0);
453 if (ret)
454 return ret;
(gdb) p o
$1 = {branch1 = 0x8047650 "origin", branch2 = 0x0, subtree_merge = 0,
buffer_output = 1, verbosity = 0, diff_rename_limit = -1,
merge_rename_limit = -1, call_depth = 0, obuf = {alloc = 0, len = 0, buf
= 0x81643ac ""}, current_file_set = {
items = 0x0, nr = 0, alloc = 0, strdup_strings = 1},
current_directory_set = {items = 0x0, nr = 0, alloc = 0, strdup_strings
= 1}}
(gdb) p new
$2 = {name = 0x8047650 "origin", path = 0x8166438 "refs/heads/origin",
commit = 0x8168f48}
(gdb) p work
$3 = (struct tree *) 0x8174f90
(gdb) p old
No symbol "old" in current context.
(gdb) p result
$4 = (struct tree *) 0xfefc81be
(gdb)
^ permalink raw reply
* Re: How to exclude files from "git diff"
From: H.J. Lu @ 2010-01-05 18:15 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Jeff King, git
In-Reply-To: <37fcd2781001050954y778ba661n7cee6cda699968c2@mail.gmail.com>
On Tue, Jan 5, 2010 at 9:54 AM, Dmitry Potapov <dpotapov@gmail.com> wrote:
> On Tue, Jan 5, 2010 at 5:20 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>
>> Yes, I want those files in repository. They are for my personal use only.
>
> If you modified some file locally and do not want to see and commit
> those modifications, you may want to use:
>
> git update-index --assume-unchanged foo
>
I added those files into my repository for bookkeeping purpose. It
shouldn't go out at all.
--
H.J.
^ permalink raw reply
* Re: How to exclude files from "git diff"
From: Dmitry Potapov @ 2010-01-05 17:54 UTC (permalink / raw)
To: H.J. Lu; +Cc: Jeff King, git
In-Reply-To: <6dc9ffc81001050620q55c23072p93f58c8685d77f9d@mail.gmail.com>
On Tue, Jan 5, 2010 at 5:20 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>
> Yes, I want those files in repository. They are for my personal use only.
If you modified some file locally and do not want to see and commit
those modifications, you may want to use:
git update-index --assume-unchanged foo
After that, git will not notice any change to `foo'. So, 'git diff' and any
other command (such git commit -a) will ignore those changes.
Warning: using --assume-unchanged may result in losing your changes
if you switch between branches containing different versions of 'foo'.
Normally, when you try to do that, git will not allow switch to another
branch saying that `foo' is modified. But using --assume-unchanged
disables this check. But if you have the same `foo' on all branches
then switching between branches will preserve your modifications.
Dmitry
^ permalink raw reply
* Re: [PATCH/RFC] Add support for the google-chrome web browser
From: Avery Pennarun @ 2010-01-05 17:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Evan Farrer, git, Christian Couder
In-Reply-To: <7vr5q56rew.fsf@alter.siamese.dyndns.org>
On Tue, Jan 5, 2010 at 12:40 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Then we don't even have to add any specific support for "google-chrome" or
> anything that takes "$command $path..." and opens the documents.
>
> Is there a downside in this approach?
If someone has another firefox-derived browser installed with a
different name and tries to use it, this default wouldn't do the right
"firefoxy" thing, and would instead fail strangely. On the other
hand, right now it'll fail anyway, just not strangely.
So your proposed change would decrease the number of failures, but
increase the strangeness of the remaining failures. Maybe that's the
right thing to do though.
Avery
^ permalink raw reply
* Re: am fails to apply patches for files with CRLF lineendings
From: Brandon Casey @ 2010-01-05 16:41 UTC (permalink / raw)
To: Jason King; +Cc: Junio C Hamano, Björn Steinbrink, git, Brandon Casey
In-Reply-To: <F25E4EFA-BDD8-4920-96FC-2347AD5A3605@silentcow.com>
Jason King wrote:
> I just grabbed 1.6.6 and noticed that this problem still exists. I just
> wanted to ping this thread to make sure this hadn't been forgotten.
I am interested in fixing this but have not been able to get to it.
-brandon
^ permalink raw reply
* Re: Re: submodules' shortcomings, was Re: RFC: display dirty submodule working directory in git gui and gitk
From: Johannes Schindelin @ 2010-01-05 15:30 UTC (permalink / raw)
To: Heiko Voigt
Cc: Jens Lehmann, Git Mailing List, Junio C Hamano, Shawn O. Pearce,
Paul Mackerras, Lars Hjemli, Avery Pennarun
In-Reply-To: <20100105142727.GA83546@book.hvoigt.net>
Hi,
On Tue, 5 Jan 2010, Heiko Voigt wrote:
> On Tue, Jan 05, 2010 at 10:46:11AM +0100, Johannes Schindelin wrote:
> > On Tue, 5 Jan 2010, Jens Lehmann wrote:
> > > Yes. This synchronization could be either obsoleted by only using
> > > .gitmodules or automated.
> >
> > I start to wonder whether the insistence that .gitmodules' settings must
> > be overrideable makes any sense in practice.
>
> I just read this and felt the need to comment.
>
> Yes, it definitely makes sense in practise to have it overrideable
> otherwise we loose the distributed nature of git for submodules.
AFAICT you can use url.<base>.insteadOf for that.
Or maybe even better use a different remote for that, as you are likely
wanting to stay up-to-date with the upstream projects even if you work on
the stuff locally.
> But I know what you mean by the general confusion about manual updates.
> So how about an approach like this:
>
> * clone will initialise all submodules in .git/config from .gitmodules
>
> * if a change in .gitmodules happens git scans .git/config for that
> entry and in case nothing is there it syncronises the new one and
> notifies the user.
>
> * if a change in .gitmodules happens and the entry before was the same
> in .git/config we also automatically update that entry there.
>
> * In every other case we just leave .git/config alone.
I'm sorry, but this is the kind of stuff I am seeing in Git: a lot of
really complicated design with a lot of corner cases, put on top of a
really simple and elegant design.
So I'd like to see a solution that is obviously superior by being
plain simple.
Ciao,
Dscho
^ permalink raw reply
* Re: submodules' shortcomings, was Re: RFC: display dirty submodule working directory in git gui and gitk
From: Johan Herland @ 2010-01-05 15:07 UTC (permalink / raw)
To: Heiko Voigt
Cc: git, Johannes Schindelin, Jens Lehmann, Junio C Hamano,
Shawn O. Pearce, Paul Mackerras, Lars Hjemli, Avery Pennarun
In-Reply-To: <20100105142727.GA83546@book.hvoigt.net>
On Tuesday 05 January 2010, Heiko Voigt wrote:
> P.S.: Additionally (for my use case) we could add a "hint mechanism"
> which allows git to "guess" a new submodules address. For example in
> case I have all my local clones on
> "git@my.server.net:<modulename>.git". Now when a new submodule gets
> seen in .gitmodules it will infer the address from the hint
> configuration and not take the original one from upstream.
This can be achieved today, if the upstream .gitmodules uses relative
submodule URLs. I normally place super-repo and submodules in a single
directory on the server, and use submodule URLs of the
form "../<modulename>.git". Now, downstream developers can "git
clone --mirror" the repos from my server, and - as long as they
preserve the directory layout - provide their own complete server
mirror, without editing .gitmodules. Granted, the existing submodule
tools don't make working with relative submodule URLs particularily
easy...
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: Re: submodules' shortcomings, was Re: RFC: display dirty submodule working directory in git gui and gitk
From: Heiko Voigt @ 2010-01-05 14:27 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jens Lehmann, Git Mailing List, Junio C Hamano, Shawn O. Pearce,
Paul Mackerras, Lars Hjemli, Avery Pennarun
In-Reply-To: <alpine.DEB.1.00.1001051032440.4985@pacific.mpi-cbg.de>
On Tue, Jan 05, 2010 at 10:46:11AM +0100, Johannes Schindelin wrote:
> On Tue, 5 Jan 2010, Jens Lehmann wrote:
> > Yes. This synchronization could be either obsoleted by only using
> > .gitmodules or automated.
>
> I start to wonder whether the insistence that .gitmodules' settings must
> be overrideable makes any sense in practice.
I just read this and felt the need to comment.
Yes, it definitely makes sense in practise to have it overrideable
otherwise we loose the distributed nature of git for submodules.
Imagine you fork a project and you want to work with others on a change
that involves chaning a subproject. If you can not override .gitmodules
you can only work on the central repository.
I am actually working like this in practise. I have a private clone of
all the subprojects msysgit has and commit/push locally first. Once I
sense the change is going to be useful for a wider audience I send it
upstream. This would be more uncomfortable if it is not overideable.
But I know what you mean by the general confusion about manual updates.
So how about an approach like this:
* clone will initialise all submodules in .git/config from .gitmodules
* if a change in .gitmodules happens git scans .git/config for that
entry and in case nothing is there it syncronises the new one and
notifies the user.
* if a change in .gitmodules happens and the entry before was the same
in .git/config we also automatically update that entry there.
* In every other case we just leave .git/config alone.
Did I miss anything? I think you should get the idea and that it could
get rid of the confusion caused by manual .gitmodule updates.
cheers Heiko
P.S.: Additionally (for my use case) we could add a "hint mechanism"
which allows git to "guess" a new submodules address. For example in
case I have all my local clones on "git@my.server.net:<modulename>.git".
Now when a new submodule gets seen in .gitmodules it will infer the
address from the hint configuration and not take the original one from
upstream.
^ permalink raw reply
* Re: How to exclude files from "git diff"
From: H.J. Lu @ 2010-01-05 14:20 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20100105064509.GC19025@coredump.intra.peff.net>
On Mon, Jan 4, 2010 at 10:45 PM, Jeff King <peff@peff.net> wrote:
> On Fri, Dec 18, 2009 at 09:09:15AM -0800, H.J. Lu wrote:
>
>> I have some bookkeeping files in my git repository. How do I
>> exclude them from "git diff"? Does "git diff" support
>>
>> # git diff --exclude="foo.*.bar*"
>
> No, I don't believe there is a way to do that. You would have to do
> something like:
>
> git diff $(git ls-files | grep -v whatever)
>
> The usual concept of "exclusion" for git is not to track files at all
> via the .gitignore mechanism. Are these files that have content you
> really _want_ in the repository, but you just don't want to see them
> when doing some diffs? Or are they files that could not be in the
> repository at all?
Yes, I want those files in repository. They are for my personal use only.
Thanks.
--
H.J.
^ permalink raw reply
* [PATCH RFC] gitk: display submodule diffs with appropriate encoding
From: Kirill Smelkov @ 2010-01-05 12:44 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Kirill Smelkov, git
Previsously, when submodule commits headings contained non-latin-1
characters, they were displayed incorrectly in gitk, because $line was
not properly decoded, i.e.
----------------------------- Documentation/Dokko -----------------------------
Submodule Documentation/Dokko 2ca20c7..0ea204d:
> ßрþтþúþûы ÑÂþÿрÑÂöõýøѠØÃχ "ÃœþÑÂтøú-21631" (ÛØ2 ø áðýôðû)
> hardware: ôþúуüõýтðцøѠýð InnoDisk SATA 10000
> hardware: ôþúуüõýтðцøѠýð IEI PCISA-6770E2 v3.0
> hardware: ôþúуüõýтðцøѠýð Fastwel NIB941
> hardware: ôþúуüõýтðцøѠýð IEI IPX-9S
> hardware: ôþúуüõýтðцøѠýð Hirschmann 5TX-EEC
instead of
----------------------------- Documentation/Dokko -----------------------------
Submodule Documentation/Dokko 2ca20c7..0ea204d:
> Протоколы ÑопрÑÐ¶ÐµÐ½Ð¸Ñ Ð˜ÐœÐ¡ "МоÑтик-21631" (ЛИ2 и Сандал)
> hardware: Ð´Ð¾ÐºÑƒÐ¼ÐµÐ½Ñ‚Ð°Ñ†Ð¸Ñ Ð½Ð° InnoDisk SATA 10000
> hardware: Ð´Ð¾ÐºÑƒÐ¼ÐµÐ½Ñ‚Ð°Ñ†Ð¸Ñ Ð½Ð° IEI PCISA-6770E2 v3.0
> hardware: Ð´Ð¾ÐºÑƒÐ¼ÐµÐ½Ñ‚Ð°Ñ†Ð¸Ñ Ð½Ð° Fastwel NIB941
> hardware: Ð´Ð¾ÐºÑƒÐ¼ÐµÐ½Ñ‚Ð°Ñ†Ð¸Ñ Ð½Ð° IEI IPX-9S
> hardware: Ð´Ð¾ÐºÑƒÐ¼ÐµÐ½Ñ‚Ð°Ñ†Ð¸Ñ Ð½Ð° Hirschmann 5TX-EEC
This fixes it.
Signed-off-by: Kirill Smelkov <kirr@landau.phys.spbu.ru>
---
gitk | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/gitk b/gitk
index 86dff0f..0edef8f 100755
--- a/gitk
+++ b/gitk
@@ -7689,8 +7689,10 @@ proc getblobdiffline {bdf ids} {
makediffhdr $fname $ids
$ctext insert end "\n$line\n" filesep
} elseif {![string compare -length 3 " >" $line]} {
+ set line [encoding convertfrom $diffencoding $line]
$ctext insert end "$line\n" dresult
} elseif {![string compare -length 3 " <" $line]} {
+ set line [encoding convertfrom $diffencoding $line]
$ctext insert end "$line\n" d0
} elseif {$diffinhdr} {
if {![string compare -length 12 "rename from " $line]} {
--
1.6.6.78.gbd757c.dirty
^ permalink raw reply related
* Re: "git add -i" with path gives "Argument list too long"
From: Wincent Colaiuta @ 2010-01-05 12:34 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20100105041438.GB12574@coredump.intra.peff.net>
El 05/01/2010, a las 05:14, Jeff King escribió:
>> - 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/.
[snip patch]
I tried out the patch and it obviously does avoid the "Argument list
too long" problem. At least for my usage patterns the superficial
differences in behavior that you note would not be a problem (I
usually want to limit things to a subdir, and seldom if ever pass in
things like '*.c').
> 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"?
In my relative ignorance of the finer details here, I meant that I
would want "diff-index" to give us the exact same set of blobs as we
get from "ls-files", so as to fix the error without modifying the user
visible behavior.
As I said, I personally wouldn't be impacted by the change in behavior
that your patch produces, but maybe others might.
Cheers,
Wincent
^ permalink raw reply
* git-cherry-pick problem - directory not touched by commit is marked "added by us"
From: Hakim Cassimally @ 2010-01-05 12:33 UTC (permalink / raw)
To: git
I got into a bit of trouble with a git-cherry-pick last night, and
though mugwump
and others on #git helped me as far as a workaround, I'm still very confused,
and would like to make sure it doesn't happen again
I'm fairly sure the problem is due to my ignorance, so I'll firstly describe
the mess I've made of my repo :-)
BACKGROUND
==========
* I had a (trunk) branch that contained most of the code
* I started to experiment with porting our .cgi code to a framework and later,
after the fact, created (experimental) off (trunk)
* As experimental has of course taken longer than expected, I've since forked
(stable) again from (trunk), but from a commit before the experimental stages
started.
* I've developed Feature "X", which took advantage of some of the experimental
refactoring... so of course I developed it in (experimental)...
* I now want to port it back to (stable) so I can release it...
* I was recommended to use 'git rebase -i' but didn't understand how
* ... so I was also recommended to use 'git cherry-pick'. As there were
only 6 relevant commits, I chose to do that
WHAT HAPPENS
============
When I'm in (stable), and try to cherry-pick the change from (experimental),
git thinks that I'm making a massive number of changes in a directory that
wasn't touched by the relevant commit.
Here's a sample transcript which hopefully makes sense: I've included output
of 'git show' and 'git whatchanged' which seem to suggest that the commit
I'm cherry-picking shouldn't be changing these files.
(stable) $ git --version
git version 1.6.6
# I tried previously on 1.6.0.4 but upgraded in case it helped
(stable) $ git status
# On branch stable
# nothing to commit (working directory clean)
(stable) $ git show --stat 301afce1
commit 301afce1c78380276d208077ef4ec76b469c1024
Author: osfameron <...>
Date: Wed Dec 23 23:45:20 2009 +0000
Proof of concept for import module (parse Excel)
bin/upload_module.pl | 142
++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 142 insertions(+), 0 deletions(-)
(stable) $ git whatchanged -1 301afce1
commit 301afce1c78380276d208077ef4ec76b469c1024
Author: osfameron <...>
Date: Wed Dec 23 23:45:20 2009 +0000
Proof of concept for import module (parse Excel)
:000000 100644 0000000... c90e261... A bin/upload_module.pl
(stable) $ git cherry-pick 301afce1
Finished one cherry-pick.
www/client/css/admin-clean.css: needs merge
www/client/css/admin.css: needs merge
www/client/css/error.css: needs merge
www/client/css/public.css: needs merge
www/client/css/user-clean.css: needs merge
<...snip>
www/client/css/admin-clean.css: unmerged
(832c41e99d19f2dd39c9cf3709f14619ffab24b8)
www/client/css/admin.css: unmerged
(8e7cd850bf40d1a921b1f62ce0945abd374fa55d)
www/client/css/error.css: unmerged
(88945d05640c0820c9cf68922392573d4ac07b2c)
<...snip>
...
error: Error building trees
(stable) $ git status
# On branch stable
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: bin/upload_module.pl
#
# Unmerged paths:
# (use "git reset HEAD <file>..." to unstage)
# (use "git add <file>..." to mark resolution)
#
# added by us: www/client/css/admin-clean.css
# added by us: www/client/css/admin.css
# added by us: www/client/css/error.css
# added by us: www/client/css/public.css
<...snip>
As mugwump suggested, I can resolve by doing
(stable) $ git checkout HEAD www/
And then proceed by commiting that cherry-pick. This is how I've fixed it.
(Slightly annoying to repeat/lather/rinse for 6 separate commits, but works).
Oddly, though I've done some messing about in the www/ tree, these files exist
in both, for example "www/client/css/admin.css" exists in both (experimental)
and in (stable).
Please let me know if I should be submitting different or more detailed
information to describe the problem better!
Any help in working out what I'm doing wrong would be really appreciated,
osfameron
^ permalink raw reply
* Re: submodules' shortcomings, was Re: RFC: display dirty submodule working directory in git gui and gitk
From: Jens Lehmann @ 2010-01-05 12:19 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Git Mailing List, Junio C Hamano, Shawn O. Pearce, Paul Mackerras,
Heiko Voigt, Lars Hjemli, Avery Pennarun
In-Reply-To: <alpine.DEB.1.00.1001051032440.4985@pacific.mpi-cbg.de>
Am 05.01.2010 10:46, schrieb Johannes Schindelin:
> But I have a use case here where the shared content is _not_ a library
> that can live in a subdirectory naturally.
Yes, we had to reorganize a major part of one project too. Heiko could
tell more about that.
>> Having read up about svn externals in the meantime, what about something
>> like this:
>> - Add a command like "git submodule forward" (as update is already in
>> use) that takes an optional -b <branchname>. It does a fetch in the
>> submodule, then tries to fast forward (or rebase) to master or the
>> branch given and stages this commit in the superproject. This should
>> be the equivalent to doing an "svn update" in a repo with externals.
>> Or am i missing something?
>
> Yes. It is not the decision of the fetcher, but of the guy who adds the
> submodule to decide what it is.
>
>> - We could also add an option to "git submodule add" to specify the
>> default branch name for forward.
>
> That's an obvious precondition for proper always-tip-submodules. But
> Git's core data structure, the index, does not allow for it. _That_ is
> the difficulty, not what the user interface would look like.
I have never experienced (and never had the need for) such an always-tip
scenario and therefore still seem to have difficulties to grok it. I
assume you always want to have the newest tip at /checkout/ time, not at
/commit/ time? Then my proposal would really not help you.
> I start to wonder whether the insistence that .gitmodules' settings must
> be overrideable makes any sense in practice.
I know of none, maybe someone else can speak up here?
(And even if it is overrideable, do the settings necessarily have to be
copied into .git/config when they aren't even overridden?)
^ permalink raw reply
* Re: submodules' shortcomings, was Re: RFC: display dirty submodule working directory in git gui and gitk
From: Jens Lehmann @ 2010-01-05 11:57 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Git Mailing List, Shawn O. Pearce,
Paul Mackerras, Heiko Voigt, Lars Hjemli, Avery Pennarun
In-Reply-To: <7v1vi428w0.fsf@alter.siamese.dyndns.org>
Am 05.01.2010 10:33, schrieb Junio C Hamano:
> So it is not necessarily a bad thing if the commit checked out in the
> submodule repository is different from what the superproject records in
> its index when a commit is made in the superproject. We allow committing
> with local changes in regular files, while we do notify the users about
> them to avoid mistakes. We should give the same kind of notification
> about submodules, but the "local changes" need to be thought out more
> carefully than plain files in the superproject itself. Does uncommitted
> changes in the index of submodule repository count? Local changes in the
> work tree files? What about untracked files that the user might have
> forgot to add? Should they be warned? What about the commit in the
> submodule repository being a non-descendant of the commit recorded in the
> HEAD of the superproject's tree, resulting in a non-ff change at the
> submodule level?
Committing in the superproject with any dirty state in a submodule
should always work (same as it does with local changes in regular files),
but be visible for the user (again as local changes in regular files are).
Right now we do not show enough information about a submodule to protect
the user from accidentally throwing away changes made inside it.
The only thing we show right now are the differences between submodule
commits and what the superproject has in its index and in its commits.
Missing are:
a) modified files
I think these have to be shown, no matter if they are checked into
the submodules index or not (because until they are committed, they
can't be staged in the superproject anyway).
b) new unignored files
IMO these files should show up too (the superproject doesn't show
ignored files, the submodule state shouldn't do that either). But
OTOH i don't see a possibility for loss of data when this state is
not shown.
c) a detached HEAD not on any local *or* remote branch
This can be fatal when doing a reset, revert or checkout, so it
should be shown. Alternatively when applied on a submodule, forcing
could be disabled to let the command fail instead of throwing stuff
away.
d) a detached HEAD not on any remote branch
AFAICS this is only important for a push, and could just error out
there.
(But i don't think it is necessary to show detailed information, just
what type of states are found in the submodule)
Concerning Dscho's remarks about the performace impact: We could control
this behavior via .gitmodules too (and later have different settings
for the submodules depending on the group the user chose). So you could
turn these checks off for repos where you don't care, saving the time to
go through the whole working directory of the submodule. But i would vote
for the default to show at least case a) and maybe even c) to follow the
principle of least surprise.
> I think "clone" has a chicken-and-egg problem. If all of your project
> participant are expected to check out all the submodules, are expected to
> make commits in all of them, and essentially have to track everything in
> sync, then "clone" can obviously do that without asking what kind of
> participant you are [*1*]. Otherwise, you need to have some mechanism
> (e.g. "group mapping" you mentioned earlier) for the user to specify "I am
> interested in these submodules" before the actual sub-clones to happen,
> but until you clone the superproject that has some description for that
> mechanism to use, and the user to see what's available, you cannot say
> what kind of participant you are. It has to become two-step process;
> either "clone" going interactive in the middle, or you let the clone to
> happen and then "submodule init" to express that information.
Yes, we can leave it that way for now (first "clone" and then "submodule
init <the submodules you need>"). We can migrate to the "group mapping"
functionality later (which would then allow to force certain submodules
to always be populated because they appear in every group).
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2010, #01; Mon, 04)
From: Ilari Liusvaara @ 2010-01-05 11:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vskal5c11.fsf@alter.siamese.dyndns.org>
On Mon, Jan 04, 2010 at 09:57:46PM -0800, Junio C Hamano wrote:
>
> * il/vcs-helper (2009-12-09) 8 commits
> According to http://thread.gmane.org/gmane.comp.version-control.git/134980
> this is very close to completion (or did I overlook a reroll after that?)
> but the final touch is not there yet.
AFAICT, the only nits about that series in that thread were:
- SoB ping-pong
- Not using warning()
And AFAICT both have been fixed in current pu. Or did I overlook some nit?
-Ilari
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2010, #01; Mon, 04)
From: Johan Herland @ 2010-01-05 11:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vskal5c11.fsf@alter.siamese.dyndns.org>
On Tuesday 05 January 2010, Junio C Hamano wrote:
> I am tempted to merge the following to 'next' soonish; please
> complain and stop me before I do so in a few days if there are
> issues.
>
> * jh/notes (2009-12-07) 11 commits
> I didn't see any negative comments after this round; is everybody
> happy with this? If so let's move it to 'next'. If not, please
> complain.
Please hold until I send a new iteration of the series (which will be
based on what is currently in 'next'). The new iteration should be
ready in a few days.
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: submodules' shortcomings, was Re: RFC: display dirty submodule working directory in git gui and gitk
From: Johannes Schindelin @ 2010-01-05 10:07 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jens Lehmann, Git Mailing List, Shawn O. Pearce, Paul Mackerras,
Heiko Voigt, Lars Hjemli, Avery Pennarun
In-Reply-To: <7v1vi428w0.fsf@alter.siamese.dyndns.org>
Hi,
On Tue, 5 Jan 2010, Junio C Hamano wrote:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
>
> > Am 04.01.2010 23:29, schrieb Johannes Schindelin:
> > ...
> >> - 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.
> >
> > Definitely (and if i got that right, svn externals have the same
> > problem).
> >
> > What about checking for every submodule before a push in the
> > superproject that its HEAD is on a remote branch? I don't think we can
> > provide full safety here, but we could handle the 99% case of a
> > forgotten push in the submodule. This could even be done with a rather
> > simple hook (if we had a pre-push hook that is :-).
>
> You don't need "pre-push" hook, if the eventual goal is to integrate this
> into "git push" proper; it can notice submodule directories, descending
> into them, check if the remote lacks the necessary commit and invoke "git
> push" via run_command() interface as needed.
That is obvious, _iff_ we make the necessary changes in core Git. Jens'
point was that you can do it with hooks, too.
> >> - 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?
> >
> > Having read up about svn externals in the meantime, what about
> > something like this:
> > - Add a command like "git submodule forward" (as update is already in
> > use) that takes an optional -b <branchname>. It does a fetch in the
> > submodule, then tries to fast forward (or rebase) to master or the
> > branch given and stages this commit in the superproject. This should
> > be the equivalent to doing an "svn update" in a repo with externals.
> > Or am i missing something? (And we could avoid the detached HEAD in
> > the fast forward case by really checking out the branch in the
> > submodule)
> > - We could also add an option to "git submodule add" to specify the
> > default branch name for forward.
>
> Instead of recording a specific submodule commit in the superproject, we
> could record a branch name (this would need a separate "gitlink" type of
> object we toyed around during the early days of submodule design) to say
> "the tip of the branch".
Yes, and it would be as limited (but in a different way) as the current
gitlink.
You might argue that "gitlink" in its current form has not raised too many
complaints. But that is only because next to nobody uses submodules
unless forced to.
> But there is a difference between a distributed system and a centralized
> one like Subversion. When you say "tip of the branch", you have to say
> "which repository". If your position is that _any_ repository will do
> as long as the commit is at the tip of the named branch, that is like
> saying you don't care what commit it really is, as you are free to muck
> with branch heads in your copy of submodule repository, by adding
> commits, or resetting new ones away. For that matter, your 'master'
> branch in the submodule repository may not build-on/fork-from the
> 'master' branch in the upstream of it, so even "tip of the branch by
> _this name_" is still fuzzy.
>
> I am not saying "any commit will do" is necessarily a bad position to
> take. But people who claim they want to say "this branch" need to
> realize what they are really saying: whatever you record in the
> superproject commit is immaterial. In other words, "this superproject
> will work no matter which version of submodule is checked out at its
> location".
>
> Thatv actually is a very valid thing to say in some situations (Dscho
> mentioned different versions of artwork checked out as a submodule in a
> developer's superproject to build an app). Interestingly enough, some
> people seem to think that we place too much importance on not having to
> check out submodules, but it indeed is a very natural extention of "any
> commit will do". If the configuration you chose for your build does not
> depend on any files from there, it will truly be "any commit will do",
> including "nothing checked out there is just fine".
Come on Junio, do not insult my intelligence.
You know all too well about scenarios where a superproject tracks a
3rd-party project which the superproject's developers do not contribute
to.
"nothing checked out there is just fine". Pfff. That's ridiculous.
You'll have to try much harder than that.
Ciao,
Johannes
^ 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