[PATCH] Call prune-packed from "git prune" as well.
Add -n (dryrun) flag to git-prune-packed, and call it from "git prune".
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
git-prune-script |6 --
prune-packed.c | 16
2 files changed, 16 insertions(+), 6 deletions(-)
51890a64eb152fb914d0dd3676f549ab8d8cc49a
diff --git a/git-prune-script b/git-prune-script
--- a/git-prune-script
+++ b/git-prune-script
@@ -3,10 +3,11 @@
. git-sh-setup-script || die "Not a git archive"
dryrun=
+echo=
while case "$#" in 0) break ;; esac
do
case "$1" in
--n) dryrun=echo ;;
+-n) dryrun=-n echo=echo ;;
--) break ;;
-*) echo >&2 "usage: git-prune-script [ -n ] [ heads... ]"; exit 1 ;;
*) break ;;
@@ -20,6 +21,7 @@ sed -ne '/unreachable /{
s|\(..\)|\1/|p
}' | {
cd "$GIT_OBJECT_DIRECTORY" || exit
- xargs $dryrun rm -f
+ xargs $echo rm -f
}
+git-prune-packed $dryrun
diff --git a/prune-packed.c b/prune-packed.c
--- a/prune-packed.c
+++ b/prune-packed.c
@@ -1,6 +1,9 @@
#include "cache.h"
-static const char prune_packed_usage[] = "git-prune-packed (no arguments)";
+static const char prune_packed_usage[] =
+"git-prune-packed [-n]";
+
+static int dryrun;
static void prune_dir(int i, DIR *dir, char *pathname, int len)
{
@@ -18,7 +21,9 @@ static void prune_dir(int i, DIR *dir, c
if (!has_sha1_pack(sha1))
continue;
memcpy(pathname + len, de->d_name, 38);
- if (unlink(pathname) < 0)
+ if (dryrun)
+ printf("rm -f %s\n", pathname);
+ else if (unlink(pathname) < 0)
error("unable to unlink %s", pathname);
}
}
@@ -55,8 +60,11 @@ int main(int argc, char **argv)
const char *arg = argv[i];
if (*arg == '-') {
- /* Handle flags here .. */
- usage(prune_packed_usage);
+ if (!strcmp(arg, "-n"))
+ dryrun = 1;
+ else
+ usage(prune_packed_usage);
+ continue;
}
/* Handle arguments here .. */
usage(prune_packed_usage);
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
My GIT Day
Junio C Hamano <[EMAIL PROTECTED]> writes: > *1* I should probably write a bit about how I do things in a > separate message as a how-to. So here it is. Note that the version of git on my $PATH is usually the one from the proposed updates branch, so some of the commands I use in the following text may not work for you unless you also have built "pu" one yourself. I am planning to finish updating, testing and documenting what's in the current proposed updates branch, and have most of them graduate to the master branch over the weekend. I am aiming for doing the 0.99.5 on Wednesday next week. I have the following heads all the time in my private repository: master - the one to be pushed to public "master" branch pu - master plus various proposed changes rc - master plus minimum release engineering ko-master - a copy of public "master" branch head ko-rc - a copy of public "rc" branch head My GIT day always starts with this command: $ git fetch ko I have this in .git/remotes/ko: $ cat .git/remotes/ko URL: master.kernel.org:/pub/scm/git/git.git/ Pull: master:ko-master rc:ko-rc Push: master pu rc The Pull: line gives me the default set of s to give to the "git fetch" command. I slurp "master" and "rc" heads from the public repository at master.kernel.org, and fast-forward my ko-master and ko-rc branches with them. I do not touch these two branches in any way other than this "git fetch" fast forwarding. I have a few "topic branches" in addition to the above; they change from time to time. Recently I've been looking at multi-head fetches, and that work is done in "mhf" branch. There also is a catch-all topic called "misc". I started them like this: $ git branch mhf master $ git branch misc master The first thing I do during my GIT day is to process the patches I received via e-mail. I store them one topic per file in my working tree, like this: $ ls +*.txt +js-glossary.txt +mc-mailinfo.txt Depending on the quality of the patch, seriousness of the bug they fix, and the area of the code they touch, they either go directly to "master", "misc", or sent back to the sender, but the last one, luckily for me, rarely happens: $ git checkout master $ git applymbox -q ./+js-glossary.txt .git/info/signoff $ git checkout misc $ git applymbox -q ./+mc-mailinfo.txt please The last parameter to the applymbox command is the name of a file that has my signoff message. The latest applymbox in the "pu" branch has a bit more useful extension to do the same thing as what "git commit" does. At this point, I may push out the "master" branch (and nothing else), like this: $ git push ko master This pushes only "master", ignoring the default s defined in the .git/remotes/ko file you saw earlier. Once I am done with the outside patches, I go back to where I left off the previous day: $ git checkout mhf And I check where my head is relative to the master: $ git show-branches master mhf ! [master] Yet another tweak * [mhf] Make git-fetch-script a bit more chatty. + Yet another tweak + Another tweak in Makefile + Make git-fetch-script a bit more chatty. + Update git-ls-remote-script + ... + Start adding the $GIT_DIR/remotes/ support. ++ [PATCH] Allow file removal when "git commit --all" is used. The output from show-branches is a poor-man's gitk. The named branches are shown, and '+' sign in each column shows whether the commit is contained in each branch, and the output stops where all branches converge, or you hit ^C ;-). If the mhf branch is way behind, I may choose to first rebase it, to clean up my history: $ git rebase master $ git show-branches master mhf ! [master] Yet another tweak * [mhf] Make git-fetch-script a bit more chatty. + Make git-fetch-script a bit more chatty. + Update git-ls-remote-script + ... + Start adding the $GIT_DIR/remotes/ support. ++ Yet another tweak I keep working in my topic branches. I may make some other changes in "misc" topic branch. It's a simple cycle of: $ edit-and-test $ git commit -s -a -v Eventually I get to a good point where it makes sense to push things to the public repository. $ git show-branches master mhf misc ! [master] Yet another tweak * [mhf] Make git-fetch-script a bit more chatty. ! [misc] Add hooks to tools/git-applypatch. + Make git-fetch-script a bit more chatty. + Update git-ls-remote-script + ... + Start adding the $GIT_DIR/remotes/ support. ++ Yet another tweak ++ Another tweak in Makefile + Add hooks to tools/git-applypatch. + Add commit hook and make the verification customizable. +++ [PATCH] Allow file removal when "git commit --all" is used. As you may have noticed, my topic branches are private and not pushed to the public repository. Instead, I m
Re: gitweb "tag" display
Hi, On Sat, 20 Aug 2005, Paul Mackerras wrote: > Hmmm... now I suppose we want a way to use gitk to drive the git > bisection process... :) Ssshh! Let sleeping dogs lie! ;-) Ciao, Dscho - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gitweb "tag" display
Junio C Hamano writes: > If you can pop-up a temporary window that shows the tag contents > when I hover over a tag icon for 2 seconds, and remove that > temporary window when step outside it would be ideal. It is up I did something a little easier - if you click on the tag, it now displays the contents of the tag in the details pane. Is that good enough? > to you to implement the part to show my wife's picture, reading > "object-content-type: image/jpeg" thing ;-). That one was not a > serious request. Well, Tk can display inline images in text widgets... :) > I have two more requests to gitk, which are related to each > other but not related to the "tag contents" one above: > > - if "gitk --all" slurped not just refs/heads and refs/tags but >everything under refs/* recursively, that would help >visualizing the bisect status. bisect creates bunch of >commit object names in refs/bisect. > > - I have not looked at the code closely enough, but I cannot >find how to re-read references. I would appreciate it if it >allowed it. This relates to the bisect status visualization, >where the set of references changes _after_ the user started >gitk. I implemented these two. There is now a "Reread references" button in the File menu. References other than tags and heads get displayed in a light blue box. Hmmm... now I suppose we want a way to use gitk to drive the git bisection process... :) Paul. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Make git pull default to origin
Currently, typing `git pull' without a third argument will result in an error message. Make it default to orgin, which is what the user typically means. Signed-off-by: Amos Waterland <[EMAIL PROTECTED]> --- git-pull-script | 11 +-- 1 files changed, 9 insertions(+), 2 deletions(-) de9b7753b008a1dc1bdd46f87c76ee3cd9a81d19 diff --git a/git-pull-script b/git-pull-script --- a/git-pull-script +++ b/git-pull-script @@ -1,10 +1,17 @@ #!/bin/sh # . git-sh-setup-script || die "Not a git archive" -. git-parse-remote "$@" + +if [ $# -eq 0 ]; then +remote="origin" +else +remote="$@" +fi + +. git-parse-remote "$remote" merge_name="$_remote_name" -git-fetch-script "$@" || exit 1 +git-fetch-script "$remote" || exit 1 git-resolve-script \ "$(cat "$GIT_DIR"/HEAD)" \ - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Stgit - patch history / add extra parents
On Fri, 2005-08-19 at 20:27 +0200, Jan Veldeman wrote: > hmm, not exactly, for example, when reordering the patches (including the > top one), I would like to see this in gitk. > Or when a patch has been dropped (amongst a lot of patches), it should be > easily spotted. I tried your patch but the gitk image confused me. I will look again at it tomorrow (it's quite late in the UK now). One immediate thing I noticed was that the commits directly accessible via .git/HEAD are shown as empty by gitk and you would need to follow the parents to see what they contain. For every freeze, the patches expand to the right in gitk and the graph could get very complex after several freeze commands. -- Catalin - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Add hooks to tools/git-applypatch.
This teachs git-applypatch, which is used from git-applymbox, three
hooks, similar to what git-commit-script uses.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
This is still in the proposed updates branch, along with the
hooks for "git commit". Are people comfortable with the
three-hook arrangements these two commands use?
templates/hooks--applypatch-msg | 14 ++
templates/hooks--pre-applypatch | 14 ++
tools/git-applypatch| 87 +++
3 files changed, 97 insertions(+), 18 deletions(-)
create mode 100644 templates/hooks--applypatch-msg
create mode 100644 templates/hooks--pre-applypatch
b5df0d94bf045627e74cf7faef3f51ce5e567aa4
diff --git a/templates/hooks--applypatch-msg b/templates/hooks--applypatch-msg
new file mode 100644
--- /dev/null
+++ b/templates/hooks--applypatch-msg
@@ -0,0 +1,14 @@
+#!/bin/sh
+#
+# An example hook script to check the commit log message taken by
+# applypatch from an e-mail message.
+#
+# The hook should exit with non-zero status after issuing an
+# appropriate message if it wants to stop the commit. The hook is
+# allowed to edit the commit message file.
+#
+# To enable this hook, make this file executable.
+
+test -x "$GIT_DIR/hooks/commit-msg" &&
+ exec "$GIT_DIR/hooks/commit-msg" ${1+"$@"}
+:
diff --git a/templates/hooks--pre-applypatch b/templates/hooks--pre-applypatch
new file mode 100644
--- /dev/null
+++ b/templates/hooks--pre-applypatch
@@ -0,0 +1,14 @@
+#!/bin/sh
+#
+# An example hook script to verify what is about to be committed
+# by applypatch from an e-mail message.
+#
+# The hook should exit with non-zero status after issuing an
+# appropriate message if it wants to stop the commit.
+#
+# To enable this hook, make this file executable.
+
+test -x "$GIT_DIR/hooks/pre-commit" &&
+ exec "$GIT_DIR/hooks/pre-commit" ${1+"$@"}
+:
+
diff --git a/tools/git-applypatch b/tools/git-applypatch
--- a/tools/git-applypatch
+++ b/tools/git-applypatch
@@ -10,58 +10,109 @@
## $3 - "info" file with Author, email and subject
## $4 - optional file containing signoff to add
##
-signoff="$4"
+. git-sh-setup-script || die "Not a git archive."
+
final=.dotest/final-commit
##
## If this file exists, we ask before applying
##
query_apply=.dotest/.query_apply
+
+## We do not munge the first line of the commit message too much
+## if this file exists.
keep_subject=.dotest/.keep_subject
+
+
MSGFILE=$1
PATCHFILE=$2
INFO=$3
-EDIT=${VISUAL:-$EDITOR}
-EDIT=${EDIT:-vi}
+SIGNOFF=$4
+EDIT=${VISUAL:-${EDITOR:-vi}}
export GIT_AUTHOR_NAME="$(sed -n '/^Author/ s/Author: //p' .dotest/info)"
export GIT_AUTHOR_EMAIL="$(sed -n '/^Email/ s/Email: //p' .dotest/info)"
export GIT_AUTHOR_DATE="$(sed -n '/^Date/ s/Date: //p' .dotest/info)"
export SUBJECT="$(sed -n '/^Subject/ s/Subject: //p' .dotest/info)"
-if [ -n "$signoff" -a -f "$signoff" ]; then
- cat $signoff >> $MSGFILE
+if test '' != "$SIGNOFF"
+then
+ if test -f "$SIGNOFF"
+ then
+ SIGNOFF=`cat "$SIGNOFF"` || exit
+ elif case "$SIGNOFF" in yes | true | me | please) : ;; *) false ;; esac
+ then
+ SIGNOFF=`git-var GIT_COMMITTER_IDENT | sed -e '
+ s/>.*/>/
+ s/^/Signed-off-by: /'
+ `
+ else
+ SIGNOFF=
+ fi
+ if test '' != "$SIGNOFF"
+ then
+ LAST_SIGNED_OFF_BY=`
+ sed -ne '/^Signed-off-by: /p' "$MSGFILE" |
+ tail -n 1
+ `
+ test "$LAST_SIGNED_OFF_BY" = "$SIGNOFF" ||
+ echo "$SIGNOFF" >>"$MSGFILE"
+ fi
fi
+
patch_header=
test -f "$keep_subject" || patch_header='[PATCH] '
-(echo "$patch_header$SUBJECT" ; if [ -s $MSGFILE ]; then echo ; cat $MSGFILE;
fi ) > $final
+{
+ echo "$patch_header$SUBJECT"
+ if test -s "$MSGFILE"
+ then
+ echo
+ cat "$MSGFILE"
+ fi
+} >"$final"
-f=0
-[ -f $query_apply ] || f=1
+interactive=yes
+test -f "$query_apply" || interactive=no
-while [ $f -eq 0 ]; do
+while [ "$interactive" = yes ]; do
echo "Commit Body is:"
echo "--"
- cat $final
+ cat "$final"
echo "--"
echo -n "Apply? [y]es/[n]o/[e]dit/[a]ccept all "
read reply
- case $reply in
- y|Y) f=1;;
+ case "$reply" in
+ y|Y) interactive=no;;
n|N) exit 2;; # special value to tell dotest to keep going
- e|E) $EDIT $final;;
- a|A) rm -f $query_apply
-f=1;;
+ e|E) "$EDIT" "$final";;
+ a|A) rm -f "$query_apply"
+interactive=no ;;
esac
done
+if test -x "$GIT_DIR"/hooks/applypatch-msg
+then
+ "$GIT_DIR"/hooks/applypatch-msg "$final" || exit
+fi
+
echo
echo Applying
Re: [PATCH] git-rev-list: avoid crash on broken repository
I humbly appreciate your patch, sir. I am really sorry to be in the position of having to tell you this, but earlier the Emperor Penguin himself gave me this shiny blue baseball bat and told me to show it to any deserving person. Could you please come closer and kindly extend your neck a little bit more, so I can swing it well at your head... Subject: Re: [PATCH] Teach applymbox to keep the Subject: line. Date: Wed, 17 Aug 2005 13:42:57 -0700 Message-ID: <[EMAIL PROTECTED]> Linus Torvalds <[EMAIL PROTECTED]> writes: > ... > Ergo: if somebody sends you mime-encoded patches, hit them > with a baseball bat (politely) and teach them not to do > that... I agree with you in principle and that is why I always run applymbox with the -q flag. Maybe I should start trying the baseball bat approach to see what happens. ;-) Anyway, I have merged your fix and pushed it out. Thanks for the patch. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Spell __attribute__ correctly in cache.h.
Jason Riedy <[EMAIL PROTECTED]> writes: > And Junio C Hamano writes: > - It turns out that your patch breaks GCC build > > Whoops, sorry. Your fix works with Sun's cc. Thanks. > BTW, how would people feel about replacing the > setenv() and unsetenv() calls with the older putenv()? > The Solaris version I have to work on doesn't have > the nicer functions (and I'm not an admin). I have > to check that the unsetenv() in git-fsck-cache.c works > correctly as a putenv before I send along a patch. No comment on this one at this moment until I do my own digging a bit. > There's also the issue that /bin/sh isn't bash, but an > installation-time helper script can fix that. My personal preference is to rewrite parts that are easily unbashified first before going that route, but I suspect that it would end up being the best practical solution to simply admit that we depend on bash, start our scripts with "#!/bin/bash", and rewrite them "#!/usr/local/bin/bash" upon installation; modulo that it may be a stupid and ugly workaround. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git commit (or git-commit-script) question
Linus Torvalds <[EMAIL PROTECTED]> writes: > However, one thing to look out for is that if you've marked any files for > update (with git-update-cache) those will always be committed regardless > of what arguments you give to "git commit". Another thing to look out for is that the files you told it about with "git add" will be included and does not show up in "git diff", because there currently is no way to record "intent to add" (rather, "Mr GIT, please keep an eye on this file") without actually adding a path to the index file for inclusion in the next commit. I have a couple of updates to git-commit-script in the proposed updates branch, and one of the changes is that git-update-cache in git-commit-script, used when either the --all flag or explicit paths are given, has a --remove flag there. The reason it does not need --add flag there as well is a direct consequence of this asymmetry. Although I do not think this asymmetry a major source of confusion, I suspect that we could "fix" it by treating an index entry with all-zero mode and sha1 as "keep-an-eye-on" entry with a new flag "git-update-cache --watch " or something like that. "git-diff-files" would then treat that special entry as a nonexistent path and would compare it with whatever happens to be (or lack of it) in the working tree, and "git diff" would show a diff that creates the file. This needs a tweak or two in the diffcore machinery as well. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Stgit - patch history / add extra parents
Catalin Marinas wrote: > > The patch history feature was available in StGIT 0.1/0.2 releases > where you should have run a 'stg commit' before 'stg refresh'. The > commit was handling all the history changes, with separate commit > messages and refresh was updating the main commit with 2 parents. I > removed it in 0.3 after some people (I think it was Paul Jackson and > Daniel Barkalow) convinced me that this would make it yet another SCM > interface on top of GIT, which wasn't really my intention. I've quickly reread the threads about stg commit. Am I right to assume that _all_ history was being recorded? Because this is not what I want. The person controlling the archive should specify when to record the history. So for example, you only tag (freeze) the history when exporting the patches. When an error is being reported on that version, it's easy to view it and also view the progress that was already been made on those patches. Best regards, Jan - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] git-rev-list: avoid crash on broken repository
When following tags, check for parse_object() success and error out
properly instead of segfaulting.
Signed-off-by: Sergey Vlasov <[EMAIL PROTECTED]>
---
rev-list.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
f4ec41063d2f43b06b7c8e511108b4c9bf9e6ebe
diff --git a/rev-list.c b/rev-list.c
--- a/rev-list.c
+++ b/rev-list.c
@@ -418,6 +418,8 @@ static struct commit *get_commit_referen
if (tag_objects && !(object->flags & UNINTERESTING))
add_pending_object(object, tag->tag);
object = parse_object(tag->tagged->sha1);
+ if (!object)
+ die("bad object %s", sha1_to_hex(tag->tagged->sha1));
}
/*
pgpfrZHSo19JB.pgp
Description: PGP signature
Re: [RFC] Stgit - patch history / add extra parents
Catalin Marinas wrote: > > The patch history feature was available in StGIT 0.1/0.2 releases > where you should have run a 'stg commit' before 'stg refresh'. The > commit was handling all the history changes, with separate commit > messages and refresh was updating the main commit with 2 parents. I > removed it in 0.3 after some people (I think it was Paul Jackson and > Daniel Barkalow) convinced me that this would make it yet another SCM > interface on top of GIT, which wasn't really my intention. hmm, I must have misted those threads, I'll try to find and read them. > > The main problem with having multiple parents for a commit object > corresponding to a patch is the upstream merging via 'git pull'. In > general you don't want a gatekeeper to pull the history of your patch > but the patch only. I agree that such history should not be imported into the mainline, but such history would still be very usefull when these patches won't be pushed to mailine immediately. Also, when pushing to mainline, this history can easily be removed by removing the branch/patch/parent files and refreshing (this should off course be automated) > > > The patch below, together with the following script could be used to > > make snapshots of the patch stack (I call it freeze, as I thought snapshot > > was already going to be used for something else): > > 'snapshot' is not yet used for anything and I'm not sure how it is > best to be implemented. I thought about simply saving the current HEAD > into some .git/refs/heads/, without preserving any history for > the patch. A gitk on this file would show the patches as they were on > the time of the snapshot creation. A new snapshot would remove this. > > It might be best for a per-patch history to have a separate file in > //, maybe called freeze, which keeps this history > information. The top one should remain unchanged. Its hash could be > accessed with the 'stg id /freeze' command (implemented > yesterday). This file would only be updated via the 'freeze' command > and its parent would be the previous freeze value. > > Would this be close to what you need? > hmm, not exactly, for example, when reordering the patches (including the top one), I would like to see this in gitk. Or when a patch has been dropped (amongst a lot of patches), it should be easily spotted. But even if the "stg-freeze" would not be incorporated into stgit, would it still be possible to include some sort of extra parents directory. So that the freeze can be implemented on top of stgit? TIA Best regards, Jan - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git commit (or git-commit-script) question
Ah, that explains it. I had already marked all my changes for update, that's what threw me off here. Thanks! Linus Torvalds wrote: On Fri, 19 Aug 2005, Johnny Stenback wrote: That made me assume that if I do: git-commit-script somedir it would *only* commit the changes I've made in "somedir", but it appears to commit *all* files that have changed (and shows all files in the list of changed files in the commit message it displays in the editor), as if it's completely ignoring the argument. Known problem? I got this using git that I pulled from kernel.org earlier this morning. It works for me. You _should_ see something like # # Updated but not checked in: # (will commit) # # modified: somedir/somefile # # # Changed but not updated: # (use git-update-cache to mark for commit) # # modified: otherdir/anotherfile # which basically means that it will commit "somedir/somefile", but _not_ commit "otherdir/anotherfile". However, one thing to look out for is that if you've marked any files for update (with git-update-cache) those will always be committed regardless of what arguments you give to "git commit". You can reset the index with "git reset" if you decided that you don't want to commit after all. (For example, if you do a "git commit --all", but decide not to commit after all by writing an empty commit message, that will already have marked all the files to be committed, so next time, even if you then use "git commit somedir", all the files in all the _other_ dirs have already been marked for update, so you'll see everything being committed). Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- jst - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git commit (or git-commit-script) question
On Fri, 19 Aug 2005, Johnny Stenback wrote: > > That made me assume that if I do: > >git-commit-script somedir > > it would *only* commit the changes I've made in "somedir", but it > appears to commit *all* files that have changed (and shows all files in > the list of changed files in the commit message it displays in the > editor), as if it's completely ignoring the argument. > > Known problem? I got this using git that I pulled from kernel.org > earlier this morning. It works for me. You _should_ see something like # # Updated but not checked in: # (will commit) # # modified: somedir/somefile # # # Changed but not updated: # (use git-update-cache to mark for commit) # # modified: otherdir/anotherfile # which basically means that it will commit "somedir/somefile", but _not_ commit "otherdir/anotherfile". However, one thing to look out for is that if you've marked any files for update (with git-update-cache) those will always be committed regardless of what arguments you give to "git commit". You can reset the index with "git reset" if you decided that you don't want to commit after all. (For example, if you do a "git commit --all", but decide not to commit after all by writing an empty commit message, that will already have marked all the files to be committed, so next time, even if you then use "git commit somedir", all the files in all the _other_ dirs have already been marked for update, so you'll see everything being committed). Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
git commit (or git-commit-script) question
Hey all, git-commit-script --help says: git commit [-a] [-m ] [-F ] [(-C|-c) ] [...] That made me assume that if I do: git-commit-script somedir it would *only* commit the changes I've made in "somedir", but it appears to commit *all* files that have changed (and shows all files in the list of changed files in the commit message it displays in the editor), as if it's completely ignoring the argument. Known problem? I got this using git that I pulled from kernel.org earlier this morning. -- jst - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Importing from a patch-oriented SCM
On Fri, 19 Aug 2005, Martin Langhoff wrote: > On 8/19/05, Junio C Hamano <[EMAIL PROTECTED]> wrote: > > Martin Langhoff <[EMAIL PROTECTED]> writes: > > > > > If I remember correctly, Junio added some stuff in the merge & rebase > > > code that will identify if a particular patch has been seen and > > > applied, and skip it even if it's a bit out of order. But I don't know > > > > I think you are talking about git-patch-id. > > Is this used at commit time, and stored somewhere (doesn't seem to be) > or do you select older patches from the destination branch at merge > time? If a patch is applied verbatim, or a merge results in no conflicts (i.e., only offsets), then you can run git-patch-id on the diff caused by it and compare the result with the git-patch-id of the diff caused by your local change to see if you've found it. Of course, if there was any modification to the patch or a conflict was resolved, you won't see a match, but that's plausibly correct anyway: you don't know whether the content change that resulted from your patch really matched the change you wanted to make. > If you only compare patches since the last merge, patches that were > merged but somehow unreported will fall into a black hole and cause a > conflict going forward anyway. Hmm. That seems to be a problem I > won't be able to avoid if merges happen out-of-order. They might cause conflicts, but they're relatively unlikely to require manual intervention, because the merging mechanism in git is stronger than the one in arch (by virtue of identifying a common ancestor), and will recognize when a section of changes made by both sides is the same and produce a warning rather than a conflict. That's how the rebase stuff can identify that your rebased patch is empty (when upstream applies your patch): the content change that it would make has been made. -Daniel *This .sig left intentionally blank* - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Merge conflicts as .rej .orig files
On Fri, 19 Aug 2005, Martin Langhoff wrote: > After using arch for a while, I've gotten used to getting .rej and > .orig files instead of big ugly conflict markers inside the file. > Emacs has a nice 'diff' mode that is a boon when dealing with > conflicts this way. > > Is there a way to convince cogito/git to leave reject files around? > What utility is git using to do the merges? Or at least: where should > I look? I believe you should be able to get that effect by having a version of "git-merge-one-script" that does "diff -c $2 $3 | patch $1" or "diff -c $2 $1 | patch $3", depending on which you want as the orig. (Or something like that. I'm not sure exactly how to get the conflict files out of the script and into the right place, or the arguments it gets.) Of course, you'll probably have more conflicts to deal with, because the merging code gets less information that way. (In particular, you'll lose the "already contains changes" behavior, so you'll be unhappy if you have patches merged upstream.) -Daniel *This .sig left intentionally blank* - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
FYI: My experiences with cygwin & git
Hi, I tried to compile & run git on cygwin. Two showstoppers: - cygwin does not support IPv6 (yet). Therefore, it does not have getaddrinfo() and friends. (minor showstopper) - fork() and mmap() together have problems. This manifests itself in "git-diff-tree -p" not working. (showbomber) No big problem for me, I only tested cygwin out of curiosity. Ciao, Dscho - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Questions on 'cvs migration guide''
On Fri, 19 Aug 2005, Martin Langhoff wrote: > > I'm keen on keeping my 'merge & publish' step in a single repo that > has all the 'team' branches. The person running this repo will > probably actually code in separate repos, and merge in there too. I would suggest against a person owning a "merge and publish". Instead, just have a public repo that everybody involved to can push to - _they_ will need to merge before they push (since a push won't accept a unrelated parent), but that way anybody can export their changes at any time, exactly like with a central CVS repository. > Right now I'm switching 'heads' (I'm getting used to cogito's use of > 'branch' for 'remote head') using this quick'n'dirty bit of shell: No, just do git checkout > but I want to prevent the action if the checkout is 'dirty'. Is there > any way to check whether cg-diff thinks anything has changed? If you use "git checkout" to switch branches, it will do that testing for you. You can still _force_ a head switch with "git checkout -f". Oh, and if a file was dirty that is the same in both heads, the "dirtyness" follows you into the new head. If that isn't what you want, then you need to add some logic like if [ "$(git-diff-files)" != "" ]; then echo "Current branch not clean" >&2 exit 1 fi git checkout "$@" or something. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Spell __attribute__ correctly in cache.h.
And Junio C Hamano writes: - It turns out that your patch breaks GCC build Whoops, sorry. Your fix works with Sun's cc. BTW, how would people feel about replacing the setenv() and unsetenv() calls with the older putenv()? The Solaris version I have to work on doesn't have the nicer functions (and I'm not an admin). I have to check that the unsetenv() in git-fsck-cache.c works correctly as a putenv before I send along a patch. There's also the issue that /bin/sh isn't bash, but an installation-time helper script can fix that. Jason - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Multi-head fetches, pulls, and a King Ghidorah
Johannes Schindelin <[EMAIL PROTECTED]> writes: > Hi, > > If I understand correctly, the multi-head fetch would not write any ref if > used like this: > > git fetch remote:repository/ head tail > > but it would try a fast-forward when used like this: > > git fetch remote:repository/ head:head tail:tail > > Correct? If yes: This is fantastic! It obsoletes my dumb script. That is the intent, but what is currently in "pu" is somewhat broken. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
SVN import
Quick note: I'm working on importing from SVN.
My current main problem is that SVN's Perl interface leaks server
connections (apparently nobody has used it for any real work yet),
which is of course *bad*, and kindof prevents me from finishing
the job today. :-/
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
I could certainly run a marvellous university here if only we didn't
have to have all these damn students underfoot all the time.
-- Terry Pratchett (Hogfather)
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Stgit - patch history / add extra parents
Jan Veldeman <[EMAIL PROTECTED]> wrote: > I like stgit very much, but I feel there is still something missing: > stgit is very handy when you use it for patches which should be pushed to > mainline rather quickly. But for pacthes which won't be pushed immediately > to mainline, it would be usefull to have a history of the patches > itself. The patch history feature was available in StGIT 0.1/0.2 releases where you should have run a 'stg commit' before 'stg refresh'. The commit was handling all the history changes, with separate commit messages and refresh was updating the main commit with 2 parents. I removed it in 0.3 after some people (I think it was Paul Jackson and Daniel Barkalow) convinced me that this would make it yet another SCM interface on top of GIT, which wasn't really my intention. The main problem with having multiple parents for a commit object corresponding to a patch is the upstream merging via 'git pull'. In general you don't want a gatekeeper to pull the history of your patch but the patch only. > The patch below, together with the following script could be used to > make snapshots of the patch stack (I call it freeze, as I thought snapshot > was already going to be used for something else): 'snapshot' is not yet used for anything and I'm not sure how it is best to be implemented. I thought about simply saving the current HEAD into some .git/refs/heads/, without preserving any history for the patch. A gitk on this file would show the patches as they were on the time of the snapshot creation. A new snapshot would remove this. It might be best for a per-patch history to have a separate file in //, maybe called freeze, which keeps this history information. The top one should remain unchanged. Its hash could be accessed with the 'stg id /freeze' command (implemented yesterday). This file would only be updated via the 'freeze' command and its parent would be the previous freeze value. Would this be close to what you need? -- Catalin - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Multi-head fetches, pulls, and a King Ghidorah
Hi, If I understand correctly, the multi-head fetch would not write any ref if used like this: git fetch remote:repository/ head tail but it would try a fast-forward when used like this: git fetch remote:repository/ head:head tail:tail Correct? If yes: This is fantastic! It obsoletes my dumb script. On Fri, 19 Aug 2005, Junio C Hamano wrote: > However, suppose then I were Joe Random, an individual netdev > contributor who is interested in these two netdev branches. > Upon seeing the pull request, I might decide it is a good time > to get changes from there, my upstream. > > $ git pull jgarzik/netdev-2.6.git/ sis190:sis190 e100:e100 > > Because I am keeping track of copies of these two branches, I > use "sis190:sis190 e100:e100" to update my local heads. I propose a "--separate" flag to git pull. This would do exactly the same as a plain git pull, but for each fetched branch which could not be fast-forwarded - try to switch to the branch (dying if it is not the current, and the working tree is dirty) - try a merge - if the merge fails, reset the branch to original state, write out a temporary head and output a warning After that, it would switch back to the original branch and check that out. For all failed merges, the user needs to "git resolve" (the exact command line could be output by "git pull --separate"). Ciao, Dscho - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Spell __attribute__ correctly in cache.h.
Jason Riedy <[EMAIL PROTECTED]> writes: > Sun's cc doesn't know __attribute__. It turns out that your patch breaks GCC build (#ifndef __attribute__ is true there, and it should be---what it does cannot be done in preprocessor alone). I am going to work it around like this. Could you try it with Sun cc please? --- diff --git a/cache.h b/cache.h --- a/cache.h +++ b/cache.h @@ -38,11 +38,10 @@ #define NORETURN __attribute__((__noreturn__)) #else #define NORETURN -#endif - #ifndef __attribute__ #define __attribute__(x) #endif +#endif /* * Intensive research over the course of many years has shown that - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Importing from a patch-oriented SCM
On 8/19/05, Junio C Hamano <[EMAIL PROTECTED]> wrote: > Martin Langhoff <[EMAIL PROTECTED]> writes: > > > If I remember correctly, Junio added some stuff in the merge & rebase > > code that will identify if a particular patch has been seen and > > applied, and skip it even if it's a bit out of order. But I don't know > > I think you are talking about git-patch-id. Is this used at commit time, and stored somewhere (doesn't seem to be) or do you select older patches from the destination branch at merge time? If you only compare patches since the last merge, patches that were merged but somehow unreported will fall into a black hole and cause a conflict going forward anyway. Hmm. That seems to be a problem I won't be able to avoid if merges happen out-of-order. I'll try and work out how it's being used during the merge (pointers/hints welcome) and see if I can do something smart w it. Thanks! cheers, martin - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Importing from a patch-oriented SCM
Hi, On Fri, 19 Aug 2005, Martin Langhoff wrote: > Each patchset has a unique identifier, and can carry metadata with the > identifiers of the patches it "includes". If you are using gnu arch, > when you merge across branches, it'll know to skip a particular > patchset if it has been applied already. AFAICT there is no such > concept in GIT, and I wonder what to do with all this metadata about > merges. You should include the metadata in the commit object. If the information is about parents, they should be parents in git, too. If the information is something else, you should convert it to readable text and put it in the comment part of the commit object. > If I remember correctly, Junio added some stuff in the merge & rebase > code that will identify if a particular patch has been seen and > applied, and skip it even if it's a bit out of order. The usual way of git is to use a 3-way merge: given a common ancestor, try to apply the changes between the ancestor and the second branch to the first branch. And yes, this does not take history into account. Originally, I wanted to write an "intelligent" merge, which turns the history into patches and tries to merge these, but ultimately I got convinced that this is too complicated to be worthwhile. Ciao, Dscho - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Merge conflicts as .rej .orig files
Martin Langhoff <[EMAIL PROTECTED]> wrote:
> After using arch for a while, I've gotten used to getting .rej and
> .orig files instead of big ugly conflict markers inside the file.
> Emacs has a nice 'diff' mode that is a boon when dealing with
> conflicts this way.
>
> Is there a way to convince cogito/git to leave reject files around?
> What utility is git using to do the merges? Or at least: where should
> I look?
You could have a look at StGIT as well. The tool you use for merges is
configurable via the stgitrc file (diff3 is used by default, which
leaves markers in the file). StGIT also leaves the 3 files involved in
the tree-way merge as .{older,local,remote} for further
inspection.
If you prefer other tool than diff3, you can define it in the stgitrc
file. Two examples are given for emacs and xxdiff. You could also
write a small script which invokes diff3 by default and, if it fails,
run the emacs ediff-merge-files-with-ancestor function.
--
Catalin
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] Allow file removal when "git commit --all" is used.
Hi, On Thu, 18 Aug 2005, Junio C Hamano wrote: > Johannes Schindelin <[EMAIL PROTECTED]> writes: > > >> The patch is for people who thinks the user who uses the "--all" > >> flag deserves the danger that comes with the convenience. > >> > >> Comments? > > > > This is a sane default behaviour. Maybe introduce yet another flag > > "--no-remove", which says that removes should not be performed? But then, > > "--all" is mostly used by lazy people, who probably expect the removes to > > take place. > > Well, let's refrain from using that word; I am one of the "lazy" > people, but I do that on purpose and from principle, not from > lazyness. http://members.cox.net/junkio/per-file-commit.txt. Sorry, when I say "lazy people" I mean "yours truly". Ciao, Dscho - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Fix git-mailinfo to understand empty commit messages
In case of empty messages git-mailinfo ignores the "---"
line adding dirty stuff in commit message otherwise empty
Signed-off-by: Marco Costalba <[EMAIL PROTECTED]>
---
tools/mailinfo.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
1ebfddf05e4655811157028091d03dfce39cc4f0
diff --git a/tools/mailinfo.c b/tools/mailinfo.c
--- a/tools/mailinfo.c
+++ b/tools/mailinfo.c
@@ -273,6 +273,12 @@ int main(int argc, char ** argv)
}
while (1) {
int len = read_one_header_line(line, sizeof(line), stdin);
+ /* Check for empty messages */
+ if (!memcmp("---", line, 3)) {
+ line[len] = '\n';
+ handle_rest();
+ break;
+ }
if (!len) {
handle_body();
break;
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Importing from a patch-oriented SCM
Martin Langhoff <[EMAIL PROTECTED]> writes: > If I remember correctly, Junio added some stuff in the merge & rebase > code that will identify if a particular patch has been seen and > applied, and skip it even if it's a bit out of order. But I don't know I think you are talking about git-patch-id. f97672225b3b1a2ca57cfc16f49239bed1efcd87 Author: Linus Torvalds <[EMAIL PROTECTED]> Date: Thu Jun 23 15:06:04 2005 -0700 Add "git-patch-id" program to generate patch ID's. A "patch ID" is nothing but a SHA1 of the diff associated with a patch, with whitespace and line numbers ignored. As such, it's "reasonably stable", but at the same time also reasonably unique, ie two patches that have the same "patch ID" are almost guaranteed to be the same thing. IOW, you can use this thing to look for likely duplicate commits. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Multi-head fetches, pulls, and a King Ghidorah
The current "pu" branch has most of the necessary plumbing for
multi-head fetching, pulling and creating Octopus merges based
on multiple heads. I have made "git pull" multi-head aware but
did not make it multi-head capable.
I have been trying out Tony Luck's excellent topic-branch
workflow (see Documentation/using-topic-branches.txt), and the
head of the "pu" branch is an Octopus on top of the "master" and
my two private topic branches [*1*] made with "git octopus".
I have been thinking about how the multi-head fetch and merge
should interact with each other. It appears to me that coming
up with a reasonably semantics for "git pull" that would fit
everybody is very difficult, because there are at least two
different valid workflows that involve multi-head pulling, and
they need to do different things. I'll talk about "git pull"
that can deal with more than one remote heads, which does not
exist yet, in the next couple of paragraphs.
Suppose I were the Emperor Penguin [*2*], and Jeff asks "Please
pull from my netdev-2.6.git repository, sis190 and e100
branches." It is very reasonable to expect the following to
fetch heads of those two branches and attempt to make an Octopus
[*3*] on top of a copy of the Penguin head:
$ cat .git/branches/jgarzik
kernel.org:/pub/linux/kernel/git/jgarzik/
$ git checkout -b try-jeffs-update master
$ git pull jgarzik/netdev-2.6.git/ sis190 e100
$ git diff -p master..HEAD | git apply --stat --summary
The arguments to pull, especially the refspec parameters
("sis190" and "e100" in the above example) are given to the
underlying "git fetch", and because neither of them have a
colon, they are not stored in corresponding places under the
local refs/heads/. Instead, fetched heads would be fed directly
to "git octopus" inside "git pull" (just like the current "git
pull" invokes "git resolve" internally after fetching just one
head).
However, suppose then I were Joe Random, an individual netdev
contributor who is interested in these two netdev branches.
Upon seeing the pull request, I might decide it is a good time
to get changes from there, my upstream.
$ git pull jgarzik/netdev-2.6.git/ sis190:sis190 e100:e100
Because I am keeping track of copies of these two branches, I
use "sis190:sis190 e100:e100" to update my local heads.
I might have some local changes in these two branches. The old
"git fetch" unconditionally overwrote local heads when told to,
but lately it acquired the "reverse push" semantics Johannes
Schindelin proposed to make it safer. The fetch process only
overwrites local heads when the upstream change results in a
fast-forward merge; practically, that happens only when I have
not worked on that branch since I pulled from the upstream the
last time. So my refs/heads/sis190 and refs/heads/e100 may be
copies of Jeff's heads, or they may be the same heads as I had
before starting the fetch.
At this point, it might be reasonable to expect that the above
"git pull" command would behave as if I pulled (i.e. fetched and
merged) these heads separately, using traditional single-head
pull:
$ git checkout sis190
$ git pull jgarzik/netdev-2.6.git/ sis190:sis190
$ git checkout e100
$ git pull jgarzik/netdev-2.6.git/ e100:e100
That is, fetch and resolve them independently and individually.
Back in the Emperor Penguin example, he _could_ also have been
interested in keeping copies of Jeff's branch heads, so he could
have written refspecs on the command line the same way as Joe
Random did. I.e. instead of:
$ git pull jgarzik/netdev-2.6.git/ sis190 e100
he could have said:
$ git pull jgarzik/netdev-2.6.git/ sis190:sis190 e100:e100
Both "Octopus" and "Multiple independent pull" semantics are
valid to support different workflows, and there is no way to
differenciate the two from the command line, without giving an
extra flag and making the implementation more complicated.
Currently, I am inclined to leave the current "not more than one
remote head" implementation, and possibly extend it to support
the "Octopus" semantics later, for three very simple reasons.
(1) What the latter "git pull" is buying us compared to two
traditional single-head pulls is very little; that the
underlying "git fetch" _could_ obtain packs more
efficiently than two independent fetches.
(2) The netdev example happened to involve multiple heads from
a single repository, but the pull request could as well
have been "jgarzik/netdev-2.6.git#sis190 and
jgarzik/libata-dev.git#sil24", in which case I wouldn't
have to be worrying about multi-head pull at all; the user
would just have used two independent traditional "git
pull" --- there is no other option.
(3) Or course, because I am lazy ;-). Seriously, multiple
independent merges is a nightmere when you start thinking
about what to do when you get a conflict and need to have
the user hand merge in the middle of the first one.
Sinc
[PATCH] Fixup Documentation Makefile for cg-%.txt
The syntax for .PRECIOUS in a makefile requires an implicit target to match exactly: %.txt does not cover all *.txt Signed-off-by: Kris Shannon <[EMAIL PROTECTED]> --- Documentation/Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Documentation/Makefile b/Documentation/Makefile --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -52,7 +52,7 @@ clean: rm -f *.xml *.html *.1 *.7 cg-*.txt cogito.txt -.PRECIOUS: %.txt +.PRECIOUS: cg-%.txt introduction.html: ../README asciidoc -b xhtml11 -d article -f asciidoc.conf -o $@ $< - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] Importing from a patch-oriented SCM
I am drafting an import script to turn a GNU Arch into a GIT archive. Importing the branches and commits increamentally is reasonably straightforward -- or so it seems so far. Note: the repository manipulation is based on cvsimport -- so my knowledge of the git repo internals is still pertty close to zero. Each patchset has a unique identifier, and can carry metadata with the identifiers of the patches it "includes". If you are using gnu arch, when you merge across branches, it'll know to skip a particular patchset if it has been applied already. AFAICT there is no such concept in GIT, and I wonder what to do with all this metadata about merges. My proto-plan is to keep track of merged stuff (in a cache file somewhere), and if a particular merge means that the branches are fully merged up to the last patch of the series (if no commits from the source branch have been skipped) mark it as a merge in GIT. If the merges have been done out-of-order, that may show up in the latest merge. For example, branch A and B of the same project each have 10 commits from the branching point. If a merge A -> B does commits 1,2,3,7,8 it gets imported to git as a merge up to commit "3", although there is more there. The next merge, which does 4,5,6,10 will show up as a merge of commit 8. Yuk. If I remember correctly, Junio added some stuff in the merge & rebase code that will identify if a particular patch has been seen and applied, and skip it even if it's a bit out of order. But I don't know what that is based on, and whether I can somehow maximize the chances of the patch being identified as already merged across branches. If it's based on the initial commit identifier being carried through (does that travel with commits when you merge?) I stand a small chance. Otherwise, I'm lost. Suggestions? cheers, martin - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
