* Re: Git push over git protocol for corporate environment
From: Ismael Luceno @ 2009-10-02 18:54 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git
In-Reply-To: <76c5b8580910020741p2024f6c0w70be53338924e7e8@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1077 bytes --]
Eugene Sajine escribió:
> I think that this is what is missing right now in order for git to get
> rocket start and spread inside companies: secure and easy to maintain
> mainline hosting.
>
It looks like your problem is using cygwin. It's more complicated on a
MS-Windows environment, and personally I think it's a _very bad idea_.
Git is really easy to use in fact, you just set up the repo with:
mkdir repo.git
cd repo.git
git init --bare --shared=all
--shared=all makes the repo readable to anyone, and ensures push rights
to users under the same group as the user setting up the repo. You can
change the group with chmod of course.
SSH access will be needed to push, unless the users can remotely mount
the repo via NFS or any other protocol.
Pulling is possible over http too, you just need to make
hooks/post-update executable. To export via git protocol you must create
an empty file named "git-daemon-export-ok".
Besides setting a web repo browser and git-server there's nothing else
specific to git.
--
Ismael Luceno
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Figuring out which patches have been applied
From: Julian Phillips @ 2009-10-02 18:45 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910910020736n539f4331nfd61175b275c7d28@mail.gmail.com>
On Fri, 2 Oct 2009, Jon Smirl wrote:
> I have a stack of 100 patches against 2.6.30. A lot of these got
> merged between 2.6.30-32. How can I tell which ones have been
> applied?
>
> It doesn't work to check if patch A has been applied to 2.6.32. Other
> patches may have been applied on top of patch A obscuring it.
>
> Once solution would be to rebase the patch stack forward one commit at
> a time. That solves the problem of later patches obscuring patch A. Is
> there a better way to do this?
Have you tried using git-cherry? I belive that it was intended for this
purpose?
--
Julian
---
Progress might have been all right once, but it's gone on too long.
-- Ogden Nash
^ permalink raw reply
* Re: git as a versioned filesystem
From: Avery Pennarun @ 2009-10-02 18:11 UTC (permalink / raw)
To: Scott Wiersdorf, git
In-Reply-To: <20091002164929.GA12725@perlcode.org>
On Fri, Oct 2, 2009 at 12:49 PM, Scott Wiersdorf <scott@perlcode.org> wrote:
> Git seems like the perfect tool for this, but I'm still not sure how
> to adapt it to our situation. I'm building a tool that uses git to let
> the developers commit their binary changes to this master image into
> the git repository, which hopefully will allow me to offer the QA team
> some ability to cherry-pick updates or revert regressions and make a
> clean dist image from week to week.
Beware that git performs rather badly on binary files, especially huge
ones, which it tries to load entirely into RAM. It also keeps every
revision of every file that was ever committed (and every user who
checks it out needs to download the whole thing), so your giant binary
repository is going to get very big, very fast.
I've looked into using git for this kind of situation myself. It's
close, but not quite there (for my purposes anyway). It basically
just needs some optimizations and some improved support for "shallow
clones."
But on to your actual question:
> But now it's a few weeks later and we're ready to do another
> dist. What I *want* to do is create a *copy* of branch B1 to give the
> release manager a reference point for him to bring things up to
> date. What is the best way to do that?
>
> If I branch off of B1, now I have the burden of doing a whole lot of
> cherry-picks and having a challenging time getting things back in sync:
>
> -----a----b--T1-------c--------d-e---f------g [master]
> \ (a) \ \ \
> ----|----c'--- \ \ [B1]
> \ \ \
> -----e'--f'---[B2]
>
> Ugh. Now B2 is kind of a mess. If I rebase it on master, I'll get (d)
> and maybe (a) again, which I don't want. [side question: unless
> there's a way to rebase on master but still exclude
> commits... possible?]. B3 and B4 are going to look even worse and the
> risk of drifting so far away from the master is unappealing.
If you rebase your "release" changes onto current master, you'll get
the revert-a patch applied, so (a) will still be gone. Rebase will
also probably be smart enough to throw away c', since it's identical
to (c). You will indeed end up with the unwanted (d), but you can
just revert that in B2.
> Ideally I'd want each week's release to come directly from the master,
> kind of the flying-fish approach:
>
> ----e'--f'--- [B2]
> / / /
> -----a----b--T1-------c--------d-e---f------g [master]
> \ (a) \
> ----|----c'--- [B1]
>
> The problem with this is that now B2 contains (a), so I'll have to
> revert that again--which I can do happily--but I just wonder if
> there's a better way. If it's possible to simply *copy* branch B1 to
> B2 without making B2 a branch off of B1.
"revert-a" is a patch on its own. Git doesn't think of reverting (a)
as anything special; it's just a change that happens to reverse what
(a) does. So if you rebase B1 onto master, it will get copied. It
sounds rebase will produce exactly the results you're looking for
here.
Now, that said, this release process seems extremely suspicious to me.
To summarize what I'm hearing: you have a 'master' branch that people
put stuff into, but which doesn't actually work correctly. At the
last minute before a release, you make a new branch, drop out the
stuff that doesn't work, and put it into production.
This sounds problematic. If (a) and (d) don't work, why are they in
master at all? Git makes branching really easy: get people to put
their not-quite-working features into a different branch, and let the
release manager merge those branches into master when they're actually
ready.
If you do that, you'll always be releasing straight out of master, and
your life will be a lot simpler. And if you "merge --squash" from the
feature branches into master, you can throw away the interim versions
of the feature branches, which should help keep your repository from
growing so quickly with tons of binary file revisions that never even
got released.
> ## is there way besides rebase to clean out a revert as if it never
> ## happened? I suppose I could branch again and repeat this as
> ## needed.
You probably want "git revert -i".
Have fun,
Avery
^ permalink raw reply
* HTTP NTLM Authentication
From: gsky @ 2009-10-02 17:28 UTC (permalink / raw)
To: git
Is is possible for me to pass arguments to the curl calls that git uses to
access a repository hosted over HTTP?
I am having a problem accessing the repository as it is authenticated using
NTLM, I can curl the repository using
curl --ntlm http://username:pass@machine.domain/git
How can I do the same for the git clone of the repository? Is it possible
easily, or do I have to modify the source and recompile?
gsky
--
View this message in context: http://www.nabble.com/HTTP-NTLM-Authentication-tp25718488p25718488.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: git only one file
From: gsky @ 2009-10-02 17:24 UTC (permalink / raw)
To: git
In-Reply-To: <25140456.post@talk.nabble.com>
synhedionn wrote:
>
> with git add . , a directory is expected, but I don't need all my files
> to be recorded, only one of my thousands, so how can I record just 1 file?
>
git add /path/to/file
--
View this message in context: http://www.nabble.com/git-only-one-file-tp25140456p25718014.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* git as a versioned filesystem
From: Scott Wiersdorf @ 2009-10-02 16:49 UTC (permalink / raw)
To: git
Hi all,
First off, I'm *not* using git as a typical VCS on the front-end; I'm
using it for dist control on the back-end. I'm also fairly new to git
(about a week and a half into it).
The Scene
=========
For source control, we're using CVS (migrating off of it, btw--I only
have limited influence around here). We build our software, etc,
etc. and then we have the developers scp/rsync/untar their builds on a
*master disk image*.
This master disk image is disted via rsync to a few thousand servers
to keep them all up to date and in sync, etc. This works mostly fine
and I can't really change this system.
The Problem
===========
Our problem has been that occasionally bad stuff gets put in the
master image and we have no easy way to revert it or to allow the QA
team to cherry-pick/revert changes to that master image.
The Solution
============
Git seems like the perfect tool for this, but I'm still not sure how
to adapt it to our situation. I'm building a tool that uses git to let
the developers commit their binary changes to this master image into
the git repository, which hopefully will allow me to offer the QA team
some ability to cherry-pick updates or revert regressions and make a
clean dist image from week to week.
The Question
============
What I need to know from y'all is: is there a better way, a more
git-like way, to accomplish this. Here's the model I *want* to follow:
-----a----b--T1-------c--------d-e---f------g [master]
\ (a) \
----|----c'--- [B1]
Here is branch B1 created from the master at some point in time T1. On
branch B1, I revert commit (a) and cherry-pick commit (c):
git checkout master
git branch B1
git checkout B1
git revert a
git cherry-pick c
At this point, B1 is our "perfect image" and we're ready to dist it. I
check it out elsewhere and rsync it, etc. Wonderful.
But now it's a few weeks later and we're ready to do another
dist. What I *want* to do is create a *copy* of branch B1 to give the
release manager a reference point for him to bring things up to
date. What is the best way to do that?
If I branch off of B1, now I have the burden of doing a whole lot of
cherry-picks and having a challenging time getting things back in sync:
-----a----b--T1-------c--------d-e---f------g [master]
\ (a) \ \ \
----|----c'--- \ \ [B1]
\ \ \
-----e'--f'---[B2]
Ugh. Now B2 is kind of a mess. If I rebase it on master, I'll get (d)
and maybe (a) again, which I don't want. [side question: unless
there's a way to rebase on master but still exclude
commits... possible?]. B3 and B4 are going to look even worse and the
risk of drifting so far away from the master is unappealing.
Ideally I'd want each week's release to come directly from the master,
kind of the flying-fish approach:
----e'--f'--- [B2]
/ / /
-----a----b--T1-------c--------d-e---f------g [master]
\ (a) \
----|----c'--- [B1]
The problem with this is that now B2 contains (a), so I'll have to
revert that again--which I can do happily--but I just wonder if
there's a better way. If it's possible to simply *copy* branch B1 to
B2 without making B2 a branch off of B1.
In the absence of a git-branch-copy, is there something that would
help me do set intersection and subtraction between branches?
Something like this:
git log B1
... bunch of commit ids ...
git log B2
... bunch of commit ids ...
## find the intersection(B1, B2)
## revert all the things missing in B1 from B2
## now B2 is the same as B1--assuming git is idempotent (is it?)
## is there way besides rebase to clean out a revert as if it never
## happened? I suppose I could branch again and repeat this as
## needed.
Am I even thinking about this correctly?
Keep in mind that these commits are not source code commits; they're
file system changes of all kinds: updated binaries and libraries, new
directory trees, removed directory trees, etc. It's much closer to a
package manager in spirit than a VCS.
I feel like I'm missing something grand in git-rev-list or git-log or
git-bisect some other tool that will make all my troubles
disappear. I've read an awful lot of the man pages, but am still very
new to git and I'm certain I've missed some subtleties.
Any ideas? I'm not even sure I'm asking the right questions. I'll
accept any advice on this subject.
Scott
--
Scott Wiersdorf
<scott@perlcode.org>
^ permalink raw reply
* Re: Re: Git push over git protocol for corporate environment
From: Eugene Sajine @ 2009-10-02 15:58 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Eugene Sajine
In-Reply-To: <20091002144727.GZ14660@spearce.org>
Thanks Shawn!
I saw info about Scumd and Gerrit in previous emails, but
unfortunately haven't enough time to spend with those tools yet.
Reading about Gerrit right now.
On Fri, Oct 2, 2009 at 10:47 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
> Eugene Sajine <euguess@gmail.com> wrote:
>> Gitorious is even better!! for corporate use, i think, because of its
>> team oriented approach, but... man... I would kill for java
>> implementation or anything as simple as that!!
>
> If you want a Java based server, look at either:
>
> * SCuMD http://github.com/gaffo/scumd
> * Gerrit Code Review http://code.google.com/p/gerrit/
>
> I think SCuMD might be easier to install, I don't think it depends
> upon a database or a servlet container like Gerrit does. But both
> are a SSH+Git implementation with some access control capabilities,
> and are implemented in Java.
>
> I don't think either is (yet) as easy to install as Hudson CI.
> Both projects have a much smaller team of developers behind them,
> and are still focusing on basic functionality rather than ease of
> new system setup.
>
> --
> Shawn.
>
^ permalink raw reply
* Re: Trying to split repository
From: Josef Wolf @ 2009-10-02 15:42 UTC (permalink / raw)
To: git
In-Reply-To: <c376da900910011747i894404dne1ea60dae5e3990b@mail.gmail.com>
On Thu, Oct 01, 2009 at 08:47:15PM -0400, Adam Brewster wrote:
> >>
> >> git-filter-branch accepts a --prune-empty option that does what I
> >> think you're looking for.
> > Thanks for your answer, Adam!
> > Is this a new option? 1.6.0.2 don't seem to have it?
> 1.6.0.2 was released September 2008 (git log -n1 v1.6.0.2).
>
> This feature was added in October 2008. (git blame
> Documentation/git-filter-branch.txt; git log -n1 d3240d93).
>
> It's still it is missing from the option summary in master though.
Thanks for clarifying that, Adam!
^ permalink raw reply
* Re: [PATCH] Introduce <branch>@{tracked} as shortcut to the tracked branch
From: Björn Steinbrink @ 2009-10-02 14:54 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, Johan Herland, git, Michael J Gruber,
Johannes Schindelin, Pete Wyckoff, i.am
In-Reply-To: <7vzl92bql9.fsf@alter.siamese.dyndns.org>
On 2009.09.10 11:29:54 -0700, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > On Thu, Sep 10, 2009 at 12:18:06PM +0200, Johan Herland wrote:
> >
> >> > > A special shortcut '@{tracked}' refers to the branch tracked by the
> >> > > current branch.
> >> >
> >> > Sorry, I didn't know the name of the long form was up for discussion.
> >> > But it should certainly coincide with the key which for-each-ref
> >> > uses, shouldn't it? I don't care whether tracked or upstream, but
> >> > for-each-ref's "upstream" has set the precedent.
> >>
> >> ...and 'git branch --track' set an even earlier precedent...
> >
> > FWIW, that came about from this discussion:
> >
> > http://article.gmane.org/gmane.comp.version-control.git/115765
>
> After re-reading the discussion in the thread that contains the quoted
> article, it sounds like we may want to fix "branch --track X Y". X does
> not "track" Y in the same sense as origin/master "tracks" master at
> origin. Rather, X builds on Y.
FWIW, I just had a discussion on #git with Jim Ramsay (lack) about that.
We agreed that "branch --track" is unfortunate and causes confusion,
when it comes to the term "tracking branch" (which the glossary
basically defines to be something in the refs/remotes/ namespace, at
least something you never commit to), as people also start to use that
for branch heads that have an "upstream branch" set in the
configuration.
Jim initially preferred the term "linked", while I argued for the option
to be called --upstream (potentially with the possibility to say
--upstream=rebase or --upstream=merge, the default being "merge", unless
branch.autosetuprebase is set).
We could (I think) to some degree agree that "upstream" is quite good,
although we couldn't find a short and sweet term to describe the branch
head that has a configured upstream branch (some ideas were "upstreamed
branch", "uplinked branch", "downstream branch" and some more, which I
all dislike). After having read the glossary and finding "upstream
branch" in there, I'm even more in favor of using the "upstream" term in
some form.
During the discussion, there were some requests (again) for a command
that allows to change branch.<name>.remote and branch.<name>.merge for
already existing branch heads. With that extra input, I'd now favor:
git branch --set-upstream X Y
because that's potentially reusable for the "change upstream for an
existing branch" case, though I'm totally clueless how to actually do
that, given that "git branch" uses flags to switch between "create new
branch" and "operate on existing branch". So reusing a flag won't
(easily) do the trick, at least not without special casing that could be
dangerous. You could, for example, accidently change the upstream for an
existing branch, while you meant to create a new one.
It's a bit sad that we don't have subcommands for "git branch" like we
do for "git remote", that would make the whole thing a lot easier, but
it's way too late to change that, I guess. At least having "git branch
<name>" default to be "git branch add <name>" would make some branch
names "invalid" for that shortform. So that looks like a no-go.
Björn
^ permalink raw reply
* Re: Re: Git push over git protocol for corporate environment
From: Shawn O. Pearce @ 2009-10-02 14:47 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git
In-Reply-To: <76c5b8580910020741p2024f6c0w70be53338924e7e8@mail.gmail.com>
Eugene Sajine <euguess@gmail.com> wrote:
> Gitorious is even better!! for corporate use, i think, because of its
> team oriented approach, but... man... I would kill for java
> implementation or anything as simple as that!!
If you want a Java based server, look at either:
* SCuMD http://github.com/gaffo/scumd
* Gerrit Code Review http://code.google.com/p/gerrit/
I think SCuMD might be easier to install, I don't think it depends
upon a database or a servlet container like Gerrit does. But both
are a SSH+Git implementation with some access control capabilities,
and are implemented in Java.
I don't think either is (yet) as easy to install as Hudson CI.
Both projects have a much smaller team of developers behind them,
and are still focusing on basic functionality rather than ease of
new system setup.
--
Shawn.
^ permalink raw reply
* Re: Re: Git push over git protocol for corporate environment
From: Eugene Sajine @ 2009-10-02 14:41 UTC (permalink / raw)
To: Eugene Sajine, git
In-Reply-To: <00163623ac5d75929b0474e66b96@google.com>
I'm sorry if it will be a dup again... My first email got stuck or
deleted by server, although i didn't use any html...
Thanks to everybody for prompt answers!
There is one thing I’m still missing though. Do I understand correctly
that if a person has an ssh access (account) to the host in internal
network, then this won’t be enough for him to be able to push to the
repo? Should we still go through the hassle of managing the ssh keys
for each particular user who is supposed to have push access?
I believe the answer is yes and that's why I'm leaning towards pulls
and pushes over git protocol. There is no solution yet which would be
as effective and simple to maintain. Using git protocol will not add
security, but it won't be worse than existing CVS or any other
centralized version control security model. As soon as security comes
into play, then we will need some other solution, but currently i
didn't see anything that would be easy to sell to the company.
Github is cool, but FI is way too expensive and very hard to sell.
Gitorious is even better!! for corporate use, i think, because of its
team oriented approach, but... man... I would kill for java
implementation or anything as simple as that!! As i see It is
impossible to install in network without internet access, and the
amount of dependencies which you have install/pre-install is enormous.
I read somewhere ruby on rails is fun to develop with, but is a
nightmare to deploy and maintain, and it seems to be true. Come on,
guys!! Look at the Hudson CI - one war file containing everything you
need, application starts from command line "java -jar hudson.war" and
runs on any port you specify. Time to start from download to having
first build is less the 10 min!!! If there are gitorious guys -
please, think about it and don't forget to share the profit;)!
I think Cgit can be something competitive - although i failed to run
it yet, having some issues with build...and as all other web based
stuff, you should implement something in order to create and set up
bare repos on the server automatically (even probably edit the config
file via script) to avoid a mess and to avoid one guy spending his
time adding and configuring repos... Probably we will and up using
gitweb as it at least knows to scan a folder for git repos...although
it also gives me troubles installing... both with cgit and gitweb are
conducted under cygwin, so probably this is the real problem with
them;)
I think that this is what is missing right now in order for git to get
rocket start and spread inside companies: secure and easy to maintain
mainline hosting.
Probably my lack of experience with git causes these thoughts - so,
while i will continue to work on it, i would really appreciate any
advice, especially about experience using git not for open source and
not in 3 person's team.
Thanks a lot,
Eugene
^ permalink raw reply
* Figuring out which patches have been applied
From: Jon Smirl @ 2009-10-02 14:36 UTC (permalink / raw)
To: Git Mailing List
I have a stack of 100 patches against 2.6.30. A lot of these got
merged between 2.6.30-32. How can I tell which ones have been
applied?
It doesn't work to check if patch A has been applied to 2.6.32. Other
patches may have been applied on top of patch A obscuring it.
Once solution would be to rebase the patch stack forward one commit at
a time. That solves the problem of later patches obscuring patch A. Is
there a better way to do this?
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] filter-branch: add --prune-empty to option summary
From: Adam Brewster @ 2009-10-02 14:18 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20091002074537.GA27664@coredump.intra.peff.net>
>
> Thanks. This makes sense given the existing structure, though I have to
> wonder how useful some of these gigantic synopses really are.
I find them useful mostly when dealing with commands that I generally
know, but don't remember the exact spelling or ordering of the
options. I might forget, for example, if it's --msg-filter or
--message-filter.
Adam
^ permalink raw reply
* Re: How to delete large files
From: Johannes Sixt @ 2009-10-02 13:41 UTC (permalink / raw)
To: Mikael Magnusson; +Cc: Nils Homer, git
In-Reply-To: <237967ef0910020526w51c05570g606ebc16e0b4a3e7@mail.gmail.com>
Mikael Magnusson schrieb:
> Well, you just gave "HEAD" to git filter-branch to rewrite, i think
> you want --all to rewrite all refs you have.
... and '--tag-filter cat' to rewrite tags as well.
-- Hannes
^ permalink raw reply
* Re: How to delete large files
From: Mikael Magnusson @ 2009-10-02 12:26 UTC (permalink / raw)
To: Nils Homer; +Cc: git
In-Reply-To: <C6EB1E10.D7AB%nilshomer@gmail.com>
2009/10/2 Nils Homer <nilshomer@gmail.com>:
> I wish to delete some large offending files (10MB to >100MB each) from my
> git repository (git://bfast.git.sourceforge.net/gitroot/bfast/bfast). The
> current size of the repo is 656MB.
>
> I created a backup of my repository and then searched for such offending
> files using a script found here:
> http://stubbisms.wordpress.com/2009/07/10/git-script-to-show-largest-pack-ob
> jects-and-trim-your-waist-line/
> where I modified the script to output in MB instead of KB.
>
> This gave me a list of files that I wanted to delete:
> -e size pack SHA
> location
> 113 113 f9f2faab597d4f8ccbfac2864347dbc256353fbf
> tests.long/save/save.tar.gz
> 113 113 926b1ba880a26354c4a6b9391985f57fbc9a1174
> tests.long/save/save.tar.gz
> 113 113 e568480bcb8239e6d1ed8d2da86c309c0d3d101b
> tests.long/save/save.tar.gz
> 113 113 e3c0ee53f20e8ebfb60eaefcd7b405168c26a565
> tests.long/save/save.tar.gz
> 103 103 ee2ee50c5075d05d29764c8d4b9acc2acedda919
> tests.long/save/save.tar.gz
> 35 35 319c75945c27096093dbab5a0bf6a9a08089bc2d
> tests.long/data/data.tar.gz
> 11 11 805193c74ceeffca9da3a2788545e701d77e1caf tests/save/save.tar.gz
> 11 11 658e4a78c1028875ab597d6bde5823cd6a1694b9 tests/save/save.tar.gz
>
> So I decided to remove these files using:
> git filter-branch --index-filter "git rm -rf --cached --ignore-unmatch
> tests.long/save/save.tar.gz tests.long/data/data.tar.gz
> tests/save/save.tar.gz" HEAD
>
> I then ran:
> rm -rf .git/refs/original
> git reflog expire --expire=now 卟ll
> git gc --prune=now
>
> Still (using du 虐) the repository is 656MB and I can see the above files in
> the revision list:
> git rev-list --all --objects | grep tests.long/save/save.tar.gz
> ee2ee50c5075d05d29764c8d4b9acc2acedda919 tests.long/save/save.tar.gz
> e568480bcb8239e6d1ed8d2da86c309c0d3d101b tests.long/save/save.tar.gz
> f9f2faab597d4f8ccbfac2864347dbc256353fbf tests.long/save/save.tar.gz
> 926b1ba880a26354c4a6b9391985f57fbc9a1174 tests.long/save/save.tar.gz
> e3c0ee53f20e8ebfb60eaefcd7b405168c26a565 tests.long/save/save.tar.gz
>
> Could this be because of tags that I had previously created?
>
> I am running git version 1.6.3.3. I appreciate any help in advance,
Well, you just gave "HEAD" to git filter-branch to rewrite, i think
you want --all to rewrite all refs you have.
--
Mikael Magnusson
^ permalink raw reply
* Re: How to delete large files
From: Matthieu Moy @ 2009-10-02 11:41 UTC (permalink / raw)
To: Nils Homer; +Cc: git
In-Reply-To: <C6EB1E10.D7AB%nilshomer@gmail.com>
Nils Homer <nilshomer@gmail.com> writes:
> Still (using du h) the repository is 656MB and I can see the above files in
> the revision list:
> git rev-list --all --objects | grep tests.long/save/save.tar.gz
> ee2ee50c5075d05d29764c8d4b9acc2acedda919 tests.long/save/save.tar.gz
> e568480bcb8239e6d1ed8d2da86c309c0d3d101b tests.long/save/save.tar.gz
> f9f2faab597d4f8ccbfac2864347dbc256353fbf tests.long/save/save.tar.gz
> 926b1ba880a26354c4a6b9391985f57fbc9a1174 tests.long/save/save.tar.gz
> e3c0ee53f20e8ebfb60eaefcd7b405168c26a565 tests.long/save/save.tar.gz
>
> Could this be because of tags that I had previously created?
I guess so. Anything pointing to the old history will prevent Git from
deleting it.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* How to delete large files
From: Nils Homer @ 2009-10-02 10:03 UTC (permalink / raw)
To: git
I wish to delete some large offending files (10MB to >100MB each) from my
git repository (git://bfast.git.sourceforge.net/gitroot/bfast/bfast). The
current size of the repo is 656MB.
I created a backup of my repository and then searched for such offending
files using a script found here:
http://stubbisms.wordpress.com/2009/07/10/git-script-to-show-largest-pack-ob
jects-and-trim-your-waist-line/
where I modified the script to output in MB instead of KB.
This gave me a list of files that I wanted to delete:
-e size pack SHA
location
113 113 f9f2faab597d4f8ccbfac2864347dbc256353fbf
tests.long/save/save.tar.gz
113 113 926b1ba880a26354c4a6b9391985f57fbc9a1174
tests.long/save/save.tar.gz
113 113 e568480bcb8239e6d1ed8d2da86c309c0d3d101b
tests.long/save/save.tar.gz
113 113 e3c0ee53f20e8ebfb60eaefcd7b405168c26a565
tests.long/save/save.tar.gz
103 103 ee2ee50c5075d05d29764c8d4b9acc2acedda919
tests.long/save/save.tar.gz
35 35 319c75945c27096093dbab5a0bf6a9a08089bc2d
tests.long/data/data.tar.gz
11 11 805193c74ceeffca9da3a2788545e701d77e1caf tests/save/save.tar.gz
11 11 658e4a78c1028875ab597d6bde5823cd6a1694b9 tests/save/save.tar.gz
So I decided to remove these files using:
git filter-branch --index-filter "git rm -rf --cached --ignore-unmatch
tests.long/save/save.tar.gz tests.long/data/data.tar.gz
tests/save/save.tar.gz" HEAD
I then ran:
rm -rf .git/refs/original
git reflog expire --expire=now ‹all
git gc --prune=now
Still (using du h) the repository is 656MB and I can see the above files in
the revision list:
git rev-list --all --objects | grep tests.long/save/save.tar.gz
ee2ee50c5075d05d29764c8d4b9acc2acedda919 tests.long/save/save.tar.gz
e568480bcb8239e6d1ed8d2da86c309c0d3d101b tests.long/save/save.tar.gz
f9f2faab597d4f8ccbfac2864347dbc256353fbf tests.long/save/save.tar.gz
926b1ba880a26354c4a6b9391985f57fbc9a1174 tests.long/save/save.tar.gz
e3c0ee53f20e8ebfb60eaefcd7b405168c26a565 tests.long/save/save.tar.gz
Could this be because of tags that I had previously created?
I am running git version 1.6.3.3. I appreciate any help in advance,
Nils Homer
^ permalink raw reply
* Re: [PATCH 1/2] do not mangle short options which take arguments
From: Johannes Schindelin @ 2009-10-02 9:04 UTC (permalink / raw)
To: Jeff King; +Cc: Clemens Buchacher, Shawn O. Pearce, git
In-Reply-To: <20091002084359.GA8878@coredump.intra.peff.net>
Hi,
On Fri, 2 Oct 2009, Jeff King wrote:
> On Fri, Oct 02, 2009 at 10:42:36AM +0200, Johannes Schindelin wrote:
>
> > > Yes, we deliberately allow users to shoot themselves in the foot. But
> > > they should have to use at least a long option to do it.
> >
> > Something like this?
> > [...]
> > + } else if (!strcmp(cmd, "--shoot-me-in-the-foot")) {
> > + warning ("Bang, bang!");
>
> Doh! Now I have to come up with a new joke patch for the GitTogether!
Don't make me envious :-(
Ciao,
Dscho
^ permalink raw reply
* Re: MSVC build broken (on cygwin)
From: Marius Storm-Olsen @ 2009-10-02 8:49 UTC (permalink / raw)
To: Alex Riesen; +Cc: Ramsay Jones, GIT Mailing-list, Shawn O. Pearce
In-Reply-To: <81b0412b0910020123j13c74497w874e301c38cddec9@mail.gmail.com>
Alex Riesen said the following on 02.10.2009 10:23:
> MSVC (all versions) define a compiler specific _MSC_VER, if that's of any use.
In this case it was define guards to let both MSVC and MinGW through
:) Both use _WIN32 and WIN32, which Cygwin gcc normally doesn't,
unless, as Ramsay said, you specify -mno-cygwin, or include windows.h
apparently.
Maybe we should allow Cygwin to also include the LEAN_AND_MEAN
windows.h in git-compat-util.h, and rather fix up the guards to
cleanly differ between Cygwin and non-Cygwin on Windows?
Apparently, nothing is broken in neither Cygwin, MinGW or MSVC after
Ramsays whitespace fix, but I'm sure it might get hairy later, if/when
we get more Windows contributions. Keeping the guards right could get
tricky.
So, something like this maybe, in git-compat-util.h:
#if defined(__MINGW32__) || defined(_MSC_VER)
# defined API_WIN32
# defined OS_WINDOWS
#elif defined(__CYGWIN__)
# defined API_POSIX
# defined OS_WINDOWS
#else
# defined API_POSIX
#endif
So, then we can use #ifdef API_WIN32 when using the Win32 API is the
only option/preferred for MinGW or MSVC; and use #ifdef OS_WINDOWS
when there are things that affect all the Windows builds.
Opinions?
--
.marius
^ permalink raw reply
* Re: [PATCH 1/2] do not mangle short options which take arguments
From: Jeff King @ 2009-10-02 8:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Clemens Buchacher, Shawn O. Pearce, git
In-Reply-To: <alpine.DEB.1.00.0910021042110.18640@intel-tinevez-2-302>
On Fri, Oct 02, 2009 at 10:42:36AM +0200, Johannes Schindelin wrote:
> > Yes, we deliberately allow users to shoot themselves in the foot. But
> > they should have to use at least a long option to do it.
>
> Something like this?
> [...]
> + } else if (!strcmp(cmd, "--shoot-me-in-the-foot")) {
> + warning ("Bang, bang!");
Doh! Now I have to come up with a new joke patch for the GitTogether!
-Peff
^ permalink raw reply
* Re: [PATCH 1/2] do not mangle short options which take arguments
From: Johannes Schindelin @ 2009-10-02 8:42 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: Jeff King, Shawn O. Pearce, git
In-Reply-To: <20091002073628.GA9444@localhost>
Hi,
On Fri, 2 Oct 2009, Clemens Buchacher wrote:
> On Fri, Oct 02, 2009 at 02:11:59AM -0400, Jeff King wrote:
>
> > So I don't feel _too_ strongly. I am just concerned that we are
> > introducing some DWYM magic that is not really going to help many
> > people out, and is just going to make understanding the rules for
> > option parsing more complex, and introduce the possibility (albeit
> > slim) of breaking people's scripts and trained fingers.
>
> But it makes the rules simpler, because it removes ambiguities such as
> the one above.
>
> Yes, we deliberately allow users to shoot themselves in the foot. But
> they should have to use at least a long option to do it.
Something like this?
-- snipsnap --
[PATCH] Deliberately allow users to shoot themselves in the foot
But they should have to use at least a long option to do it.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
git.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/git.c b/git.c
index 9883009..e7cb946 100644
--- a/git.c
+++ b/git.c
@@ -122,6 +122,8 @@ static int handle_options(const char ***argv, int *argc, int *envchanged)
setenv(GIT_DIR_ENVIRONMENT, getcwd(git_dir, sizeof(git_dir)), 0);
if (envchanged)
*envchanged = 1;
+ } else if (!strcmp(cmd, "--shoot-me-in-the-foot")) {
+ warning ("Bang, bang!");
} else {
fprintf(stderr, "Unknown option: %s\n", cmd);
usage(git_usage_string);
--
1.6.4.297.gcb4cc
^ permalink raw reply related
* Re: [PATCH 2/2] allow mangling short options which take integer arguments
From: Johannes Schindelin @ 2009-10-02 8:41 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: Jeff King, Shawn O. Pearce, git
In-Reply-To: <20091002082633.GA21168@localhost>
Hi,
On Fri, 2 Oct 2009, Clemens Buchacher wrote:
> On Fri, Oct 02, 2009 at 03:50:12AM -0400, Jeff King wrote:
> > On Fri, Oct 02, 2009 at 09:43:17AM +0200, Clemens Buchacher wrote:
> >
> > > On Thu, Oct 01, 2009 at 11:55:03PM +0200, Johannes Schindelin wrote:
> > >
> > > > And this patch looks even more straight-forward than 1/2, _but_... what
> > > > about cases where there are short options that are digits?
> > >
> > > Could you point me to one of those? I did not find any during my
> > > non-exhaustive search. We should be able to handle them easily by adding
> > > PARSE_OPT_MANY.
> >
> > The one that comes readily to mind is "git log -1", but that is actually
> > parsed by the revision options parser, which doesn't use parseopt. But
> > there are a few done by parseopt:
>
> Oh, I mistakenly thought Dscho was asking about options with
> single-digit arguments. Thanks for clearing this up.
I was actually thinking both of "git log -11" as well as out-of-tree users
of parse-options.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] tests: make all test files executable
From: Jeff King @ 2009-10-02 8:39 UTC (permalink / raw)
To: Mark Rada; +Cc: Junio C Hamano, git
In-Reply-To: <20091002080134.GD27664@coredump.intra.peff.net>
On Fri, Oct 02, 2009 at 04:01:34AM -0400, Jeff King wrote:
> > 0 files changed, 0 insertions(+), 0 deletions(-)
> > mode change 100644 => 100755 t/t5531-deep-submodule-push.sh
> > mode change 100644 => 100755 t/t9501-gitweb-standalone-http-status.sh
> >
> > diff --git a/t/t5531-deep-submodule-push.sh b/t/t5531-deep-submodule-push.sh
> > old mode 100644
> > new mode 100755
> > diff --git a/t/t9501-gitweb-standalone-http-status.sh
> > b/t/t9501-gitweb-standalone-http-status.sh
> > old mode 100644
> > new mode 100755
>
> When applying via "am", I only got the first change in my tree. I'll see
> if I can confirm and make a test case.
Ah, nevermind. The problem is that your patch was word-wrapped, making
the second "diff --git" line bogus. It would have been nice to have it
print a warning instead of silently ignoring that bit of the patch.
I'm not sure if it is a good idea, though. git-apply sees that the "diff
--git" line is there but can't get a filename from it. Which _should_
cause it to barf when we get to the mode lines. But we first see the
wrapped filename and consider that patch section to be over (and the
mode lines just become cruft at the end of the patch, which we must
ignore).
And we must consider that patch section to be over when we see random
text, because we need to jump back to the outer parser looking for more
hunks. We could warn about a "diff --git" line that has no actual
changes associated with it, though that is certainly a user-visible
change. I also suspect it wouldn't help if there was a mode change
followed by some actual content changes.
Hmph.
-Peff
^ permalink raw reply
* Re: [PATCH 2/2] allow mangling short options which take integer arguments
From: Clemens Buchacher @ 2009-10-02 8:26 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Shawn O. Pearce, git
In-Reply-To: <20091002075012.GB27664@coredump.intra.peff.net>
On Fri, Oct 02, 2009 at 03:50:12AM -0400, Jeff King wrote:
> On Fri, Oct 02, 2009 at 09:43:17AM +0200, Clemens Buchacher wrote:
>
> > On Thu, Oct 01, 2009 at 11:55:03PM +0200, Johannes Schindelin wrote:
> >
> > > And this patch looks even more straight-forward than 1/2, _but_... what
> > > about cases where there are short options that are digits?
> >
> > Could you point me to one of those? I did not find any during my
> > non-exhaustive search. We should be able to handle them easily by adding
> > PARSE_OPT_MANY.
>
> The one that comes readily to mind is "git log -1", but that is actually
> parsed by the revision options parser, which doesn't use parseopt. But
> there are a few done by parseopt:
Oh, I mistakenly thought Dscho was asking about options with single-digit
arguments. Thanks for clearing this up.
Clemens
^ permalink raw reply
* Re: MSVC build broken (on cygwin)
From: Alex Riesen @ 2009-10-02 8:23 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: Ramsay Jones, GIT Mailing-list, Shawn O. Pearce
In-Reply-To: <4AC5B4AE.5070307@gmail.com>
MSVC (all versions) define a compiler specific _MSC_VER, if that's of any use.
^ 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