* Re: [BUG] git archive broken in 1.7.8.1
From: Allan Wind @ 2012-01-10 23:01 UTC (permalink / raw)
To: git
In-Reply-To: <1431498.0yPWNQLupF@xps>
On 2012-01-10 23:05:45, Albert Astals Cid wrote:
> Unfortunately this producess a tarball with a different layout, e.g.
>
> git archive --remote=git://anongit.kde.org/kgraphviewer.git HEAD:doc/en_US
> gives me a tarball with the doc/en_US files in the root
Meaning the files you have stored in git under doc/en_US are
dumped in the root directory of the tar? That does not sound
like desired behavior for the feature.
/Allan
--
Allan Wind
Life Integrity, LLC
<http://lifeintegrity.com>
^ permalink raw reply
* Re: Regulator updates for 3.3
From: Mark Brown @ 2012-01-10 23:17 UTC (permalink / raw)
To: Linus Torvalds
Cc: Liam Girdwood, linux-kernel, Junio C Hamano, Git Mailing List
In-Reply-To: <CA+55aFxvQF=Bm4ae6euB_UO8otMCuN9Lv37Zn3TpE-L7JH3Kzw@mail.gmail.com>
On Tue, Jan 10, 2012 at 02:54:27PM -0800, Linus Torvalds wrote:
> On Tue, Jan 10, 2012 at 2:27 PM, Mark Brown
> > Especially in the cases where the lack of the bug fix breaks the new
> > code it sems sensible enough to want to do the merges so that the
> > history includes things that actually work.
> So I don't mind merges if they have a lear reason for existing.
OK, good - I figured that was the case but wanted to make sure as you
were stating things rather more strongly than that.
Just to warn you there's also a whole stack of similar merges going to
come in via the sound tree too due to the same workflow, I *could* try
to rebuild the history and ask Takashi to redo his tree using that but
there's a lot of history there and it'd be hard to figure out which of
the merges was actually important. Is it OK to leave things as they are
for this release?
> So right now "git merge" (and "git pull") make it too easy to make
> those meaningless merge commits. If instead of seven pointless merges
> you had (say) had two merges that had messages about *why* they
> weren't pointless, I'd be perfectly happy.
> Addid junio and git to the cc just to bring up this issue of bad UI
> once again. I realize it could break old scripts to start up an editor
> window, but still..
I'd use a configuration option that popped up an editor by default, even
if I did have to manually enable it.
^ permalink raw reply
* Re: [BUG] git archive broken in 1.7.8.1
From: Jeff King @ 2012-01-10 23:21 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: Albert Astals Cid, git
In-Reply-To: <20120110225011.GJ2714@centaur.lab.cmartin.tk>
On Tue, Jan 10, 2012 at 11:50:11PM +0100, Carlos Martín Nieto wrote:
> > Unfortunately this producess a tarball with a different layout, e.g.
> >
> > git archive --remote=git://anongit.kde.org/kgraphviewer.git HEAD:doc/en_US
> > gives me a tarball with the doc/en_US files in the root
> >
> > git archive --remote=git://anongit.kde.org/kgraphviewer.git HEAD -- doc/en_US
> > gives me a tarball with the doc/en_US folders and then the files
> >
> > Is there a way to keep the old behaviour or do we need to update our scripts?
>
> Not as far as I know. However, the commit that hardened the input
> (ee27ca4a781844: archive: don't let remote clients get unreachable
> commits, 2011-11-17) does state that HEAD:doc/en_US should be valid,
> so it looks like it's actually a regression. As it's bedtime in my
> timezone, I'm blaming Peff and I'll look into this if it hasn't been
> fixed by the time I get to the office tomorrow.
It is definitely my fault. According to ee27ca4a, sub-trees were an
unfortunate casualty of the tightening. However, I did have some patches
that moved towards allowing things like that safely (basically the rev
parser needs to pass more context back to the caller).
It's evening here and I'm doing family stuff, but I'll take a look
either late tonight or tomorrow morning.
-Peff
^ permalink raw reply
* Re: [PATCH] xdiff: print post-image for common records instead of pre-image
From: Junio C Hamano @ 2012-01-10 22:58 UTC (permalink / raw)
To: René Scharfe; +Cc: git, Joey Hess
In-Reply-To: <4F072B9C.1030005@lsrfire.ath.cx>
René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> Normally it doesn't matter if we show the pre-image or th post-image
> for the common parts of a diff because they are the same. If
> white-space changes are ignored they can differ, though. The
> new text after applying the diff is more interesting in that case,
> so show that instead of the old contents.
>
> Note: GNU diff shows the pre-image.
>
> Suggested-by: Junio C Hamano <gitster@pobox.com>
> Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
I was looking at this one again, and I think one possible downside of
showing post-image for the context lines is that the resulting patch would
not apply to the pre-image tree anymore. Probably GNU folks thought that
it is a big enough issue. Or perhaps they didn't simply care either way ;-)
In any case, showing pre-image lines as the context at least makes the
patch easier to apply, but the result would be different from the intended
post-image and would appear as if indentation fixes in the patch are
reverted, so you would need manual fix-up after applying such a patch
generated with (gnu) "diff -w".
I tried to generate an output from "show -w", with this change, on a
commit that is largely indentation fix. The resulting patch seems to apply
cleanly with "apply --ignore-space-change" to the parent of the commit
"show -w" was taken from; of course the result needs some manual fix-ups
for the indentation changes, but that is not a news anyway. So I suspect
it won't be a huge downside and I think the benefit of being able to see
the post-image in the context when the user is more interested in how the
file looks like after the change outweighs it.
Thanks again.
^ permalink raw reply
* (unknown),
From: Steven Line @ 2012-01-10 23:56 UTC (permalink / raw)
To: git
Hi All,
First off I am a new user to git, I'm not a git developer or power
user. Am I in the right mailing list? If not could somebody point me
where I could get some help from experienced git people?
Here's the problem:
I need some help getting my subversion repository cloned over to git.
Our svn repository has about 12,000 commits, when I run
git svn clone -s -A authors.txt
svn+ssh://csvn@source.res.ourdomain.com/home/svn/sem sem
It runs for about 2h 15m then completes with no error messages. I have
also cloned starting at revision 6300, about the middle of the svn
repository, and I get the same results as below.
After cloning, I cd into the sem directory and run
$ git log
fatal: bad default revision 'HEAD'
$ git log --all # this seems to work
$ git branch -a # shows only about half the branches that should have
been cloned
$ ls -al sem
total 6
drwxr-xr-x 3 git other 512 Jan 10 20:58 ./
drwxr-xr-x 6 git root 512 Jan 10 20:58 ../
drwxr-xr-x 9 git other 512 Jan 10 23:13 .git/
I think this means the clone terminated prematurely but other than
that I'm stuck. There were no error messages from the clone. Could
somebody give me some suggestions on what to try? I haven't found the
answer via google yet.
Thank you for any help.
--
Steven Line
303-910-1212
^ permalink raw reply
* git svn clone terminating prematurely (I think)
From: Steven Line @ 2012-01-11 0:02 UTC (permalink / raw)
To: git
Reposting this with a better subject than (unknown) . . .
Hi All,
First off I am a new user to git, I'm not a git developer or power
user. Am I in the right mailing list? If not could somebody point me
where I could get some help from experienced git people?
Here's the problem:
I need some help getting my subversion repository cloned over to git.
Our svn repository has about 12,000 commits, when I run
git svn clone -s -A authors.txt
svn+ssh://csvn <at> source.res.ourdomain.com/home/svn/sem sem
It runs for about 2h 15m then completes with no error messages. I have
also cloned starting at revision 6300, about the middle of the svn
repository, and I get the same results as below.
After cloning, I cd into the sem directory and run
$ git log
fatal: bad default revision 'HEAD'
$ git log --all # this seems to work
$ git branch -a # shows only about half the branches that should have
been cloned
$ ls -al sem
total 6
drwxr-xr-x 3 git other 512 Jan 10 20:58 ./
drwxr-xr-x 6 git root 512 Jan 10 20:58 ../
drwxr-xr-x 9 git other 512 Jan 10 23:13 .git/
I think this means the clone terminated prematurely but other than
that I'm stuck. There were no error messages from the clone. Could
somebody give me some suggestions on what to try? I haven't found the
answer via google yet.
Thank you for any help.
--
Steven Line
303-910-1212
sline00@gmail.com
^ permalink raw reply
* Re: [GIT PULL] use generic pci_iomap on all architectures
From: Linus Torvalds @ 2012-01-11 1:51 UTC (permalink / raw)
To: Stephen Rothwell, Junio C Hamano, Git Mailing List
Cc: Michael S. Tsirkin, linux-arch, linux-kernel, Arnd Bergmann,
Jesse Barnes, Andrew Morton
In-Reply-To: <20120106084701.8f704542754db826deda318a@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 937 bytes --]
On Thu, Jan 5, 2012 at 1:47 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> On Fri, 6 Jan 2012 08:39:16 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> So why does you pull request refer to "commit
>> 805a6af8dba5dfdd35ec35dc52ec0122400b2610", I wonder? Is that just what
>> "git request-pull" produced?
>
> I see, "git request-pull" just puts in whatever you specify on the
> command line rather than the merge-base ...
.. and that is a fairly silly misfeature, since it makes the "since
commit xyz" largely meaningless.
I suspect we really should make "git request-pull" show the merge
base(s) as the "since commit", because that way the output of git
request-pull is "stable", and doesn't depend on what particular random
state you've synced up to since.
Junio, I think the patch would be as simple as the attached - totally
untested - one-liner? Comments?
Linus
[-- Attachment #2: patch.diff --]
[-- Type: text/x-patch, Size: 486 bytes --]
git-request-pull.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-request-pull.sh b/git-request-pull.sh
index d7ba1178ae75..64960d65a1c2 100755
--- a/git-request-pull.sh
+++ b/git-request-pull.sh
@@ -96,7 +96,7 @@ git show -s --format='The following changes since commit %H:
%s (%ci)
are available in the git repository at:
-' $baserev &&
+' $merge_base &&
echo " $url${ref+ $ref}" &&
git show -s --format='
for you to fetch changes up to %H:
^ permalink raw reply related
* Re: [PATCH] Fix incorrect ref namespace check
From: Nguyen Thai Ngoc Duy @ 2012-01-11 1:54 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git, Junio C Hamano
In-Reply-To: <7v39bunmno.fsf@alter.siamese.dyndns.org>
Any comments Mike?
2012/1/5 Junio C Hamano <gitster@pobox.com>:
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>
>> The reason why the trailing slash is needed is obvious. refs/stash and
>> HEAD are not namespace, but complete refs. Do full string compare on them.
>>
>> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
>> ---
>> I missed prefixcmp(..., "HEAD") right below prefixcmp(..., "refs/stash")
>
> As Michael has been actively showing interest in cleaning up the area, he
> should have been CC'ed, I would think.
>
>>
>> builtin/fetch.c | 2 +-
>> builtin/remote.c | 2 +-
>> log-tree.c | 4 ++--
>> 3 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/builtin/fetch.c b/builtin/fetch.c
>> index 33ad3aa..daa68d2 100644
>> --- a/builtin/fetch.c
>> +++ b/builtin/fetch.c
>> @@ -573,7 +573,7 @@ static void find_non_local_tags(struct transport *transport,
>>
>> for_each_ref(add_existing, &existing_refs);
>> for (ref = transport_get_remote_refs(transport); ref; ref = ref->next) {
>> - if (prefixcmp(ref->name, "refs/tags"))
>> + if (prefixcmp(ref->name, "refs/tags/"))
>> continue;
>>
>> /*
>> diff --git a/builtin/remote.c b/builtin/remote.c
>> index 583eec9..f54a89a 100644
>> --- a/builtin/remote.c
>> +++ b/builtin/remote.c
>> @@ -534,7 +534,7 @@ static int add_branch_for_removal(const char *refname,
>> }
>>
>> /* don't delete non-remote-tracking refs */
>> - if (prefixcmp(refname, "refs/remotes")) {
>> + if (prefixcmp(refname, "refs/remotes/")) {
>> /* advise user how to delete local branches */
>> if (!prefixcmp(refname, "refs/heads/"))
>> string_list_append(branches->skipped,
>> diff --git a/log-tree.c b/log-tree.c
>> index 319bd31..535b905 100644
>> --- a/log-tree.c
>> +++ b/log-tree.c
>> @@ -119,9 +119,9 @@ static int add_ref_decoration(const char *refname, const unsigned char *sha1, in
>> type = DECORATION_REF_REMOTE;
>> else if (!prefixcmp(refname, "refs/tags/"))
>> type = DECORATION_REF_TAG;
>> - else if (!prefixcmp(refname, "refs/stash"))
>> + else if (!strcmp(refname, "refs/stash"))
>> type = DECORATION_REF_STASH;
>> - else if (!prefixcmp(refname, "HEAD"))
>> + else if (!strcmp(refname, "HEAD"))
>> type = DECORATION_REF_HEAD;
>>
>> if (!cb_data || *(int *)cb_data == DECORATE_SHORT_REFS)
--
Duy
^ permalink raw reply
* Re: Regulator updates for 3.3
From: Junio C Hamano @ 2012-01-11 2:28 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Mark Brown, Liam Girdwood, linux-kernel, Git Mailing List
In-Reply-To: <CA+55aFxvQF=Bm4ae6euB_UO8otMCuN9Lv37Zn3TpE-L7JH3Kzw@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> Addid junio and git to the cc just to bring up this issue of bad UI
> once again. I realize it could break old scripts to start up an editor
> window, but still..
It is a non-starter to unconditionally start an editor. We would need a
good way for users to conveniently say "I am doing this unusual merge that
needs to be justified, and I want an editor to write my justification".
Obviously, "git merge -e regulator/for-linus" would work and is just three
keystrokes, which can be said "convenient enough" once the user gets used
to, but I think this is still inadequate as a solution, as the real
problem is it is _too_ easy to forget to give the option. Until the user
becomes _aware_ of the issues, it will not even occur to the user that
s/he _has_ to justify a merge (or not create a merge at all) in certain
circumstances and directions. After all, you have been repeating the "do
not make meaningless merges" for the past five years on the list. UI tweak
alone will not fix that.
If we are to rely on user's conscious action, I think it may be something
like a set of configurations that say things like:
- This branch is for advancing a specific topic, and not for merging
random development that happen elsewhere;
- This branch is for merging works by people downstream from me;
- This remote tracking branch (and by extension that branch at that
remote that uses this as its remote tracking branch) is my upstream and
I should not be merging back from it; and
- This remote tracking branch is my downstream, and I should freely merge
it when I heard it is ready.
and depending on the combination of what is being merged into what, toggle
the --edit option by default for "git merge" when neither "--edit" nor
"--no-edit" is given, just like "git merge" defaults to "--edit" when
merging an annotated tag.
^ permalink raw reply
* Re: [GIT PULL] use generic pci_iomap on all architectures
From: Junio C Hamano @ 2012-01-11 2:38 UTC (permalink / raw)
To: Linus Torvalds
Cc: Stephen Rothwell, Git Mailing List, Michael S. Tsirkin,
linux-arch, linux-kernel, Arnd Bergmann, Jesse Barnes,
Andrew Morton
In-Reply-To: <CA+55aFwXj2ELrTDSgFfSC2Usz99-24uFSznAP34feJiCttwayQ@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Thu, Jan 5, 2012 at 1:47 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> On Fri, 6 Jan 2012 08:39:16 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>
>>> So why does you pull request refer to "commit
>>> 805a6af8dba5dfdd35ec35dc52ec0122400b2610", I wonder? Is that just what
>>> "git request-pull" produced?
>>
>> I see, "git request-pull" just puts in whatever you specify on the
>> command line rather than the merge-base ...
>
> .. and that is a fairly silly misfeature, since it makes the "since
> commit xyz" largely meaningless.
>
> I suspect we really should make "git request-pull" show the merge
> base(s) as the "since commit", because that way the output of git
> request-pull is "stable", and doesn't depend on what particular random
> state you've synced up to since.
>
> Junio, I think the patch would be as simple as the attached - totally
> untested - one-liner? Comments?
I think it makes sense.
We use whatever garbage the user gave us (e.g. "origin/linus" which may
have been updated since the topic forked and be made irrelevant) only to
figure out where the history forked, and once we find that out we
consistently use the fork-point which has some meaning.
The parameter to "git shortlog" that appears later should also be updated
to match this, by the way, even though that should not affect the outcome
in any way.
I am however not sure what would happen when there are more than one merge
bases. I guess those who throw pull requests are not supposed to be doing
merges in reverse direction, so it should not matter ;-)
git-request-pull.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-request-pull.sh b/git-request-pull.sh
index d7ba117..38b68bb 100755
--- a/git-request-pull.sh
+++ b/git-request-pull.sh
@@ -96,7 +96,7 @@ git show -s --format='The following changes since commit %H:
%s (%ci)
are available in the git repository at:
-' $baserev &&
+' $merge_base &&
echo " $url${ref+ $ref}" &&
git show -s --format='
for you to fetch changes up to %H:
@@ -124,7 +124,7 @@ then
echo "----------------------------------------------------------------"
fi &&
-git shortlog ^$baserev $headrev &&
+git shortlog $merge_base..$headrev &&
git diff -M --stat --summary $patch $merge_base..$headrev || status=1
if test -z "$ref"
^ permalink raw reply related
* Intriguing error with Git 1.6.3.1: Too many open files
From: Soham Mehta @ 2012-01-11 2:44 UTC (permalink / raw)
To: git
We use Git (1.6.3.1) exclusively here at Box.
Starting this afternoon, we started getting errors when pushing to one of
the repos. It is a very active, bare shared repo, shared among
multiple developers. The
error is:
*"error: unable to open object pack directory: ./objects/pack: Too many
open files"
Things I tried/observed to resolve it:
1) ulimit -H = unlimited, when run as root (original error seems
misleading?). I also killed other proceses that had some open files, and
brought down the total count of open files (roughly lsof | wc -l) to <1000.
2) I can push to several other repos on the same machine just fine
3) git fsck, git gc, git-branch and git-status return the same error
4) I copied the repo (using scp -r, git-clone failed) to a different
machine, but got the same errors when pushing to it
5) I asked #git and the suggestion was that the repo is somehow corrupt and
I should re-push to it
One more thing worth mentioning: Gerrit (code review) uses the same repo
(lots of stuff in refs/changes)
If the repo is indeed not recoverable, I know how to restore it. But I'd
rather fix this if possible. Wondering if it is worth pursuing and what
might be wrong?
Thanks.
-Soham
^ permalink raw reply
* Re: Regulator updates for 3.3
From: Linus Torvalds @ 2012-01-11 2:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Mark Brown, Liam Girdwood, linux-kernel, Git Mailing List
In-Reply-To: <7vmx9v7z1r.fsf@alter.siamese.dyndns.org>
On Tue, Jan 10, 2012 at 6:28 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> It is a non-starter to unconditionally start an editor.
I really wonder. Because not being default will always lead to really
odd ways of saying "it should have been default, so we'll make up
these complex and arbitrary special rules" (like the ones you were
starting to outline).
So I really suspect it would be easier and more straightforward to
instead just bite the bullet, and say:
(a) start an editor by default if both stdin/stdout matched in fstat
and were istty().
(b) have some trivial way to disable that default behavior for people
who really want the legacy behavior. And by "trivial" I mean "set the
GIT_LEGACY_MERGE environment variable" or something.
(c) have a "--no-editor" command line switch so that scripts and/or
users that want to make it explicit (rather than rely on the hacky
legacy workaround) can do so (and a explicit "--editor" switch to
enable people to use a GUI editor even if they aren't on a terminal -
think something IDE environment, whatever).
Where (a) is so that people will always get the editor if they aren't
aware of it, and (b) is so that existing scripting environments can
then *trivially* work around the fact that we changed semantics,
including on a site-wide basis. With (c) being for future users. Of
course, just a "git merge < /dev/null" would also do it, but sounds
ridiculously hacky (and doesn't allow the "--editor" version), so that
"--no-editor" flag sounds saner and much more powerful.
Of course, if you use "-m", no editor would fire up anyway, exactly
like with "git commit", so that's one way to avoid the issue forever
(and be backwards compatible). But if you actually *want* to get the
auto-generated message and no editor, that would need that new switch.
Yes, git has been very good about not breaking semantics. But it's
happened before too when it needed to happen. We've had much bigger
breaks (like the whole "git-xyz" to "git xyz" transition, for example,
which broke a lot of scripts).
Linus
^ permalink raw reply
* Re: [GIT PULL] use generic pci_iomap on all architectures
From: Linus Torvalds @ 2012-01-11 2:52 UTC (permalink / raw)
To: Junio C Hamano
Cc: Stephen Rothwell, Git Mailing List, Michael S. Tsirkin,
linux-arch, linux-kernel, Arnd Bergmann, Jesse Barnes,
Andrew Morton
In-Reply-To: <7vipkj7ykd.fsf@alter.siamese.dyndns.org>
On Tue, Jan 10, 2012 at 6:38 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> The parameter to "git shortlog" that appears later should also be updated
> to match this, by the way, even though that should not affect the outcome
> in any way.
No, don't do that part.
Why?
Remember: there can be *multiple* merge bases. The expression
git shortlog ^$baserev $headrev
always works, but changing "baserev" to "merge_base" will suddenly
break for the multiple merge-bases case.
> I am however not sure what would happen when there are more than one merge
> bases. I guess those who throw pull requests are not supposed to be doing
> merges in reverse direction, so it should not matter ;-)
The other cases don't really care. For them, "show one merge-base" is
fine, and they are "end-point" operations (like "diff") that really
cannot handle a set of commits anyway.
But for "git shortlog", switching to using the merge base would
actually start showing commits that shouldn't be shown. It's
fundamentally a set operator, and does the right thing in the presense
of multiple merge-bases (which "diff" and "since commit XYZ" are
clearly not set operators, although arguably you could try to show all
merge bases for the "since" case).
Linus
^ permalink raw reply
* Re: Regulator updates for 3.3
From: Junio C Hamano @ 2012-01-11 3:03 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Mark Brown, Liam Girdwood, linux-kernel, Git Mailing List
In-Reply-To: <CA+55aFx5NATrpLnkMiV2vAxSAJPK7wkY2vyHbyeZGgT9+jP06w@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Tue, Jan 10, 2012 at 6:28 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>
>> It is a non-starter to unconditionally start an editor.
>
> I really wonder. Because not being default will always lead to really
> odd ways of saying "it should have been default, so we'll make up
> these complex and arbitrary special rules" (like the ones you were
> starting to outline).
>
> So I really suspect it would be easier and more straightforward to
> instead just bite the bullet, and say:
>
> (a) start an editor by default if both stdin/stdout matched in fstat
> and were istty().
>
> (b) have some trivial way to disable that default behavior for people
> who really want the legacy behavior. And by "trivial" I mean "set the
> GIT_LEGACY_MERGE environment variable" or something.
>
> (c) have a "--no-editor" command line switch so that scripts and/or
> users that want to make it explicit (rather than rely on the hacky
> legacy workaround) can do so (and a explicit "--editor" switch to
> enable people to use a GUI editor even if they aren't on a terminal -
> think something IDE environment, whatever).
Hrm. Lack of any quoted line other than the first line from my message,
together with (c) above, makes me suspect that you did not read beyond the
first line before composing this message you are responding to.
> Yes, git has been very good about not breaking semantics. But it's
> happened before too when it needed to happen. We've had much bigger
> breaks (like the whole "git-xyz" to "git xyz" transition, for example,
> which broke a lot of scripts).
Yes, I am learning from the experience to be cautious ;-)
I dunno. You just scrapped the plan for 1.7.10; it may have to be called 2.0
instead.
^ permalink raw reply
* Re: Intriguing error with Git 1.6.3.1: Too many open files
From: Jonathan Nieder @ 2012-01-11 3:09 UTC (permalink / raw)
To: Soham Mehta; +Cc: git
In-Reply-To: <CALjyegUJ+ZY7g0Lpxqs=gvAyhtYW_a3SNWVybSG4EG3X=ROV9Q@mail.gmail.com>
Hi,
Soham Mehta wrote:
> *"error: unable to open object pack directory: ./objects/pack: Too many
> open files"
Do current git versions (v1.7.4.2 or later) behave the same way?
Sorry for the trouble,
Jonathan
^ permalink raw reply
* Re: Regulator updates for 3.3
From: Linus Torvalds @ 2012-01-11 3:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Mark Brown, Liam Girdwood, linux-kernel, Git Mailing List
In-Reply-To: <7vehv77xeq.fsf@alter.siamese.dyndns.org>
On Tue, Jan 10, 2012 at 7:03 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>
>> I really wonder. Because not being default will always lead to really
>> odd ways of saying "it should have been default, so we'll make up
>> these complex and arbitrary special rules" (like the ones you were
>> starting to outline).
>
> Hrm. Lack of any quoted line other than the first line from my message,
> together with (c) above, makes me suspect that you did not read beyond the
> first line before composing this message you are responding to.
No. See again. I did read your suggestion, and that's where the "we'll
make up these complex and arbitrary special rules" comment comes from.
Did I mis-understand it?
I think it's a *horrible* idea to go down the road or some
branch-specific configurations and then, and I quote:
"depending on the combination of what is being merged into what,
toggle the --edit option by default"
THAT is the kind of design that sounds crazy.
Instead, just make editing the default. No ifs, buts, or maybe. No
configuration, no complexities - just make it act the same way our
pager logic acts (ie redirecting stdin/stdout obviously shuts down the
pager, and equally obviously needs to shut down the editor).
Then, the --edit/--no-edit flags are for future users that want to
make it explicit. But they aren't about rules, they are about just
making very explicit statements of "I don't want the editor".
The (b) thing I suggested was for "work around for people who have
legacy cases that they don't want to make explicit". I guess you could
count that as some rule, but I really think it's more of a "ok, we had
bad legacy behavior, and now we have scripts that depended on that bad
legacy".
But the notion of complex rules? That sounds really really bad. I'd
much rather get *rid* of the one complex rule we have (the "merging a
tag implies --edit"). That rule is already a hack.
Linus
^ permalink raw reply
* Re: Regulator updates for 3.3
From: Linus Torvalds @ 2012-01-11 3:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Mark Brown, Liam Girdwood, linux-kernel, Git Mailing List
In-Reply-To: <7vehv77xeq.fsf@alter.siamese.dyndns.org>
On Tue, Jan 10, 2012 at 7:03 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> I dunno. You just scrapped the plan for 1.7.10; it may have to be called 2.0
> instead.
Btw, version numbers are cheap. I already argued for updating to 2.0
just because of the new signed tag pulling, which I think is a much
bigger issue.
I don't think a small change like "start the editor by default for
merge messages" is nearly as worthy of a version number. But I
wouldn't argue against it either, exactly because those major numbers
are cheap.
It took the kernel until 2.6.39 to learn that, I think git could learn
to use its major number more freely much earlier.
Linus
^ permalink raw reply
* [PATCH] t2203: fix wrong commit command
From: Nguyễn Thái Ngọc Duy @ 2012-01-11 3:21 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy
Add commit message to avoid commit's aborting due to the lack of
commit message, not because there are INTENT_TO_ADD entries in index.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
t/t2203-add-intent.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t2203-add-intent.sh b/t/t2203-add-intent.sh
index 58a3299..2543529 100755
--- a/t/t2203-add-intent.sh
+++ b/t/t2203-add-intent.sh
@@ -41,7 +41,7 @@ test_expect_success 'cannot commit with i-t-a entry' '
echo frotz >nitfol &&
git add rezrov &&
git add -N nitfol &&
- test_must_fail git commit
+ test_must_fail git commit -m initial
'
test_expect_success 'can commit with an unrelated i-t-a entry in index' '
--
1.7.3.1.256.g2539c.dirty
^ permalink raw reply related
* Re: leaky cherry-pick
From: Ramkumar Ramachandra @ 2012-01-11 3:30 UTC (permalink / raw)
To: Jeff King
Cc: Pete Wyckoff, git, Junio C Hamano,
Nguyễn Thái Ngọc
In-Reply-To: <20120110195017.GA19961@sigill.intra.peff.net>
Hi Jeff,
Jeff King wrote:
> On Tue, Jan 10, 2012 at 10:58:45AM +0530, Ramkumar Ramachandra wrote:
>> diff --git a/attr.c b/attr.c
>> index 76b079f..12e3824 100644
>> --- a/attr.c
>> +++ b/attr.c
>> @@ -745,6 +745,7 @@ int git_check_attr(const char *path, int num,
>> struct git_attr_check *check)
>> check[i].value = value;
>> }
>>
>> + drop_attr_stack();
>> return 0;
>> }
>
> I don't think this is right.
Yeah, I figured it wasn't right by running the testsuite. I was
struggling to figure out why.
> The attr_stack is intentionally kept in
> place after a lookup as a cache, because callers are very likely to
> lookup nearby filenames. The first thing we do is pop unrelated parts of
> the stack, keep the early bits, and then push any new needed
> directories.
>
> So if you do a lookup for "foo/bar/baz/file1", the stack afterwards would
> be:
>
> $GIT_DIR/info/attributes
> foo/bar/baz/.gitattributes
> foo/bar/.gitattributes
> foo/.gitattributes
> .gitattributes
> [builtins]
>
> If you then do a lookup for "foo/bar/baz/file2", it can use the exact
> same stack without looking for or reparsing the attribute files. If you
> then do a lookup for "foo/bar/bleep/file", it pops only the entry for
> "foo/bar/baz/.gitattributes", and pushes only the entry for
> "foo/bar/bleep/.gitattributes".
I see. Thanks for the excellent explanation- I'll try implementing
this scheme.
-- Ram
^ permalink raw reply
* Re: [PATCH 2/8] revert: decouple sequencer actions from builtin commands
From: Ramkumar Ramachandra @ 2012-01-11 4:02 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Git List, Junio C Hamano
In-Reply-To: <20120110183857.GC22184@burratino>
Jonathan Nieder wrote:
> Ramkumar Ramachandra wrote:
> [...]
>> -static const char *action_name(const struct replay_opts *opts)
>> +static const char *command_name(struct replay_opts *opts)
>
> This part does a similar renaming, and drops a const while at it for
> no intelligible reason.
Carried over from the previous iteration- sorry I forgot to fix this.
> [...]
>> @@ -142,7 +147,7 @@ static void verify_opt_mutually_compatible(const char *me, ...)
>> static void parse_args(int argc, const char **argv, struct replay_opts *opts)
>> {
>> const char * const * usage_str = revert_or_cherry_pick_usage(opts);
>> - const char *me = action_name(opts);
>> + const char *me = command_name(opts);
>
> The rest is stuff like this, which follows from the first part.
>
> Stepping back, I think the idea is that "enum replay_action" is not a
> good way to identify the command name in error messages like
>
> fatal: cherry-pick: --abort cannot be used with --continue
>
> So you introduce a _new_ enum to represent the command name. Why not
> just use a string, so commands using the nice and generic sequencer
> library do not have to register themselves in a global callers list to
> use it?
Fine; I'm sold on the string idea. Also, I figured it would be
easier to explain the changes if I change this enum to a string -- I
should probably use "ease of explaining changes" as a stronger
criterion in the future when I have two competing implementations in
mind.
Thanks.
-- Ram
^ permalink raw reply
* Re: [PATCH 2/8] revert: decouple sequencer actions from builtin commands
From: Ramkumar Ramachandra @ 2012-01-11 4:17 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Git List, Junio C Hamano
In-Reply-To: <CALkWK0k=44znLr2oYSx61Mk=qdAurona0f0H4i4=YXNSAeQhHQ@mail.gmail.com>
Ramkumar Ramachandra wrote:
> Fine; I'm sold on the string idea. Also, I figured it would be
> easier to explain the changes if I change this enum to a string -- I
> should probably use "ease of explaining changes" as a stronger
> criterion in the future when I have two competing implementations in
> mind.
I wrote that too quickly. I can't stand seeing so many strcmp() calls
all over my codebase -- look at the number of instances of matching
opts->command to REPLAY_CMD_*. Why should I have to use strcmp() when
the data is semantic? It makes no sense: by spelling out the string
in so many places, I'm just making the code more error-prone, because
the compiler can't warn me if I make a spelling mistake in one place.
Why do you like the string so much? A new caller will have to
register new actions in the replay_actions enum and modify the
codebase to define a codepath for its specific case anyway: so I don't
mind it registering a new command in replay_command.
-- Ram
^ permalink raw reply
* Re: [PATCH] t2203: fix wrong commit command
From: Ramkumar Ramachandra @ 2012-01-11 4:21 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Junio C Hamano
In-Reply-To: <1326252098-2891-1-git-send-email-pclouds@gmail.com>
Hi Duy,
Nguyễn Thái Ngọc Duy wrote:
> Add commit message to avoid commit's aborting due to the lack of
> commit message, not because there are INTENT_TO_ADD entries in index.
Is there any way to differentiate between the two kinds of errors, so
that we can avoid this in the future? Can we grep the error message
for something, or inspect the exit status?
-- Ram
^ permalink raw reply
* Re: git svn clone terminating prematurely (I think)
From: Ramkumar Ramachandra @ 2012-01-11 4:34 UTC (permalink / raw)
To: Steven Line; +Cc: git
In-Reply-To: <CAJ1a7SrkDOyNRv8Spo4xvoKjP4zaXteim4h3JGcWU-nYDugx9Q@mail.gmail.com>
Hi Steven,
Steven Line wrote:
> First off I am a new user to git, I'm not a git developer or power
> user. Am I in the right mailing list? If not could somebody point me
> where I could get some help from experienced git people?
This is the right place. The Git community believes in maintaining
just one mailing list.
> I need some help getting my subversion repository cloned over to git.
> Our svn repository has about 12,000 commits, when I run
> git svn clone -s -A authors.txt
> svn+ssh://csvn <at> source.res.ourdomain.com/home/svn/sem sem
> It runs for about 2h 15m then completes with no error messages. I have
> also cloned starting at revision 6300, about the middle of the svn
> repository, and I get the same results as below.
> $ git branch -a # shows only about half the branches that should have
> been cloned
Interesting. From the git-svn-id of the most recent commit, can you
tell if there's anything especially fishy about the revision where
git-svn stops? Your Subversion repository is probably broken in some
way, but git-svn should not use that as an excuse for appearing to
finish successfully while failing in reality.
Cheers.
-- Ram
^ permalink raw reply
* Re: [BUG] gitattribute macro expansion oddity
From: Michael Haggerty @ 2012-01-11 4:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git, Henrik Grubbström, git-dev
In-Reply-To: <7v1ur7bhhe.fsf@alter.siamese.dyndns.org>
On 01/10/2012 06:22 PM, Junio C Hamano wrote:
> Regardless of this unrelated regression, after looking at what ec775c4
> wanted to do again, I am very much tempted to just revert it.
>
> It aimed to take these three
>
> * ident
> foo mybin
> bar mybin ident
>
> and wanted to omit 'ident' from "foo" when there is this macro definition
> elsewhere:
>
> [attr] mybin binary -ident
>
> But the real point of the macro was that the users do not have to know
> their internals, iow, if you explicitly specify a pattern that overrides
> the contents of the macro, that explicit pattern should win. When deciding
> the value of "ident" attribute for path "foo", "* ident" is stronger than
> "foo mybin" (the latter of which does not say anything about 'ident'
> explicitly).
I like the simplicity of the rule "apply attributes in the order found
in the .gitattributes files" better than the rule you are proposing,
which seems like it will become more complicated to explain.
For example, it would seem under your rule for the above example that
the "mybin" macro should bestow on file foo the "binary" attribute and
also the "mybin" attribute (given that macros are themselves
attributes), but not "-ident".
You would also have to decide and explain whether a macro that invokes a
macro that sets or clears attribute "foo" is "weaker" than a simple
macro that clears or sets attribute "foo".
I have one real-life use case that would become more difficult with your
rule:
# Marker for textlike files whose EOL characters haven't been
# normalized yet:
[attr]eol-fixme -text !eol
*.cc text eol=lf
# Then later, perhaps in some subdirectory's .gitattributes:
SomeParticularScrewedUpFile.cc eol-fixme
The point of the eol-fixme macro is (1) to prevent git from throwing a
tantrum and (2) to mark the file as needing cleanup sometime in the future.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH] t2203: fix wrong commit command
From: Nguyen Thai Ngoc Duy @ 2012-01-11 4:43 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: git, Junio C Hamano
In-Reply-To: <CALkWK0kDBFvssyX2ZPJ9WNzfNXD=wEJoXTRVpFWm1TDKJrvNzA@mail.gmail.com>
2012/1/11 Ramkumar Ramachandra <artagnon@gmail.com>:
> Hi Duy,
>
> Nguyễn Thái Ngọc Duy wrote:
>> Add commit message to avoid commit's aborting due to the lack of
>> commit message, not because there are INTENT_TO_ADD entries in index.
>
> Is there any way to differentiate between the two kinds of errors, so
> that we can avoid this in the future? Can we grep the error message
> for something, or inspect the exit status?
commit exits with 1 in both cases, so no.
--
Duy
^ 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