* Re: [PATCH 0/4] Makefile fixes
From: Jonathan Nieder @ 2010-01-06 4:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, git
In-Reply-To: <7vpr5onir5.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Nanako Shiraishi <nanako3@lavabit.com> writes:
>
>> Junio, could you tell us what happened to this thread?
>>
>> Makefile improvements. No discussion.
These had some issues and instead of following up, I simply forgot
about them.
> I took 4/4, and after looking at them again, I think 2/4 looks sensible,
> too.
I also think the patch for 2/4 looks sensible, but the commit message
does not make much sense. Optimization flags do not affect
compilation of assembler code as far as I can tell. It would have
made more sense to say something like "Since the only .S file in git
does not have any #ifdefs, leaving the dependency out was mostly
harmless." (Will resend.)
> I was puzzled by 3/4 and I still am; the dependency rules are the same for
> %.o and %.s yet the patch changes only %.s. Either it leaves the same
> breakage for %.o (which is much more important in practice), or the
> problem Jonathan has with %.s may have other causes, but it was unclear to
> me.
The Makefile lists dependencies for each .o target elsewhere. While
cleaning up those other dependency rules, I noticed there was nothing
analogous for the .s targets. You can reproduce this by running
"make var.o var.s && touch cache.h && make var.o var.s".
Of course, I should have mentioned this in the commit message. Will
resend as well. Sorry to leave these standing for so long.
Sincerely,
Jonathan
^ permalink raw reply
* Re: A question about changing remote repo name
From: Dongas @ 2010-01-06 3:55 UTC (permalink / raw)
To: David Aguilar; +Cc: Russell Steicke, git
In-Reply-To: <20100105211521.GC2657@gmail.com>
2010/1/6 David Aguilar <davvid@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.
Thanks for your advices.
> 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.
It's a good idea.
I have tried and it seemed to work.
(I also did a few more works to make it better)
Below is the result:
root@ubuntu:/work/git-repo/tmp/free_monkey# git branch -a
* master
origin/HEAD
origin/master
root@ubuntu:/work/git-repo/tmp/free_monkey# cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = git@192.168.1.106:free_monkey.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
root@ubuntu:/work/git-repo/tmp/free_monkey# git remote add karmic
git@192.168.1.106:free_monkey.git
root@ubuntu:/work/git-repo/tmp/free_monkey# git fetch karmic
From git@192.168.1.106:free_monkey
* [new branch] master -> karmic/master
root@ubuntu:/work/git-repo/tmp/free_monkey# git branch -a
* master
karmic/master
origin/HEAD
origin/master
root@ubuntu:/work/git-repo/tmp/free_monkey# git remote rm origin
root@ubuntu:/work/git-repo/tmp/free_monkey# git branch -a
* master
karmic/master
However there's a little issue:
root@ubuntu:/work/git-repo/tmp/free_monkey# git pull
fatal: 'origin': unable to chdir or not a git archive
fatal: The remote end hung up unexpectedly
root@ubuntu:/work/git-repo/tmp/free_monkey# grep -wrin 'origin' .git/
root@ubuntu:/work/git-repo/tmp/free_monkey# cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[branch "master"]
[remote "karmic"]
url = git@192.168.1.106:free_monkey.git
fetch = +refs/heads/*:refs/remotes/karmic/*
But 'git pull karmic master' worked well.
root@ubuntu:/work/git-repo/tmp/free_monkey# git pull karmic master
From git@192.168.1.106:free_monkey
* branch master -> FETCH_HEAD
Already up-to-date.
For conveniently, i did a few more steps.
Add two lines below '[branch "master"]':
root@ubuntu:/work/git-repo/tmp/free_monkey# cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[branch "master"]
remote = karmic
merge = refs/heads/master
[remote "karmic"]
url = git@192.168.1.106:free_monkey.git
fetch = +refs/heads/*:refs/remotes/karmic/*
Then, 'git pull' worked well.
root@ubuntu:/work/git-repo/tmp/free_monkey# git pull
Already up-to-date.
> 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.
Thanks for the info.
> 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.
Thanks a lot for the alternative way , it looks good.
Regards
Dongas
^ permalink raw reply
* Re: A question about changing remote repo name
From: Dongas @ 2010-01-06 3:58 UTC (permalink / raw)
To: Russell Steicke; +Cc: git
In-Reply-To: <c1b8b6671001051607j6b6398d8gf08f7615a38de64e@mail.gmail.com>
2010/1/6 Russell Steicke <russellsteicke@gmail.com>:
> On Tue, Jan 5, 2010 at 12:30 PM, Dongas <dongas86@gmail.com> wrote:
>> 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.
>
> Ah yes, I forgot about those files. I _think_ (but I'm not certain
> without digging into the code) that it's always safe to rm
> packed-refs, as that file is a cache for quicker access to the refs.
> At least it's never caused me any problems.
>
> In any case, your approach of grepping the whole of .git for
> interesting strings is a good way to learn about the implementation.
Thanks a lot for your help. :)
Regards
Dongas
^ permalink raw reply
* Re: [PATCH v3 2/6] t5541-http-push.sh: add test for unmatched, non-fast-forwarded refs
From: Tay Ray Chuan @ 2010-01-06 2:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Shawn O. Pearce, Daniel Barkalow, Jeff King
In-Reply-To: <7viqbgoxgg.fsf@alter.siamese.dyndns.org>
Hi,
On Wed, Jan 6, 2010 at 9:04 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Tay Ray Chuan <rctay89@gmail.com> writes:
>
>> Test that when non-fast-forwarded refs cannot be matched without an
>> explicit refspect, the push fails with a non-fast-forward ref status and
>> help message.
>>
>> Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
>> ---
>> t/t5541-http-push.sh | 20 ++++++++++++++++++++
>> 1 files changed, 20 insertions(+), 0 deletions(-)
>>
>> diff --git a/t/t5541-http-push.sh b/t/t5541-http-push.sh
>> index f49c7c4..5ebe04a 100755
>> --- a/t/t5541-http-push.sh
>> +++ b/t/t5541-http-push.sh
>> @@ -111,5 +111,25 @@ Merge the remote changes before pushing again. See the '"'non-fast-forward'"'
>> section of '"'git push --help'"' for details." output
>> '
>>
>> +test_expect_failure 'push fails for non-fast-forward refs unmatched by remote helper' '
>> + # create a dissimilarly-named ref so that git is unable to match the refs
>> + git push origin master:retsam
>> +
>> + echo "change changed" > path2 &&
>> + git commit -a -m path2 --amend &&
>> +
>> + # push master too. This ensures there is at least one '"'push'"' command to
>> + # the remote helper and triggers interaction with the helper.
>> + !(git push -v origin +master master:retsam >output 2>&1) &&
>
> A dumb question. Why is this done in a sub-shell?
>
>> +
>> + grep "^ + [a-z0-9]\+\.\.\.[a-z0-9]\+[ ]*master -> master (forced update)$" output &&
>> + grep "^ ! \[rejected\][ ]*master -> retsam (non-fast-forward)$" output &&
>
> [a-z0-9] seems too broad to catch hexadecimal.
Oops, my bad.
> "\+" to introduce ERE
> elements to grep that expects BRE is a GNU extension, IIRC. You could use
> egrep if you really want to say one-or-more, but I think in this case it
> is better to simply replace it with a zero-or-more '*'.
Ok.
> Why is a single
> SP made into character class with "[ ]" pair?
To make it clearer that I'm trying to match a SP.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [PATCH] git-update-index: report(...) now flushes stdout after printing the report line
From: Tay Ray Chuan @ 2010-01-06 1:51 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Miklos Vajna, Sebastian Thiel,
Nanako Shiraishi, git
In-Reply-To: <7vwrzwoxh4.fsf@alter.siamese.dyndns.org>
Hi,
On Wed, Jan 6, 2010 at 9:04 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Tay Ray Chuan <rctay89@gmail.com> writes:
>
>> from your above message solely and setting aside your original patch,
>> I presume that you want to introduce the ability to force progress
>> reporting even if stderr isn't a terminal.
>>
>> I am working a feature (display progress for http operations) that
>> happens to add this ability to git-push and git-fetch, by specifying
>> the --progress option.
>>
>> Regarding git-pull - I guess it's only git-fetch (being
>> transport-related) that reports progress?
>
> Are you talking about this topic?
>
> * tc/clone-v-progress (2009-12-26) 4 commits
> - clone: use --progress to force progress reporting
> - clone: set transport->verbose when -v/--verbose is used
> - git-clone.txt: reword description of progress behaviour
> - check stderr with isatty() instead of stdout when deciding to show progress
no, I'm not referring to that - the topic I mentioned is still off-list.
> What do people think about it? I vaguely recall that somebody asked to
> add a warning to release notes on the behaviour change to this series, and
> I think it may be a worthwhile thing to do (e.g. "Earlier we did X but now
> we do Y; change things in this way if you want us to keep doing X"), but
> otherwise I think it is a sensible change.
Yes, that request was from Dscho, and Miklos said something to that
effect as well. Could you advise how one could go about adding such a
warning, as I'm not sure about the release schedule details.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: Filename quoting / parsing problem
From: Junio C Hamano @ 2010-01-06 1:32 UTC (permalink / raw)
To: Andreas Gruenbacher; +Cc: git
In-Reply-To: <201001060104.25737.agruen@suse.de>
Andreas Gruenbacher <agruen@suse.de> writes:
> * sha1 checksums are not verified right now. I'm not sure when that
> should happen: always by default, or only optionally?
preimage and postimage sums are not something you would "verify" with
anyway, and they are not useful unless you are dealing with binary patch,
so I wouldn't worry too much about them.
> * Similarity and dissimilarity headers are ignored.
I think it is fine to ignore them; even git doesn't use this information
other than parroting them in "apply --summary --stat" output.
> * Binary diffs are no supported. I think GNU patch should recognize
> them and give a reasonable message for now.
Nice.
^ permalink raw reply
* Re: cmake, was Re: submodules' shortcomings
From: Pau Garcia i Quiles @ 2010-01-06 1:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <alpine.DEB.1.00.1001060005010.4985@pacific.mpi-cbg.de>
On Wed, Jan 6, 2010 at 12:06 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Tue, 5 Jan 2010, Pau Garcia i Quiles wrote:
>
>> 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.
>
> ... which reminds me... it was you who wanted to provide a working recipe
> to compile and install CMake on msysGit, right?
Right
> What happened in the meantime?
What happened is I was very busy until November. Now I've got some free time.
At this moment, what stops me from beginning this project is a simple
question: is it worth my time? From the discussion a few months ago,
it looked like it would the a second-class citizen and never replace
the existing buildsystems, so I really wonder if I should spend me
time porting git to CMake, or I should focus on other projects which
would gladly receive my contributions. If you honestly think it's
worth it, just tell me and I'll start the port to CMake immediately.
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
^ permalink raw reply
* Re: Filename quoting / parsing problem
From: Junio C Hamano @ 2010-01-06 1:08 UTC (permalink / raw)
To: Andreas Gruenbacher; +Cc: git
In-Reply-To: <201001022148.47841.agruen@suse.de>
Andreas Gruenbacher <agruen@suse.de> writes:
> Right now, git generates lines like "diff --git a/f a/f b/f b/f" in some
> corner cases, and from such lines alone, it is not possible to tell what the
> two file names are (either "a/f a/f" and "b/f b/f", or "a/f a/f b/f" and
> "b/f"). I can only find that out by looking at the other header lines.
I would understand "a/f a/f b/f a/f", which would be a diff of "f a/f"
between two versions.
"a/f a/f b/f b/f" could be rename from "f /a/f" to "f b/f" (or "f a/f b/f"
to "f"). But you will always get "rename from" and "rename to" in that
case.
So you can (and I think git-apply does) follow this simple rule:
If you see +++/---/rename from/rename to/new file/deleted file, use
the names you find there. Otherwise, because there is no rename,
"diff --git" lines has two identical names that follow a/ and b/, so
use that name.
The parsing code in builtin-apply.c is not so dense; you should be able to
lift it from there, I think.
Although an output of "a/f a/f b/f b/f" without "rename from/to" is
possible with --no-index of two unrelated files, --no-index output is not
even something that is meant to be appliable, so I wouldn't worry too much
about it.
^ permalink raw reply
* Re: [PATCH 0/4] Makefile fixes
From: Junio C Hamano @ 2010-01-06 1:07 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Jonathan Nieder, git
In-Reply-To: <20100101090556.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Junio, could you tell us what happened to this thread?
>
> Makefile improvements. No discussion.
I took 4/4, and after looking at them again, I think 2/4 looks sensible,
too.
I was puzzled by 3/4 and I still am; the dependency rules are the same for
%.o and %.s yet the patch changes only %.s. Either it leaves the same
breakage for %.o (which is much more important in practice), or the
problem Jonathan has with %.s may have other causes, but it was unclear to
me.
^ permalink raw reply
* Re: [PATCH/RFC 0/2] Lazily generate header dependencies
From: Junio C Hamano @ 2010-01-06 1:06 UTC (permalink / raw)
To: Nanako Shiraishi
Cc: Jonathan Nieder, Johannes Sixt, Git Mailing List,
Johannes Schindelin
In-Reply-To: <20100101090550.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Junio, could you tell us what happened to this thread?
>
> Makefile improvements. No discussion.
I was mildly interested in the series, but after this:
http://thread.gmane.org/gmane.comp.version-control.git/133872/focus=133911
the progress seems to have stopped.
^ permalink raw reply
* Re: [PATCH 9/9] rerere forget path: forget recorded resolution
From: Junio C Hamano @ 2010-01-06 1:06 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
In-Reply-To: <4B43AE38.9070800@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
> 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.
Doesn't "checkout --conflict=merge" use the same ll_merge() machinery?
> [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: submodules' shortcomings, was Re: RFC: display dirty submodule working directory in git gui and gitk
From: Junio C Hamano @ 2010-01-06 1:04 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: <4B439A86.3020500@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
> 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.
Yeah, your "i don't see a possibility for lost of data when this state is
not shown" confused me into thinking as if you were saying it is not _too_
bad if we didn't show the information.
After all we _were_ in agreement. We both think the user should be told
about untracked files in submodule directory when inspecting the status to
make a commit in the superproject.
^ permalink raw reply
* Re: [PATCH v3 2/6] t5541-http-push.sh: add test for unmatched, non-fast-forwarded refs
From: Junio C Hamano @ 2010-01-06 1:04 UTC (permalink / raw)
To: Tay Ray Chuan
Cc: git, Shawn O. Pearce, Daniel Barkalow, Jeff King, Junio C Hamano
In-Reply-To: <20091224154158.15ba580f.rctay89@gmail.com>
Tay Ray Chuan <rctay89@gmail.com> writes:
> Test that when non-fast-forwarded refs cannot be matched without an
> explicit refspect, the push fails with a non-fast-forward ref status and
> help message.
>
> Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
> ---
> t/t5541-http-push.sh | 20 ++++++++++++++++++++
> 1 files changed, 20 insertions(+), 0 deletions(-)
>
> diff --git a/t/t5541-http-push.sh b/t/t5541-http-push.sh
> index f49c7c4..5ebe04a 100755
> --- a/t/t5541-http-push.sh
> +++ b/t/t5541-http-push.sh
> @@ -111,5 +111,25 @@ Merge the remote changes before pushing again. See the '"'non-fast-forward'"'
> section of '"'git push --help'"' for details." output
> '
>
> +test_expect_failure 'push fails for non-fast-forward refs unmatched by remote helper' '
> + # create a dissimilarly-named ref so that git is unable to match the refs
> + git push origin master:retsam
> +
> + echo "change changed" > path2 &&
> + git commit -a -m path2 --amend &&
> +
> + # push master too. This ensures there is at least one '"'push'"' command to
> + # the remote helper and triggers interaction with the helper.
> + !(git push -v origin +master master:retsam >output 2>&1) &&
A dumb question. Why is this done in a sub-shell?
> +
> + grep "^ + [a-z0-9]\+\.\.\.[a-z0-9]\+[ ]*master -> master (forced update)$" output &&
> + grep "^ ! \[rejected\][ ]*master -> retsam (non-fast-forward)$" output &&
[a-z0-9] seems too broad to catch hexadecimal. "\+" to introduce ERE
elements to grep that expects BRE is a GNU extension, IIRC. You could use
egrep if you really want to say one-or-more, but I think in this case it
is better to simply replace it with a zero-or-more '*'. Why is a single
SP made into character class with "[ ]" pair?
> +
> + grep \
> +"To prevent you from losing history, non-fast-forward updates were rejected
> +Merge the remote changes before pushing again. See the '"'non-fast-forward'"'
> +section of '"'git push --help'"' for details." output
> +'
> +
> stop_httpd
> test_done
> --
> 1.6.6.rc1.249.g048b3
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2010, #01; Mon, 04)
From: Junio C Hamano @ 2010-01-06 1:04 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <20100105115620.GA27121@Knoppix>
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> writes:
> - Not using warning()
Ah, I forgot about locally fixing that one up. Sorry, and thanks.
^ permalink raw reply
* Re: [PATCH] git-update-index: report(...) now flushes stdout after printing the report line
From: Junio C Hamano @ 2010-01-06 1:04 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: Sebastian Thiel, Nanako Shiraishi, git
In-Reply-To: <be6fef0d1001031503h11cb65c6ha34eee345b9b7055@mail.gmail.com>
Tay Ray Chuan <rctay89@gmail.com> writes:
> from your above message solely and setting aside your original patch,
> I presume that you want to introduce the ability to force progress
> reporting even if stderr isn't a terminal.
>
> I am working a feature (display progress for http operations) that
> happens to add this ability to git-push and git-fetch, by specifying
> the --progress option.
>
> Regarding git-pull - I guess it's only git-fetch (being
> transport-related) that reports progress?
Are you talking about this topic?
* tc/clone-v-progress (2009-12-26) 4 commits
- clone: use --progress to force progress reporting
- clone: set transport->verbose when -v/--verbose is used
- git-clone.txt: reword description of progress behaviour
- check stderr with isatty() instead of stdout when deciding to show progress
What do people think about it? I vaguely recall that somebody asked to
add a warning to release notes on the behaviour change to this series, and
I think it may be a worthwhile thing to do (e.g. "Earlier we did X but now
we do Y; change things in this way if you want us to keep doing X"), but
otherwise I think it is a sensible change.
^ permalink raw reply
* Re: A question about changing remote repo name
From: Junio C Hamano @ 2010-01-06 1:02 UTC (permalink / raw)
To: Russell Steicke; +Cc: Dongas, git
In-Reply-To: <c1b8b6671001051607j6b6398d8gf08f7615a38de64e@mail.gmail.com>
Russell Steicke <russellsteicke@gmail.com> writes:
> Ah yes, I forgot about those files. I _think_ (but I'm not certain
> without digging into the code) that it's always safe to rm
> packed-refs, as that file is a cache for quicker access to the refs.
No what you think is incorrect, no it is not safe at all, and no it is not
a cache.
refs are created loose as files under $GIT_DIR/refs/. When pack-refs is
run (either from the toplevel or as part of gc), these loose ref files are
removed and instead written to $GIT_DIR/packed-refs file. When a new ref
is created or an existing ref is updated, only $GIT_DIR/refs/ is modified.
When reading or enumerating, a loose ref, if found, is used. Otherwise
a record in packed-refs is consulted. The consequences are:
- If you have $GIT_DIR/refs/heads/master and at the same time, an entry
for refs/heads/master exists in $GIT_DIR/packed-refs, removing the
entry in packed-refs happens to be safe, because it was already masked.
- If you do not have $GIT_DIR/refs/heads/old, but an entry for
refs/heads/old exists in $GIT_DIR/packed-refs, removing the entry in
packed-refs means you lose the "old" branch. You don't want to do
that.
- When deleting a ref, we remove it from $GIT_DIR/refs/, but at the same
time, if packed-refs contains an entry for it, we remove it from
there. Otherwise, the removal of the loose one will unmask the stale
entry in packed-refs file.
^ permalink raw reply
* Re: A question about changing remote repo name
From: Johannes Schindelin @ 2010-01-06 0:27 UTC (permalink / raw)
To: Russell Steicke; +Cc: Dongas, git
In-Reply-To: <c1b8b6671001051607j6b6398d8gf08f7615a38de64e@mail.gmail.com>
Hi,
On Wed, 6 Jan 2010, Russell Steicke wrote:
> On Tue, Jan 5, 2010 at 12:30 PM, Dongas <dongas86@gmail.com> wrote:
> > 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.
>
> Ah yes, I forgot about those files. I _think_ (but I'm not certain
> without digging into the code) that it's always safe to rm
> packed-refs, as that file is a cache for quicker access to the refs.
For everybody reading this thread: DON'T!
Russel, it would be better if you knew about the mechanism before
making other people believe that it is safe to delete a file that is _not_
a cache, but _replaces_ the existing refs.
(Just mentioning that you only _think_ it is safe does not help; it is not
safe, but people will think that it is safe. Maybe you'll spend those 5
minutes in the future before sending a message like you did...)
Hth,
Dscho
^ permalink raw reply
* Re: A question about changing remote repo name
From: Russell Steicke @ 2010-01-06 0:07 UTC (permalink / raw)
To: Dongas; +Cc: git
In-Reply-To: <60ce8d251001042030l75c5443gf173f127ad206df3@mail.gmail.com>
On Tue, Jan 5, 2010 at 12:30 PM, Dongas <dongas86@gmail.com> wrote:
> 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.
Ah yes, I forgot about those files. I _think_ (but I'm not certain
without digging into the code) that it's always safe to rm
packed-refs, as that file is a cache for quicker access to the refs.
At least it's never caused me any problems.
In any case, your approach of grepping the whole of .git for
interesting strings is a good way to learn about the implementation.
--
Virus found in this message.
^ permalink raw reply
* Re: Filename quoting / parsing problem
From: Andreas Gruenbacher @ 2010-01-06 0:04 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <201001022148.47841.agruen@suse.de>
On Saturday 02 January 2010 09:48:47 pm Andreas Gruenbacher wrote:
> On Saturday 02 January 2010 07:37:08 pm Junio C Hamano wrote:
> > I don't think it happened in the GNU land yet, and you would be the
> > person to know about it ;-).
>
> I'm working on it ...
The "experimental" branch [*] now has very lightly tested code for parsing
most extended headers ("index", "rename from", "rename to", "copy from", "copy
to", "old mode", "new mode", "deleted file mode", "new file mode"). Most
things should work, except:
* Doesn't parse filenames in "diff --git" lines. (I tried to argue why
those lines are a problem in this thread.)
* sha1 checksums are not verified right now. I'm not sure when that should
happen: always by default, or only optionally? (Like verifying file modes,
this is going to surprise a lot of users.)
* Similarity and dissimilarity headers are ignored.
* Binary diffs are no supported. I think GNU patch should recognize them and
give a reasonable message for now.
[*] http://git.savannah.gnu.org/cgit/patch.git/log/?h=experimental
Can you guys please do something to make parsing of filenames in "diff --git"
lines a lot easier, or unnecessary?
Thanks!
Andreas
^ 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 23:13 UTC (permalink / raw)
To: Nanako Shiraishi
Cc: Heiko Voigt, Jens Lehmann, Git Mailing List, Junio C Hamano,
Shawn O. Pearce, Paul Mackerras, Lars Hjemli, Avery Pennarun
In-Reply-To: <20100106073718.6117@nanako3.lavabit.com>
Hi,
On Wed, 6 Jan 2010, Nanako Shiraishi wrote:
> I found this other discussion in the design area enlightening.
>
> http://thread.gmane.org/gmane.comp.version-control.git/47466/focus=47621
Could you be so kind and summarize the result of the thread in something
like 2000 characters?
I am sorry, but what with the recent trend of a precious few Git mailing
list members using up my weekly Git time budget in less than half a day,
just by me reading their mails, it would be nice if at least _some_
discussions on the list could be concise and to the point.
Thanks,
Dscho
^ permalink raw reply
* cmake, was Re: submodules' shortcomings
From: Johannes Schindelin @ 2010-01-05 23:06 UTC (permalink / raw)
To: Pau Garcia i Quiles; +Cc: Git Mailing List
In-Reply-To: <3af572ac1001051238t63e07a25hf9dd77056b79be89@mail.gmail.com>
Hi,
On Tue, 5 Jan 2010, Pau Garcia i Quiles wrote:
> 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.
... which reminds me... it was you who wanted to provide a working recipe
to compile and install CMake on msysGit, right?
What happened in the meantime?
Ciao,
Dscho
^ 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 23:02 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: <7vd41oz9mp.fsf@alter.siamese.dyndns.org>
Hi,
On Tue, 5 Jan 2010, Junio C Hamano wrote:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
>
> >> 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).
That's just like saying "you only see the URL first, and you have to clone
before you see what the project is about".
So in effect you are saying that things are bad. But you do not take the
leap of imagination to say what we need to improve.
There are quite a number of settings which could benefit from git-clone --
finally -- learning to take more information than just the URL; autocrlf
and submodules' "grouping" (which is a lousy name, by the way) being the
most prominent examples (which the core Git developers very obviously do
not use, otherwise the state of things would not be as sorry as it is).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCHv2] am: fix patch format detection for Thunderbird "Save As" emails
From: Nanako Shiraishi @ 2010-01-05 22:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stephen Boyd, git
In-Reply-To: <1261172078-9174-1-git-send-email-bebarino@gmail.com>
Junio, could you tell us what happened to this thread?
After a lengthy discussion, nothing happened.
^ permalink raw reply
* Re: [RFC/PATCH] branch: new option --will-track
From: Nanako Shiraishi @ 2010-01-05 22:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Dave Olszewski
In-Reply-To: <7vaaxhdu1f.fsf@alter.siamese.dyndns.org>
Junio, could you tell us what happened to this thread?
After "--will-track" was discussed and agreed not to be the best
solution, and "pull --remember" and "branch --configure" were
suggested, nothing happened.
^ permalink raw reply
* 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
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