* Re: error from 'git push' on v1.7.8-rc0
From: Junio C Hamano @ 2011-11-03 18:59 UTC (permalink / raw)
To: Stefan Näwe; +Cc: gitlist, Junio C Hamano
In-Reply-To: <CAJzBP5Q1_zX+H0jeBZNB81KLYAbtJWhUuHA3rf8CuW-_OSFXbg@mail.gmail.com>
Stefan Näwe <stefan.naewe@gmail.com> writes:
> I get errors from git push when trying to delete a (remote) branch:
>
> $ ./bin-wrappers/git versiongit version 1.7.8.rc0
> $ ./bin-wrappers/git push -q . :refs/heads/nogofatal: bad object
> 0000000000000000000000000000000000000000fatal: bad object
> 0000000000000000000000000000000000000000remote: warning: Allowing
> deletion of corrupt ref.
Thanks. I think the operation does _not_ error out and fail to delete, but
I agree that the "fatal:" message should be squelched.
^ permalink raw reply
* Re: [PATCH v3 2/7] invalidate_ref_cache(): take the submodule as parameter
From: Junio C Hamano @ 2011-11-03 18:57 UTC (permalink / raw)
To: Michael Haggerty
Cc: Junio C Hamano, git, Jeff King, Drew Northup, Jakub Narebski,
Heiko Voigt, Johan Herland, Julian Phillips
In-Reply-To: <4EB26BA0.9030609@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> Sorry I didn't respond to this earlier.
>
> The public API convention (which predates my changes) is that "char
> *submodule" arguments either point at the relative path to the submodule
> or are NULL to denote the main module. But since these are stored
> internally in a name[FLEX_ARRAY] field, I have been using "" internally
> to denote the main module. I believe that everything is done correctly,
> but I admit that the use of different conventions internally and
> externally is a potential source of programming errors.
Yes, it would have been better if the original also used "". After all,
that would make it more consistent---"sub/" means the repository goverend
by "sub/.git", and "" would mean the repository governed by ".git".
Is it hard to change to do so now, given that we won't be rushing this for
the upcoming release and we have plenty of time?
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Junio C Hamano @ 2011-11-03 18:52 UTC (permalink / raw)
To: Linus Torvalds
Cc: Ted Ts'o, Shawn Pearce, git, James Bottomley, Jeff Garzik,
Andrew Morton, linux-ide, LKML
In-Reply-To: <7v62j1gitn.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> BUT.
Ahh, sorry for the noise. I realize that we already have a winner, namely,
the proposal outlined in your message I was responding to.
It just didn't click to me that you were replacing "signed material from
pull request copied into the merge" with "contents of signed tag copied
into the merge".
So forget everything I said in the later parts of my response that talks
about refs/audit/*, and the other message except for gpgsig header being a
stronger form of existing committer line.
^ permalink raw reply
* [PATCH] completion: add --interactive option to git svn dcommit
From: Frédéric Heitzmann @ 2011-11-03 18:33 UTC (permalink / raw)
To: git, gitster; +Cc: normalperson, Frederic Heitzmann
From: Frederic Heitzmann <frederic.heitzmann@gmail.com>
see afd7f1e for more details on git svn dcommit --interactive
Signed-off-by: Frederic Heitzmann <frederic.heitzmann@gmail.com>
---
contrib/completion/git-completion.bash | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 98af8f5..d919baa 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2508,7 +2508,7 @@ _git_svn ()
__gitcomp "
--merge --strategy= --verbose --dry-run
--fetch-all --no-rebase --commit-url
- --revision $cmt_opts $fc_opts
+ --revision --interactive $cmt_opts $fc_opts
"
;;
set-tree,--*)
--
1.7.7.rc2.4.g5ec82.dirty
^ permalink raw reply related
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Junio C Hamano @ 2011-11-03 18:29 UTC (permalink / raw)
To: Linus Torvalds
Cc: Ted Ts'o, git, James Bottomley, Jeff Garzik, Andrew Morton,
linux-ide, LKML
In-Reply-To: <CA+55aFz7TeQQH3D4Tpp31cZYZoQKeK37jouo+2Kh61Wa07knfw@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Tue, Nov 1, 2011 at 2:56 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>
>> But on the other hand, in many ways, publishing your commit to the outside
>> world, not necessarily for getting pulled into the final destination
>> (i.e. your tree) but merely for other people to try it out, is the point
>> of no return (aka "don't rewind or rebase once you publish"). "pushing
>> out" might be less special than "please pull", but it still is special.
>
> So I really think that signing the top commit itself is fundamentally wrong.
It merely is a stronger form of the "committer" line in the commit
object. A random repository at Github anybody can create repositories at
can serve you a random commit with any random name on "committer" line,
and the new gpgsig header is a way to let the committer certify it
genuinely is from the committer.
I do not think for that purpose, in-commit signature is fundamentally
wrong. I was hoping it would be more useful than it turned out to be, but
I agree that it just is not suitable as a vehicle to convey "I made that
commit some time ago, and now I want you to pull it for such and such
reasons" in a larger workflow.
The "now I want you to pull it for such and such reasons" part is the pull
request, and if we are to protect them with GPG signatures, and perhaps
copy the signed part in the resulting merge, don't we have a reasonable
solution, without all the downsides the signed tag approach would cause if
we wanted to allow third party auditors to have access to the signatures
for independent auditing purposes (described in a separate message)?
Perhaps what is causing the problem is the desire to allow third party
auditors finer grained audit trail, but after having heard that $DAYJOB
folks went through each and every commit after known release points with
fine-toothed comb, I am not brave/rude/blunt enough to dismiss it as
unimportant.
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Junio C Hamano @ 2011-11-03 18:16 UTC (permalink / raw)
To: Linus Torvalds
Cc: Ted Ts'o, Shawn Pearce, git, James Bottomley, Jeff Garzik,
Andrew Morton, linux-ide, LKML
In-Reply-To: <CA+55aFwXu=+HdQ5nW11Ts5p-V=KgpxjyagKqB+Xv+qBOEEWXvQ@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> [torvalds@i5 linux]$ git fetch
> git://github.com/rustyrussell/linux.git
> rusty@rustcorp.com.au-v3.1-8068-g5087a50
> fatal: Couldn't find remote ref rusty@rustcorp.com.au-v3.1-8068-g5087a50
>
> oops. Ok, so his tag naming is *really* akward. Whatever.
It is not "Whatever".
$ git fetch git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git v3.0
fatal: Couldn't find remote ref v3.0
I do not think we ever DWIMmed fetch refspecs to prefix refs/tags/, so it
is not the naming but fetching tags without saying "git fetch tag v3.0"
(which IIRC was your invention long time ago).
If we changed this "git fetch $there v3.0" to fetch tag, it would help the
final step in your illustration, and I do not think it would be a huge
regression---the only case it becomes fuzzy is when they have v3.0 branch
at the same time, but the owner of such a repository is already playing
with fire.
> [torvalds@i5 linux]$ git fetch
> git://github.com/rustyrussell/linux.git
> refs/tags/rusty@rustcorp.com.au-v3.1-8068-g5087a50
> From git://github.com/rustyrussell/linux
> * tag
> rusty@rustcorp.com.au-v3.1-8068-g5087a50 -> FETCH_HEAD
>
> Ahh, success!
>
> Oops. Nope. It turns out that git will *peel* the tag when you fetch
> it, so FETCH_HEAD actually doesn't contain the tag object at all, but
> the commit object that the tag pointed to. MAJOR FAIL.
>
> Quite frankly, I think that's a git bug, but it's a git bug because
> "git fetch" was designed to get the commit to merge. Fair enough.
And because FETCH_HEAD started as (and probably still is) an internal
implementation detail of communication between fetch and merge inside
pull. So I do not have any issue in changing it to store tags unpeeled
there.
> [torvalds@i5 linux]$ git fetch
> git://github.com/rustyrussell/linux.git
> refs/tags/rusty@rustcorp.com.au-v3.1-8068-g5087a50:refs/tags/rusty
> From git://github.com/rustyrussell/linux
> * [new tag]
> rusty@rustcorp.com.au-v3.1-8068-g5087a50 -> rusty
> * [new tag]
> rusty@rustcorp.com.au-v3.1-2-gb1e4d20 ->
> rusty@rustcorp.com.au-v3.1-2-gb1e4d20
> * [new tag]
> rusty@rustcorp.com.au-v3.1-4896-g0acf000 ->
> rusty@rustcorp.com.au-v3.1-4896-g0acf000
> * [new tag]
> rusty@rustcorp.com.au-v3.1-8068-g5087a50 ->
> rusty@rustcorp.com.au-v3.1-8068-g5087a50
>
> WTF?
This is not WTF but "fetching a history to store the tip of it in your
refs/ namespace causes tags pointing into the history line followed
automatically", and it exactly is what you want to happen if rusty asked
you to fetch his for-linus branch (which the tag may point at) instead.
> We got three other
> tags too that we didn't even ask for!
We could change the rule to read "fetching a history to store the tip of it
in your refs/heads namespace causes autofollow". I am not sure if that is
what we really want, though.
> Again - not a fundamental design mistake in the data structures, and
> it actually made sense from a "signed tags are important release
> points" standpoint, but it makes it *really* inconvenient to use
> signed tags for signature verification.
We could update three things:
- DWIM $name in "git fetch $there $name" to refs/tags/$name when it makes
sense;
- FETCH_HEAD stores unpeeled object names; and
- "git pull" learns --verify option.
Then
$ git pull --verify rusty rusty@rustcorp.com.au-v3.1-8068-g5087a50
could integrate the history leading to that tag to your current branch
while running verify-tag on it.
For this, disabling the tag-auto-following is not necessary, as you are
not storing the retrieved tag anywhere.
That is a longwinded way to say I agree what you said below.
> So signed tags are not mis-designed from a conceptual standpoint -
> they just work really really awkwardly right now for what the kernel
> would like to do with them.
>
> With a few UI fixes, I think the signed tag thing would "just work".
>
> That said, I do think that the "signature in the pull request" should
> also "just work", and I'm not entirely sure which one is better.
I do not think it is necessarily either/or choice.
Either way does not solve anything other than validating the last hop
between the last lieutenant to the integrator without having a way to give
the verification material to third parties.
Your earlier "pull request signature could be copied into the message of
the merge that integrates the pulled history" solves 90% of the "third
party validation" issue.
With the signed tags approach, you could push out these signed tags you
get from lieutenants, but there are quite a few things that need to happen
for it to be usable:
- You or your lieutenants do not want to keep these tags in your working
repository, to be listed in "git tag -l". They are ephemeral to you and
your lieutenant, even though they have to be permanent for third
party auditors.
- Normal users of your project do not want to see them in "git tag -l"
either.
- Responses to "git fetch" and "git ls-remote" produced by "git
upload-pack" do need to (optionally) include them to allow third party
auditors to ask for them.
I wonder if an approach like the following, in addition to the three
things I listed above, may give us a workable solution:
* "git fetch linus v3.0" called by "git pull --verify linus v3.0" fetches
the v3.0 unpeeled into FETCH_HEAD, GPG verifies it, creates
refs/audit/$u, before running "git merge". $u is derived from v3.0
(given tag), the identity of the GPG signer, and perhaps timestamp to
make it both identifiable and unique under refs/audit/ hierarchy.
* You "git push origin". This causes refs/audit/* refs that point at
commits in the transferred history to auto-follow, just like the
current "git fetch $there $src:$dst" causes refs/tags/* auto-follow.
The refs/audit/* hierarchy in your public repository will be populated
by lieutenant signatures.
* (Optional) You may have signed "git tag -s 'Linux v3.2' v3.2 master"
before you push origin out, or you may have not. Currently, you do have
to "git push origin v3.2" separately if you did. The above auto-follow
could be extended to push refs/tags/* hierarchy to eliminate this step
as well.
Note that because of the way "upload-pack" protocol is structured, the
first response from "upload-pack" after it gets connection is the
advertisement of refs, and there is no way for "fetch-pack" to ask for
customized refs advertisement to it. So for this to work without incurring
undue overhead for normal users, we would need to exclude refs/audit/*
from the normal ref advertisement (i.e. "ls-remote" does not see it) so
that "git fetch" by casual users will not have to wait for megabytes of
ref advertisements before issuing its first "want" request. Probably we
can change "upload-pack" to advertise only refs/heads/*, refs/tags/*, and
HEAD by default, and a protocol extension could be added to ask for other
hierarchies for specialized needs like third party auditors.
BUT.
This does not allow third party auditors to audit how sub-subsystem
histories came into your lieutenants' history unless you also fetch from
your lieutenants in "auditor" mode to retrieve their refs/audit/* refs to
be propagated to your public repository, which all of us involved in this
thread know you wouldn't bother if it is an additional manual step (and I
personally do not think I would bother if I were you).
So the audit trail will end at one level unless we have even more complex
arrangements. The auditors know the history up to some point in the past
came from you (your last signed tag at release time, which some people may
feel a bit too sparse for auditing purposes when a security incident like
that one happens in between releases), and they know subhistories of what
you merged came from your direct lieutenants (the refs/audit/* tags the
above change allowed you to forward automatically when you published), but
they have to take the word of your direct lieutenants at face value.
I do not know if that is acceptable for $DAYJOB types, though.
^ permalink raw reply
* Re: Folder level Acces in git
From: Jens Lehmann @ 2011-11-03 18:13 UTC (permalink / raw)
To: redhat1981; +Cc: Magnus Bäck, git
In-Reply-To: <20111103071701.GA22412@jpl.local>
Am 03.11.2011 08:17, schrieb Magnus Bäck:
> On Thursday, November 03, 2011 at 07:10 CET,
> redhat1981 <redhat1981@gmail.com> wrote:
>> Inside the repository, testabc let us say there are folders folder1,
>> folder 2 etc, I want some users to have read/write, read or no access
>> to the folder1 or folder2, Is this possible in Git, I have done it in
>> SVN, Please help!!
>
> Given Git's nature, you can't have read access restrictions on a sub-git
> level (i.e. file/directory level). For basically the same reason, you
> can never prevent users from making (local) commits that modify certain
> paths (but you can encourage people to have local hooks to enforce such
> policies). What you *can* do is install a server-side update hook that
> rejects attempts to push commits that modify certain paths. If you're
> willing to trade Gitosis for Gitolite, you get that feature for free.
Directory read access control can be achieved by putting the directory
content into a submodule. You can then control who is allowed to clone
from the repo for that submodule separately from the superproject,
thereby disallowing a group of people to see (let alone modify) what is
in there.
http://progit.org/book/ch6-6.html
^ permalink raw reply
* Re: error from 'git push' on v1.7.8-rc0
From: Stefan Naewe @ 2011-11-03 17:26 UTC (permalink / raw)
To: git
In-Reply-To: <CAJzBP5Q1LaUBL_wHFfaY-cLatd_=oez9j+=60z3kxwg_47GN_Q@mail.gmail.com>
Stefan Näwe <stefan.naewe <at> gmail.com> writes:
>
> On Thu, Nov 3, 2011 at 12:43 PM, Stefan Näwe <stefan.naewe <at> gmail.com>
wrote:
> > I get errors from git push when trying to delete a (remote) branch:
> >
> > $ ./bin-wrappers/git versiongit version 1.7.8.rc0
> > $ ./bin-wrappers/git push -q . :refs/heads/nogofatal: bad object
> $ ./bin-wrappers/git push -q . :refs/heads/nogo
>
> (re-wrapped)
>
> $ ./bin-wrappers/git push -q . :refs/heads/nogo
> fatal: bad object 0000000000000000000000000000000000000000
> fatal: bad object 0000000000000000000000000000000000000000
> remote: warning: Allowing deletion of corrupt ref.
I think the problem lies actually in 'rev-list':
$ git rev-list --verify-objects 0000000000000000000000000000000000000000 \
--not --all
fatal: bad object 0000000000000000000000000000000000000000
Regards,
Stefan
^ permalink raw reply
* Re: How to make "git push/pull" work in non-clone repo?
From: Andreas Schwab @ 2011-11-03 17:00 UTC (permalink / raw)
To: Hong-Ming Su; +Cc: Kirill Likhodedov, git
In-Reply-To: <CANiMyiF=C_uBXf3kV8ix=CY9Mi=cxHU-J3dn5UyJ87gu3Sm0dg@mail.gmail.com>
Hong-Ming Su <halleyinvent@gmail.com> writes:
> /d/workspace/git/work1 (master)
> $ git remote add origin ../depot
$ git branch --set-upstream master origin/master
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: git svn dcommit COMMIT silently checks in everything if COMMIT is not a complete revision
From: Thomas Rast @ 2011-11-03 16:28 UTC (permalink / raw)
To: Reuben Thomas; +Cc: git
In-Reply-To: <CAOnWdoj1eUipRd8M=jsAPdDTNcgEbT7adWR78iU5Oac9DvODkQ@mail.gmail.com>
Reuben Thomas wrote:
> If I run
>
> git svn dcommit COMMIT
>
> with COMMIT being an unambiguous, but partial revision string, it
> behaves like git svn dcommit, i.e. commits everything.
In what git version? How do I reproduce? I just ran a simple test
and can't:
svnadmin create svnrepo
svn co file://$(pwd)/svnrepo svnwt
cd svnwt
echo a > a
svn add a
svn ci -m'do a'
cd ..
git svn clone file://$(pwd)/svnrepo gitwt
cd gitwt
echo b > a
git add a
git commit -mb
echo c>a
git add a
git commit -mc
git log --oneline
git svn dcommit 1b4c4e1
where 1b4c4e1 was the abbreviated hash of the parent commit (i.e., the
commit 'b'). As expected, it commits everything *up to* 1b4c4e1 from
a detached HEAD, not affecting the current branch.
Note that this is different from what you describe:
> (If I remember to copy and paste the whole nine yards of the
> revision string, it works as expected, i.e. commits just that
> revision.)
It was never designed to commit "just that revision".
By "it" I mean 5eec27e (git-svn: let 'dcommit $rev' work on $rev
instead of HEAD, 2009-05-29), which changed it to the current
semantics and went into 1.6.4. Before that, 'git svn dcommit <foo>'
did something weird and you should avoid giving it arguments.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: How to find a commit that introduces (not removes) a string?
From: Vijay Lakshminarayanan @ 2011-11-03 16:13 UTC (permalink / raw)
To: Sebastian Schuberth; +Cc: git
In-Reply-To: <j8to8h$vqd$1@dough.gmane.org>
Sebastian Schuberth <sschuberth@gmail.com> writes:
> Hi all,
>
> I know about git log's -S / -G, but I'm unable to make these search through *introduced* strings only. Is there a way to do so?
This appears to work:
$ for ref in `git log -SWORD --pretty=format:"%h"` ; do
git log -1 -p $ref | grep WORD | grep -E '^[+]' > /dev/null ;
if [ $? -eq 0 ]; then
echo $ref;
fi ;
done
substitute WORD for what you're looking for. Note that it is repeated
twice.
> Thanks!
>
> PS: I also read [1], but although the author claims to be interested in introduced strings only, he seems to be satisfied with -G, which slightly puzzles me.
>
> [1] http://stackoverflow.com/questions/5816134/git-finding-a-commit-that-introduced-a-string
--
Cheers
~vijay
^ permalink raw reply
* Re: How to make "git push/pull" work in non-clone repo?
From: Hong-Ming Su @ 2011-11-03 16:10 UTC (permalink / raw)
To: Kirill Likhodedov; +Cc: git
In-Reply-To: <F802D297-95A0-4B1E-894D-9681E0EEF3AD@jetbrains.com>
Thank for your hints. I get "git push" work. The "git pull" need argument.
/d/workspace/git
$ ls
depot work1 work2
/d/workspace/git
$ git clone --bare work1 depot
Cloning into bare repository depot...
done.
/d/workspace/git/work1 (master)
$ git push
fatal: No destination configured to push to.
/d/workspace/git/work1 (master)
$ git pull
fatal: No remote repository specified. Please, specify either a URL or a
remote name from which new revisions should be fetched.
/d/workspace/git/work1 (master)
$ git remote add origin ../depot
/d/workspace/git/work1 (master)
$ git push
Everything up-to-date
/d/workspace/git/work1 (master)
$ git pull
From ../depot
* [new branch] master -> origin/master
You asked me to pull without telling me which branch you
want to merge with, and 'branch.master.merge' in
your configuration file does not tell me, either. Please
specify which branch you want to use on the command line and
try again (e.g. 'git pull <repository> <refspec>').
See git-pull(1) for details.
If you often merge with the same branch, you may want to
use something like the following in your configuration file:
[branch "master"]
remote = <nickname>
merge = <remote-ref>
[remote "<nickname>"]
url = <url>
fetch = <refspec>
/d/workspace/git/work1 (master)
$ git pull origin master:master
Already up-to-date.
2011/11/4 Kirill Likhodedov <Kirill.Likhodedov@jetbrains.com>:
>
>
> 03.11.2011, в 17:59, Hong-Ming Su:
>
>> I create a repo X with git init. After several commit in X, I clone a
>> bare repo Y from X.
>> I try to continue work in X, and push to/pull from Y. The command git
>> push and git pull fails. I see the error message but I do not know
>> which git command can fix that problem.
>> Then I clone Z from Y. git push/pull works in Z.
>> How to make "git push/pull" the same in X as in Z?
>>
>
>
> By cloning Y from X you made X to be a parent of Y while you need vice versa.
> To fix this add Y as a remote to X and set up tracking for you master branch.
>
> By the way, in such cases you'd better write commands you've executed, and the error report you've got.
> " I see the error message but I do not know which git command can fix that problem" - this is zero of useful information.
>
> ----------------------------------
> Kirill Likhodedov
> JetBrains, Inc
> http://www.jetbrains.com
> "Develop with pleasure!"
>
>
^ permalink raw reply
* Re: Repository data loss in fast-export with a merge of a deleted submodule
From: Joshua Jensen @ 2011-11-03 16:05 UTC (permalink / raw)
To: git@vger.kernel.org
In-Reply-To: <4EA9B0B5.6060005@workspacewhiz.com>
----- Original Message -----
From: Joshua Jensen
Date: 10/27/2011 1:27 PM
> We had a submodule that we deleted and then added back into the
> repository at the same location as the former submodule. When running
> fast-export, the newly 'added' files for the merge commit are listed
> and then are followed with a:
>
> M ... path/to/submodule/file
> D path/to/submodule
>
> On fast-import, the resultant repository becomes corrupt due to the
> Delete instruction above occurring AFTER the file adds/modifications.
> The new repository does not match the old repository where the
> fast-export was performed.
>
> I am not familiar with the fast-export code. Can anyone help out?
Okay, I looked into this further, and I came up with a patch that works
for me. Nevertheless, I do not understand exactly what is going on
here, so I would like to defer to someone else's patch to fix the issue.
-Josh
---
builtin/fast-export.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/builtin/fast-export.c b/builtin/fast-export.c
index 9836e6b..1abc470 100644
--- a/builtin/fast-export.c
+++ b/builtin/fast-export.c
@@ -161,6 +161,14 @@ static int depth_first(const void *a_, const void *b_)
name_a = a->one ? a->one->path : a->two->path;
name_b = b->one ? b->one->path : b->two->path;
+ /*
+ * Move 'D'elete entries first.
+ */
+ if (a->status == 'D')
+ return -1;
+ else if (b->status == 'D')
+ return 1;
+
len_a = strlen(name_a);
len_b = strlen(name_b);
len = (len_a < len_b) ? len_a : len_b;
--
^ permalink raw reply related
* Re: How to find a commit that introduces (not removes) a string?
From: Neal Kreitzinger @ 2011-11-03 15:56 UTC (permalink / raw)
To: Sebastian Schuberth; +Cc: git
In-Reply-To: <j8to8h$vqd$1@dough.gmane.org>
On 11/3/2011 4:50 AM, Sebastian Schuberth wrote:
> Hi all,
>
> I know about git log's -S / -G, but I'm unable to make these search through *introduced* strings only. Is there a way to do so?
>
> Thanks!
>
> PS: I also read [1], but although the author claims to be interested in introduced strings only, he seems to be satisfied with -G, which slightly puzzles me.
>
> [1] http://stackoverflow.com/questions/5816134/git-finding-a-commit-that-introduced-a-string
>
If you are using linux, here is git diff command I use to find leftover
debug statements. I imagine the -S option will work the same in git
log. I pipe the results into grep to filter the results to show only
the additions. (I'm using git 1.7.1)
$ git diff --unified=0 -S"DEBUG" <commit> <commit> -- <path> | grep -e
"diff --" -e "+" | grep -v -e "@@" -e "+++"
maybe you will find this helpful.
v/r,
neal
^ permalink raw reply
* Re: git svn dcommit COMMIT silently checks in everything if COMMIT is not a complete revision
From: Frans Klaver @ 2011-11-03 15:56 UTC (permalink / raw)
To: Reuben Thomas; +Cc: git
In-Reply-To: <CAOnWdoj1eUipRd8M=jsAPdDTNcgEbT7adWR78iU5Oac9DvODkQ@mail.gmail.com>
Hi,
On Thu, Nov 3, 2011 at 4:12 PM, Reuben Thomas <rrt@sc3d.org> wrote:
> If I run
>
> git svn dcommit COMMIT
>
> with COMMIT being an unambiguous, but partial revision string, it
> behaves like git svn dcommit, i.e. commits everything. (If I remember
> to copy and paste the whole nine yards of the revision string, it
> works as expected, i.e. commits just that revision.)
>
> I'd expect it to work like other git commands, and understand partial
> revision strings, or at least bail out saying it was an invalid
> revision.
Sounds like git-svn skips the rev-parse, or doesn't verify. Which
version of git is this?
Workaround would probably be something like
dcommit.sh:
#!/bin/sh
COMMIT=$1
THINGY=$(git rev-parse --verify $COMMIT) || exit $?
git svn dcommit THINGY
$ dcommit.sh COMMIT
Meh. Better fix git-svn.
Cheers,
Frans
^ permalink raw reply
* git svn dcommit COMMIT silently checks in everything if COMMIT is not a complete revision
From: Reuben Thomas @ 2011-11-03 15:12 UTC (permalink / raw)
To: git
If I run
git svn dcommit COMMIT
with COMMIT being an unambiguous, but partial revision string, it
behaves like git svn dcommit, i.e. commits everything. (If I remember
to copy and paste the whole nine yards of the revision string, it
works as expected, i.e. commits just that revision.)
I'd expect it to work like other git commands, and understand partial
revision strings, or at least bail out saying it was an invalid
revision.
--
http://rrt.sc3d.org
^ permalink raw reply
* Re: How to make "git push/pull" work in non-clone repo?
From: Kirill Likhodedov @ 2011-11-03 16:09 UTC (permalink / raw)
To: Hong-Ming Su; +Cc: git
In-Reply-To: <CANiMyiFfiLnK8-q7vTZ9VAtkW8ip2NQfpR4iaU2oSnnonVDuUA@mail.gmail.com>
03.11.2011, в 17:59, Hong-Ming Su:
> I create a repo X with git init. After several commit in X, I clone a
> bare repo Y from X.
> I try to continue work in X, and push to/pull from Y. The command git
> push and git pull fails. I see the error message but I do not know
> which git command can fix that problem.
> Then I clone Z from Y. git push/pull works in Z.
> How to make "git push/pull" the same in X as in Z?
>
By cloning Y from X you made X to be a parent of Y while you need vice versa.
To fix this add Y as a remote to X and set up tracking for you master branch.
By the way, in such cases you'd better write commands you've executed, and the error report you've got.
" I see the error message but I do not know which git command can fix that problem" - this is zero of useful information.
----------------------------------
Kirill Likhodedov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
^ permalink raw reply
* Re: How to make "git push/pull" work in non-clone repo?
From: Frans Klaver @ 2011-11-03 15:07 UTC (permalink / raw)
To: Hong-Ming Su; +Cc: git
In-Reply-To: <CANiMyiFfiLnK8-q7vTZ9VAtkW8ip2NQfpR4iaU2oSnnonVDuUA@mail.gmail.com>
Hi,
On Thu, Nov 3, 2011 at 3:59 PM, Hong-Ming Su <halleyinvent@gmail.com> wrote:
> I create a repo X with git init. After several commit in X, I clone a
> bare repo Y from X.
> I try to continue work in X, and push to/pull from Y. The command git
> push and git pull fails. I see the error message but I do not know
> which git command can fix that problem.
Care to tell us which commands you use and which errors you get? It
will give clues about how to help.
> Then I clone Z from Y. git push/pull works in Z.
> How to make "git push/pull" the same in X as in Z?
Same here.
Cheers,
Frans
^ permalink raw reply
* How to make "git push/pull" work in non-clone repo?
From: Hong-Ming Su @ 2011-11-03 14:59 UTC (permalink / raw)
To: git
Hi,
I create a repo X with git init. After several commit in X, I clone a
bare repo Y from X.
I try to continue work in X, and push to/pull from Y. The command git
push and git pull fails. I see the error message but I do not know
which git command can fix that problem.
Then I clone Z from Y. git push/pull works in Z.
How to make "git push/pull" the same in X as in Z?
Thanks,
Hong-Ming
^ permalink raw reply
* Re: git rev-parse --since=1970-01-01 does not work reliably
From: Nguyen Thai Ngoc Duy @ 2011-11-03 12:36 UTC (permalink / raw)
To: Dmitry V. Levin; +Cc: git
In-Reply-To: <20111101124434.GB22229@altlinux.org>
2011/11/1 Dmitry V. Levin <ldv@altlinux.org>:
> BTW, the timezone specifier (UTC) in "git rev-parse --since='1970-01-01 UTC'"
> seems to be completely ignored by date string parser.
It takes this "00:00 1970-01-01 UTC"
--
Duy
^ permalink raw reply
* [PATCH] log: allow to specify diff pathspec in addition to prune pathspec
From: Nguyễn Thái Ngọc Duy @ 2011-11-03 12:15 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <1320314474-19536-1-git-send-email-pclouds@gmail.com>
Pathspec in "git log -p <pathspec>" is used for both commit pruning
and diff generation. If --full-diff is given, then diff pathspec is
reset to generate complete diff.
This patch gives more control to diff generation. The first pathspec
in "git log -p -- <pathspec> -- <pathspec>" is used as commit pruning
as usual. The second one is used for diff generation. So --full-diff
now is essentially "git log -p -- <pathspec> --".
This form requires specifying "--" twice. If a file name happens to be
"--", it may be misunderstood as the second "--" marker. This is an
unfortunate consequence for this syntax. Users can still use "./--" or
similar to workaround this.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Version 2. Now it looks more acceptable.
Documentation/git-log.txt | 9 +++++++--
revision.c | 28 +++++++++++++++++++++++++---
2 files changed, 32 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index 249fc87..8e00dbc 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -9,7 +9,7 @@ git-log - Show commit logs
SYNOPSIS
--------
[verse]
-'git log' [<options>] [<since>..<until>] [[\--] <path>...]
+'git log' [<options>] [<since>..<until>] [[\--] <path>... [\-- <path>...]]
DESCRIPTION
-----------
@@ -52,11 +52,12 @@ OPTIONS
commit was reached.
--full-diff::
- Without this flag, "git log -p <path>..." shows commits that
+ Without this flag, `git log -p <path>...` shows commits that
touch the specified paths, and diffs about the same specified
paths. With this, the full diff is shown for commits that touch
the specified paths; this means that "<path>..." limits only
commits, and doesn't limit diff for those commits.
+ It is equivalent to `git log -p \-- <path>... \--`.
+
Note that this affects all diff-based output types, e.g. those
produced by --stat etc.
@@ -76,6 +77,10 @@ produced by --stat etc.
+
To prevent confusion with options and branch names, paths may need to
be prefixed with "\-- " to separate them from options or refnames.
++
+If the second "\--" is found, the following pathspec is used to limit
+diff generation. Note that this affects all diff-based output types,
+e.g. those produced by --stat etc.
include::rev-list-options.txt[]
diff --git a/revision.c b/revision.c
index 8764dde..f560647 100644
--- a/revision.c
+++ b/revision.c
@@ -1682,20 +1682,37 @@ static int handle_revision_pseudo_opt(const char *submodule,
*/
int setup_revisions(int argc, const char **argv, struct rev_info *revs, struct setup_revision_opt *opt)
{
- int i, flags, left, seen_dashdash, read_from_stdin, got_rev_arg = 0;
+ int i, flags, left, read_from_stdin, got_rev_arg = 0;
+ int seen_dashdash, seen_second_dashdash;
struct cmdline_pathspec prune_data;
+ struct cmdline_pathspec diff_data;
const char *submodule = NULL;
memset(&prune_data, 0, sizeof(prune_data));
+ memset(&diff_data, 0, sizeof(diff_data));
if (opt)
submodule = opt->submodule;
/* First, search for "--" */
- seen_dashdash = 0;
+ seen_dashdash = seen_second_dashdash = 0;
for (i = 1; i < argc; i++) {
+ int i2;
const char *arg = argv[i];
if (strcmp(arg, "--"))
continue;
+
+ /* Search for second "--" */
+ for (i2 = i + 1; i2 < argc; i2++) {
+ const char *arg = argv[i2];
+ if (strcmp(arg, "--"))
+ continue;
+ argv[i2] = NULL;
+ if (argv[i2 + 1])
+ append_prune_data(&diff_data, argv + i2 + 1);
+ seen_second_dashdash = 1;
+ break;
+ }
+
argv[i] = NULL;
argc = i;
if (argv[i + 1])
@@ -1817,7 +1834,12 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, struct s
/* Can't prune commits with rename following: the paths change.. */
if (!DIFF_OPT_TST(&revs->diffopt, FOLLOW_RENAMES))
revs->prune = 1;
- if (!revs->full_diff)
+ if (seen_second_dashdash) {
+ ALLOC_GROW(diff_data.path, diff_data.nr+1, diff_data.alloc);
+ diff_data.path[diff_data.nr++] = NULL;
+ diff_tree_setup_paths(diff_data.path, &revs->diffopt);
+ }
+ else if (!revs->full_diff)
diff_tree_setup_paths(revs->prune_data.raw, &revs->diffopt);
}
if (revs->combine_merges)
--
1.7.4.74.g639db
^ permalink raw reply related
* Re: error from 'git push' on v1.7.8-rc0
From: Stefan Näwe @ 2011-11-03 11:49 UTC (permalink / raw)
To: gitlist, Junio C Hamano
In-Reply-To: <CAJzBP5Q1_zX+H0jeBZNB81KLYAbtJWhUuHA3rf8CuW-_OSFXbg@mail.gmail.com>
On Thu, Nov 3, 2011 at 12:43 PM, Stefan Näwe <stefan.naewe@gmail.com> wrote:
> I get errors from git push when trying to delete a (remote) branch:
>
> $ ./bin-wrappers/git versiongit version 1.7.8.rc0
> $ ./bin-wrappers/git push -q . :refs/heads/nogofatal: bad object
$ ./bin-wrappers/git push -q . :refs/heads/nogo
(re-wrapped)
$ ./bin-wrappers/git push -q . :refs/heads/nogo
fatal: bad object 0000000000000000000000000000000000000000
fatal: bad object 0000000000000000000000000000000000000000
remote: warning: Allowing deletion of corrupt ref.
Stefan
--
----------------------------------------------------------------
python -c "print '73746566616e2e6e6165776540676d61696c2e636f6d'.decode('hex')"
^ permalink raw reply
* error from 'git push' on v1.7.8-rc0
From: Stefan Näwe @ 2011-11-03 11:43 UTC (permalink / raw)
To: gitlist, Junio C Hamano
I get errors from git push when trying to delete a (remote) branch:
$ ./bin-wrappers/git versiongit version 1.7.8.rc0
$ ./bin-wrappers/git push -q . :refs/heads/nogofatal: bad object
0000000000000000000000000000000000000000fatal: bad object
0000000000000000000000000000000000000000remote: warning: Allowing
deletion of corrupt ref.
I bisected this to: 52fed6e receive-pack: check connectivity before
concluding "git push"
$ git describe 52fed6e~1
v1.7.5.3-492-gf96400c
$ ./bin-wrappers/git version
git version 1.7.5.3.492.gf9640
$ ./bin-wrappers/git push -q . :refs/heads/nogo
remote: warning: Allowing deletion of corrupt ref.
It makes no difference if the branch to be deleted exists, or not.
Regards,
Stefan
--
----------------------------------------------------------------
python -c "print '73746566616e2e6e6165776540676d61696c2e636f6d'.decode('hex')"
^ permalink raw reply
* Re: [PATCH 1/2] git-gui: make config gui.warndetachedcommit a boolean
From: Bert Wesarg @ 2011-11-03 11:27 UTC (permalink / raw)
To: Pat Thoyts; +Cc: Heiko Voigt, git, Bert Wesarg
In-Reply-To: <0f4995b5df707782c73ec83171fb2f512ae887ef.1319312280.git.bert.wesarg@googlemail.com>
On Sat, Oct 22, 2011 at 21:39, Bert Wesarg <bert.wesarg@googlemail.com> wrote:
> Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
> ---
> lib/commit.tcl | 2 +-
> lib/option.tcl | 1 +
> 2 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/lib/commit.tcl b/lib/commit.tcl
> index 372bed9..e27e148 100644
> --- a/lib/commit.tcl
> +++ b/lib/commit.tcl
> @@ -263,7 +263,7 @@ proc commit_commitmsg {curHEAD msg_p} {
> global is_detached repo_config
> global pch_error
>
> - if {$is_detached && $repo_config(gui.warndetachedcommit)} {
> + if {$is_detached && [is_config_true gui.warndetachedcommit]} {
> set msg [mc "You are about to commit on a detached head.\
> This is a potentially dangerous thing to do because if you switch\
> to another branch you will loose your changes and it can be difficult\
> diff --git a/lib/option.tcl b/lib/option.tcl
> index 719103a..f7f866b 100644
> --- a/lib/option.tcl
> +++ b/lib/option.tcl
> @@ -156,6 +156,7 @@ proc do_options {} {
> {i-0..99 gui.commitmsgwidth {mc "Commit Message Text Width"}}
> {t gui.newbranchtemplate {mc "New Branch Name Template"}}
> {c gui.encoding {mc "Default File Contents Encoding"}}
> + {b gui.warndetachedcommit {mc "Warn before commiting to a detached head"}}
> {s gui.stageuntracked {mc "Staging of untracked files"} {list "yes" "no" "ask"}}
> } {
> set type [lindex $option 0]
Pat,
if you're interessted in this patch, please fix the typo in the second
hunk, mentioning 'commiting'.
Also shouldn't this variable be called gui.warndetachedhead?
Thanks.
Bert
> --
> 1.7.7.908.g383b5
>
>
^ permalink raw reply
* Re: git-p4: problem with commit 97a21ca50ef8
From: Vitor Antunes @ 2011-11-03 11:04 UTC (permalink / raw)
To: Michael Wookey; +Cc: Pete Wyckoff, Git Mailing List, Luke Diamand
In-Reply-To: <CAOk9v+_xaS_Y1m17TROOSjgiscT+QEJWbpZbAZFmh8_tAviF6Q@mail.gmail.com>
Hi Michael,
On Wed, Nov 2, 2011 at 10:42 PM, Michael Wookey <michaelwookey@gmail.com> wrote:
> I tried your suggested version of git-p4 (at rev 630fb678c46c) and
> unfortunately, the perforce repository fails to import. Firstly, there
> was a problem with importing UTF-16 encoded files, secondly the
> "apple" filetype files are still skipped.
I had no intention of directing you to try that version. Sorry for
misleading you on this.
I just found it interesting that P4's KB contains an article that
directs users to another version which isn't this one.
--
Vitor Antunes
^ 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