* Re: sending changesets from the middle of a git tree
From: Linus Torvalds @ 2005-08-14 5:03 UTC (permalink / raw)
To: Steve French; +Cc: git
In-Reply-To: <42FEBC16.9050309@austin.rr.com>
On Sat, 13 Aug 2005, Steve French wrote:
>
> 1) There is no way to send a particular changeset from the "middle" of a
> set from one tree to another, without exporting it as a patch or
> rebuilding a new git tree.
Correct.
> If I export those two changesets as patches, and send them on.
> presumably I lose the changset comments etc.
Well, you can export them with "git send-email" and you won't be losing
any comments.
Alternatively, use "git cherry", which helps re-order the commits in your
tree. They'll be _new_ commits, but they'll have the contents moved over.
Junio, maybe you want to talk about how you move patches from your "pu"
branch to the real branches.
> and then when the upstream tree is merged back, it might look a little
> odd in the changeset history.
Well, you'll end up having the same change twice. It happens. Or if you
just redo your tree as a separate branch, you can reorder things so that
you don't have them twice at all.
> 2) There is no way to update the comment field of a changeset after it
> goes in (e.g. to add a bugzilla bug number for a bug that was opened
> just after the fix went in).
That's correct. Same things apply: you can move a patch over, and create a
new one with a modified comment, but basically the _old_ commit will be
immutable.
The good news is that it means that nobody else can change what you said
or did either.
> 3) There is no way to do a test commit of an individual changeset
> against a specified tree (to make sure it would still merge cleanly,
> automatically).
Oh, sure, that's certainly very possible, and the git cherry stuff even
helps you do it. Or use "git-apply --check" to just see if a patch
applies and do your own scripts.
Linus
^ permalink raw reply
* Re: sending changesets from the middle of a git tree
From: Linus Torvalds @ 2005-08-14 5:16 UTC (permalink / raw)
To: Steve French; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0508132155100.3553@g5.osdl.org>
On Sat, 13 Aug 2005, Linus Torvalds wrote:
> That's correct. Same things apply: you can move a patch over, and create a
> new one with a modified comment, but basically the _old_ commit will be
> immutable.
Let me clarify.
You can entirely _drop_ old branches, so commits may be immutable, but
nothing forces you to keep them. Of course, when you drop a commit, you'll
always end up dropping all the commits that depended on it, and if you
actually got somebody else to pull that commit you can't drop it from
_their_ repository, but undoing things is not impossible.
For example, let's say that you've made a mess of things: you've committed
three commits "old->a->b->c", and you notice that "a" was broken, but you
want to save "b" and "c". What you can do is
# Create a branch "broken" that is the current code
# for reference
git branch broken
# Reset the main branch to three parents back: this
# effectively undoes the three top commits
git reset HEAD^^^
git checkout -f
# Check the result visually to make sure you know what's
# going on
gitk --all
# Re-apply the two top ones from "broken"
#
# First "parent of broken" (aka b):
git-diff-tree -p broken^ | git-apply --index
git commit --reedit=broken^
# Then "top of broken" (aka c):
git-diff-tree -p broken | git-apply --index
git commit --reedit=broken
and you've now re-applied (and possibly edited the comments) the two
commits b/c, and commit "a" is basically gone (it still exists in the
"broken" branch, of course).
Finally, check out the end result again:
# Look at the new commit history
gitk --all
to see that everything looks sensible.
And then, you can just remove the broken branch if you decide you really
don't want it:
# remove 'broken' branch
rm .git/refs/heads/broken
# Prune old objects if you're really really sure
git prune
And yeah, I'm sure there are other ways of doing this. And as usual, the
above is totally untested, and I just wrote it down in this email, so if
I've done something wrong, you'll have to figure it out on your own ;)
Linus
^ permalink raw reply
* [PATCH] clean up git script
From: Amos Waterland @ 2005-08-14 5:16 UTC (permalink / raw)
To: git
Makes git work with a pure POSIX shell (tested with bash --posix and ash).
Right now git causes ash to choke on the redundant shift on line two.
Reduces the number of system calls git makes just to do a usage
statement from 22610 to 1122, and the runtime for same from 349ms to
29ms on my x86 Linux box.
Presents a standard usage statement, and pretty prints the available
commands in a form that does not scroll off small terminals.
Signed-off-by: Amos Waterland <apw@rossby.metr.ou.edu>
---
git | 27 +++++++++++++--------------
1 files changed, 13 insertions(+), 14 deletions(-)
diff --git a/git b/git
--- a/git
+++ b/git
@@ -1,19 +1,18 @@
#!/bin/sh
+
cmd="$1"
-shift
-if which git-$cmd-script >& /dev/null
-then
- exec git-$cmd-script "$@"
-fi
+path=$(dirname $0)
-if which git-$cmd >& /dev/null
-then
- exec git-$cmd "$@"
-fi
+test -x $path/git-$cmd-script && exec $path/git-$cmd-script "$@"
+test -x $path/git-$cmd && exec $path/git-$cmd "$@"
-alternatives=($(echo $PATH | tr ':' '\n' | while read i; do ls $i/git-*-script 2> /dev/null; done))
+echo "Usage: git COMMAND [OPTIONS] [TARGET]"
+if [ -n "$cmd" ]; then
+ echo " git command '$cmd' not found: commands are:"
+else
+ echo " git commands are:"
+fi
-echo Git command "'$cmd'" not found. Try one of
-for i in "${alternatives[@]}"; do
- echo $i | sed 's:^.*/git-: :' | sed 's:-script$::'
-done | sort | uniq
+alternatives=$(cd $path &&
+ ls git-*-script | sed -e 's/git-//' -e 's/-script//')
+echo $alternatives | fmt | sed 's/^/ /'
^ permalink raw reply
* Re: sending changesets from the middle of a git tree
From: Junio C Hamano @ 2005-08-14 7:57 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds
In-Reply-To: <Pine.LNX.4.58.0508132155100.3553@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
>> If I export those two changesets as patches, and send them on.
>> presumably I lose the changset comments etc.
>
> Well, you can export them with "git send-email" and you won't be losing
> any comments.
Yes, except the command is "git format-patch". Not just
comments, but "format-patch --author --date" generates messages
that would help preserving the authorship and original author
date information as well.
> Alternatively, use "git cherry", which helps re-order the commits in your
> tree. They'll be _new_ commits, but they'll have the contents moved over.
> Junio, maybe you want to talk about how you move patches from your "pu"
> branch to the real branches.
As I have mentioned elsewhere, I have been trying not to use
JIT, my own Porcelain, to make sure that the core-git barebone
Porcelain is usable.
Unfortunately, this is one area in my workflow that I still
heavily rely on JIT, because it is so handy. I've kept saying I
do not do Porcelain, but I'll make an exception this time, by
invitation ;-).
Let's say I have three commits in "pu" which are not yet in
"master". I first use "jit-cherry-snap" to give myself a ready
access to these them:
prompt$ jit-cherry-snap master pu
* 3: Alternate object pool mechanism updates.
* 4: Audit rev-parse users.
* 5: Add cheap local clone '-s' flag to git-clone-script
This command is a thin wrapper around "git cherry". Instead of
giving you long SHA1 commit object names, JIT gave a short name
to them, #3, #4, and #5 (I can say "git-rev-parse 3", or even
"git-diff-tree 3", for example). I have to mention that
x"alternate object pool" commit is the oldest (i.e. the one that
immediately follows the "master" head), #4 is its child, and #5
is #4's child.
Suppose I have tested the "pu" branch to my satisfaction, but
I would want to hold the commit #3 back (because I promised
Pasky to hold it for a couple of days). But I know #4 and #5
are good and would like to push them out. Here is what I do:
prompt$ git checkout master
prompt$ jit-replay 4 5
*** 4 ***
patching file git-rebase-script
patching file git-reset-script
patching file git-tag-script
*** 5 ***
patching file git-clone-script
prompt$
"jit-replay" is essentially this shell scriptlet:
#!/bin/sh
. git-sh-setup-script || die "not a git repository"
for snap
do
snap=$(git-rev-parse --verify "$snap") &&
git-diff-tree -p "$snap" | git-apply --index &&
git commit -C "$snap"
done
That is, to apply the change in an existing commit, and record
it with the commit log message, authorship information and
author timestamp from that commit. What I just did is to port
commits #4 and #5 on top of the "master" branch.
What happened so far is this:
* I used to have this commit graph. O is the original "master"
head, P is the original "pu" head.
O --> #3 --> #4 --> #5 == P
* I advanced the "master" branch, but not along the original
path that lead to "pu" head. Instead, I made a fork:
* New "master" head
--> #4'--> #5'
/
O --> #3 --> #4 --> #5 == P
As Linus and Ryan already said, the old history is "immutable".
I did not (actually, could not) touch #3...#5 commits; they are
still there. I created two new commit objects #4' and #5'. And
#5' is now the new "master" head.
What's left to do is to make sure that I do not lose the change
in #3. So I rebase the "pu" branch to the new "master" head.
The following sequence does it:
prompt$ git-rev-parse master >.git/refs/heads/pu
prompt$ git checkout pu
prompt$ jit-replay 3
*** 3 ***
patching file cache.h
patching file fsck-cache.c
patching file sha1_file.c
Now, the commit ancestry graph looks like this. "pu" head is at
P', and the original "pu" head P is still recorded as the
snapshot #5.
new "master"
*head *new "pu" head
--> #4'--> #5'--> #3 == P'
/
O --> #3 --> #4 --> #5 == P
As the last sanity check, I make sure that the resulting "pu"
head has exactly the same tree as the original "pu" head;
because all I did in this example was to shuffle the order of
commits, they should exactly match:
prompt$ git diff HEAD..5
prompt$
And they do match. I discard the numbered snapshots, because I
do not need them anymore.
prompt$ jit-clean
It is worth pointing out that this workflow means that "pu"
branch is just a staging area and if people start pulling from
and merging with it, things will get messy on the receiving end
(not my end), so the owner of a frequently rebased branch like
this should be very clear about the nature of the branch
upfront. Saying "this branch will be frequently rebased" is
equivalent of saying "comments and replacement patches are
welcome, but do not merge with it, or you may have hard time
yourself cleaning _your_ history up later".
As I said, I do not do Porcelain, and I would _not_ encourage
people to try JIT out at this point. Because I have not had
enough time to keep it up-to-date and make it take advantage of
the recent git-core improvements, some of the parts I did not
demonstrate above have still (or have acquired) rough edges that
I myself know not to touch, but others would by accident and
burn themselves. What I would eventually do is to take good
pieces and ideas out of JIT and repackage them as part of the
core-git barebone Porcelain.
^ permalink raw reply
* [PATCH] Add cheap local clone '-s' flag to git-clone-script
From: Junio C Hamano @ 2005-08-14 8:20 UTC (permalink / raw)
To: git
Using the $GIT_OBJECT_DIRECTORY/info/alternates mechanism,
create a new repository that borrows objects from the original
repository when --shared flag is given in addition to --local.
It is worth pointing out that the "cloned" repository depends on
the original repository, so this should be used only when you
can reasonably trust that the original repository would not
disappear without your knowing.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
This depends on the "Alternate object pool mechanism" patch I
sent out earlier, with a change suggested by Pasky to use
"$GIT_OBJECT_DIRECTORY/info/alternates" as the file name
instead of "info/alt".
This approach has the same danger as symlinking .git/objects
directory to the original repository that cg-clone mentions
about its '-l' option, but it is safer and easier to use in
multi-user environment. Objects newly created in the cloned
repository go to the primary object pool of it, not the
object pool of the original repository.
git-clone-script | 45 ++++++++++++++++++++++++++++-----------------
1 files changed, 28 insertions(+), 17 deletions(-)
ffdb36832dd755e65b9adfb68fa6b4a137176bc5
diff --git a/git-clone-script b/git-clone-script
--- a/git-clone-script
+++ b/git-clone-script
@@ -6,7 +6,7 @@
# Clone a repository into a different directory that does not yet exist.
usage() {
- echo >&2 "* git clone [-l] [-q] [-u <upload-pack>] <repo> <dir>"
+ echo >&2 "* git clone [-l [-s]] [-q] [-u <upload-pack>] <repo> <dir>"
exit 1
}
@@ -16,11 +16,14 @@ get_repo_base() {
quiet=
use_local=no
+local_shared=no
upload_pack=
while
case "$#,$1" in
0,*) break ;;
*,-l|*,--l|*,--lo|*,--loc|*,--loca|*,--local) use_local=yes ;;
+ *,-s|*,--s|*,--sh|*,--sha|*,--shar|*,--share|*,--shared)
+ local_shared=yes ;;
*,-q|*,--quiet) quiet=-q ;;
1,-u|1,--upload-pack) usage ;;
*,-u|*,--upload-pack)
@@ -57,22 +60,30 @@ yes,yes)
exit 1
}
- # See if we can hardlink and drop "l" if not.
- sample_file=$(cd "$repo" && \
- find objects -type f -print | sed -e 1q)
-
- # objects directory should not be empty since we are cloning!
- test -f "$repo/$sample_file" || exit
-
- l=
- if ln "$repo/$sample_file" "$D/.git/objects/sample" 2>/dev/null
- then
- l=l
- fi &&
- rm -f "$D/.git/objects/sample" &&
- cd "$repo" &&
- find objects -type f -print |
- cpio -puamd$l "$D/.git/" || exit 1
+ case "$local_shared" in
+ no)
+ # See if we can hardlink and drop "l" if not.
+ sample_file=$(cd "$repo" && \
+ find objects -type f -print | sed -e 1q)
+
+ # objects directory should not be empty since we are cloning!
+ test -f "$repo/$sample_file" || exit
+
+ l=
+ if ln "$repo/$sample_file" "$D/.git/objects/sample" 2>/dev/null
+ then
+ l=l
+ fi &&
+ rm -f "$D/.git/objects/sample" &&
+ cd "$repo" &&
+ find objects -type f -print |
+ cpio -puamd$l "$D/.git/" || exit 1
+ ;;
+ yes)
+ mkdir -p "$D/.git/objects/info"
+ echo "$repo/objects" >"$D/.git/objects/info/alternates"
+ ;;
+ esac
# Make a duplicate of refs and HEAD pointer
HEAD=
^ permalink raw reply
* Re: [ANNOUNCE] qgit-0.9
From: Martin Langhoff @ 2005-08-14 9:04 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <20050813121216.15512.qmail@web26305.mail.ukl.yahoo.com>
Marco,
How do I get this to build on Debian? Not familiar with scons, and it
is complaining that it can't find qt and related header files, when
they are there...
It's been mentioned on the list that v0.3 didn't build on Debian, but
I thought it had been dealt with. There were no fixes mentioned on the
thread.
cheers,
martin
^ permalink raw reply
* Re: sending changesets from the middle of a git tree
From: Petr Baudis @ 2005-08-14 9:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds
In-Reply-To: <7vhddtdk86.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sun, Aug 14, 2005 at 09:57:13AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> Linus Torvalds <torvalds@osdl.org> writes:
> > Alternatively, use "git cherry", which helps re-order the commits in your
> > tree. They'll be _new_ commits, but they'll have the contents moved over.
>
> > Junio, maybe you want to talk about how you move patches from your "pu"
> > branch to the real branches.
>
> As I have mentioned elsewhere, I have been trying not to use
> JIT, my own Porcelain, to make sure that the core-git barebone
> Porcelain is usable.
>
> Unfortunately, this is one area in my workflow that I still
> heavily rely on JIT, because it is so handy. I've kept saying I
> do not do Porcelain, but I'll make an exception this time, by
> invitation ;-).
Actually, wouldn't this be also precisely for what StGIT is intended to?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: git/cogito workshop/bof at linuxconf au?
From: Petr Baudis @ 2005-08-14 9:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Martin Langhoff, GIT, vojtech
In-Reply-To: <Pine.LNX.4.58.0508131625010.3553@g5.osdl.org>
Dear diary, on Sun, Aug 14, 2005 at 01:33:53AM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> told me that...
> On Sun, 14 Aug 2005, Martin Langhoff wrote:
> >
> > And how are things lining up for the upcoming one (January 2006, Dunedin, NZ)?
>
> Dunno yet. I have a policy of trying to travel with the whole family,
> which means I'll have to decide whether I'm willing to put that much money
> into it, or whether some poor unsuspecting company can help sponsor me ;)
> We'll see.
BTW, I've asked my unsuspecting company. I'll see too. ;-)
> > There's a lot of interest, but the barriers of entry are somewhat
> > high, with the codebase moving fast, and some of the concepts
> > requiring re-learning of what to expect from an SCM. Perhaps no so
> > much among kernel hackers, but the general populace is largely still
> > laden with cvs/svn and their mindset.
>
> Yeah. We do not have a nice paper explaining the concepts and usage. The
> tutorial isn't really in-depth enough (it doesn't even mention a lot of
> the helper scripts or even some of the core stuff). The old README started
> out explaining some of the concepts, but it's _way_ of out date in all
> usage respects.
>
> Pasky has the Overview thing, which gets pointed to by kernel.org, and
> which could be expanded upon a lot.
I wanted to offer a Git/Cogito tutorial session (Is that what is meant
by "workshop"? I'm no skilled conference traveller and the website
mentions no workshops.), but on a second thought paper might be better -
Cogito is supposed to be so simple to use that a tutorial wouldn't give
you much (except tutorial.txt since I would have a strong incentive to
write it), and Git concepts aren't tutorial material. So I might try to
apply with a paper giving some overview of the new wave of "modern"
version control systems, with a special focus on GIT design and core
interface. (I will probably skip the core GIT plumbing since I'm
naturally a bit sceptical about it. ;-)
I also imagined a BOF session for more interested people (if there would
be any), for discussing advanced topics, possible further development
directions (see also the Cogito TODO for also some Git-related stuff I
have on my mind but is not yet ready for mailing list bashing) etc.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: [RFC][PATCH] Rewriting revs in place in push target repository
From: Matthias Urlichs @ 2005-08-14 10:02 UTC (permalink / raw)
To: git
In-Reply-To: <20050814022011.GA19897@taniwha.stupidest.org>
Hi, Chris Wedgwood wrote:
> On Sat, Aug 13, 2005 at 11:47:25PM +0200, Petr Baudis wrote:
>
>> I think it does not in real setups, since thanks to O_RDWR the
>> file should be overwritten only when the write() happens.
>> Can a 41-byte write() be non-atomic in any real conditions?
>
> if you journal metadata only you can see a file extended w/o having
> the block flushed
??? but the file is *not* extended. Also, whether or not a block is
flushed should only matter if the machine crashes ..?
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
CONS [from LISP] 1. v. To add a new element to a list. 2. CONS UP:
v. To synthesize from smaller pieces: "to cons up an example".
-- From the AI Hackers' Dictionary
^ permalink raw reply
* Re: [ANNOUNCE] qgit-0.9
From: Ryan Anderson @ 2005-08-14 11:58 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Marco Costalba, git
In-Reply-To: <46a038f905081402049d317e5@mail.gmail.com>
On Sun, Aug 14, 2005 at 09:04:19PM +1200, Martin Langhoff wrote:
> Marco,
>
> How do I get this to build on Debian? Not familiar with scons, and it
> is complaining that it can't find qt and related header files, when
> they are there...
You just need to add -I/usr/include/qt3/ in the appropriate place in the
scons control file, IIRC.
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* ImO <Name>, we invite You to elite sites with 4 in 1 rOQ
From: John Elmond @ 2005-08-14 11:58 UTC (permalink / raw)
To: Git
In-Reply-To: <4CA8EAAAGE3J1F71@vger.kernel.org>
Hello Git,
At this time we can offer a small update at our system - BD-MAGAZINE Issue N1,2,3,4,5!
... When it's late at night , all ya really need is some midnight passion. See
a video few sweet young models show fashion for your passion within these pages.
Tanya, Marisha, Oksana and Alena.They have new video serries of beautiful Tanya...
http://tH8JgaxRDDp.leetempire.com/5/?1hj7aDU7
Our great and unique offer: for each subscribtion You get access to another
three sites from our portal for 31 days... without any additional payments!
Simply subscribe, select and use!
MSGID: f0iXIq2vagnTz5Qjk1QeFvEGLZMWCT4R
^ permalink raw reply
* (cogito) Branch offf from older commit?
From: Wolfgang Denk @ 2005-08-14 15:50 UTC (permalink / raw)
To: git
Is there (in cogito) a way to start a branch off from an older
commit?
Assume I receive a patch whichis based on an old version which I want
to test first (and resolve problems) in a separate branch.
This was what I tried:
* Clone main repo:
-> cg-clone /git/u-boot u-boot-testing
* Identify wanted branch point and seek to it:
-> cd u-boot-testing
-> cg-seek 024447b186cca55c2d803ab96b4c8f8674363b86
* Apply patch
Now how to proceed?
I can add new files created by the patch using "cg-add", but
cg-status says "Changes recording BLOCKED: seeked from master", and
cg-commit says "committing blocked: seeked from master", too.
However, when I now seek back I get this:
-> cg-seek
Warning: uncommitted local changes, trying to bring them along
which then results in a couple of conflicts which are probably to be
expected.
So I tried this (after throwing away and re-creating my cloned repo):
* Uncommit the commit following the one I want to keep:
-> cg-admin-uncommit 342717f72a2f92a14b9c823546e5bcec244f8bf4
-> cg-reset
* cg-status reports a couple of unknown files (those added later to
the tree); I manually removed these
* Apply patch
* Check in modifications
* Clone another tree
-> cg-clone /git/u-boot u-boot-test-merge
-> cd u-boot-test-merge
* Create branch for the stuff to be tested
-> cg-branch-add testing-NAND /work/u-boot-testing
* Pull and merge:
-> cg-pull testing-NAND
-> cg-merge testing-NAND
This works as intended, but seems to be a bit circuitous to me; I
think this is probably a pretty common situation and there might be a
simpler approach which I am missing?
[If possible I'd like to use cogito only, but if there is a clever
way to do this using git-core commands I'm interested, too.]
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
The price of curiosity is a terminal experience.
- Terry Pratchett, _The Dark Side of the Sun_
^ permalink raw reply
* Re: (cogito) Branch offf from older commit?
From: Linus Torvalds @ 2005-08-14 17:03 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: git
In-Reply-To: <20050814155005.6492A353BBF@atlas.denx.de>
On Sun, 14 Aug 2005, Wolfgang Denk wrote:
>
> Is there (in cogito) a way to start a branch off from an older
> commit?
You should be able to just use the git commands, and cogito should be
perfectly happy.
IOW, if you do
git checkout -b newbranch <starting-point-sha1>
you'll switch to a "newbranch" that was created at the starting point, and
as far as I can tell, this is all very cogito-friendly indeed. So now you
can work in that "newbranch" - commit things, do anything you want, and
all with cogito (ie it's only this one raw git command you need to set
things up, after that you're back in cogito-land).
You can switch back with "git checkout master" (again, I don't think
cogito does the local git branches yet, but once you've switched back
you're golden), and if you're in the "master" branch, you can merge with
your new-branch with
git resolve master newbranch "Merge my work on xyz"
or similar.
And always remember "gitk --all", since that's a very useful thing to
visualize where you are.
> -> cg-seek 024447b186cca55c2d803ab96b4c8f8674363b86
No, cg-seek doesn't start a new branch, so the result is "locked". You
can't commit on top of the seek-point, because the branch you are in
already _has_ a child of that point.
(Actually, these days cg-seek does use a fixed local git branch for the
seek target, so that's not _technically_ true any more. I suspect Pasky is
working on exposing the general local branch interfaces)
Linus
^ permalink raw reply
* Re: [PATCH] Alternate object pool mechanism updates.
From: Junio C Hamano @ 2005-08-14 23:46 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050813120815.GC5608@pasky.ji.cz>
Petr Baudis <pasky@suse.cz> writes:
> What about calling it rather info/alternates (or info/alternate)? It
> looks better, sounds better, is more namespace-ecological tab-completes
> fine and you don't type it that often anyway. :-)
Ok, so the one in the proposed updates branch says
info/alternates.
With this, your recent cg-clone -l can be made to still use
individual .git/object/??/ hierarchy to keep objects newly
created in each repository while sharing the inherited objects
from the parent repository, which would probably alleviate the
multi-user environment worries you express in the comments for
the option. The git-clone-script in the proposed updates branch
has such a change.
^ permalink raw reply
* Switching heads and head vs branch after CVS import
From: Martin Langhoff @ 2005-08-15 0:24 UTC (permalink / raw)
To: GIT
After having done a cvs import of Moodle using git-cvsimport-script
all the cvs branches show up as heads. How do I switch heads within a
checkout? cogito doesn't seem to be able to, and I'm unsure on how to
do it with git.
And I am confused about the difference between heads and branches. Git
and cogito seem prepared to merge across the heads (using cg-update
for instance, when pointed to a different head merged it in, rather
than switched to it), that would match a workflow where a group of
people maintain very closely related heads and merge constantly
across.
Branches don't seem to have the same expectation or support in the
toolset. Why? What makes a branch different from a head, apart from
the fact that they would be expected to drift further apart?
In any case, should the cvsimport turn cvs branches into git branches
instead of heads? Is there are way to turn a head into a proper
branch?
cheers,
martin
^ permalink raw reply
* Re: [PATCH] Alternate object pool mechanism updates.
From: Linus Torvalds @ 2005-08-15 0:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7v1x4wcca0.fsf@assigned-by-dhcp.cox.net>
On Sun, 14 Aug 2005, Junio C Hamano wrote:
>
> Ok, so the one in the proposed updates branch says
> info/alternates.
>
> With this, your recent cg-clone -l can be made to still use
> individual .git/object/??/ hierarchy to keep objects newly
> created in each repository while sharing the inherited objects
> from the parent repository, which would probably alleviate the
> multi-user environment worries you express in the comments for
> the option. The git-clone-script in the proposed updates branch
> has such a change.
I think this is great - especially for places like kernel.org, where a lot
of repos end up being related to each other, yet independent.
However, exactly for places like kernel.org it would _also_ be nice if
there was some way to prune objects that have been merged back into the
parent. In other words, imagine that people start using my kernel tree as
their source of "alternate" objects, which works wonderfully well, but
then as I pull from them, nothing ever removes the objects that are now
duplicate.
We've got a "git prune-packed", it would be good to have a "git
prune-alternate" or something equivalent.
Linus
^ permalink raw reply
* Re: Switching heads and head vs branch after CVS import
From: Junio C Hamano @ 2005-08-15 0:40 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f905081417241f9598cc@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> writes:
> After having done a cvs import of Moodle using git-cvsimport-script
> all the cvs branches show up as heads. How do I switch heads within a
> checkout? cogito doesn't seem to be able to, and I'm unsure on how to
> do it with git.
The documentation may be quite sketchy on this front.
I do not speak for Pasky, so Cogito may treat them a little
differently, but at the core GIT level, you can treat branches
and heads synonymously.
What you have recorded in .git/refs/heads/frotz file is the SHA1
object name of the commit that is at the top of "frotz" branch.
When your .git/HEAD symlink points at refs/heads/nitfol, your
working tree is said to be on "nitfol" branch.
You switch branches by using "git checkout". You can create a
new branch using "git checkout -b newbranch commit-id". You
examine which branch you are on by "readlink .git/HEAD". As you
already found out, you can merge branches with "git resolve
master other-branch 'comment'". The last one is briefly covered
by the tutorial.
^ permalink raw reply
* Re: Switching heads and head vs branch after CVS import
From: Linus Torvalds @ 2005-08-15 0:46 UTC (permalink / raw)
To: Martin Langhoff; +Cc: GIT
In-Reply-To: <46a038f905081417241f9598cc@mail.gmail.com>
On Mon, 15 Aug 2005, Martin Langhoff wrote:
>
> After having done a cvs import of Moodle using git-cvsimport-script
> all the cvs branches show up as heads. How do I switch heads within a
> checkout? cogito doesn't seem to be able to, and I'm unsure on how to
> do it with git.
Just do
git checkout branch-name
to switch between them.
One thing that "git cvsimport" does not know to do is to show when a
branch was merged back into the HEAD. That would be a very interesting
thing to see, but I don't think there's any way to get that information
out of CVS (so you'd have to basically make an educated guess by looking
at the changes).
So in a cvsimport, you'll never see a merge back to the head, even if one
technically took place.
> And I am confused about the difference between heads and branches.
Confusion of naming.
branches and heads are the same thing in git. However, largely due to
historical reasons, I encouraged "one tree pre branch", and then you had
"external branches" which were totally separate repositories.
Now, we're stuck with both the "internal branches" (heads) and "external
branches" (other repositories) _both_ being confusingly called "branch",
and then to make it more confusing, sometimes you'll see people say
"head" to make clear that it's a branch internal to one repo.
> In any case, should the cvsimport turn cvs branches into git branches
> instead of heads? Is there are way to turn a head into a proper
> branch?
They are "proper branches", and sorry about the confusion. A head is a
branch.
Linus
^ permalink raw reply
* Re: sending changesets from the middle of a git tree
From: Junio C Hamano @ 2005-08-15 1:37 UTC (permalink / raw)
To: git; +Cc: Petr Baudis, Linus Torvalds
In-Reply-To: <20050814092757.GP5608@pasky.ji.cz>
Petr Baudis <pasky@suse.cz> writes:
> Dear diary, on Sun, Aug 14, 2005 at 09:57:13AM CEST, I got a letter
> where Junio C Hamano <junkio@cox.net> told me that...
>> Linus Torvalds <torvalds@osdl.org> writes:
>>
>> > Junio, maybe you want to talk about how you move patches from your "pu"
>> > branch to the real branches.
>>
> Actually, wouldn't this be also precisely for what StGIT is intended to?
Exactly my feeling. I was sort of waiting for Catalin to speak
up. With its basing philosophical ancestry on quilt, this is
the kind of task StGIT is designed to do.
I just have done a simpler one, this time using only the core
GIT tools.
I had a handful commits that were ahead of master in pu, and I
wanted to add some documentation bypassing my usual habit of
placing new things in pu first. At the beginning, the commit
ancestry graph looked like this:
*"pu" head
master --> #1 --> #2 --> #3
So I started from master, made a bunch of edits, and committed:
$ git checkout master
$ cd Documentation; ed git.txt git-apply-patch-script.txt ...
$ cd ..; git add Documentation/*.txt
$ git commit -s -v
NOTE. The -v flag to commit is a handy way to make sure that
your additions are not introducing bogusly formatted lines.
After the commit, the ancestry graph would look like this:
*"pu" head
master^ --> #1 --> #2 --> #3
\
\---> master
The old master is now master^ (the first parent of the master).
The new master commit holds my documentation updates.
Now I have to deal with "pu" branch.
This is the kind of situation I used to have all the time when
Linus was the maintainer and I was a contributor, when you look
at "master" branch being the "maintainer" branch, and "pu"
branch being the "contributor" branch. Your work started at the
tip of the "maintainer" branch some time ago, you made a lot of
progress in the meantime, and now the maintainer branch has some
other commits you do not have yet. And "git rebase" was written
with the explicit purpose of helping to maintain branches like
"pu". You _could_ merge master to pu and keep going, but if you
eventually want to cherrypick and merge some but not necessarily
all changes back to the master branch, it often makes later
operations for _you_ easier if you rebase (i.e. carry forward
your changes) "pu" rather than merge. So I ran "git rebase":
$ git checkout pu
$ git rebase master pu
What this does is to pick all the commits since the current
branch (note that I now am on "pu" branch) forked from the
master branch, and forward port these changes.
master^ --> #1 --> #2 --> #3
\ *"pu" head
\---> master --> #1' --> #2' --> #3'
The diff between master^ and #1 is applied to master and
committed to create #1' commit with the commit information (log,
author and date) taken from commit #1. On top of that #2' and #3'
commits are made similarly out of #2 and #3 commits.
Old #3 is not recorded in any of the .git/refs/heads/ file
anymore, so after doing this you will have dangling commit if
you ran fsck-cache, which is normal. After testing "pu", you
can run "git prune" to get rid of those original three commits.
While I am talking about "git rebase", I should talk about how
to do cherrypicking using only the core GIT tools.
Let's go back to the earlier picture, with different labels.
You, as an individual developer, cloned upstream repository and
amde a couple of commits on top of it.
*your "master" head
upstream --> #1 --> #2 --> #3
You would want changes #2 and #3 incorporated in the upstream,
while you feel that #1 may need further improvements. So you
prepare #2 and #3 for e-mail submission.
$ git format-patch master^^ master
This creates two files, 0001-XXXX.txt and 0002-XXXX.txt. Send
them out "To: " your project maintainer and "Cc: " your mailing
list. You could use contributed script git-send-email-script if
your host has necessary perl modules for this, but your usual
MUA would do as long as it does not corrupt whitespaces in the
patch.
Then you would wait, and you find out that the upstream picked
up your changes, along with other changes.
where *your "master" head
upstream --> #1 --> #2 --> #3
used \
to be \--> #A --> #2' --> #3' --> #B --> #C
*upstream head
The two commits #2' and #3' in the above picture record the same
changes your e-mail submission for #2 and #3 contained, but
probably with the new sign-off line added by the upsteam
maintainer and definitely with different committer and ancestry
information, they are different objects from #2 and #3 commits.
You fetch from upstream, but not merge.
$ git fetch upstream
This leaves the updated upstream head in .git/FETCH_HEAD but
does not touch your .git/HEAD nor .git/refs/heads/master.
You run "git rebase" now.
$ git rebase FETCH_HEAD master
Earlier, I said that rebase applies all the commits from your
branch on top of the upstream head. Well, I lied. "git rebase"
is a bit smarter than that and notices that #2 and #3 need not
be applied, so it only applies #1. The commit ancestry graph
becomes something like this:
where *your old "master" head
upstream --> #1 --> #2 --> #3
used \ your new "master" head*
to be \--> #A --> #2' --> #3' --> #B --> #C --> #1'
*upstream
head
Again, "git prune" would discard the disused commits #1-#3 and
you continue on starting from the new "master" head, which is
the #1' commit.
-jc
^ permalink raw reply
* Re: [PATCH] Alternate object pool mechanism updates.
From: Junio C Hamano @ 2005-08-15 1:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, git
In-Reply-To: <Pine.LNX.4.58.0508141726390.3553@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> I think this is great - especially for places like kernel.org, where a lot
> of repos end up being related to each other, yet independent.
Yes. There is one shortcoming in the current git-clone -s in
the proposed updates branch. If the parent repository has
alternates on its own, that information should be copied to the
cloned one as well (e.g. Jeff has alternates pointing at you,
and I clone from Jeff with -s flag --- I should list not just
Jeff but also you to borrow from in my alternates file).
> However, exactly for places like kernel.org it would _also_ be nice if
> there was some way to prune objects that have been merged back into the
> parent.
Yes. Another possibility is to use git-relink which was written
exactly to solve this in a different way.
^ permalink raw reply
* Re: Switching heads and head vs branch after CVS import
From: Martin Langhoff @ 2005-08-15 2:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: GIT
In-Reply-To: <Pine.LNX.4.58.0508141737270.3553@g5.osdl.org>
> Just do
>
> git checkout branch-name
>
> to switch between them.
thanks! I was doing cg-branch-chg branch-name and it wasn't working.
> So in a cvsimport, you'll never see a merge back to the head, even if one
> technically took place.
There may be some surprises in here! gitk --all shows at least one
branch opening and merging back into origin, and it has figured it out
correctly: that was a feature branch where people worked on for a
while and merged back. I haven't had time to explore it more, but it
looks promising.
Except for the keyword expansion. surely there's a way to tell cvsps
to not do it. Why would we ever want it?
> > And I am confused about the difference between heads and branches.
>
> Confusion of naming.
>
> branches and heads are the same thing in git.
right. There are two separate directories in .git for them, so I was
misled by that. Should I assume git is safe from name clashes or is it
up to porcelain to deal with such minutiae?
> They are "proper branches", and sorry about the confusion.
Don't worry! Means I'll have to wake up and pay attention from now on...
thanks,
martin
^ permalink raw reply
* symlinked directories in refs are now unreachable
From: Matt Draisey @ 2005-08-15 2:41 UTC (permalink / raw)
To: git-list
The behaviour of the symlinked in ref directories has changed from
earlier versions of git. They used to be taken into account in
git-fsck-cache --unreachable. The code in question would simply stat
the contents of .git/refs and recursively expand any S_ISDIR. Now the
code does an lstat and effectively throws symlinks away.
refs.c lines 48,52 @ do_for_each_ref
...
memcpy(path + baselen, de->d_name, namelen+1);
if (lstat(git_path("%s", path), &st) < 0)
continue;
if (S_ISDIR(st.st_mode)) {
retval = do_for_each_ref(path, fn);
...
Can the previous behaviour be reinstated?
^ permalink raw reply
* Re: Switching heads and head vs branch after CVS import
From: Linus Torvalds @ 2005-08-15 2:49 UTC (permalink / raw)
To: Martin Langhoff; +Cc: GIT, Sven Verdoolaege
In-Reply-To: <46a038f905081419057cc6b5cd@mail.gmail.com>
On Mon, 15 Aug 2005, Martin Langhoff wrote:
>
> > So in a cvsimport, you'll never see a merge back to the head, even if one
> > technically took place.
>
> There may be some surprises in here! gitk --all shows at least one
> branch opening and merging back into origin, and it has figured it out
> correctly
Oh, wow. The new cvsimport is obviously being a hell of a lot smarter than
my original one was. Goodie.
> Except for the keyword expansion. surely there's a way to tell cvsps
> to not do it. Why would we ever want it?
Ahh. I don't think we should blame cvsps, I think cvsimport should use the
"-ko" flag to disable keyword expansion or whatever the magic flag is.
Sven, Matthias, opinions? I've never used CVS keyword expansion, and
always felt it was pointless, but hey..
> > branches and heads are the same thing in git.
>
> right. There are two separate directories in .git for them, so I was
> misled by that. Should I assume git is safe from name clashes or is it
> up to porcelain to deal with such minutiae?
Well, you actually are _expected_ to get clashes.
What happens normally (at least for core git) is that the ".git/branches"
directory contains external sources for the branches (for example, a "git
clone" will fill in the "origin" source, while I often have a
".git/branches/parent" in my tree because). That is just a pointer to
where the external branch exists.
Then, when you do something like
git fetch parent
it will look up the source of "parent" by looking in the
".git/branches/parent" file, and update the ".git/refs/heads/parent"
branch appropriately from that external branch.
So in this example the parent "head" ("local branch") points to the actual
_commit_ we have, while the ".git/branches/parent thing points to what
_external_ branch it came from.
But yes, you _can_ mess this up if you want to. If you have the same
"external branch" name that you use for an "internal branch", you deserve
all the confusion you get ;)
Linus
^ permalink raw reply
* Re: symlinked directories in refs are now unreachable
From: Linus Torvalds @ 2005-08-15 3:12 UTC (permalink / raw)
To: Matt Draisey; +Cc: git-list
In-Reply-To: <1124073677.27393.15.camel@della.draisey.ca>
On Mon, 15 Aug 2005, Matt Draisey wrote:
>
> The behaviour of the symlinked in ref directories has changed from
> earlier versions of git.
Hmm.. There used to be a mix of lstat() (in receive-pack) and stat() (in
fsck-cache.c, and it got standardized in one function which used lstat.
The reason for the lstat is really to try to avoid having especially the
remote protocols follow symlinks, but I guess it's not a very good reason,
so I don't think it would be wrong to just standardize refs.c to use
"stat()" instead.
You might sent a patch to Junio..
HOWEVER: symlinks for references really are pretty dangerous. We do things
like "echo new-id > .git/HEAD" and links (symlinks _or_ hardlinks) thus
really aren't safe. You're much better off copying those small files.
Linus
^ permalink raw reply
* Git 1.0 Synopis (Draft v4)
From: Ryan Anderson @ 2005-08-15 4:55 UTC (permalink / raw)
To: Horst von Brand; +Cc: git, Junio C Hamano
In-Reply-To: <200507312215.j6VMFeqn030963@laptop11.inf.utfsm.cl>
On Sun, Jul 31, 2005 at 06:15:40PM -0400, Horst von Brand wrote:
> Ryan Anderson <ryan@michonline.com> wrote:
> > Source Code Management with Git
>
> More bugging...
Ok, I think I've got all this addressed (plus the other email).
It just took me a lot longer to get to it than I planned.
Junio, do you want to pull this into the git tree? (I'll reply with a
patch)
==========
Source Code Management with git
In Linus's own words as the creator of git:
"git" can mean anything, depending on your mood.
- random three-letter combination that is pronounceable, and not
actually used by any common UNIX command. The fact that it is a
mispronunciation of "get" may or may not be relevant.
- stupid. contemptible and despicable. simple. Take your pick from the
dictionary of slang.
- "global information tracker": you're in a good mood, and it actually
works for you. Angels sing, and a light suddenly fills the room.
- "goddamn idiotic truckload of sh*t": when it breaks
git is a "directory content manager". git has been designed to handle
absolutely massive projects with speed and efficiency, and the release of the
2.6.12 and (soon) the 2.6.13 version of the Linux kernel would indicate that it
does this task well.
git falls into the category of distributed source code management tools,
similar to Arch or Darcs (or, in the commercial world, BitKeeper). Every git
working directory is a full-fledged repository with full revision tracking
capabilities, not dependent on network access to a central server.
git provides a content-addressable pseudo filesystem, complete with its own
version of fsck.
o Speed of use, both for the project maintainer, and the end-users, is
a key development principle.
o The history is stored as a directed acyclic graph, making long-lived
branches and repeated merging simple.
o The core git project considers itself to provide "plumbing" for other
projects, as well as to serve to arbitrate for compatibility between them.
The project built on top of the core git are referred to as "porcelain".
Stgit, Cogito, qgit, gitk and gitweb are all building upon the core git
tools, and providing an easy to use interface to various pieces of
functionality.
o Some other projects have taken the concepts from the core git project, and
are either porting an existing toolset to use the git tools, or
reimplementing the concepts internally, to benefit from the performance
improvements. This includes both Arch 2.0, and Darcs-git.
o Two, interchangeable, on-disk formats are used:
o An efficient, packed format that saves space and network
bandwidth.
o An unpacked format, optimized for fast writes and incremental
work.
To get a copy of git:
Daily snapshots are available at:
http://www.codemonkey.org.uk/projects/git-snapshots/git/
(Thanks to Dave Jones)
Source tarballs and RPMs at:
http://www.kernel.org/pub/software/scm/git/
Debian packages should be availabe in unstable (sid) as "git-core"
Or via git itself:
git clone http://www.kernel.org/pub/scm/git/git.git/ <local directory>
git clone rsync://rsync.kernel.org/pub/scm/git/git.git/ <local directory>
(rsync is generally faster for an initial clone, you can switch later
by editing .git/branches/origin and changing the url)
To get the 'Porcelain' tools mentioned above:
SCM Interface layers:
cogito - http://www.kernel.org/pub/software/scm/cogito/
Patch Management (similar to Quilt):
StGIT - http://www.procode.org/stgit/
History Visualization:
gitk - http://ozlabs.org/~paulus/gitk/ (Included in the standard git
distribution)
gitweb - http://www.kernel.org/pub/software/scm/gitweb/
qgit - http://sourceforge.net/projects/qgit
git distributions contain a tutorial in the Documentation subdirectory.
Additionally, the Kernel-Hacker's git Tutorial at
http://linux.yyz.us/git-howto.html may be useful. (Thanks to Jeff Garzik for
that document)
git development takes place on the git mailing list. To subscribe, send an
email with just "subscribe git" in the body to majordomo@vger.kernel.org.
Mailing list archives are available at http://marc.theaimsgroup.com/?l=git
(This summary written by Ryan Anderson <ryan@michonline.com>. Please bug him
with any corrections or complaints.)
--
Ryan Anderson
sometimes Pug Majere
^ 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