* Re: mtimes of working files
From: J. Bruce Fields @ 2007-07-14 0:44 UTC (permalink / raw)
To: David Woodhouse
Cc: Linus Torvalds, Theodore Tso, Andy Parkins, git, Jan Hudec,
Johannes Schindelin
In-Reply-To: <1184373393.2785.99.camel@shinybook.infradead.org>
On Sat, Jul 14, 2007 at 01:36:33AM +0100, David Woodhouse wrote:
> Yeah, much of it. Although I've also seen other people trying to get to
> grips with git and tripping up over branches recently.
Could you give any details? What specifically was it they were having
trouble with?
--b.
^ permalink raw reply
* Re: [PATCH] More permissive "git-rm --cached" behavior without -f.
From: Jakub Narebski @ 2007-07-14 0:44 UTC (permalink / raw)
To: git
In-Reply-To: <11843484982037-git-send-email-Matthieu.Moy@imag.fr>
Matthieu Moy wrote:
> In the previous behavior, "git-rm --cached" (without -f) had the same
> restriction as "git-rm". This forced the user to use the -f flag in
> situations which weren't actually dangerous, like:
>
> $ git add foo # oops, I didn't want this
> $ git rm --cached foo # back to initial situation
>
> Previously, the index had to match the file *and* the HEAD. With
> --cached, the index must now match the file *or* the HEAD. The behavior
> without --cached is unchanged, but provides better error messages.
Sensible.
There might be some discussion if what git-rm without --cached does
is right, but that is besides scope of this patch.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: mtimes of working files
From: David Woodhouse @ 2007-07-14 0:36 UTC (permalink / raw)
To: Linus Torvalds
Cc: Theodore Tso, Andy Parkins, git, Jan Hudec, Johannes Schindelin
In-Reply-To: <alpine.LFD.0.999.0707131704000.20061@woody.linux-foundation.org>
On Fri, 2007-07-13 at 17:10 -0700, Linus Torvalds wrote:
>
> On Sat, 14 Jul 2007, David Woodhouse wrote:
> >
> > On the occasions I actually try to _use_ branches, I find it very
> > suboptimal.
>
> This seems to be very personal.
Yeah, much of it. Although I've also seen other people trying to get to
grips with git and tripping up over branches recently. It _was_ getting
easier, for a while :)
> But I literally tend to just use branches for something small. I don't
> personally tend to have any long-term live branches (apart from the remove
> ones, obviously). I create a branch, do something in it, merge it, and
> go back to master.
I don't usually bother with that. I just do something in HEAD and then
reset (possibly after pushing it to some tree elsewhere for posterity).
> I don't even use ccache, and I don't care. Probably because most of the
> time the rebuild time really isn't that long for me, and for the kernel,
> the much more painful part is actually the rebooting part.
I can usually find some other machine to reboot than the machine I'm
working on. Don't these people send you enough toys? :)
I've also spent most of the last year travelling and hence working on my
laptop, which isn't the beefiest build machine I've ever had the
pleasure of using. Changing branches, when I've done it, really has been
a pain.
> But the place where branches *really* rock is when you don't even switch
> to them, but use the data from them locally (cherry-picking from them,
> or doing something like "git show origin/pu:builtin-blame.c" etc).
You can achieve much of that just by sharing object directories, and
I'll admit that sometimes I do set up temporary branches just for the
purpose of cherry-picking by name ('foo^^' etc.) without having to paste
sha1sums from the other tree.
> And for that to work, you have to get used to having multiple branches in
> the tree, even if you don't check them out - and once you do that,
> switching between them isn't really that confusing any more, because it's
> already part of your "mind map" of how the repo works.
I'm sure it's true that if I persist I'll get used to it, as will the
newbies who have trouble with branches. But mostly I suspect that I'll
get used to it by learning how best to work around it and keep separate
trees of my own, even when people persist in having multiple branches on
their servers. And while today's set of newbies will get used to it,
tomorrow's set of newbies will also find it troubling.
Nothing really prevents you from using branches _locally_ if you want
to, but still keeping separate trees on the _servers_. I just think that
might be a more cunning way forward. But as you correctly point out,
that's just my personal viewpoint.
--
dwmw2
^ permalink raw reply
* Re: [PATCH 3/4] --decorate now decorates ancestors, too
From: Johannes Schindelin @ 2007-07-14 0:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Theodore Tso, git
In-Reply-To: <7vmyy1tq96.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 12 Jul 2007, Junio C Hamano wrote:
> Theodore Tso <tytso@mit.edu> writes:
>
> > On Wed, Jul 11, 2007 at 02:29:49AM +0100, Johannes Schindelin wrote:
> >>
> >> The option --decorate changed default behavior: Earlier, it decorated
> >> commits pointed to by any ref. The new behavior is this: decorate the
> >> with the given refs and its ancestors, i.e.
> >>
> >> git log --decorate next master
> >>
> >> will show "next", "next^", "next~2", ..., "master", "master^", ...
> >> in parenthesis after the commit name.
> >
> > I'm wondering how useful the default is. The arguments get used for
> > two things; both for git-log to decide what revisions to display, and
> > which refs to decorate, right? I'm not sure that overloading is such
> > a great idea.
> >
> > Also, I note that "git log --decorate" does nothing at all. Maybe it
> > would be better to keep the default to be "any-ref" instead of "given"?
>
> I think defaulting to "given" is a regression. It could be
> argued that "tag-ref" or "tag" might be a better default
> (judging from my experience with "name-rev"), but keeping
> "any-ref" would probably be the safest.
Okay, fair enough. I kind of expected people to disagree as of the
default mode. My preference would have been "tag", since I need that
quite often, but I am willing to put my wishes aside there.
Probably I should follow up with a replacement patch, and a config
variable "commit.decorateMode" patch, leaving the default at "any-ref"?
> But in general I do not see ("I haven't realized" might turn out to be a
> better expression) much value in this series yet except for the initial
> clean-up patches, while I think this option would be quite expensive in
> terms of memory footprints on projects with nontrivial size of history.
> I dunno.
There are a few points I want to make to convince you:
- I need this quite often to see which version introduced a certain
feature. This is most visible on IRC, where people ask "how can I do X,
I have version Y", and me responding "There is a feature P, but
unfortunately, it is only available from revision Q~N" where Q > Y.
I really want other people to do this easily, without having to know how
name-rev (which has a dash in its name, and thus is kind of
plumbing-ish) works.
- It is _not_ expensive. It only ever allocates something in the case of
merges (at least that's how I designed it), and should free the used
memory when the commit name is not used at all (but maybe I forgot that
part...). So you will have at most one allocation of a few bytes per
merge, and I really do not see how this could break down for
pathological, but real-world, cases.
- 40-character commit names seem to be really hard on people.
To drive the 3rd point home: I often see people confused as to what those
long commit names are. They do not even realise that they are _object_
names, actually, not only applicable to commit objects.
IMHO a great way to teach users that commit names are equivalent to
shortcuts like "v1.5.0-rc1~20" would be to even enable decoration by tags
by default.
Ciao,
Dscho
^ permalink raw reply
* Re: mtimes of working files
From: Linus Torvalds @ 2007-07-14 0:10 UTC (permalink / raw)
To: David Woodhouse
Cc: Theodore Tso, Andy Parkins, git, Jan Hudec, Johannes Schindelin
In-Reply-To: <1184370414.2785.79.camel@shinybook.infradead.org>
On Sat, 14 Jul 2007, David Woodhouse wrote:
>
> On the occasions I actually try to _use_ branches, I find it very
> suboptimal.
This seems to be very personal.
I tend to use just temporary branches, but I love just going on another
branch, fixing something up, and working on that without having to set up
a whole new tree. It's *much* faster to just switch branches than to do
even a local clone, because I usually would work on something that is
pretty close to the HEAD anyway, so the cost of rewriting a few hundred
files is much less than checking out the 22,000 files all over again.
But I literally tend to just use branches for something small. I don't
personally tend to have any long-term live branches (apart from the remove
ones, obviously). I create a branch, do something in it, merge it, and
go back to master.
The last example of this for me was just re-doing a pull by Ingo, because
he had created some really strange commit in his tree, so I fetched his
stuff, re-created his branch locally without the thing, and then merged
it. And then I just deleted the branch.
> But having to rebuild (even with ccache) after changing branches is a
> PITA.
I don't even use ccache, and I don't care. Probably because most of the
time the rebuild time really isn't that long for me, and for the kernel,
the much more painful part is actually the rebooting part.
But the place where branches *really* rock is when you don't even switch
to them, but use the data from them locally (cherry-picking from them,
or doing something like "git show origin/pu:builtin-blame.c" etc).
And for that to work, you have to get used to having multiple branches in
the tree, even if you don't check them out - and once you do that,
switching between them isn't really that confusing any more, because it's
already part of your "mind map" of how the repo works.
Linus
^ permalink raw reply
* Re: CVS -> SVN -> Git
From: Michael Haggerty @ 2007-07-13 23:03 UTC (permalink / raw)
To: Julian Phillips; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707131541140.11423@reaper.quantumfyre.co.uk>
Julian Phillips wrote:
> Has anyone managed to succssfully import a Subversion repository that
> was initially imported from CVS using cvs2svn using fast-import?
>
> It looks like cvs2svn has created a rather big mess. It has created
> single commits that change files in more than one branch and/or tag. It
> also creates tags using more than one commit. Now I come to try and
> import the Subversion history into git and I'm having trouble creating a
> sensible stream to feed into fast-import.
I'm the main cvs2svn developer. Obviously, the tool is intended to
convert to Subversion, but there are ways to tune it to make its output
a little bit more git-friendly.
[Please note that both CVS and SVN allow changes to multiple
tags/branches in a single commit and creating tags using more than one
commit. That is why cvs2svn converts these repository "features" 1:1 by
default.]
Release 2.0.0-rc1 of cvs2svn (released today) has a
--no-cross-branch-commits option that prevents commits that affect more
than one branch. For multiproject conversions, the
"ctx.cross_project_commits" option might also be useful. (The latter is
only available if you start cvs2svn with an --options file.)
The new cvs2svn release is also more intelligent about determining the
most likely source branch from which a tag/branch was created. This
does not eliminate the creation of tags from more than one revision, but
it should reduce its frequency. If your repository uses any vendor
branches, you might also consider --exclude'ing them. In the new
cvs2svn version, this causes vendor revisions to be grafted onto trunk
and thereby eliminates another common cause of multiple-source
branches/tags.
Incidentally, now that cvs2svn 2.0.0 is nearly out, I am thinking about
what it would take to write some other back ends for cvs2svn--turning
it, essentially, into cvs2xxx. Most of the work that cvs2svn does is
inferring the most plausible history of the repository from CVS's
sketchy, incomplete, idiomatic, and often corrupt data. This work
should also be useful for a cvs2git or cvs2hg or cvs2baz or ...
I haven't played with a distributed SCM yet, but if somebody would be
interested in working with me on this please let me know.
Michael
^ permalink raw reply
* Re: mtimes of working files
From: David Woodhouse @ 2007-07-13 23:46 UTC (permalink / raw)
To: Linus Torvalds
Cc: Theodore Tso, Andy Parkins, git, Jan Hudec, Johannes Schindelin
In-Reply-To: <alpine.LFD.0.999.0707131617270.20061@woody.linux-foundation.org>
On Fri, 2007-07-13 at 16:18 -0700, Linus Torvalds wrote:
> Why would anybody force you to do that?
>
> The "switch between branchs in the same repo" is really convenient.
> But nobody *forces* you to do it.
This is true. I already mirror a bunch of CVS and SVN repositories into
git so that I can use them without too much pain¹, and I can do the same
for git trees which use branches too; mirroring them into a bunch of
separate trees for easy access.
On the occasions I actually try to _use_ branches, I find it very
suboptimal. Perhaps it's just because I'm stupid. I'm sure that's why I
ended up committing changes to the wrong branch. But having to rebuild
(even with ccache) after changing branches is a PITA. Just changing
branches at all is a PITA if you have uncommitted changes (which I
usually do because I've usually tested _some_ random patch in a build
tree for the hardware which is closest to hand). Pulling a whole bunch
of unwanted changes on the 'development' branch while on GPRS, when all
I really needed was a single commit from the 'stable' branch also didn't
amuse me, although I'm sure if I had the time to play with it I'd have
been able to avoid that.
I can, and do, mirror stuff from all kinds of suboptimal version control
systems into single-branch git trees. And I include multi-branched git
trees in my definition of 'suboptimal'. My ability to do that doesn't
really help the newbies who are expected with branches, though.
I just wish people would make stuff available on the _servers_ in
separate trees rather than in branches -- if some people prefer branches
locally then that's their option; at the moment we kind of force people
into it. They _could_ avoid it but they'd have to know what they're
doing.
But I didn't really mean to start an argument; it's just my opinion.
--
dwmw2
¹ and I'd do the same for Hg if I could get hg2git to work.
^ permalink raw reply
* Re: mtimes of working files
From: Linus Torvalds @ 2007-07-13 23:18 UTC (permalink / raw)
To: David Woodhouse
Cc: Theodore Tso, Andy Parkins, git, Jan Hudec, Johannes Schindelin
In-Reply-To: <1184367619.2785.58.camel@shinybook.infradead.org>
On Sat, 14 Jul 2007, David Woodhouse wrote:
>
> Branches just seem like a source of complexity and hence pain. Using git
> was just starting to become sensible for newbies, and now when people
> are forced to deal with multiple branches it's all horribly painful
> again.
Why would anybody force you to do that?
The "switch between branchs in the same repo" is really convenient. But
nobody *forces* you to do it.
Linus
^ permalink raw reply
* kernel.org needs gitweb help
From: H. Peter Anvin @ 2007-07-13 23:12 UTC (permalink / raw)
To: Linux Kernel Mailing List, Git Mailing List; +Cc: J.H.
Hi all,
A lot of people have asked me if there is anything they can do to help
out kernel.org. At this point, the number one thing anyone could do to
help, and which would be reasonably self-contained a project, would be
to help maintain our fork of gitweb:
http://git.kernel.org/?p=git/warthog9/gitweb.git;a=summary
We really need the caching version of gitweb, but it does have a number
of problems, including the non-working tarball generator.
-hpa
^ permalink raw reply
* [PATCH] Support output ISO 8601 format dates
From: Robin Rosenberg @ 2007-07-13 23:00 UTC (permalink / raw)
To: junkio; +Cc: git
In-Reply-To: <7vy7hklzsf.fsf@assigned-by-dhcp.cox.net>
Support output of full ISO 8601 style dates in e.g. git log
and other places that use interpolation for formatting.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
Updated docs too. The show --date is not included because I didn't know
about it.
Documentation/pretty-formats.txt | 2 ++
cache.h | 2 +-
commit.c | 6 +++++-
date.c | 7 +++++++
4 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index d922e8e..1296b31 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -106,12 +106,14 @@ The placeholders are:
- '%aD': author date, RFC2822 style
- '%ar': author date, relative
- '%at': author date, UNIX timestamp
+- '%ai': author date, ISO 8601 format
- '%cn': committer name
- '%ce': committer email
- '%cd': committer date
- '%cD': committer date, RFC2822 style
- '%cr': committer date, relative
- '%ct': committer date, UNIX timestamp
+- '%ci': committer date, ISO 8601 format
- '%e': encoding
- '%s': subject
- '%b': body
diff --git a/cache.h b/cache.h
index 5dff2f1..3dc0def 100644
--- a/cache.h
+++ b/cache.h
@@ -389,7 +389,7 @@ extern void *read_object_with_reference(const unsigned char *sha1,
unsigned long *size,
unsigned char *sha1_ret);
-enum date_mode { DATE_NORMAL = 0, DATE_RELATIVE, DATE_SHORT, DATE_LOCAL };
+enum date_mode { DATE_NORMAL = 0, DATE_RELATIVE, DATE_SHORT, DATE_LOCAL, DATE_ISO8601 };
const char *show_date(unsigned long time, int timezone, enum date_mode mode);
const char *show_rfc2822_date(unsigned long time, int timezone);
int parse_date(const char *date, char *buf, int bufsize);
diff --git a/commit.c b/commit.c
index 5632e32..68df3b4 100644
--- a/commit.c
+++ b/commit.c
@@ -773,6 +773,7 @@ static void fill_person(struct interp *table, const char *msg, int len)
interp_set_entry(table, 2, show_date(date, tz, 0));
interp_set_entry(table, 3, show_rfc2822_date(date, tz));
interp_set_entry(table, 4, show_date(date, tz, 1));
+ interp_set_entry(table, 6, show_date(date, tz, DATE_ISO8601));
}
static long format_commit_message(const struct commit *commit,
@@ -791,12 +792,14 @@ static long format_commit_message(const struct commit *commit,
{ "%aD" }, /* author date, RFC2822 style */
{ "%ar" }, /* author date, relative */
{ "%at" }, /* author date, UNIX timestamp */
+ { "%ai" }, /* author date, ISO 8601 */
{ "%cn" }, /* committer name */
{ "%ce" }, /* committer email */
{ "%cd" }, /* committer date */
{ "%cD" }, /* committer date, RFC2822 style */
{ "%cr" }, /* committer date, relative */
{ "%ct" }, /* committer date, UNIX timestamp */
+ { "%ci" }, /* committer date, ISO 8601 */
{ "%e" }, /* encoding */
{ "%s" }, /* subject */
{ "%b" }, /* body */
@@ -813,10 +816,11 @@ static long format_commit_message(const struct commit *commit,
IPARENTS, IPARENTS_ABBREV,
IAUTHOR_NAME, IAUTHOR_EMAIL,
IAUTHOR_DATE, IAUTHOR_DATE_RFC2822, IAUTHOR_DATE_RELATIVE,
- IAUTHOR_TIMESTAMP,
+ IAUTHOR_TIMESTAMP, IAUTHOR_ISO8601,
ICOMMITTER_NAME, ICOMMITTER_EMAIL,
ICOMMITTER_DATE, ICOMMITTER_DATE_RFC2822,
ICOMMITTER_DATE_RELATIVE, ICOMMITTER_TIMESTAMP,
+ ICOMMITTER_ISO8601,
IENCODING,
ISUBJECT,
IBODY,
diff --git a/date.c b/date.c
index 4690371..5155bb2 100644
--- a/date.c
+++ b/date.c
@@ -137,6 +137,13 @@ const char *show_date(unsigned long time, int tz, enum date_mode mode)
if (mode == DATE_SHORT)
sprintf(timebuf, "%04d-%02d-%02d", tm->tm_year + 1900,
tm->tm_mon + 1, tm->tm_mday);
+ else if (mode == DATE_ISO8601)
+ sprintf(timebuf, "%04d-%02d-%02d %02d:%02d:%02d %+05d",
+ tm->tm_year + 1900,
+ tm->tm_mon + 1,
+ tm->tm_mday,
+ tm->tm_hour, tm->tm_min, tm->tm_sec,
+ tz);
else
sprintf(timebuf, "%.3s %.3s %d %02d:%02d:%02d %d%c%+05d",
weekday_names[tm->tm_wday],
^ permalink raw reply related
* Re: mtimes of working files
From: David Woodhouse @ 2007-07-13 23:00 UTC (permalink / raw)
To: Theodore Tso; +Cc: Andy Parkins, git, Jan Hudec, Johannes Schindelin
In-Reply-To: <20070713003700.GA21304@thunk.org>
On Thu, 2007-07-12 at 20:37 -0400, Theodore Tso wrote:
> I could use separate trees, I suppose, but then I have to keep
> multiple copies of the .o files around in all of those separate trees,
> and it's cheaper and more efficient to keep them in the ccache cache
> IMHO. And with 7200 RPM laptop drives and dual core processors
> combined with ccache, I hardly notice the rebuild/relink time.
I'm not entirely sure why it would be cheaper and more efficient to keep
your object files in ccache rather than in the build tree. It takes time
for ccache to do the preprocessing and fetch them, and it takes even
more time to redo the linking.
Disk space is cheap too, and you can always 'make clean' or even remove
all the source files too, if you really care.
Not that I'm presuming to suggest that there's anything _wrong_ with
your choice of workflow, of course -- it just doesn't really make much
sense to me.
Branches just seem like a source of complexity and hence pain. Using git
was just starting to become sensible for newbies, and now when people
are forced to deal with multiple branches it's all horribly painful
again.
--
dwmw2
^ permalink raw reply
* Re: Possible to make a totally empty repository for remote access?
From: Junio C Hamano @ 2007-07-13 22:18 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git
In-Reply-To: <54C69B03-C589-480E-80D3-75166DBF2D29@wincent.com>
Wincent Colaiuta <win@wincent.com> writes:
> I understand that Git is a *content* manager and a totally empty
> repository has no content, and therefore no tree object which the
> HEAD can point to. But the trouble with adding content the way I
> describe above, is that my public repository is no longer bare; it
> now has a working copy, which I didn't really want.
You prepared an empty bare repository for publishing, and that
is very good.
The next step is that you prepare your contents elsewhere. That
would be your private working place, i.e. the place you would
normally work in). You push from your private working place
into that publishing repository. Your working place is where
the very initial commit should come from, since you are the one
who is starting the project.
Note that the private working place does not have to be a clone
of the empty one. That actually is backwards. Your work
started from your private working place to the publishing one.
You could even clone your private repository to publishing one
to make it clear who is the master and who is the copy if you
wanted to, but because you already have the bare repository for
publishing, just pushing into it is all that is needed.
^ permalink raw reply
* Re: [PATCH] Support output ISO 8601 format dates
From: Junio C Hamano @ 2007-07-13 22:11 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <20070713202258.14107.18196.stgit@lathund.dewire.com>
Documentation/pretty-formats.txt does not talk about this
addition.
Almost everything else looks fine with your patch, except that
neither "git show --date=iso" nor "git log --date=iso8601" works
with this change, but that is only half your fault.
When we added DATE_SHORT support we could have added the option
parser to revision.c so that you could mimick it more easily.
That half is my fault.
The patch, especially this hunk:
> diff --git a/commit.c b/commit.c
> index 5632e32..68df3b4 100644
> --- a/commit.c
> +++ b/commit.c
> @@ -773,6 +773,7 @@ static void fill_person(struct interp *table, const char *msg, int len)
> interp_set_entry(table, 2, show_date(date, tz, 0));
> interp_set_entry(table, 3, show_rfc2822_date(date, tz));
> interp_set_entry(table, 4, show_date(date, tz, 1));
> + interp_set_entry(table, 6, show_date(date, tz, DATE_ISO8601));
> }
>
> static long format_commit_message(const struct commit *commit,
makes me wonder if we would want to refactor and reimplement
show_rfc2822_date() in terms of show_date(), by introducing
DATE_RFC2822 in the date format enum, which will allow us to say
"git show --date=rfc2822".
Hmm?
^ permalink raw reply
* question about git-submodule
From: VMiklos @ 2007-07-13 21:46 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 398 bytes --]
hi,
even after reading the manpage, i'm not sure about what git submodules
are for :)
i mean, first i thought that after configuring a submodule under libfoo,
then a git pull will update libfoo's repo under libfoo, too. or
something like that. but in fact even after reasing the source, i'm not
sure about what is git submodule update is for :s
sorry for the lame question :)
thanks,
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Possible to make a totally empty repository for remote access?
From: Wincent Colaiuta @ 2007-07-13 21:41 UTC (permalink / raw)
To: git
For a new project (no code yet) I wanted to make an empty, bare
repository (no working copy) on a remote public server as a starting
point, clone it locally, and gradually create content locally and
push it out to the remote, public server.
But so far I've been unable to do so in a straightfoward fashion...
mkdir test.git
cd test.git
git --bare init
touch git-daemon-export-ok
If I try to clone such an empty repository I get:
fatal: no matching remote head
And GIT_DIR/HEAD points to refs/heads/master, which doesn't exist yet.
Same if I go for a non-bare, but still empty repository:
mkdir test
cd test
git init
touch .git/git-daemon-export-ok
Only after adding actual content can I clone without getting the "no
matching remote head" error:
echo "foo" > bar
git add bar
git commit -m "foobar"
Then cloning works.
I understand that Git is a *content* manager and a totally empty
repository has no content, and therefore no tree object which the
HEAD can point to. But the trouble with adding content the way I
describe above, is that my public repository is no longer bare; it
now has a working copy, which I didn't really want.
What's the way around this? Do I start with a non-bare repository,
add any old bogus content, and then convert it to bare and blow away
the working copy?
mkdir test
cd test
git init
touch .git/git-daemon-export-ok
touch .gitignore
git add .gitignore
git commit -m "Initial empty repository containing only an
empty .gitignore file"
git config core.bare true
mv .git ../test.git
cd ..
rm -r test
Is there a better way? Am I missing something obvious?
Cheers,
Wincent
^ permalink raw reply
* [PATCH] Support output ISO 8601 format dates
From: Robin Rosenberg @ 2007-07-13 20:22 UTC (permalink / raw)
To: junkio; +Cc: git
Support output of full ISO 8601 style dates in e.g. git log
and other places that use interpolation for formatting.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
cache.h | 2 +-
commit.c | 6 +++++-
date.c | 7 +++++++
3 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/cache.h b/cache.h
index 5dff2f1..3dc0def 100644
--- a/cache.h
+++ b/cache.h
@@ -389,7 +389,7 @@ extern void *read_object_with_reference(const unsigned char *sha1,
unsigned long *size,
unsigned char *sha1_ret);
-enum date_mode { DATE_NORMAL = 0, DATE_RELATIVE, DATE_SHORT, DATE_LOCAL };
+enum date_mode { DATE_NORMAL = 0, DATE_RELATIVE, DATE_SHORT, DATE_LOCAL, DATE_ISO8601 };
const char *show_date(unsigned long time, int timezone, enum date_mode mode);
const char *show_rfc2822_date(unsigned long time, int timezone);
int parse_date(const char *date, char *buf, int bufsize);
diff --git a/commit.c b/commit.c
index 5632e32..68df3b4 100644
--- a/commit.c
+++ b/commit.c
@@ -773,6 +773,7 @@ static void fill_person(struct interp *table, const char *msg, int len)
interp_set_entry(table, 2, show_date(date, tz, 0));
interp_set_entry(table, 3, show_rfc2822_date(date, tz));
interp_set_entry(table, 4, show_date(date, tz, 1));
+ interp_set_entry(table, 6, show_date(date, tz, DATE_ISO8601));
}
static long format_commit_message(const struct commit *commit,
@@ -791,12 +792,14 @@ static long format_commit_message(const struct commit *commit,
{ "%aD" }, /* author date, RFC2822 style */
{ "%ar" }, /* author date, relative */
{ "%at" }, /* author date, UNIX timestamp */
+ { "%ai" }, /* author date, ISO 8601 */
{ "%cn" }, /* committer name */
{ "%ce" }, /* committer email */
{ "%cd" }, /* committer date */
{ "%cD" }, /* committer date, RFC2822 style */
{ "%cr" }, /* committer date, relative */
{ "%ct" }, /* committer date, UNIX timestamp */
+ { "%ci" }, /* committer date, ISO 8601 */
{ "%e" }, /* encoding */
{ "%s" }, /* subject */
{ "%b" }, /* body */
@@ -813,10 +816,11 @@ static long format_commit_message(const struct commit *commit,
IPARENTS, IPARENTS_ABBREV,
IAUTHOR_NAME, IAUTHOR_EMAIL,
IAUTHOR_DATE, IAUTHOR_DATE_RFC2822, IAUTHOR_DATE_RELATIVE,
- IAUTHOR_TIMESTAMP,
+ IAUTHOR_TIMESTAMP, IAUTHOR_ISO8601,
ICOMMITTER_NAME, ICOMMITTER_EMAIL,
ICOMMITTER_DATE, ICOMMITTER_DATE_RFC2822,
ICOMMITTER_DATE_RELATIVE, ICOMMITTER_TIMESTAMP,
+ ICOMMITTER_ISO8601,
IENCODING,
ISUBJECT,
IBODY,
diff --git a/date.c b/date.c
index 4690371..5155bb2 100644
--- a/date.c
+++ b/date.c
@@ -137,6 +137,13 @@ const char *show_date(unsigned long time, int tz, enum date_mode mode)
if (mode == DATE_SHORT)
sprintf(timebuf, "%04d-%02d-%02d", tm->tm_year + 1900,
tm->tm_mon + 1, tm->tm_mday);
+ else if (mode == DATE_ISO8601)
+ sprintf(timebuf, "%04d-%02d-%02d %02d:%02d:%02d %+05d",
+ tm->tm_year + 1900,
+ tm->tm_mon + 1,
+ tm->tm_mday,
+ tm->tm_hour, tm->tm_min, tm->tm_sec,
+ tz);
else
sprintf(timebuf, "%.3s %.3s %d %02d:%02d:%02d %d%c%+05d",
weekday_names[tm->tm_wday],
^ permalink raw reply related
* Re: Better handling of local changes in 'gitk'?
From: Linus Torvalds @ 2007-07-13 19:32 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Git Mailing List
In-Reply-To: <18071.20289.270560.640460@cargo.ozlabs.ibm.com>
On Fri, 13 Jul 2007, Paul Mackerras wrote:
>
> I should add that I'm sure that gitk won't yet do the right thing if
> there are files in the index at other than stage 0, or if the local
> changes are the result of an incomplete merge. (In the latter case I
> suppose one or other of the fake commits should have multiple parents,
> but I don't have the infrastructure to add fake commits with multiple
> parents yet.)
That would be beautiful to see, indeed, when you're in the middle of a
merge. "gitk --merge" already does most of it, but actually seeing the
diff of the currently merged stuff would be pretty darn cool.
Linus
^ permalink raw reply
* Fwd: git-svn: trunk missing, checks out tag instead
From: Bradford Smith @ 2007-07-13 19:05 UTC (permalink / raw)
To: git
In-Reply-To: <f158199e0707131024o5eb27b72v900f0d0613bc834b@mail.gmail.com>
UPDATE:
I get the same behavior even after checking in a new change on the trunk.
Oh, well...
Bradford
---------- Forwarded message ----------
From: Bradford Smith <bradford.carl.smith@gmail.com>
Date: Jul 13, 2007 1:24 PM
Subject: git-svn: trunk missing, checks out tag instead
To: git@vger.kernel.org
I am using git-svn version 1.5.3.rc1.4.gaf83 (svn 1.4.3), and I work
with an SVN repository that is layed out like this:
/trunk/proj1/
...
/trunk/proj2/
...
/trunk/testing/
...
/branches/proj1/
...
/branches/proj2/
...
/branches/testing/
/branches/testing/0000-baseline
/tags/proj1/
...
/tags/proj2/
...
/tags/testing/
/tags/testing/0000-baseline-0
I want to track the testing project, so I tried to use this git-svn
command line:
git-svn clone <base-url> -T/trunk/testing -t/tags/testing
-b/branches/testing testing
This appears to work, though I do get this warning message (edited for privacy):
W: Ignoring error from SVN, path probably does not exist: (175002): RA
layer request failed: REPORT request failed on
'/<server_path>/!svn/bc/101': REPORT of '/<server_path>!svn/bc/101':
Could not read chunk size: Secure connection truncated
(https://<myserver>)
When I run 'git branch -a' in the new testing directory I get this:
* master
0000-baseline
0000-baseline@1546
1.0
1.0@1549
1.0@1656
tags/0000-baseline
tags/0000-baseline-0
tags/0000-baseline@1663
Where is the remote branch for trunk? And, why do I have remote
entries for the defunct 1.0 branch that I deleted from svn earlier
today? What's more, the latest changes from /trunk/testing do not
appear in my working directory, and gitk confirms that master is
pointing at the same commit as tags/0000-baseline-0.
If I just try to track the trunk like this:
git-svn clone <base-url>/trunk/testing
Then I get all of the latest changes and 'git branch -a' shows:
* master
git-svn
So that seems OK at least. It just doesn't work when I try to get
branches and tags. For now, I'll just work this way.
FWIW, I suspect this behavior may be related to recent changes I made
to the Subversion repository. I created
/branches/testing/0000-baseline today by copying an _old_ revision of
/trunk/testing. Then I created /tags/testing/0000-baseline-0 by
copying /branches/testing/0000-baseline. No commits have been done on
/testing/trunk since then. Perhaps the recent (probably latest)
commit that copied an OLD version of trunk is somehow confusing
git-svn? Once I commit a change to the subversion trunk, I'll try to
clone trunk, branches, and tags again and post an update to this
message. Maybe it will work then.
Thanks for your help.
Bradford C. Smith
^ permalink raw reply
* Re: [PATCH] More permissive "git-rm --cached" behavior without -f.
From: Matthieu Moy @ 2007-07-13 18:53 UTC (permalink / raw)
To: Jeff King; +Cc: git, Johannes Schindelin
In-Reply-To: <20070713175737.GA20416@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Jul 13, 2007 at 07:41:38PM +0200, Matthieu Moy wrote:
>
>> Previously, the index had to match the file *and* the HEAD. With
>> --cached, the index must now match the file *or* the HEAD. The behavior
>> without --cached is unchanged, but provides better error messages.
>
> This does make more sense, but there are still some inconsistencies. Is
> it OK to lose content that is only in the index, or not?
I'd say it isn't OK. At least, that's what the previous git-rm
considered.
> If it is OK, then --cached shouldn't need _any_ safety valve (and after
> all, anything you remove in that manner is recoverable with git-fsck
> until the next prune).
>
> If it isn't OK, then you are not addressing the cases where git-rm
> without --cached loses index content (that is different than HEAD and
> the working tree).
Either I didn't understand your question, or the answer is "yes, I
do.". The behavior without --cached is not modified, except for the
error message, and the previous was to require -f whenever the index
doesn't match the head, *or* doesn't match the file. So, without
--cached, you need to have file=index=HEAD to be able to git-rm.
If I missunderstand you, please, provide a senario where my patch
doesn't do the expected.
--
Matthieu
^ permalink raw reply
* Re: [PATCH] lockfile.c: schedule remove_lock_file only once.
From: Junio C Hamano @ 2007-07-13 18:23 UTC (permalink / raw)
To: Sven Verdoolaege; +Cc: git
In-Reply-To: <20070713141450.GA8392MdfPADPa@greensroom.kotnet.org>
Sven Verdoolaege <skimo@kotnet.org> writes:
> Removing a lockfile once should be enough.
Yeah. I wonder what we were smoking. 415e96c8 which introduces
the atexit to index.c does:
int hold_index_file_for_update(struct cache_file *cf, const char *path)
{
sprintf(cf->lockfile, "%s.lock", path);
cf->next = cache_file_list;
cache_file_list = cf;
if (!cf->next) {
signal(SIGINT, remove_lock_file_on_signal);
atexit(remove_lock_file);
}
return open(cf->lockfile, O_RDWR | O_CREAT | O_EXCL, 0600);
}
whose intent is exactly "do this once, only for the first one".
The reason we do not use lk->next but instead check lk->on_list,
and the reason why we do not remove the lock from the list, are
described in 1084b845.
But your "fire atexit() once" fix is needed. Thanks.
^ permalink raw reply
* Re: sharing between local "work" and "nightly build" git repos
From: Junio C Hamano @ 2007-07-13 18:23 UTC (permalink / raw)
To: David Frech; +Cc: Junio C Hamano, git
In-Reply-To: <7154c5c60707121727k36854891u82afc4a8be822861@mail.gmail.com>
"David Frech" <nimblemachines@gmail.com> writes:
> Could you, for my sake and the list's (if others are as confused) be
> clearer about the distinctions among -l, -s, and --reference? Exactly
> what they do, and their orthogonality (or lack of) really isn't clear
> from reading the man page.
Clone "-l" makes the new repository share the initial set of
objects from the original by hardlinking each and every file
under .git/objects/. After "-l" clone, two repositories are
truly independent, except for the fact that the new one
obviously treats the old one as its "origin".
There are a few implications:
- New objects created in the new repository is not visible in
the original repository and vice versa. If you do
development in the new repository, and push the results back
to the original, the push will involve object transfer. If
your original one is updated (perhaps with git-pull from the
upstream), you would need to update the clone separately.
- You can safely rewind the refs in the original repository and
run git-prune there without worrying about corrupting the
cloned repository.
Clone "-s" does not make hardlinked copy like "-l" makes. It
creates an entry in .git/objects/info/alternates file in the new
repository, that instructs git that any object missing in the
new repository should be looked up in the cloned repository.
New objects created in the original will be shared with the
cloned repository because of this, but the sharing does not
happen in the other direction. Also if you run "rebase" (or
"reset --hard" to rewind the tip of branches) in the original
repository and then run git-gc, it would cause some objects to
become unneeded in the original repository and they can get
discarded. If your cloned repository depends in them, you will
be in trouble. So you would need to be a bit careful when you
use "-s" --- the rule of thumb is not to rewind the branches, or
if you do, make sure the cloned ones are kept in sync
(i.e. rewind the commits lost in the original the same way in
the clone).
The "--reference" option uses the same mechanism as "-s" uses to
share objects from a local repository. It is useful if you have
a repository of a different project that is related to the
project you are cloning from outside. For example, if you have
a copy of LInus's Linux 2.6 kernel repository locally, and if
you want to clone 2.6.x.y maintenance "stable" repository, you
know the two repositories are alike and share a lot of objects,
so you would:
$ git clone --reference ../linus-2.6/ git://.../linux-2.6.x.y/ stable.git
To this option, because it uses the same "alternate object
store" mechanism as "-s" option does, the same "be careful
rewinding the branches in the original" caveat applies. Because
Linus never rewind his branches, the above clone is safe.
For the purpose of "keep rebuilding 'next' from git.git
repository", because my 'next' will never rewind by social
convention, you do not have to worry about the "original
repository being rewound and losing objects" problem, either, as
long as 'next' is the branch you rebuild in the "nightly"
repository.
^ permalink raw reply
* Re: [PATCH 0/6] Pack window memory limit, take 2
From: Junio C Hamano @ 2007-07-13 18:23 UTC (permalink / raw)
To: Brian Downing; +Cc: git, Nicolas Pitre
In-Reply-To: <1184244952554-git-send-email-bdowning@lavos.net>
Very nicely done. Thanks, everybody involved.
^ permalink raw reply
* Re: [PATCH] More permissive "git-rm --cached" behavior without -f.
From: Jeff King @ 2007-07-13 17:57 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, Johannes Schindelin
In-Reply-To: <11843484982037-git-send-email-Matthieu.Moy@imag.fr>
On Fri, Jul 13, 2007 at 07:41:38PM +0200, Matthieu Moy wrote:
> Previously, the index had to match the file *and* the HEAD. With
> --cached, the index must now match the file *or* the HEAD. The behavior
> without --cached is unchanged, but provides better error messages.
This does make more sense, but there are still some inconsistencies. Is
it OK to lose content that is only in the index, or not?
If it is OK, then --cached shouldn't need _any_ safety valve (and after
all, anything you remove in that manner is recoverable with git-fsck
until the next prune).
If it isn't OK, then you are not addressing the cases where git-rm
without --cached loses index content (that is different than HEAD and
the working tree).
-Peff
^ permalink raw reply
* [PATCH] Use $(RM) in makefiles instead of rm
From: Emil Medve @ 2007-07-13 17:48 UTC (permalink / raw)
To: git; +Cc: Emil Medve
Use $(RM) in makefiles instead of rm
Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
---
Documentation/Makefile | 14 +++++-----
Makefile | 66 ++++++++++++++++++++++++------------------------
contrib/emacs/Makefile | 2 +-
git-gui/Makefile | 14 +++++-----
t/Makefile | 2 +-
templates/Makefile | 2 +-
6 files changed, 50 insertions(+), 50 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index f3a6c73..eaab01d 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -84,7 +84,7 @@ install: man
# Determine "include::" file references in asciidoc files.
#
doc.dep : $(wildcard *.txt) build-docdep.perl
- rm -f $@+ $@
+ $(RM) $@+ $@
perl ./build-docdep.perl >$@+
mv $@+ $@
@@ -109,11 +109,11 @@ cmd-list.made: cmd-list.perl $(MAN1_TXT)
git.7 git.html: git.txt core-intro.txt
clean:
- rm -f *.xml *.xml+ *.html *.html+ *.1 *.5 *.7 howto-index.txt howto/*.html doc.dep
- rm -f $(cmds_txt) *.made
+ $(RM) *.xml *.xml+ *.html *.html+ *.1 *.5 *.7 howto-index.txt howto/*.html doc.dep
+ $(RM) $(cmds_txt) *.made
%.html : %.txt
- rm -f $@+ $@
+ $(RM) $@+ $@
$(ASCIIDOC) -b xhtml11 -d manpage -f asciidoc.conf \
$(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $<
mv $@+ $@
@@ -122,7 +122,7 @@ clean:
xmlto -m callouts.xsl man $<
%.xml : %.txt
- rm -f $@+ $@
+ $(RM) $@+ $@
$(ASCIIDOC) -b docbook -d manpage -f asciidoc.conf \
$(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $<
mv $@+ $@
@@ -137,7 +137,7 @@ user-manual.html: user-manual.xml
xsltproc $(XSLTOPTS) -o $@ $(XSLT) $<
howto-index.txt: howto-index.sh $(wildcard howto/*.txt)
- rm -f $@+ $@
+ $(RM) $@+ $@
sh ./howto-index.sh $(wildcard howto/*.txt) >$@+
mv $@+ $@
@@ -147,7 +147,7 @@ $(patsubst %,%.html,$(ARTICLES)) : %.html : %.txt
WEBDOC_DEST = /pub/software/scm/git/docs
$(patsubst %.txt,%.html,$(wildcard howto/*.txt)): %.html : %.txt
- rm -f $@+ $@
+ $(RM) $@+ $@
sed -e '1,/^$$/d' $< | $(ASCIIDOC) -b xhtml11 - >$@+
mv $@+ $@
diff --git a/Makefile b/Makefile
index d7541b4..2453fc8 100644
--- a/Makefile
+++ b/Makefile
@@ -729,7 +729,7 @@ export TAR INSTALL DESTDIR SHELL_PATH
all:: $(ALL_PROGRAMS) $(BUILT_INS) $(OTHER_PROGRAMS)
ifneq (,$X)
- $(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), rm -f '$p';)
+ $(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), $(RM) '$p';)
endif
all::
@@ -743,7 +743,7 @@ strip: $(PROGRAMS) git$X
$(STRIP) $(STRIP_OPTS) $(PROGRAMS) git$X
gitk-wish: gitk GIT-GUI-VARS
- $(QUIET_GEN)rm -f $@ $@+ && \
+ $(QUIET_GEN)$(RM) $@ $@+ && \
sed -e '1,3s|^exec .* "$$0"|exec $(subst |,'\|',$(TCLTK_PATH_SQ)) "$$0"|' <gitk >$@+ && \
chmod +x $@+ && \
mv -f $@+ $@
@@ -759,10 +759,10 @@ git$X: git.o $(BUILTIN_OBJS) $(GITLIBS)
help.o: common-cmds.h
git-merge-subtree$X: git-merge-recursive$X
- $(QUIET_BUILT_IN)rm -f $@ && ln git-merge-recursive$X $@
+ $(QUIET_BUILT_IN)$(RM) $@ && ln git-merge-recursive$X $@
$(BUILT_INS): git$X
- $(QUIET_BUILT_IN)rm -f $@ && ln git$X $@
+ $(QUIET_BUILT_IN)$(RM) $@ && ln git$X $@
common-cmds.h: ./generate-cmdlist.sh
@@ -770,7 +770,7 @@ common-cmds.h: $(wildcard Documentation/git-*.txt)
$(QUIET_GEN)./generate-cmdlist.sh > $@+ && mv $@+ $@
$(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
- $(QUIET_GEN)rm -f $@ $@+ && \
+ $(QUIET_GEN)$(RM) $@ $@+ && \
sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
-e 's|@@PERL@@|$(PERL_PATH_SQ)|g' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
@@ -782,7 +782,7 @@ $(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
$(patsubst %.perl,%,$(SCRIPT_PERL)): perl/perl.mak
$(patsubst %.py,%,$(SCRIPT_PYTHON)) : % : %.py
- rm -f $@ $@+
+ $(RM) $@ $@+
sed -e '1s|#!.*/python|#!$(PYTHON_PATH_SQ)|' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
-e 's/@@NO_CURL@@/$(NO_CURL)/g' \
@@ -794,7 +794,7 @@ perl/perl.mak: GIT-CFLAGS
$(QUIET_SUBDIR0)perl $(QUIET_SUBDIR1) PERL_PATH='$(PERL_PATH_SQ)' prefix='$(prefix_SQ)' $(@F)
$(patsubst %.perl,%,$(SCRIPT_PERL)): % : %.perl
- $(QUIET_GEN)rm -f $@ $@+ && \
+ $(QUIET_GEN)$(RM) $@ $@+ && \
INSTLIBDIR=`$(MAKE) -C perl -s --no-print-directory instlibdir` && \
sed -e '1{' \
-e ' s|#!.*perl|#!$(PERL_PATH_SQ)|' \
@@ -813,7 +813,7 @@ git-status: git-commit
$(QUIET_GEN)cp $< $@+ && mv $@+ $@
gitweb/gitweb.cgi: gitweb/gitweb.perl
- $(QUIET_GEN)rm -f $@ $@+ && \
+ $(QUIET_GEN)$(RM) $@ $@+ && \
sed -e '1s|#!.*perl|#!$(PERL_PATH_SQ)|' \
-e 's|++GIT_VERSION++|$(GIT_VERSION)|g' \
-e 's|++GIT_BINDIR++|$(bindir)|g' \
@@ -836,7 +836,7 @@ gitweb/gitweb.cgi: gitweb/gitweb.perl
mv $@+ $@
git-instaweb: git-instaweb.sh gitweb/gitweb.cgi gitweb/gitweb.css
- $(QUIET_GEN)rm -f $@ $@+ && \
+ $(QUIET_GEN)$(RM) $@ $@+ && \
sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
-e 's/@@NO_CURL@@/$(NO_CURL)/g' \
@@ -849,11 +849,11 @@ git-instaweb: git-instaweb.sh gitweb/gitweb.cgi gitweb/gitweb.css
mv $@+ $@
configure: configure.ac
- $(QUIET_GEN)rm -f $@ $<+ && \
+ $(QUIET_GEN)$(RM) $@ $<+ && \
sed -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
$< > $<+ && \
autoconf -o $@ $<+ && \
- rm -f $<+
+ $(RM) $<+
# These can record GIT_VERSION
git.o git.spec \
@@ -908,7 +908,7 @@ $(patsubst git-%$X,%.o,$(PROGRAMS)): $(LIB_H) $(wildcard */*.h)
$(DIFF_OBJS): diffcore.h
$(LIB_FILE): $(LIB_OBJS)
- $(QUIET_AR)rm -f $@ && $(AR) rcs $@ $(LIB_OBJS)
+ $(QUIET_AR)$(RM) $@ && $(AR) rcs $@ $(LIB_OBJS)
XDIFF_OBJS=xdiff/xdiffi.o xdiff/xprepare.o xdiff/xutils.o xdiff/xemit.o \
xdiff/xmerge.o
@@ -916,7 +916,7 @@ $(XDIFF_OBJS): xdiff/xinclude.h xdiff/xmacros.h xdiff/xdiff.h xdiff/xtypes.h \
xdiff/xutils.h xdiff/xprepare.h xdiff/xdiffi.h xdiff/xemit.h
$(XDIFF_LIB): $(XDIFF_OBJS)
- $(QUIET_AR)rm -f $@ && $(AR) rcs $@ $(XDIFF_OBJS)
+ $(QUIET_AR)$(RM) $@ && $(AR) rcs $@ $(XDIFF_OBJS)
perl/Makefile: perl/Git.pm perl/Makefile.PL GIT-CFLAGS
@@ -927,11 +927,11 @@ doc:
$(MAKE) -C Documentation all
TAGS:
- rm -f TAGS
+ $(RM) TAGS
find . -name '*.[hcS]' -print | xargs etags -a
tags:
- rm -f tags
+ $(RM) tags
find . -name '*.[hcS]' -print | xargs ctags -a
### Detect prefix changes
@@ -1010,9 +1010,9 @@ endif
cp '$(DESTDIR_SQ)$(bindir_SQ)/git$X' \
'$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X'; \
fi
- $(foreach p,$(BUILT_INS), rm -f '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' && ln '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X' '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' ;)
+ $(foreach p,$(BUILT_INS), $(RM) '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' && ln '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X' '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' ;)
ifneq (,$X)
- $(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), rm -f '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p';)
+ $(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), $(RM) '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p';)
endif
install-doc:
@@ -1042,7 +1042,7 @@ dist: git.spec git-archive configure
$(GIT_TARNAME)/configure \
$(GIT_TARNAME)/version \
$(GIT_TARNAME)/git-gui/version
- @rm -rf $(GIT_TARNAME)
+ @$(RM) -r $(GIT_TARNAME)
gzip -f -9 $(GIT_TARNAME).tar
rpm: dist
@@ -1051,13 +1051,13 @@ rpm: dist
htmldocs = git-htmldocs-$(GIT_VERSION)
manpages = git-manpages-$(GIT_VERSION)
dist-doc:
- rm -fr .doc-tmp-dir
+ $(RM) -r .doc-tmp-dir
mkdir .doc-tmp-dir
$(MAKE) -C Documentation WEBDOC_DEST=../.doc-tmp-dir install-webdoc
cd .doc-tmp-dir && $(TAR) cf ../$(htmldocs).tar .
gzip -n -9 -f $(htmldocs).tar
:
- rm -fr .doc-tmp-dir
+ $(RM) -r .doc-tmp-dir
mkdir -p .doc-tmp-dir/man1 .doc-tmp-dir/man5 .doc-tmp-dir/man7
$(MAKE) -C Documentation DESTDIR=./ \
man1dir=../.doc-tmp-dir/man1 \
@@ -1066,31 +1066,31 @@ dist-doc:
install
cd .doc-tmp-dir && $(TAR) cf ../$(manpages).tar .
gzip -n -9 -f $(manpages).tar
- rm -fr .doc-tmp-dir
+ $(RM) -r .doc-tmp-dir
### Cleaning rules
clean:
- rm -f *.o mozilla-sha1/*.o arm/*.o ppc/*.o compat/*.o xdiff/*.o \
+ $(RM) *.o mozilla-sha1/*.o arm/*.o ppc/*.o compat/*.o xdiff/*.o \
$(LIB_FILE) $(XDIFF_LIB)
- rm -f $(ALL_PROGRAMS) $(BUILT_INS) git$X
- rm -f $(TEST_PROGRAMS)
- rm -f *.spec *.pyc *.pyo */*.pyc */*.pyo common-cmds.h TAGS tags
- rm -rf autom4te.cache
- rm -f configure config.log config.mak.autogen config.mak.append config.status config.cache
- rm -rf $(GIT_TARNAME) .doc-tmp-dir
- rm -f $(GIT_TARNAME).tar.gz git-core_$(GIT_VERSION)-*.tar.gz
- rm -f $(htmldocs).tar.gz $(manpages).tar.gz
- rm -f gitweb/gitweb.cgi
+ $(RM) $(ALL_PROGRAMS) $(BUILT_INS) git$X
+ $(RM) $(TEST_PROGRAMS)
+ $(RM) *.spec *.pyc *.pyo */*.pyc */*.pyo common-cmds.h TAGS tags
+ $(RM) -r autom4te.cache
+ $(RM) configure config.log config.mak.autogen config.mak.append config.status config.cache
+ $(RM) -r $(GIT_TARNAME) .doc-tmp-dir
+ $(RM) $(GIT_TARNAME).tar.gz git-core_$(GIT_VERSION)-*.tar.gz
+ $(RM) $(htmldocs).tar.gz $(manpages).tar.gz
+ $(RM) gitweb/gitweb.cgi
$(MAKE) -C Documentation/ clean
$(MAKE) -C perl clean
$(MAKE) -C templates/ clean
$(MAKE) -C t/ clean
ifndef NO_TCLTK
- rm -f gitk-wish
+ $(RM) gitk-wish
$(MAKE) -C git-gui clean
endif
- rm -f GIT-VERSION-FILE GIT-CFLAGS GIT-GUI-VARS
+ $(RM) GIT-VERSION-FILE GIT-CFLAGS GIT-GUI-VARS
.PHONY: all install clean strip
.PHONY: .FORCE-GIT-VERSION-FILE TAGS tags .FORCE-GIT-CFLAGS
diff --git a/contrib/emacs/Makefile b/contrib/emacs/Makefile
index 98aa0aa..7000d99 100644
--- a/contrib/emacs/Makefile
+++ b/contrib/emacs/Makefile
@@ -17,4 +17,4 @@ install: all
%.elc: %.el
$(EMACS) -batch -f batch-byte-compile $<
-clean:; rm -f $(ELC)
+clean:; $(RM) $(ELC)
diff --git a/git-gui/Makefile b/git-gui/Makefile
index 1bac6fe..ab13b8a 100644
--- a/git-gui/Makefile
+++ b/git-gui/Makefile
@@ -37,7 +37,7 @@ INSTALL_R0 = $(INSTALL) -m644 # space is required here
INSTALL_R1 =
INSTALL_X0 = $(INSTALL) -m755 # space is required here
INSTALL_X1 =
-INSTALL_L0 = rm -f # space is required here
+INSTALL_L0 = $(RM) # space is required here
INSTALL_L1 = && ln # space is required here
INSTALL_L2 =
INSTALL_L3 =
@@ -59,7 +59,7 @@ ifndef V
INSTALL_L0 = dst=
INSTALL_L1 = && src=
INSTALL_L2 = && dst=
- INSTALL_L3 = && echo ' ' 'LINK ' `basename "$$dst"` '->' `basename "$$src"` && rm -f "$$dst" && ln "$$src" "$$dst"
+ INSTALL_L3 = && echo ' ' 'LINK ' `basename "$$dst"` '->' `basename "$$src"` && $(RM) "$$dst" && ln "$$src" "$$dst"
endif
TCL_PATH ?= tclsh
@@ -83,7 +83,7 @@ exedir = $(dir $(gitexecdir))share/git-gui/lib
exedir_SQ = $(subst ','\'',$(exedir))
$(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
- $(QUIET_GEN)rm -f $@ $@+ && \
+ $(QUIET_GEN)$(RM) $@ $@+ && \
GITGUI_RELATIVE= && \
if test '$(exedir_SQ)' = '$(libdir_SQ)'; then \
if test "$(uname_O)" = Cygwin; \
@@ -101,7 +101,7 @@ $(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
mv $@+ $@
$(GITGUI_BUILT_INS): git-gui
- $(QUIET_BUILT_IN)rm -f $@ && ln git-gui $@
+ $(QUIET_BUILT_IN)$(RM) $@ && ln git-gui $@
lib/tclIndex: $(ALL_LIBFILES)
$(QUIET_INDEX)if echo \
@@ -110,7 +110,7 @@ lib/tclIndex: $(ALL_LIBFILES)
| $(TCL_PATH) $(QUIET_2DEVNULL); then : ok; \
else \
echo 1>&2 " * $(TCL_PATH) failed; using unoptimized loading"; \
- rm -f $@ ; \
+ $(RM) $@ ; \
echo '# Autogenerated by git-gui Makefile' >$@ && \
echo >>$@ && \
$(foreach p,$(PRELOAD_FILES) $(ALL_LIBFILES),echo '$(subst lib/,,$p)' >>$@ &&) \
@@ -151,8 +151,8 @@ dist-version:
@echo $(GITGUI_VERSION) > $(TARDIR)/version
clean::
- rm -f $(ALL_PROGRAMS) lib/tclIndex
- rm -f GIT-VERSION-FILE GIT-GUI-VARS
+ $(RM) $(ALL_PROGRAMS) lib/tclIndex
+ $(RM) GIT-VERSION-FILE GIT-GUI-VARS
.PHONY: all install dist-version clean
.PHONY: .FORCE-GIT-VERSION-FILE
diff --git a/t/Makefile b/t/Makefile
index b25caca..dc9e8cc 100644
--- a/t/Makefile
+++ b/t/Makefile
@@ -19,7 +19,7 @@ $(T):
@echo "*** $@ ***"; GIT_CONFIG=.git/config '$(SHELL_PATH_SQ)' $@ $(GIT_TEST_OPTS)
clean:
- rm -fr trash
+ $(RM) -r trash
# we can test NO_OPTIMIZE_COMMITS independently of LC_ALL
full-svn-test:
diff --git a/templates/Makefile b/templates/Makefile
index aaa39d3..50a5453 100644
--- a/templates/Makefile
+++ b/templates/Makefile
@@ -42,7 +42,7 @@ custom:
$(QUIET): no custom templates yet
clean:
- rm -rf blt boilerplates.made
+ $(RM) -r blt boilerplates.made
install: all
$(INSTALL) -d -m755 '$(DESTDIR_SQ)$(template_dir_SQ)'
--
1.5.3.rc0.90.gbaa79
^ permalink raw reply related
* [PATCH] More permissive "git-rm --cached" behavior without -f.
From: Matthieu Moy @ 2007-07-13 17:41 UTC (permalink / raw)
To: git, Johannes Schindelin; +Cc: Matthieu Moy
In-Reply-To: <vpq8x9k9peu.fsf@bauges.imag.fr>
In the previous behavior, "git-rm --cached" (without -f) had the same
restriction as "git-rm". This forced the user to use the -f flag in
situations which weren't actually dangerous, like:
$ git add foo # oops, I didn't want this
$ git rm --cached foo # back to initial situation
Previously, the index had to match the file *and* the HEAD. With
--cached, the index must now match the file *or* the HEAD. The behavior
without --cached is unchanged, but provides better error messages.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
Documentation/git-rm.txt | 3 ++-
builtin-rm.c | 32 ++++++++++++++++++++++++++------
t/t3600-rm.sh | 34 ++++++++++++++++++++++++++++++++++
3 files changed, 62 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt
index 78f45dc..be61a82 100644
--- a/Documentation/git-rm.txt
+++ b/Documentation/git-rm.txt
@@ -14,7 +14,8 @@ DESCRIPTION
Remove files from the working tree and from the index. The
files have to be identical to the tip of the branch, and no
updates to its contents must have been placed in the staging
-area (aka index).
+area (aka index). When --cached is given, the staged content has to
+match either the tip of the branch *or* the file on disk.
OPTIONS
diff --git a/builtin-rm.c b/builtin-rm.c
index 4a0bd93..9a808c1 100644
--- a/builtin-rm.c
+++ b/builtin-rm.c
@@ -46,7 +46,7 @@ static int remove_file(const char *name)
return ret;
}
-static int check_local_mod(unsigned char *head)
+static int check_local_mod(unsigned char *head, int index_only)
{
/* items in list are already sorted in the cache order,
* so we could do this a lot more efficiently by using
@@ -65,6 +65,8 @@ static int check_local_mod(unsigned char *head)
const char *name = list.name[i];
unsigned char sha1[20];
unsigned mode;
+ int local_changes = 0;
+ int staged_changes = 0;
pos = cache_name_pos(name, strlen(name));
if (pos < 0)
@@ -87,14 +89,32 @@ static int check_local_mod(unsigned char *head)
continue;
}
if (ce_match_stat(ce, &st, 0))
- errs = error("'%s' has local modifications "
- "(hint: try -f)", ce->name);
+ local_changes = 1;
if (no_head
|| get_tree_entry(head, name, sha1, &mode)
|| ce->ce_mode != create_ce_mode(mode)
|| hashcmp(ce->sha1, sha1))
- errs = error("'%s' has changes staged in the index "
- "(hint: try -f)", name);
+ staged_changes = 1;
+
+ if (local_changes && staged_changes)
+ errs = error("'%s' has staged content different "
+ "from both the file and the HEAD\n"
+ "(use -f to force removal)", name);
+ else if (!index_only) {
+ /* It's not dangerous to git-rm --cached a
+ * file if the index matches the file or the
+ * HEAD, since it means the deleted content is
+ * still available somewhere.
+ */
+ if (staged_changes)
+ errs = error("'%s' has changes staged in the index\n"
+ "(use --cached to keep the file, "
+ "or -f to force removal)", name);
+ if (local_changes)
+ errs = error("'%s' has local modifications\n"
+ "(use --cached to keep the file, "
+ "or -f to force removal)", name);
+ }
}
return errs;
}
@@ -192,7 +212,7 @@ int cmd_rm(int argc, const char **argv, const char *prefix)
unsigned char sha1[20];
if (get_sha1("HEAD", sha1))
hashclr(sha1);
- if (check_local_mod(sha1))
+ if (check_local_mod(sha1, index_only))
exit(1);
}
diff --git a/t/t3600-rm.sh b/t/t3600-rm.sh
index 13a461f..5c001aa 100755
--- a/t/t3600-rm.sh
+++ b/t/t3600-rm.sh
@@ -46,6 +46,40 @@ test_expect_success \
'git rm --cached foo'
test_expect_success \
+ 'Test that git rm --cached foo succeeds if the index matches the file' \
+ 'echo content > foo
+ git add foo
+ git rm --cached foo'
+
+test_expect_success \
+ 'Test that git rm --cached foo succeeds if the index matches the file' \
+ 'echo content > foo
+ git add foo
+ git commit -m foo
+ echo "other content" > foo
+ git rm --cached foo'
+
+test_expect_failure \
+ 'Test that git rm --cached foo fails if the index matches neither the file nor HEAD' \
+ 'echo content > foo
+ git add foo
+ git commit -m foo
+ echo "other content" > foo
+ git add foo
+ echo "yet another content" > foo
+ git rm --cached foo'
+
+test_expect_success \
+ 'Test that git rm --cached -f foo works in case where --cached only did not' \
+ 'echo content > foo
+ git add foo
+ git commit -m foo
+ echo "other content" > foo
+ git add foo
+ echo "yet another content" > foo
+ git rm --cached -f foo'
+
+test_expect_success \
'Post-check that foo exists but is not in index after git rm foo' \
'[ -f foo ] && ! git ls-files --error-unmatch foo'
--
1.5.3.rc1.4.gaf83-dirty
^ permalink raw reply related
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