* Re: [PATCH v2 2/3] format-patch: make full-diff enabled by default
From: Nanako Shiraishi @ 2010-01-05 22:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Felipe Contreras, Felipe Contreras, git
In-Reply-To: <1259408429-5685-3-git-send-email-felipe.contreras@gmail.com>
Junio, could you tell us what happened to this thread?
^ permalink raw reply
* Re: edit Author/Date metadata as part of 'git commit' $EDITOR invocation?
From: Nanako Shiraishi @ 2010-01-05 22:38 UTC (permalink / raw)
To: Adam Megacz; +Cc: git
In-Reply-To: <xuu2zl4tfuij.fsf@nowhere.com>
Quoting Adam Megacz <adam@megacz.com>
> Perhaps a preference (off by default) demanding that they be set
> explicitly when "git commit -m" is used?
Sverre pointed out why this won't work.
> Some people care more than others about the metadata; this is for the
> folks to whom it matters a lot.
So the only workable solution is to check your commits with "git show -s" until you become confident that you configured your new box correctly. Some people unfortunately don't care enough to do so, but it is for the people to whom it matters.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: submodules' shortcomings, was Re: RFC: display dirty submodule working directory in git gui and gitk
From: Nanako Shiraishi @ 2010-01-05 22:37 UTC (permalink / raw)
To: Heiko Voigt
Cc: Johannes Schindelin, 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>
Quoting Heiko Voigt <hvoigt@hvoigt.net>
> 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.
Thanks for sharing your thoughts. I find this discussion very interesting.
I found this other discussion in the design area enlightening.
http://thread.gmane.org/gmane.comp.version-control.git/47466/focus=47621
It was before I started using git heavily and I don't see many people who were in the discussion yet in the current thread, but I think it is worth reading.
P.S. A happy new year to everybody!
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: git-cherry-pick problem - directory not touched by commit is marked "added by us"
From: Sam Vilain @ 2010-01-05 21:37 UTC (permalink / raw)
To: Hakim Cassimally; +Cc: git
In-Reply-To: <82cfa8031001050433r6d705222qf905c929ad6395c4@mail.gmail.com>
On Tue, 2010-01-05 at 12:33 +0000, Hakim Cassimally wrote:
> 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
Yes, that was me. I'm very confused by the bug, too.
[...]
> 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.
[...]
> (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
So by here, we know that the commit only affects that single file. No
funny stuff like mode changes of other files.
> (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
Then, wham, these files want to be changed. What is the diff-tree
inside revert/cherry-pick doing differently to the one in log?
> (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>
Hakim, one more useful thing in this situation would be to show the
state of these files in the index;
git ls-files -s -u
Also take the 'git ls-tree -r HEAD', 'git ls-tree -r 301afce1' and 'git
ls-tree -r 301afce1^' output, and grep for the files in question. The
answer (or at least a bug triage) should be in the output of those
commands.
You can reproduce exactly the merge by making a new branch at the
position where you were attempting to land the cherry pick before, and
checking that branch out.
One last test, would be to check that it happens on a clean clone of the
repository. I don't think that you're hitting any repository-local
behaviour (eg, the ability to mark certain files as "always ignore") but
you never know. These commands are all being run on the same working
copy, right?
Thanks for your persistence,
Sam
^ permalink raw reply
* Re: [PATCH 9/9] rerere forget path: forget recorded resolution
From: Johannes Sixt @ 2010-01-05 21:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1262122958-9378-10-git-send-email-gitster@pobox.com>
Junio C Hamano schrieb:
> After you find out an earlier resolution you told rerere to use was a
> mismerge, there is no easy way to clear it. A new subcommand "forget" can
> be used to tell git to forget a recorded resolution, so that you can redo
> the merge from scratch.
> ...
> diff --git a/rerere.c b/rerere.c
> index f013ae7..c1da6f6 100644
> --- a/rerere.c
> +++ b/rerere.c
> ...
> +static int handle_cache(const char *path, unsigned char *sha1)
> +{
> +...
> + ll_merge(&result, path, &mmfile[0],
> + &mmfile[1], "ours",
> + &mmfile[2], "theirs", 0);
When you simply call ll_merge(), will it obey any merge drivers that are
defined in .gitattributes? Do we care about them?
I already had an implementation of "rerere forget" before you presented
this solution, but it relies on that the user calls "checkout
--conflict=merge" first. One reason (besides its simplicity) was that it
does not have to care how the merge is computed.
[I haven't submitted my solution, yet, because I haven't had the time to
do this large merge where I expect to make use "rerere forget", testing
its usefulness.]
-- Hannes
^ permalink raw reply
* Re: A question about changing remote repo name
From: David Aguilar @ 2010-01-05 21:15 UTC (permalink / raw)
To: Dongas; +Cc: Russell Steicke, git
In-Reply-To: <60ce8d251001042030l75c5443gf173f127ad206df3@mail.gmail.com>
Hi,
On Tue, Jan 05, 2010 at 12:30:03PM +0800, Dongas wrote:
> 2010/1/5 Russell Steicke <russellsteicke@gmail.com>:
> > On Mon, Jan 4, 2010 at 2:45 PM, Dongas <dongas86@gmail.com> wrote:
>
> Thanks a lot, Russell.
> I followed you instruction but it seemed it needs more changes.
>
> Execute your steps....
> Becomes:
> root@ubuntu:/work/git-repo/free_monkey# tree -a
Just a note: I would recommend against being root.
You cloned the repo so you should own it.
More below...
> root@ubuntu:/work/git-repo/free_monkey# cat .git/config
> [core]
> repositoryformatversion = 0
> filemode = true
> bare = false
> logallrefupdates = true
> [remote "karmic"]
> url = git@192.168.1.116:free_monkey.git
> fetch = +refs/heads/*:refs/remotes/karmic/*
> [branch "master"]
> remote = karmic
> merge = refs/heads/master
>
> But the result was:
> root@ubuntu:/work/git-repo/free_monkey# git branch -a
> * master
> karmic/HEAD
> origin/master
> The 'origin/master' was still not changed.
A safter alternative would be to leave the "origin" lines in
place as a duplicate of karmic:
[remote "karmic"]
url = git@192.168.1.116:free_monkey.git
fetch = +refs/heads/*:refs/karmic/origin/*
[remote "origin"]
url = git@192.168.1.116:free_monkey.git
fetch = +refs/heads/*:refs/remotes/origin/*
At that point you will have two remotes, "karmic" and "origin".
"git fetch karmic" to get the latest branches.
Finally, "git remote rm origin" to remove all references to it.
> I did a few more steps:
> root@ubuntu:/work/git-repo/free_monkey# grep -wrin 'origin' .
> ./.git/packed-refs:2:abfae429bb4081043e84681e5ee94102085f87e0
> refs/remotes/origin/master
> ./.git/refs/remotes/karmic/HEAD:1:ref: refs/remotes/origin/master
>
> Change 'origin' to 'karmic' in above files.
You can skip this step by using "git remote rm" as described
above.
> The steps are a little complicated.
> Do you know if there's a way to rename the remote on server side?
> If there is, then everyone could just clone the project with a new
> remote name rather than the defaul 'origin'.
Unfortunately, no. "origin" is actually a local thing.
Your local git client gives it that name. As you can see, the
remote does not care whether we call it "origin" or "karmic".
There were some patches flying around on the ML some time ago
that allowed you to change the default "origin" name on the
client side at "git clone" time (or maybe patches never
materialized and it was purely discussion).
That was a while ago (probably over a year ago) and this wasn't
anybody's itch to scratch in the meantime so nothing every
materialized. It think this is only the 2nd time this has come
up in that whole time. Sorry, I wasn't able to find the thread.
Here's a nice middle ground --
instead of naming your branch "master" you can call your default
branch "karmic".
To make it the default for "git clone" then you'll need to push
your local master branch and call it "karmic" over there:
git push origin master:karmic
Then, go to that server and change the repo's HEAD entry so that
it points to karmic instead of master.
ssh admin@gitbox
cd /path/to/repo.git
vi HEAD
>From then on, everyone who clones the repo will have a "karmic"
branch by default instead of the master branch.
To get that branch on repos that were cloned before the change:
git fetch origin
git checkout -b karmic origin/karmic
With this setup you might even want to remove the "master"
branch altogether since it might be confusing to have both:
Once:
git push origin :master
In everyone's repo:
git remote prune origin
You will need to make sure everyone has either:
a) cloned from the new master-less repo
b) run the "checkout -b" and "remote prune" commands
Otherwise someone'll likely "git push" the master branch back
into existence.
--
David
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2010, #01; Mon, 04)
From: Johannes Sixt @ 2010-01-05 20:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhbr1bagk.fsf@alter.siamese.dyndns.org>
Junio C Hamano schrieb:
> 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?
The patch text is good, but since it will not make a difference (and there
are a ton of other places that use /bin/sh successfully), the change is
not warrented at this time, IMO.
> 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?
Well, the test will break on Windows only after "run-command: optimize out
useless shell calls", and I wrote the commit message accordingly. If you
move it before that one (and if you are picky) the commit message should
be changed as well.
-- Hannes
^ permalink raw reply
* Re: submodules' shortcomings, was Re: RFC: display dirty submodule working directory in git gui and gitk
From: Pau Garcia i Quiles @ 2010-01-05 20:38 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>
Hello,
Let me pop here to support Johannes: I agree with every single point
he enumerated. Every. Single. Point.
For instance, I'd like to have a 'cmake' repository where I store all
the FindBlah.cmake modules, so that I can share them from every
repository, and not worry about users changing and committing in the
main project instead of the submodule. I can't. Subversion externals
still rule in that regard.
On Mon, Jan 4, 2010 at 11:29 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> 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
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
^ permalink raw reply
* Re: edit Author/Date metadata as part of 'git commit' $EDITOR invocation?
From: David Aguilar @ 2010-01-05 20:22 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Adam Megacz, git
In-Reply-To: <fabb9a1e1001041452q299f1f28hff041eb06fd24b1f@mail.gmail.com>
On Mon, Jan 04, 2010 at 05:52:42PM -0500, Sverre Rabbelier wrote:
> 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
Workaround:
If you use "git commit -s" it includes a Signed-off-by line
which includes your name and email.
Seeing "Signed-off-by: root <root@localhost>" would give you a
hint that you should abort the commit, set the vars, and
try again.
--
David
^ permalink raw reply
* 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
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