* Re: 'git commit' duplicates parents?
From: Linus Torvalds @ 2005-06-20 15:11 UTC (permalink / raw)
To: Dan Holmsand; +Cc: Git Mailing List
In-Reply-To: <42B690EA.2080605@gmail.com>
On Mon, 20 Jun 2005, Dan Holmsand wrote:
>
> git-resolve-script still seems a bit too eager to write MERGE_HEAD and
> ORIG_HEAD - they only make sense if there's actually been any merging
> done, don't they?
>
> Patch below shows what I mean.
I considered this, but decided that MERGE_HEAD is potentially very useful
for some of the other failure exits. There's a few "exit 1"'s in there,
for example when the "git-read-tree -m" fails because of a dirty
workspace.
Of course, you can always re-do the merge completely (and maybe that's
what people end up doing), but at least in theory you can fix it up and
just re-resolve. But in order to do that, you need to know what the
MERGE_HEAD was...
So I'm not sure what the right answer is, which is why my fix was the
minimally invasive one that only removes the heads on success..
Linus
^ permalink raw reply
* How did this odd merge happen?
From: Wayne Scott @ 2005-06-20 15:09 UTC (permalink / raw)
To: git
$ git-cat-file commit 13e652800d1644dfedcd0d59ac95ef0beb7f3165
tree 6cdd9771bd9a56de1b0246a330ccd916ecdb1d41
parent 4332bdd332a2dca93dc3b1d017b2dd27d5c8cef3
parent 88d7bd8cb9eb8d64bf7997600b0d64f7834047c5
parent 88d7bd8cb9eb8d64bf7997600b0d64f7834047c5
author David Woodhouse <dwmw2@shinybook.infradead.org> 1115555034 +0100
committer David Woodhouse <dwmw2@shinybook.infradead.org> 1115555034 +0100
Merge with master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
-Wayne
^ permalink raw reply
* Re: git merging
From: Linus Torvalds @ 2005-06-20 15:58 UTC (permalink / raw)
To: Jens Axboe, Daniel Barkalow; +Cc: Jeff Garzik, Git Mailing List
In-Reply-To: <20050620123053.GI15021@suse.de>
[ Daniel put on the To: list to see if he can confirm or deny my theory ]
On Mon, 20 Jun 2005, Jens Axboe wrote:
>
> axboe@nelson:[.]l/git/linux-2.6-block.git $ git prune
> error: cannot map sha1 file c39ae07f393806ccf406ef966e9a15afc43cc36a
That's the 2.6.11 "tree" object.
> bad sha1 entry '5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c'
> axboe@nelson:[.]l/git/linux-2.6-block.git $ git-fsck-cache
> error: cannot map sha1 file c39ae07f393806ccf406ef966e9a15afc43cc36a
> bad object in tag 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c
> bad sha1 entry '5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c'
>
> Running git prune again gives me the same output. What is wrong?
Very interesting. You have my "v2.6.11-tree" tag file pointing the 2.6.11
tree object, but you seem to not have that 2.6.11 tree itself.
Actually, judging from the fact that you got this error _during_ the
prune, maybe you never had it in that repository in the first place?
In particular, if you don't use "rsync", but instead use one of the
"optimized pull" things to create a repository (ie git-http-pull or
git-ssh-pull), I think your newly pulled tree will always miss anything
that isn't a head. And the 2.6.11 tree is a special case: it's a pure
"tree" object without any commit at all pointing to it, just a single tag
that points directly to the tree.
Anyway, the fact that you're missing the original 2.6.11 tree doesn't
really matter, so it's not a huge deal per se. You can re-populate it with
an "rsync -avz --ignore-existing", but clearly something seems to be
wrong.
Daniel: I think git-ssh-pull has problems with any refs that aren't
commits. I also noticed earlier that I can't use git-ssh-push -w to write
a tag - it is apparently unhappy because it would write a "tag" object,
and it only wants to write references to "commit" objects. The same thing
might be true about the special "tag to a tree" object?
Jeff, do you remember (did you check?) if your prune problems might also
have been about the tag to a tree?
Linus
^ permalink raw reply
* Re: git merging
From: Daniel Barkalow @ 2005-06-20 16:06 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jens Axboe, Jeff Garzik, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0506200844420.2268@ppc970.osdl.org>
On Mon, 20 Jun 2005, Linus Torvalds wrote:
> Daniel: I think git-ssh-pull has problems with any refs that aren't
> commits. I also noticed earlier that I can't use git-ssh-push -w to write
> a tag - it is apparently unhappy because it would write a "tag" object,
> and it only wants to write references to "commit" objects. The same thing
> might be true about the special "tag to a tree" object?
You're correct; it's actually that pull.c has never gotten extended to
look at the object you specify, determine what it is, and then behave
appropriately. Basically, it needs a "process_unknown()" which does the
appropriate thing, and pull() needs to call that instead of
process_commit(). It should also get a "process_tag()" which handles tags
(calling process_unknown() on their objects). I should be able to do it
Tuesday evening or Wednesday night, if nobody else gets it before then.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Patch (apply) vs. Pull
From: Darrin Thompson @ 2005-06-20 16:19 UTC (permalink / raw)
To: git
In trying to understand git I've adopted a mental model where everybody
duplicates locally the remote history in which they are interested.
These histories have various points in common, allowing for intelligent
merging. That makes perfect sense to me, until I look at the list
archives filled with patches.
How exactly are these patches being generated? Is there a right-way(tm)
which causes the recipient's a later pullers' histories to be
intelligently handled in the future?
TIA.
--
Darrin
^ permalink raw reply
* Re: 'git commit' duplicates parents?
From: Dan Holmsand @ 2005-06-20 17:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0506200808090.2268@ppc970.osdl.org>
Linus Torvalds wrote:
>
> On Mon, 20 Jun 2005, Dan Holmsand wrote:
>
>>git-resolve-script still seems a bit too eager to write MERGE_HEAD and
>>ORIG_HEAD - they only make sense if there's actually been any merging
>>done, don't they?
>>
>>Patch below shows what I mean.
>
>
> I considered this, but decided that MERGE_HEAD is potentially very useful
> for some of the other failure exits. There's a few "exit 1"'s in there,
> for example when the "git-read-tree -m" fails because of a dirty
> workspace.
Yeah, but that was exactly what I was after...
As far as I understand it, the git-read-tree -u -m doesn't actually do
anything when the workspace is dirty - so there's actually no merging
going on, right?
If you react to the dirty-workspace-warnings in such a failed merge by
"git commit-ing" (and not noting the MERGE_HEAD warning, which has been
known to happen), you'll end up with an unwanted parent in the commit.
Or am I just being stupid :-?
/dan
^ permalink raw reply
* Re: Patch (apply) vs. Pull
From: Junio C Hamano @ 2005-06-20 17:22 UTC (permalink / raw)
To: Darrin Thompson; +Cc: git
In-Reply-To: <1119284365.3926.15.camel@localhost.localdomain>
>>>>> "DT" == Darrin Thompson <darrint@progeny.com> writes:
DT> How exactly are these patches being generated? Is there a right-way(tm)
DT> which causes the recipient's a later pullers' histories to be
DT> intelligently handled in the future?
Those patches are, as far as GIT is concerned, out of band
communications. You could still merge the result if the patch
was picked up by more than one tree independently, but the
behaviour is a bit less than ideal. Usually the merge ends up
to be still manageable.
FYI, here is what I have been doing:
(1) Start from Linus HEAD.
(2) Repeat develop-and-commit cycle.
(3) Run "git format-patch" (not in Linus tree) to generate
patches.
(4) Send them out and wait to see which one sticks.
(5) Pull from Linus.
(6) Throw away my HEAD, making Linus HEAD my HEAD, while
preserving changes I have made since I forked from him. I
use "jit-rewind" for this.
(7) Examine patches that Linus rejected, and apply ones that I
still consider good, making one commit per patch. I use
"jit-patch" and "jit-commit -m" for this.
(8) Go back to step 2.
^ permalink raw reply
* Re: 'git commit' duplicates parents?
From: Linus Torvalds @ 2005-06-20 17:44 UTC (permalink / raw)
To: Dan Holmsand; +Cc: Git Mailing List
In-Reply-To: <42B6FAE5.6060904@gmail.com>
On Mon, 20 Jun 2005, Dan Holmsand wrote:
>
> Yeah, but that was exactly what I was after...
>
> As far as I understand it, the git-read-tree -u -m doesn't actually do
> anything when the workspace is dirty - so there's actually no merging
> going on, right?
No, but you can trivially do so by hand afterwards.
For example, git-read-tree -u -m will complain and say "file xyz is
dirty, cannot merge" (or something), and what you might decide to do is
just
git-checkout-cache -f -u xyz
git resolve $(cat .git/HEAD) $(cat .git/MERGE_HEAD) "..."
and note how you needed to know what the merge head was in order to do
this.
[ Side note: I should make "git-resolve-script" run "git-rev-parse" on its
arguments, so that it would expand HEAD and MERGE_HEAD on its own. Maybe
somebody who is interested in this script might want to do that? Hint
hint. ]
Note how we could make both of us happy by saving that temporary
MERGE_HEAD information somewhere _else_ instead. Maybe the answer is to
only use "MERGE_HEAD" for the "merge manually" case, and use something
else for the "this was the merge you tried to do last" case?
Linus
^ permalink raw reply
* Re: 'git commit' duplicates parents?
From: Dan Holmsand @ 2005-06-20 18:52 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0506201040140.2268@ppc970.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 1026 bytes --]
Linus Torvalds wrote:
>
> [ Side note: I should make "git-resolve-script" run "git-rev-parse" on its
> arguments, so that it would expand HEAD and MERGE_HEAD on its own. Maybe
> somebody who is interested in this script might want to do that? Hint
> hint. ]
Got it. Included below.
> Note how we could make both of us happy by saving that temporary
> MERGE_HEAD information somewhere _else_ instead. Maybe the answer is to
> only use "MERGE_HEAD" for the "merge manually" case, and use something
> else for the "this was the merge you tried to do last" case?
I like the "everybody happy" idea...
How about "LAST_MERGE"? And something like this?
/dan
---
[PATCH] git-resolve-script: Add LAST_MERGE and use git-rev-parse
Make git-resolve-script only write MERGE_HEAD if a merge actually
occurred. All merge failures leave ORIG_HEAD and LAST_MERGE
behind (instead of ORIG_HEAD and MERGE_HEAD).
Use git-rev-parse to expand arguments (and check for bad ones).
Signed-off-by: Dan Holmsand <holmsand@gmail.com>
[-- Attachment #2: git-resolve-script.patch2.txt --]
[-- Type: text/plain, Size: 2096 bytes --]
diff --git a/git-resolve-script b/git-resolve-script
--- a/git-resolve-script
+++ b/git-resolve-script
@@ -4,26 +4,31 @@
#
# Resolve two trees.
#
-head="$1"
-merge="$2"
+head=$(git-rev-parse --revs-only "$1")
+merge=$(git-rev-parse --revs-only "$2")
merge_repo="$3"
: ${GIT_DIR=.git}
: ${GIT_OBJECT_DIRECTORY="${SHA1_FILE_DIRECTORY-"$GIT_DIR/objects"}"}
-rm -f "$GIT_DIR"/MERGE_HEAD "$GIT_DIR"/ORIG_HEAD
-echo $head > "$GIT_DIR"/ORIG_HEAD
-echo $merge > "$GIT_DIR"/MERGE_HEAD
+dropheads() {
+ rm -f -- "$GIT_DIR/ORIG_HEAD" "$GIT_DIR/MERGE_HEAD" \
+ "$GIT_DIR/LAST_MERGE" || exit 1
+}
#
# The remote name is just used for the message,
# but we do want it.
#
-if [ "$merge_repo" == "" ]; then
+if [ -z "$head" -o -z "$merge" -o -z "$merge_repo" ]; then
echo "git-resolve-script <head> <remote> <merge-repo-name>"
exit 1
fi
+dropheads
+echo $head > "$GIT_DIR"/ORIG_HEAD
+echo $merge > "$GIT_DIR"/LAST_MERGE
+
common=$(git-merge-base $head $merge)
if [ -z "$common" ]; then
echo "Unable to find common commit between" $merge $head
@@ -32,7 +37,7 @@ fi
if [ "$common" == "$merge" ]; then
echo "Already up-to-date. Yeeah!"
- rm -f -- "$GIT_DIR/ORIG_HEAD" "$GIT_DIR/MERGE_HEAD"
+ dropheads
exit 0
fi
if [ "$common" == "$head" ]; then
@@ -40,7 +45,7 @@ if [ "$common" == "$head" ]; then
git-read-tree -u -m $head $merge || exit 1
echo $merge > "$GIT_DIR"/HEAD
git-diff-tree -p ORIG_HEAD HEAD | git-apply --stat
- rm -f -- "$GIT_DIR/ORIG_HEAD" "$GIT_DIR/MERGE_HEAD"
+ dropheads
exit 0
fi
echo "Trying to merge $merge into $head"
@@ -51,6 +56,7 @@ if [ $? -ne 0 ]; then
echo "Simple merge failed, trying Automatic merge"
git-merge-cache -o git-merge-one-file-script -a
if [ $? -ne 0 ]; then
+ echo $merge > "$GIT_DIR"/MERGE_HEAD
echo "Automatic merge failed, fix up by hand"
exit 1
fi
@@ -60,4 +66,4 @@ result_commit=$(echo "$merge_msg" | git-
echo "Committed merge $result_commit"
echo $result_commit > "$GIT_DIR"/HEAD
git-diff-tree -p $head $result_commit | git-apply --stat
-rm -f -- "$GIT_DIR/ORIG_HEAD" "$GIT_DIR/MERGE_HEAD"
+dropheads
^ permalink raw reply
* Re: git merging
From: Matthias Urlichs @ 2005-06-20 19:21 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.21.0506201156360.30848-100000@iabervon.org>
Hi, Daniel Barkalow wrote:
> Basically, it needs a "process_unknown()" which does the
> appropriate thing, and pull() needs to call that instead of
> process_commit().
It also needs a request queue.
The beauty of rsync() is that it doesn't depend on a low-latency wire to
work efficiently. Right now, pull() needs one round trip per object, and
that's way too much.
I hope to have some free time for that this week, but no promises. :-/
--
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
- -
Creativity varies inversely with the number of cooks involved with the
broth.
-- Bernice Fitz-Gibbon
^ permalink raw reply
* Re: git merging
From: Jens Axboe @ 2005-06-20 20:38 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Daniel Barkalow, Jeff Garzik, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0506200844420.2268@ppc970.osdl.org>
On Mon, Jun 20 2005, Linus Torvalds wrote:
>
> [ Daniel put on the To: list to see if he can confirm or deny my theory ]
>
> On Mon, 20 Jun 2005, Jens Axboe wrote:
> >
> > axboe@nelson:[.]l/git/linux-2.6-block.git $ git prune
> > error: cannot map sha1 file c39ae07f393806ccf406ef966e9a15afc43cc36a
>
> That's the 2.6.11 "tree" object.
>
> > bad sha1 entry '5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c'
> > axboe@nelson:[.]l/git/linux-2.6-block.git $ git-fsck-cache
> > error: cannot map sha1 file c39ae07f393806ccf406ef966e9a15afc43cc36a
> > bad object in tag 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c
> > bad sha1 entry '5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c'
> >
> > Running git prune again gives me the same output. What is wrong?
>
> Very interesting. You have my "v2.6.11-tree" tag file pointing the 2.6.11
> tree object, but you seem to not have that 2.6.11 tree itself.
>
> Actually, judging from the fact that you got this error _during_ the
> prune, maybe you never had it in that repository in the first place?
I can't tell exactly, but I'm fairly sure this is a new error. I have
two git trees locally - one which is just an rsync of your kernel.org
tree, the other which is based off that (with a clone of the fs dir) and
has multiple branches for developments. The main tree did not have this
problem, while the development tree does/did.
> In particular, if you don't use "rsync", but instead use one of the
> "optimized pull" things to create a repository (ie git-http-pull or
> git-ssh-pull), I think your newly pulled tree will always miss anything
> that isn't a head. And the 2.6.11 tree is a special case: it's a pure
> "tree" object without any commit at all pointing to it, just a single tag
> that points directly to the tree.
>
> Anyway, the fact that you're missing the original 2.6.11 tree doesn't
> really matter, so it's not a huge deal per se. You can re-populate it with
> an "rsync -avz --ignore-existing", but clearly something seems to be
> wrong.
I pulled with rsync manually from kernel.org, and that did fix things up
for me. The main tree is rsync'ed, but the development tree gets the
changes with /opt/kernel/git/linux-2.6/.git/ as the url given to
git-pull-script.
--
Jens Axboe
^ permalink raw reply
* Stacked GIT 0.2
From: Catalin Marinas @ 2005-06-20 21:00 UTC (permalink / raw)
To: git
StGIT 0.2 is now available. See http://www.procode.org/stgit/
The main changes:
- Multiple heads are supported. Each head has its own series (needs
separate 'stg init' command for each head). To change between
series, simply change the .git/HEAD link (thanks to Daniel Barkalow
for suggesting this)
- top/bottom files for each patch are backed up as a safety measure
- 'stg push' warns when the patch is empty (i.e. it was already merged
upstream)
- Many bug fixes. The tool is now usable
--
Catalin
^ permalink raw reply
* Re: git merging
From: Linus Torvalds @ 2005-06-20 21:15 UTC (permalink / raw)
To: Jens Axboe; +Cc: Daniel Barkalow, Jeff Garzik, Git Mailing List
In-Reply-To: <20050620203821.GC7712@suse.de>
On Mon, 20 Jun 2005, Jens Axboe wrote:
>
> I pulled with rsync manually from kernel.org, and that did fix things up
> for me. The main tree is rsync'ed, but the development tree gets the
> changes with /opt/kernel/git/linux-2.6/.git/ as the url given to
> git-pull-script.
Ok, that explains it. Since you're using a regular local filename, the
pull will be using "git-local-pull", which will only fetch the objects
directly needed. And doesn't understand the tag-to-tree thing, so doesn't
fetch the tree (or possibly you just copied the tags by hand totally
outside of the regular pull?)
Linus
^ permalink raw reply
* [PATCH Cogito] Prevent '.git/merging: No such file or directory' error message
From: Marcel Holtmann @ 2005-06-20 22:15 UTC (permalink / raw)
To: Petr Baudis; +Cc: GIT Mailing List
[-- Attachment #1: Type: text/plain, Size: 171 bytes --]
Hi Petr,
the attached patch prevent the '.git/merging: No such file or directory'
error message.
Regards
Marcel
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
[-- Attachment #2: patch --]
[-- Type: text/x-patch, Size: 347 bytes --]
diff --git a/cg-merge b/cg-merge
--- a/cg-merge
+++ b/cg-merge
@@ -48,7 +48,7 @@ branch=$(commit-id "$branchname") || exi
[ -s $_git/blocked ] && die "merge blocked: $(cat $_git/blocked)"
-if grep -q "$branch" $_git/merging; then
+if grep -sq "$branch" $_git/merging; then
echo "Branch already merged in the working tree." >&2
echo 0
fi
^ permalink raw reply
* [PATCH Cogito] More flexiable colorize for Acked-by statement
From: Marcel Holtmann @ 2005-06-20 22:19 UTC (permalink / raw)
To: Petr Baudis; +Cc: GIT Mailing List
[-- Attachment #1: Type: text/plain, Size: 262 bytes --]
Hi Petr,
the attached patch makes the colorize of the Acked-by statement a little
bit more flexible. It seems like people tend to use various combinations
of upper and lower case letters.
Regards
Marcel
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
[-- Attachment #2: patch --]
[-- Type: text/x-patch, Size: 429 bytes --]
diff --git a/cg-log b/cg-log
--- a/cg-log
+++ b/cg-log
@@ -265,7 +265,7 @@ print_commit_log()
sed -e '
s/^ \(.*\)/% \1/
/^% *[Ss]igned-[Oo]ff-[Bb]y:.*/ s/^% \(.*\)/% '$colsignoff'\1'$coldefault'/
- /^% *[Aa]cked-[Bb]y:.*/ s/^% \(.*\)/% '$colsignoff'\1'$coldefault'/
+ /^% *[Aa][Cc][Kk]ed-[Bb]y:.*/ s/^% \(.*\)/% '$colsignoff'\1'$coldefault'/
' | while read key rest; do
trap exit SIGPIPE
process_commit_line
^ permalink raw reply
* [PATCH] Add more curl options to git-http-pull
From: Darrin Thompson @ 2005-06-20 23:48 UTC (permalink / raw)
To: GIT Mailing List
All,
This patch makes git-http-pull work with basic http auth and ssl when
you aren't using a real cert.
Also, it makes curl's verbose output available, which is useful for
debugging.
Apologies as I expect my mail client is munging this patch slightly.
Signed-off-by: Darrin Thompson <darrint at progeny com>
---
Create option to turn off ssl peer verification.
Create option to provide username:password to curl.
Make -v additive.
When -v is specified twice, turn on CURLOPT_VERBOSE.
diff --git a/http-pull.c b/http-pull.c
--- a/http-pull.c
+++ b/http-pull.c
@@ -15,6 +15,8 @@ static z_stream stream;
static int local;
static int zret;
+static int curl_ssl_verify_enabled = 1;
+static char *curl_user_pwd = NULL;
static size_t fwrite_sha1_file(void *ptr, size_t eltsize, size_t nmemb,
void *data) {
@@ -117,12 +119,17 @@ int main(int argc, char **argv)
get_tree = 1;
get_history = 1;
} else if (argv[arg][1] == 'v') {
- get_verbosely = 1;
+ get_verbosely += 1;
+ } else if (argv[arg][1] == 'S') {
+ curl_ssl_verify_enabled = 0;
+ } else if (argv[arg][1] == 'u') {
+ arg++;
+ curl_user_pwd = argv[arg];
}
arg++;
}
if (argc < arg + 2) {
- usage("git-http-pull [-c] [-t] [-a] [-d] [-v]
[--recover] commit-id url");
+ usage("git-http-pull [-u] user:passwd [-S] [-c] [-t]
[-a] [-d] [-v] [--recover] commit-id url");
return 1;
}
commit_id = argv[arg];
@@ -131,6 +138,13 @@ int main(int argc, char **argv)
curl_global_init(CURL_GLOBAL_ALL);
curl = curl_easy_init();
+ if (curl_user_pwd) {
+ curl_easy_setopt(curl, CURLOPT_USERPWD, curl_user_pwd);
+ }
+ curl_easy_setopt(curl, CURLOPT_SSL_VERIFYPEER,
curl_ssl_verify_enabled);
+ if (get_verbosely >= 2) {
+ curl_easy_setopt(curl, CURLOPT_VERBOSE, 1);
+ }
base = url;
^ permalink raw reply
* Re: Patch (apply) vs. Pull
From: Darrin Thompson @ 2005-06-20 23:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbr61j631.fsf@assigned-by-dhcp.cox.net>
On Mon, 2005-06-20 at 10:22 -0700, Junio C Hamano wrote:
> (6) Throw away my HEAD, making Linus HEAD my HEAD, while
> preserving changes I have made since I forked from him. I
> use "jit-rewind" for this.
When you say it that way it sounds so _bad_. :-)
Would it make sense to come up with a way to make an emailed series of
patches represent a series of commits? Could patches still be
cherrypicked?
--
Darrin
^ permalink raw reply
* ORIG_HEAD
From: David S. Miller @ 2005-06-21 5:10 UTC (permalink / raw)
To: git
Is there a really good reason why git-pull-script runs are deleting
that file now?
All my scripts use ORIG_HEAD so that I can look at the changelog after
I pull from someone. There is now no record left around of what the
head was before the pull.
I could take the SHA1 output by the git-pull-script, but it'd be nice
if it was sitting under .git somewhere in case I forget to record
that information somewhere.
This is my "git-mklog" script, for example:
#/bin/sh
git-rev-tree HEAD ^ORIG_HEAD | sort -n | cut -d' ' -f2 >commit-list
cat commit-list | git-diff-tree --stdin -p | diffstat -p1
echo ''
for i in $(cat commit-list)
do
git-diff-tree -s -v ${i}
git-diff-tree -p ${i} | diffstat -p1
echo ''
done
rm -f commit-list
^ permalink raw reply
* [PATCH] fix scalability problems with git-deltafy-script (fwd)
From: Nicolas Pitre @ 2005-06-21 14:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
[ Third resent... ]
Current version would spin forever and exhaust memory while
attempting to sort all files from all revisions at once, until it
dies before even doing any real work. This is especially noticeable
when used on a big repository like the imported bkcvs repo for the
Linux kernel.
This patch allows for batching the sort to put a bound on needed
resources and making progress early, as well as including some small
cleanups.
Signed-off-by: Nicolas Pitre <nico@cam.org>
diff --git a/git-deltafy-script b/git-deltafy-script
--- a/git-deltafy-script
+++ b/git-deltafy-script
@@ -1,6 +1,6 @@
#!/bin/bash
-# Example script to deltafy an entire GIT repository based on the commit list.
+# Example script to deltify an entire GIT repository based on the commit list.
# The most recent version of a file is the reference and previous versions
# are made delta against the best earlier version available. And so on for
# successive versions going back in time. This way the increasing delta
@@ -25,37 +25,51 @@
set -e
-depth=
-[ "$1" == "-d" ] && depth="--max-depth=$2" && shift 2
+max_depth=
+[ "$1" == "-d" ] && max_depth="--max-depth=$2" && shift 2
+
+overlap=30
+max_behind="--max-behind=$overlap"
function process_list() {
if [ "$list" ]; then
echo "Processing $curr_file"
- echo "$head $list" | xargs git-mkdelta $depth --max-behind=30 -v
+ echo "$list" | xargs git-mkdelta $max_depth $max_behind -v
fi
}
+rev_list=""
curr_file=""
git-rev-list HEAD |
-git-diff-tree -r -t --stdin |
-awk '/^:/ { if ($5 == "M" || $5 == "N") print $4, $6;
- if ($5 == "M") print $3, $6 }' |
-LC_ALL=C sort -s -k 2 | uniq |
-while read sha1 file; do
- if [ "$file" == "$curr_file" ]; then
- list="$list $sha1"
- else
- process_list
- curr_file="$file"
- list=""
- head="$sha1"
- fi
+while true; do
+ # Let's batch revisions into groups of 1000 to give it a chance to
+ # scale with repositories containing long revision lists. We also
+ # overlap with the previous batch the size of mkdelta's look behind
+ # value in order to account for the processing discontinuity.
+ rev_list="$(echo -e -n "$rev_list" | tail --lines=$overlap)"
+ for i in $(seq 1000); do
+ read rev || break
+ rev_list="$rev_list$rev\n"
+ done
+ echo -e -n "$rev_list" |
+ git-diff-tree -r -t --stdin |
+ awk '/^:/ { if ($5 == "M") printf "%s %s\n%s %s\n", $4, $6, $3, $6 }' |
+ LC_ALL=C sort -s -k 2 | uniq |
+ while read sha1 file; do
+ if [ "$file" == "$curr_file" ]; then
+ list="$list $sha1"
+ else
+ process_list
+ curr_file="$file"
+ list="$sha1"
+ fi
+ done
+ [ "$rev" ] || break
done
process_list
curr_file="root directory"
-head=""
list="$(
git-rev-list HEAD |
while read commit; do
^ permalink raw reply
* Re: git merging
From: Jens Axboe @ 2005-06-21 14:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Daniel Barkalow, Jeff Garzik, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0506201410050.2268@ppc970.osdl.org>
On Mon, Jun 20 2005, Linus Torvalds wrote:
>
>
> On Mon, 20 Jun 2005, Jens Axboe wrote:
> >
> > I pulled with rsync manually from kernel.org, and that did fix things up
> > for me. The main tree is rsync'ed, but the development tree gets the
> > changes with /opt/kernel/git/linux-2.6/.git/ as the url given to
> > git-pull-script.
>
> Ok, that explains it. Since you're using a regular local filename, the
> pull will be using "git-local-pull", which will only fetch the objects
> directly needed. And doesn't understand the tag-to-tree thing, so doesn't
> fetch the tree (or possibly you just copied the tags by hand totally
> outside of the regular pull?)
Isn't that a little 'end user' confusing from a usability point of view,
that it behaves differently depending on which pull script it ends up
using in the end?
I guess I can just always use rsync even for local trees. And use it
directly, so I always have everything :)
--
Jens Axboe
^ permalink raw reply
* [PATCH] git-apply: Don't barf when --stat'ing a diff with no line changes.
From: Sven Verdoolaege @ 2005-06-21 15:14 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
Diffs with only mode changes didn't pass through git-apply --stat.
E.g.,
sh-3.00$ cg-diff -p | cat
diff --git a/autogen.sh b/autogen.sh
old mode 100644
new mode 100755
diff --git a/cdd2polylib.pl b/cdd2polylib.pl
old mode 100644
new mode 100755
sh-3.00$ cg-diff -p | git-apply --stat
Floating point exception
sh-3.00$ cg-diff -p | ~/src/git-linus/git-apply --stat
autogen.sh | 0
cdd2polylib.pl | 0
2 files changed, 0 insertions(+), 0 deletions(-)
skimo
--
git-apply: Don't barf when --stat'ing a diff with no line changes.
---
commit 2c796d01298b7e5bb5518927bf85aa461603a5c5
tree f80d68da66ee8c2ec1d491ef92c95e49db2016cd
parent 0795495388d703dc84110a9a7917dd6ec9516bb4
author Sven Verdoolaege <skimo@liacs.nl> Tue, 21 Jun 2005 17:09:27 +0200
committer Sven Verdoolaege <skimo@liacs.nl> Tue, 21 Jun 2005 17:09:27 +0200
apply.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/apply.c b/apply.c
--- a/apply.c
+++ b/apply.c
@@ -751,9 +751,11 @@ static void show_stats(struct patch *pat
del = patch->lines_deleted;
total = add + del;
- total = (total * max + max_change / 2) / max_change;
- add = (add * max + max_change / 2) / max_change;
- del = total - add;
+ if (max_change > 0) {
+ total = (total * max + max_change / 2) / max_change;
+ add = (add * max + max_change / 2) / max_change;
+ del = total - add;
+ }
printf(" %-*s |%5d %.*s%.*s\n",
len, name, patch->lines_added + patch->lines_deleted,
add, pluses, del, minuses);
^ permalink raw reply
* Re: [PATCH] git-apply: Don't barf when --stat'ing a diff with no line changes.
From: Linus Torvalds @ 2005-06-21 15:36 UTC (permalink / raw)
To: Sven Verdoolaege; +Cc: git
In-Reply-To: <20050621151430.GA26628@pc117b.liacs.nl>
On Tue, 21 Jun 2005, Sven Verdoolaege wrote:
>
> Diffs with only mode changes didn't pass through git-apply --stat.
Heh. On ppc64, "divw 0,0" apparently just silently produces 0, so I never
noticed. Thanks.
Linus
^ permalink raw reply
* Re: git merging
From: Linus Torvalds @ 2005-06-21 15:53 UTC (permalink / raw)
To: Jens Axboe; +Cc: Daniel Barkalow, Jeff Garzik, Git Mailing List
In-Reply-To: <20050621145919.GB12271@suse.de>
On Tue, 21 Jun 2005, Jens Axboe wrote:
>
> Isn't that a little 'end user' confusing from a usability point of view,
> that it behaves differently depending on which pull script it ends up
> using in the end?
Yes, I'm not claiming it's good, I'm just claiming it explains what you
see ;)
So it's a bug, but I'm hoping somebody else will fix it. I've not actually
worked on that "intelligent pull" functionality at all (aside from making
the ssh-push thing work for my limited use).
Linus
^ permalink raw reply
* [PATCH 1/1] Fix --merge-order unit test breaks introduced by 6c88be169881c9223532796bd225e79afaa115e1
From: Jon Seymour @ 2005-06-21 15:58 UTC (permalink / raw)
To: git; +Cc: torvalds, jon.seymour
The sensible cleanup of the in-memory storage order of commit parents broke the --merge-order
code which was dependent on the previous behaviour of parse_commit().
This patch restores the correctness --merge-order behaviour by taking account of the
new behaviour of parse_commit.
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
---
Tested on Linus HEAD: 0795495388d703dc84110a9a7917dd6ec9516bb4.
---
epoch.c | 15 +++------------
1 files changed, 3 insertions(+), 12 deletions(-)
diff --git a/epoch.c b/epoch.c
--- a/epoch.c
+++ b/epoch.c
@@ -424,19 +424,10 @@ static void mark_ancestors_uninteresting
static void sort_first_epoch(struct commit *head, struct commit_list **stack)
{
struct commit_list *parents;
- struct commit_list *reversed_parents = NULL;
head->object.flags |= VISITED;
/*
- * parse_commit() builds the parent list in reverse order with respect
- * to the order of the git-commit-tree arguments. So we need to reverse
- * this list to output the oldest (or most "local") commits last.
- */
- for (parents = head->parents; parents; parents = parents->next)
- commit_list_insert(parents->item, &reversed_parents);
-
- /*
* TODO: By sorting the parents in a different order, we can alter the
* merge order to show contemporaneous changes in parallel branches
* occurring after "local" changes. This is useful for a developer
@@ -445,8 +436,8 @@ static void sort_first_epoch(struct comm
* changes.
*/
- while (reversed_parents) {
- struct commit *parent = pop_commit(&reversed_parents);
+ for (parents = head->parents; parents; parents = parents->next) {
+ struct commit *parent = parents->item;
if (head->object.flags & UNINTERESTING) {
/*
@@ -470,7 +461,7 @@ static void sort_first_epoch(struct comm
} else {
sort_first_epoch(parent, stack);
- if (reversed_parents) {
+ if (parents) {
/*
* This indicates a possible
* discontinuity it may not be be
------------
^ permalink raw reply
* Re: Patch (apply) vs. Pull
From: Daniel Barkalow @ 2005-06-21 18:02 UTC (permalink / raw)
To: Darrin Thompson; +Cc: Junio C Hamano, git
In-Reply-To: <1119308502.3926.18.camel@localhost.localdomain>
On Mon, 20 Jun 2005, Darrin Thompson wrote:
> On Mon, 2005-06-20 at 10:22 -0700, Junio C Hamano wrote:
> > (6) Throw away my HEAD, making Linus HEAD my HEAD, while
> > preserving changes I have made since I forked from him. I
> > use "jit-rewind" for this.
>
> When you say it that way it sounds so _bad_. :-)
The reason is actually that he has to end up with a different history,
which is the history of the project mainline, rather than the history of
his tree. He could, of course, follow his own history, but then
communication with people who use a different history becomes difficult.
> Would it make sense to come up with a way to make an emailed series of
> patches represent a series of commits? Could patches still be
> cherrypicked?
Commits are fundamentally resistant to cherrypicking, because they give
the state of the tree rather than expressing changes in that
state. Long-term, I think that something like StGIT should be integrated
into the system and deal with generating the HEAD you get after getting
patches in.
-Daniel
*This .sig left intentionally blank*
^ 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