* 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: [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
* 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
* (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
* 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
* 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: 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: 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: 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: 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: [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: 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: 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: [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: 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: Carlos Martín Nieto @ 2012-01-10 21:33 UTC (permalink / raw)
To: Albert Astals Cid; +Cc: git
In-Reply-To: <5142795.2dTmMhVRTP@xps>
[-- Attachment #1: Type: text/plain, Size: 671 bytes --]
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
>
> 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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: rsync a *bunch* of git repos
From: Seth Robertson @ 2012-01-10 21:24 UTC (permalink / raw)
To: Jason; +Cc: git
In-Reply-To: <20120110211548.GD10255@titan.lakedaemon.net>
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.
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
* [BUG] git archive broken in 1.7.8.1
From: Albert Astals Cid @ 2012-01-10 21:18 UTC (permalink / raw)
To: git
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
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.
Is that a regression or should have never it worked and the current behaviour
is the correct one?
Albert
^ permalink raw reply
* rsync a *bunch* of git repos
From: Jason @ 2012-01-10 21:15 UTC (permalink / raw)
To: git
All,
I have a home directory with a lot of git repos in it. Possibly over a
hundred. This is a good thing. :-) However, I'm in the process of
changing OS's and need to move my home directory out of my root
partition into its own partition.
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.
Going through the git repos one by one would be long and prone to
errors, so I'm looking at alternatives. Does this look ok?
## From single user mode, or live cd
$ su -
# mkfs.ext4 /dev/sda3
# mount /dev/sda3 /mnt/home
# rsync --progress -avu /home/ /mnt/home/
# umount /mnt/home
# mv /home /home.orig
# mkdir /home
### Sanity check?
# mount /dev/sda3 /home
# rsync -avun /home.orig/ /home/
That'll check that rsync thinks things are ok, but what about git? Is
there a git sanity check I could run to detect that three hardlinks
still point to the same inode?
One alternative may be to boot to a live CD, delete everything from the
root partition except /home, then mv /home/* -> / . Basically, use my
current root partition as the new /home partition.
thx,
Jason.
^ permalink raw reply
* Re: [PATCH] attr: don't confuse prefixes with leading directories
From: Junio C Hamano @ 2012-01-10 20:25 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20120110192810.GA16018@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Jan 10, 2012 at 11:23:01AM -0800, Junio C Hamano wrote:
>
>> > I'm not sure if the right solution is to change the popping loop to:
>> >
>> > /* we will never run out of stack, because we always have the root */
>> > while (attr_stack->origin) {
>> > ...
>>
>> Yeah, that makes sense, as that existing check "attr_stack &&" was a
>> misguided defensive coding, that was _not_ defensive at all as we didn't
>> do anything after we stop iterating from that loop and without checking
>> dereferenced attr_stack->origin, which was a simple bogosity.
>>
>> >
>> > Or to be extra defensive and put:
>> >
>> > if (!attr_stack)
>> > die("BUG: we ran out of attr stack!?");
>> >
>> > after the loop, or to somehow handle the case of an empty attr stack
>> > below (which is hard to do, because it can't be triggered, so I have no
>> > idea what it would mean).
>>
>> And this is even more so.
>
> I wasn't clear: the second one is "even more so" making sense, or "even
> more so" misguided defensive coding?
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.
But the condition to break out of that loop is either we hit an elem that
satisfy the condition (in which case that elem cannot be NULL) or we
successfully saw that attr_stack->origin is NULL (in which case attr_stack
couldn't have been NULL), so it is pointless to check the NULLness of
attr_stack itself. Assertion _before_ going into the while loop might make
sense, but if we look at what bootstrap_attr_stack() does, it should be
pretty obvious that that cannot happen.
An assert(attr_stack->origin) before we use it may make sense, though, in
order to make sure we do not mistakenly pop the root one and expose the
built-in ones whose origin are set to NULL.
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;
^ permalink raw reply related
* Re: [PATCH] rebase --fix: interactive fixup mode
From: Neal Kreitzinger @ 2012-01-10 19:58 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Clemens Buchacher, git, Junio C Hamano
In-Reply-To: <4F0AA7E2.9010200@alum.mit.edu>
On 1/9/2012 2:40 AM, Michael Haggerty wrote:
>
> Two comments:
>
> * The name "--fix" might be confusing because of its similarity to the
> "fixup" command that can be specified in the interactive instructions file.
>
> * I agree with you that "interactive rebase is frequently used not to
> rebase history, but to manipulate recent commits". In fact, I use
> interactive rebase *only* for manipulating recent commits and
> non-interactive rebase *only* for changing commits' ancestry. I think
> it is a good idea to make these two uses more distinct. For example, it
> makes me nervous that I might mis-type the<upstream> parameter when I
> am trying to touch up commits and end up inadvertently rebasing the
> commits onto a new parent.
>
He could all it --touchup like you did above.
v/r,
neal
^ permalink raw reply
* Re: leaky cherry-pick
From: Jeff King @ 2012-01-10 19:50 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Pete Wyckoff, git, Junio C Hamano,
Nguyễn Thái Ngọc Duy
In-Reply-To: <CALkWK0nwE0c6qVvbauPrjmb3NX4NDeGSrvrC2ry2bjMeM4Hr0A@mail.gmail.com>
On Tue, Jan 10, 2012 at 10:58:45AM +0530, Ramkumar Ramachandra wrote:
> Interesting- I wonder where .gitattributes parsing code fits into all
> this. The purpose of bootstrap _attr_stack() is to populate
> attr_stack for its callers. Lots of memory allocation happening in
> handle_attr_line() -- that information is returned to
> bootstrap_attr_stack(). We have to keep backtracking until that
> information is provably useless and free it. Hm, convert_attrs() (in
> convert.c) is a common caller in both cases, but the populated
> attr_stack is local to attr.c; I wonder if this is the problem. If my
> hunch is right, it should be a trivial fix (caution: untested):
>
> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
>
> 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. 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".
The calling code _could_ say "btw, I am done with attributes now, so
free the memory". But we don't bother, since it's a small amount of
memory, and other parts of the code may want it later.
-Peff
^ permalink raw reply
* Re: git svn dcommit sends to wrong branch
From: Thomas Rast @ 2012-01-10 19:43 UTC (permalink / raw)
To: git
In-Reply-To: <20120110161843.GC8196@victor>
Victor Engmark <victor.engmark@terreactive.ch> writes:
> Commands:
>
> git svn clone -s -r 1:HEAD http://svn/repo
> cd repo
> git commit [thrice, in master only]
Which git version is this? Before 1.6.5 (b186a261 to be precise)
git-svn pointed master at the branch where the last commit in SVN
happened, which is not necessarily trunk. After that it tries to point
it at trunk instead. You can find out, e.g., by saying 'git show' on
the fresh clone and looking at the git-svn-id line.
> git rebase --interactive HEAD~20 [i.e., started rebase in commits before
> the clone]
> [Merged two commits I had made *after* the clone]
> git commit ...
> git dcommit
>
> This created commits on
> <http://svn/repo/branches/branch_name>! Why? Is it because HEAD~20's
> git-svn-id <http://svn/repo/branches/branch_name@22481> is on that
> branch?
The rule is that the commits go to the branch named in the git-svn-id
line of the most recent first-parent ancestor of HEAD.
You can find the "base" commit in question with
git log -1 --first-parent --grep=^git-svn-id:
> And more importantly, how do I "replay" my commits on trunk?
You need to rebase the commits on trunk, and (very important) strip the
git-svn-id lines from their messages. If you only had a handful of
commits, your best bet is to use something like
git checkout -b newbranch
git rebase -i --onto svn/trunk svn/branch_name # or whatever git-svn named the remote branches
# edit all the 'pick' into 'reword'
# in every commit message editor that pops up, remove the git-svn-id line
gitk # make sure that you like the resulting history!
git svn dcommit
(If you have many commits, git-filter-branch can do the removal
automatically, but it's a bit of a loaded gun pointed at your foot.)
If your git-rebase is too old for 'reword', you can use 'edit' instead
and then, every time that git-rebase drops you into a command line, say
git commit --amend # and edit the commit message
git rebase --continue
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Please support add -p with a new file, to add only part of the file
From: Jeff King @ 2012-01-10 19:38 UTC (permalink / raw)
To: Junio C Hamano
Cc: Thomas Rast, Jonathan Nieder, Josh Triplett, git,
Wincent Colaiuta
In-Reply-To: <7vd3ar9wto.fsf@alter.siamese.dyndns.org>
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].
Sorry for the noise.
-Peff
[1] For the record, I _do_ find myself using "git add -N" so that new
files can be part of my "git add -p" workflow. So that feature is
working as intended. It would save me a little bit of effort,
though, if I could tell git I also want to include untracked files
during the "-p" session, and dispense with the earlier "add -N".
I'd also find it useful to mark conflicts as resolved, but I think
we discussed that once before and you brought up some ugly corner
cases.
^ permalink raw reply
* Re: Please support add -p with a new file, to add only part of the file
From: Junio C Hamano @ 2012-01-10 19:33 UTC (permalink / raw)
To: Jeff King
Cc: Thomas Rast, Jonathan Nieder, Josh Triplett, git,
Wincent Colaiuta
In-Reply-To: <20120110183833.GA15787@sigill.intra.peff.net>
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 ;-)
And that is why I was contrasting an imaginary workflow to use the
existing "add -p" with requested "allow it to be used with new files" with
what somebody may "emulate" without help from "add -p" machinery, which
is:
$ cp newfile.c newfile.c-saved
$ edit newfile.c ;# delete all the things you do not want for now
$ git add newfile.c
$ mv newfile.c-saved newfile.c
I just had to point the above out, even though I agree with the use case
you shown below for final verification. They are quite different topic, as
"git diff" won't be very useful for 'inspect changes' step in the "new
file" case to begin with.
> $ hack hack hack
> $ git add -p ;# inspect and add changes
> $ git commit
>
> which is very similar to the traditional git workflow:
>
> $ hack hack hack
> $ git diff ;# inspect changes
> $ git add foo ;# add changes
> $ git commit
>
> I find myself using "add -p" almost exclusively these days, as it
> combines the two middle steps (and even though I usually am just hitting
> "y" after inspection, when I _do_ want to make a change, I am right
> there in the hunk selection loop already).
^ 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