* Re: several quick questions
From: Linus Torvalds @ 2006-02-14 17:05 UTC (permalink / raw)
To: Nicolas Vilz 'niv'; +Cc: git
In-Reply-To: <43F20532.5000609@iaglans.de>
On Tue, 14 Feb 2006, Nicolas Vilz 'niv' wrote:
>
> i wonder, how i revoke a straight forward merge of two trees... I
> actually wanted to be look like somewhere in the git-repository, where
> some branches are merged back with the master tree, but i think, that
> wasn't "cg-merge -c <tree to merge with the actual one>"...
>
> my result was that my master tree has now the same sha1-sum as my
> development-tree and gitk visualisation differs from that what i saw in
> the git-repository. (Several Arrows headed into back into one line...)
>
> maybe that was because i didn't do anything in my master tree in the
> meantime.
>
> And another thing, is there no posibility to get back to some commits or
> tags? I realized you can rebranch tags... what, if i want to switch back
> to git version 1.1.6 in the git repository? Or a certain commit?
Both of these can be solved with "git reset".
Before going into any more detail on that, let's go over the other related
"basic operations" too:
- "git branch". This creates a new branch of development at an arbitrary
point (that defaults to "current state").
Example:
git branch development-trial v1.1.6
This will create a new branch called "development-trial", which starts
at the v1.1.6 state. NOTE! It will _not_ check it out - your old active
state is left totally alone, and you still stay on whatever branch you
used to be on.
- "git checkout". This switches to another branch. As a shorthand, you
can also choose to create the branch at the same time, but normally
you'd just do like this example:
git checkout development-trial
which will switch to the branch you just created and check that out.
- "git reset". This will reset the current branch state to something
else. This is what you would use if you want to undo a commit,
for example: you can "reset" the current branch to before the commit
happened.
NOTE! When you do this, you also have to choose what you want to do
about your checked-out working tree. For example, when undoing the last
commit, you normally want to totally undo all the working tree changes
too, but you might also want to just undo the commit, and leave the
actual changes you committed alone, so that you can re-commit them with
a fixed commit message, for example.
Example:
git reset --hard HEAD^
this will undo the last commit (more exactly: it will select the first
parent of HEAD to be the new top-of-development, so if the last thing
you did was a merge, it will reset to the previous state). The "--hard"
means that you want to reset the working tree too.
Other example:
git reset --hard v1.1.6
This will just reset the current branch to a particular known state (ie
1.1.6 in this case).
Without the "--hard", it will _not_ change the working tree, but just
update the index (and branch pointer, of course) to the new state, and
tell you which files are "dirty" in that new state. This is great for
undoing just a "git commit", but leaving the tree in the state is was
before you committed. It's not so great if you expected to revert
everything, and are now confused because "git diff" shows lots of
changes ;)
Finally, let's go over the difference between "git fetch" and "git pull":
- "git fetch" is what you want to do if you want to _update_ another
branch. For example, if you want to track what Junio is doing in his
git repository (assuming that was what you cloned for), doing
git fetch origin
will update the "origin" branch, but will _not_ touch the current
branch itself. This is very useful for seeing what Junio has been
doing, without actually affecting your own work in any way.
- "git pull" is really just "git fetch" + "git merge". It will fetch the
state you asked for, and then merge that into your current branch. So
it's important to rmember that this actually _changes_ what you have
checked out and have worked on.
One very special case of "git pull" is when you only use the repository
to track another branch, and you never do any changes at all, and you
never switch branches around, and you always pull from the same source.
In that case, "git pull" will basically boil down to just a read-only
tracking mechanism (ie you could think of this particular usage as
being the git equivalent of "anoncvs" access)
The reason people may get confused is that they start out using "git pull"
as a read-only tracking mechanism, and it's not necessarily obvious that
"git pull" really fundamentally is a very powerful operations - much MUCH
more complex and powerful than just "track that other branch". Which is
why I try to make the distinction between "git fetch" and "git pull"
clear.
Linus
^ permalink raw reply
* git-svnimport issue with rename+change in the same commit
From: Eduardo Pereira Habkost @ 2006-02-14 17:12 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1708 bytes --]
Hi,
I've just hit a problem when using git-svnimport to import a big
subversion repository: it doesn't import correctly a commit when the
commit renames (or copies) and modify a file at the same time.
At the bottom of this message, there is a script that reproduces the bug.
The result of the final 'diff' command on the script is:
diff -u --exclude .git --exclude .svn checkout/universe.py
git/universe.py
--- checkout/universe.py 2006-02-14 14:55:37.000000000 -0200
+++ git/universe.py 2006-02-14 14:55:38.000000000 -0200
@@ -1 +1 @@
-print "Hello, universe!"
+print "Hello, world!"
git-svnadmin is just taking the original version of the file when
the commit has a 'file copy', even if this copy was modified before
the commit.
However I can't see a way to fix this problem without making the script
ignore completely the the "copied from" information from the svn commits
(and always fetching the resulting files from the repository). It seems
that subversion doesn't tell us if the copied file was changed (or this
information is hidden somewhere else).
--
Eduardo
#!/bin/sh
set -e
mkdir repos
svnadmin create $PWD/repos
repos=file://$PWD/repos
svn mkdir $repos/trunk -m 'creating trunk'
svn co file://$PWD/repos/trunk checkout
cd checkout
cat >hello.py <<EOF
print "Hello, world!"
EOF
svn add hello.py
svn commit -m 'adding hello.py'
svn mv hello.py world.py
svn commit -m 'renaming to world.py'
svn mv world.py universe.py
sed -i -e 's/world/universe/' universe.py
svn commit -m 'universe, now'
cd ..
mkdir git
cd git
git svnimport $repos
cd ..
diff -u --exclude .git --exclude .svn checkout git # will report differences
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git-svnimport issue with rename+change in the same commit
From: Manu @ 2006-02-14 17:29 UTC (permalink / raw)
To: Eduardo Pereira Habkost; +Cc: git
In-Reply-To: <20060214171233.GC4381@duckman.conectiva>
Hi,
Eduardo Pereira Habkost wrote:
> Hi,
>
> I've just hit a problem when using git-svnimport to import a big
> subversion repository: it doesn't import correctly a commit when the
> commit renames (or copies) and modify a file at the same time.
I came accross the same problem myself. Here is a patch that seemed to
do the trick for me.
I tried your script, and it also seems to work.
Regards,
Emmanuel
---
[PATCH] git-svnimport: Correction when a "copy_path" has different
contents for src and dest.
In my SVN repository, there is a weird log:
A /trunk/mydir2 (from /trunk/mydir1:4)
R /trunk/mydir2/test.txt (from /trunk/mydir1/test.txt:4)
As a result, mydir2/test.txt is different than mydir1/test.txt, but
git-svnimport assumes that the content of mydir2/test.txt is the same
as mydir1/test.txt.
This patch adds a test in copy_path, that makes sure that src and dest
have the same content. If not, it uses the content of dest.
---
git-svnimport.perl | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
e107ff9a06497a0003036ffafa45fa9dc050ecc4
diff --git a/git-svnimport.perl b/git-svnimport.perl
index f17d5a2..a2faa9a 100755
--- a/git-svnimport.perl
+++ b/git-svnimport.perl
@@ -409,6 +409,12 @@ sub copy_path($$$$$$$$) {
$p = $path . substr($p,length($srcpath)-1);
} else {
$p = $path;
+ # Deal with copy and modification
+ my $f=get_file($newrev,$newbranch,$path);
+ my ($tmode,$tsha1,$tp)=@$f;
+ if ($tsha1 ne $sha1) {
+ $sha1=$tsha1;
+ }
}
push(@$new,[$mode,$sha1,$p]);
}
--
1.1.GIT
^ permalink raw reply related
* bug: stgit doesn't handle branch names with / in them
From: Karl Hasselström @ 2006-02-14 17:35 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
"stg branch -l" only shows branches directly under refs/heads, and
completely ignores branches in subdirectories. But it does print the
name of the subdirectories . . .
"stg branch" prints only the part of the branch name following the
final slash.
$ git-branch
kha/abc123
kha/dab
* kha/patches
kha/powerup
kha/dare
kha/dare-build
kha/boo123
kha/lisp106
local/test0
local/test3
local/test4
SVN-import
test5
$ stg branch -l
Available branches:
SVN-import |
kha |
local |
test5 |
$ stg branch
patches
No patch (yet), sorry.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: several quick questions
From: Kenneth Johansson @ 2006-02-14 17:47 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0602140845080.3691@g5.osdl.org>
On Tue, 14 Feb 2006 09:05:16 -0800, Linus Torvalds wrote:
>
>
> On Tue, 14 Feb 2006, Nicolas Vilz 'niv' wrote:
>>
>> i wonder, how i revoke a straight forward merge of two trees... I
>> actually wanted to be look like somewhere in the git-repository, where
>> some branches are merged back with the master tree, but i think, that
>> wasn't "cg-merge -c <tree to merge with the actual one>"...
>>
>> my result was that my master tree has now the same sha1-sum as my
>> development-tree and gitk visualisation differs from that what i saw in
>> the git-repository. (Several Arrows headed into back into one line...)
>>
>> maybe that was because i didn't do anything in my master tree in the
>> meantime.
>>
>> And another thing, is there no posibility to get back to some commits or
>> tags? I realized you can rebranch tags... what, if i want to switch back
>> to git version 1.1.6 in the git repository? Or a certain commit?
>
> Both of these can be solved with "git reset".
I also had this exact question today since I wanted to compile an earlier
version of the kernel and like Nicolas I naturally got stuck on the
checkout command and that dose not work like one would think.
What I ended up doing was going nee deep into the plumbing.
first doing cat on the tag in .git/refs/tags/
taking the output as an argument to "git-read-tree"
followed by "git-update-index --replace" and "git-checkout-index -a -f -u"
I'm not sure that many people will understand that they want git-reset for
this just reading the man pages.
^ permalink raw reply
* [PATCH 1/2] cg-clean shouldn't clean untracked directories without -d
From: Pavel Roskin @ 2006-02-14 18:05 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
Use the new squashdirs argument in list_untracked_files() to treat
untracked directories and their contents as a whole. Remove a separate
pass to find untracked directories. Adjust the testsuite accordingly.
Don't change IFS - it's no longer needed.
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
cg-clean | 99 ++++++++++--------------------------------------------
t/t9400-clean.sh | 3 +-
2 files changed, 20 insertions(+), 82 deletions(-)
diff --git a/cg-clean b/cg-clean
index b40b41b..5c27a26 100755
--- a/cg-clean
+++ b/cg-clean
@@ -53,88 +53,27 @@ done
[ ${#ARGS[*]} = 0 ] || usage
-
-clean_dirs()
-{
- dirlist="$(mktemp -t gitlsfiles.XXXXXX)"
- git-ls-files --cached |
- sed -n 's|/[^/]*$||p' |
- while IFS=$'\n' read -r dir; do
- while true; do
- echo "$dir"
- updir="${dir%/*}"
- [ "$dir" = "$updir" ] && break
- dir="$updir"
- done
- done |
- sort -u >"$dirlist"
-
- save_IFS="$IFS"
- IFS=$'\n'
-
- find ./ -type d -print |
- sed 's/^\.\///;/^$/d;/^\.git$/d;/^\.git\//d' |
- cat - "$dirlist" | sort -u |
- diff - "$dirlist" |
- sed -n 's/< //p' |
- while read -r dir; do
- if [ ! -d "$dir" ]; then
- # Perhaps directory was removed with its parent
- continue
- fi
+cd "${_git_relpath-.}"
+list_untracked_files "$noexclude" squashdirs | tr '\0' '\n' |
+while read -r file; do
+ if [ -d "$file" -a ! -L "$file" ]; then
if [ -z "$cleandir" ]; then
- echo "Not removing $dir/"
+ echo "Not removing $file"
continue
fi
- [ "$quiet" ] || echo "Removing $dir/"
+ [ "$quiet" ] || echo "Removing $file"
if [ "$cleandirhard" ]; then
- chmod -R 700 "$dir"
+ chmod -R 700 "$file"
fi
- $rm -rf "$dir"
- if [ -e "$dir" -o -L "$dir" ]; then
- echo "Cannot remove $dir/"
- fi
- done
-
- IFS="$save_IFS"
- rm "$dirlist"
-}
-
-clean_files()
-{
- save_IFS="$IFS"
- IFS=$'\n'
-
- list_untracked_files "$noexclude" nosquashdirs | tr '\0' '\n' |
- (cd "${_git_relpath-.}" &&
- while read -r file; do
- if [ -z "$_git_relpath" ] || [ x"${file#$_git_relpath}" != x"$file" ]; then
- file="${file#$_git_relpath}"
- else
- continue
- fi
-
- if [ -d "$file" -a ! -L "$file" ]; then
- # Sanity check, shouldn't happen
- echo "FATAL: cg-status reports directories (internal error)" >&2
- exit 1
- elif [ -e "$file" -o -L "$file" ]; then
- [ "$quiet" ] || echo "Removing $file"
- "$rm" -f "$file"
- # rm would complain itself on failure
- else
- echo "File $file has disappeared!"
- fi
- done)
-
- IFS="$save_IFS"
-}
-
-
-# Even if -d or -D is not specified, we want to tell user about
-# directories that are not removed
-if [ -z "$quiet" -o "$cleandir" ]; then
- ( cd "${_git_relpath-.}" && clean_dirs )
-fi
-
-clean_files
+ $rm -rf "$file"
+ if [ -e "$file" -o -L "$file" ]; then
+ echo "Cannot remove $file"
+ fi
+ elif [ -e "$file" -o -L "$file" ]; then
+ [ "$quiet" ] || echo "Removing $file"
+ "$rm" -f "$file"
+ # rm would complain itself on failure
+ else
+ echo "File $file has disappeared!"
+ fi
+done
diff --git a/t/t9400-clean.sh b/t/t9400-clean.sh
index 47ae0dc..98801c5 100755
--- a/t/t9400-clean.sh
+++ b/t/t9400-clean.sh
@@ -84,10 +84,8 @@ echo "ign file 3" >"repo dir/ign file 3.
echo "ign file 4" >"repo dir/ign file 4.ign1"
mklist init
-# FIXME: cg-clean shouldn't clean unknown directories without "-d"
loss='extra file 1
ign file 2.ign1
-extra dir 1/extra file 3
repo dir/extra file 2'
test_expect_success 'cg-clean in top-level dir' \
"(cg-clean && check_loss)"
@@ -99,6 +97,7 @@ test_expect_success 'cg-clean -x in top-
"(cg-clean -x && check_loss)"
loss='extra dir 1
+extra dir 1/extra file 3
repo dir/extra dir 2'
test_expect_success 'cg-clean -d in top-level dir' \
"(cg-clean -d && check_loss)"
^ permalink raw reply related
* [PATCH 2/2] Workaround git < 1.2.0 ignoring .gitignore in parent directories
From: Pavel Roskin @ 2006-02-14 18:05 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060214180520.13766.78172.stgit@dv.roinet.com>
Add --exclude-from for all existing .gitignore files in parent
directories up to the repository root. This is not needed for git 1.2.0
and newer.
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
cg-Xlib | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/cg-Xlib b/cg-Xlib
index 85a21c2..af278b6 100644
--- a/cg-Xlib
+++ b/cg-Xlib
@@ -230,6 +230,22 @@ list_untracked_files()
EXCLUDE[${#EXCLUDE[@]}]="--exclude-from=$EXCLUDEFILE"
fi
EXCLUDE[${#EXCLUDE[@]}]="--exclude-per-directory=.gitignore"
+ # Workaround for git < 1.2.0
+ if [ -n "$_git_relpath" ]; then
+ local dir="${_git_relpath%/}"
+ local reldir=".."
+ while [ "$dir" != "." ]; do
+ if [ "${dir%/*}" = "$dir" ]; then
+ dir="."
+ else
+ dir="${dir%/*}"
+ fi
+ if [ -f "$reldir/.gitignore" ]; then
+ EXCLUDE[${#EXCLUDE[@]}]="--exclude-from=$dir/.gitignore"
+ fi
+ reldir="../$reldir"
+ done
+ fi
fi
local listdirs=
[ "$squashflag" = "squashdirs" ] && listdirs=--directory
^ permalink raw reply related
* Re: several quick questions
From: Andreas Ericsson @ 2006-02-14 18:08 UTC (permalink / raw)
To: Kenneth Johansson; +Cc: git
In-Reply-To: <pan.2006.02.14.17.47.53.126690@canit.se>
Kenneth Johansson wrote:
>
> I'm not sure that many people will understand that they want git-reset for
> this just reading the man pages.
>
Hence the tutorial.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: several quick questions
From: Carl Worth @ 2006-02-14 18:10 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nicolas Vilz 'niv', git
In-Reply-To: <Pine.LNX.4.64.0602140845080.3691@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 2123 bytes --]
On Tue, 14 Feb 2006 09:05:16 -0800 (PST), Linus Torvalds wrote:
>
> Both of these can be solved with "git reset".
...
> - "git branch". This creates a new branch of development at an arbitrary
> point (that defaults to "current state").
>
> - "git checkout". This switches to another branch.
>
> - "git reset". This will reset the current branch state to something
> else.
Thanks for the summary.
I don't know if it's the original poster's question or not, but an
operation I don't see in the above is "put the working files into the
state of a given revision".
I recently needed this for some historical investigation,
(specifically examining all release tags to ensure that the results
after a git import match the results of what we get from the former
CVS repository).
In this kind of historical exploration, the notion of a "current
branch" isn't interesting, since I won't be doing any commits. So the
handling of the current branch in the above commands ends up getting
in my way [*].
Is there a more fundamental operation to "put the working files into
the state of the index"? If that exists, then that combined with
git-read-tree would give me what I wanted I think.
-Carl
[*] I did succeed in performing the operation, but only in rather
awkward ways. Here are a couple of versions of "put the working files
into the state of <revision>", both requiring the use of an otherwise
unnecessary branch, (bogus-branch):
1) Ensure bogus-branch doesn't exist, then create it at <revision>:
# Can't be on bogus-branch when we delete it
git checkout master
# Use -D to force the removal, ignore errors for branch-does-not-exist
git branch -D bogus-branch >& /dev/null || true
# Create the branch where we want it
git checkout -b bogus-branch <revision>
2) Ensure that bogus-branch exists somewhere (don't care where), then
move it:
# Create the branch (if it doesn't exist)
git checkout -b bogus-branch >& /dev/null
# Switch to it (which doesn't happen above if it already existed)
git checkout bogus-branch
# Move the branch to the revision of interest
git reset --hard <revision>
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: cg-clean, cg-status improvements
From: Pavel Roskin @ 2006-02-14 18:17 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060214155356.GB9573@pasky.or.cz>
On Tue, 2006-02-14 at 16:53 +0100, Petr Baudis wrote:
> I didn't plan to require git 1.2.0 with 0.17, so it would be better if
> you could do the workaround. But if the workaround means significant
> hassle, it's no biggie if git 1.2.0 will be required.
It turns out a proper workaround can only be implemented in cg-Xlib, not
in cg-clean. It's a bit hairy for my taste (a bash guru could write it
better, I believe), but it's a compact blob of code that can be easily
removed at any time.
The patches have been sent by StGIT.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: several quick questions
From: Kenneth Johansson @ 2006-02-14 18:21 UTC (permalink / raw)
To: git
In-Reply-To: <43F21CB1.5010203@op5.se>
On Tue, 14 Feb 2006 19:08:49 +0100, Andreas Ericsson wrote:
> Kenneth Johansson wrote:
>>
>> I'm not sure that many people will understand that they want git-reset for
>> this just reading the man pages.
>>
>
> Hence the tutorial.
It could be a little clearer what you would do in any other tool is
checkout a specifically tagged version. Perhaps adding a pointer from the
checkout man page to the reset command.
^ permalink raw reply
* Re: several quick questions
From: Linus Torvalds @ 2006-02-14 18:26 UTC (permalink / raw)
To: Kenneth Johansson; +Cc: git
In-Reply-To: <pan.2006.02.14.17.47.53.126690@canit.se>
On Tue, 14 Feb 2006, Kenneth Johansson wrote:
>
> What I ended up doing was going nee deep into the plumbing.
>
> first doing cat on the tag in .git/refs/tags/
> taking the output as an argument to "git-read-tree"
> followed by "git-update-index --replace" and "git-checkout-index -a -f -u"
>
> I'm not sure that many people will understand that they want git-reset for
> this just reading the man pages.
Hey, but I bet you now as a result feel you really understand git, right?
;)
You did it the old-fashioned way - the way real men did it back in June.
In general, doing "ls *.sh" in the git source tree shows you pretty much
every command that you might ever want to use. Using the actual core git
binaries directly is normally not all that useful, unless you want to do
some strange shell pipeline to do statistics about different things in the
tree.
Linus
^ permalink raw reply
* Re: several quick questions
From: Linus Torvalds @ 2006-02-14 18:34 UTC (permalink / raw)
To: Carl Worth; +Cc: Nicolas Vilz 'niv', git
In-Reply-To: <87k6bxvmj6.wl%cworth@cworth.org>
On Tue, 14 Feb 2006, Carl Worth wrote:
>
> I don't know if it's the original poster's question or not, but an
> operation I don't see in the above is "put the working files into the
> state of a given revision".
What a strange thing to ask for.
But you can do it several ways:
- just use "git reset" to move around in history, possibly on a temporary
branch.
- use "git checkout <rev> <filename>" to checkout a particular filename
of a particular version (it's a special case of "git checkout", which
is useful, but I personally think it's a bit confusing, so I wouldn't
mention it unless you asked)
- use the core internal git functions, in particular
git-read-tree -m -u <oldtree> <newtree>
will switch from "oldtree" to "newtree" and update (-u) the working
tree.
> 2) Ensure that bogus-branch exists somewhere (don't care where), then
> move it:
>
> # Create the branch (if it doesn't exist)
> git checkout -b bogus-branch >& /dev/null
> # Switch to it (which doesn't happen above if it already existed)
> git checkout bogus-branch
> # Move the branch to the revision of interest
> git reset --hard <revision>
This is actually what I'd suggest you always do.
Why?
It's actually as efficient as anything else, and there's much less room
for confusion. When you want to go back, you can just do a simple
git checkout -f master
and there's no room for confusion. You've not lost sight of any old state,
and your HEAD never differs from your checked-out copy, so all the normal
commands work the way you'd expect them to.
Linus
^ permalink raw reply
* Re: several quick questions
From: Carl Worth @ 2006-02-14 18:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nicolas Vilz 'niv', git
In-Reply-To: <87k6bxvmj6.wl%cworth@cworth.org>
[-- Attachment #1: Type: text/plain, Size: 590 bytes --]
On Tue, 14 Feb 2006 10:10:53 -0800, Carl Worth wrote:
>
> Is there a more fundamental operation to "put the working files into
> the state of the index"? If that exists, then that combined with
> git-read-tree would give me what I wanted I think.
Oh, I'm blind. I didn't see git-checkout-index, (thanks Kenneth for
mentioning it elsewhere in the thread). So now I've at least got the
recipe I was after:
git-read-tree <revision>
git-update-index --replace
git-checkout-index -a -f -u
And I think that would make for a dandy command to have in git. Any
suggestions for a name?
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: several quick questions
From: Keith Packard @ 2006-02-14 18:55 UTC (permalink / raw)
To: Carl Worth; +Cc: keithp, Linus Torvalds, Nicolas Vilz 'niv', git
In-Reply-To: <87k6bxvmj6.wl%cworth@cworth.org>
[-- Attachment #1: Type: text/plain, Size: 579 bytes --]
On Tue, 2006-02-14 at 10:10 -0800, Carl Worth wrote:
> I don't know if it's the original poster's question or not, but an
> operation I don't see in the above is "put the working files into the
> state of a given revision".
I was using:
rm -r *
rm -f .cvsignore .gitignore
git-reset --hard <tag>
to get to a specific tag. Of course, I cloned the repository and did
this in a separate directory; I wanted to make sure nothing 'bad'
happened to my working directory.
Creating a fake branch seemed like a lot more bother.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Handling large files with GIT
From: Johannes Schindelin @ 2006-02-14 18:56 UTC (permalink / raw)
To: Ian Molton; +Cc: git
In-Reply-To: <43F113A5.2080506@f2s.com>
Hi,
On Mon, 13 Feb 2006, Ian Molton wrote:
> Im curious as to why anyone would want to use a SCM tool on a mail dir
> anyway - surely no-one edits their pasnt mails and needs to keep logs?
>
> surely incremental backups would be a better way to manage something
> like this?
Point is, if you want to read your email on different computers (like one
desktop and one laptop), you are quite well off managing them with git. Of
course, you could rsync them from/to the other computer. But rsync is slow
once you accumulated enough files, since it has to compare the hashes of
tons of files (or file chunks). Git knows if they have changed.
Hth,
Dscho
^ permalink raw reply
* Re: several quick questions
From: Linus Torvalds @ 2006-02-14 19:00 UTC (permalink / raw)
To: Carl Worth; +Cc: Nicolas Vilz 'niv', git
In-Reply-To: <87irrhvkyl.wl%cworth@cworth.org>
On Tue, 14 Feb 2006, Carl Worth wrote:
>
> Oh, I'm blind. I didn't see git-checkout-index, (thanks Kenneth for
> mentioning it elsewhere in the thread). So now I've at least got the
> recipe I was after:
>
> git-read-tree <revision>
> git-update-index --replace
> git-checkout-index -a -f -u
This is very very inefficient, because it will replace the old
index without using the (valid) information that is there from before.
Resulting in a lot of unnecessary IO..
You may not care for a small project, but for bigger stuff, you're better
off using more subtle approaches.
Explore using "git-read-tree --reset <revision>" or, perhaps even more
interesting is "git-read-tree -u -m <oldrev> <newrev>"
> And I think that would make for a dandy command to have in git. Any
> suggestions for a name?
I'd suggest "git reset" as a cool way to say that it "resets" the tree to
another version ;)
Linus
^ permalink raw reply
* Re: several quick questions
From: Linus Torvalds @ 2006-02-14 19:04 UTC (permalink / raw)
To: Keith Packard; +Cc: Carl Worth, Nicolas Vilz 'niv', git
In-Reply-To: <1139943349.4341.66.camel@evo.keithp.com>
On Tue, 14 Feb 2006, Keith Packard wrote:
>
> I was using:
>
> rm -r *
> rm -f .cvsignore .gitignore
> git-reset --hard <tag>
Ooh.
Try doing that on a big project, and it will just kill you. You've also
lost the "top-of-branch" info, but if you're just tracking some other
tree, that's likely not an issue.
(actually, under Linux, with enough memory, and the git stuff all cached,
it will perform pretty well, but that's just because the OS does a _lot_
to try to hide how expensive it is to re-write everything. And even under
Linux it will suck in the cold-cache case).
> Creating a fake branch seemed like a lot more bother.
You'll find that if cairo ever grows bigger, it has huge advantages to
switch between branches (or any random state, for that matter) without
having to rewrite it all is a _major_ performance impact.
Linus
^ permalink raw reply
* Re: several quick questions
From: Junio C Hamano @ 2006-02-14 19:13 UTC (permalink / raw)
To: Carl Worth; +Cc: git
In-Reply-To: <87k6bxvmj6.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> writes:
> 2) Ensure that bogus-branch exists somewhere (don't care where), then
> move it:
>
> # Create the branch (if it doesn't exist)
> git checkout -b bogus-branch >& /dev/null
> # Switch to it (which doesn't happen above if it already existed)
> git checkout bogus-branch
> # Move the branch to the revision of interest
> git reset --hard <revision>
For moving around in history (like cg-seek if I understand
correctly), the above is the right and probably most efficient
way to do with the core-git tools.
# setup
$ git branch -f temp ;# make sure it exists
$ git checkout temp ;# and switch to it
# repeatedly...
$ git reset --hard <revision1>
# do interesting things
$ git reset --hard <revision2>
# do interesting things
$ git reset --hard <revision3>
# ...
$ git reset --hard <revisionn>
# do interesting things
# once you are done
$ git checkout master
$ git branch -D temp
^ permalink raw reply
* Re: several quick questions
From: Andreas Ericsson @ 2006-02-14 19:38 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Carl Worth, Nicolas Vilz 'niv', git
In-Reply-To: <Pine.LNX.4.64.0602141056170.3691@g5.osdl.org>
Linus Torvalds wrote:
>
> I'd suggest "git reset" as a cool way to say that it "resets" the tree to
> another version ;)
>
OTOH, it would be nifty (and I imagine not particularly hard) to teach
"git checkout" to check out any revision, and not just a branch.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: several quick questions
From: Keith Packard @ 2006-02-14 19:39 UTC (permalink / raw)
To: Linus Torvalds; +Cc: keithp, Carl Worth, Nicolas Vilz 'niv', git
In-Reply-To: <Pine.LNX.4.64.0602141101110.3691@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 654 bytes --]
On Tue, 2006-02-14 at 11:04 -0800, Linus Torvalds wrote:
> Try doing that on a big project, and it will just kill you. You've also
> lost the "top-of-branch" info, but if you're just tracking some other
> tree, that's likely not an issue.
I was validating the cvs import by comparing every tagged version. Trust
me, the git tree-rewriting stage was somewhat faster than the CVS
checkout of the same content. And, as an egg, one often prefers BFI to
finesse. I had trouble figuring out precisely what sequence of commands
were needed to make git-reset --hard happy with existing bits in the
directory.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: several quick questions
From: Petr Baudis @ 2006-02-14 19:46 UTC (permalink / raw)
To: Nicolas Vilz 'niv'; +Cc: git
In-Reply-To: <43F20532.5000609@iaglans.de>
Hi,
now from the simple Cogito's point of view. I will swap the two parts
of your mail.
Dear diary, on Tue, Feb 14, 2006 at 05:28:34PM CET, I got a letter
where Nicolas Vilz 'niv' <niv@iaglans.de> said that...
> And another thing, is there no posibility to get back to some commits or
> tags? I realized you can rebranch tags... what, if i want to switch back
> to git version 1.1.6 in the git repository? Or a certain commit?
>
> do you have to make a new private branch out of the tag 1.1.6?
>
> i used svn and there i could go back some revisions. I haven't found
> such a feature in git, yet... but i think i am blind all the time.
The simple answer is cg-seek, which is meant for temporary ventures to
the commit history - e.g. you want to go back to git version 1.1.6, but
intend to do no development on top of it and to return back to the top
later. cg-seek will remember "where you came from" and by doing either
cg-reset or simply calling cg-seek without any parameters, it will
return back to the top.
If you want to permanently change your branch to point to the 1.1.6
tag, the command to use is cg-switch -f. There is also a simpler but
less powerful variant of this command available as cg-admin-uncommit.
> i wonder, how i revoke a straight forward merge of two trees... I
> And another thing, is there no posibility to get back to some commits or
> tags? I realized you can rebranch tags... what, if i want to switch back
> to git version 1.1.6 in the git repository? Or a certain commit?
>
> do you have to make a new private branch out of the tag 1.1.6?
>
> i used svn and there i could go back some revisions. I haven't found
> such a feature in git, yet... but i think i am blind all the time.
>
> I like git very much and every new day I like it more.
> actually wanted to be look like somewhere in the git-repository, where
> some branches are merged back with the master tree, but i think, that
> wasn't "cg-merge -c <tree to merge with the actual one>"...
>
> my result was that my master tree has now the same sha1-sum as my
> development-tree and gitk visualisation differs from that what i saw in
> the git-repository. (Several Arrows headed into back into one line...)
>
> maybe that was because i didn't do anything in my master tree in the
> meantime.
So I assume that it made a fast-forward merge and you want to undo it.
Unfortunately, there is no facility to automatically remember what your
previous last commit was, so you either:
* Remember the "fast-forwarding" message cg-merge gave you. ;-)
* Fire up cg-log and find the commit you want to go back to.
Now, when you have the commit id, this is the time for cg-switch -f -
what you want to do is to "repoint" your current branch (let's assume it
is master) to the commit id you've just found:
cg-switch -f -r commit_id master
(The same thing could be done using cg-admin-uncommit, but it is a
little confusing in this particular usage; you would have to rather
choose the commit id of the last commit to uncommit, and it does not
cope well with merges.)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: Handling large files with GIT
From: Linus Torvalds @ 2006-02-14 19:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Ian Molton, git
In-Reply-To: <Pine.LNX.4.63.0602141953000.22451@wbgn013.biozentrum.uni-wuerzburg.de>
On Tue, 14 Feb 2006, Johannes Schindelin wrote:
>
> Point is, if you want to read your email on different computers (like one
> desktop and one laptop), you are quite well off managing them with git. Of
> course, you could rsync them from/to the other computer. But rsync is slow
> once you accumulated enough files, since it has to compare the hashes of
> tons of files (or file chunks). Git knows if they have changed.
Yes. I actually think that git would be a _wonderful_ email tracking tool,
but that may not mean that it's a wonderful tool for tracking all
particular email layout possibilities. It clearly is _not_ a wonderful
tool for tracking mbox-style email setups, for example ;)
I suspect we actually could make the "one linear directory" setup perform
pretty well. It wouldn't be the best possible layout (by far), but I think
our problems there are just because of some decisions we've (me, mostly)
made that didn't take that layout into account. I don't think the problems
are in any way fundamental.
That said, I think git could do much better if the layout was optimized
for git. For example, in the maildir thing, there's two issues: the flat
directory structure is sub-optimal, but the other thing seems to be that
maildir apparently saves metadata in the filename.
Saving meta-data in the filename should actually work wonderfully well
with git, but both merging and git-diff-tree consider the filename to be
the "index", so they optimize for that. You could do indexing the other
way around, and consider the contents to be the index (and the filename is
the "status"), but that's obviously not sane for a sw project, even if it
might be exactly what you want to do for mail handling.
Linus
^ permalink raw reply
* Re: several quick questions
From: Carl Worth @ 2006-02-14 20:10 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nicolas Vilz 'niv', git
In-Reply-To: <Pine.LNX.4.64.0602141026570.3691@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 2201 bytes --]
On Tue, 14 Feb 2006 10:34:35 -0800 (PST), Linus Torvalds wrote:
> On Tue, 14 Feb 2006, Carl Worth wrote:
> >
> > I don't know if it's the original poster's question or not, but an
> > operation I don't see in the above is "put the working files into the
> > state of a given revision".
>
> What a strange thing to ask for.
It's pretty common in other tools. For example, many tools have a way
to examine the files from a previous state in a "no current branch"
state. Any attempt to commit from that state would prompt the user to
create a new branch name at that point.
In fact, this is the natural operation for the basis of something like
git-bisect.
> It's actually as efficient as anything else, and there's much less room
> for confusion. When you want to go back, you can just do a simple
>
> git checkout -f master
OK, the efficiency arguments made elsewhere in the thread make it
clear that these are the operations that need to happen.
But I'd still like to be able to do this without having to invent a
fake branch name, without the ability to accidentally commit on the
fake branch, and without the possibility of accidentally leaving those
commits dangling the next time I seek somewhere else.
So I looked, and git-bisect does use this approach with a fake branch
of "bisect" and by saving the original head ref in $GIT_DIR/head-name
for the sake of the final "git bisect reset".
Also, git-bisect does take advantage of the $GIT_DIR/head-name state
to prevent nested calls to "git bisect start", ("won't bisect on
seeked tree").
That gives a very natural name, "seek", for the operation I'd like.
How about "git seek" for doing the operations above, and using some
reserved branch name, (say "seek"). Then, git-bisect could easily be
built on that, and git-commit could respect the "seek" name and refuse
to commit to it, (could tell the user how to create the branch
necessary to commit from the current point).
There could also be a "git seek reset" to return to the HEAD saved by
the first in a chain of "git seek" operations.
That looks like I minor generalization of existing behavior in
git-bisect, but it would provide an operation that I would find
useful.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: several quick questions
From: Carl Worth @ 2006-02-14 20:14 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nicolas Vilz 'niv', git
In-Reply-To: <Pine.LNX.4.64.0602141056170.3691@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 586 bytes --]
On Tue, 14 Feb 2006 11:00:44 -0800 (PST), Linus Torvalds wrote:
> > And I think that would make for a dandy command to have in git. Any
> > suggestions for a name?
>
> I'd suggest "git reset" as a cool way to say that it "resets" the tree to
> another version ;)
Heh. It also moves a branch name though, and that's the part I don't
want. See my suggestion elsewhere of "git seek". [*]
-Carl
[*] Yes, I appear doomed to be reinventing cogito piecemeal. I got
"seek" from the error message in git-bisect, before I heard about
cg-seek, (as Junio pointed out elsewhere in the thread).
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ 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