* Re: rebase hint unmerged file removed
From: Jeff King @ 2009-08-24 14:36 UTC (permalink / raw)
To: git
In-Reply-To: <20090824140549.GA3973@debian.b2j>
On Mon, Aug 24, 2009 at 10:05:49PM +0800, bill lam wrote:
> Sometimes during rebase -i, it stopped with an unmerged file but that
> file did not have any sections of conflict marked. ls-files showed it
> had :1: and :2: but no :3: I suspected that file was git-rm in that
> commit. Will it be possible for git status or rebase to give hint
> that unmerged file was actually removed?
The version of "git status" in next (and presumably what will be in
v1.6.5) shows unmerged paths with more information. In this case,
you would see something like:
$ echo content >foo && git add foo && git commit -m 'base foo'
$ echo changes >>foo && git add foo && git commit -m 'change foo'
$ git checkout -b other HEAD^
$ git rm foo && git commit -m 'remove foo'
$ git rebase master
$ git status
# Unmerged paths:
# (use "git reset HEAD <file>..." to unstage)
# (use "git add <file>..." to mark resolution)
#
# deleted by them: foo
#
-Peff
^ permalink raw reply
* Re: rebase hint unmerged file removed
From: Johannes Sixt @ 2009-08-24 14:42 UTC (permalink / raw)
To: bill lam; +Cc: git
In-Reply-To: <20090824140549.GA3973@debian.b2j>
bill lam schrieb:
> Sometimes during rebase -i, it stopped with an unmerged file but that
> file did not have any sections of conflict marked. ls-files showed it
> had :1: and :2: but no :3: I suspected that file was git-rm in that
> commit. Will it be possible for git status or rebase to give hint
> that unmerged file was actually removed?
Rebase -i emitted used to write merge-recursive's conflict hints that said
"modify/delete", "modify/rename", "content", etc. I think that's what you
were looking for. But these hints have vanished since quite some time now.
I haven't taken the time, yet, to track down when this happened and why.
-- Hannes
^ permalink raw reply
* Re: Announcement: cvs2svn 2.3.0 released
From: Michael Haggerty @ 2009-08-24 14:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0908241632470.11375@intel-tinevez-2-302>
Johannes Schindelin wrote:
> On Sun, 23 Aug 2009, Michael Haggerty wrote:
>> I am happy to announce release 2.3.0 of cvs2svn/cvs2git/cvs2bzr.
>
> Does it support incremental operation yet? (I.e. do not bother to
> re-import what was imported already?)
No, sorry, incremental conversion is not likely to be developed in the
absence of new volunteers or sponsorship. (But I'd be happy to help a
willing volunteer get started!)
Michael
^ permalink raw reply
* Git workflow: Managing topic branches.
From: Thomas Adam @ 2009-08-24 14:44 UTC (permalink / raw)
To: git list
Hello all,
I've a question regarding a specific workflow which we're currently using
here at work, but I am not convinced it's particularly brilliant -- and
there's a number of oddities about it which I'd like to discus -- perhaps
with a way of coming up with a new solution.
We have a work-flow such as this:
o---o---o---o--o--o (stable)
/
o---o---o---o---o---o---o (master)
\
o---o--o---o---o---o (featureA)
Master is where all our stable code lives after a release -- and also where
bug-fixes for released code is put. When we're working on a new feature,
almost all developers here will push (in this case) to "featureA" ---
eventually this branch will get merged into master, tagged and the code
released. Then a new branch, "featureB" is created off it, and process
continues. (Yes, we're using Git in a very CVS-like way, alas.)
Periodically though we need to release updates for our product. This the
area which is where my question lies about whether the workflow is good or
not. Here's how we do that:
We have a branch called "stable" which contains all of our released code
plus any updates release. When we wish to create a new update, we create a
new branch off the tip of stable:
o---o---o---o (updateN)
/
o---o---o---o--o--o (stable)
/
o---o---o---o---o---o---o (master)
\
o---o--o---o---o---o (featureA)
Because bug-fixes happen on Master, we now want those fixes to appear on the
updateN branch so we can create a tarball from them (to release to our
customers). We're using "git cherry" to get a list of SHA1s that are
relevant between updateN and master, as in:
git cherry updateN master
... and then manually deciding (based on it's "+"/"-" output whether that
SHA1 needs to be used and then:
git cherry-pick SHA1
... onto updateN as appropriate. This branch is then pushed to our
"central" server as a public branch, is checked out elsewhere on another
macine to build this update. If that's successful, various other bits and
bobs in terms of meta data is added into the commits onto the updateN branch
and it is merged into stable:
o---o---o---o (updateN)
/ / <-- (merge updateN to stable)
o---o---o---o--o--o------------o (stable)
/
o---o---o---o---o---o---o (master)
\
o---o--o---o---o---o (featureA)
The "stable" branch is then merged into master so that when we create
another "featureX" branch, it's at a point where it's on a known set of
released code.
So my questions: I am not convinced this workflow is very elegant, or
indeed a particularly good solution to what we're wanting to do. Because
the cherry-picking that happens to the "updateN" branch happens from
"master" which itself will have had several local topic-branches merged into
it from other developers -- I've found "git-cherry" to give unreliable
results -- in some cases, the same two commits with the same data appear on
the "updateN" branch -- using git patch-id manually with processing on top
of that seems to give a much shorter and succient set of SHA1s to
cherry-pick. (But this is kind of peripheral to my question).
I am interested to know if this branch and merge scenario is the right one.
I also don't believe we're using git-cherry in the right way to isolate the
correct commits. I have toyed with the idea of rebasing, but am hesitant on
this idea, and unsure if that would even be the right way to go --
especially seeing as all the branches mentioned are tracking branches.
The eventual aim of all of this is to try and automate building of these
updates -- but we sure as hell can't do that at the moment with our current
workflow. If anyone has any suggestions on any of this, I'd appreciate it.
If I've not explained things adequately. shout and I'll try and clarify.
Thanks in advance,
Thomas Adam
^ permalink raw reply
* sr/gfi-options, was Re: What's cooking in git.git (Aug 2009, #04; Sun, 23)
From: Johannes Schindelin @ 2009-08-24 14:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1vn2qb29.fsf@alter.siamese.dyndns.org>
Hi,
On Sun, 23 Aug 2009, Junio C Hamano wrote:
> * sr/gfi-options (2009-08-13) 3 commits
> - fast-import: test the new option command
> - fast-import: add option command
> - fast-import: put option parsing code in seperate functions
>
> What is this used by?
By a hg-fast-import Sverre was writing for me:
http://github.com/SRabbelier/hg-git/tree/fast-export
Sverre hinted at the possibility of ripping this out of hg-git and putting
it into a hg:// helper.
Ciao,
Dscho
^ permalink raw reply
* Re: gitosis-lite
From: Shawn O. Pearce @ 2009-08-24 15:10 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: Jakub Narebski, Git Mailing List, Tommi Virtanen
In-Reply-To: <2e24e5b90908240735n5f754c87u960493c92769c0a8@mail.gmail.com>
Sitaram Chamarty <sitaramc@gmail.com> wrote:
> On Mon, Aug 24, 2009 at 6:43 PM, Jakub Narebski<jnareb@gmail.com> wrote:
> > Why not contrib/hooks/update-paranoid (which is written in Perl)?
>
> Hmmm several reasons. To start with, it appears to me that
> update-paranoid assumes each user has his own ACL file, and
> I'm going the other way -- you'll notice I have exactly one
> file as a single ACL source for many *projects*, leave alone
> users.
That is true, update-paranoid uses an ACL file per user, because
we approached it from the perspective of "what can this user do"
rather than "what is allowed in this project".
We later ran into needing groups, which meant that in practice the
per-user ACL files really just enumerated what groups they were
a member of, and the group ACL files enumerated what they were
allowed to do in projects.
I can certainly see how this might be backwards, and someone would
prefer the other direction, a per-project listing or something.
> Secondly, I want to stick to the gitosis philosophy -- it
> has served very well, and I'm not sure how "in use"
> update-paranoid is.
Well, my prior job used it heavily, and I think is still using it,
a year after I left. My current job would use it, except that we
went and wrote Gerrit Code Review instead. :-)
> Thirdly, I'm not comfortable having a hook be so complex.
> The whole thing is 10 lines shorter than all my code put
> together :)
Yes, update-paranoid is a big script. It does a lot. It not only
checks "can you write in this repository, on this branch" but it
also checks that every commit matches your own email address(es),
and it can also check file path edits, to see if you can modify
the files that were changed.
> And finally, it's far too complex for me, leave alone some
> of my users. I count 6 pipe opens in there,
Not surprised, it needs to read a lot of data from git to do its
job correctly. It has to enumerate all new commits, any commits
which may be discarded by the update (non-fast-forward), as well
as scan the diff to see which paths were affected.
> and the ACLs
> are read by git cat-file or something
Because I didn't want to check out a copy of the ACLs to the local
disk just to read them into the hook. The hook pulls them directly
out of a bare "admin" repository, making it easier to push changes
into the repository and have them take effect immediately.
I know Gitosis handles this by having a magic hook in the admin
repository that copies the file out. update-paranoid just reads
it from git.
> I'll be honest: I
> came away feeling very stupid after trying to read and
> understand that program. It was... humbling :(
*sigh* That's not good, the hook is meant as a practical example,
if it was too complex to understand, I did a poor job of writing it.
--
Shawn.
^ permalink raw reply
* Re: What's cooking in git.git (Aug 2009, #04; Sun, 23)
From: Johan Herland @ 2009-08-24 15:22 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7v1vn2qb29.fsf@alter.siamese.dyndns.org>
On Monday 24 August 2009, Junio C Hamano wrote:
> * sr/gfi-options (2009-08-13) 3 commits
> - fast-import: test the new option command
> - fast-import: add option command
> - fast-import: put option parsing code in seperate functions
>
> What is this used by?
I'm planning to use it in the CVS remote helper, as a somewhat cleaner
replacement of this one:
> * db/vcs-helper (2009-08-09) 17 commits
> - Allow helpers to request marks for fast-import
In other words, I need one or the other, and I currently find the
gfi-options solution somewhat more elegant than adding the 'marks
<filename>' command to the foreign remote API.
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: gitosis-lite
From: Jakub Narebski @ 2009-08-24 15:43 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: Git Mailing List, Tommi Virtanen
In-Reply-To: <2e24e5b90908240735n5f754c87u960493c92769c0a8@mail.gmail.com>
On Mon, 24 August 2009, Sitaram Chamarty wrote:
> On Mon, Aug 24, 2009 at 6:43 PM, Jakub Narebski<jnareb@gmail.com> wrote:
>
> > Could you add information about this tool (perhaps after confirmation
> > / deciding on project name[1]) to Git Wiki page
> > http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
> > somewhere below Gitosis? Please do not forget to include that it is
> > written in Perl; see other entries for example.
>
> Will do; though I'll probably wait until at least one person
> other than me has used it :)
On the other hand having the link in IFAT wiki page could help you
gain more users of gitosis-lite (name pending ;-)
> > You wrote in project's README.markdown that you were inspired by
> > Gitosis (which requires Python and python-setuptools) and
> > Documentation/howto/update-hook-example.txt (which uses bash).
> > Why not contrib/hooks/update-paranoid (which is written in Perl)?
>
> Hmmm several reasons. To start with, it appears to me that
> update-paranoid assumes each user has his own ACL file, and
> I'm going the other way -- you'll notice I have exactly one
> file as a single ACL source for many *projects*, leave alone
> users.
Well, gitosis uses single SSH user: 'git' (by default, at least).
Also from what I understand update-paranoid uses the same set of ACLs
for all projects (well, depending how $acl_git and $acl_branch are
defined).
> Secondly, I want to stick to the gitosis philosophy -- it
> has served very well, and I'm not sure how "in use"
> update-paranoid is.
I wonder about this too.
> Thirdly, I'm not comfortable having a hook be so complex.
> The whole thing is 10 lines shorter than all my code put
> together :)
The update-paranoid hook has inline POD documentation, which adds to
its size (I think that your gitosis-lite (name pending) should also
use this Perl literate programming convention). On the other hand
this documentation is not, unfortunately, up to date; for example
it allows to control which directories you can change, which is not
documented in POD.
> And finally, it's far too complex for me, leave alone some
> of my users. I count 6 pipe opens in there, and the ACLs
> are read by git cat-file or something :)
That's because update-paranoid, like gitosis, uses configuration in
$scl_repo repository. git-cat-file is low level (plumbing) equivalent
of git-show (porcelain).
Those pipelines are required for strict (paranoid) access control that
update-paranoid uses: checking that committers are on allowed list,
that taggers are on allowed list, that branches points to commits, that
tags points to tag objects, etc.
> I'll be honest: I
> came away feeling very stupid after trying to read and
> understand that program. It was... humbling :(
On the other hand it uses subroutine prototypes (unnecessary, and not
recommended), old-style bareword filehandles instead of lexically scoped
filehandles ("open I, ..." vs "open my $fh, ...")
> > Using Perl code for configuration is simple and fast, but not very
> > secure. Why not use git config format (via "git config -l -z" like in
>
> Not secure in what sense? Only the "git admin" (whoever
> owns the account in which gitosis-lite is running) will be
> able to generate it, and only scripts that run with his
> authority (by way of hooks in repos he owns) can run it.
>
> It cannot do what he did not intend to do, and what he wants
> to do he can do anyway, whether it's JSON or perl.
>
> Except for umasking the file, I don't see anything I missed.
> Could you help me understand?
Ah, thats O.K. then.
>
> > gitweb), or YAML or JSON (or Storable)? Well, YAML might be overkill.
>
> One of the objectives is to work *as is* on any Unix system
> that managed to install git (which implies Perl). So, no
> JSON or YAML. Storable would be fine (I think it's also
> part of core perl) so if I find a compelling reason I don't
> mind switching to that.
One reason to not use Storable is that it is binary. Another that format
is not exactly stable (but it contains version info, so it is backwards
compatibile I think).
As for dependencies: some people on #perl told me to not worry about
dependencies because there is PAR :-)
>
> All I really have is a nested hash to be saved and restored
> -- nothing more complex, no objects, no blessed refs, etc.
JSON would be good then ;-)
>
> > BTW. if you blog about gitosis-lite (http://sitaramc.blogspot.com/)
> > it could be picked up by Perl Iron Man Blogging challenge, and you
> > could get wider review.
>
> Will do; thanks. I did not know my blog got picked up by
> anything; till date it has never come up on a google search
> or a blog search anywhere, and it's more of a rant-box +
> annotated bookmarking service for myself :)
I don't know if it would be picked; still, you can try to submit it to
(join) http://ironman.enlightenedperl.org; note that only posts which
contain one of magic words ('perl', 'ironman', ...) would get picked by
this planet.
>
> > [1]: gitosis-lite doesn't look like CPAN-y name. Git::Admin perlhaps?
>
> Too presumptuous for someone like me -- makes it sound like
> the "one true way to Admin git" :)
Git::Auth perhaps (authentication and authorization)?
Git::AccessControl?
You can always ask on #perl (also on freenode).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] fix simple deepening of a repo
From: Daniel Barkalow @ 2009-08-24 16:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, Johannes Schindelin, git
In-Reply-To: <7vocq5q0j7.fsf@alter.siamese.dyndns.org>
On Sun, 23 Aug 2009, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > If all refs sent by the remote repo during a fetch are reachable
> > locally, then no further conversation is performed with the remote. This
> > check is skipped when the --depth argument is provided to allow the
> > deepening of a shallow clone which corresponding remote repo has no
> > changed.
> >
> > However, some additional filtering was added in commit c29727d5 to
> > remove those refs which are equal on both sides. If the remote repo has
> > not changed, then the list of refs to give the remote process becomes
> > empty and simply attempting to deepen a shallow repo always fails.
> >
> > Let's stop being smart in that case and simply send the whole list over
> > when that condition is met. The remote will do the right thing anyways.
> >
> > Test cases for this issue are also provided.
> >
> > Signed-off-by: Nicolas Pitre <nico@cam.org>
> > ---
>
> Thanks. The fix looks correct (as usual with patches from you).
>
> But it makes me wonder if this logic to filter refs is buying us anything.
>
> > for (rm = refs; rm; rm = rm->next) {
> > + nr_refs++;
> > if (rm->peer_ref &&
> > !hashcmp(rm->peer_ref->old_sha1, rm->old_sha1))
> > continue;
> ALLOC_GROW(heads, nr_heads + 1, nr_alloc);
> heads[nr_heads++] = rm;
> }
>
> What is the point of not asking for the refs that we know are the same?
This code is part of the original C implementation of fetch; I suspect the
optimization was somehow in the shell version and made sense there,
perhaps because there wasn't a quickfetch in the shell version or that
there was some non-negligable per-ref cost in the code around there, since
it was calling helper programs and such.
Anyway, I think it makes sense to remove the filtering from
transport_fetch_refs(), like your patch does.
If it makes a difference for the actual protocol, fetch_refs_via_pack()
could filter them at that stage.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Possible regression: overwriting untracked files in a fresh repo
From: Johannes Schindelin @ 2009-08-24 16:31 UTC (permalink / raw)
To: git
Hi,
I _think_ that this used to complain about untracked files being
overwritten:
$ git init
$ git remote add -f origin <url>
$ git checkout -b blub origin/master
It does not do that here (any longer, IIAC). Intended?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] remove ARM and Mozilla SHA1 implementations
From: Johannes Schindelin @ 2009-08-24 16:52 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0908241333130.11375@intel-tinevez-2-302>
Hi,
On Mon, 24 Aug 2009, Johannes Schindelin wrote:
> On Mon, 24 Aug 2009, Nicolas Pitre wrote:
>
> > On Tue, 18 Aug 2009, Johannes Schindelin wrote:
> >
> > > On Mon, 17 Aug 2009, Nicolas Pitre wrote:
> > >
> > > > They are both slower than the new BLK_SHA1 implementation, so it is
> > > > pointless to keep them around.
> > > >
> > > > Signed-off-by: Nicolas Pitre <nico@cam.org> ---
> > > >
> > > > Someone else would need to make the call for the PPC version.
> > >
> > > If I don't forget, I can test tomorrow on 2 different 32-bit PPCs and
> > > possibly one 64-bit PPC.
> >
> > Did you forget? ;-)
>
> Yes.
At long last (XTools took a real long time to install here; it is an old
PowerPC running MacOSX):
Best of 10 "git rev-list --all" runs on a full Git repository (including
my own tree):
before 30ae47b4
1.85 real, 1.52 user, 0.28 sys
after 30ae47b4
1.86 real, 1.52 user, 0.28 sys
To be frank, the 1.85 looks like an outlier, so I think there is exactly 0
difference between the two.
If you want me to perform other tests, please let me know; I'll be back at
this computer tomorrow.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] import-tars: Allow per-tar author and commit message.
From: Peter Krefting @ 2009-08-24 17:07 UTC (permalink / raw)
To: Nanako Shiraishi, Sam Vilain; +Cc: git
In-Reply-To: <4A91B8BB.1030906@vilain.net>
Nanako Shiraishi:
> Instead of requiring the user to have millions of separate files, how
> about reading a single metainfo file that may look like this?
The advantage of having one (or more) files per tarball is that I can use
the shell's tab completion to make sure I spell the name of the archive
correctly. And that it makes it a lot easier to parse.
Sam Vilain:
> Also I wonder if there isn't a nicer interface for users. Why not allow
> the file to specify From:, Committer: etc as header lines
Good idea. My initial patch was simple, just using the .msg file to add a
message. Then I needed to have a different author for one commit, so I added
the .author file. Then came the changes that are in the current import-tars
that separates author and committer, hence the .committer file. Somewhere
along there it became a bit too complex.
Parsing the .msg file for (optional) committer and author info is probably
better. I'll update the patch.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: [PATCH] Add script for importing bits-and-pieces to Git.
From: Peter Krefting @ 2009-08-24 17:10 UTC (permalink / raw)
To: Thomas Adam; +Cc: git
In-Reply-To: <18071eea0908231328r58b0e22ap20e664d2904420a0@mail.gmail.com>
Thomas Adam:
> Minor nit. Better written as:
> my ($size, $mtime) = (stat(FILE))[7,9];
Ah. Another obscure Perl syntax to consider :-) I'll send an updated patch.
Thanks.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* [PATCH v2] Add script for importing bits-and-pieces to Git.
From: Peter Krefting @ 2009-08-24 17:09 UTC (permalink / raw)
To: git
Allows the user to import version history that is stored in bits and
pieces in the file system, for instance snapshots of old development
trees, or day-by-day backups. A configuration file is used to
describe the relationship between the different files and allow
describing branches and merges, as well as authorship and commit
messages.
Output is created in a format compatible with git-fast-import.
Full documentation is provided inline in perldoc format.
Signed-off-by: Peter Krefting <peter@softwolves.pp.se>
---
Changed the use of stat() as suggested by Thomas Adam.
contrib/fast-import/import-directories.perl | 332 +++++++++++++++++++++++++++
1 files changed, 332 insertions(+), 0 deletions(-)
create mode 100755 contrib/fast-import/import-directories.perl
diff --git a/contrib/fast-import/import-directories.perl b/contrib/fast-import/import-directories.perl
new file mode 100755
index 0000000..98079ad
--- /dev/null
+++ b/contrib/fast-import/import-directories.perl
@@ -0,0 +1,332 @@
+#!/usr/bin/perl -w
+#
+# Copyright 2008-2009 Peter Krefting <peter@softwolves.pp.se>
+#
+# ------------------------------------------------------------------------
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+#
+# ------------------------------------------------------------------------
+
+=pod
+
+=head1 NAME
+
+import-directories - Import bits and pieces to Git.
+
+=head1 SYNOPSIS
+
+B<import-directories.perl> F<configfile>
+
+=head1 DESCRIPTION
+
+Script to import arbitrary projects version controlled by the "copy the
+source directory to a new location and edit it there"-version controlled
+projects into version control. Handles projects with arbitrary branching
+and version trees, taking a file describing the inputs and generating a
+file compatible with the L<git-fast-import(1)> format.
+
+=head1 CONFIGURATION FILE
+
+=head2 Format
+
+The configuration file is using a standard I<.ini> format.
+
+ ; Comments start with semi-colons
+ [section]
+ key=value
+
+=head2 Global configuration
+
+Global configuration is done in the B<[config]> section, which should be
+the first section in the file. Configuration can be changed by
+repeating configuration sections later on.
+
+ [config]
+ ; configure conversion of CRLFs. "convert" means that all CRLFs
+ ; should be converted into LFs (suitable for the core.autocrlf
+ ; setting set to true in Git). "none" means that all data is
+ ; treated as binary.
+ crlf=convert
+
+=head2 Revision configuration
+
+Each revision that is to be imported is described in three
+sections. Sections should be defined chronologically, so that a
+revision's parent has always been defined when a new revision
+is introduced. All sections for one revision should be defined
+before defining the next revision.
+
+Revisions are specified numerically, but they numbers need not be
+consecutive, only unique.
+
+=pod
+
+=head3 Revision description section
+
+A section whose section name is just an integer gives meta-data
+about the revision.
+
+ [3]
+ ; author sets the author of the revisions
+ author=Peter Krefting <peter@softwolves.pp.se>
+ ; branch sets the branch that the revision should be committed to
+ branch=master
+ ; parent describes the revision that is the parent of this commit
+ ; (optional)
+ parent=1
+ ; merges describes a revision that is merged into this commit
+ ; (optional; can be repeated)
+ merges=2
+ ; selects one file to take the timestamp from
+ ; (optional; if unspecified, the most recent file from the .files
+ ; section is used)
+ timestamp=3/source.c
+
+=head3 Revision contents section
+
+A section whose section name is an integer followed by B<.files>
+describes the files included in this revision.
+
+ [3.files]
+ ; the key is the path inside the repository, the value is the path
+ ; as seen from the importer script.
+ source.c=3/source.c
+ source.h=3/source.h
+
+=head3 Revision commit message section
+
+A section whose section name is an integer followed by B<.message>
+gives the commit message. This section is read verbatim.
+
+ [3.message]
+ Implement foobar.
+ ; trailing blank lines are ignored.
+
+=cut
+
+# Globals
+use strict;
+use integer;
+my $crlfmode = 0;
+my @revs;
+my (%revmap, %message, %files, %author, %branch, %parent, %merges, %time, %timesource);
+my $sectiontype = 0;
+my $rev = 0;
+my $mark = 1;
+
+# Check command line
+if ($#ARGV == -1 || $ARGV[0] =~ /^--?h/)
+{
+ exec('perldoc', $0);
+ exit 1;
+}
+
+# Open configuration
+my $config = $ARGV[0];
+open CFG, '<', $config or die "Cannot open configuration file \"$config\": ";
+
+# Open output
+my $output = $ARGV[1];
+open OUT, '>', $output or die "Cannot create output file \"$output\": ";
+binmode OUT;
+
+LINE: while (my $line = <CFG>)
+{
+ $line =~ s/\r?\n$//;
+ next LINE if $sectiontype != 4 && $line eq '';
+ next LINE if $line =~ /^;/;
+ my $oldsectiontype = $sectiontype;
+ my $oldrev = $rev;
+
+ # Sections
+ if ($line =~ m"^\[(config|(\d+)(|\.files|\.message))\]$")
+ {
+ if ($1 eq 'config')
+ {
+ $sectiontype = 1;
+ }
+ elsif ($3 eq '')
+ {
+ $sectiontype = 2;
+ $rev = $2;
+ # Create a new revision
+ die "Duplicate rev: $line\n " if defined $revmap{$rev};
+ print "Reading revision $rev\n";
+ push @revs, $rev;
+ $revmap{$rev} = $mark ++;
+ $time{$revmap{$rev}} = 0;
+ }
+ elsif ($3 eq '.files')
+ {
+ $sectiontype = 3;
+ $rev = $2;
+ die "Revision mismatch: $line\n " unless $rev == $oldrev;
+ }
+ elsif ($3 eq '.message')
+ {
+ $sectiontype = 4;
+ $rev = $2;
+ die "Revision mismatch: $line\n " unless $rev == $oldrev;
+ }
+ else
+ {
+ die "Internal parse error: $line\n ";
+ }
+ next LINE;
+ }
+
+ # Parse data
+ if ($sectiontype != 4)
+ {
+ # Key and value
+ if ($line =~ m"^(.*)=(.*)$")
+ {
+ my ($key, $value) = ($1, $2);
+ # Global configuration
+ if (1 == $sectiontype)
+ {
+ if ($key eq 'crlf')
+ {
+ $crlfmode = 1, next LINE if $value eq 'convert';
+ $crlfmode = 0, next LINE if $value eq 'none';
+ }
+ die "Unknown configuration option: $line\n ";
+ }
+ # Revision specification
+ if (2 == $sectiontype)
+ {
+ my $current = $revmap{$rev};
+ $author{$current} = $value, next LINE if $key eq 'author';
+ $branch{$current} = $value, next LINE if $key eq 'branch';
+ $parent{$current} = $value, next LINE if $key eq 'parent';
+ $timesource{$current} = $value, next LINE if $key eq 'timestamp';
+ push(@{$merges{$current}}, $value), next LINE if $key eq 'merges';
+ die "Unknown revision option: $line\n ";
+ }
+ # Filespecs
+ if (3 == $sectiontype)
+ {
+ # Add the file and create a marker
+ die "File not found: $line\n " unless -f $value;
+ my $current = $revmap{$rev};
+ ${$files{$current}}{$key} = $mark;
+ my $time = &fileblob($value, $crlfmode, $mark ++);
+
+ # Update revision timestamp if more recent than other
+ # files seen, or if this is the file we have selected
+ # to take the time stamp from using the "timestamp"
+ # directive.
+ if ((defined $timesource{$current} && $timesource{$current} eq $value)
+ || $time > $time{$current})
+ {
+ $time{$current} = $time;
+ }
+ }
+ }
+ else
+ {
+ die "Parse error: $line\n ";
+ }
+ }
+ else
+ {
+ # Commit message
+ my $current = $revmap{$rev};
+ if (defined $message{$current})
+ {
+ $message{$current} .= "\n";
+ }
+ $message{$current} .= $line;
+ }
+}
+close CFG;
+
+# Start spewing out data for git-fast-import
+foreach my $commit (@revs)
+{
+ # Progress
+ print OUT "progress Creating revision $commit\n";
+
+ # Create commit header
+ my $mark = $revmap{$commit};
+
+ # Branch and commit id
+ print OUT "commit refs/heads/", $branch{$mark}, "\nmark :", $mark, "\n";
+
+ # Author and timestamp
+ die "No timestamp defined for $commit (no files?)\n" unless defined $time{$mark};
+ print OUT "committer ", $author{$mark}, " ", $time{$mark}, " +0100\n";
+
+ # Commit message
+ die "No message defined for $commit\n" unless defined $message{$mark};
+ my $message = $message{$mark};
+ $message =~ s/\n$//; # Kill trailing empty line
+ print OUT "data ", length($message), "\n", $message, "\n";
+
+ # Parent and any merges
+ print OUT "from :", $revmap{$parent{$mark}}, "\n" if defined $parent{$mark};
+ if (defined $merges{$mark})
+ {
+ foreach my $merge (@{$merges{$mark}})
+ {
+ print OUT "merge :", $revmap{$merge}, "\n";
+ }
+ }
+
+ # Output file marks
+ print OUT "deleteall\n"; # start from scratch
+ foreach my $file (sort keys %{$files{$mark}})
+ {
+ print OUT "M 644 :", ${$files{$mark}}{$file}, " $file\n";
+ }
+ print OUT "\n";
+}
+
+# Create one file blob
+sub fileblob
+{
+ my ($filename, $crlfmode, $mark) = @_;
+
+ # Import the file
+ print OUT "progress Importing $filename\nblob\nmark :$mark\n";
+ open FILE, '<', $filename or die "Cannot read $filename\n ";
+ binmode FILE;
+ my ($size, $mtime) = (stat(FILE))[7,9];
+ my $file;
+ read FILE, $file, $size;
+ close FILE;
+ $file =~ s/\r\n/\n/g if $crlfmode;
+ print OUT "data ", length($file), "\n", $file, "\n";
+
+ return $time;
+}
+
+__END__
+
+=pod
+
+=head1 EXAMPLES
+
+B<import-directories.perl> F<project.import>
+
+=head1 AUTHOR
+
+Copyright 2008-2009 Peter Krefting E<lt>peter@softwolves.pp.se>
+
+This program is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation.
+
+=cut
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] remove ARM and Mozilla SHA1 implementations
From: Nicolas Pitre @ 2009-08-24 17:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0908241849160.8306@pacific.mpi-cbg.de>
On Mon, 24 Aug 2009, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 24 Aug 2009, Johannes Schindelin wrote:
>
> > On Mon, 24 Aug 2009, Nicolas Pitre wrote:
> >
> > > On Tue, 18 Aug 2009, Johannes Schindelin wrote:
> > >
> > > > On Mon, 17 Aug 2009, Nicolas Pitre wrote:
> > > >
> > > > > They are both slower than the new BLK_SHA1 implementation, so it is
> > > > > pointless to keep them around.
> > > > >
> > > > > Signed-off-by: Nicolas Pitre <nico@cam.org> ---
> > > > >
> > > > > Someone else would need to make the call for the PPC version.
> > > >
> > > > If I don't forget, I can test tomorrow on 2 different 32-bit PPCs and
> > > > possibly one 64-bit PPC.
> > >
> > > Did you forget? ;-)
> >
> > Yes.
>
> At long last (XTools took a real long time to install here; it is an old
> PowerPC running MacOSX):
>
> Best of 10 "git rev-list --all" runs on a full Git repository (including
> my own tree):
>
> before 30ae47b4
>
> 1.85 real, 1.52 user, 0.28 sys
>
> after 30ae47b4
>
> 1.86 real, 1.52 user, 0.28 sys
>
> To be frank, the 1.85 looks like an outlier, so I think there is exactly 0
> difference between the two.
Maybe there wasn't any _code_ difference after all. According to the
Makefile, only mingw defines NO_OPENSSL (although there might certainly
be others).
TRy a build with PPC_SHA1=1, and then compare with BLK_SHA1=1.
And best is to time a fsck --full.
Nicolas
^ permalink raw reply
* Re: [PATCH] send-email: confirm on empty mail subjects
From: Jan Engelhardt @ 2009-08-24 17:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhbwlpigo.fsf@alter.siamese.dyndns.org>
On Thursday 2009-08-06 08:25, Junio C Hamano wrote:
>Jan Engelhardt <jengelh@medozas.de> writes:
>
>> When the user forgot to enter a subject in a compose session,
>> send-email will now inquire whether this is really intended, similar
>> to what the Alpine MUA does when a subject is absent.
>
>This seems to break t9001...
>
Did I miss something in building?
19:26 sovereign:../git/git-1.6.4.1 > quilt pu
Applying patch patches/send-email-empty-subject.diff
patching file git-send-email.perl
Now at patch patches/send-email-empty-subject.diff
19:26 sovereign:../git/git-1.6.4.1 > cd t
19:26 sovereign:../git-1.6.4.1/t > ./t9001-send-email.sh
* ok 1: prepare reference tree
* ok 2: Setup helper tool
* ok 3: Extract patches
* ok 4: No confirm with --suppress-cc
* ok 5: No confirm with --confirm=never
* ok 6: No confirm with sendemail.confirm=never
* ok 7: Send patches
* ok 8: Verify commandline
* ok 9: Show all headers
* ok 10: Prompting works
* ok 11: cccmd works
* ok 12: reject long lines
* ok 13: no patch was sent
* ok 14: Author From: in message body
* ok 15: Author From: not in message body
* ok 16: allow long lines with --no-validate
* ok 17: Invalid In-Reply-To
* ok 18: Valid In-Reply-To when prompting
* ok 19: setup fake editor
* ok 20: --compose works
* ok 21: first message is compose text
* ok 22: second message is patch
* ok 23: sendemail.cc set
* ok 24: sendemail.cc unset
* ok 25: sendemail.cccmd
* ok 26: --suppress-cc=all
* ok 27: --suppress-cc=body
* ok 28: --suppress-cc=body --suppress-cc=cccmd
* ok 29: --suppress-cc=sob
* ok 30: --suppress-cc=bodycc
* ok 31: --suppress-cc=cc
* ok 32: --confirm=always
* ok 33: --confirm=auto
* ok 34: --confirm=cc
* ok 35: --confirm=compose
* ok 36: confirm by default (due to cc)
* ok 37: confirm by default (due to --compose)
* ok 38: confirm detects EOF (inform assumes y)
* ok 39: confirm detects EOF (auto causes failure)
* ok 40: confirm doesnt loop forever
* ok 41: utf8 Cc is rfc2047 encoded
* ok 42: --compose adds MIME for utf8 body
* ok 43: --compose respects user mime type
* ok 44: --compose adds MIME for utf8 subject
* ok 45: detects ambiguous reference/file conflict
* ok 46: feed two files
* ok 47: in-reply-to but no threading
* ok 48: no in-reply-to and no threading
* ok 49: threading but no chain-reply-to
* passed all 49 test(s)
^ permalink raw reply
* [PATCH v2] import-tars: Allow per-tar author and commit message.
From: Peter Krefting @ 2009-08-24 17:55 UTC (permalink / raw)
To: git
Instead of having each imported tar ball's commit message be "Imported
from filename.tar", optionally take a commit message from a file
called "filename.tar.msg". The author and committer of the tar ball
can also be overridden by embedding an "Author:" or "Committer:" header
in the .msg file.
Signed-off-by: Peter Krefting <peter@softwolves.pp.se>
---
Instead of having a .author and .committer file to override the author
and committer, allow embedding this information in the .msg file, as
suggested by Sam Vilain <sam@vilain.net>.
contrib/fast-import/import-tars.perl | 38 +++++++++++++++++++++++++++++++--
1 files changed, 35 insertions(+), 3 deletions(-)
diff --git a/contrib/fast-import/import-tars.perl b/contrib/fast-import/import-tars.perl
index 78e40d2..0d59434 100755
--- a/contrib/fast-import/import-tars.perl
+++ b/contrib/fast-import/import-tars.perl
@@ -109,12 +109,44 @@ foreach my $tar_file (@ARGV)
$have_top_dir = 0 if $top_dir ne $1;
}
+ # Optionally read a commit message from <filename.tar>.msg
+ # Add a line on the form "Committer: name <e-mail>" to override
+ # the committer and "Author: name <e-mail>" to override the
+ # author for this tar ball.
+ my $commit_msg = "Imported from $tar_file.";
+ my $this_committer_name = $committer_name;
+ my $this_committer_email = $committer_email;
+ my $this_author_name = $author_name;
+ my $this_author_email = $author_email;
+ if (open MSG, '<', "${tar_file}.msg")
+ {
+ $commit_msg = '';
+ while (<MSG>)
+ {
+ if (/^Committer:\s+([^<>]*)\s+<(.*)>\s*$/i)
+ {
+ $this_committer_name = $1;
+ $this_committer_email = $2;
+ }
+ elsif (/^Author:\s+([^<>]*)\s+<(.*)>\s*$/i)
+ {
+ $this_author_name = $1;
+ $this_author_email = $2;
+ }
+ else
+ {
+ $commit_msg .= $_;
+ }
+ }
+ close MSG;
+ }
+
print FI <<EOF;
commit $branch_ref
-author $author_name <$author_email> $author_time +0000
-committer $committer_name <$committer_email> $commit_time +0000
+author $this_author_name <$this_author_email> $author_time +0000
+committer $this_committer_name <$this_committer_email> $commit_time +0000
data <<END_OF_COMMIT_MESSAGE
-Imported from $tar_file.
+$commit_msg
END_OF_COMMIT_MESSAGE
deleteall
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] send-email: confirm on empty mail subjects
From: Junio C Hamano @ 2009-08-24 18:19 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: git
In-Reply-To: <alpine.LSU.2.00.0908241927300.5382@fbirervta.pbzchgretzou.qr>
Jan Engelhardt <jengelh@medozas.de> writes:
> On Thursday 2009-08-06 08:25, Junio C Hamano wrote:
>
>>Jan Engelhardt <jengelh@medozas.de> writes:
>>
>>> When the user forgot to enter a subject in a compose session,
>>> send-email will now inquire whether this is really intended, similar
>>> to what the Alpine MUA does when a subject is absent.
>>
>>This seems to break t9001...
>>
>
> Did I miss something in building?
>
> 19:26 sovereign:../git/git-1.6.4.1 > quilt pu
> Applying patch patches/send-email-empty-subject.diff
> patching file git-send-email.perl
Is this using 'pu' with your patch? Near the tip of the 'pu' branch I
have a iffy workaround to "unbreak" the issue, but it is a rather
sledgehammer approach I do not feel comfortable enough to squash into your
patch yet.
^ permalink raw reply
* Re: Pulling one commit at a time.
From: Avery Pennarun @ 2009-08-24 18:19 UTC (permalink / raw)
To: Sanjiv Gupta; +Cc: Nanako Shiraishi, git
In-Reply-To: <4A92318F.6050105@microchip.com>
On Mon, Aug 24, 2009 at 6:22 AM, Sanjiv Gupta<sanjiv.gupta@microchip.com> wrote:
> Excellent description. Thanks for that. I want to merge commits one by one
> because I want to run a regression suite on each commit and therefore know
> if any one is causing failures.
Hi Sanjiv,
'git bisect' is an even better way to do this, in my experience. I
wrote a program (http://github.com/apenwarr/gitbuilder/) that
automatically runs regression tests against all the new versions on
all the new branches. It then publishes the results on a web page and
via RSS.
gitbuilder does take a shortcut: if commit x passes and commit x+10
passes, it doesn't bother to test commit x+1..9. However, if x+10
fails, it bisects automatically to find the first commit that caused a
failure. You could disable this shortcut easily enough, however.
Have fun,
Avery
^ permalink raw reply
* Re: What's cooking in git.git (Aug 2009, #04; Sun, 23)
From: Adam Simpkins @ 2009-08-24 18:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git@vger.kernel.org
In-Reply-To: <7v1vn2qb29.fsf@alter.siamese.dyndns.org>
On Sun, Aug 23, 2009 at 06:01:50PM -0700, Junio C Hamano wrote:
>
> * as/maint-graph-interesting-fix (2009-08-18) 1 commit.
> - graph API: fix bug in graph_is_interesting()
>
> I need to queue the associated test after getting it signed-off.
Whoops. Sorry about that.
Signed-off-by: Adam Simpkins <simpkins@facebook.com>
--
Adam Simpkins
simpkins@facebook.com
^ permalink raw reply
* Re: [PATCH] Add script for importing bits-and-pieces to Git.
From: Randal L. Schwartz @ 2009-08-24 18:37 UTC (permalink / raw)
To: Peter Krefting; +Cc: Thomas Adam, git
In-Reply-To: <alpine.DEB.2.00.0908241909420.16576@perkele.intern.softwolves.pp.se>
>>>>> "Peter" == Peter Krefting <peter@softwolves.pp.se> writes:
Peter> Ah. Another obscure Perl syntax to consider :-) I'll send an updated
Peter> patch. Thanks.
It's fair game to say it's not "obscure" if it's in Learning Perl,
and that was in Learning Perl.
Minor trivia note: that's one of the three Perl syntax features
that I can take credit for having created, back in the day.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
^ permalink raw reply
* Re: gitosis-lite
From: Jakub Narebski @ 2009-08-24 18:44 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: Git Mailing List, Tommi Virtanen
In-Reply-To: <2e24e5b90908240528v56fdf30cq4c046fca321a3b17@mail.gmail.com>
Sitaram Chamarty <sitaramc@gmail.com> writes:
> I created a new project called gitosis-lite, which combines
> the essential pieces of gitosis with the per-branch
> permissions stuff in the example in the howto directory of
> git.git.
As for the name: gitness, gitamine, gitrify,... ;-)
> The config file is different, (there's an annotated example
> you can look at).
>
> The "why" and the "what" are all at
> http://github.com/sitaramc/gitosis-lite
A few comments about the code, taking gl-auth-command as example.
> #!/usr/bin/perl -w
>
> use strict;
Wouldn't it be better to use "use warnings" instead of 'perl -w'?
> # === auth-command ===
> # the command that GL users actually run
>
> # part of the gitosis-lite (GL) suite
>
> # how run: via sshd, being listed in "command=" in ssh authkeys
> # when: every login by a GL user
> # input: $1 is GL username, plus $SSH_ORIGINAL_COMMAND
> # output:
> # security:
> # - currently, we just make some basic checks, copied from gitosis
>
> # robustness:
>
> # other notes:
It would be, I think, better if you have used POD for such
documentation. One would be able to generate manpage using pod2man,
and it is no less readable in source code. See e.g. perl/Git.pm or
contrib/hooks/update-paranoid.
> our $GL_ADMINDIR;
> our $GL_CONF;
> our $GL_KEYDIR;
> our $GL_CONF_COMPILED;
> our $REPO_BASE;
> our %repos;
Why is the reason behind using 'our' instead of 'my' here?
> # first, fix the biggest gripe I have with gitosis, a 1-line change
> my $user=$ENV{GL_USER}=shift; # there; now that's available everywhere!
Eh? This is standalone script, isn't it? Shouldn't it be
my $user = $ENV{GL_USER} = $ARGV[0]; # there; now that's available everywhere!
> my $perm = 'W'; $perm = 'R' if $verb =~ $R_COMMANDS;
Either split it into two lines, or use ?: confitional operator:
my $perm = ($verb =~ $R_COMMANDS ? 'R' : 'W');
> open(LOG, ">>", "$GL_ADMINDIR/log");
> print LOG "\n", scalar(localtime), " $ENV{SSH_ORIGINAL_COMMAND} $user\n";
> close(LOG);
It is better practice to use lexical variables instead of barewords
for filehandles:
if (open my $logfh, ">>", "$GL_ADMINDIR/log") {
print $logfh "\n", scalar(localtime), " $ENV{SSH_ORIGINAL_COMMAND} $user\n";
close $logfh;
}
Don't forget to check for error.
> $repo = "'$REPO_BASE/$repo.git'";
> exec("git", "shell", "-c", "$verb $repo");
That's not enough. You have to shell-quote $repo, like in gitweb or
using String::ShellQuote module, or somehow use list form to pass
arguments to git-shell. You protect here againts spaces in filename,
but not againts "'" (single quote) and for show shells "!"
(exclamation mark).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: sr/gfi-options, was Re: What's cooking in git.git (Aug 2009, #04; Sun, 23)
From: Sverre Rabbelier @ 2009-08-24 18:45 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0908241641390.11375@intel-tinevez-2-302>
Heya,
On Mon, Aug 24, 2009 at 07:45, Johannes
Schindelin<Johannes.Schindelin@gmx.de> wrote:
> On Sun, 23 Aug 2009, Junio C Hamano wrote:
>> * sr/gfi-options (2009-08-13) 3 commits
>> - fast-import: test the new option command
>> - fast-import: add option command
>> - fast-import: put option parsing code in seperate functions
>>
>> What is this used by?
>
> By a hg-fast-import Sverre was writing for me:
And possibly also by the p4 helper I think?
> Sverre hinted at the possibility of ripping this out of hg-git and putting
> it into a hg:// helper.
I don't know if I have time for that this week, but it's at the top of
my todo list :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] import-tars: Allow per-tar author and commit message.
From: Junio C Hamano @ 2009-08-24 18:54 UTC (permalink / raw)
To: Peter Krefting; +Cc: Nanako Shiraishi, Sam Vilain, git
In-Reply-To: <alpine.DEB.2.00.0908241659380.16576@perkele.intern.softwolves.pp.se>
Peter Krefting <peter@softwolves.pp.se> writes:
> Nanako Shiraishi:
>
>> Instead of requiring the user to have millions of separate files,
>> how about reading a single metainfo file that may look like this?
>
> The advantage of having one (or more) files per tarball is that I can
> use the shell's tab completion to make sure I spell the name of the
> archive correctly. And that it makes it a lot easier to parse.
>
>
> Sam Vilain:
>
>> Also I wonder if there isn't a nicer interface for users. Why not allow
>> the file to specify From:, Committer: etc as header lines
>
> Good idea.
That sounds like a sensible thing to do.
I however am a bit uneasy to see that the patch didn't seem to (and the
rerolled one does not seem to, either) allow any way to forbid reading of
the .msg files, other than an obvious workaround of running "find | xargs
rm" beforehand. Unlike your "import-directories" that is a brand new
program without any existing users, you are touching code that other
people have already used, and you do not want to change the behaviour for
them only because they happen to have unrelated files in the same
directory.
^ permalink raw reply
* Re: Possible regression: overwriting untracked files in a fresh repo
From: Jeff King @ 2009-08-24 19:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0908241829510.11375@intel-tinevez-2-302>
On Mon, Aug 24, 2009 at 06:31:21PM +0200, Johannes Schindelin wrote:
> I _think_ that this used to complain about untracked files being
> overwritten:
>
> $ git init
> $ git remote add -f origin <url>
> $ git checkout -b blub origin/master
>
> It does not do that here (any longer, IIAC). Intended?
I agree that it probably _should_ complain, but I don't think it ever
did. I tried a handful of released versions as far back as v1.4.4, and
all of them overwrite local files without complaining. My test was:
-- >8 --
#!/bin/sh
rm -rf parent child
mkdir parent && (
cd parent &&
git init-db &&
echo content >file &&
git add file &&
git commit -m add
) &&
mkdir child && (
cd child &&
git init-db &&
git fetch ../parent master:origin &&
echo precious >file &&
! git checkout -b foo origin
)
-- >8 --
However, if I then do this:
(cd parent && echo content >another && git add . && git commit -m more)
(cd child && git fetch ../parent && git checkout -b new FETCH_HEAD)
then it does complain. I'm guessing there is a different code path for
the case that we have no index at all, and that it is not properly
checking for overwrites.
But now I have a small child waking up so I can't look into it further.
:)
-Peff
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox