* 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: 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
* 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: 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: [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
* 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: 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
* 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: [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: 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: 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
* 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: 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
* 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 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
* 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 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
* [PATCH] Use the best HTTP authentication method supported by the server
From: Nicholas Miell @ 2009-10-02 19:04 UTC (permalink / raw)
To: gsky51; +Cc: git, Nicholas Miell
In-Reply-To: <25718488.post@talk.nabble.com>
Currently, libcurl is limited to using HTTP Basic authentication if a
username and password are specified. HTTP Basic passes the username
and password to the server as plaintext, which is obviously
suboptimal. Furthermore, some servers are configured to require a more
secure authentication method (e.g. Digest or NTLM), which means that
git can't talk to them at all.
This is easily solved by telling libcurl to use any HTTP
authentication method it pleases. I leave the decision as to whether
HTTP Basic (i.e. completely insecure) should be allowed at all to
somebody else. This can be easily changed in the future by using
CURLAUTH_ANYSAFE instead of CURLAUTH_ANY.
Signed-off-by: Nicholas Miell <nmiell@gmail.com>
---
http.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
This passes make test; but I haven't actually tested it on a real
HTTP server.
diff --git a/http.c b/http.c
index 23b2a19..1937b45 100644
--- a/http.c
+++ b/http.c
@@ -185,6 +185,7 @@ static void init_curl_http_auth(CURL *result)
if (!user_pass)
user_pass = xstrdup(getpass("Password: "));
strbuf_addf(&up, "%s:%s", user_name, user_pass);
+ curl_easy_setopt(result, CURLOPT_HTTPAUTH, CURLAUTH_ANY);
curl_easy_setopt(result, CURLOPT_USERPWD,
strbuf_detach(&up, NULL));
}
--
1.6.2.5
^ permalink raw reply related
* Re: Figuring out which patches have been applied
From: skillzero @ 2009-10-02 19:16 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910910020736n539f4331nfd61175b275c7d28@mail.gmail.com>
On Fri, Oct 2, 2009 at 7:36 AM, Jon Smirl <jonsmirl@gmail.com> 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?
There may be a better way, but I needed to do a similar thing with
commits that were cherry-pick'd so I wrote a simple
git-contains-equivalent script to search for equivalent patch ID's
given a commit ID. You could do something like that, but using
git-patch-id as the source instead getting it from an existing commit
like the following script does.
#!/bin/bash
set -o pipefail
searchCommitID=`git rev-parse $1`
searchPatchID=`git show $searchCommitID | git patch-id`
if [ $? -ne 0 ]; then
exit 1
fi
searchPatchID=${searchPatchID% *}
echo "Searching for equivalents to commit $searchCommitID (patch
$searchPatchID)..."
git log --all -p | git patch-id | grep $searchPatchID |
while read patchID commitID; do
if [ "$commitID" = "$searchCommitID" ]; then
echo "Exact commit $commitID is on the following branches:"
else
echo "Equivalent commit $commitID is on the following branches:"
fi
git branch -a --contains $commitID
done
^ permalink raw reply
* Re: How to delete large files
From: Nils Homer @ 2009-10-02 19:20 UTC (permalink / raw)
To: git
In-Reply-To: <4AC6031A.2070409@viscovery.net>
Thank-you for all of your insightful help. Combining all the advice, the
commands that worked are:
git filter-branch --index-filter "git rm -rf --cached --ignore-unmatch
$files" --tag-name-filter cat -- --all
git -rf .git/refs/original
git reflog expire --expire=now
git gc --prune=now
I then cloned the repository to a different location and replaced my
centralized version with the cloned copy.
Thanks,
Nils
On 10/2/09 6:41 AM, "Johannes Sixt" <j.sixt@viscovery.net> wrote:
> 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
* "Not currently on any branch"
From: Tim @ 2009-10-02 20:08 UTC (permalink / raw)
To: git
I have some code in a git repo that is "Not currently on any branch". Now,
there's the master branch and another branch 'ui-integration' that I'm using in
this project. I don't know how the project got into this headless state, but I
need to be using the 'ui-integration' branch.
I tried looking around the blogosphere for a solution, and tried what I found
here. But it seems like only my last commit (not the previous 10 I made) shows
up in the master branch (not ui-integration ).
http://blog.kortina.net/post/71935540/fix-git-not-currently-on-any-branch-problem
What's the most straightforward & cleanest way to merge my changes in the
headless branch to my 'ui-integration' branch?
Thanks in advance
Tim
^ permalink raw reply
* Re: "Not currently on any branch"
From: Steven Noonan @ 2009-10-02 20:58 UTC (permalink / raw)
To: Tim; +Cc: git
In-Reply-To: <loom.20091002T215942-663@post.gmane.org>
On Fri, Oct 2, 2009 at 1:08 PM, Tim <timothyjwashington@yahoo.ca> wrote:
> I have some code in a git repo that is "Not currently on any branch". Now,
> there's the master branch and another branch 'ui-integration' that I'm using in
> this project. I don't know how the project got into this headless state, but I
> need to be using the 'ui-integration' branch.
>
> I tried looking around the blogosphere for a solution, and tried what I found
> here. But it seems like only my last commit (not the previous 10 I made) shows
> up in the master branch (not ui-integration ).
> http://blog.kortina.net/post/71935540/fix-git-not-currently-on-any-branch-problem
>
> What's the most straightforward & cleanest way to merge my changes in the
> headless branch to my 'ui-integration' branch?
>
Try 'git checkout -b temp', which creates a branch called 'temp' with
its HEAD at where you currently are, and then merge your changes to
ui-integration via 'git checkout ui-integration; git merge temp', and
finally drop the junk branch with 'git branch -d temp'
- Steven
^ permalink raw reply
* [PATCH] MSVC: fix build warnings
From: Michael Wookey @ 2009-10-02 21:40 UTC (permalink / raw)
To: git
When building with MSVC, the following warnings are issued:
warning C4700: uninitialized local variable 'xxx' used
Where 'xxx' is the name of the uninitialised variable that is being used
to initialise another variable. In all instances, the variable 'xxx' is
being used to initialise itself. Remove the use of initialising a
variable with itself to suppress these warnings with MSVC.
Some of these variables require an initial value. This is to prevent gcc
from issuing a warning about a variable being used before it has been
initialised. Suppress these gcc warnings by explicitly initialising the
required variables.
Signed-off-by: Michael Wookey <michaelwookey@gmail.com>
---
This patch is but a small step in removing the build warnings that are
generated when compiling with MSVC.
builtin-branch.c | 2 +-
builtin-cat-file.c | 2 +-
builtin-fast-export.c | 2 +-
builtin-fetch--tool.c | 4 ++--
builtin-rev-list.c | 2 +-
fast-import.c | 4 ++--
match-trees.c | 12 ++++++------
merge-recursive.c | 2 +-
run-command.c | 2 +-
transport.c | 2 +-
wt-status.c | 2 +-
11 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index 9f57992..cf6a9ca 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -93,7 +93,7 @@ static const char *branch_get_color(enum color_branch ix)
static int delete_branches(int argc, const char **argv, int force, int kinds)
{
- struct commit *rev, *head_rev = head_rev;
+ struct commit *rev, *head_rev;
unsigned char sha1[20];
char *name = NULL;
const char *fmt, *remote;
diff --git a/builtin-cat-file.c b/builtin-cat-file.c
index 5906842..669608a 100644
--- a/builtin-cat-file.c
+++ b/builtin-cat-file.c
@@ -152,7 +152,7 @@ static int batch_one_object(const char *obj_name,
int print_contents)
unsigned char sha1[20];
enum object_type type = 0;
unsigned long size;
- void *contents = contents;
+ void *contents;
if (!obj_name)
return 1;
diff --git a/builtin-fast-export.c b/builtin-fast-export.c
index b0a4029..07e41ea 100644
--- a/builtin-fast-export.c
+++ b/builtin-fast-export.c
@@ -422,7 +422,7 @@ static void get_tags_and_duplicates(struct
object_array *pending,
for (i = 0; i < pending->nr; i++) {
struct object_array_entry *e = pending->objects + i;
unsigned char sha1[20];
- struct commit *commit = commit;
+ struct commit *commit;
char *full_name;
if (dwim_ref(e->name, strlen(e->name), sha1, &full_name) != 1)
diff --git a/builtin-fetch--tool.c b/builtin-fetch--tool.c
index 3dbdf7a..8463f66 100644
--- a/builtin-fetch--tool.c
+++ b/builtin-fetch--tool.c
@@ -416,14 +416,14 @@ static int expand_refs_wildcard(const char
*ls_remote_result, int numrefs,
static int pick_rref(int sha1_only, const char *rref, const char
*ls_remote_result)
{
int err = 0;
- int lrr_count = lrr_count, i, pass;
+ int lrr_count, i, pass;
const char *cp;
struct lrr {
const char *line;
const char *name;
int namelen;
int shown;
- } *lrr_list = lrr_list;
+ } *lrr_list;
for (pass = 0; pass < 2; pass++) {
/* pass 0 counts and allocates, pass 1 fills... */
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index 4ba1c12..b7b9fe3 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -386,7 +386,7 @@ int cmd_rev_list(int argc, const char **argv,
const char *prefix)
mark_edges_uninteresting(revs.commits, &revs, show_edge);
if (bisect_list) {
- int reaches = reaches, all = all;
+ int reaches, all;
revs.commits = find_bisection(revs.commits, &reaches, &all,
bisect_find_all);
diff --git a/fast-import.c b/fast-import.c
index 7ef9865..6ed1602 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -1858,7 +1858,7 @@ static void file_change_m(struct branch *b)
const char *p = command_buf.buf + 2;
static struct strbuf uq = STRBUF_INIT;
const char *endp;
- struct object_entry *oe = oe;
+ struct object_entry *oe;
unsigned char sha1[20];
uint16_t mode, inline_data = 0;
@@ -2084,7 +2084,7 @@ static int parse_from(struct branch *b)
static struct hash_list *parse_merge(unsigned int *count)
{
- struct hash_list *list = NULL, *n, *e = e;
+ struct hash_list *list = NULL, *n, *e;
const char *from;
struct branch *s;
diff --git a/match-trees.c b/match-trees.c
index 0fd6df7..99d559e 100644
--- a/match-trees.c
+++ b/match-trees.c
@@ -72,12 +72,12 @@ static int score_trees(const unsigned char *hash1,
const unsigned char *hash2)
die("%s is not a tree", sha1_to_hex(hash2));
init_tree_desc(&two, two_buf, size);
while (one.size | two.size) {
- const unsigned char *elem1 = elem1;
- const unsigned char *elem2 = elem2;
- const char *path1 = path1;
- const char *path2 = path2;
- unsigned mode1 = mode1;
- unsigned mode2 = mode2;
+ const unsigned char *elem1 = NULL;
+ const unsigned char *elem2 = NULL;
+ const char *path1 = NULL;
+ const char *path2 = NULL;
+ unsigned mode1 = 0;
+ unsigned mode2 = 0;
int cmp;
if (one.size)
diff --git a/merge-recursive.c b/merge-recursive.c
index f55b7eb..8d7de22 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -1267,7 +1267,7 @@ int merge_recursive(struct merge_options *o,
{
struct commit_list *iter;
struct commit *merged_common_ancestors;
- struct tree *mrtree = mrtree;
+ struct tree *mrtree;
int clean;
if (show(o, 4)) {
diff --git a/run-command.c b/run-command.c
index cf2d8f7..014f723 100644
--- a/run-command.c
+++ b/run-command.c
@@ -19,7 +19,7 @@ int start_command(struct child_process *cmd)
{
int need_in, need_out, need_err;
int fdin[2], fdout[2], fderr[2];
- int failed_errno = failed_errno;
+ int failed_errno;
/*
* In case of errors we must keep the promise to close FDs
diff --git a/transport.c b/transport.c
index 644a30a..c6bb992 100644
--- a/transport.c
+++ b/transport.c
@@ -102,7 +102,7 @@ static void insert_packed_refs(const char
*packed_refs, struct ref **list)
return;
for (;;) {
- int cmp = cmp, len;
+ int cmp, len;
if (!fgets(buffer, sizeof(buffer), f)) {
fclose(f);
diff --git a/wt-status.c b/wt-status.c
index 38eb245..060ad17 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -133,7 +133,7 @@ static void wt_status_print_change_data(struct wt_status *s,
{
struct wt_status_change_data *d = it->util;
const char *c = color(change_type, s);
- int status = status;
+ int status = 0;
char *one_name;
char *two_name;
const char *one, *two;
--
1.6.5.rc2
^ permalink raw reply related
* Re: "Not currently on any branch"
From: Alex Riesen @ 2009-10-02 21:46 UTC (permalink / raw)
To: Tim; +Cc: git
In-Reply-To: <loom.20091002T215942-663@post.gmane.org>
On Fri, Oct 2, 2009 at 22:08, Tim <timothyjwashington@yahoo.ca> wrote:
> What's the most straightforward & cleanest way to merge my changes in the
> headless branch to my 'ui-integration' branch?
Assuming you use a Bourne shell:
$ prev=$(git rev-parse HEAD)
$ git checkout ui-integration && git merge $prev
^ permalink raw reply
* Re: [PATCH] MSVC: fix build warnings
From: Junio C Hamano @ 2009-10-02 22:05 UTC (permalink / raw)
To: Michael Wookey; +Cc: git
In-Reply-To: <d2e97e800910021440q46bd46c4y8a5af987620ffc5c@mail.gmail.com>
Michael Wookey <michaelwookey@gmail.com> writes:
> diff --git a/builtin-branch.c b/builtin-branch.c
> index 9f57992..cf6a9ca 100644
> --- a/builtin-branch.c
> +++ b/builtin-branch.c
> @@ -93,7 +93,7 @@ static const char *branch_get_color(enum color_branch ix)
>
> static int delete_branches(int argc, const char **argv, int force, int kinds)
> {
> - struct commit *rev, *head_rev = head_rev;
I haven't tried, but the patch may break build with "gcc -Werror".
This is a common and unfortunate idiom to tell the readers of the code
that this initialization is unnecessary, gcc is not clever enough to
notice and gives warnings, and we are squelching it, knowing what we are
doing.
^ 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