* fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.
From: Thomas Glanzmann @ 2007-06-08 10:08 UTC (permalink / raw)
To: GIT
Hello,
(s017241) [/usr/src/linux-2.6] git checkout v2.6.20
warning: You appear to be on a branch yet to be born.
warning: Forcing checkout of v2.6.20.
fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions
Cannot detach HEAD
(s017241) [/usr/src/linux-2.6] git version
git version 1.5.2.1
what is going wrong here?
Thomas
^ permalink raw reply
* Re: [PATCH] Fix push with refspecs containing wildcards
From: Alex Riesen @ 2007-06-08 9:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin
In-Reply-To: <7vodjqlwnc.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano, Fri, Jun 08, 2007 09:42:47 +0200:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > Sending a fix is a good thing, but whenever doing one, could
> > people please also do a testcase that demonstrates the original
> > bug, and also a demonstration that the fix does not introduce
> > regression?
Sorry. I actually have a test script I used to develop the fix,
but somehow missed to send it.
> > For this one, obviously a test for push that uses such wildcard
> > ref is needed but at the same time we would want a test for push
> > that does _not_ use a wildcard, fetch that uses a wildcard, and
> > a fetch that does not use a wildcard.
>
> How about this?
> ---
>
> t/t5516-fetch-push.sh | 82 +++++++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 82 insertions(+), 0 deletions(-)
>
Gratefully-Acked-by: Alex Riesen <raa.lkml@gmail.com>
^ permalink raw reply
* Re: Spec file for StGIT (or equivalent)
From: Catalin Marinas @ 2007-06-08 8:46 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200706080224.20493.jnareb@gmail.com>
On 08/06/07, Jakub Narebski <jnareb@gmail.com> wrote:
> I can see that stgit repository contains some helper files to build deb
> package. How to build rpm package from current version of stgit?
python setup.py bdist_rpm
I have a release script that build rpm and dist, I should add it to
the contrib dir.
> Is here main version planned to be released soon?
Yes, 0.13, in about a week or as soon as I clear some of the bugs in
https://gna.org/bugs/?group=stgit.
--
Catalin
^ permalink raw reply
* Re: [PATCH] git-branch: cleanup config file when deleting branches
From: Junio C Hamano @ 2007-06-08 8:45 UTC (permalink / raw)
To: Gerrit Pape; +Cc: git
In-Reply-To: <20070606100947.18990.qmail@bef1f6489d171f.315fe32.mid.smarden.org>
Gerrit Pape <pape@smarden.org> writes:
> When deleting branches, remove the sections referring to these branches
> from the config file.
>
> Signed-off-by: Gerrit Pape <pape@smarden.org>
Hmph. Makes sense and might even be a maint material, but it
probably is safe not to do a behaviour change in maint.
Tests?
^ permalink raw reply
* Re: [PATCH] gitweb: change filename/directory name of snapshots
From: Junio C Hamano @ 2007-06-08 8:43 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git
In-Reply-To: <20070607092708.GA25097@moooo.ath.cx>
Matthias Lederhofer <matled@gmx.net> writes:
> /.git or .git is removed from the project name and the
> basename of the remaining path is used as the beginning of
> the filename and as the directory in the archive.
>
> The regexp will actually not strip off /.git or .git if there
> wouldn't be anything left after removing it.
>
> Currently the full project name is used as directory in the
> archive and the basename is used as filename. For example a
> repository named foo/bar/.git will have a archive named
> .git-<version>.* and extract to foo/bar/.git. With this patch
> the file is named bar-<version>.* and extracts to bar.
Makes sense to me for "foo/bar/.git", but I am not sure if we
would want to do this to "foo/bar.git". Opinions?
^ permalink raw reply
* Re: [PATCH] fsck: do not crash on tag objects which do not contain an empty line
From: Andy Parkins @ 2007-06-08 8:32 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, gitster
In-Reply-To: <Pine.LNX.4.64.0706072338260.4046@racer.site>
On Thursday 2007 June 07, Johannes Schindelin wrote:
> + error("tag %s does not contain any tag?", refname);
Seems a bad error message to me. Also, why is it a question?
git: tag does not contain a tag
user: WTF?
Perhaps, "The annotated tag, %s, does not contain a message", or similar?
Also - is this really something that should be complained about? I'm
wondering why it is important that tag objects contain a message? For
example, tagging a release as v1.0.0 - it's important to record who tagged
it, and when it was tagged, but I can certainly envisage there not being a
message to go with it. Most tags in the git repository are just a repeat of
the tag name in the message.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: [PATCH] Fix failed tag parsing when tag object has no body/message (and thus ends with a single '\n')
From: Johan Herland @ 2007-06-08 8:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin
In-Reply-To: <7vd507m159.fsf@assigned-by-dhcp.cox.net>
On Friday 08 June 2007, Junio C Hamano wrote:
> Johan Herland <johan@herland.net> writes:
>
> > Thanks to Johannes Schindelin <Johannes.Schindelin@gmx.de> for
> > discovering this.
> >
> > Also add a testcase for this condition.
> >
> > Signed-off-by: Johan Herland <johan@herland.net>
>
> While this certainly is an improvement, I suspect that your
> parse_tag() does a little too much. In a format such as "tag"
> object that does header + blank + body, it is customary to allow
> header fields that your version does not understand (assuming
> that such extention will go after the known fields is fine).
>
> Which means that you should not be even saying "Ok, I've checked all
> headers I know about---there should be a double LF to terminate it",
> as you do not know if headers have ended.
Ok, I'm currently working on a patch series for Dscho and others where I
split up the big patch ('[PATCH 1/6] Refactor git tag objects; make "tag"
header optional; introduce new optional "keywords" header') into babysteps.
I can:
1. Provide a new patch series to totally replace the previous 6-part patch
series (plus bugfixes). The new patch series will make smaller steps and
end up (hopefully) in a better place, with less overzealous
checking/parsing, and more "traditional" whitespacing.
OR
2. Provide the babystep-series ending up exactly where we are today (i.e.
after the patch series, plus bug fixes). Then, provide patches on top of
the existing series to get it into shape, both scope-wise (i.e. not trying
to do too much) and whitespace-wise.
Which do you prefer?
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH] Fix push with refspecs containing wildcards
From: Junio C Hamano @ 2007-06-08 7:42 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Johannes Schindelin
In-Reply-To: <7v4pljlzm3.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> Sending a fix is a good thing, but whenever doing one, could
> people please also do a testcase that demonstrates the original
> bug, and also a demonstration that the fix does not introduce
> regression?
>
> For this one, obviously a test for push that uses such wildcard
> ref is needed but at the same time we would want a test for push
> that does _not_ use a wildcard, fetch that uses a wildcard, and
> a fetch that does not use a wildcard.
How about this?
---
t/t5516-fetch-push.sh | 82 +++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 82 insertions(+), 0 deletions(-)
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
new file mode 100755
index 0000000..dba018f
--- /dev/null
+++ b/t/t5516-fetch-push.sh
@@ -0,0 +1,80 @@
+#!/bin/sh
+
+test_description='fetching and pushing, with or without wildcard'
+
+. ./test-lib.sh
+
+mk_empty () {
+ rm -fr testrepo &&
+ mkdir testrepo &&
+ (
+ cd testrepo &&
+ git init
+ )
+}
+
+test_expect_success setup '
+
+ : >path1 &&
+ git add path1 &&
+ test_tick &&
+ git commit -a -m repo &&
+ the_commit=$(git show-ref -s --verify refs/heads/master)
+
+'
+
+test_expect_success 'fetch without wildcard' '
+ mk_empty &&
+ (
+ cd testrepo &&
+ git fetch .. refs/heads/master:refs/remotes/origin/master &&
+
+ r=$(git show-ref -s --verify refs/remotes/origin/master) &&
+ test "z$r" = "z$the_commit" &&
+
+ test 1 = $(git for-each-ref refs/remotes/origin | wc -l)
+ )
+'
+
+test_expect_success 'fetch with wildcard' '
+ mk_empty &&
+ (
+ cd testrepo &&
+ git config remote.up.url .. &&
+ git config remote.up.fetch "refs/heads/*:refs/remotes/origin/*" &&
+ git fetch up &&
+
+ r=$(git show-ref -s --verify refs/remotes/origin/master) &&
+ test "z$r" = "z$the_commit" &&
+
+ test 1 = $(git for-each-ref refs/remotes/origin | wc -l)
+ )
+'
+
+test_expect_success 'push without wildcard' '
+ mk_empty &&
+
+ git push testrepo refs/heads/master:refs/remotes/origin/master &&
+ (
+ cd testrepo &&
+ r=$(git show-ref -s --verify refs/remotes/origin/master) &&
+ test "z$r" = "z$the_commit" &&
+
+ test 1 = $(git for-each-ref refs/remotes/origin | wc -l)
+ )
+'
+
+test_expect_success 'push with wildcard' '
+ mk_empty &&
+
+ git push testrepo "refs/heads/*:refs/remotes/origin/*" &&
+ (
+ cd testrepo &&
+ r=$(git show-ref -s --verify refs/remotes/origin/master) &&
+ test "z$r" = "z$the_commit" &&
+
+ test 1 = $(git for-each-ref refs/remotes/origin | wc -l)
+ )
+'
+
+test_done
^ permalink raw reply related
* Re: [PATCH] Teach filter-branch about subdirectory filtering
From: Johannes Sixt @ 2007-06-08 7:19 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0706080603520.4059@racer.site>
Johannes Schindelin wrote:
> It's just a guess, but now that we come really, really close to having a
> concise implementation of git-subproject which will probably soon
> propagate to master, and then maint, I gather that more and more people
> come and want to split their projects (which they maintained as one big
> project) into several subprojects (which they should have been from the
> start, but the tool did not easily allow for that).
I think that --subdirectry-filter needs to become a bit smarter to be
really useful for splitting a big project into sub-projects plus a
super-project. The reason is that once you have extracted the
sub-project(s), you have a hard time to find out which commits to
gitlink into the super-project. I don't have a plan how to make it
smarter, though.
-- Hannes
^ permalink raw reply
* Re: gitk highlighting commits
From: Shawn O. Pearce @ 2007-06-08 6:57 UTC (permalink / raw)
To: picca; +Cc: git
In-Reply-To: <20070608084501.1b66f16a@localhost.localdomain>
picca <picca@synchrotron-soleil.Fr> wrote:
> I am using git to follow the wine development. And I wondering if it
> is possible to highlight all the commit since my last git pull ?
If you do it *right after* the pull, you can see those commits that
are new to you with:
gitk ORIG_HEAD..
ORIG_HEAD is a special name for the commit that you had just before
you pulled. So you are asking gitk to show you all commits that
are now in your current branch (implied by nothing to the right of
the ..) that were not in your branch before the pull (ORIG_HEAD).
That is the stuff you just pullled.
If its many days later that you want to look at this and you have
done some things that overwrite ORIG_HEAD (git reset; git rebase;
etc.) then this becomes more difficult. But you can also do by
time:
gitk HEAD@{2.days.ago}..
This shows you everything that is new *to you* in the past two days.
Even if the changes were created months ago and just recently were
pulled by you yesterday, they will appear in gitk, because you asked
for *your* history over the past two days, not the project history.
These same tricks also work with git-log of course:
git log ORIG_HEAD...
git log HEAD@{2.days.ago}..
You could also take a look at the manual page for git-rev-parse,
there are some more details covered there I think.
--
Shawn.
^ permalink raw reply
* Re: gitk highlighting commits
From: Marius Storm-Olsen @ 2007-06-08 6:55 UTC (permalink / raw)
To: picca; +Cc: git
In-Reply-To: <20070608084501.1b66f16a@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 686 bytes --]
picca said the following on 08.06.2007 08:45:
> Hello
>
> I am using git to follow the wine development. And I wondering if it
> is possible to highlight all the commit since my last git pull ?
>
> Indeed there is so many commits that I can not remenber the
> last one I red before I did this git pull.
You _could_ do:
Simply use a tag to mark the HEAD commit before you do the next pull.
git tag LastReadCommit
(HEAD is implicit on the tag command)
The tag will then be displayed in gitk, so you know where you left
off. Then, when you're done, simply move the tag to the new HEAD.
git tag -d LastReadCommit
git tag LastReadCommit
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: git-stash
From: Matthias Lederhofer @ 2007-06-08 6:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0706072328000.4046@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> I just was in the need for git-stash (for the 1e6th time this year), but
> instead of writing a script, I though I'd try the "!" convention for
> aliases. Works quite well for me:
I have scripts saving and restoring the current state of the working
tree in the current branch using two commits: one is the current index
and the other one the index after adding all changes.
% tail -n 1000 save restore
==> save <==
#!/bin/sh
set -e
die() { echo "$0: $*" >&2; exit 1; }
parent=$(git rev-parse HEAD^0 2> /dev/null) || die requires at least one commit
tree=$(git write-tree)
commit=$(echo wip index | git commit-tree $tree -p $parent)
git diff-files --name-only -z | git update-index --remove -z --stdin
tree=$(git write-tree)
commit=$(echo wip working tree | git commit-tree $tree -p $commit)
git update-ref -m 'wip save' HEAD $commit
echo saved wip
==> restore <==
#!/bin/sh
set -e
die() { echo "$0: $*" >&2; exit 1; }
p=$(git rev-parse HEAD~1) || die requires at least 3 commits
pp=$(git rev-parse HEAD~2) || die requires at least 3 commits
git-read-tree --reset $p
git update-ref -m 'wip restore' HEAD $pp
echo restored wip
^ permalink raw reply
* gitk highlighting commits
From: picca @ 2007-06-08 6:45 UTC (permalink / raw)
To: git
Hello
I am using git to follow the wine development. And I wondering if it
is possible to highlight all the commit since my last git pull ?
Indeed there is so many commits that I can not remenber the
last one I red before I did this git pull.
Maybe using the blob date on the disk ?
Have a nice day.
^ permalink raw reply
* Re: [PATCH/RFC] filter-branch: support skipping of commits more easily
From: Junio C Hamano @ 2007-06-08 6:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0706080455440.4046@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> > IOW, given A-B-C, if commit-filter says "skip" upon B, the rewritten
>> > branch will look like this: A'-C'.
>> >
>> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
>> > ---
>> >
>> > Of course, if you think of "patchsets", this behaviour might
>> > be unexpected, since the children will still contain everything
>> > which was changed in the skipped revisions, and not changed in
>> > _them_.
>>
>> I think that is fine; in effect, by saying "skip" B, you are
>> squashing B-C into C'.
>> ...
>> I am not objecting; just trying to get a mental picture.
>
> Yeah, but you called it "squash" instead of "skip". So, maybe it should
> accept "squash" to do that operation instead?
Skip is logically correct, but this does sound like squashing to
me.
^ permalink raw reply
* Re: [PATCH] Fix push with refspecs containing wildcards
From: Junio C Hamano @ 2007-06-08 6:38 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Johannes Schindelin
In-Reply-To: <20070607234305.GB10633@steel.home>
Sending a fix is a good thing, but whenever doing one, could
people please also do a testcase that demonstrates the original
bug, and also a demonstration that the fix does not introduce
regression?
For this one, obviously a test for push that uses such wildcard
ref is needed but at the same time we would want a test for push
that does _not_ use a wildcard, fetch that uses a wildcard, and
a fetch that does not use a wildcard.
^ permalink raw reply
* Re: git-send-pack: broken handling of ref specs with wildcards
From: Junio C Hamano @ 2007-06-08 6:33 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Alex Riesen, git, Daniel Barkalow
In-Reply-To: <Pine.LNX.4.64.0706072356220.4046@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Fri, 8 Jun 2007, Alex Riesen wrote:
>
>> Try something like this:
>>
>> git-send-pack --remote=origin --thin /some/other/repo \
>> 'refs/heads/*:refs/remotes/child/*'
>>
>> The result looks broken: the sent reference are created not in
>> refs/remotes/child/ but just in refs/heads/ of /some/other/repo.
>
> I had the impression that it was git-push, a porcelain, which handles
> refspec wildcards, not send-pack, which is plumbing.
Well, I do not think it is wrong per-se if plumbing send-pack
starts understanding 'a/*:b/*'. Earlier it only understood
concrete refspecs, and such a refspec that has asterisks cannot
be concrete, as '*' is an invalid char in a refname. So there
is no risk of confusion.
That is, as long as it is done right, which was not true in this
case.
^ permalink raw reply
* Re: [PATCH] Fix failed tag parsing when tag object has no body/message (and thus ends with a single '\n')
From: Junio C Hamano @ 2007-06-08 6:05 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Johannes Schindelin
In-Reply-To: <200706080208.14571.johan@herland.net>
Johan Herland <johan@herland.net> writes:
> Thanks to Johannes Schindelin <Johannes.Schindelin@gmx.de> for
> discovering this.
>
> Also add a testcase for this condition.
>
> Signed-off-by: Johan Herland <johan@herland.net>
While this certainly is an improvement, I suspect that your
parse_tag() does a little too much. In a format such as "tag"
object that does header + blank + body, it is customary to allow
header fields that your version does not understand (assuming
that such extention will go after the known fields is fine).
Which means that you should not be even saying "Ok, I've checked all
headers I know about---there should be a double LF to terminate it",
as you do not know if headers have ended.
^ permalink raw reply
* Re: clarify git clone --local --shared --reference
From: Shawn O. Pearce @ 2007-06-08 5:37 UTC (permalink / raw)
To: Brandon Casey; +Cc: git
In-Reply-To: <466701E0.4000108@nrlssc.navy.mil>
Brandon Casey <casey@nrlssc.navy.mil> wrote:
> ok. I just want to make sure this is not really about prune'ing.
>
> In the following, source and --shared repos are identical except...
> 1) Source repo contains loose objects which are new commits.
> --shared repo does git-pull.
> we fast-forward, copying very little.
> success.
Copying nothing actually. All of the objects required are in the
source repository, so --shared needs nothing additional.
> 2) Source repo contains loose objects which are new commits.
> Source repo does git-gc, which repacks but doesn't prune.
> --shared repo does git-pull.
> success?
Yes, same as above. Except: If --shared has a branch that points
at a commit that used to be in source (hence its data isn't in
--shared) and that data used to be packed, but source no longer
has a reference to it. When you repack source we won't include
that commit in the new pack, but we will delete the old pack.
That means the commit goes away.
> 3) Source repo deletes a branch that --shared repo also has.
> This deletion creates dangling unreferenced objects.
Yes... see above about the repack problem.
> ** --shared repo still ok here, right?
> Source repo does git-gc, which repacks but doesn't prune.
Broken. The repack didn't include the dangling objects.
> ** Is --shared screwed at this point? (This is what I understand
> you to say above) Or do the dangling objects still exist,
> so --shared is still ok?
--shared is fubar, on the deleted branch.
> git gc --prune
> --shared is fubar, at least on the deleted branch.
also fubar, on the deleted branch.
> The docs (git-repack.txt) seem to suggest that git-repack (without -d)
> does not delete any objects. And if -d is used, then at most objects
> already referenced in other packs will be deleted. This makes me think
> that repack is safe on the source repository.
You are correct that leaving off the '-d' won't delete objects.
But a pack is created by listing the objects we need, and if we don't
need the object in source, we don't include it into the new pack.
-a -d implies delete all packs that existed when we started the
repack. So if an object was in the old packfile, and we didn't
copy it to the new packfile, it gets deleted. ;-)
Packfiles are immutable. We cannot delete something from it without
deleting the entire packfile.
> If the above is wrong, then I'm missing a clue about git-rebase. And
> don't feel like you have to explain it to me. Do feel free to give a
> short *NO!! REPACK IS DANGEROUS ON SHARED REPOS YOU IDIOT!!* or other
> such beating. But if you see what I'm misunderstanding please let me know.
;-)
NO!! REPACK IS DANGEROUS ON SHARED REPOS YOU IDIOT!!
Exactly because of what I'm saying above, and what you mention about
source deleting a branch and repacking or pruning, and --shared
then being corrupt because its now missing at least one object it
wants to have.
> If the above is right, then it seems like the source repo developer
> should be able to go about his developing, and git-gc'ing without
> regard for other developers who may be --share'ing. And only when the
> source developer wants to do a prune of dangling objects must something
> special be done. git-prune.txt suggests:
>
> git prune $(cd ../another && $(git-rev-parse --all))
Right; but the thing that is shocking to some people (me in my
early days with Git) is that a repack is *also* doing a prune if
you add -d. Its not quite the same type of prune as it prunes only
previously packed objects, but its still a prune.
> >In my day-job repositories I have about 150 MiB of blobs that
> >are very common across a number of Git repositories. I've made a
> >single repo that has all of those packed, and then setup that as an
> >alternate for everything else. It saves a huge chunk of disk for us.
> >But that common-blob.git thing that I created never gets changed,
> >and never gets repacked. Its sort of a "historical archive" for us.
> >Works very nicely. Alternates have their uses...
>
> Ahh, now that's interesting.
>
> Could I create something like that by doing something like this:
>
> (in a cloned repository with only a master branch)
> git reset --hard HEAD^ # I know, HEAD is still in the history
> git gc --prune # log so it doesn't get pruned, but
> # it's just an example
>
> (now back in my devel repo)
> <add archive repo to alternates>
> git prune-packed
Actually you want `git gc` in your --shared repo now. That way it
minimizes the current packfiles. prune-packed only applies to loose
objects; not already packed stuff. Since you added a repo with a
large packfile to your alternates list you probably want to shrink
your own packfile down as much as possible. That works because
`git gc` is actually running `git repack -a -d -l`. The -l means
"only things that are local to this --shared repository.
> Now most everything is likely referenced in the archive repo except the
> last commit. Well, maybe even the HEAD commit due to the history log.
Right.
> Depending on how you reply above, a periodic pull into the archive repo
> (and a repack?), then a 'git prune-packed' from the sharers could allow
> good sharing? <waiting for a "NO, YOU IDIOT!"> If not, then I guess the
> archive creation steps could be repeated periodically.
Yes, exactly. The trick here is that once something enters the
shared repo IT MUST STAY THERE. You cannot allow a branch to be
deleted from the shared repo, unless it is fully merged into another
branch (or tag) that is staying. You also cannot rewind a branch
(e.g. push with --force).
But I do exactly what you are suggesting. I pull every so often
into a the shared common repo and repack it. And then everyone
else can repack and their repack deletes things that are in the
shared common repo.
Just make sure you have a good backup of the shared common repo. :)
--
Shawn.
^ permalink raw reply
* Re: [PATCH] fsck: do not crash on tag objects which do not contain an empty line
From: Johannes Schindelin @ 2007-06-08 5:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johan Herland
In-Reply-To: <7vmyzbm3cx.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 7 Jun 2007, Junio C Hamano wrote:
> Recent git-tag does this
>
> ( printf 'object %s\ntype %s\ntag %s\ntagger %s\n\n' \
> "$object" "$type" "$name" "$tagger";
> cat "$GIT_DIR"/TAG_FINALMSG ) >"$GIT_DIR"/TAG_TMP
>
> so even if TAG_FINALMSG (which is -m or edited message after
> filtering out the comments and git-stripspace) is empty, you
> would have the two LFs at the end of the header.
I could imagine that there is still a git-stripspace after that. Undoing
the last LF.
> Did this tag come from cvsimport (or svnimport) perhaps?
Yep. cvsimport.
But nevertheless, I know the convention of "LFLF" being the end of the
header from several places: HTTP, mail, proxies.
_None_ of them fail as badly as what I experienced. Heck, Git used to be
the _most_ stable software I ever used, _including_ the Linux kernel. And
all of a sudden, when I really needed it just to work properly, and did
not bother to install a "stable" version, but just took "next", it failed
on me.
I don't like this at all.
And I have to say, even if I was responsible for my share of
not-quite-perfect patches, this patch _series_ is bad IMHO.
Not only does already the _first_ patch contain a serious error. I did not
even bother to read it in total, because it was _huge_, contained
_white-space_ fixes in combination with some dubious comment changes, did
not clean up _obvious_ errors (like lookup_object(sha1)->object!!), but at
the same time _changed_ behaviour.
And it is totally unreadable, with 120+ characters per line.
Frankly, I am angry at myself that I did not have a look and shot that
patch down on the merits of its _line size_ alone.
I have come to expect bad code from bad style and I would have been right
again, had I read the patch in time.
> I agree with you that if something does not have body, we should not
> require an empty trailing line after the header.
It is just _one_ issue about it.
We should not fail to process a fetch _at all_, just because a single
_tag_ is not really conforming to some obscure convention.
Ciao,
Dscho "still somewhat upset"
^ permalink raw reply
* Re: p4 + svn + git
From: Benjamin Sergeant @ 2007-06-08 5:31 UTC (permalink / raw)
To: git
In-Reply-To: <1621f9fa0706072227s7b64e4abq682b53eb920c8f53@mail.gmail.com>
Looks like this git-p4 is there:
http://repo.or.cz/w/fast-export.git
On 6/7/07, Benjamin Sergeant <bsergean@gmail.com> wrote:
> On 6/7/07, Benjamin Sergeant <bsergean@gmail.com> wrote:
> > That might be too much, but let's ask anyway...
>
> This is probably too much, so on to the next question:
> Is there a perforce equivalent of git-svn ?
>
> What I'd like to do:
> My main Linux machine will be the gateway.
>
> 1. I 'clone' the perforce tree with git-p4. I now have a .git, a full repo.
> Can I use this as the equivalent of a subversion server, so that every
> other machines pull / push from it.
>
> And once in a while (weekly basis), I push the work that's been done
> in git to perforce using the Linux box.
>
> Doest that make sense ?
>
> Thanks,
> Benjamin.
>
>
> >
> > My company uses perforce.
> > I took a snapshot of some code checked out from perforce (a single
> > branch), that I imported into subversion, a while ago, and started
> > working with svn only. I have different Unix machines checking in /
> > out code code from the subversion server (with svn), and I'd like to
> > keep it this way (if possible).
> >
> > I'm wondering if I could use git as a gateway between both systems, to
> > merge code in both direction (svn <-> perforce).
> >
> > Is this possible, with the help of git-p4import, git-svn, and using
> > several branches ?
> >
> > Thanks,
> > Benjamin.
> >
>
^ permalink raw reply
* Re: p4 + svn + git
From: Benjamin Sergeant @ 2007-06-08 5:27 UTC (permalink / raw)
To: git
In-Reply-To: <1621f9fa0706072145s3ea6d5cdt3c3e6a2eaaffa14c@mail.gmail.com>
On 6/7/07, Benjamin Sergeant <bsergean@gmail.com> wrote:
> That might be too much, but let's ask anyway...
This is probably too much, so on to the next question:
Is there a perforce equivalent of git-svn ?
What I'd like to do:
My main Linux machine will be the gateway.
1. I 'clone' the perforce tree with git-p4. I now have a .git, a full repo.
Can I use this as the equivalent of a subversion server, so that every
other machines pull / push from it.
And once in a while (weekly basis), I push the work that's been done
in git to perforce using the Linux box.
Doest that make sense ?
Thanks,
Benjamin.
>
> My company uses perforce.
> I took a snapshot of some code checked out from perforce (a single
> branch), that I imported into subversion, a while ago, and started
> working with svn only. I have different Unix machines checking in /
> out code code from the subversion server (with svn), and I'd like to
> keep it this way (if possible).
>
> I'm wondering if I could use git as a gateway between both systems, to
> merge code in both direction (svn <-> perforce).
>
> Is this possible, with the help of git-p4import, git-svn, and using
> several branches ?
>
> Thanks,
> Benjamin.
>
^ permalink raw reply
* Re: [PATCH] fsck: do not crash on tag objects which do not contain an empty line
From: Junio C Hamano @ 2007-06-08 5:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Johan Herland
In-Reply-To: <Pine.LNX.4.64.0706072338260.4046@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> The first empty line in a tag object separates the header from the
> message. If the tag object has no empty line, do not crash, but
> complain loudly instead.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>
> I have no idea how this tag crept into one of my repos, but it is
> no good to crash for git-fsck.
Absolutely. git-fsck is to find suspicious data and should not
crash on them.
Thanks.
But it _does_ make me wonder how. Recent git-tag does this
( printf 'object %s\ntype %s\ntag %s\ntagger %s\n\n' \
"$object" "$type" "$name" "$tagger";
cat "$GIT_DIR"/TAG_FINALMSG ) >"$GIT_DIR"/TAG_TMP
so even if TAG_FINALMSG (which is -m or edited message after
filtering out the comments and git-stripspace) is empty, you
would have the two LFs at the end of the header. Ancient
"git-tag-script" did this, which is a moral equivalent with echo
and has the same effect:
( echo -e "object $object\ntype $type\ntag $name\ntagger $tagger\n";
cat .tagmsg ) > .tmp-t
Did this tag come from cvsimport (or svnimport) perhaps? We are
in the process of updating its use of git-mktag to git-tag, but
they use git-mktag and do not leave a blank line after the
header (and they do not add any body).
I notice that gitk creates lightweight tag by hand (it directly
goes to the filesystem) It should probably use git-tag as well.
I agree with you that if something does not have body, we should
not require an empty trailing line after the header.
^ permalink raw reply
* Re: [PATCH/RFC] filter-branch: support skipping of commits more easily
From: Johannes Schindelin @ 2007-06-08 5:12 UTC (permalink / raw)
To: linux; +Cc: git, gitster
In-Reply-To: <20070608021157.18066.qmail@science.horizon.com>
Hi,
On Fri, 7 Jun 2007, linux@horizon.com wrote:
> > I think that is fine; in effect, by saying "skip" B, you are
> > squashing B-C into C'.
> >
> > Does this mean that, given
> >
> > C---D---E
> > / /
> > A---B
> >
> > and if commit-filter says "skip" on D, the written history would
> > look like this?
> >
> > C'------E'
> > / /
> > A'--B'--'
> >
> > The new commit E' would become an evil merge that has difference
> > between D and E in the original history?
> >
> > I am not objecting; just trying to get a mental picture.
>
> I think, for compatibility with the existing git path limiter,
> it should delete D from the history only if:
> 1) Told to skip D, and
> 2) Told to skip B or C (or both).
>
> So you could get A--B--E' or A--C--E' or even A--E', but D would only
> be deleted if it wasn't needed as a merge marker.
>
> That's probably a little more complex to implement, but it feels like
> The Right Thing.
... but if that script should do that, the name "filter"-branch was a
misnomer.
It filters the _branch_. In the sense that a branch is one or more perls
of commits, uniting in the tip of that branch.
If you want to skip a commit, that is fine. But a commit is _not_ a patch,
no sir. It is a revision.
The fact that we actually are able to extract nice patches from any patch
series, does not mean that the revisions are actually only deltas with
regard to the previous commit. To the contrary: we actually allow -- and
encourage -- git-diff between different revisions, be they on the same
branch or not. That alone should tell everybody that a revision is a
revision is a revision, and _not_ a delta.
So, when you filter commits, you should not expect a certain _patch_ to be
skipped when you say "skip" (or maybe "squash", which I actually like
better, because it is as unambiguous as you get it), but a _commit_ (AKA
revision) to be skipped.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Teach filter-branch about subdirectory filtering
From: Johannes Schindelin @ 2007-06-08 5:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzm3bmfeq.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 7 Jun 2007, Junio C Hamano wrote:
> Good thing you folded git-split into this, which is an obviously right
> thing to do.
So my secritt evvil plann did not stay secritt that long.
> But it makes me wonder, if it is common to want to split a combined
> project into two (or more) sets, taking more than one directories at a
> time.
It's just a guess, but now that we come really, really close to having a
concise implementation of git-subproject which will probably soon
propagate to master, and then maint, I gather that more and more people
come and want to split their projects (which they maintained as one big
project) into several subprojects (which they should have been from the
start, but the tool did not easily allow for that).
> We might however want to make sure that we detect an attempt to give
> more than one --subdirectory-filter parameter.
Yeah. But then, I think that rev-list actually does not like to be passed
a file/directory which does not exist currently, so that is probably a
sensible safeguard against that usage.
Unless you think -- as I fear you do -- that people could think
git-filter-branch (its name not withstanding) filters _multiple_ branches
_at once_.
That case I did not foresee, and you're right, I should output a big fat
error for the case when somebody says "filter-branch --subdirectory-filter
a/ --subdirectory-filter b/". It does not make any sense. But humans are
known for their unique feeling that things should work, even if they make
no sense at all, and their brain should have warned them (that it is
unlikely, at best, to work), but failed to do so.
Ciao,
Dscho
^ permalink raw reply
* p4 + svn + git
From: Benjamin Sergeant @ 2007-06-08 4:45 UTC (permalink / raw)
To: git
That might be too much, but let's ask anyway...
My company uses perforce.
I took a snapshot of some code checked out from perforce (a single
branch), that I imported into subversion, a while ago, and started
working with svn only. I have different Unix machines checking in /
out code code from the subversion server (with svn), and I'd like to
keep it this way (if possible).
I'm wondering if I could use git as a gateway between both systems, to
merge code in both direction (svn <-> perforce).
Is this possible, with the help of git-p4import, git-svn, and using
several branches ?
Thanks,
Benjamin.
^ 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