* Re: [PATCH] git-repack question
From: Linus Torvalds @ 2006-02-17 22:20 UTC (permalink / raw)
To: linux; +Cc: git, junkio
In-Reply-To: <20060217213824.5848.qmail@science.horizon.com>
On Fri, 17 Feb 2006, linux@horizon.com wrote:
>
> I'm trying to imagine when you'd want to run git-repack without the -d
> option, or without running git-prune-packed afterwards.
> (Isn't the idea behind packs to save space?)
Normally you'd always run git-prune-packed.
The reason it doesn't do that is simply being anally careful, and because
conceptually the pruning phase is totally independent.
For example, in an environment that mirrors out git repositories by rsync,
it can make sense to wait with pruning until the mirror cycle has
finished, so that all mirrors always have all the objects.
(I don't do it for the kernel, because (a) I'm a lazy bastard, (b) I'm so
confused that I sometimes forget my own name, much less to prune things a
day after I've repacked them and (c) I don't care that much about rsync
anyway, since you can't avoid some of the _other_ races).
As to whether you'd normally run "-d" - usually you'd run it whenever you
pair it up with "-a". When you do an incremental re-pack, "-d" won't do
anything anyway.
Again, it might make sense to not delete the old packs when repacking
everything in a rsync'ing environment - or even in a shared repository,
where removing a pack-file could race with somebody else working on it.
Basically, the default ends up being to never remove any objects at all,
simply because that's the _safe_ thing to do.
In practice, I personally always do
git repack -a -d
git prune-packed
together, because the full repack isn't _that_ expensive for me (I tend to
have lots of cpu power), and because I can't be bothered to worry too much
about rsync and there are never any other users working on my git trees.
Linus
^ permalink raw reply
* Re: stGIT: commit vs export vs mail
From: Catalin Marinas @ 2006-02-17 22:12 UTC (permalink / raw)
To: Jesse Brandeburg; +Cc: git
In-Reply-To: <Pine.WNT.4.63.0602171139020.3052@jbrandeb-desk.amr.corp.intel.com>
Jesse Brandeburg wrote:
> So I am using stgit .8 right now, and I'm having a hard time figuring
> out what the correct workflow should be for using stg and then
> committing a change
>
> Here is what I've been doing:
> stg new test
> enter my short description on first line
> enter my long description on next lines.
> vi file
> stg refresh
> stg mail <blah blah blah>
> or
> stg commit
There is no "or" above but only "and maybe". The 'commit' command is
only used to permanently store a set of patches into the repository.
After that, you should not be able to change them anymore (well, someone
just sent me a patch for an uncommit command). I only use this command
when I work in the "maintainer" mode on StGIT. For contributing patches,
you shouldn't need it since the base of the stack should usually be
identical to the HEAD of the remote repository.
> Problem that I'm having right now is that the templates do the right
> thing for mail, but, the commit only puts in the "enter my..." text.
I don't fully understand this. Where does commit put the "enter my..." text?
> Is there a template based way to automatically append the author in the
> Signed-off-by: line when i do stg commit?
This can only be done when creating a patch. Commit doesn't modify the
patches. I think you slightly misunderstood the commit command.
Catalin
^ permalink raw reply
* Re: [ANNOUNCE] pg - A patch porcelain for GIT
From: Catalin Marinas @ 2006-02-17 21:57 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060213210001.GA31278@pasky.or.cz>
Petr Baudis wrote:
> * I can't just get the patch in its "canonical ready-to-mail
> form" on stdout so that I could easily review it. Why is
> pg-export insisting to dump it to a file?
I pushed tonight 2 patches for this. One of them adds a --stdout option
to 'export' so that you can see the patches. The other patch adds a
--mbox option to 'mail' that generates an mbox file on the stdout. This
is useful not only for reviewing patches.
--
Catalin
^ permalink raw reply
* [PATCH] git-repack question
From: linux @ 2006-02-17 21:38 UTC (permalink / raw)
To: git; +Cc: junkio
I'm trying to imagine when you'd want to run git-repack without the -d
option, or without running git-prune-packed afterwards.
(Isn't the idea behind packs to save space?)
I'll leave changing the default to wiser heads, but this trivial patch
will at least allow the normal operations to be performed with one
command.
Oh, and is the failure to support getopt-style concatenated
single-letter options (git-repack -dp) a deliberate design feature
of git, or just laziness?
(Legalese: Patch placed in the public domain; copyright abandoned.)
diff --git a/Documentation/git-repack.txt b/Documentation/git-repack.txt
index 9060fe8..1b1f50d 100644
--- a/Documentation/git-repack.txt
+++ b/Documentation/git-repack.txt
@@ -47,6 +47,10 @@ OPTIONS
Do not update the server information with
`git update-server-info`.
+-p::
+ After packing, run gitlink:git-prune-packed[1] to delete
+ redundant unpacked objects.
+
Author
------
Written by Linus Torvalds <torvalds@osdl.org>
diff --git a/git-repack.sh b/git-repack.sh
index 1fafb6e..361c7e9 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -3,10 +3,10 @@
# Copyright (c) 2005 Linus Torvalds
#
-USAGE='[-a] [-d] [-l] [-n]'
+USAGE='[-a] [-d] [-l] [-n] [-p]'
. git-sh-setup
-no_update_info= all_into_one= remove_redundant= local=
+no_update_info= all_into_one= remove_redundant= local= prune=
while case "$#" in 0) break ;; esac
do
case "$1" in
@@ -14,6 +14,7 @@ do
-a) all_into_one=t ;;
-d) remove_redundant=t ;;
-l) local=t ;;
+ -p) prune=t ;;
*) usage ;;
esac
shift
@@ -76,6 +77,10 @@ then
fi
fi
+case "$prune" in
+t) git-prune-packed ;;
+esac
+
case "$no_update_info" in
t) : ;;
*) git-update-server-info ;;
^ permalink raw reply related
* [PATCH 3/3] New test to verify that when git-clone fails it cleans up the new directory.
From: Carl Worth @ 2006-02-17 21:33 UTC (permalink / raw)
To: git; +Cc: Carl Worth
In-Reply-To: <1140212006127-git-send-email-cworth@cworth.org>
Signed-off-by: Carl Worth <cworth@cworth.org>
---
t/t5600-clone-fail-cleanup.sh | 36 ++++++++++++++++++++++++++++++++++++
1 files changed, 36 insertions(+), 0 deletions(-)
create mode 100755 t/t5600-clone-fail-cleanup.sh
0d8852c105e5f910ba53fc974a5d929a2136aecd
diff --git a/t/t5600-clone-fail-cleanup.sh b/t/t5600-clone-fail-cleanup.sh
new file mode 100755
index 0000000..0c6a363
--- /dev/null
+++ b/t/t5600-clone-fail-cleanup.sh
@@ -0,0 +1,36 @@
+#!/bin/sh
+#
+# Copyright (C) 2006 Carl D. Worth <cworth@cworth.org>
+#
+
+test_description='test git-clone to cleanup after failure
+
+This test covers the fact that if git-clone fails, it should remove
+the directory it created, to avoid the user having to manually
+remove the directory before attempting a clone again.'
+
+. ./test-lib.sh
+
+test_expect_failure \
+ 'clone of non-existent source should fail' \
+ 'git-clone foo bar'
+
+test_expect_failure \
+ 'failed clone should not leave a directory' \
+ 'cd bar'
+
+# Need a repo to clone
+test_create_repo foo
+
+# clone doesn't like it if there is no HEAD. Is that a bug?
+(cd foo && touch file && git add file && git commit -m 'add file' >/dev/null 2>&1)
+
+test_expect_success \
+ 'clone should work now that source exists' \
+ 'git-clone foo bar'
+
+test_expect_success \
+ 'successfull clone must leave the directory' \
+ 'cd bar'
+
+test_done
--
1.2.0.gf6e8
^ permalink raw reply related
* [PATCH 2/3] Abstract test_create_repo out for use in tests.
From: Carl Worth @ 2006-02-17 21:33 UTC (permalink / raw)
To: git; +Cc: Carl Worth
In-Reply-To: <11402120042011-git-send-email-cworth@cworth.org>
Signed-off-by: Carl Worth <cworth@cworth.org>
---
t/test-lib.sh | 23 +++++++++++++++++------
1 files changed, 17 insertions(+), 6 deletions(-)
6110a439c2b1962c6f128cdaac3a2ee8450ac22c
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 7a58a86..66f62b9 100755
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -149,6 +149,21 @@ test_expect_code () {
fi
}
+# Most tests can use the created repository, but some amy need to create more.
+# Usage: test_create_repo <directory>
+test_create_repo () {
+ test "$#" = 1 ||
+ error "bug in the test script: not 1 parameter to test-create-repo"
+ owd=`pwd`
+ repo="$1"
+ mkdir "$repo"
+ cd "$repo" || error "Cannot setup test environment"
+ "$GIT_EXEC_PATH/git" init-db --template=$GIT_EXEC_PATH/templates/blt/ 2>/dev/null ||
+ error "cannot run git init-db -- have you built things yet?"
+ mv .git/hooks .git/hooks-disabled
+ cd "$owd"
+}
+
test_done () {
trap - exit
case "$test_failure" in
@@ -196,9 +211,5 @@ test -d ../templates/blt || {
# Test repository
test=trash
rm -fr "$test"
-mkdir "$test"
-cd "$test" || error "Cannot setup test environment"
-"$GIT_EXEC_PATH/git" init-db --template=../../templates/blt/ 2>/dev/null ||
-error "cannot run git init-db -- have you built things yet?"
-
-mv .git/hooks .git/hooks-disabled
+test_create_repo $test
+cd "$test"
--
1.2.0.gf6e8
^ permalink raw reply related
* Making git-clone clean up when it fails
From: Carl Worth @ 2006-02-17 21:33 UTC (permalink / raw)
To: git
So instead of just making noise, I'll start actually contributing to
git. The first patch here is designed to fix the annoying bug that
when git-clone fails it still leaves the created directory around, (so
that a subsequent git-clone will be guaranteed to fail since the
directory already exists).
The second and third patches provide a new test case for the new
behavior. I had to guess at the number for the new test, since the
distinction of the various numbers in t/README was too vague for me to
know where a git-clone test should go. Feel free to adjust that as
you might see fit.
-Carl
--
cworth@redhat.com
^ permalink raw reply
* [PATCH 1/3] Trap exit to clean up created directory if clone fails.
From: Carl Worth @ 2006-02-17 21:33 UTC (permalink / raw)
To: git; +Cc: Carl Worth
In-Reply-To: <11402120031687-git-send-email-cworth@cworth.org>
Signed-off-by: Carl Worth <cworth@cworth.org>
---
git-clone.sh | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
589b68168e3dad89238b879b06680c662a99ad8d
diff --git a/git-clone.sh b/git-clone.sh
index e192b08..d184ceb 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -118,6 +118,7 @@ dir="$2"
[ -e "$dir" ] && echo "$dir already exists." && usage
mkdir -p "$dir" &&
D=$(cd "$dir" && pwd) &&
+trap 'err=$?; rm -r $D; exit $err' exit
case "$bare" in
yes) GIT_DIR="$D" ;;
*) GIT_DIR="$D/.git" ;;
@@ -255,3 +256,6 @@ Pull: $head_points_at:$origin" &&
git checkout
esac
fi
+
+trap - exit
+
--
1.2.0.gf6e8
^ permalink raw reply related
* stGIT: commit vs export vs mail
From: Jesse Brandeburg @ 2006-02-17 21:09 UTC (permalink / raw)
To: git
So I am using stgit .8 right now, and I'm having a hard time figuring out
what the correct workflow should be for using stg and then committing a
change
Here is what I've been doing:
stg new test
enter my short description on first line
enter my long description on next lines.
vi file
stg refresh
stg mail <blah blah blah>
or
stg commit
Problem that I'm having right now is that the templates do the right thing
for mail, but, the commit only puts in the "enter my..." text.
Is there a template based way to automatically append the author in the
Signed-off-by: line when i do stg commit?
I realize that I could put Signed-off-by in the log by hand (or even in
.git/patchdescr.tmpl which i just found) but it would be cool if the
commit just had something like patchmail.tmpl (maybe call it
commitdescr.tmpl or something?)
thanks for any opinions or instruction.
Jesse
^ permalink raw reply
* Re: [PATCH 5/5] Optionally work without python
From: Radoslaw Szkodzinski @ 2006-02-17 21:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0602171523510.24274@wbgn013.biozentrum.uni-wuerzburg.de>
[-- Attachment #1: Type: text/plain, Size: 644 bytes --]
Johannes Schindelin wrote:
> In some setups (notably server setups) you do not need that dependency.
> Gracefully handle the absence of python when NO_PYTHON is defined.
>
> +# Define NO_PYTHON if you want to loose all benefits of the recursive merge.
lose
> --- a/git-merge.sh
> +++ b/git-merge.sh
> @@ -11,7 +11,11 @@ LF='
> '
>
> all_strategies='recursive octopus resolve stupid ours'
Maybe use this:
default_strategies='recursive'
if test -n "@@NO_PYTHON@@"; then
default_strategies='resolve'
fi
--
GPG Key id: 0xD1F10BA2
Fingerprint: 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2
AstralStorm
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* Re: git-cvs-import and branches
From: David Mansfield @ 2006-02-17 20:35 UTC (permalink / raw)
To: Martin Mares; +Cc: git, CVSps
In-Reply-To: <mj+md-20060217.193815.10412.albireo@ucw.cz>
On Fri, 2006-02-17 at 20:55 +0100, Martin Mares wrote:
> Hello!
>
> I'm git-importing a rather large CVS repository with lots of branches and
> although the mainline is imported correctly, the branches aren't. They
> usually contain some changes introduced to the ancestor branch after
> the point the new branch has been tagged.
>
> I haven't studied git-cvsimport and cvsps in much detail yet, but it seems
> that git-cvsimport forks off the branch at the first patchset reported by
> cvsps which mentions the branch and copies the current state of the ancestor
> branch at that time.
>
> This doesn't seem to be correct, since many changes might have happened
> to the ancestor branch since the real branching point. However, since
> cvsps doesn't report the branching points (and they aren't exact points anyway
> since tagging is not atomic in CVS), I don't see how to make cvsimport
> find the right starting revision.
Ugh. I understand the problem but really don't have any solutions
off-hand. Unfortunately, I dying under a 'real work' load at the
moment, so I have to apologize and say, 'good luck.'
David
^ permalink raw reply
* git-cvs-import and branches
From: Martin Mares @ 2006-02-17 19:55 UTC (permalink / raw)
To: git; +Cc: CVSps
Hello!
I'm git-importing a rather large CVS repository with lots of branches and
although the mainline is imported correctly, the branches aren't. They
usually contain some changes introduced to the ancestor branch after
the point the new branch has been tagged.
I haven't studied git-cvsimport and cvsps in much detail yet, but it seems
that git-cvsimport forks off the branch at the first patchset reported by
cvsps which mentions the branch and copies the current state of the ancestor
branch at that time.
This doesn't seem to be correct, since many changes might have happened
to the ancestor branch since the real branching point. However, since
cvsps doesn't report the branching points (and they aren't exact points anyway
since tagging is not atomic in CVS), I don't see how to make cvsimport
find the right starting revision.
Does anybody have an idea how to solve this?
Have a nice fortnight
--
Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
COBOL -- Completely Outdated, Badly Overused Language
^ permalink raw reply
* git-cvs-import retries
From: Martin Mares @ 2006-02-17 19:38 UTC (permalink / raw)
To: git
Hello!
I am trying git-cvsimport on a rather huge repository and the CVS server
sometimes drops the connection and the whole importing aborts, although
it contains some retrying logic. I've noticed that in the connection closes
I experience, $res ends up being empty instead of undefined. This is tested
by the `server went again' check, but not by the retry check a couple of
lines before.
This patch extends the retry check and makes the symptoms go away.
However, take it with a grain of salt as I don't understand yet why the
connection is aborted.
Have a nice fortnight
--
Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
A jury consists of 12 persons chosen to decide who has the better lawyer.
Signed-Off-By: Martin Mares <mj@ucw.cz>
--- old/git-cvsimport 2006-02-17 13:02:24.000000000 +0100
+++ new/git-cvsimport 2006-02-17 18:13:06.000000000 +0100
@@ -371,7 +371,7 @@
$self->_file($fn,$rev) and $res = $self->_line($fh);
- if (!defined $res) {
+ if (!defined $res || $res eq '') {
# retry
$self->conn();
$self->_file($fn,$rev)
^ permalink raw reply
* Re: [PATCH] pack-objects: reuse data from existing pack.
From: Junio C Hamano @ 2006-02-17 18:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0602170738390.916@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Thu, 16 Feb 2006, Junio C Hamano wrote:
>>
>> This one has one nasty data corruption bug, which fortunately I
>> think I have figured out how to fix.
>
> Circular deltas? What else can go wrong?
Circular deltas are prevented by not using deltified objects
check_object() decides to keep in find_deltas(), so I do not
think it is an issue.
^ permalink raw reply
* Re: [PATCH 1/5] Fixes for ancient versions of GNU make
From: Jason Riedy @ 2006-02-17 17:15 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0602171522020.24274@wbgn013.biozentrum.uni-wuerzburg.de>
And Johannes Schindelin writes:
-
- Some version of GNU make do not understand $(call), and have
- problems to interpret rules like this:
Is building a newer version of GNU make impossible on Irix?
Thankfully, I haven't had to deal with that OS in quite some
time.
Jason
^ permalink raw reply
* Re: [PATCH 0/5] Support ancient systems
From: Tim O'Callaghan @ 2006-02-17 17:03 UTC (permalink / raw)
To: git
In-Reply-To: <94fc236b0602170718t76e01204ib2b50e33eaa5eeaa@mail.gmail.com>
On Fri, Feb 17, 2006 at 04:18:35PM +0100, Adrien Beau wrote:
> On 2/17/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > I just got git to work on an Irix box. These are the changes I needed
> > to apply. Maybe some of them are of use for other ancient systems... You
> > know, I like ancient systems. And if I could get my hands on a VMS, I
> > would try to get git to work on it, too ;-)
>
> You can get free VMS accounts at the Deathrow Cluster:
> http://deathrow.vistech.net/
>
> If you're serious about using your account, you'll find that the admin
> team is pretty supportive and friendly.
You should check out polarhome.com if you want a variety of platforms
to muck about on, including IRIX, Plan 9, OpenVMS Vax, OpenVMS Alpha
etc.
I work on VMS systems at the moment and i thought of attempting to
port git for the hell of it. I decided not to bother for a variety of
reasons, but mostly because it looked like too much work :)
Tim.
^ permalink raw reply
* Re: Why can't git-rebase back up?
From: Andreas Ericsson @ 2006-02-17 16:30 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20060217153434.26359.qmail@science.horizon.com>
linux@horizon.com wrote:
>>>[[ This is because core git won't allow the checked-out HEAD to point
>>>to anything but a branch,
>
>
>>Yes it will. That's how "git reset" works (i.e. pointing HEAD to some
>>random object). Think of branches and tags as short and humanly
>>understandable names for certain points in the history. You can visit
>>any point in history without having a special short name for it.
>
>
> Er... say again? git reset doesn't touch the .git/HEAD symlink;
> it overwrites the file that .git/HEAD points to.
>
My bad. You're right.
> If you know a way to make the core git tools produce a .git/HEAD that
> is either not a symlink or does NOT begin with "refs/heads/", I'm quite
> curious.
>
The order of precedence works as such:
.git/<anchor-name>
.git/refs/<anchor-name>
.git/refs/tags/<tag-name>
.git/refs/heads/<branch-name>
sha1, with git magic to allow abbreviations
This is why you can't sanely have a branch named HEAD.
>
>>>and checking out something without having
>>>HEAD point to it is fragile and delicate. Cogito lets you do this with
>>>cg-seek. ]]
>
>
>>It's more than delicate. It's impossible (even for Cogito). You can take
>>snapshots of how the tree looked at a certain state and export that
>>using git-tar-tree if you wish, but other than that it's impossible to
>>visit a certain point in history without pointing HEAD to it (that's how
>>visiting that point is done, actually).
>
>
> Actually, you're right... Cogito uses refs/heads/cg-seek-point.
> But you can do it by hand with git-read-tree and git-checkout-index.
> (Very little in git is impossible; some things are just a Really Bad
> Idea.)
>
>
>>Now, if I want to migrate to a newer base version, I can always use
>>git-reset --hard v2.6.16-rc3, but that's a bit dangerous.
>>Preferable is to use git-rebase v2.6.16-rc3, which will preserve
>>any local edits.
>>
>>(I could also do it as a merge, but that seems like unnecessary history
>>clutter. It's not like local edits are common, anyway.)
>>
>>But suppose discover a nasty bug in -rc3 and want to move my build branch
>>back to -rc2. "git-rebase v2.6.16-rc2" does nothing. After a bit
>>of thought, I realize why, but sometime I do want to back up.
>>
>
>
>>I'd suggest doing something like this when changing base version (of any
>>project, really).
>
>
> [Use separate branch names for the two build versions.]
>
> That's certainly a possibility, but kind of annoying to remember what
> the "current" version is. Typically, there are no local changes,
> and I'm just using "build" as a conventional name to let me check
> out the version. Just like cg-seek-point.
>
Then make the current production be 'build', the "soon-to-become
production" to be 'devel' and tag the ones you're finished with so you
can revert to them easily if it becomes necessary. That's more or less
how all projects work, AFAIK.
>
>>However, branches and tags are cheap to create, efficient to use, easy
>>to remove once you're done with them. They make life easier. Use them.
>>You'll be glad you did.
>
>
> I don't really *want* a branch at all. I just want to export the
> right source tree and compile it.
$ git tar-tree v2.6.16-rc3 linux-2.6.16-rc3
OTOH, you could just download the released sources and patches from ftp.
> Local changes are more likely a
> mistake than anything else, but core git doesn't have Cogito's "blocked"
> flag. I'm just trying to avoid getting
> into the habit of typing "git reset --hard" a lot because that's
> dangerous.
>
I don't see why you should have to, even if you don't use a topic-branch
for fiddling with things. You can still do
$ git tar-tree <tag> linux-<tag>
to get the snapshot no matter how much you reset and muck about with the
working tree copy of the current HEAD.
If you're unsure about this, try
$ git checkout -b foo 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
$ gitk; # behold the dawn of time
$ git tar-tree v2.6.16-rc3 foo | gzip -9 > foo.tar.gz
Note that the first operation takes quite a while, as it has to update
all the files in the working tree.
> It's sort of along the lines of "any workflow that makes you type
> 'rm -rf *' on a regular basis is a recipe for disaster".
>
> The usual solution, of course, is to write a shell script wrapper with
> some safety checking. For example, I could see if git-name-rev --tags
> can come up with a name for the branch head before unleashing git-reset
> on it.
>
> But I thought I'd check if the tool already existed.
>
It does, and it doesn't. git checkout -b <name> <commit-ish> does what
you want, although it creates a branch. "git seek" isn't needed, since
creating branches is so cheap and far better than having to protect
certain branch- and tag-names for the sake of creating tools that offer
less power and flexibility than those already there.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Make git-reset delete empty directories
From: Shawn Pearce @ 2006-02-17 16:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20060217151654.GA26362@spearce.org>
Shawn Pearce <spearce@spearce.org> wrote:
> Junio C Hamano <junkio@cox.net> wrote:
> > I thought I said it would be a few-liner, but it appears I did
> > not send that message.
Actually its only a one line change if you accept Perl as Perl,
but not everyone likes having their loops do nothing in the loop
body whilest the condition does all of the work.
---
diff --git a/git-reset.sh b/git-reset.sh
index fe53fc8..e6471c0 100755
--- a/git-reset.sh
+++ b/git-reset.sh
@@ -88,6 +88,7 @@ case "$reset_type" in
# it is ok if this fails -- it may already
# have been culled by checkout-index.
unlink $_;
+ 1 while (s,/[^/]*$,, && rmdir $_);
}
}
' $tmp-exists
^ permalink raw reply related
* Re: [PATCH] pack-objects: reuse data from existing pack.
From: Linus Torvalds @ 2006-02-17 15:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu0ay8v4f.fsf@assigned-by-dhcp.cox.net>
On Thu, 16 Feb 2006, Junio C Hamano wrote:
>
> This one has one nasty data corruption bug, which fortunately I
> think I have figured out how to fix.
Circular deltas? What else can go wrong?
Linus
^ permalink raw reply
* Re: Why can't git-rebase back up?
From: linux @ 2006-02-17 15:34 UTC (permalink / raw)
To: ae, linux; +Cc: git
In-Reply-To: <43F5DF8B.6050307@op5.se>
>> [[ This is because core git won't allow the checked-out HEAD to point
>> to anything but a branch,
> Yes it will. That's how "git reset" works (i.e. pointing HEAD to some
> random object). Think of branches and tags as short and humanly
> understandable names for certain points in the history. You can visit
> any point in history without having a special short name for it.
Er... say again? git reset doesn't touch the .git/HEAD symlink;
it overwrites the file that .git/HEAD points to.
If you know a way to make the core git tools produce a .git/HEAD that
is either not a symlink or does NOT begin with "refs/heads/", I'm quite
curious.
>> and checking out something without having
>> HEAD point to it is fragile and delicate. Cogito lets you do this with
>> cg-seek. ]]
> It's more than delicate. It's impossible (even for Cogito). You can take
> snapshots of how the tree looked at a certain state and export that
> using git-tar-tree if you wish, but other than that it's impossible to
> visit a certain point in history without pointing HEAD to it (that's how
> visiting that point is done, actually).
Actually, you're right... Cogito uses refs/heads/cg-seek-point.
But you can do it by hand with git-read-tree and git-checkout-index.
(Very little in git is impossible; some things are just a Really Bad
Idea.)
> Now, if I want to migrate to a newer base version, I can always use
> git-reset --hard v2.6.16-rc3, but that's a bit dangerous.
> Preferable is to use git-rebase v2.6.16-rc3, which will preserve
> any local edits.
>
> (I could also do it as a merge, but that seems like unnecessary history
> clutter. It's not like local edits are common, anyway.)
>
> But suppose discover a nasty bug in -rc3 and want to move my build branch
> back to -rc2. "git-rebase v2.6.16-rc2" does nothing. After a bit
> of thought, I realize why, but sometime I do want to back up.
>
> I'd suggest doing something like this when changing base version (of any
> project, really).
[Use separate branch names for the two build versions.]
That's certainly a possibility, but kind of annoying to remember what
the "current" version is. Typically, there are no local changes,
and I'm just using "build" as a conventional name to let me check
out the version. Just like cg-seek-point.
> However, branches and tags are cheap to create, efficient to use, easy
> to remove once you're done with them. They make life easier. Use them.
> You'll be glad you did.
I don't really *want* a branch at all. I just want to export the
right source tree and compile it. Local changes are more likely a
mistake than anything else, but core git doesn't have Cogito's "blocked"
flag. I'm just trying to avoid getting
into the habit of typing "git reset --hard" a lot because that's
dangerous.
It's sort of along the lines of "any workflow that makes you type
'rm -rf *' on a regular basis is a recipe for disaster".
The usual solution, of course, is to write a shell script wrapper with
some safety checking. For example, I could see if git-name-rev --tags
can come up with a name for the branch head before unleashing git-reset
on it.
But I thought I'd check if the tool already existed.
^ permalink raw reply
* Re: [PATCH 0/5] Support ancient systems
From: Adrien Beau @ 2006-02-17 15:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0602171517580.24274@wbgn013.biozentrum.uni-wuerzburg.de>
On 2/17/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> I just got git to work on an Irix box. These are the changes I needed
> to apply. Maybe some of them are of use for other ancient systems... You
> know, I like ancient systems. And if I could get my hands on a VMS, I
> would try to get git to work on it, too ;-)
You can get free VMS accounts at the Deathrow Cluster:
http://deathrow.vistech.net/
If you're serious about using your account, you'll find that the admin
team is pretty supportive and friendly.
^ permalink raw reply
* Re: [PATCH] Make git-reset delete empty directories
From: Shawn Pearce @ 2006-02-17 15:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7j7u8koz.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> I thought I said it would be a few-liner, but it appears I did
> not send that message.
You did. Somehow I forgot that request. I wrote a simple approach
similar to what you show below then tried to make it slightly
more efficient by only attempting to delete each directory once.
Obviously that wasn't wise on my part. :-)
> This untested one is far simpler, if less efficient, isn't it?
>
> ---
>
> diff --git a/git-reset.sh b/git-reset.sh
> index fe53fc8..195d043 100755
> --- a/git-reset.sh
> +++ b/git-reset.sh
> @@ -88,6 +88,9 @@ case "$reset_type" in
> # it is ok if this fails -- it may already
> # have been culled by checkout-index.
> unlink $_;
> + while (s|/[^/]*$|| && $_ ne "") {
> + rmdir($_) or last;
> + }
> }
> }
> ' $tmp-exists
I just ran it through the test script (t7101-reset.sh) that I
included in my patch and it passed, so clearly the version above
would be the better version to include.
Since it was untested before you are welcome to include the test
script with your version. :-)
--
Shawn.
^ permalink raw reply
* Re: [PATCH 0/5] Support ancient systems
From: Andreas Ericsson @ 2006-02-17 14:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0602171517580.24274@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> I just got git to work on an Irix box. These are the changes I needed
> to apply. Maybe some of them are of use for other ancient systems... You
> know, I like ancient systems. And if I could get my hands on a VMS, I
> would try to get git to work on it, too ;-)
>
http://www.testdrive.hp.com/
You can sign up for a free account there and get (telnet and ftp) access
to all sorts of wonky and fun systems.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Why can't git-rebase back up?
From: Andreas Ericsson @ 2006-02-17 14:36 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20060217135938.7412.qmail@science.horizon.com>
linux@horizon.com wrote:
> Newbie question... In what I assume is a usual technique, I maintain a
> "build" branch off of the linux-2.6 history which is what I check out
> to build a kernel. I usually keep it at an official tagged releas,
> such as v2.6.16-rc2.
>
> [[ This is because core git won't allow the checked-out HEAD to point
> to anything but a branch,
Yes it will. That's how "git reset" works (i.e. pointing HEAD to some
random object). Think of branches and tags as short and humanly
understandable names for certain points in the history. You can visit
any point in history without having a special short name for it.
> and checking out something without having
> HEAD point to it is fragile and delicate. Cogito lets you do this with
> cg-seek. ]]
>
It's more than delicate. It's impossible (even for Cogito). You can take
snapshots of how the tree looked at a certain state and export that
using git-tar-tree if you wish, but other than that it's impossible to
visit a certain point in history without pointing HEAD to it (that's how
visiting that point is done, actually).
> Now, if I want to migrate to a newer base version, I can always use
> git-reset --hard v2.6.16-rc3, but that's a bit dangerous.
> Preferable is to use git-rebase v2.6.16-rc3, which will preserve
> any local edits.
>
> (I could also do it as a merge, but that seems like unnecessary history
> clutter. It's not like local edits are common, anyway.)
>
> But suppose discover a nasty bug in -rc3 and want to move my build branch
> back to -rc2. "git-rebase v2.6.16-rc2" does nothing. After a bit
> of thought, I realize why, but sometime I do want to back up.
>
I'd suggest doing something like this when changing base version (of any
project, really). Let's say you start, for the first time, with
v2.6.16-rc2. The workflow would look something like this:
$ git checkout -b mod-2.6.16-rc2 v2.6.16-rc2; # create a branch at the
desired point in history
$ apply your changes
2.6.16-rc3 is out, and you want to use that instead.
$ git checkout -b mod-2.6.16-rc3 v2.6.16-rc3; # new branch for new trial
$ git rebase mod-2.6.16-rc2; # apply patches you've already made
Now a couple of different things can happen:
1. The rebase works fine. Oh, joy of joy!
2. The rebase doesn't work, but a merge does:
$ git pull . mod-2.6.16-rc2
3. Neither merge or rebase works, but you can manually apply your
patches, drop the offending ones or resolve the conflicts.
4. There's a bug so you want to regress. Just do:
$ git checkout mod-2.6.16-rc2
In this scenario, only option 3 means trouble and that's inevitable no
matter how you work since your patches no longer apply.
> What's the best way to do that? Should git-rebase take an optional
> third argument which is the branch head we are moving away from?
> E.g. what I want to do would be
>
> git-rebase v2.6.16-rc2 build v2.6.16-rc3
>
> Or is there some other tool already suited to the job?
>
> (Yes, I'm aware the operations cannot be exact inverses, because if
> I applied a local patch that was also included in -rc3, git-rebase
> will delete the redundant copy from the build branch, and the backing
> up will have no way to know to put it back. If I wanted to do that,
> I would use a merge.)
>
If you merge a branch based on top of a later head you'd end up with the
same commits in your history anyways, since it would have to merge all
commits up to the merge-base. In essence, you'd do a complicated
fast-forward, but with reverse history to what I think you think (i.e.
you'd be pulling 2.6.16-rc3 in on top of your patches).
One way to accomplish this would be to do:
$ git checkout mod-2.6.16-rc3; # get to that point, one way or another
$ git format-patch -k --stdout v2.6.16-rc3 > 2.6.16-rc3.patches.mbox
$ git reset --hard v2.6.16-rc2; # get to that point, one way or another
$ git am -k 2.6.16-rc3.patches.mbox
However, branches and tags are cheap to create, efficient to use, easy
to remove once you're done with them. They make life easier. Use them.
You'll be glad you did.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: What's in git.git
From: linux @ 2006-02-17 14:28 UTC (permalink / raw)
To: junkio; +Cc: git
- "Rebase to different branch" (1 commit):
This was previously discussed on the list. With this command
line:
$ git rebase --onto master~1 master topic
would rebase this ancestry graph to:
A---B---C topic
/
D---E---F---G master
another graph that looks like this:
A'--B'--C' topic
/
D---E---F---G master
Earlier, you couldn't rebase to anywhere other than on top of
"the other branch".
Er... what does this do, again? I couldn't find the list discussion, and
I can get this exact effect in vanilla 1.2.1 with "git rebase master~1 topic".
AFAIK, $ARGV[1] of git-rebase only has to be a commit-ish, not a branch.
OTOH, I can imagine wanting
$ git-rebase master~1 topic topic~2
to produce
A B---C topic
/ /
D---E---F---G master
H'm... I wonder if the same syntax could be used to resolve the ambiguous
case where there are multiple possible common ancestors, e.g.
A---B---C topic
/ /
D---E---F---G master
as discussed in the "git rebase behaviour changed?" thread...
^ 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