* 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
* Re: MSVC build broken (on cygwin)
From: Marius Storm-Olsen @ 2009-10-02 8:07 UTC (permalink / raw)
To: Ramsay Jones; +Cc: GIT Mailing-list, Shawn O. Pearce
In-Reply-To: <4AC4E2C2.6030509@ramsay1.demon.co.uk>
Ramsay Jones said the following on 01.10.2009 19:11:
> Hi Marius,
>
> I know that I'm somewhat late to comment on your recent MSVC
> build patches, but I was busy at the time; better late than
> never... maybe ;-)
>
> While the patches were traversing the list, I was feeling
> somewhat nervous about the effect of the patches on the
> cygwin build; in fact I remember thinking that they had
> *probably* broken the build. But I was busy...
>
> Well I finally found time, yesterday, to take a closer look.
> I spent 10-15 minutes squinting at the code in order to
> convince myself that you had in fact *not* broken the cygwin
> build. :)
...
> [Note: I was a little surprised that it got that far, since I didn't
> expect it to find the zlib header files. However, I have set the
> INCLUDE environment variable which msvc is respecting! yeah, a bit old
> fashioned! Having also set the LIB environment variable, I was then
> a bit surprised that the linker didn't find the library; until I
> noticed that my library is called libz.lib *not* zlib.lib!]
...
Clone the git://repo.or.cz/msvcgit.git, and run the
setup_32bit_env.cmd script in there, and you should have everything
you need to both compile and link Git with MSVC.
> Note that the patch below includes some line-wrapping which you can
> ignore if you like, it just makes the Makefile easier to read.
> The only change that matters is inserting a space between -DWIN32 and
> -D_CONSOLE.
>
> Anyway, the point is *not* to get the msvc build to work for me; rather
> it is to understand why the build *works* for you. ;-)
First of all, thanks for the thorough report! :)
Second, I just recompiled, and it magically works for me. Why is a
good question, since I also think it shouldn't at this point. The
_WIN32 define is added by the compiler, and the WIN32 is added by
windows.h, so our define guards *should* be testing for the _WIN32 define.
To how the guarded code reacts, I preprocessed the run-command.c with
both version of the command line, and the result was the same:
( 9:54:49 - D:\msvc\git)
> cl -E ... -DWIN32-D_CONSOLE ... run-command.c | grep run_thread
run-command.c
static unsigned __stdcall run_thread(void *data)
async->tid = (HANDLE) _beginthreadex(((void *)0), 0,
run_thread, async, 0, ((void *)0));
( 9:55:43 - D:\msvc\git)
> cl -E ... -DWIN32 -D_CONSOLE ... run-command.c | grep run_thread
run-command.c
static unsigned __stdcall run_thread(void *data)
async->tid = (HANDLE) _beginthreadex(((void *)0), 0,
run_thread, async, 0, ((void *)0));
So, obviously, some magic in there is making it work for me. I have a
hard time locating the magic in question though. :-/
That being said, does adding the space between the defines fix the
MSVC compilation using Cygwin's GNU Make? It's none-the-less a correct
patch, so you get an ack from me. Thanks!
Acked-by: Marius Storm-Olsen <mstormo@gmail.com>
--
.marius
^ permalink raw reply
* Re: [PATCH] tests: make all test files executable
From: Jeff King @ 2009-10-02 8:01 UTC (permalink / raw)
To: Mark Rada; +Cc: Junio C Hamano, git
In-Reply-To: <4AC55E78.7010109@mailservices.uwaterloo.ca>
On Thu, Oct 01, 2009 at 09:59:20PM -0400, Mark Rada wrote:
> For consistency with the rest of the test files.
Thanks. Interestingly, though, I think this may be triggering a bug in
git-am:
> 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.
-Peff
^ permalink raw reply
* Re: [PATCH 1/2] do not mangle short options which take arguments
From: Jeff King @ 2009-10-02 7:57 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: Shawn O. Pearce, git
In-Reply-To: <20091002073628.GA9444@localhost>
On Fri, Oct 02, 2009 at 09:36:28AM +0200, Clemens Buchacher wrote:
> Yes, that syntax looks reasonable. I expect this to be more involved, so I
> will rework the patch once we agree on whether or not we want it at all.
Thanks.
> Yes, that can happen. On the other hand, the "-ammend" typo actually did
> happen.
It did, but we are only guessing at how many people will be disrupted by
the new rule. That being said...
> And what I'm even more worried about are ambiguities like
>
> $ git commit -uno <path>
> $ git commit -nou <path>
>
> which are interpreted as one of
>
> $ git commit --untracked-files=no <path>
> $ git commit --untracked-files --no-verify --only <path>
Making this clearer is a much more compelling argument to me. Though I
thought it was customary (not just for git, but for other programs) that
a short option that takes a parameter (even an optional one) would
consume the rest of a short options string. Still, it is a potential
source of confusion.
> > On the other hand, the cuddled value already has some DWYM magic (it
> > recognizes -amend), so it is already a little bit unsafe to use
>
> Well, an error message is a lot safer than executing something you did not
> intend.
It's also an error exit code, which can affect how a script performs
(e.g., "git diff --exit-code"). But I don't have any real examples off
the top of my head of how this could be particularly disastrous, so feel
free to dismiss that as pushing too far into the hypothetical.
-Peff
^ permalink raw reply
* Re: [PATCH 2/2] allow mangling short options which take integer arguments
From: Jeff King @ 2009-10-02 7:50 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: Johannes Schindelin, Shawn O. Pearce, git
In-Reply-To: <20091002074317.GB9444@localhost>
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:
$ git grep "OPT_.*'[0-9]'"
archive.c: OPT__COMPR('1', &compression_level, "compress faster", 1),
archive.c: OPT__COMPR_HIDDEN('2', &compression_level, 2),
archive.c: OPT__COMPR_HIDDEN('3', &compression_level, 3),
archive.c: OPT__COMPR_HIDDEN('4', &compression_level, 4),
archive.c: OPT__COMPR_HIDDEN('5', &compression_level, 5),
archive.c: OPT__COMPR_HIDDEN('6', &compression_level, 6),
archive.c: OPT__COMPR_HIDDEN('7', &compression_level, 7),
archive.c: OPT__COMPR_HIDDEN('8', &compression_level, 8),
archive.c: OPT__COMPR('9', &compression_level, "compress better", 9),
builtin-checkout.c: OPT_SET_INT('2', "ours", &opts.writeout_stage, "stage",
builtin-checkout.c: OPT_SET_INT('3', "theirs", &opts.writeout_stage, "stage",
-Peff
^ 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