* Re: rsync a *bunch* of git repos
From: Philip Oakley @ 2012-01-10 22:00 UTC (permalink / raw)
To: Jason, Seth Robertson; +Cc: git
In-Reply-To: <201201102124.q0ALOowL026941@no.baka.org>
From: "Seth Robertson" <in-gitvger@baka.org> Sent: Tuesday, January 10, 2012
9:24 PM
> In message <20120110211548.GD10255@titan.lakedaemon.net>, Jason writes:
>
> The nuts and bolts of this aren't difficult, the problem is I don't
> have
> a complete understanding of how git stores data. I've heard in the
> past that it uses a lot of hardlinks and softlinks. I need to make
> sure, that once I transfer the data, and reboot the machine with the
> new
> partition mounted under /home, that all my git repos will be okay.
>
> Under most circumstances, git will do the right thing. Only if you
> use specific flags on clone (like --shared or --reference) might
> something go wrong, and as the manual page explains, you can use
> git-repack to undo these.
I think there is an exception for certain git submodule setups with local
repos, where the gitdir link is hard coded to the absolute machine path.
There has been some discussion on the list recently about trying to cover
this case.
>
> The real solution is, after you rsync, to:
>
> for f in */.git; do (cd $f; git fsck >&/dev/null || echo "$f is BAD!!");
> done
>
> If you get no output, you should be golden. If you get output, check
> to make sure the repo you are copying from is good as well.
>
> -Seth Robertson
^ permalink raw reply
* Re: [BUG] git archive broken in 1.7.8.1
From: Albert Astals Cid @ 2012-01-10 22:05 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: git
In-Reply-To: <20120110213344.GI2714@centaur.lab.cmartin.tk>
El Dimarts, 10 de gener de 2012, a les 22:33:44, Carlos Martín Nieto va
escriure:
> On Tue, Jan 10, 2012 at 10:18:41PM +0100, Albert Astals Cid wrote:
> > CC me on answers since i'm not subscribed to the list
> >
> > Hi, one of our [KDE] anongit servers was updated to 1.7.8.1 and not the
> > syntax
> >
> > git archive --remote=git://anongit.kde.org/repo.git HEAD:path
>
> This syntax is no longer allowed due to some security tightening. Use
> the alternate syntax
>
> git archive --remote=git://anongit.kde.org/repo.git HEAD -- path
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?
Thanks for the fast answer!
Albert
>
> > does not seem to return a valid tar archive anymore when it did work
> > previously. In fact the man page of my version has that syntax in one of
> > the examples.
>
> That sounds like a documentation bug.
>
> cmn
^ permalink raw reply
* Re: Please support add -p with a new file, to add only part of the file
From: Josh Triplett @ 2012-01-10 22:29 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Thomas Rast, Jonathan Nieder, git,
Wincent Colaiuta
In-Reply-To: <20120110193857.GA19665@sigill.intra.peff.net>
On Tue, Jan 10, 2012 at 02:38:57PM -0500, Jeff King wrote:
> On Tue, Jan 10, 2012 at 11:33:39AM -0800, Junio C Hamano wrote:
>
> > Jeff King <peff@peff.net> writes:
> >
> > >> Even if you start with "add -N", there won't be individual "hunks" you can
> > >> pick and choose from diffing emptiness and the whole new file, so you end
> > >> up using "edit hunk" interface.
> > >
> > > I don't think the main impetus for this is that people necessarily want
> > > to pick and choose hunks from added files.
> >
> > Well, read the subject of your e-mail and tell me what it says ;-)
>
> Heh. Oops.
>
> Yes, I agree that "add -p" is not especially useful for that case, and
> the workflow I was describing is very different[1].
I've gotten used to editing diffs directly, and when I just want to
include subsets of a file on a chunk-by-chunk basis (for instance, one
new function but not another new function), I'd find it a lot easier and
less error-prone to "git add -p newfile" and edit a diff than to copy
the file aside, edit the original to delete pieces I don't want, add,
commit, and copy the file back.
Most importantly, I want to use "git add -p" because I know it'll
*never* modify my working copy, only the index. I find that a useful
safety property.
Apart from that, it also means I have less mental state to track
("remember to copy the original file back later").
- Josh Triplett
^ permalink raw reply
* Re: rsync a *bunch* of git repos
From: Junio C Hamano @ 2012-01-10 22:30 UTC (permalink / raw)
To: Philip Oakley; +Cc: Jason, Seth Robertson, git
In-Reply-To: <25207BDC675840DEA94AA2B04D6783BD@PhilipOakley>
"Philip Oakley" <philipoakley@iee.org> writes:
> I think there is an exception for certain git submodule setups with
> local repos, where the gitdir link is hard coded to the absolute
> machine path. There has been some discussion on the list recently
> about trying to cover this case.
But if you read the original post carefully, all repositories involved are
under /home before the transition, and they will move to the exact same
place under /home anyway, so I do not think the discussion you have in
mind would apply to this case.
The only thing that is needed after the move would be to run
git update-index --refresh
in all of the repositories, I think.
^ permalink raw reply
* Re: [PATCH] attr: don't confuse prefixes with leading directories
From: Jeff King @ 2012-01-10 22:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7h0z9ufu.fsf@alter.siamese.dyndns.org>
On Tue, Jan 10, 2012 at 12:25:09PM -0800, Junio C Hamano wrote:
> Sorry for sending a half-baked response. The initial draft of my response
> had just "that makes sense" and nothing else in the first paragraph.
>
> If the original meant to be defensive, it should have had your "extra
> defensive" die(), but it didn't.
> [...]
> diff --git a/attr.c b/attr.c
> index ad7eb9c..4d3b61a 100644
> --- a/attr.c
> +++ b/attr.c
> @@ -566,7 +567,9 @@ static void prepare_attr_stack(const char *path, int dirlen)
>
> /*
> * Pop the ones from directories that are not the prefix of
> - * the path we are checking.
> + * the path we are checking. Break out of the loop when we see
> + * the root one (whose origin is an empty string "") or the builtin
> + * one (whose origin is NULL) without popping it.
> */
> while (attr_stack->origin) {
> int namelen = strlen(attr_stack->origin);
> @@ -586,6 +589,13 @@ static void prepare_attr_stack(const char *path, int dirlen)
> * Read from parent directories and push them down
> */
> if (!is_bare_repository() || direction == GIT_ATTR_INDEX) {
> + /*
> + * bootstrap_attr_stack() should have added, and the
> + * above loop should have stopped before popping, the
> + * root element whose attr_stack->origin is set to an
> + * empty string.
> + */
> + assert(attr_stack->origin);
> while (1) {
> char *cp;
Yeah, this version looks good to me (though I thought we usually spelled
assert as die("BUG: ...")).
-Peff
^ permalink raw reply
* Re: [BUG] git archive broken in 1.7.8.1
From: Carlos Martín Nieto @ 2012-01-10 22:50 UTC (permalink / raw)
To: Albert Astals Cid; +Cc: git, peff
In-Reply-To: <1431498.0yPWNQLupF@xps>
[-- Attachment #1: Type: text/plain, Size: 1873 bytes --]
On Tue, Jan 10, 2012 at 11:05:45PM +0100, Albert Astals Cid wrote:
> El Dimarts, 10 de gener de 2012, a les 22:33:44, Carlos Martín Nieto va
> escriure:
> > On Tue, Jan 10, 2012 at 10:18:41PM +0100, Albert Astals Cid wrote:
> > > CC me on answers since i'm not subscribed to the list
> > >
> > > Hi, one of our [KDE] anongit servers was updated to 1.7.8.1 and not the
> > > syntax
> > >
> > > git archive --remote=git://anongit.kde.org/repo.git HEAD:path
> >
> > This syntax is no longer allowed due to some security tightening. Use
> > the alternate syntax
> >
> > git archive --remote=git://anongit.kde.org/repo.git HEAD -- path
>
> 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.
>
> Thanks for the fast answer!
>
> Albert
>
> >
> > > does not seem to return a valid tar archive anymore when it did work
> > > previously. In fact the man page of my version has that syntax in one of
> > > the examples.
> >
> > That sounds like a documentation bug.
Notice that the syntax is for the local case, not for --remote.
cmn
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: Regulator updates for 3.3
From: Linus Torvalds @ 2012-01-10 22:54 UTC (permalink / raw)
To: Mark Brown; +Cc: Liam Girdwood, linux-kernel, Junio C Hamano, Git Mailing List
In-Reply-To: <20120110222711.GK7164@opensource.wolfsonmicro.com>
On Tue, Jan 10, 2012 at 2:27 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
>
> 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.
This is actually one of my major gripes with the git UI, and one of
the few areas where I really think I screwed up: I made merging *too*
easy by default. I should have made it always start up an editor for a
merge message, the way it does for a commit - rather than just do a
trivial pointless merge without even asking the user for a reason for
the merge.
So looking at that almost two months of regulator history in
gitk d52739c62e00..269d430131b6
I would not have reacted badly at all if there were one or two of
those merges, and they actually had a reason associated with them.
Sadly, due to that git UI mess-up, that's harder to do than it should
be. Oh, it's easy enough with "git merge --no-commit" followed by just
"git commit", and then you get the normal git editor window.
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..
Linus
^ permalink raw reply
* 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
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