* Howto setup-git-server-over-http.txt with SSL and basic authentication?
From: Josef Wolf @ 2008-10-17 16:06 UTC (permalink / raw)
To: git
Hello folks,
I am new to git and I am trying to set up a git repository as described in
http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt
but with SSL and basic authentication.
This is what I have done:
1. Create bare git repository on the server:
root: mkdir -p /data/git/test
root: ( cd /data/git/test ; git --bare init )
root: chown -R wwwrun:www /data/git
2. Add a new DAV location to the (existing and already working) apache
config, pointing to the newly created git repository. I list only
the relevant parts here:
LoadModule dav_svn_module /usr/lib/apache2/mod_dav_svn.so
LoadModule dav_fs_module /usr/lib/apache2/mod_dav_fs.so
DAVLockDB "/data/dav/lock/DAV.lock"
Alias /git/test /data/git/test
<Location /git/test>
DAV on
Order Allow,Deny
Allow from all
AllowOverride None
AuthName "test"
AuthType Basic
AuthUserFile /m/b/httpd/passwd
AuthGroupFile /m/b/httpd/group
Require group test test-ro
SSLRequireSSL
<LimitExcept GET PROPFIND OPTIONS REPORT>
Require group test
</LimitExcept>
</Location>
3. Now it's time to test DAV access, so I go to the client:
konqueror webdavs://repo.host.org/git/test
After asking for credentials, Konqueror shows me content, and I can
read/copy/delete files to/from the DAV directory. So the server
seems to work fine.
Now I go test curl:
$ curl --cacert /etc/cacerts/myca.pem \
https://user@repo.host.org/git/test/HEAD
fails with "authentication required", but
$ curl --cacert /etc/cacerts/myca.pem --user user \
https://user@repo.host.org/git/test/HEAD
works fine. So I put this information into ~/.curlrc:
$ cat ~/.curlrc
--cacert /etc/cacerts/myca.pem
--user user
$ curl https://repo.host.org/git/test/HEAD
Enter host password for user 'user':
ref: refs/heads/master
$
this looks good now.
4. OK, now I go to the next step on the client:
$ git-config remote.upload.url https://repo.host.org/git/test/
error: could not lock config file .git/config
$
hmm, maybe I should have an empty repos here? So:
$ git init
Initialized empty Git repository in /tmp/test/.git/
$ git-config remote.upload.url https://repo.host.org/git/test/
$ git push upload master
error: Cannot access URL https://repo.host.org/git/test/, return code 60
error: failed to push some refs to 'https://repo.host.org/git/test/'
OK, from the above mentioned howto, this looks like cacert is missing.
Looks like (unlike the howto states) ~/.curlrc is ignored by git.
So I go searching for appropriate configuration options in git:
$ git-config http.sslCAPath /etc/cacerts
don't help (why?), but
$ git-config http.sslCAInfo /etc/cacerts/myca.pem
$ git push upload master
error: Cannot access URL https://repo.host.org/git/test/, return code 22
error: failed to push some refs to 'https://repo.host.org/git/test/'
Finally, that's a new error code. This is probably because the server
requires authentication. But I can't find any hints how to specify
credentials in git-config or git-push.
So now come my questions:
0. The howto says curl is used for transport. Why is my ~/.curlrc ignored?
1. Since .curlrc is ignored: How do I specify credentials for git?
2. Why don't sslCAPath work?
3. Is there a way to override credentials and sslCAPath on a per-remote
basis (as can be done with http.proxy, for example)
Any hints?
^ permalink raw reply
* Re: "checkout --track -b" broken? (with suggested fix)
From: Daniel Barkalow @ 2008-10-17 15:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jay Soffian
In-Reply-To: <7vej2fohfr.fsf@gitster.siamese.dyndns.org>
On Thu, 16 Oct 2008, Junio C Hamano wrote:
> Sorry for bringing up a potentially old issue, but I do not think the test
> added by 9ed36cf (branch: optionally setup branch.*.merge from upstream
> local branches, 2008-02-19) is correct. It does this:
>
> test_expect_success \
> 'checkout w/--track from non-branch HEAD fails' '
> git checkout -b delete-me master &&
> rm .git/refs/heads/delete-me &&
> test refs/heads/delete-me = "$(git symbolic-ref HEAD)" &&
> test_must_fail git checkout --track -b track'
>
> It creates branch 'delete-me' at the tip of 'master' to check it out, and
> then it manually deletes the branch. It expects "checkout --track -b track"
> to fail because the current branch is broken and there is no way to set up
> a tracking information for the new branch.
>
> But I think this is bogus. The checkout fails not because of lack of
> trackability (due to broken current _branch_), but because there is no
> current _commit_ to branch from.
>
> Jay CC'ed because 9ed36cf is his; Daniel CC'ed as branch.c was
> originally his.
>
> Here is an attempt to fix the test, which then revealed that the feature
> the commit introduced is broken in the tip of 'maint'. Back when 9ed36cf
> was written, test_must_fail was unavailable, and test_expect_failure meant
> something different, so transplanting this on top of that old commit won't
> reveal the breakage, but I strongly suspect that the feature was broken
> from the very beginning.
>
> The patch to branch.c is a quick fix for this issue. The resulting code
> passes all the tests, but I am not very proud of hardcoding the "HEAD" in
> the code. There must be a better way to do this.
I agree with the change to the test. I think it would be better to
hard-code "refs/heads/" instead of "HEAD", and I feel like we must have a
"is this ref name a branch?" function, if only because someone could stick
"refs/tags/foo" in HEAD, and we should still say it's not something you
could track, despite it being something different from "HEAD".
> branch.c | 4 +++-
> t/t7201-co.sh | 11 +++++------
> 2 files changed, 8 insertions(+), 7 deletions(-)
>
> diff --git c/branch.c w/branch.c
> index b1e59f2..6a75057 100644
> --- c/branch.c
> +++ w/branch.c
> @@ -129,7 +129,9 @@ void create_branch(const char *head,
> die("Cannot setup tracking information; starting point is not a branch.");
> break;
> case 1:
> - /* Unique completion -- good */
> + /* Unique completion -- good, only if it is a real ref */
> + if (track == BRANCH_TRACK_EXPLICIT && !strcmp(real_ref, "HEAD"))
> + die("Cannot setup tracking information; starting point is not a branch.");
> break;
> default:
> die("Ambiguous object name: '%s'.", start_name);
> diff --git c/t/t7201-co.sh w/t/t7201-co.sh
> index fbec70d..da1fbf8 100755
> --- c/t/t7201-co.sh
> +++ w/t/t7201-co.sh
> @@ -330,12 +330,11 @@ test_expect_success \
> test "$(git config branch.track2.merge)"
> git config branch.autosetupmerge false'
>
> -test_expect_success \
> - 'checkout w/--track from non-branch HEAD fails' '
> - git checkout -b delete-me master &&
> - rm .git/refs/heads/delete-me &&
> - test refs/heads/delete-me = "$(git symbolic-ref HEAD)" &&
> - test_must_fail git checkout --track -b track'
> +test_expect_success 'checkout w/--track from non-branch HEAD fails' '
> + git checkout master^0 &&
> + test_must_fail git symbolic-ref HEAD &&
> + test_must_fail git checkout --track -b track
> +'
>
> test_expect_success 'checkout an unmerged path should fail' '
> rm -f .git/index &&
>
^ permalink raw reply
* Re: Excluding files from git-diff
From: Michael J Gruber @ 2008-10-17 15:18 UTC (permalink / raw)
To: Erik Hahn; +Cc: git
In-Reply-To: <20081017145313.GA23471@eriks>
Erik Hahn venit, vidit, dixit 17.10.2008 16:53:
> I'm currently working on a script whose developer does not use
> git. Hence, when I mail him the patch, I don't want to include the
> .gitignore file. Is it possible to exclude a file from git-diff (except
> not adding it to git, of course?)
Am I right in assuming that by "script" you mean a manuscript consisting
of several files, rather than a single script (programme in scripting
language)? In any case:
git diff commit1 commit2 file
gives you the diff for "file" between those commits, so if you're really
interested in one file that's the way to go; you can also specify more
than one file here.
On the other hand, your .gitignore probably doesn't change that often,
so that it shouldn't show up in the diff after that anyways. Or put it
in .git/info/excludes.
Cheers,
Michael
^ permalink raw reply
* Re: Excluding files from git-diff
From: Johannes Schindelin @ 2008-10-17 15:08 UTC (permalink / raw)
To: Erik Hahn; +Cc: git
In-Reply-To: <20081017145313.GA23471@eriks>
Hi,
On Fri, 17 Oct 2008, Erik Hahn wrote:
> I'm currently working on a script whose developer does not use git.
> Hence, when I mail him the patch, I don't want to include the .gitignore
> file. Is it possible to exclude a file from git-diff (except not adding
> it to git, of course?)
You can specify everything else:
git diff -- *
Hth,
Dscho
^ permalink raw reply
* Re: Excluding files from git-diff
From: Raphael Zimmerer @ 2008-10-17 15:08 UTC (permalink / raw)
To: Erik Hahn; +Cc: git
In-Reply-To: <20081017145313.GA23471@eriks>
On Fri, Oct 17, 2008 at 04:53:13PM +0200, Erik Hahn wrote:
> I'm currently working on a script whose developer does not use
> git. Hence, when I mail him the patch, I don't want to include the
> .gitignore file. Is it possible to exclude a file from git-diff (except
> not adding it to git, of course?)
Just add the content of .gitignore to .git/info/exclude, and remove
.gitignore from the repository.
Raphael
^ permalink raw reply
* Re: Working with remotes; cloning remote references
From: Michael J Gruber @ 2008-10-17 15:08 UTC (permalink / raw)
To: Marc Branchaud; +Cc: Michael J Gruber, Peter Harris, git
In-Reply-To: <48F8A4E8.8070008@xiplink.com>
Marc Branchaud venit, vidit, dixit 17.10.2008 16:44:
> Thanks for joining the thread, Michael!
Sure, there's no need to mention it.
Well, maybe there is, given the recent discussion: Everyone can
contribute (with or without C/perl/whatever fu) and thus "pay back" for
free software, even by "only" trying to answer questions. But it
requires participation, combining efforts, rather than splitting off and
not returning... Uh, sorry, your question:
> Michael J Gruber wrote:
>> Would it be sufficient for you if a clone could trigger the main repo to
>> update its remotes (i.e. git remote update)?
>
> Hmmm, I'm not sure... How would the overall
> merge-in-changes-from-upstream process work in that case?
I thought your problem was "transporting" the remote branches from main
(which tracks external) to clone, without having the remote config for
external on the clones. In that case being able to trigger "remote
update" on main from the clones would help.
> Say the main repo has the code for "ThingOne" merged under a top-level
> thing-one/ directory:
>
> main/$ git remote add -f ThingOne git://thing/ThingOne.git
> main/$ git merge -s ours --no-commit ThingOne/master
> main/$ git read-tree --prefix=thing-one/ -i ThingOne/master
> main/$ git commit -m "Merged ThingOne into /thing-one/"
>
> Then the ThingOne folks update their code, so we want to incorporate
> their changes into our version of their code. I think you're suggesting
> that we might make a clone of the main repo then trigger a "git remote
> update" in the clone's origin:
>
> clone/$ make-origin-do-git-remote-update
>
> What's not clear to me is how to proceed from here. At this point I'm
> hoping there's some way I could do some work in the clone to merge the
> changes the ThingOne folks did into our code. I'm too new to git to
> know if there is a way forward -- is there?
>
> (With the subtree merge pattern I'd run "git pull -s subtree ThingOne
> master" in the main repo -- is there an equivalent achievable in the
> clone if the main has done a "git remote update"?)
"pull -s strategy repo master" does a fetch followed by "merge -s
strategy repomaster", where repomaster is the ref for master on repo.
So, if you got that branch (repomaster=ThingOne/master) by cloning from
main you can do the merge (subtree or other) on your clone, even without
the remote repo config for ThingOne on clone.
I guess you want to do those merges on several clones, and main, and
push everything back to main. I don't know how well that mixes, but I
don't expect problems, only unexpected ones ;)
Cheers,
Michael
^ permalink raw reply
* Excluding files from git-diff
From: Erik Hahn @ 2008-10-17 14:53 UTC (permalink / raw)
To: git
I'm currently working on a script whose developer does not use
git. Hence, when I mail him the patch, I don't want to include the
.gitignore file. Is it possible to exclude a file from git-diff (except
not adding it to git, of course?)
-Erik
--
hackerkey://v4sw5hw2ln3pr5ck0ma2u7LwXm4l7Gi2e2t4b7Ken4/7a16s0r1p-5.62/-6.56g5OR
^ permalink raw reply
* Re: Working with remotes; cloning remote references
From: Marc Branchaud @ 2008-10-17 14:44 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Peter Harris, git
In-Reply-To: <48F83FD0.90606@drmicha.warpmail.net>
Thanks for joining the thread, Michael!
Michael J Gruber wrote:
>
> I don't think there is a direct gittish way for transferring the remote
> config from one repo to a clone (other than copying what git submodule
> does with .gitmodules etc.).
That's my impression, too, so I'm suggesting that the clone/push/pull
commands get an option to work with remotes in config.
> Would it be sufficient for you if a clone could trigger the main repo to
> update its remotes (i.e. git remote update)?
Hmmm, I'm not sure... How would the overall
merge-in-changes-from-upstream process work in that case?
Say the main repo has the code for "ThingOne" merged under a top-level
thing-one/ directory:
main/$ git remote add -f ThingOne git://thing/ThingOne.git
main/$ git merge -s ours --no-commit ThingOne/master
main/$ git read-tree --prefix=thing-one/ -i ThingOne/master
main/$ git commit -m "Merged ThingOne into /thing-one/"
Then the ThingOne folks update their code, so we want to incorporate
their changes into our version of their code. I think you're suggesting
that we might make a clone of the main repo then trigger a "git remote
update" in the clone's origin:
clone/$ make-origin-do-git-remote-update
What's not clear to me is how to proceed from here. At this point I'm
hoping there's some way I could do some work in the clone to merge the
changes the ThingOne folks did into our code. I'm too new to git to
know if there is a way forward -- is there?
(With the subtree merge pattern I'd run "git pull -s subtree ThingOne
master" in the main repo -- is there an equivalent achievable in the
clone if the main has done a "git remote update"?)
Thanks,
Marc
^ permalink raw reply
* Re: [PATCH] fix guilt-pop and push to fail if no relevant patches
From: Scott Moser @ 2008-10-17 14:40 UTC (permalink / raw)
To: Josef 'Jeff' Sipek; +Cc: git
In-Reply-To: <20081017142832.GF27647@josefsipek.net>
On Fri, 17 Oct 2008, Josef 'Jeff' Sipek wrote:
> On Fri, Oct 17, 2008 at 07:37:33AM -0400, Scott Moser wrote:
> > Jeff,
> > Did you not like the patch below for some reason ?
>
> I don't remember my train of thought, but I ended up making a simpler patch
> to address the push-pushing-more-than-it-should bug. I completely missed the
> part about the exit codes.
>
good enough. I hadn't pulled in a while and didn't realize you'd made a
change. I never actually saw a problem with "pushing too much" , but
only in the exit codes.
> > > diff --git a/guilt-push b/guilt-push
> > > index 018f9ac..48f886b 100755
> > > --- a/guilt-push
> > > +++ b/guilt-push
> [snipped long diff]
>
> With my fix, this should be a 2-liner :)
for what its worth, the patch i sent only added a couple lines. It
really just changed indentation. So, the patch was long, only 2 new
lines that did anything.
anyway... I'm happy if you make it exit failure.
Thanks,
^ permalink raw reply
* Re: [PATCH] fix guilt-pop and push to fail if no relevant patches
From: Josef 'Jeff' Sipek @ 2008-10-17 14:28 UTC (permalink / raw)
To: Scott Moser; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0810170736240.27798@brickies>
On Fri, Oct 17, 2008 at 07:37:33AM -0400, Scott Moser wrote:
> Jeff,
> Did you not like the patch below for some reason ?
I don't remember my train of thought, but I ended up making a simpler patch
to address the push-pushing-more-than-it-should bug. I completely missed the
part about the exit codes.
> It seemed fairly straightforward to me that guilt-pop and guilt-push
> should exit failure if they did not do anything due to having nothing to
> do.
I'd actually say that it's not obvious, but...see below :)
> On Mon, 29 Sep 2008, Scott Moser wrote:
> > currently guilt-pop and guilt-push will exit with '0' if there are no more
> > relevant patches in the series (ie, if you've pushed or popped all of them)
> >
> > This means that you cannot do something like:
> > while guilt-push; do
> > guilt refresh || break
> > done
> >
> > for reference, quilt does exit with non-zero in those cases:
> > $ quilt push -a && quilt push
> > File series fully applied, ends at patch my.patch
> > $ echo $?
> > 1
> >
> > $ quilt pop -a; quilt pop
> > No patch removed
> > $ echo $?
> > 2
Who am I to argue against compatibility.
...
> > diff --git a/guilt-push b/guilt-push
> > index 018f9ac..48f886b 100755
> > --- a/guilt-push
> > +++ b/guilt-push
[snipped long diff]
With my fix, this should be a 2-liner :)
Sorry for missing the return code part...
Josef 'Jeff' Sipek.
--
We have joy, we have fun, we have Linux on a Sun...
^ permalink raw reply
* Re: Git hooks are not called over HTTP
From: Shawn O. Pearce @ 2008-10-17 14:11 UTC (permalink / raw)
To: Jakub Narebski; +Cc: KwangYul Seo, git
In-Reply-To: <m38wsnk24l.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> wrote:
> "KwangYul Seo" <kwangyul.seo@gmail.com> writes:
>
> > I have setup a git repository with post-receive and post-update
> > enabled. I configured hooks.envelopesender and hooks.mailinglist. I
> > confirmed that it works fine with push from local repositories.
> > However, hooks are never called when push is done over HTTP.
>
> Perhaps that would get improved when "smart" HTTP protocol gets
> implemented (currently in the phase of design, I think just after
> designing protocol).
Yes. The Git-in-HTTP protocol for push basically calls for an
embedding of send-pack/receive-pack's protocol into HTTP, and
implementation wise will probably be invoking git-receive-pack on
the web server side of the connection. So if/when that finally
gets implemented we'd run hooks over HTTP, but *ONLY* if both sides
support the new Git-in-HTTP protocol.
If both sides are still using WebDAV, no hooks, for the reason you
cited earlier.
--
Shawn.
^ permalink raw reply
* Re: Removing some files from history
From: Jakub Narebski @ 2008-10-17 12:20 UTC (permalink / raw)
To: Gennady Kushnir; +Cc: Michael J Gruber, git
In-Reply-To: <96ed5eac0810170451y69fd864jb44ef62bca468498@mail.gmail.com>
Please do not toppost, and quote only fragments you are replying to.
"Gennady Kushnir" <genkush@rujel.net> writes:
> thank you for precise instructions.
>
> however I did not completely understand the part about references
> and reflog what are these? git tags?
git-filter-branch saves old version under refs/original/* namespace.
You have to remove them after making sure that your rewritten history
is correct.
Additionally git keeps log where branch (tip/head of branch) was in
your repository; this is kind of generalization of ORIG_HEAD, and
allows to recover from such mistakes as wrong "git reset --hard".
Reflog entries from your original history also would pin commits, so
you have to expire reflog.
And finally the commits you have are there in repository, so you have
to "prune" repository to get rid of them. Reflog entries and
refs/original/* pin those commits, so you have to remove them prior to
pruning. Pruning simply removes objects which are unreferenced.
> and another question:
> did I understand it right, that I can even make some changes to that
> file in history - not just simply delete one?
Yes, see man git-filter-branch.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Removing some files from history
From: Gennady Kushnir @ 2008-10-17 11:51 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <48F86E6A.7080102@fastmail.fm>
thank you for precise instructions.
however I did not completely understand the part about references and reflog
what are these? git tags?
and another question:
did I understand it right, that I can even make some changes to that
file in history - not just simply delete one?
Gennady
2008/10/17 Michael J Gruber <michaeljgruber+gmane@fastmail.fm>:
> Gennady Kushnir venit, vidit, dixit 17.10.2008 12:38:
>> Hello all
>> I'm not yet subscribed, but I wish I shall get reply anyway
>>
>> I'm going to make my repository public, but I have found that one of
>> my files contains some private data that I would not like to share.
>> Is it possible to remove that file from all commits in my local
>> repository history before publishing it?
>> Or it would be easier to start publishing with just my current state
>> (whith all private data cleaned up)?
>>
>> Thanks in advance.
>> Gennady
> Use
>
> git filter-branch --index-filter 'git rm --cached secret' -- --all
>
> or
>
> git filter-branch --tree-filter 'rm -f secret' -- --all
>
> where 'secret' is the name of the file to be removed.
>
> After that, make sure you clean up your repo before publishing:
> Clean out the original references (command on 1 line):
>
> git for-each-ref --format='%(refname)' refs/original |while read ref;
> do git update-ref -d $ref;done
>
> Clean out the reflog:
>
> git reflog --expire=0 expire
>
> Remove the old objects and packs:
>
> git prune
> git repack -adf
>
> [Makes me feel this should be easier.]
>
> Michael
>
^ permalink raw reply
* Re: [PATCH] fix guilt-pop and push to fail if no relevant patches
From: Scott Moser @ 2008-10-17 11:37 UTC (permalink / raw)
To: Josef 'Jeff' Sipek; +Cc: git
In-Reply-To: <1222714293-9680-1-git-send-email-smoser@brickies.net>
Jeff,
Did you not like the patch below for some reason ?
It seemed fairly straightforward to me that guilt-pop and guilt-push
should exit failure if they did not do anything due to having nothing to
do.
On Mon, 29 Sep 2008, Scott Moser wrote:
> currently guilt-pop and guilt-push will exit with '0' if there are no more
> relevant patches in the series (ie, if you've pushed or popped all of them)
>
> This means that you cannot do something like:
> while guilt-push; do
> guilt refresh || break
> done
>
> for reference, quilt does exit with non-zero in those cases:
> $ quilt push -a && quilt push
> File series fully applied, ends at patch my.patch
> $ echo $?
> 1
>
> $ quilt pop -a; quilt pop
> No patch removed
> $ echo $?
> 2
>
> Signed-off-by: Scott Moser <smoser@brickies.net>
> ---
> guilt-pop | 3 +--
> guilt-push | 43 ++++++++++++++++++++++++-------------------
> regression/t-021.out | 3 +++
> 3 files changed, 28 insertions(+), 21 deletions(-)
>
> diff --git a/guilt-pop b/guilt-pop
> index db8473e..8a83fdb 100755
> --- a/guilt-pop
> +++ b/guilt-pop
> @@ -45,8 +45,7 @@ patch="$1"
> [ ! -z "$all" ] && patch="-a"
>
> if [ ! -s "$applied" ]; then
> - disp "No patches applied."
> - exit 0
> + die "No patches applied."
> elif [ "$patch" = "-a" ]; then
> # we are supposed to pop all patches
>
> diff --git a/guilt-push b/guilt-push
> index 018f9ac..48f886b 100755
> --- a/guilt-push
> +++ b/guilt-push
> @@ -97,22 +97,27 @@ fi
> sidx=`wc -l < $applied`
> sidx=`expr $sidx + 1`
>
> -get_series | sed -n -e "${sidx},${eidx}p" | while read p
> -do
> - disp "Applying patch..$p"
> - if [ ! -f "$GUILT_DIR/$branch/$p" ]; then
> - die "Patch $p does not exist. Aborting."
> - fi
> -
> - push_patch "$p" $abort_flag
> -
> - # bail if necessary
> - if [ $? -eq 0 ]; then
> - disp "Patch applied."
> - elif [ -z "$abort_flag" ]; then
> - die "Patch applied with rejects. Fix it up, and refresh."
> - else
> - die "To force apply this patch, use 'guilt push -f'"
> - fi
> -done
> -
> +get_series | sed -n -e "${sidx},${eidx}p" |
> + {
> + did_patch=0
> + while read p
> + do
> + disp "Applying patch..$p"
> + if [ ! -f "$GUILT_DIR/$branch/$p" ]; then
> + die "Patch $p does not exist. Aborting."
> + fi
> +
> + push_patch "$p" $abort_flag
> +
> + # bail if necessary
> + if [ $? -eq 0 ]; then
> + disp "Patch applied."
> + elif [ -z "$abort_flag" ]; then
> + die "Patch applied with rejects. Fix it up, and refresh."
> + else
> + die "To force apply this patch, use 'guilt push -f'"
> + fi
> + did_patch=1
> + done
> + [ $did_patch -ge 1 ] || die "no patches to apply"
> + }
> diff --git a/regression/t-021.out b/regression/t-021.out
> index cd8ae96..44771cb 100644
> --- a/regression/t-021.out
> +++ b/regression/t-021.out
> @@ -822,6 +822,7 @@ index 0000000..8baef1b
> @@ -0,0 +1 @@
> +abc
> % guilt-push --all
> +no patches to apply
> % guilt-pop -n -1
> Invalid number of patches to pop.
> % list_files
> @@ -908,6 +909,7 @@ index 0000000..8baef1b
> @@ -0,0 +1 @@
> +abc
> % guilt-push --all
> +no patches to apply
> % guilt-pop -n 0
> No patches requested to be removed.
> % list_files
> @@ -994,6 +996,7 @@ index 0000000..8baef1b
> @@ -0,0 +1 @@
> +abc
> % guilt-push --all
> +no patches to apply
> % guilt-pop -n 1
> Now at remove.
> % list_files
> --
> 1.5.6.3
>
>
> !DSPAM:48e123ca138521410093335!
>
>
^ permalink raw reply
* Re: Removing some files from history
From: Michael J Gruber @ 2008-10-17 10:52 UTC (permalink / raw)
To: Gennady Kushnir; +Cc: git
In-Reply-To: <96ed5eac0810170338s292fe858s1c092428a44a7ad2@mail.gmail.com>
Gennady Kushnir venit, vidit, dixit 17.10.2008 12:38:
> Hello all
> I'm not yet subscribed, but I wish I shall get reply anyway
>
> I'm going to make my repository public, but I have found that one of
> my files contains some private data that I would not like to share.
> Is it possible to remove that file from all commits in my local
> repository history before publishing it?
> Or it would be easier to start publishing with just my current state
> (whith all private data cleaned up)?
>
> Thanks in advance.
> Gennady
Use
git filter-branch --index-filter 'git rm --cached secret' -- --all
or
git filter-branch --tree-filter 'rm -f secret' -- --all
where 'secret' is the name of the file to be removed.
After that, make sure you clean up your repo before publishing:
Clean out the original references (command on 1 line):
git for-each-ref --format='%(refname)' refs/original |while read ref;
do git update-ref -d $ref;done
Clean out the reflog:
git reflog --expire=0 expire
Remove the old objects and packs:
git prune
git repack -adf
[Makes me feel this should be easier.]
Michael
^ permalink raw reply
* Re: Removing some files from history
From: Jeff King @ 2008-10-17 10:42 UTC (permalink / raw)
To: Gennady Kushnir; +Cc: git
In-Reply-To: <96ed5eac0810170338s292fe858s1c092428a44a7ad2@mail.gmail.com>
On Fri, Oct 17, 2008 at 02:38:54PM +0400, Gennady Kushnir wrote:
> I'm going to make my repository public, but I have found that one of
> my files contains some private data that I would not like to share.
> Is it possible to remove that file from all commits in my local
> repository history before publishing it?
Yes, see "git help filter-branch". The first example given does exactly
what you are asking for.
-Peff
^ permalink raw reply
* Removing some files from history
From: Gennady Kushnir @ 2008-10-17 10:38 UTC (permalink / raw)
To: git
Hello all
I'm not yet subscribed, but I wish I shall get reply anyway
I'm going to make my repository public, but I have found that one of
my files contains some private data that I would not like to share.
Is it possible to remove that file from all commits in my local
repository history before publishing it?
Or it would be easier to start publishing with just my current state
(whith all private data cleaned up)?
Thanks in advance.
Gennady
^ permalink raw reply
* Re: git-commit does not signoff using name supplied by --author
From: bain @ 2008-10-17 10:31 UTC (permalink / raw)
To: git
In-Reply-To: <6a7ddf4e-8fcb-4a39-b4c5-1396cf702c8b@f40g2000pri.googlegroups.com>
> If i use git-commit --author "A U Thor <author.example.net>" -s it
> still uses my global author.name and author.email to add signoff
> message.
>
> Is this expected behavior?
Never mind...
Looking at the code i found out commiter name/email is used to
signoff, which is correct and can be different than author.
BAIN
^ permalink raw reply
* git-commit does not signoff using name supplied by --author
From: bain @ 2008-10-17 10:11 UTC (permalink / raw)
To: git
Hi all,
If i use git-commit --author "A U Thor <author.example.net>" -s it
still uses my global author.name and author.email to add signoff
message.
Is this expected behavior?
thanks
BAIN
^ permalink raw reply
* Re: What's in git.git (Oct 2008, #03; Tue, 14)
From: Jeff King @ 2008-10-17 9:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vej2i7rt9.fsf@gitster.siamese.dyndns.org>
On Tue, Oct 14, 2008 at 03:08:50PM -0700, Junio C Hamano wrote:
> * The 'master' branch has these since the last announcement
> in addition to the above.
>
> Jeff King (1):
> tests: shell negation portability fix
Can you cherry-pick this into maint? The problem it fixes was caused by
969c877, which is in maint (IOW, master is fixed, but maint is still
broken).
-Peff
^ permalink raw reply
* Re: commiting while the current version is in conflict
From: Junio C Hamano @ 2008-10-17 9:36 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Richard Hartmann, Shawn O. Pearce, Miklos Vajna, git
In-Reply-To: <m3d4hzk2du.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> From time to time somebody proposes to add a command which is used
> only to say that given conflict got resolved, i.e. yet another
> porcelain "around" git-update-index plumbing (in addition to git-add,
> git-mv and git-rm). One of problems is how to call it: git-resolve,
> git-resolved, git-mark-resolved?
>
> BTW. while I usually use "git commit -a", when comitting merge commit
> I usually use explicit "git add" together "git commit" (without '-a').
There are three things to keep in mind while thinking about this:
* "git add" _always_ is to mark "this path now is in a good shape and is
ready to be committed", whether you are doing a conflict resolution of
a merge or making a normal commit.
* you cannot partially commit a merge, as the resulting tree won't be a
proper merge (i.e. the change from either parents do not describe what
happened).
* during a conflicted merge, cleanly merged paths are already staged in
the index.
Which means that the only paths you would "git add" during a conflicted
merge are the paths you resolved (unless you are creating an evil merge),
and there is no point having a separate "git resolved" -- such a command
will be nothing but an alias to "git add" anyway.
We could add a training wheel mode to "git commit -a" (or "git add -u")
that warns about unmerged paths and asks confirmation, but I suspect that
it would really annoy people who used git for more than 2 weeks if we made
it the default, and on the other hand if it is not the default, it would
not help new people that much. It is nice to try to help new people from
shooting themselves in the foot, but we need to draw a line somewhere so
that we do not hurt people by being obnoxious. After all, even these new
people will graduate from the "new" status soon. My gut feeling is that
helping "oh, I staged the file that I wasn't ready to commit" is on the
other side of that line, especially since the example pre-commit hook
safety is easily available. If somebody wants to add a pre-add hook that
is run by "git add" Porcelain (but never by "update-index"), that would
add the safety net, too.
^ permalink raw reply
* Re: commiting while the current version is in conflict
From: Richard Hartmann @ 2008-10-17 9:35 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio Hamano, Shawn O. Pearce, Miklos Vajna, git
In-Reply-To: <m3d4hzk2du.fsf@localhost.localdomain>
On Fri, Oct 17, 2008 at 11:16, Jakub Narebski <jnareb@gmail.com> wrote:
> From time to time somebody proposes to add a command which is used
> only to say that given conflict got resolved, i.e. yet another
> porcelain "around" git-update-index plumbing (in addition to git-add,
> git-mv and git-rm). One of problems is how to call it: git-resolve,
> git-resolved, git-mark-resolved?
In that case, you would still need a pre-add hook.
The problem is not that people can't mark resolved without adding.
It's that they can't add without checking (automatically) if there
are no conflicts.
Richard
^ permalink raw reply
* Re: commiting while the current version is in conflict
From: Richard Hartmann @ 2008-10-17 9:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, Miklos Vajna, git
In-Reply-To: <7vwsg7mxb6.fsf@gitster.siamese.dyndns.org>
On Fri, Oct 17, 2008 at 10:37, Junio C Hamano <gitster@pobox.com> wrote:
> Eh, Sorry about that --- I did not mean "ignorant" in that sense. Perhaps
> replacing the word with "unfortunate" would sound nicer?
A lot yes. No harm done, apologies for picking the bad interpretation
of ignorant.
> Don't you realize that is what the hook is doing already? After making
> such an error, the definitive information is lost, because the user told
> the tool that the resolution is done and the file is ready to be
> committed) by mistake. Even then the hook is trying its best to help the
> user.
You misunderstood me, there. I was thinking about the pre-add hook
while writing the above. Doing anything at commit time is obviously
wrong.
> As to pre-add hook, I am not enthused, but if somebody sends in a clean
> patch, I wouldn't be opposed to it at least in principle.
An implicit need for it does apparently exist. Else, the default hook for
pre-commit would not need to check for conflicts.
Richard
^ permalink raw reply
* Re: Git hooks are not called over HTTP
From: Jakub Narebski @ 2008-10-17 9:22 UTC (permalink / raw)
To: KwangYul Seo; +Cc: git
In-Reply-To: <7beb12420810162323o6dce0a71r897fbed9b9d3e417@mail.gmail.com>
"KwangYul Seo" <kwangyul.seo@gmail.com> writes:
> I have setup a git repository with post-receive and post-update
> enabled. I configured hooks.envelopesender and hooks.mailinglist. I
> confirmed that it works fine with push from local repositories.
> However, hooks are never called when push is done over HTTP. I added
> 'echo abc' to post-receive to see if it is called or not. With local
> push, abc was printed, but with HTTP push it was not printed. What is
> the problem here?
The "problem" here (which is very much the way HTTP protocol was
designed) is that it isn't _git_ that updates repository on remote
side on push (which knows about hooks), but _web server_ via WebDAV.
And web server knows nothing about hooks.
Perhaps that would get improved when "smart" HTTP protocol gets
implemented (currently in the phase of design, I think just after
designing protocol).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: commiting while the current version is in conflict
From: Jakub Narebski @ 2008-10-17 9:16 UTC (permalink / raw)
To: Richard Hartmann; +Cc: Junio Hamano, Shawn O. Pearce, Miklos Vajna, git
In-Reply-To: <2d460de70810170021q5daa902er1e6e2fb6633400ec@mail.gmail.com>
"Richard Hartmann" <richih.mailinglist@gmail.com> writes:
> On Fri, Oct 17, 2008 at 01:39, Junio Hamano <junio@twinsun.com> wrote:
> > (2) pre-commit hook is a last ditch effort to help ignorant
> > users who have already done "git add" without thinking and
> > lost the "unmerged" state. It has to look at and guess at
> > the contents for that.
>
> Ignoring the ad hominem attack, I would argue that the two
> distinct mental concepts of 'I want to commit this in the next
> commit' and 'I have resolved this conflict' should have two
> distinct commands.
>
> To err is human, which is why rm -i exists. Else, you could
> just use alias rm='rm -rf'.
>From time to time somebody proposes to add a command which is used
only to say that given conflict got resolved, i.e. yet another
porcelain "around" git-update-index plumbing (in addition to git-add,
git-mv and git-rm). One of problems is how to call it: git-resolve,
git-resolved, git-mark-resolved?
BTW. while I usually use "git commit -a", when comitting merge commit
I usually use explicit "git add" together "git commit" (without '-a').
--
Jakub Narebski
Poland
ShadeHawk on #git
^ 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