* Re: how to ignore all .xvpics directories
From: Jakub Narebski @ 2008-11-03 11:49 UTC (permalink / raw)
To: Christoph Duelli; +Cc: git
In-Reply-To: <490ECE54.5090505@melosgmbh.de>
Christoph Duelli <duelli@melosgmbh.de> writes:
> Is it possible to ignore (once and for all) that directories like
> .pics or .xvpics (that might occur all over the place where xv was
> called) should be ignored?
>
> [ Note: some time ago this issue has already popped up:
> http://thread.gmane.org/gmane.comp.version-control.git/50504
>
> However, adding a line with just .xvpics in the toplevel .gitignore
> does not help. Neither does /**/.xvpics
Could you reproduce the steps you tried? Because I have checked, and
putting .xvpics or .xvpics/ in top level .gitignore (or in
.git/info/excludes, or ~/.gitignore) works as expected: filename
without '/' in it is match agains _basename_.
Note that .gitignore is about contents which is not tracked (not known
to git). If you added .xvpics to commit by accident, .gitignore will
do nothing then.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Jakub Narebski @ 2008-11-03 12:06 UTC (permalink / raw)
To: Sam Vilain; +Cc: git, Nicolas Pitre
In-Reply-To: <1225701813.20883.85.camel@maia.lan>
Dnia poniedziałek 3. listopada 2008 09:43, Sam Vilain napisał:
> On Fri, 2008-10-31 at 08:36 +0100, Jakub Narebski wrote:
> > > > git checkout --track origin/wr34251-do-something
> > >
> > > Ah, that's a new feature. Still, I think it's poorly Huffman coded; far
> > > too verbose.
> >
> > Well, either you have a little bit more verbose, or you have to have
> > some DWIM-mery, which (as usual with DWIM) can go wrong.
>
> That's right, you need to choose when to assume that the user meant
> something that they didn't write very carefully.
>
> But look at this:
>
> git checkout origin/master
>
> git checkout -t origin/master
>
> The option is called "--track", yet in this case what it actually means
> in the default situation where you have autosetupmerge (or whatever it's
> really called) set to true, is that it modifies the command to imply "-b
> master". So, in this situation, that is clearly what was meant.
>
> Perhaps you can give an example of why this particular piece of DWIM
> might not be WYM?
I was not talking about "git checkout -t origin/master" being shortcut
for "git checkout -b master -t origin/master", but about proposed
DWIM-mery for "git checkout -b <branch>" which would be
{ git checkout -b <branch> -t <remote>/<branch>
git checkout -b <branch> = { if there exists <remote>/<branch>
{
{ git checkout -b <branch> HEAD
{ otherwise
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: how to ignore all .xvpics directories
From: Christoph Duelli @ 2008-11-03 12:15 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3d4hdf2qp.fsf@localhost.localdomain>
Jakub Narebski schrieb:
>> [ Note: some time ago this issue has already popped up:
>> http://thread.gmane.org/gmane.comp.version-control.git/50504
>>
>> However, adding a line with just .xvpics in the toplevel .gitignore
>> does not help. Neither does /**/.xvpics
>
> Could you reproduce the steps you tried? Because I have checked, and
> putting .xvpics or .xvpics/ in top level .gitignore (or in
> .git/info/excludes, or ~/.gitignore) works as expected: filename
> without '/' in it is match agains _basename_.
>
> Note that .gitignore is about contents which is not tracked (not known
> to git). If you added .xvpics to commit by accident, .gitignore will
> do nothing then.
Thank you Jakub,
I checked that and indeed... someone left uncomitted changes (i.e.
deleted those (acc. commited) files without committing) and got me confused.
It *does* work for untracked files.
Sorry for the noise.
--
Christoph Duelli
^ permalink raw reply
* Re: [PATCH 3/3] git send-email: add --annotate option
From: Matthieu Moy @ 2008-11-03 12:18 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Junio C Hamano, git
In-Reply-To: <20081102095152.GG4066@artemis>
Pierre Habouzit <madcoder@debian.org> writes:
> I don't know for others, but with those series, git-send-email is
> _REALLY_ what I would have wanted it to be from day 1.
Same for me. I didn't really understand why git was asking me to run
two separate commands to send a patch. Having git-send-email do
everything and ask me only the required is really the way I expected
it to be.
(probably not a coincidence that at least bzr and darcs have a "send"
command that does just this)
--
Matthieu
^ permalink raw reply
* Re: [Announce] teamGit v0.0.4
From: Matthieu Moy @ 2008-11-03 12:53 UTC (permalink / raw)
To: Abhijit Bhopatkar; +Cc: git
In-Reply-To: <d62af2d5-4ba4-4fe6-9ecb-6df007f87245@s9g2000prm.googlegroups.com>
Abhijit Bhopatkar <bain@devslashzero.com> writes:
> I have just tagged the teamgit repo as v0.0.4
You should include a short summary (teamgit is a .... for git) of what
teamgit does in such announcements.
AIUI, it's a GUI for git.
--
Matthieu
^ permalink raw reply
* Re: libgit2 - a true git library
From: Andreas Ericsson @ 2008-11-03 13:08 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Scott Chacon
In-Reply-To: <20081101204259.GC15463@spearce.org>
Shawn O. Pearce wrote:
> Andreas Ericsson <ae@op5.se> wrote:
>> Shawn O. Pearce wrote:
>>> During the GitTogether we were kicking around the idea of a ground-up
>>> implementation of a Git library.
>> Having looked briefly at the code, I've got a couple of comments:
>> * GIT_EXTERN() does nothing. Ever. It's noise and should be removed.
>
> I feel the same way.
>
> But I was also under the impression that the brilliant engineers
> who work for Microsoft decided that on their platform special
> annotations have to be inserted on functions that a DLL wants to
> export to applications.
>
> Hence any cross-platform library that I have seen annotates their
> exported functions this way, with the macro being empty on POSIX
> and expanding to some magic keyword on Microsoft's OS. I think it
> goes between the return type and the function name too...
>
>> Instead it would be better to have GIT_PRIVATE(),
>
> I can see why you said this; needing GIT_PRIVATE() is a lot more
> rare than needing GIT_EXTERN(). Only a handful of cross-module,
> but private, functions are likely to exist, so it makes sense to
> mark the smaller subset. But see above. *sigh*
>
Thanks for the detailed explanation.
>> * Prefixing the files themselves with git_ is useless and only leads
>> to developer frustration. I imagine we'd be installing any header
>> files in a git/ directory anyway, so we're gaining absolutely
>> nothing with the git_ prefix on source-files.
>
> Yes, I realized that this morning. I plan on changing that mess
> around so we have "include/git/oid.h" and library and application
> code can use "#include <git/oid.h>". Library modules should just
> be "src/oid.c" then.
>
I noticed when I fetched the latest head today that it's already
done. I fail to understand why headers need to be in a separate
path so that oid.c can't just '#include "oid.h"'.
With the risk of nitpicking you to death, put public headers in a
separate dir (I'd suggest public/%.h in Make-speak, but I have no
strong preference) and keep private headers next to %.c. Always
#include the public header file from the private one (that should
probably be in CONVENTIONS).
>> Apart from that, it seems you've been designing a lot rather than
>> trying to use the API to actually do something.
>
> I wanted to get a solid idea of what our API conventions should be,
> before we started writing a lot of code around them. Part of the
> problem with the git.git code is we don't have conventions that are
> really suited for use in a shared library (assuming we even have
> conventions in there) so we can't use that code as a library today.
>
Right. I guess I'm too firm a believer in system evolution by constant
refactoring (with fluctuating api's, yes) rather than thinking initial
design can ever be done exactly right.
>> It would, imo, be
>> a lot better to start development with adding functionality shared
>> between all programs and then expand further on that, such as
>> incorporating all functions needed for manipulating tags into the
>> library and then modify existing code to use the library to get
>> tag-ish things done.
>
> Tags are mostly pointless. Its a tiny part of the code that isn't
> that interesting to most people. And it requires object database
> access anyway if you want to talk about parsing or reading a tag.
> There's almost no point in a git library that can't read the on
> disk object database, or write to it.
>
True, but designing top-down means you'll need to write one more
API to get the first stuff working, so you'll always be using the
new code you write immediately and for something real. IMO, that
makes it much more fun and productive to write the lib itself.
>> I also think it's quite alright to not strive *too* hard to make
>> all functions thread-safe, as very few of them will actually need
>> that. It's unlikely that a user program will spawn one thread to
>> write a lot of tags while another is trying to parse them, for
>> example.
>
> Oh really?
>
> Maybe true for tags, just because they are such an unimportant part
> of the git suite compared to everything else.
>
> But right now I'm running a production system using a threaded server
> process that is operating on Git repositories. Fortunately threads
> suck less on Java than they do on POSIX, and we have a 100% pure
> Java library available for Git.
>
> It would be nice if a library created in the late part of 2008
> recognized that threads exist, aren't going to disappear tomorrow,
> and that consumers of libraries actually may need to run the library
> within a threaded process.
>
> Or are you one of those developers who think threads only exist
> in the giant monolithic kernel land, and all user space should
> be isolated process? I often wonder who such people can justify
> the kernel address space being multi-threaded but userland being
> stuck to single threaded applications. Oh, right, the kernel has
> to go fast...
>
No, I'm one of those developers who think that if implementing a
function as thread-safe means it'll take 50 times longer than just
writing something that works, the right decision is to go with the
faster way to get the job done and then expand on it later when the
need arises. Reading my original post, I realize I should have made
that more clear. Sorry for making your gall rise unnecessarily.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: why not TortoiseGit
From: Johannes Schindelin @ 2008-11-03 13:26 UTC (permalink / raw)
To: Nigel Magnay; +Cc: Li Frank, Scott Chacon, Andreas Ericsson, Ian Hilt, git
In-Reply-To: <320075ff0811030200q606b76a8i16496cf7b8b1b7d2@mail.gmail.com>
Hi,
On Mon, 3 Nov 2008, Nigel Magnay wrote:
> But it doesn't look like a hard project to me, just requires stripping
> out a lot of junk and re-patching callouts to a git executable (which
> could be the standard git tools) and a minimal git library that knows if
> files are dirty.
I only wish that people would put their code where there mouth is.
At least with GitCheetah, we have working code, _and_ an opportunity to go
cross-platform.
Ciao,
Dscho
^ permalink raw reply
* Re: how to ignore all .xvpics directories
From: Matthieu Moy @ 2008-11-03 13:03 UTC (permalink / raw)
To: Christoph Duelli; +Cc: git
In-Reply-To: <490ECE54.5090505@melosgmbh.de>
Christoph Duelli <duelli@melosgmbh.de> writes:
> Is it possible to ignore (once and for all) that directories like
> .pics or .xvpics (that might occur all over the place where xv was
> called) should be ignored?
in ~/.gitconfig:
[core]
excludesfile = /home/yourlogin/.gitignore
then, in ~/.gitignore:
.xvpics
and all your .xvpics will be ignored for all your projects.
(it's nice to keep such ignore list user-wide and not project-wide if
you don't want to bother your collaborators with your choice of
software).
--
Matthieu
^ permalink raw reply
* Re: [Announce] teamGit v0.0.4
From: Abhijit Bhopatkar @ 2008-11-03 13:35 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqfxm9km1w.fsf@bauges.imag.fr>
>> I have just tagged the teamgit repo as v0.0.4
>
> You should include a short summary (teamgit is a .... for git) of what
> teamgit does in such announcements.
>
Ack,
teamGit is a GUI for git,
in its final roadmap it aims to aid small closed teams to use git,
currently its a pretty good frontend for basic git operations.
Abhijit
^ permalink raw reply
* [Q] Abbreviated history graph?
From: Brian Foster @ 2008-11-03 13:39 UTC (permalink / raw)
To: Git Mailing List
Hello,
A colleague and I recently wanted to examine the
history in a broad sense without worrying too much
about the individual commits. What we (think we)
wanted is a ‘gitk --all’ history graph showing only
“named” historical points; i.e., tags and branch
HEADs, perhaps with an indication of whether or not
it's a “linear” change sequence that leads from one
to another. That is, hypothetically, if the history
looks something like (where ‘A’ &tc has a name as
per above, and ‘*’ does not):
A--->*--->*--->C--->D--->*----->E
\ \ /
\->*-->B \->*--->*--->F
What we wanted to see is something like:
A------>C--->D--->E
\ \ /
\->B \-----/--->F
Is there some way of doing something similar to that
(git v1.6.0.2)? In addition to ‘gitk’, we also (rather
quickly!) tried both ‘qgit’ and ‘giggle’, but without
any apparent success.
cheers!
-blf-
--
“How many surrealists does it take to | Brian Foster
change a lightbulb? Three. One calms | somewhere in south of France
the warthog, and two fill the bathtub | Stop E$$o (ExxonMobil)!
with brightly-coloured machine tools.” | http://www.stopesso.com
^ permalink raw reply
* Re: why not TortoiseGit
From: Nigel Magnay @ 2008-11-03 13:39 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Li Frank, Scott Chacon, Andreas Ericsson, Ian Hilt, git
In-Reply-To: <alpine.DEB.1.00.0811031425080.22125@pacific.mpi-cbg.de.mpi-cbg.de>
>> But it doesn't look like a hard project to me, just requires stripping
>> out a lot of junk and re-patching callouts to a git executable (which
>> could be the standard git tools) and a minimal git library that knows if
>> files are dirty.
>
> I only wish that people would put their code where there mouth is.
>
> At least with GitCheetah, we have working code, _and_ an opportunity to go
> cross-platform.
>
Well, hey, I don't care there's no TortoiseGit. I looked at these
things back when I had colleagues stuck on Windows, and at the time
wanted to try and wean them off SVN.
The shell-icon overlay limit on Windows looked a significant problem
to me, and a good reason for at least re-using that bit of code (which
is common to even tortoiseCVS). It looked like it had been through a
significant number of iterations to get platform shell subtleties
right.
I even looked at wacky things, like using IKVM.Net and JGit to hack it
quickly, but that's a non-starter because of MS' stupid
one-clr-per-process.
That's what I found. Maybe it'll be useful for anyone else that wants
to continue. Since it's not an itch for me any more, and it won't feed
my children, until someone that cares enough does something there
won't be one.
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Pierre Habouzit @ 2008-11-03 13:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sam Vilain, git
In-Reply-To: <7vy70123rr.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1513 bytes --]
On Sun, Nov 02, 2008 at 09:53:44PM +0000, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
> > * git-send-email should be either more interactive, or less: either
> > just use the damn configuration, or propose a mode where it spawns
> > an editor for each patch so that you can add further comments.
>
> In principle I'd agree, but I use send-email non-interactively myself (I
> type Meta/SE where Meta is an independent checkout of my 'todo' branch),
> so I am not sure if the "just use the configuration" is an added
> requirement. I also have this in .git/config in the repo:
>
> [sendemail]
> smtpserver = /usr/bin/msmtp
> to = git@vger.kernel.org
> suppressfrom
> signedoffcc = false
Well with my patches it goes _more_ interactive on request only, so that
wouldn't break your setup (you have to explicitely pass --annotated
and/or --compose). Okay arguably not the feature that auto enables
--compose on series of more than 1 patch, but you can redirect
send-email to | cat or pass --no-compose for that. Or we can drop that
bit of the patch if people find it too cumbersome, I can put that in an
alias I don't really care.
I really _care_ about not breaking send-email for its previous uses.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Fetch via http and proxy which requires authentication
From: Dilip M @ 2008-11-03 14:02 UTC (permalink / raw)
To: Paolo Ciarrocchi, Git Mailing List
In-Reply-To: <4d8e3fd30808280313i70f572cfh9c14fbc2adbf5cea@mail.gmail.com>
On Thu, Aug 28, 2008 at 3:43 PM, Paolo Ciarrocchi
<paolo.ciarrocchi@gmail.com> wrote:
>> Hi all,
>> i'm looking for a way to use git behind a corporate proxy which
>> requires authentication.
>> i just need to be able to fetch/pull via http.
>> i'm using git on a win xp box.
>> Any hint?
>
> Yes, google for http_proxy ;-)
>
> export http_proxy=http://host:port
> git clone http://username:password@giturl
I tried setting, export http_proxy=http://<user>:<password>@host:port
But git clone failed!
$git clone http://kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git git
clone http://kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Initialized empty Git repository in /home/dilipm/bin/linux-2.6/.git/
fatal:
http://kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/info/refs
download error - The requested file was not found
What may the problem? How can debug....
PS: wget works ...
--
Dilip
^ permalink raw reply
* Re: [Q] Abbreviated history graph?
From: Santi Béjar @ 2008-11-03 14:20 UTC (permalink / raw)
To: Brian Foster; +Cc: Git Mailing List
In-Reply-To: <200811031439.12111.brian.foster@innova-card.com>
[-- Attachment #1: Type: text/plain, Size: 2075 bytes --]
On Mon, Nov 3, 2008 at 2:39 PM, Brian Foster
<brian.foster@innova-card.com> wrote:
>
> Hello,
>
> A colleague and I recently wanted to examine the
> history in a broad sense without worrying too much
> about the individual commits. What we (think we)
> wanted is a 'gitk --all' history graph showing only
> "named" historical points; i.e., tags and branch
> HEADs, perhaps with an indication of whether or not
> it's a "linear" change sequence that leads from one
> to another. That is, hypothetically, if the history
> looks something like (where 'A' &tc has a name as
> per above, and '*' does not):
>
> A--->*--->*--->C--->D--->*----->E
> \ \ /
> \->*-->B \->*--->*--->F
>
> What we wanted to see is something like:
>
> A------>C--->D--->E
> \ \ /
> \->B \-----/--->F
>
> Is there some way of doing something similar to that
> (git v1.6.0.2)? In addition to 'gitk', we also (rather
> quickly!) tried both 'qgit' and 'giggle', but without
> any apparent success.
Not in git.git but you can use the script at the bottom (also attached
in case it is whitespace damage).
It could be much faster if "git log" stops when finding a tag/branch.
HTH,
Santi
[git-overview]
#!/bin/sh
TMP=$(mktemp -t git-overview.XXXXXXXXXXX)
trap 'rm -f "$TMP"' 0 1 2 3 15
git log --reverse --pretty=short --decorate --pretty=format:%H%d $@ |\
awk 'BEGIN {FS="[ ,()]*"} NF>=2 {print $1}' | \
while read hash ; do
# Independent tags/branches parents:
# Notes:
# * -n 1000 to limit the search, ideally "git log" could stop
# traversing the history when hits a tag/branch tip
# * head -n 25 because "git show-branch --independent" has this limit
ancestors=$(git log -n 1000 --pretty=short --decorate
--pretty=format:%H%d $hash^@ |\
awk 'BEGIN {FS="[ ,()]*"} NF>=2 {print $1}' | head -n 25)
if [ -n "$ancestors" ] ; then
echo $hash $(git show-branch --independent $ancestors)
else
echo $hash
fi
done > $TMP
GIT_GRAFT_FILE=$TMP gitk "$@" -d
[-- Attachment #2: git-overview --]
[-- Type: application/octet-stream, Size: 806 bytes --]
#!/bin/sh
TMP=$(mktemp -t git-overview.XXXXXXXXXXX)
trap 'rm -f "$TMP"' 0 1 2 3 15
git log --reverse --pretty=short --decorate --pretty=format:%H%d $@ |\
awk 'BEGIN {FS="[ ,()]*"} NF>=2 {print $1}' | \
while read hash ; do
# Independent tags/branches parents:
# Notes:
# * -n 1000 to limit the search, ideally "git log" could stop
# traversing the history when hits a tag/branch tip
# * head -n 25 because "git show-branch --independent" has this limit
ancestors=$(git log -n 1000 --pretty=short --decorate --pretty=format:%H%d $hash^@ |\
awk 'BEGIN {FS="[ ,()]*"} NF>=2 {print $1}' | head -n 25)
if [ -n "$ancestors" ] ; then
echo $hash $(git show-branch --independent $ancestors)
else
echo $hash
fi
done > $TMP
GIT_GRAFT_FILE=$TMP gitk "$@" -d
^ permalink raw reply
* Git SVN Rebranching Issue
From: Matt Kern @ 2008-11-03 14:07 UTC (permalink / raw)
To: git
I have a git-svn issue which keeps biting me.
My company uses svn as its primary version control system. We
frequently create branches, e.g. /branches/somebranch, by forking the
trunk to ensure stability over the "somebranch" code. The problem is
that we also frequently blow away /branches/somebranch and refork it
from the trunk.
git-svn does a good job for most work, but I notice that if you delete
the "somebranch" branch in svn and then refork it, also in svn, then
when you git-svn fetch, the git commit at the head of remotes/somebranch
will have two parents: the first is the previous head of
remotes/somebranch, and the second is the head of remotes/trunk. Surely
only the remotes/trunk parent should be listed? Any connection with the
previous remotes/somebranch is an accident of naming. The real problem
then comes when you come to look at the history in gitk. If
"somebranch" is rebranched many times, the git history starts looking
pretty complicated, when in fact it should simply be the linear history
of remotes/trunk up to the branch point followed by a few,
branch-specific commits. Is there any way to prevent (or modify) the
git history to remove the errant parent?
In the ideal world, we wouldn't reuse branch names in svn, but it is
convenient and doesn't cause problems for svn users. I can't force the
rest of the company to change to accommodate my use of git...
I am using git (svn) version 1.5.6.5 (svn 1.4.6) from Debian/Lenny and
can provide a trivial repository demonstrating the problem if anyone is
interested.
Matt
--
Matt Kern
http://www.undue.org/
^ permalink raw reply
* Re: [Announce] teamGit v0.0.4
From: Abhijit Bhopatkar @ 2008-11-03 14:49 UTC (permalink / raw)
To: Ping Yin, git
In-Reply-To: <20081103134654.GA13989@kooxoo235>
On Mon, Nov 3, 2008 at 7:16 PM, Ping Yin <pkufranky@gmail.com> wrote:
> * Abhijit Bhopatkar <bain@devslashzero.com> [2008-11-03 19:05:24 +0530]:
>> teamGit is a GUI for git,
>> in its final roadmap it aims to aid small closed teams to use git,
>> currently its a pretty good frontend for basic git operations.
> Can it be used on windows?
I have just finished pushing some trivial changes to make it compile
and work on windows, I tested it with latest msysgit and it seems to
work fine, although this really is just a 5 min. test.
You will need qt 4.4.3 with mingw toolchain installed to compile this,
i do not have expertise and/or will to create a installer etc. but
patches/additions are welcome if someone can take this up.
Abhijit
^ permalink raw reply
* Re: git-cvsimport BUG: some commits are completely out of phase (but cvsps sees them all right)
From: Michael Haggerty @ 2008-11-03 14:52 UTC (permalink / raw)
To: Francis Galiegue; +Cc: tomi.pakarinen, git
In-Reply-To: <200811022331.14048.fg@one2team.net>
Francis Galiegue wrote:
> The plan would be to convert all modules in one go, with no one committing in
> the meantime, so that's not a problem.
Then you should definitely try cvs2svn/cvs2git [1]. cvsps-based
conversion tools all have known and unavoidable problems due to the
limitations of cvsps.
Michael
(the cvs2svn/cvs2git maintainer)
[1] http://cvs2svn.tigris.org/cvs2git.html
^ permalink raw reply
* Re: [Q] Abbreviated history graph?
From: Santi Béjar @ 2008-11-03 14:55 UTC (permalink / raw)
To: Brian Foster; +Cc: Git Mailing List
In-Reply-To: <adf1fd3d0811030620x1bc53db3y2afb26242e9906ac@mail.gmail.com>
On Mon, Nov 3, 2008 at 3:20 PM, Santi Béjar <santi@agolina.net> wrote:
> On Mon, Nov 3, 2008 at 2:39 PM, Brian Foster
> <brian.foster@innova-card.com> wrote:
>>
>> Hello,
>>
>> A colleague and I recently wanted to examine the
>> history in a broad sense without worrying too much
>> about the individual commits. What we (think we)
>> wanted is a 'gitk --all' history graph showing only
>> "named" historical points; i.e., tags and branch
>> HEADs, perhaps with an indication of whether or not
>> it's a "linear" change sequence that leads from one
>> to another. That is, hypothetically, if the history
>> looks something like (where 'A' &tc has a name as
>> per above, and '*' does not):
>>
>> A--->*--->*--->C--->D--->*----->E
>> \ \ /
>> \->*-->B \->*--->*--->F
>>
>> What we wanted to see is something like:
>>
>> A------>C--->D--->E
>> \ \ /
>> \->B \-----/--->F
>>
>> Is there some way of doing something similar to that
>> (git v1.6.0.2)? In addition to 'gitk', we also (rather
>> quickly!) tried both 'qgit' and 'giggle', but without
>> any apparent success.
>
> Not in git.git but you can use the script at the bottom (also attached
> in case it is whitespace damage).
> It could be much faster if "git log" stops when finding a tag/branch.
>
Just to add that it would be great if gitk's "List references" showed
them in this way (possibly with a toggle to show them in alphabetical
order).
Santi
^ permalink raw reply
* CRLF support bugs (was: Re: .gitattributes glob matching broken)
From: Hannu Koivisto @ 2008-11-03 15:05 UTC (permalink / raw)
To: git; +Cc: Jeff King
In-Reply-To: <20081103090932.GA18424@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I think your analysis is incorrect. I will try to explain what is
> happening.
Yes, you are right. The behaviour I saw in my actual use case was
so odd that I got completely confused.
I suspect one part of that "oddness" was caused by git applying its
heuristics in checkout as it doesn't use .gitattributes at that
time. For example, it seems that it recognized some of my .sh
files as text files and the rest as binary files. I suppose I was
correct to assume that it would be stupid to rely on git guessing
file type and the only sensible way is to use .gitattributes. If
it was supported in checkout too, that is.
I don't know what purpose the autodetection aims to serve but I'd
add a big warning in the core.autocrlf documentation about it and
instructions on how to configure things so that it is never applied
but instead the types must always be specified explicitly.
> The problem, again, is that we have inconsistently applied the
> gitattributes. They were _not_ applied during checkout (because
> .gitattributes did not exist yet), but they _are_ being applied here.
>
> To "fix" this, you can then do a "git reset --hard" which will respect
> your .gitattributes (since it is now checked out). And further file
> creation and checkout should work OK.
Since I'm trying to launch git in a company environment, I think I
can't rely on people remembering to do that.
Actually, even if .gitattributes were applied in checkout, I think
the whole CRLF support is broken by design because people will have
to remember to use -n in clone, then enable core.autocrlf support
and then checkout. This makes it unneccessarily complicated to
create "quick local clones" as well. You might suggest that
Windows users should enable core.autocrlf globally but it may not
be the right thing to do for all projects/repositories either.
I think CRLF conversion support should have some attribute (be it
.gitattributes attribute or something else) that is somehow
inherited from the parent repository. It would basically say that
"you should use platform's native line end type for text files with
this repository and its children". To go with that, one would
maybe have a configuration option to tell what that platform
default line end type is (just in case someone wants to pretend
Cygwin is Unix or something like that).
I also observed this problem:
# Pretend someone does this on Unix
mkdir test1
cd test1
git init
echo "*.c crlf" > .gitattributes
echo -en "foo\r\nfoo\r\nfoo\r\n" > kala.c
git add .gitattributes kala.c
git commit -m "* Initial checkin."
cd ..
# Pretend someone else does this on Windows
git clone -n test1 test2
cd test2
git config core.autocrlf true
git checkout
git status
...
# modified: kala.c
...
git reset --hard
git status
...
# modified: kala.c
...
Now, even if .gitattributes were obeyed by checkout, I suspect the end
result would be the same(?) I'm sure someone argues that this makes
sense. But try to put yourself in the position of a random Window
user. I think it's far from obvious what is going on and what
should be done in this situation.
--
Hannu
^ permalink raw reply
* Re: [PATCH] filter-branch: add git_commit_non_empty_tree and --prune-empty.
From: Pierre Habouzit @ 2008-11-03 15:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, pasky, srabbelier
In-Reply-To: <20081103092729.GE13930@artemis.corp>
[-- Attachment #1: Type: text/plain, Size: 6210 bytes --]
On Mon, Nov 03, 2008 at 09:27:29AM +0000, Pierre Habouzit wrote:
> On Mon, Nov 03, 2008 at 04:58:44AM +0000, Junio C Hamano wrote:
> > > diff --git a/t/t7003-filter-branch.sh b/t/t7003-filter-branch.sh
> > > index b0a9d7d..352b56b 100755
> > > --- a/t/t7003-filter-branch.sh
> > > +++ b/t/t7003-filter-branch.sh
> > > @@ -262,4 +262,12 @@ test_expect_success 'Tag name filtering allows slashes in tag names' '
> > > test_cmp expect actual
> > > '
> > >
> > > +test_expect_success 'Prune empty commits' '
> > > + make_commit to_remove &&
> > > + (git rev-list HEAD | grep -v $(git rev-parse HEAD)) > expect &&
> >
> > I am not sure what this one is doing.
> >
> > - Isn't this the same as "git rev-list HEAD^"?
> > - Do you need a subshell?
>
> The filter-branch is supposed to prune the last commit done (current
> HEAD) from the revision list. So I build the rev-list we're supposed to
> have in the end, and remove the matching ref from it. I don't see how to
> avoid the subshell though, but if someone knows better please do :)
Actually one can write the test this way:
test_expect_success 'Prune empty commits' '
git rev-list HEAD > expect &&
make_commit to_remove &&
git filter-branch -f --index-filter "git update-index --remove to_remove" --prune-empty HEAD &&
git rev-list HEAD > actual &&
test_cmp expect actual
'
Which basically:
- remembers the current list of revisions,
- makes a commit,
- runs an index-filter that makes that last commit void,
- checks the last commit has been removed.
below is the updated patch with your comment and this fix
---8<---
From: Pierre Habouzit <madcoder@debian.org>
Date: Fri, 31 Oct 2008 10:12:21 +0100
Subject: [PATCH] filter-branch: add git_commit_non_empty_tree and --prune-empty.
git_commit_non_empty_tree is added to the functions that can be run from
commit filters. Its effect is to commit only commits actually touching the
tree and that are not merge points either.
The option --prune-empty is added. It defaults the commit-filter to
'git_commit_non_empty_tree "$@"', and can be used with any other
combination of filters, except --commit-hook that must used
'git_commit_non_empty_tree "$@"' where one puts 'git commit-tree "$@"'
usually to achieve the same result.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
Documentation/git-filter-branch.txt | 14 ++++++++++++++
git-filter-branch.sh | 29 ++++++++++++++++++++++++++++-
t/t7003-filter-branch.sh | 8 ++++++++
3 files changed, 50 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
index fed6de6..451950b 100644
--- a/Documentation/git-filter-branch.txt
+++ b/Documentation/git-filter-branch.txt
@@ -122,6 +122,10 @@ You can use the 'map' convenience function in this filter, and other
convenience functions, too. For example, calling 'skip_commit "$@"'
will leave out the current commit (but not its changes! If you want
that, use 'git-rebase' instead).
++
+You can also use the 'git_commit_non_empty_tree "$@"' instead of
+'git commit-tree "$@"' if you don't wish to keep commits with a single parent
+and that makes no change to the tree.
--tag-name-filter <command>::
This is the filter for rewriting tag names. When passed,
@@ -151,6 +155,16 @@ to other tags will be rewritten to point to the underlying commit.
The result will contain that directory (and only that) as its
project root.
+--prune-empty::
+ Some kind of filters will generate empty commits, that left the tree
+ untouched. This switch allow git-filter-branch to ignore such
+ commits. Though, this switch only applies for commits that have one
+ and only one parent, it will hence keep merges points. Also, this
+ option is not compatible with the use of '--commit-filter'. Though you
+ just need to use the function 'git_commit_non_empty_tree "$@"' instead
+ of the 'git commit-tree "$@"' idiom in your commit filter to make that
+ happen.
+
--original <namespace>::
Use this option to set the namespace where the original commits
will be stored. The default value is 'refs/original'.
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 81392ad..331724d 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -40,6 +40,16 @@ skip_commit()
done;
}
+# if you run 'git_commit_non_empty_tree "$@"' in a commit filter,
+# it will skip commits that leave the tree untouched, commit the other.
+git_commit_non_empty_tree()
+{
+ if test $# = 3 && test "$1" = $(git rev-parse "$3^{tree}"); then
+ map "$3"
+ else
+ git commit-tree "$@"
+ fi
+}
# override die(): this version puts in an extra line break, so that
# the progress is still visible
@@ -109,11 +119,12 @@ filter_tree=
filter_index=
filter_parent=
filter_msg=cat
-filter_commit='git commit-tree "$@"'
+filter_commit=
filter_tag_name=
filter_subdir=
orig_namespace=refs/original/
force=
+prune_empty=
while :
do
case "$1" in
@@ -126,6 +137,11 @@ do
force=t
continue
;;
+ --prune-empty)
+ shift
+ prune_empty=t
+ continue
+ ;;
-*)
;;
*)
@@ -176,6 +192,17 @@ do
esac
done
+case "$prune_empty,$filter_commit" in
+,)
+ filter_commit='git commit-tree "$@"';;
+t,)
+ filter_commit="$functions;"' git_commit_non_empty_tree "$@"';;
+,*)
+ ;;
+*)
+ die "Cannot set --prune-empty and --filter-commit at the same time"
+esac
+
case "$force" in
t)
rm -rf "$tempdir"
diff --git a/t/t7003-filter-branch.sh b/t/t7003-filter-branch.sh
index b0a9d7d..8537bf9 100755
--- a/t/t7003-filter-branch.sh
+++ b/t/t7003-filter-branch.sh
@@ -262,4 +262,12 @@ test_expect_success 'Tag name filtering allows slashes in tag names' '
test_cmp expect actual
'
+test_expect_success 'Prune empty commits' '
+ git rev-list HEAD > expect &&
+ make_commit to_remove &&
+ git filter-branch -f --index-filter "git update-index --remove to_remove" --prune-empty HEAD &&
+ git rev-list HEAD > actual &&
+ test_cmp expect actual
+'
+
test_done
--
1.6.0.3.795.g892be
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply related
* Re: CRLF support bugs
From: Hannu Koivisto @ 2008-11-03 15:25 UTC (permalink / raw)
To: git; +Cc: Jeff King
In-Reply-To: <83y700alzf.fsf_-_@kalahari.s2.org>
Hannu Koivisto <azure@iki.fi> writes:
> Actually, even if .gitattributes were applied in checkout, I think
> the whole CRLF support is broken by design because people will have
> to remember to use -n in clone, then enable core.autocrlf support
> and then checkout. This makes it unneccessarily complicated to
I forgot one thing: so what if someone forgets to use -n or just
imagines that you can set core.autocrlf afterwards?
# Pretend someone does this on Unix
mkdir test1
cd test1
git init
echo "*.c crlf" > .gitattributes
echo -e "foo\nfoo\nfoo" > kala.c
git add .gitattributes kala.c
git commit -m "Initial checkin."
cd ..
# Pretend test1 is not a local repository and someone else does this on Windows
git clone test1 test2
cd test2
git config core.autocrlf true
git status
# On branch master
nothing to commit (working directory clean)
Now the user would have to know that even though git status claims
everything is ok, that is not the case. The user would have to
know to say (according to #git):
rm .git/index
git reset --hard
Just for the record, when I started to learn git, one of the first
questions I had was "how do I undo checkout?" It wasn't until now
that I learned I need to remove .git/index (in addition to all
files).
--
Hannu
^ permalink raw reply
* Re: [Q] Abbreviated history graph?
From: Brian Foster @ 2008-11-03 15:46 UTC (permalink / raw)
To: Santi Béjar; +Cc: Git Mailing List
In-Reply-To: <adf1fd3d0811030620x1bc53db3y2afb26242e9906ac@mail.gmail.com>
On Monday 03 November 2008 15:20:30 Santi Béjar wrote:
>[ ... ]
> > Is there some way of doing something similar [ the example ]
> > (git v1.6.0.2)? In addition to 'gitk', we also (rather
> > quickly!) tried both 'qgit' and 'giggle', but without
> > any apparent success.
>
> Not in git.git but you can use the script at the bottom [ ... ].
Santi,
Thanks. Unfortunately, neither I nor my colleague can try
it at the moment: It uses `git log --pretty=format:%d'
which is very new (added c.9-Sept) and not in the versions
of git we are currently using. End result is the tempfile
is always empty, and hence `gitk' shows everything.
cheers!
-blf-
--
“How many surrealists does it take to | Brian Foster
change a lightbulb? Three. One calms | somewhere in south of France
the warthog, and two fill the bathtub | Stop E$$o (ExxonMobil)!
with brightly-coloured machine tools.” | http://www.stopesso.com
^ permalink raw reply
* [PATCH - RESEND] git-cvsimport.perl: use humand readable names for options
From: Francis Galiegue @ 2008-11-03 16:00 UTC (permalink / raw)
To: git
It's not really because I've had a lack of comments :p, but because the previous patch I sent had a leftover variable that was useless in read_repo_config(). Fixed in this one.
Still welcoming comments as to option variable names, though.
----
git-cvsimport.perl: use humand readable names for options
This has required to use Getopt::Long another way, and a rewrite of the
read_repo_config() sub. The good thing with the latter is that "no strict
'refs';" has now disappeared.
---
git-cvsimport.perl | 242 ++++++++++++++++++++++++++++++++--------------------
1 files changed, 148 insertions(+), 94 deletions(-)
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index e439202..94b183a 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -29,7 +29,51 @@ use IPC::Open2;
$SIG{'PIPE'}="IGNORE";
$ENV{'TZ'}="UTC";
-our ($opt_h,$opt_o,$opt_v,$opt_k,$opt_u,$opt_d,$opt_p,$opt_C,$opt_z,$opt_i,$opt_P, $opt_s,$opt_m,@opt_M,$opt_A,$opt_S,$opt_L, $opt_a, $opt_r);
+#
+# Option values
+#
+my $help = undef; # -h
+my $branch_for_head = undef; # -o
+my $verbose = undef; # -v
+my $cvs_kill_keywords = undef; # -k
+my $convert_underscores = undef; # -u
+my $cvsroot = undef; # -d
+my $cvsps_options = undef; # -p
+my $git_repos_root = undef; # -C
+my $cvsps_fuzz = undef; # -z
+my $import_only = undef; # -i
+my $cvsps_output_file = undef; # -P
+my $branch_subst = undef, # -s
+my $detect_merges = undef; # -m
+my @more_merge_regexes = (); # -M
+my $author_conv_file = undef; # -A
+my $skip_paths = undef; # -S
+my $commit_limits = undef; # -L
+my $all_commits = undef; # -a
+my $remote_path = undef; # -r
+
+my %options = (
+ "h" => \$help,
+ "o=s" => \$branch_for_head,
+ "v" => \$verbose,
+ "k" => \$cvs_kill_keywords,
+ "u" => \$convert_underscores,
+ "d=s" => \$cvsroot,
+ "p=s" => \$cvsps_options,
+ "C=s" => \$git_repos_root,
+ "z=s" => \$cvsps_fuzz,
+ "i" => \$import_only,
+ "P=s" => \$cvsps_output_file,
+ "s=s" => \$branch_subst,
+ "m" => \$detect_merges,
+ "M=s" => \@more_merge_regexes,
+ "A=s" => \$author_conv_file,
+ "S=s" => \$skip_paths,
+ "L=s" => \$commit_limits,
+ "a" => \$all_commits,
+ "r=s" => \$remote_path
+);
+
my (%conv_author_name, %conv_author_email);
sub usage(;$) {
@@ -88,37 +132,46 @@ sub write_author_info($) {
close ($f);
}
-# convert getopts specs for use by git config
-sub read_repo_config {
- # Split the string between characters, unless there is a ':'
- # So "abc:de" becomes ["a", "b", "c:", "d", "e"]
- my @opts = split(/ *(?!:)/, shift);
- foreach my $o (@opts) {
- my $key = $o;
- $key =~ s/://g;
- my $arg = 'git config';
- $arg .= ' --bool' if ($o !~ /:$/);
-
- chomp(my $tmp = `$arg --get cvsimport.$key`);
- if ($tmp && !($arg =~ /--bool/ && $tmp eq 'false')) {
- no strict 'refs';
- my $opt_name = "opt_" . $key;
- if (!$$opt_name) {
- $$opt_name = $tmp;
- }
+sub read_repo_config ()
+{
+ while (my ($opt, $ref) = each %options) {
+ my $key = $opt;
+ my $is_boolean = 0;
+ my $cmd = "git config";
+ unless ($key =~ s/=s$//) {
+ $is_boolean = 1;
+ $cmd .= " --bool";
+ }
+ $cmd .= " cvsimport.$key";
+
+ chomp(my $tmp = qx/$cmd/);
+ $tmp or next;
+
+ if (ref($ref) eq "ARRAY") {
+ #
+ # FIXME: unhandled...
+ # However this could be handled by splitting $tmp with
+ # /\s*,\s*/ and pusing the result into @$ref (for the -M
+ # option)
+ #
+ next;
+ }
+
+ if ($is_boolean) {
+ $$ref = ("$tmp" eq "true") ? 1 : 0;
+ } else {
+ $$ref = "$tmp";
}
}
}
-my $opts = "haivmkuo:d:p:r:C:z:s:M:P:A:S:L:";
-read_repo_config($opts);
+
+read_repo_config();
Getopt::Long::Configure( 'no_ignore_case', 'bundling' );
-# turn the Getopt::Std specification in a Getopt::Long one,
-# with support for multiple -M options
-GetOptions( map { s/:/=s/; /M/ ? "$_\@" : $_ } split( /(?!:)/, $opts ) )
- or usage();
-usage if $opt_h;
+GetOptions(%options) or usage();
+
+usage() if $help;
if (@ARGV == 0) {
chomp(my $module = `git config --get cvsimport.module`);
@@ -126,31 +179,32 @@ if (@ARGV == 0) {
}
@ARGV <= 1 or usage("You can't specify more than one CVS module");
-if ($opt_d) {
- $ENV{"CVSROOT"} = $opt_d;
+if ($cvsroot) {
+ $ENV{"CVSROOT"} = $cvsroot;
} elsif (-f 'CVS/Root') {
open my $f, '<', 'CVS/Root' or die 'Failed to open CVS/Root';
- $opt_d = <$f>;
- chomp $opt_d;
+ $cvsroot = <$f>;
+ chomp $cvsroot;
close $f;
- $ENV{"CVSROOT"} = $opt_d;
+ $ENV{"CVSROOT"} = $cvsroot;
} elsif ($ENV{"CVSROOT"}) {
- $opt_d = $ENV{"CVSROOT"};
+ $cvsroot = $ENV{"CVSROOT"};
} else {
usage("CVSROOT needs to be set");
}
-$opt_s ||= "-";
-$opt_a ||= 0;
+$branch_subst ||= "-";
+$all_commits ||= 0;
-my $git_tree = $opt_C;
+my $git_tree = $git_repos_root;
$git_tree ||= ".";
my $remote;
-if (defined $opt_r) {
- $remote = 'refs/remotes/' . $opt_r;
- $opt_o ||= "master";
+
+if (defined $remote_path) {
+ $remote = 'refs/remotes/' . $remote_path;
+ $branch_for_head ||= "master";
} else {
- $opt_o ||= "origin";
+ $branch_for_head ||= "origin";
$remote = 'refs/heads';
}
@@ -168,11 +222,11 @@ if ($#ARGV == 0) {
}
our @mergerx = ();
-if ($opt_m) {
+if ($detect_merges) {
@mergerx = ( qr/\b(?:from|of|merge|merging|merged) ([-\w]+)/i );
}
-if (@opt_M) {
- push (@mergerx, map { qr/$_/ } @opt_M);
+if (@more_merge_regexes) {
+ push (@mergerx, map { qr/$_/ } @more_merge_regexes);
}
# Remember UTC of our starting time
@@ -370,7 +424,7 @@ sub _file {
$self->{'socketo'}->write("Argument -N\n") or return undef;
$self->{'socketo'}->write("Argument -P\n") or return undef;
# -kk: Linus' version doesn't use it - defaults to off
- if ($opt_k) {
+ if ($cvs_kill_keywords) {
$self->{'socketo'}->write("Argument -kk\n") or return undef;
}
$self->{'socketo'}->write("Argument -r\n") or return undef;
@@ -487,7 +541,7 @@ sub _fetchfile {
package main;
-my $cvs = CVSconn->new($opt_d, $cvs_tree);
+my $cvs = CVSconn->new($cvsroot, $cvs_tree);
sub pdate($) {
@@ -565,7 +619,7 @@ unless (-d $git_dir) {
system("git-read-tree");
die "Cannot init an empty tree: $?\n" if $?;
- $last_branch = $opt_o;
+ $last_branch = $branch_for_head;
$orig_branch = "";
} else {
open(F, "git-symbolic-ref HEAD |") or
@@ -592,8 +646,8 @@ unless (-d $git_dir) {
$branch_date{$head} = $1;
}
close(H);
- if (!exists $branch_date{$opt_o}) {
- die "Branch '$opt_o' does not exist.\n".
+ if (!exists $branch_date{$branch_for_head}) {
+ die "Branch '$branch_for_head' does not exist.\n".
"Either use the correct '-o branch' option,\n".
"or import to a new repository.\n";
}
@@ -605,31 +659,31 @@ unless (-d $git_dir) {
# now we read (and possibly save) author-info as well
-f "$git_dir/cvs-authors" and
read_author_info("$git_dir/cvs-authors");
-if ($opt_A) {
- read_author_info($opt_A);
+if ($author_conv_file) {
+ read_author_info($author_conv_file);
write_author_info("$git_dir/cvs-authors");
}
#
# run cvsps into a file unless we are getting
-# it passed as a file via $opt_P
+# it passed as a file via $cvsps_output_file
#
my $cvspsfile;
-unless ($opt_P) {
- print "Running cvsps...\n" if $opt_v;
+unless ($cvsps_output_file) {
+ print "Running cvsps...\n" if $verbose;
my $pid = open(CVSPS,"-|");
my $cvspsfh;
die "Cannot fork: $!\n" unless defined $pid;
unless ($pid) {
my @opt;
- @opt = split(/,/,$opt_p) if defined $opt_p;
- unshift @opt, '-z', $opt_z if defined $opt_z;
- unshift @opt, '-q' unless defined $opt_v;
- unless (defined($opt_p) && $opt_p =~ m/--no-cvs-direct/) {
+ @opt = split(/,/,$cvsps_options) if defined $cvsps_options;
+ unshift @opt, '-z', $cvsps_fuzz if defined $cvsps_fuzz;
+ unshift @opt, '-q' unless defined $verbose;
+ unless (defined($cvsps_options) && $cvsps_options =~ m/--no-cvs-direct/) {
push @opt, '--cvs-direct';
}
- exec("cvsps","--norc",@opt,"-u","-A",'--root',$opt_d,$cvs_tree);
+ exec("cvsps","--norc",@opt,"-u","-A",'--root',$cvsroot,$cvs_tree);
die "Could not start cvsps: $!\n";
}
($cvspsfh, $cvspsfile) = tempfile('gitXXXXXX', SUFFIX => '.cvsps',
@@ -641,7 +695,7 @@ unless ($opt_P) {
$? == 0 or die "git-cvsimport: fatal: cvsps reported error\n";
close $cvspsfh;
} else {
- $cvspsfile = $opt_P;
+ $cvspsfile = $cvsps_output_file;
}
open(CVS, "<$cvspsfile") or die $!;
@@ -688,7 +742,7 @@ sub write_tree () {
or die "Cannot get tree id ($tree): $!";
close($fh)
or die "Error running git-write-tree: $?\n";
- print "Tree ID $tree\n" if $opt_v;
+ print "Tree ID $tree\n" if $verbose;
return $tree;
}
@@ -699,7 +753,7 @@ my (@old,@new,@skipped,%ignorebranch);
$ignorebranch{'#CVSPS_NO_BRANCH'} = 1;
sub commit {
- if ($branch eq $opt_o && !$index{branch} &&
+ if ($branch eq $branch_for_head && !$index{branch} &&
!get_headref("$remote/$branch")) {
# looks like an initial commit
# use the index primed by git-init
@@ -725,7 +779,7 @@ sub commit {
@old = @new = ();
my $tree = write_tree();
my $parent = get_headref("$remote/$last_branch");
- print "Parent ID " . ($parent ? $parent : "(empty)") . "\n" if $opt_v;
+ print "Parent ID " . ($parent ? $parent : "(empty)") . "\n" if $verbose;
my @commit_args;
push @commit_args, ("-p", $parent) if $parent;
@@ -734,10 +788,10 @@ sub commit {
# based on the commit msg
foreach my $rx (@mergerx) {
next unless $logmsg =~ $rx && $1;
- my $mparent = $1 eq 'HEAD' ? $opt_o : $1;
+ my $mparent = $1 eq 'HEAD' ? $branch_for_head : $1;
if (my $sha1 = get_headref("$remote/$mparent")) {
push @commit_args, '-p', "$remote/$mparent";
- print "Merge parent branch: $mparent\n" if $opt_v;
+ print "Merge parent branch: $mparent\n" if $verbose;
}
}
@@ -764,10 +818,10 @@ sub commit {
print($commit_write "$logmsg\n") && close($commit_write)
or die "Error writing to git-commit-tree: $!\n";
- print "Committed patch $patchset ($branch $commit_date)\n" if $opt_v;
+ print "Committed patch $patchset ($branch $commit_date)\n" if $verbose;
chomp(my $cid = <$commit_read>);
is_sha1($cid) or die "Cannot get commit id ($cid): $!\n";
- print "Commit ID $cid\n" if $opt_v;
+ print "Commit ID $cid\n" if $verbose;
close($commit_read);
waitpid($pid,0);
@@ -779,14 +833,14 @@ sub commit {
if ($tag) {
my ($xtag) = $tag;
$xtag =~ s/\s+\*\*.*$//; # Remove stuff like ** INVALID ** and ** FUNKY **
- $xtag =~ tr/_/\./ if ( $opt_u );
- $xtag =~ s/[\/]/$opt_s/g;
+ $xtag =~ tr/_/\./ if ( $convert_underscores );
+ $xtag =~ s/[\/]/$branch_subst/g;
$xtag =~ s/\[//g;
system('git-tag', '-f', $xtag, $cid) == 0
or die "Cannot create tag $xtag: $!\n";
- print "Created tag '$xtag' on '$branch'\n" if $opt_v;
+ print "Created tag '$xtag' on '$branch'\n" if $verbose;
}
};
@@ -822,14 +876,14 @@ while (<CVS>) {
$state = 4;
} elsif ($state == 4 and s/^Branch:\s+//) {
s/\s+$//;
- tr/_/\./ if ( $opt_u );
- s/[\/]/$opt_s/g;
+ tr/_/\./ if ( $convert_underscores );
+ s/[\/]/$branch_subst/g;
$branch = $_;
$state = 5;
} elsif ($state == 5 and s/^Ancestor branch:\s+//) {
s/\s+$//;
$ancestor = $_;
- $ancestor = $opt_o if $ancestor eq "HEAD";
+ $ancestor = $branch_for_head if $ancestor eq "HEAD";
$state = 6;
} elsif ($state == 5) {
$ancestor = undef;
@@ -847,19 +901,19 @@ while (<CVS>) {
$logmsg = "";
$state = 8;
} elsif ($state == 8 and /^Members:/) {
- $branch = $opt_o if $branch eq "HEAD";
+ $branch = $branch_for_head if $branch eq "HEAD";
if (defined $branch_date{$branch} and $branch_date{$branch} >= $date) {
# skip
- print "skip patchset $patchset: $date before $branch_date{$branch}\n" if $opt_v;
+ print "skip patchset $patchset: $date before $branch_date{$branch}\n" if $verbose;
$state = 11;
next;
}
- if (!$opt_a && $starttime - 300 - (defined $opt_z ? $opt_z : 300) <= $date) {
+ if (!$all_commits && $starttime - 300 - (defined $cvsps_fuzz ? $cvsps_fuzz : 300) <= $date) {
# skip if the commit is too recent
# given that the cvsps default fuzz is 300s, we give ourselves another
# 300s just in case -- this also prevents skipping commits
# due to server clock drift
- print "skip patchset $patchset: $date too recent\n" if $opt_v;
+ print "skip patchset $patchset: $date too recent\n" if $verbose;
$state = 11;
next;
}
@@ -870,8 +924,8 @@ while (<CVS>) {
}
if ($ancestor) {
if ($ancestor eq $branch) {
- print STDERR "Branch $branch erroneously stems from itself -- changed ancestor to $opt_o\n";
- $ancestor = $opt_o;
+ print STDERR "Branch $branch erroneously stems from itself -- changed ancestor to $branch_for_head\n";
+ $ancestor = $branch_for_head;
}
if (defined get_headref("$remote/$branch")) {
print STDERR "Branch $branch already exists!\n";
@@ -905,18 +959,18 @@ while (<CVS>) {
my $fn = $1;
my $rev = $3;
$fn =~ s#^/+##;
- if ($opt_S && $fn =~ m/$opt_S/) {
+ if ($skip_paths && $fn =~ m/$skip_paths/) {
print "SKIPPING $fn v $rev\n";
push(@skipped, $fn);
next;
}
- print "Fetching $fn v $rev\n" if $opt_v;
+ print "Fetching $fn v $rev\n" if $verbose;
my ($tmpname, $size) = $cvs->file($fn,$rev);
if ($size == -1) {
push(@old,$fn);
- print "Drop $fn\n" if $opt_v;
+ print "Drop $fn\n" if $verbose;
} else {
- print "".($init ? "New" : "Update")." $fn: $size bytes\n" if $opt_v;
+ print "".($init ? "New" : "Update")." $fn: $size bytes\n" if $verbose;
my $pid = open(my $F, '-|');
die $! unless defined $pid;
if (!$pid) {
@@ -934,12 +988,12 @@ while (<CVS>) {
my $fn = $1;
$fn =~ s#^/+##;
push(@old,$fn);
- print "Delete $fn\n" if $opt_v;
+ print "Delete $fn\n" if $verbose;
} elsif ($state == 9 and /^\s*$/) {
$state = 10;
} elsif (($state == 9 or $state == 10) and /^-+$/) {
$commitcount++;
- if ($opt_L && $commitcount > $opt_L) {
+ if ($commit_limits && $commitcount > $commit_limits) {
last;
}
commit();
@@ -957,7 +1011,7 @@ while (<CVS>) {
}
commit() if $branch and $state != 11;
-unless ($opt_P) {
+unless ($cvsps_output_file) {
unlink($cvspsfile);
}
@@ -985,31 +1039,31 @@ if (defined $orig_git_index) {
# Now switch back to the branch we were in before all of this happened
if ($orig_branch) {
- print "DONE.\n" if $opt_v;
- if ($opt_i) {
+ print "DONE.\n" if $verbose;
+ if ($import_only) {
exit 0;
}
my $tip_at_end = `git-rev-parse --verify HEAD`;
if ($tip_at_start ne $tip_at_end) {
for ($tip_at_start, $tip_at_end) { chomp; }
- print "Fetched into the current branch.\n" if $opt_v;
+ print "Fetched into the current branch.\n" if $verbose;
system(qw(git-read-tree -u -m),
$tip_at_start, $tip_at_end);
die "Fast-forward update failed: $?\n" if $?;
}
else {
- system(qw(git-merge cvsimport HEAD), "$remote/$opt_o");
- die "Could not merge $opt_o into the current branch.\n" if $?;
+ system(qw(git-merge cvsimport HEAD), "$remote/$branch_for_head");
+ die "Could not merge $branch_for_head into the current branch.\n" if $?;
}
} else {
$orig_branch = "master";
- print "DONE; creating $orig_branch branch\n" if $opt_v;
- system("git-update-ref", "refs/heads/master", "$remote/$opt_o")
+ print "DONE; creating $orig_branch branch\n" if $verbose;
+ system("git-update-ref", "refs/heads/master", "$remote/$branch_for_head")
unless defined get_headref('refs/heads/master');
- system("git-symbolic-ref", "$remote/HEAD", "$remote/$opt_o")
- if ($opt_r && $opt_o ne 'HEAD');
+ system("git-symbolic-ref", "$remote/HEAD", "$remote/$branch_for_head")
+ if ($remote_path && $branch_for_head ne 'HEAD');
system('git-update-ref', 'HEAD', "$orig_branch");
- unless ($opt_i) {
+ unless ($import_only) {
system('git checkout -f');
die "checkout failed: $?\n" if $?;
}
--
1.6.0.3
--
fge
^ permalink raw reply related
* Re: [Q] Abbreviated history graph?
From: Santi Béjar @ 2008-11-03 16:08 UTC (permalink / raw)
To: Brian Foster; +Cc: Git Mailing List
In-Reply-To: <200811031646.20404.brian.foster@innova-card.com>
On Mon, Nov 3, 2008 at 4:46 PM, Brian Foster
<brian.foster@innova-card.com> wrote:
> On Monday 03 November 2008 15:20:30 Santi Béjar wrote:
>>[ ... ]
>> > Is there some way of doing something similar [ the example ]
>> > (git v1.6.0.2)? In addition to 'gitk', we also (rather
>> > quickly!) tried both 'qgit' and 'giggle', but without
>> > any apparent success.
>>
>> Not in git.git but you can use the script at the bottom [ ... ].
>
> Santi,
>
> Thanks. Unfortunately, neither I nor my colleague can try
> it at the moment: It uses `git log --pretty=format:%d'
> which is very new (added c.9-Sept) and not in the versions
> of git we are currently using. End result is the tempfile
> is always empty, and hence `gitk' shows everything.
Ups! So you could get the same information with the uglier (and slower):
$ git log --reverse --pretty=short --decorate | grep ^commit
but then you should change "NF>=2" with "NF>=3", or use an older one I
sent to the list (search for git-overview).
Santi
^ permalink raw reply
* Re: [PATCH 1/3] packed_git: convert pack_local flag into generic bit mask
From: Shawn O. Pearce @ 2008-11-03 16:12 UTC (permalink / raw)
To: drafnel; +Cc: git, gitster, nico
In-Reply-To: <6141358.1225643400587.JavaMail.teamon@b303.teamon.com>
drafnel@gmail.com wrote:
> This is in preparation for adding a flag indicating whether a .keep file is
> present.
Good idea.
> diff --git a/cache.h b/cache.h
> index b0edbf9..0cb9350 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -679,12 +679,15 @@ extern struct packed_git {
> int index_version;
> time_t mtime;
> int pack_fd;
> - int pack_local;
> + unsigned int flags;
Hmm, isn't this a smaller change to make?
- int pack_local;
+ unsigned pack_local:1;
Then later you can do:
- unsigned pack_local:1;
+ unsigned pack_local:1,
+ pack_keep:1;
and the compiler handles all the bitmask stuff for you?
In general in git.git we like to use the struct bitmask stuff when
possible as the code is easier to follow. We only use explicit
mask constants and mask operations when the data is being stored
on disk or written over the network and we need to ensure it is
consistent across compilers. But for in-core only stuff, struct
bitmasks are easier.
--
Shawn.
^ 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