Re: Storing state in $GIT_DIR
Martin Langhoff <[EMAIL PROTECTED]> writes: > Hmmm. That repo is in sync, but there are no guarantees that they will > travel together to a different repo. In fact, the push/pull > infrastructure wants to push/pull one head at a time. > > And if they are not in sync, I have no way of knowing. Hmpf. I lie: > the arch metadata could keep track of what it expects the last head > commits to be, and complain bitterly if something smells rotten. > > let me think about it ;) Thinking about it going from arch to git should be just a matter of checking sha1 hashes, possibly back to the beginning of the arch tree. Going from git to arch is the trickier mapping, because you need to know the full repo--category--branch--version--patch mapping. Hmm. Thinking about arch from a git perspective arch tags every commit. So the really sane thing to do (I think) is to create a git tag object for every arch commit. With that structure you would just need to create a git-arch-rev-list so you can get a list of which arch branches you already have. And then a git-arch-push and a git-arch-pull should be just a matter of finding the common ancestor and continuing along the branch until you reach the head. Handling all heads in an arch repository is a little trickier but should not be too bad. On the push side you can just treat git as an arch working directory and push changsets into the appropriate branch. For branches that do not have tla as the ancestor you can do the equivalent of tla archive-mirror. Changes can be merged on whichever side make sense. With patch trading (Martin I think I know what you are refering to) arch does seem to have a concept that does not map very well to git, and this I think is a failing in git. Arch can record that just the changes from a single changset/patch were merged. This happens all of the time in the kernel tree when patches are merged. The interesting case for merge algorithms is when two maintainers merge the same patches into separate branches and then the branches are merged. Does git have a good way of coping with that case? On the simple side it for patch trading it might just be worth treating them as a special git merge with just one parent in the parents line and the real parent listed in the merge comment, along with the original parents commit comment. But that just might be too ugly to think about. How does StGit handle this? Eric - 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: Storing state in $GIT_DIR
On 8/26/05, Junio C Hamano <[EMAIL PROTECTED]> wrote: > > Hmmm. That repo is in sync, but there are no guarantees that they will > > travel together to a different repo. In fact, the push/pull > > infrastructure wants to push/pull one head at a time. > > Wrong as of last week ;-), and definitely wrong since this morning. Haven't had time to learn what the new conventions are for push/pull scenarios. Will try and read up... > > And if they are not in sync, I have no way of knowing. Hmpf. I lie: > > the arch metadata could keep track of what it expects the last head > > commits to be, and complain bitterly if something smells rotten. > > What Linus suggests is doable by using an object that can hold > a pointer to at least one commit---you used that to record the > head commit of the corresponding git branch that the arch > metainfo represents. Yes. If I have my "arch-metadata" head, I can have several files there, one of them containing a list of head "names" and the sha we expect them to correspond to. If the thing doesn't match, we crash and burn because we are out of sync. Now, during import I'll have to be extra careful at commit-time, and update and commit the arch-metadata head immediately after I commit the head I'm importing, with strong error-handling. This should minimize the out-of-sync situation. If we _are_ out-of-sync, I could have a recovery mode that rewinds the heads to the 'last known good' position and replays things forward. If my script is stable, the results should be stable too... > You only pull arch metainfo branch; the objects associated with > the corresponding git branch head will be pulled together when > you pull it. You do not have to tell git to pull git-part of > the commit chain. There is no need to worry about version skew > when you use git this way. >From here onwards, you lost me, mate ;) 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: Storing state in $GIT_DIR
Daniel Barkalow <[EMAIL PROTECTED]> writes: > I don't think this buys you anything, because then the tag needs to be > accessible from something, which is the same problem you were trying to > solve for the commit. Actually not. My suggestion was a qualified one: "If all you need is a textual information plus a single pointer to a commit object", and Martin did not say different generations of arch metainfo needs to be strung together, so you could keep updating the tag object in "refs/tags/arch-meta-info", which has such a pointer and textual arch meta info and nothing else. - 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: Storing state in $GIT_DIR
Linus Torvalds <[EMAIL PROTECTED]> writes: > That kind of extension shouldn't be too hard, and might make tags much > more generally usable (ie you could say "I sign these official > releases" or something). Well, I admit that once I advocated changing "tag" to "bag", but one problem is how you would dereference something like that. "v0.99.5^0" means "look at the named object v0.99.5, dereference it repeatedly until you get a non-tag, and take the result, which had better be a commit". If a tag can contain more than one pointers, I do not know what it means. - 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: Storing state in $GIT_DIR
On Fri, 26 Aug 2005, Daniel Barkalow wrote: > > I don't think this buys you anything, because then the tag needs to be > accessible from something, which is the same problem you were trying to > solve for the commit. Yes. We had an earlier discussion somewhat along these lines, where a "collection" object might be useful. The "tree" object is that, of course, but the tree object really is very strictly structured (and has to be that way). There might be a valid case for an object that can point to an arbitrary collection of other objects, and have a free-form tail to it. Of course, such an object would inevitably look very much like a generalized "tag" object, so one possibility might be to just allow a tag to have multiple object pointers. We could easily generalize the tag format: just make it be something like - 1 or more lines of "object " - make the "type " line optional (it used to have an implementation reason: the internal interfaces always used to want to know the type up-front, but we've moved away from that). - a single "tag" line to start the free-form section, and to name the collection some way. That kind of extension shouldn't be too hard, and might make tags much more generally usable (ie you could say "I sign these official releases" 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: [RFC] Looking at multiple ancestors in merge
On Wed, 24 Aug 2005, Daniel Barkalow wrote: > Of course, this is going to take a bit of work, because read-tree > currently puts all of its arguments into the cache and then works on > merging, and taking multiple ancestors requires putting them somewhere > else, because they won't fit in the cache. I've started this, and have gotten as far as having read-tree accept > 3 trees and ignore everything but the last 3. Am I correct in assuming that if I break read-tree in any way, some test will fail? -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
[PATCH] update howto/using-topic-branches.txt
Various updates and cleanups for my howto on using branches in GIT as a Linux subsystem maintainer. Three categories of changes: 1) Updates for new features in GIT 0.99.5 2) Changes to use "git fetch" rather than "git pull" to update local linus branch. 3) Cleanups suggested by Len Brown Signed-off-by: Tony Luck <[EMAIL PROTECTED]> --- diff --git a/Documentation/howto/using-topic-branches.txt b/Documentation/howto/using-topic-branches.txt --- a/Documentation/howto/using-topic-branches.txt +++ b/Documentation/howto/using-topic-branches.txt @@ -5,12 +5,10 @@ Subject: Some tutorial text (was git/cog Here's something that I've been putting together on how I'm using GIT as a Linux subsystem maintainer. -I suspect that I'm a bit slap-happy with the "git checkout" commands in -the examples below, and perhaps missing some of the _true-git_ ways of -doing things. - -Tony +Last updated w.r.t. GIT 0.99.5 + Linux subsystem maintenance using GIT - @@ -48,24 +46,38 @@ Change directory into the cloned tree yo $ cd work -Make a GIT branch named "linus", and rename the "origin" branch as linus too: +Set up a remotes file so that you can fetch the latest from Linus' master +branch into a local branch named "linus": + + $ cat > .git/remotes/linus + URL: rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git + Pull: master:linus + ^D - $ git checkout -b linus - $ mv .git/branches/origin .git/branches/linus +and create the linus branch: + + $ git branch linus The "linus" branch will be used to track the upstream kernel. To update it, you simply run: - $ git checkout linus && git pull linus + $ git fetch linus + +you can do this frequently (and it should be safe to do so with pending +work in your tree, but perhaps not if you are in mid-merge). -you can do this frequently (as long as you don't have any uncommited work -in your tree). +If you need to keep track of other public trees, you can add remote branches +for them too: -If you need to keep track of other public trees, you can add branches for -them too: + $ git branch another + $ cat > .git/remotes/another + URL: ... insert URL here ... + Pull: name-of-branch-in-this-remote-tree:another + ^D - $ git checkout -b another linus - $ echo URL-for-another-public-tree > .git/branches/another +and run: + + $ git fetch another Now create the branches in which you are going to work, these start out at the current tip of the linus branch. @@ -78,15 +90,25 @@ These can be easily kept up to date by m $ git checkout test && git resolve test linus "Auto-update from upstream" $ git checkout release && git resolve release linus "Auto-update from upstream" -Set up so that you can push upstream to your public tree: +Set up so that you can push upstream to your public tree (you need to +log-in to the remote system and create an empty tree there before the +first push). - $ echo master.kernel.org:/ftp/pub/scm/linux/kernel/git/aegl/linux-2.6.git > .git/branches/origin + $ cat > .git/remotes/mytree + URL: master.kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git + Push: release + Push: test + ^D -and then push each of the test and release branches using: +and the push both the test and release trees using: - $ git push origin test -and - $ git push origin release + $ git push mytree + +or push just one of the test and release branches using: + + $ git push mytree test +or + $ git push mytree release Now to apply some patches from the community. Think of a short snappy name for a branch to hold this patch (or related group of @@ -169,9 +191,9 @@ test|release) git checkout $1 && git resolve $1 linus "Auto-update from upstream" ;; linus) - before=$(cat .git/HEAD) - git checkout linus && git pull linus - after=$(cat .git/HEAD) + before=$(cat .git/refs/heads/linus) + git fetch linus + after=$(cat .git/refs/heads/linus) if [ $before != $after ] then git-whatchanged $after ^$before | git-shortlog - 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: Storing state in $GIT_DIR
On Thu, 25 Aug 2005, Junio C Hamano wrote: > Now, among the existing object types, there are only two kinds > of objects you can use for this. If the only thing you need to > record is some textual information with one pointer to git > branch head, then you can use tag that points at the git head, > and store everything else as the tag comment. This is doable > but unwieldy. I don't think this buys you anything, because then the tag needs to be accessible from something, which is the same problem you were trying to solve for the commit. > You could abuse a commit object as well; you store commit > objects (such as the corresponding git branch head) as parent > commits, and put everything else in a tree that is associated > with that commit. If you want to go that way, you could add a new field to commits with minimal effort: you just need to parse it in commit.c, generate it in git-commit-tree (with an option), and pull it in pull.c, and everything should work as far as making the git portion follow the metadata around. -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: Storing state in $GIT_DIR
Martin Langhoff <[EMAIL PROTECTED]> writes: >> In other words, if you just have a "last commit" pointer in your >> meta-data, then git is _by_definition_ in sync. There's never anything to >> get out of sync, because objects aren't going to change. > > Hmmm. That repo is in sync, but there are no guarantees that they will > travel together to a different repo. In fact, the push/pull > infrastructure wants to push/pull one head at a time. Wrong as of last week ;-), and definitely wrong since this morning. > And if they are not in sync, I have no way of knowing. Hmpf. I lie: > the arch metadata could keep track of what it expects the last head > commits to be, and complain bitterly if something smells rotten. What Linus suggests is doable by using an object that can hold a pointer to at least one commit---you used that to record the head commit of the corresponding git branch that the arch metainfo represents. You only pull arch metainfo branch; the objects associated with the corresponding git branch head will be pulled together when you pull it. You do not have to tell git to pull git-part of the commit chain. There is no need to worry about version skew when you use git this way. Now, among the existing object types, there are only two kinds of objects you can use for this. If the only thing you need to record is some textual information with one pointer to git branch head, then you can use tag that points at the git head, and store everything else as the tag comment. This is doable but unwieldy. You could abuse a commit object as well; you store commit objects (such as the corresponding git branch head) as parent commits, and put everything else in a tree that is associated with that commit. - 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: Storing state in $GIT_DIR
On 8/26/05, Linus Torvalds <[EMAIL PROTECTED]> wrote: > > OTOH, storing the metadata in a branch will allow us to run the import > > in alternating repositories. But as Junio points out, unless I can > > guarantee that the metadata and the tree are in sync, I cannot > > trivially resume the import cycle from a new repo. > > But you can. > > Remember: the metadata is the pointers to the original git conversion, and > objects are immutable. > > In other words, if you just have a "last commit" pointer in your > meta-data, then git is _by_definition_ in sync. There's never anything to > get out of sync, because objects aren't going to change. Hmmm. That repo is in sync, but there are no guarantees that they will travel together to a different repo. In fact, the push/pull infrastructure wants to push/pull one head at a time. And if they are not in sync, I have no way of knowing. Hmpf. I lie: the arch metadata could keep track of what it expects the last head commits to be, and complain bitterly if something smells rotten. let me think about it ;) 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: Merges without bases
On Thu, 25 Aug 2005, Junio C Hamano wrote: > One thing that makes me reluctant to recommend this "merging > unrelated projects" business is that I suspect that it makes > things _much_ harder for the upstream project that is being > merged, and should not be done without prior arrangement; Linus > merged gitk after talking with paulus, so that was OK. I'd still like to revive my idea of having projects overlaid on each other, where the commits in the project that absorbed the other project say, essentially, "also include this other commit, but any changes to those files belong to that branch, not this one". That way, Linus could have included gitk in git, but changes to it, even when done in a git working tree, would show up in commits that only include gitk. (git actually can handle this with the alternative index file mechanism that Linus mentioned in a different thread.) Definitely post-1.0, of course. > Suppose the above "My Project" is published, people send patches > for core GIT part to it, and you as the maintainer of that "My > Project" accept those patches. The users of "My Project" would > be happy with the new features and wouldn't care less where > their core GIT tools come from. But how would _I_ pull from > that "My Project", if I did not want to pull unrelated stuff in? With the right info, the tools could be made to automatically generate suitable commits, because those files would be tracked by a separate index file and committed into a separate branch, which would then be reincluded (by reference) in the containing project. -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: Storing state in $GIT_DIR
On Fri, 26 Aug 2005, Martin Langhoff wrote: > > OTOH, storing the metadata in a branch will allow us to run the import > in alternating repositories. But as Junio points out, unless I can > guarantee that the metadata and the tree are in sync, I cannot > trivially resume the import cycle from a new repo. But you can. Remember: the metadata is the pointers to the original git conversion, and objects are immutable. In other words, if you just have a "last commit" pointer in your meta-data, then git is _by_definition_ in sync. There's never anything to get out of sync, because objects aren't going to change. So you can think of your meta-data as a strange kind of head ref. Or rather, a _collection_ of these strange refs. And it doesn't matter if somebody ends up committing on top of an arch import. The metadata by definition doesn't know about it, so the "import" head doesn't move anywhere (if you do git and arch work in parallell, you can then merge the two heads with git, of course). 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
[PATCH] Accept -m and friends for initial commits and merge commits.
Yes it was irritating.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
Linus Torvalds <[EMAIL PROTECTED]> writes:
> [ Junio, the fact that you can't script the initial commit with "git
> commit" is _really_ irritating. ]
git-commit-script | 86 -
1 files changed, 39 insertions(+), 47 deletions(-)
c038244ac9260c8c895bf791ff587103bacadaba
diff --git a/git-commit-script b/git-commit-script
--- a/git-commit-script
+++ b/git-commit-script
@@ -110,57 +110,51 @@ t)
fi
esac
+if [ ! -r "$GIT_DIR/HEAD" ]
+then
+ echo "#"
+ echo "# Initial commit"
+ echo "#"
+ git-ls-files | sed 's/^/# New file: /'
+ echo "#"
+elif [ -f "$GIT_DIR/MERGE_HEAD" ]; then
+ echo "#"
+ echo "# It looks like your may be committing a MERGE."
+ echo "# If this is not correct, please remove the file"
+ echo "# $GIT_DIR/MERGE_HEAD"
+ echo "# and try again"
+ echo "#"
+fi >.editmsg
+if test "$log_message" != ''
+then
+ echo "$log_message"
+elif test "$logfile" != ""
+then
+ if test "$logfile" = -
+ then
+ test -t 0 &&
+ echo >&2 "(reading log message from standard input)"
+ cat
+ else
+ cat <"$logfile"
+ fi
+elif test "$use_commit" != ""
+then
+ git-cat-file commit "$use_commit" | sed -e '1,/^$/d'
+fi | git-stripspace >>.editmsg
+
PARENTS="-p HEAD"
if [ ! -r "$GIT_DIR/HEAD" ]; then
if [ -z "$(git-ls-files)" ]; then
echo Nothing to commit 1>&2
exit 1
fi
- {
- echo "#"
- echo "# Initial commit"
- case "$no_edit" in
- t) echo "# (ignoring your commit message for initial commit)"
- no_edit=
- esac
- echo "#"
- git-ls-files | sed 's/^/# New file: /'
- echo "#"
- } >.editmsg
PARENTS=""
- no_edit=
else
if [ -f "$GIT_DIR/MERGE_HEAD" ]; then
- {
- echo "#"
- echo "# It looks like your may be committing a MERGE."
- echo "# If this is not correct, please remove the file"
- echo "# $GIT_DIR/MERGE_HEAD"
- echo "# and try again"
- case "$no_edit" in
- t) echo "# (ignoring your commit message for merge commit)"
- no_edit=
- esac
- echo "#"
- } |
- git-stripspace >.editmsg
PARENTS="-p HEAD -p MERGE_HEAD"
- elif test "$log_message" != ''
- then
- echo "$log_message" |
- git-stripspace >.editmsg
- elif test "$logfile" != ""
- then
- if test "$logfile" = -
- then
- test -t 0 &&
- echo >&2 "(reading log message from standard input)"
- cat
- else
- cat <"$logfile"
- fi |
- git-stripspace >.editmsg
- elif test "$use_commit" != ""
+ fi
+ if test "$use_commit" != ""
then
pick_author_script='
/^author /{
@@ -188,22 +182,20 @@ else
export GIT_AUTHOR_NAME
export GIT_AUTHOR_EMAIL
export GIT_AUTHOR_DATE
- git-cat-file commit "$use_commit" |
- sed -e '1,/^$/d' |
- git-stripspace >.editmsg
fi
-
case "$signoff" in
t)
git-var GIT_COMMITTER_IDENT | sed -e '
s/>.*/>/
- s/^/Signed-off-by: /' >>.editmsg ;;
+ s/^/Signed-off-by: /
+ ' >>.editmsg
+ ;;
esac
git-status-script >>.editmsg
fi
if [ "$?" != "0" -a ! -f $GIT_DIR/MERGE_HEAD ]
then
- cat .editmsg
+ sed -ne '/^#/p' .editmsg
rm .editmsg
exit 1
fi
-
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: Storing state in $GIT_DIR
On 8/26/05, Junio C Hamano <[EMAIL PROTECTED]> wrote: > If I am not mistaken, we have another foreign SCM import > interface that can repeatedly slurp from the same foreign SCM to > get updates. Doesn't cvsimport have the same issue? Yes and no. cvsimport uses cvsps which uses in ~/.cvsps as a cache. Other than that, all the info is transient - cvsimport doesn't need to know that much about past commits -- when it sees BRANCH_A_A1 open from BRANCH_A it opens a new head BRANCH_A_A1 with the parent in the _latest_ BRANCH_A. This is a bug/limitation that only hits you when you are tracking an evolving cvs project, because cvsps will otherwise mark the branching point in order, right after the 'correct' commit. IOW cvsimport gets it kind-of-right most of the time due to cvsps behaviour and sheer luck, but doesn't do it strictly right either. With Arch, we cannot even fake it. We see the branch in its own time, and it can branch off any point in the source branch history. We have the correct parent information -- it'd be silly to drop it. All we have to do, is map the parents correctly... 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: Storing state in $GIT_DIR
Linus, I like the solution you are suggesting, but I suspect it will create more problems that it will solve, and while the coolness factor is drawing me in we ain't gonna need it, as the xp people say. More below... On 8/26/05, Linus Torvalds <[EMAIL PROTECTED]> wrote: > Git won't care, so it will work, but things like clone/pull etc also won't > actually ever look there, so it will only work for that one repo. Storing things there _works_ in the sense that it will be ignored, and that is fine with me. So I could just be lazy and have it strictly tied to the repo. In practice, if you are tracking an external Arch repo, you really have it scripted, and use a dedicated git repo for that. Not using a dedicated repo is quite... messy. If you do other things in that particular repo, the import script may find it dirty, and mess things up on import. And after the import, you'll probably run git-push-script --all because it's bringing a dynamically growing forest of heads from the arch repo. That's another reason why your private branches should be elsewhere. OTOH, storing the metadata in a branch will allow us to run the import in alternating repositories. But as Junio points out, unless I can guarantee that the metadata and the tree are in sync, I cannot trivially resume the import cycle from a new repo. > The git solution to this (which nobody has ever _used_, but which > technically is wonderful) is to have a "side branch" that does not share > any commits (or files, for that matter) in common with the "real branch", > and which is used to track any metadata. In fact, you can obviously have > any number of side branches. A couple of days ago, playing with the import, I realised that the git repo can hold unrelated projects, too, if you just commit orphan trees as new heads. I mean - it was a bug in my script but I thought it was cool. ;) > The way to maintain a metadata branch is to have not only a different > branch name (obviously), but also use a totally different index file, so > that you can index both branches in parallell, and you don't actually need > to check out one or the other. Hmmm. Now that's voodoo magic! I was thinking of reading the file by asking directly for the object by its sha, or doing a checkout in a tmpdir. Interesting. 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
[PATCH] Enable git-send-email-script on Debian.
You can define WITH_SEND_EMAIL to include the send-email command as part of the installation. Since Debian, unlike RPM/Fedora, has the two necessary Perl modules available as part of the mainline distribution, there is no reason for us to shy away from shipping send-email. Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]> --- *** How do you like this one, Ryan? Yes I know that we should *** not be using the same "0.99.5-" with different package *** version to ship changes in the upsteram file (Makefile) *** like this, but that aside... Makefile |5 - debian/changelog |7 +++ debian/rules |3 +++ 3 files changed, 14 insertions(+), 1 deletions(-) 32fa6df832a1dc9ed0a1388dbe11a16b236683d5 diff --git a/Makefile b/Makefile --- a/Makefile +++ b/Makefile @@ -69,7 +69,6 @@ SCRIPTS=git git-apply-patch-script git-m git-request-pull-script git-bisect-script SCRIPTS += git-count-objects-script -# SCRIPTS += git-send-email-script SCRIPTS += git-revert-script SCRIPTS += git-octopus-script @@ -87,6 +86,10 @@ PROG= git-update-cache git-diff-files git-show-index git-daemon git-var git-peek-remote git-show-branch \ git-update-server-info git-show-rev-cache git-build-rev-cache +ifdef WITH_SEND_EMAIL +SCRIPTS += git-send-email-script +endif + ifndef NO_CURL PROG+= git-http-pull endif diff --git a/debian/changelog b/debian/changelog --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +git-core (0.99.5-1) unstable; urgency=low + + * Enable git-send-email-script on Debian. There is no reason to shy +away from it, since we have the necessary Perl modules available. + + -- Junio C Hamano <[EMAIL PROTECTED]> Thu, 25 Aug 2005 14:16:59 -0700 + git-core (0.99.5-0) unstable; urgency=low * GIT 0.99.5 diff --git a/debian/rules b/debian/rules --- a/debian/rules +++ b/debian/rules @@ -25,6 +25,9 @@ else export MOZILLA_SHA1=YesPlease endif +# We do have the requisite perl modules in the mainline, and +# have no reason to shy away from this script. +export WITH_SEND_EMAIL=YesPlease PREFIX := /usr MANDIR := /usr/share/man/ - 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: cache status after git pull
"Luck, Tony" <[EMAIL PROTECTED]> writes: > What I want is to get the latest from kernel.org...linus...master > and update my .refs/heads/linus with the new SHA1. > > I'd like to be able to do that without touching what is in my > index, and without changing the state of any checked out files. > > If that is what the above does,... At least that is how "git fetch :" is designed to work, and "Pull: :" in a remotes/ shorthand is designed to reduce typing while doing so. Please bug me if things do not work as advertised. - 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] Fix pulling into the same branch.
Earlier, I said: Subject: Re: cache status after git pull Date: Thu, 25 Aug 2005 13:26:07 -0700 Message-ID: <[EMAIL PROTECTED]> > 1) Updated my "linus" branch: > > $ git checkout linus && git pull linus The second command, "git pull linus", would internally run "git fetch linus". It depends on how your shorthand "linus" is defined, but if it is set to update (either overwrite or fast-forward) the "linus" branch head, then your HEAD pointer would be updated without updating the index and working tree. This is bad because now you are telling git that your working tree is based on updated "linus" branch head, and what you _could_ commit on top of it is the same thing as what old "linus" branch head commit used to have. That's why "git status" output shows the minefield. If I keep copies of foreign brahches in $GIT_DIR/refs/heads/ somewhere, I never checkout those branches in my working tree. I always stay in my branches to do my work. I may "diff" against them to see where I am. Of course I would "resolve" with them when I feel I am ready. So, assuming that "linus" short-hand is set up to update $GIT_DIR/refs/heads/linus with the foreign branch head, the above example would have been: $ git checkout master && git pull linus : examine diffs and be convinced what Linus does is always right. This "do not pull into the branch you are on" is probably a good advice as a workaround, but there is no fundamental reason to forbid it. Worse, there is no machinery to even warn about the situation right now. This patch is to show my current thinking. Please let me know what you think. -jc When the "git pull" command updates the branch head you are currently on, before doing anything else, first update your index file and the working tree contents to that of the new branch head. Otherwise, the later resolving steps would think your index file is attempting to revert the change between the original head commit and the updated head commit. It uses two-tree fast-forward form of "read-tree -m -u" to prevent losing whatever local changes you may have in the working tree to do this update. I think this would at least make things safer (a lot safer), and prevent mistakes. Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]> --- git-pull-script | 18 ++ 1 files changed, 18 insertions(+), 0 deletions(-) 10f624a7743fc1e29277de9875dbd6a882f2d3b3 diff --git a/git-pull-script b/git-pull-script --- a/git-pull-script +++ b/git-pull-script @@ -5,7 +5,25 @@ # Fetch one or more remote refs and merge it/them into the current HEAD. . git-sh-setup-script || die "Not a git archive" + +orig_head=$(cat "$GIT_DIR/HEAD") || die "Pulling into a black hole?" git-fetch-script "$@" || exit 1 + +curr_head=$(cat "$GIT_DIR/HEAD") +if test "$curr_head" != "$orig_head" +then + # The fetch involved updating the current branch. + + # The working tree and the index file is still based on the + # $orig_head commit, but we are merging into $curr_head. + # First update the working tree to match $curr_head. + + echo >&2 "Warning: fetch updated the current branch head." + echo >&2 "Warning: fast forwarding your working tree." + git-read-tree -u -m "$orig_head" "$curr_head" || + die "You need to first update your working tree." +fi + merge_head=$(sed -e 's/.*//' "$GIT_DIR"/FETCH_HEAD | tr '\012' ' ') merge_name=$(sed -e 's/^[0-9a-f]* //' "$GIT_DIR"/FETCH_HEAD | tr '\012' ' ') - 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: Merges without bases
On Thu, 2005-08-25 at 15:26 -0700, Junio C Hamano wrote: > empty=`GIT_INDEX_FILE=.no-such-file git-write-tree` > git-read-tree -m -u $empty $head $foreign || o. Tricky. Thanks for the script. That's a bad, bad hack. :-) > One thing that makes me reluctant to recommend this "merging > unrelated projects" business is that I suspect that it makes > things _much_ harder for the upstream project that is being > merged, and should not be done without prior arrangement; Linus > merged gitk after talking with paulus, so that was OK. > What I'm going to do is actually an inversion of that. Publishing a repository with the _intent_ of being merged into existing history, and observing obvious naming conventions as the "prior arrangement". I thought once I got the initial baseless merges done and committed that I do fetch-octopus from that point on. But octopus was still complaining about not finding a merge base. I'm going to verify that I didn't just mess something up in the process. If I can get octopus working as the tool for doing merges _after_ the baseless merges then I can live with the current situation. -- Darrin - 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: Merges without bases
Darrin Thompson <[EMAIL PROTECTED]> writes: > I have a weird situation I want to support. I want to be able to merge a > foreign-tree repeatedly. > > What makes the foreign tree foreign is that it may not yet share any > history with this branch. I believe that's exactly what Linus did when he merged gitk into git. As you discovered, the initial one could easily be scripted, if you wanted to, with something like this: #!/bin/sh # # git-merge-projects-script # . git-sh-setup-script || die "Not a git archive." foreign_project="$1" head=`git-rev-parse --verify HEAD` && foreign=`git-rev-parse --verify $foreign_project^0` || exit rm -f .no-such-file empty=`GIT_INDEX_FILE=.no-such-file git-write-tree` git-read-tree -m -u $empty $head $foreign || git-merge-cache -o git-merge-one-file-script -a || exit tree=`git-write-tree` && echo Merge $foreign_project in. | git-commit-tree $tree -p $head -p $foreign \ >"$GIT_DIR/HEAD" && git show-branch --more=10 HEAD $foreign_project Unlike my other "scripts written in e-mail buffer", I actually tested this one ;-). $ cd /var/tmp && rm -fr junk && mkdir junk $ cd /var/tmp/junk $ git init-db $ cat >./git-merge-projects-script : type the above and end with ^D $ chmod +x git-merge-projects-script $ git add git-merge-projects-script $ git commit -m 'My Project' $ git fetch http://www.kernel.org/pub/scm/git/git.git master:git $ ./git-merge-projects-script git $ git diff git..HEAD The "weird" situation to cause "git resolve" barf happens only for the first time and once they are merged you can repeatedly pull from that subset foreign branch without any "weirdo" support. Since even the oddball initial case can easily be scripted like above, and that initial case should happen very very rarely anyway, I do not think this deserves any core-level change, such as changes to read-tree you suggest. The above merge-projects-script _may_ deserve a "contrib" status to be in the source tree, though. One thing that makes me reluctant to recommend this "merging unrelated projects" business is that I suspect that it makes things _much_ harder for the upstream project that is being merged, and should not be done without prior arrangement; Linus merged gitk after talking with paulus, so that was OK. Suppose the above "My Project" is published, people send patches for core GIT part to it, and you as the maintainer of that "My Project" accept those patches. The users of "My Project" would be happy with the new features and wouldn't care less where their core GIT tools come from. But how would _I_ pull from that "My Project", if I did not want to pull unrelated stuff in? In this particular example, it only has git-merge-projects script which _is_ related to core GIT so this objection would not apply, but if I were paulus (gitk maintainer whose project has only one file, the great gitk script) and if the git.git repository had a lot of changes to gitk, I would like to pick up updates from there without pulling the rest of core GIT. That is not something the current set of tools support, and offhand I do not think of a good way to implement it cleanly. That is the reason why I never pick up any patch for gitk myself --- I always slurp changes to gitk via paulus tree, or feed patches to him and then slurp the changes from him. What I think _might_ deserve a bit more support would be a merge of a foreign project as a subdirectory of a project. Linus could have made gitk/ subdirectory in the core git project, and made that subtree in sync with the toplevel of paulus gitk project. But even this could be done without the core-level change. You would run ls-tree of the main project to figure out the tree object name of that subdirectory, and 3-way merge that with the top of the paulus project tree, and replace the tree entry with the resulting tree. Once that kind of "merging an unrelated project as a subdirectory of a superproject" workflow is established, pulling from a subdirectory that corresponds to my project after my project gets merged this way into the superproject would become easier to manage and would even become a useful workflow element. - 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] undo and redo
On Thu, Aug 25, 2005 at 04:09:29PM -0500, Kirby C. Bohling wrote: > I guess I can see that. I just see it as much easier to manage > multiple undo-redo states manually. I mean, I wouldn't make anyone > use git directly if the difference between the two commands bothers > them. git seems too low a level. I would think one of the > procelains would be be a better level. However, having a unified > interface for all the porcelains seems a reasonable request. Maybe Porcelain is the right place for it. The question would be "Is it important that porcelains handle undo/redo in a way that interoperates?" > > > > Is there something wrong with having flexibility? It seems most of the > > criticism of this feature is that there is already a way to accomplish > > what I want to do. Tools that can't be used flexibly are not tools that > > I like to use. Heck, I'm on UNIX aren't I? > > > > Oops, sorry for the rant. I'm really not in a bad mood... really. I > > hope it didn't sound like that :-). Oh, and I didn't mean to suggest > > that git is not flexible in other regards. I think its great! Moving > > along... > > > > > Assuming your patch creation and application tools capture all the > > > meta-data the SCM has (which I believe git does), it's pretty simple > > > to simulate what you want manaully. With only a handful of > > > commands. > > > > I can simulate git manually too with just a few more commands. Where's > > the cutoff? This analogy *was* a bit extreme. Cheers, Carl -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Carl BaldwinSystems VLSI Laboratory Hewlett Packard Company MS 88 work: 970 898-1523 3404 E. Harmony Rd. work: [EMAIL PROTECTED] Fort Collins, CO 80525 home: [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 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: Merges without bases
That didn't come out clearly. Restating: On Thu, 2005-08-25 at 16:10 -0500, Darrin Thompson wrote: > Could git-read-tree -m 3-args be made smart enough to treat a 0 as arg 1 > as an implicit empty tree? > Could git-read-tree -m treat an argument of "0" as an implicit empty tree? It mainly seems useful as the first arg in the three arg -m form. > Once that is done, git octopus will be able to handle the no merge base > case. > Once that is done, git octopus could _optionally_ handle the "I can't find a merge base" case by passing 0 as the merge base to git-read-tree. -- Darrin - 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] undo and redo
On Thu, Aug 25, 2005 at 03:49:30PM -0500, Kirby C. Bohling wrote: > On Thu, Aug 25, 2005 at 01:19:05PM -0700, Junio C Hamano wrote: > > "Kirby C. Bohling" <[EMAIL PROTECTED]> writes: > Just out of curiosity, why isn't the SHA1 of 'A' part of the > diff or patch format? I mean it can't be that hard to add it as a > single line of data that git can parse to extract that piece of > information. Then a patch would enable you to do the 3-way merge > you describe. If added properly "regular" patch would just ignore > that line. The patch would then record that it is relative to 'A'. Not a bad idea. It could be ignored in most cases and used when needed. Carl > Assuming git could be taught "git-merge-patch" and then take use > the patch that's saved during the "undo" step and has the anchor for > the patch to use as the pivot point (as described above). Life > should be good. There are probably corner cases I don't understand, > but it sure looks like if you have the pivot or anchor point for the > patch embedded in the patch, you have all the needed information to > pull this off. > > I would think this would be generally useful outside of the > context of "undo/redo" also. > > Kirby > > -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Carl BaldwinSystems VLSI Laboratory Hewlett Packard Company MS 88 work: 970 898-1523 3404 E. Harmony Rd. work: [EMAIL PROTECTED] Fort Collins, CO 80525 home: [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 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] undo and redo
On Thu, Aug 25, 2005 at 02:37:33PM -0600, Carl Baldwin wrote: > On Thu, Aug 25, 2005 at 02:59:18PM -0500, Kirby C. Bohling wrote: > > On Thu, Aug 25, 2005 at 10:32:01AM -0600, Carl Baldwin wrote: > > > > > Another example is if I'm working on a commit and suddenly get a > > > brilliant idea for some easy modification that I want to make and commit > > > by itself before making this commit. I can do this easily with > > > > > > % git undo > > > % carefully make easy change > > > % git commit > > > % git redo > > > > > > Having a light-weight alternative like this could make the difference > > > between realizing the easy, brilliant idea and forgetting about it on > > > the back burner because it was just too cumbersome to make the context > > > switch. > > > > > > The bottom line is that I don't argue against using the existing > > > work-flows. I hope to add the flexibility to use various work-flows to > > > fit the job at hand. > > > > > > > > > [Not much of a git user, but am evaluating it for possible future > > usage]... > > > > Why not just save the changes to a file via a patch. Just like you > > would if you were sending a patch to someone else. I have the work > > flow you are talking about when I use CVS. I just create a patch, > > apply the patch in reverse (or run the command to get you a clean > > working tree in the SCM). Make my unrelated changes commit it. > > Then apply the patch, possibly resolve merge conflicts, and proceed > > with finishing my original work. > > I used to do this with CVS too. For you and me, people who are patch > savy veterans, this is great! However, as easy as it is I knew very few > other developers who even thought about doing it. In the real world, > many people see a huge difference between: > > git diff-cache > $patchfile > cat $patchfile | patch -R -p1 > do work > cat $patchfile | patch -p1 > > AND > > git undo > do work > git redo > > The first one simply never happens with most developers. Most don't > really think of doing something outside the tool. The second option > will likely get used. Plus, I know at least one person here who is very > good with patches and working outside the tool and still would love to > have the second approach available. I guess I can see that. I just see it as much easier to manage multiple undo-redo states manually. I mean, I wouldn't make anyone use git directly if the difference between the two commands bothers them. git seems too low a level. I would think one of the procelains would be be a better level. However, having a unified interface for all the porcelains seems a reasonable request. > > Is there something wrong with having flexibility? It seems most of the > criticism of this feature is that there is already a way to accomplish > what I want to do. Tools that can't be used flexibly are not tools that > I like to use. Heck, I'm on UNIX aren't I? > > Oops, sorry for the rant. I'm really not in a bad mood... really. I > hope it didn't sound like that :-). Oh, and I didn't mean to suggest > that git is not flexible in other regards. I think its great! Moving > along... > > > Assuming your patch creation and application tools capture all the > > meta-data the SCM has (which I believe git does), it's pretty simple > > to simulate what you want manaully. With only a handful of > > commands. > > I can simulate git manually too with just a few more commands. Where's > the cutoff? Yes and no. I meant the order and style of commands was nearly identical. I meant applying the command line in reverse was the only additional step. As a workflow, I'd just document it in the HOWTO's. I'm a minimalist in that sense. Sure, I use more then echo, redirection and netcat even though in theory I could send you this e-mail with it. IMHO, the above undo/redo doesn't seem to save enough effort to me. I wouldn't bother learning undo/redo unless it was superior to the patch way, it's just one more thing I'd have to remember. > > > I see the appeal of not having manually deal with the files, but > > assuming you don't feel it's branch worthy, and you don't want to > > have it be something someone else can access externally, it doesn't > > seem like a feature I can't get almost as simply with existing git > > commands. > > Not having to manually manage a set of patches may seem small but it > reduces a barrier that may otherwise be just high enough to hurt > productivity in certain situations. I don't mean to discourge it's implementation, I really questioned it because I figured there had to be some more subtle implications I didn't understand about undo/redo that patch couldn't capture. It also seems like multiple levels of undo/redo or undo/redo on multiple branches could get tricky for the user to track and for git to be able to display the information to the user sanely. Thanks, Kirby - To unsubscribe from this list: send the line "u
Re: [RFC] undo and redo
On Thu, Aug 25, 2005 at 01:19:05PM -0700, Junio C Hamano wrote: > "Kirby C. Bohling" <[EMAIL PROTECTED]> writes: > > > I guess my final question is what does undo/redo have over saving > > stuff away in a patch assuming that the patch captures all of the > > SCM meta-data (the add/move/remove file type commands). If git > > doesn't capture all the meta-data in a patch, it would seem better > > to make it do that and get this as a side-affect. > > One thing that Carl's undo saves that is not easily available in > the patch form is the "what is this patch based on" information. > If you had it, you could do a three-way merge instead of patch > application. > You were at A (time flows from left to right) when somebody > (maybe your bright idea) interrupted you. You take a snapshot > of your tree state D as a pair , and rewind the tree to > original commit A's state: > > -->A > \ > D > > Then you do the work that interrupted you, maybe making commits > B and then C: > > -->A-->B-->C > \ > D > > At this point, you would want to restart working on whatever you > were doing, which is the difference between A->D applied on top > of C. > > You could keep that information as a patch between A->D and > apply it on top of C to get there, which is your approach if I > am reading you correctly. Carl does a three-way merge between C > and D using A as the pivot point. Just out of curiosity, why isn't the SHA1 of 'A' part of the diff or patch format? I mean it can't be that hard to add it as a single line of data that git can parse to extract that piece of information. Then a patch would enable you to do the 3-way merge you describe. If added properly "regular" patch would just ignore that line. The patch would then record that it is relative to 'A'. Assuming git could be taught "git-merge-patch" and then take use the patch that's saved during the "undo" step and has the anchor for the patch to use as the pivot point (as described above). Life should be good. There are probably corner cases I don't understand, but it sure looks like if you have the pivot or anchor point for the patch embedded in the patch, you have all the needed information to pull this off. I would think this would be generally useful outside of the context of "undo/redo" also. Kirby - 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: cache status after git pull
>To set up "linus" short-hand to be updated with "master" branch >head from Linus, you would do one of the following: > > * Using new style shorthand > >$ cat >$GIT_DIR/remotes/linus \ >URL: http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ >Pull: master:linus >$ git fetch linus This sounds like it does what I want ... so I'd like to confirm before wiring this into my scripts and fingers. What I want is to get the latest from kernel.org...linus...master and update my .refs/heads/linus with the new SHA1. I'd like to be able to do that without touching what is in my index, and without changing the state of any checked out files. If that is what the above does, then you are my hero for today :-) -Tony - 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] undo and redo
On Thu, Aug 25, 2005 at 02:59:18PM -0500, Kirby C. Bohling wrote: > On Thu, Aug 25, 2005 at 10:32:01AM -0600, Carl Baldwin wrote: > > > Another example is if I'm working on a commit and suddenly get a > > brilliant idea for some easy modification that I want to make and commit > > by itself before making this commit. I can do this easily with > > > > % git undo > > % carefully make easy change > > % git commit > > % git redo > > > > Having a light-weight alternative like this could make the difference > > between realizing the easy, brilliant idea and forgetting about it on > > the back burner because it was just too cumbersome to make the context > > switch. > > > > The bottom line is that I don't argue against using the existing > > work-flows. I hope to add the flexibility to use various work-flows to > > fit the job at hand. > > > > > [Not much of a git user, but am evaluating it for possible future > usage]... > > Why not just save the changes to a file via a patch. Just like you > would if you were sending a patch to someone else. I have the work > flow you are talking about when I use CVS. I just create a patch, > apply the patch in reverse (or run the command to get you a clean > working tree in the SCM). Make my unrelated changes commit it. > Then apply the patch, possibly resolve merge conflicts, and proceed > with finishing my original work. I used to do this with CVS too. For you and me, people who are patch savy veterans, this is great! However, as easy as it is I knew very few other developers who even thought about doing it. In the real world, many people see a huge difference between: git diff-cache > $patchfile cat $patchfile | patch -R -p1 do work cat $patchfile | patch -p1 AND git undo do work git redo The first one simply never happens with most developers. Most don't really think of doing something outside the tool. The second option will likely get used. Plus, I know at least one person here who is very good with patches and working outside the tool and still would love to have the second approach available. Is there something wrong with having flexibility? It seems most of the criticism of this feature is that there is already a way to accomplish what I want to do. Tools that can't be used flexibly are not tools that I like to use. Heck, I'm on UNIX aren't I? Oops, sorry for the rant. I'm really not in a bad mood... really. I hope it didn't sound like that :-). Oh, and I didn't mean to suggest that git is not flexible in other regards. I think its great! Moving along... > Assuming your patch creation and application tools capture all the > meta-data the SCM has (which I believe git does), it's pretty simple > to simulate what you want manaully. With only a handful of > commands. I can simulate git manually too with just a few more commands. Where's the cutoff? > I see the appeal of not having manually deal with the files, but > assuming you don't feel it's branch worthy, and you don't want to > have it be something someone else can access externally, it doesn't > seem like a feature I can't get almost as simply with existing git > commands. Not having to manually manage a set of patches may seem small but it reduces a barrier that may otherwise be just high enough to hurt productivity in certain situations. > I guess my final question is what does undo/redo have over saving > stuff away in a patch assuming that the patch captures all of the > SCM meta-data (the add/move/remove file type commands). If git > doesn't capture all the meta-data in a patch, it would seem better > to make it do that and get this as a side-affect. > > Thanks, > Kirby Thanks for your comments. Carl -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Carl BaldwinSystems VLSI Laboratory Hewlett Packard Company MS 88 work: 970 898-1523 3404 E. Harmony Rd. work: [EMAIL PROTECTED] Fort Collins, CO 80525 home: [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 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: cache status after git pull
[EMAIL PROTECTED] writes: > Aha ... is this the problem that caught me out last week (when > I ended up with 10 extra files attached to one of my commits)? Plausible. > 1) Updated my "linus" branch: > > $ git checkout linus && git pull linus I would assume that just after "git checkout linus" before "git pull linus", running "git diff -r linus" would have said nothing. The second command, "git pull linus", would internally run "git fetch linus". It depends on how your shorthand "linus" is defined, but if it is set to update (either overwrite or fast-forward) the "linus" branch head, then your HEAD pointer would be updated without updating the index and working tree. This is bad because now you are telling git that your working tree is based on updated "linus" branch head, and what you _could_ commit on top of it is the same thing as what old "linus" branch head commit used to have. That's why "git status" output shows the minefield. If I keep copies of foreign brahches in $GIT_DIR/refs/heads/ somewhere, I never checkout those branches in my working tree. I always stay in my branches to do my work. I may "diff" against them to see where I am. Of course I would "resolve" with them when I feel I am ready. So, assumes that "linus" short-hand is set up to update $GIT_DIR/refs/heads/linus with the foreign branch head, the above example would have been: $ git checkout master && git pull linus : examine diffs and be convinced what Linus does is always right. If my "master" branch is not ready to merge from Linus but I want to get a feel of what is coming, I would instead do: : while staying on my master branch $ git fetch linus $ gitk linus master ;# or git show-branch linus master and later when my branch is ready, I would merge it into my master: : still staying on my master branch $ git pull . linus If you did the pull into your master but it turns out that the merge result is too messy, you could always reset (back to the first example): $ git checkout master && git pull linus : if merge failed... $ git reset --hard master $ git checkout master && git pull linus : merge succeeds, but I realize that my tree was not quite : ready to merge from linus -- going back to pre-merge state $ git reset --hard master^1 The rules for updating $GIT_DIR/refs/ when fetch happens have been extended and clarified in 0.99.5 quite a bit. To set up "linus" short-hand to be updated with "master" branch head from Linus, you would do one of the following: * Using old style shorthand $ echo >$GIT_DIR/branches/linus \ http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ $ git fetch linus * Using new style shorthand $ cat >$GIT_DIR/remotes/linus \ URL: http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ Pull: master:linus $ git fetch linus * From the command line, having either branches/linus or remotes/linus from the above two examples: $ git fetch linus master:linus To set up "linus" short-hand _not_ to update any local branch head (i.e. you only use "pull" to update your local branch, which can be named "linus" branch), you would do one of the following: * Using old style shorthand There is no way to do this using old style shorthand without an explicit command line . See the "From the command line" example below how to do this. * Using new style shorthand $ cat >$GIT_DIR/remotes/linus \ URL: http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ Pull: master: $ git fetch linus * From the command line, having either branches/linus or remotes/linus from the above two examples: $ git fetch linus master: - 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] undo and redo
"Kirby C. Bohling" <[EMAIL PROTECTED]> writes: > I guess my final question is what does undo/redo have over saving > stuff away in a patch assuming that the patch captures all of the > SCM meta-data (the add/move/remove file type commands). If git > doesn't capture all the meta-data in a patch, it would seem better > to make it do that and get this as a side-affect. One thing that Carl's undo saves that is not easily available in the patch form is the "what is this patch based on" information. If you had it, you could do a three-way merge instead of patch application. You were at A (time flows from left to right) when somebody (maybe your bright idea) interrupted you. You take a snapshot of your tree state D as a pair , and rewind the tree to original commit A's state: -->A \ D Then you do the work that interrupted you, maybe making commits B and then C: -->A-->B-->C \ D At this point, you would want to restart working on whatever you were doing, which is the difference between A->D applied on top of C. You could keep that information as a patch between A->D and apply it on top of C to get there, which is your approach if I am reading you correctly. Carl does a three-way merge between C and D using A as the pivot point. - 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] undo and redo
On Thu, Aug 25, 2005 at 10:32:01AM -0600, Carl Baldwin wrote: > Another example is if I'm working on a commit and suddenly get a > brilliant idea for some easy modification that I want to make and commit > by itself before making this commit. I can do this easily with > > % git undo > % carefully make easy change > % git commit > % git redo > > Having a light-weight alternative like this could make the difference > between realizing the easy, brilliant idea and forgetting about it on > the back burner because it was just too cumbersome to make the context > switch. > > The bottom line is that I don't argue against using the existing > work-flows. I hope to add the flexibility to use various work-flows to > fit the job at hand. > [Not much of a git user, but am evaluating it for possible future usage]... Why not just save the changes to a file via a patch. Just like you would if you were sending a patch to someone else. I have the work flow you are talking about when I use CVS. I just create a patch, apply the patch in reverse (or run the command to get you a clean working tree in the SCM). Make my unrelated changes commit it. Then apply the patch, possibly resolve merge conflicts, and proceed with finishing my original work. Assuming your patch creation and application tools capture all the meta-data the SCM has (which I believe git does), it's pretty simple to simulate what you want manaully. With only a handful of commands. I see the appeal of not having manually deal with the files, but assuming you don't feel it's branch worthy, and you don't want to have it be something someone else can access externally, it doesn't seem like a feature I can't get almost as simply with existing git commands. I guess my final question is what does undo/redo have over saving stuff away in a patch assuming that the patch captures all of the SCM meta-data (the add/move/remove file type commands). If git doesn't capture all the meta-data in a patch, it would seem better to make it do that and get this as a side-affect. Thanks, Kirby - 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 Thu, 25 Aug 2005, Jan Veldeman wrote: > Daniel Barkalow wrote: > > > I'm not sure how applicable to this situation stgit really is; I see stgit > > as optimized for the case of a patch set which is basically done, where > > you want to keep it applicable to the mainline as the mainline advances. > > Maybe I forgot to mention this: I would also like to have my development > tree split up in a patch stack. The separate patches makes tracking the > mainline a lot easier (conflicts are a lot easier to solve) I just try to keep things in this state sufficiently briefly that it doesn't become a problem. I also split things up into a bunch of branches, rather than into a stack of patches, and only work on parallel development before I've actually got a candidate for a series. > But this would assume that once the patch goes into stgit, it won't > change except when the parent gets updated. I think we will still change > the patches quite a bit and simultanious by a couple of people. The extension I had proposed to stgit should work for this; it would let you version control each patch just like other git projects. I just think it wouldn't work so well before the group has agreed on what patches there are. -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: [ANNOUNCE] GIT 0.99.5
On Wed, 2005-08-24 at 19:38 -0700, Junio C Hamano wrote: > * Update tutorial to cover shared repository style a bit more, > maybe with a toy project that involves two or three > repositories. > Shameless plug: Feel free to use/modify/steal my writeup: http://willowbend.cx/archives/2005/08/24/git-epiphany/ -- Darrin - 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] cogito -- add -c $commit support
Add -c parameter to cg-commit to set commit data based on prior commit.
This will then commit any changes using the author and message from the commit
specified. The actual logic for parsing the old commit values was taken from
git-commit-script.
git-commit-script supports this option via -C, which was already used in
cg-commit
for something else.
Signed-off-by: James Ketrenos <[EMAIL PROTECTED]>
---
cg-commit | 46 +-
1 files changed, 45 insertions(+), 1 deletions(-)
b07037397659763271e946fc15c0b3c61a8fcdfa
diff --git a/cg-commit b/cg-commit
--- a/cg-commit
+++ b/cg-commit
@@ -3,6 +3,8 @@
# Commit into a GIT repository.
# Copyright (c) Petr Baudis, 2005
# Based on an example script fragment sent to LKML by Linus Torvalds.
+#
+# -c commit based on code in git-commit-script by Linus Torvalds
#
# Commits changes to a GIT repository. Accepts the commit message from
# `stdin`. If the commit message is not modified the commit will be
@@ -45,6 +47,12 @@
# might not actually _have_ any object database. This option is
# normally not interesting.
#
+# -c::
+# Specifify the commit SHA to inherit the GIT_AUTHOR_* variables and
+# commit message from. The GIT_COMMITTER_* variables will not be
+# inherited from the specified commit. This option is typically used
+# when replaying commits from one lineage or repository to another.
+#
# FILES
# -
# $GIT_DIR/author::
@@ -112,6 +120,7 @@ ignorecache=
infoonly=
commitalways=
missingok=
+use_commit=
msgs=()
while optparse; do
if optparse -C; then
@@ -128,6 +137,8 @@ while optparse; do
force=1
elif optparse -m=; then
[EMAIL PROTECTED]"$OPTARG"
+ elif optparse -c=; then
+ use_commit="$OPTARG"
else
optfail
fi
@@ -196,6 +207,39 @@ for msg in "[EMAIL PROTECTED]"; do
echo "$msg" | fmt -s >>$LOGMSG
written=1
done
+
+if [ "$use_commit" ]; then
+ pick_author_script='
+ /^author /{
+ h
+ s/^author \([^<]*\) <[^>]*> .*$/\1/
+ s/'\''/'\''\'\'\''/g
+ s/.*/GIT_AUTHOR_NAME='\''&'\''/p
+
+ g
+ s/^author [^<]* <\([^>]*\)> .*$/\1/
+ s/'\''/'\''\'\'\''/g
+ s/.*/GIT_AUTHOR_EMAIL='\''&'\''/p
+
+ g
+ s/^author [^<]* <[^>]*> \(.*\)$/\1/
+ s/'\''/'\''\'\'\''/g
+ s/.*/GIT_AUTHOR_DATE='\''&'\''/p
+
+ q
+ }
+ '
+ set_author_env=`git-cat-file commit "$use_commit" |
+ sed -ne "$pick_author_script"`
+ eval "$set_author_env"
+ export GIT_AUTHOR_NAME
+ export GIT_AUTHOR_EMAIL
+ export GIT_AUTHOR_DATE
+ git-cat-file commit "$use_commit" |
+ sed -e '1,/^$/d'
+written=1
+fi >> $LOGMSG
+
# Always have at least one blank line, to ease the editing for
# the poor people whose text editor has no 'O' command.
[ "$written" ] || echo >>$LOGMSG
@@ -239,7 +283,7 @@ echo "CG: vim: textwidth=75" >>$LOGMSG
cp $LOGMSG $LOGMSG2
if tty -s; then
- if ! [ "$msgs" ] || [ "$forceeditor" ]; then
+ if ! ([ "$use_commit" ] || [ "$msgs" ]) || [ "$forceeditor" ]; then
${EDITOR:-vi} $LOGMSG2
if ! [ "$commitalways" ] && ! [ $LOGMSG2 -nt $LOGMSG ]; then
echo "Log message unchanged or not specified" >&2
[PATCH] Add -c parameter to cg-commit to set commit data based on prior commit.
This will then commit any changes using the author and message from the commit
specified. The actual logic for parsing the old commit values was taken from
git-commit-script.
git-commit-script supports this option via -C, which was already used in
cg-commit
for something else.
Signed-off-by: James Ketrenos <[EMAIL PROTECTED]>
---
cg-commit | 46 +-
1 files changed, 45 insertions(+), 1 deletions(-)
b07037397659763271e946fc15c0b3c61a8fcdfa
diff --git a/cg-commit b/cg-commit
--- a/cg-commit
+++ b/cg-commit
@@ -3,6 +3,8 @@
# Commit into a GIT repository.
# Copyright (c) Petr Baudis, 2005
# Based on an example script fragment sent to LKML by Linus Torvalds.
+#
+# -c commit based on code in git-commit-script by Linus Torvalds
#
# Commits changes to a GIT repository. Accepts the commit message from
# `stdin`. If the commit message is not modified the commit will be
@@ -45,6 +47,12 @@
# might not actually _have_ any object database. This option is
# normally not interesting.
#
+# -c::
+# Specifify the commit SHA to inherit the GIT_AUTHOR_* variables and
+# commit message from. The GIT_COMMITTER_* variables will not be
+# inherited from the specified commit. This option is typically used
+# whe
Re: Storing state in $GIT_DIR
[ Junio, the fact that you can't script the initial commit with "git commit" is _really_ irritating. ] On Thu, 25 Aug 2005, Martin Langhoff wrote: > > Is there a convention of where/how it is safe to store additional > (non-git) data in $GIT_DIR? There's no convention, but I have a suggestion. > The arch import needs to keep a cache with arch-commit-id = > git-commit-id mappings, and some notes about what patch-trading Arch > recorded. It'd be great to be able to store those in > $GIT_DIR/archimport/ . Is that supported? Git won't care, so it will work, but things like clone/pull etc also won't actually ever look there, so it will only work for that one repo. Now, I have what I consider a clever idea (I've mentioned variations on it before), but it's entirely possible that people hate it. The thing is, I think you _do_ want to revision-control the git-commit-id mappings, but at the same time, you do _not_ want to mess up the resulting git commit history with arch information. The reason you want to revision-control them is that that way you get them on clones, and you can use push/pull to update them. And the reason you don't want to mess up the commit history is that it's just wrong and ugly. The git solution to this (which nobody has ever _used_, but which technically is wonderful) is to have a "side branch" that does not share any commits (or files, for that matter) in common with the "real branch", and which is used to track any metadata. In fact, you can obviously have any number of side branches. So that "metadata branch" is a real git branch in its own right, but it doesn't share the same root as the "normal" branch, and it's really totally independent: you can pull just the main branch (ie somebody who isn't arch-aware and has no reason to want the arch mappings), or you could pull just the metadata branch (for example, somebody who doesn't want to use git, but is trying to match up a git commit ID to whatever ID's arch uses). The way to maintain a metadata branch is to have not only a different branch name (obviously), but also use a totally different index file, so that you can index both branches in parallell, and you don't actually need to check out one or the other. Now, your arch import tools would then use the raw git commands explicitly to maintain the metadata branch. Every time you do an incremental import from an arch project, your import scripts would save away the mapping information into the metadata branch. I'll make a _really_ stupid example for you, just to make this a bit more concrete: mkdir silly-example cd silly-example # # The normal "main branch": use regular git # infrastructure # git init-db echo "Hello" > file git update-cache --add file git commit -m "Main branch" # # The metadata branch: magic, very special stuff # echo "initial commit:" $(git-rev-parse HEAD) > .archdata GIT_INDEX_FILE=.git/archindex git-update-cache --add .archdata arch_index_tree=$(GIT_INDEX_FILE=.git/archindex git-write-tree) echo "arch index" | git-commit-tree $arch_index_tree > .git/refs/heads/arch-index (Btw, the above example shows that the initial "git commit" won't take a "-m" flag, which is really irritating for scripts.) Then do a "gitk --all", see the two different branches, and realize that the "arch-index" branch can now contain all the tracking information necessary to go back-and-forth. 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: [RFC] undo and redo
Carl Baldwin <[EMAIL PROTECTED]> writes: > For this, I may also use branching, as suggested. I meant for undo/redo > to be a lighter weight alternative to allow for a faster context switch. I have been missing the undo command since I started to use git, so I'll share a user's perspective. I was also considering undo as a really lightweight command, nothing too fancy. Usually, I want to try implement something wild or stupid, but almost immediately decide to abandon it. With 'git undo', this kind of prototyping would be really easy. For me, redo would be just a backup if (read: when) I undo something important, nothing more. For anything else I would use branches, as was suggested. -- Kalle Valo - 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] undo and redo
On Wed, Aug 24, 2005 at 10:06:45PM -0700, Junio C Hamano wrote: > > So, I've tried cloning, pulling to|from, pushing to|from and resolving > > merges in a repository with undo information stored under > > .git/refs/undo. None of these operations seem to notice the existence > > of this directory. I think this is good. > > What I meant was that, when "undo/bar" is a tree object, things > may work in a funny way: > > $ git pull ../repo-with-undo/.git refs/undo/bar > > $ git push ../other-repo/.git undo/bar:refs/heads/foo > $ cd ../other-repo && git resolve master foo 'Attempt to merge undo' I was thinking that undo trees should not be pushed and pulled between repositories. For this I would use a new branch with proper commits as Linus suggested. > I think this undo/redo first needs to be thought about how best > it is used. My guess is that the workflow you have in mind is > something like this: > > $ git checkout master > $ hack hack hack > # Hmph, it almost works, and but my boss says work on > # some other feature that is more urgent > $ git undo > Saved current state as 2005-08-24T20:32:22 > $ work work work > $ git commit -m 'Boring but urgent fix' > # Ok, now let's back to the thing I wanted to do. > $ git redo > # I happen to know it is the last undo, so I did not name > # it, but I could have said 2005-08-24T20:32:22 > $ hack more > $ git commit -m 'Finally fix frotz.' For this, I may also use branching, as suggested. I meant for undo/redo to be a lighter weight alternative to allow for a faster context switch. I am reluctant to commit what I have in my working directory unless I have taken the time to review the changes using diff tools and cleaned up considerably. This is my way of being a careful developer. Not all developers share my style but I know many that do. This makes committing a heavy weight operation for me. So, referring to your example. If my 'boss' says that I need to switch to working on 'Boring but urgent fix' for the next *week* or more I will likely take the time to make the full context switch to a new branch and work on the fix. I may also choose to just clone my repository and use a new working directory. If the fix takes just a day or two I may do the same. Now, let's say that the 'fix' is something that I can do in an hour or two and quickly get back to where I was. In this context, making the full context switch can feel very cumbersome compared to the amount of work required to make the fix. Now, a simple 'git undo' will ease this switch. Another example is if I'm working on a commit and suddenly get a brilliant idea for some easy modification that I want to make and commit by itself before making this commit. I can do this easily with % git undo % carefully make easy change % git commit % git redo Having a light-weight alternative like this could make the difference between realizing the easy, brilliant idea and forgetting about it on the back burner because it was just too cumbersome to make the context switch. The bottom line is that I don't argue against using the existing work-flows. I hope to add the flexibility to use various work-flows to fit the job at hand. [ stuff deleted ] > $ git checkout master > $ hack hack hack > # Hmph, it almost works, and but my boss says work on > # some other feature that is more urgent > $ git commit -m 'WIP - fix frotz' > $ git branch anchor-frotz > $ git reset --hard master^ > $ work work work > $ git commit -m 'Boring but urgent fix' > # Ok, now let's go back to the thing I wanted to do. > $ git pull . anchor-frotz > $ rm .git/heads/anchor-frotz > $ git reset --soft master^ > $ hack more > $ git commit -m 'Finally fix frotz.' Again, these are effective. I simply want to provide an alternative light weight way of accomplishing this. > The above flow would be something somebody not so organized > (like myself) would do. A perfect person would have done this: > > $ git checkout -b frotz master > $ hack hack hack > # Hmph, it almost works, and but my boss says work on > # some other feature that is more urgent > $ git commit -m 'WIP - fix frotz' > $ git checkout master > $ work work work > $ git commit -m 'Boring but urgent fix' > # Ok, now let's go back to the thing I wanted to do. > $ git checkout frotz > $ git reset --soft HEAD^ > $ hack more > $ git commit -m 'Finally fix frotz.' > $ git checkout master > $ git pull . frotz > $ rm .git/refs/heads/frotz > > The "perfect person" approach has an added benefit that you > could have made intermediate commits while doing "hacking", > because your hackery is always done in the "frotz" branch. > > Of course, the scenarios your undo/redo is useful for may not be > limited to this "handling interrupt" use case. If that is the > only
cache status after git pull
>* When the branch head pointed by $GIT_DIR/HEAD changes while > the index file and working tree are looking the other way > (e.g. somebody pushed into your repository, or you ran "git > fetch" to update the ref your working tree is on), "git > checkout" without -f gets confused. Figure out a good way to > handle this. Aha ... is this the problem that caught me out last week (when I ended up with 10 extra files attached to one of my commits)? At the time the blame was placed on a failed merge not being backed out correctly. But I only had the failed merge because "get checkout" had failed to switch branches (and not provided an exit code to stop my script from trying the merge). Here's what I did this morning. 1) Updated my "linus" branch: $ git checkout linus && git pull linus This appeared to work just fine ... except that when I check the status of my tree I see: $ git status # # Updated but not checked in: # (will commit) # # modified: arch/ia64/pci/pci.c # modified: arch/ppc64/kernel/setup.c # modified: arch/sparc64/kernel/pci.c # modified: arch/x86_64/defconfig # modified: drivers/block/cfq-iosched.c # modified: include/asm-m68k/page.h # modified: kernel/cpuset.c # # # On branch refs/heads/linus Which looks like a set of landmines just waiting for me to step on them! Today these didn't bite me. "git checkout release" worked and switched to my release branch (and git status went back to saying "nothing to commit"). But in the past I think this is the situation that has caused "git checkout" to fail with the "fatal: Entry 'blah' would be overwritten by merge. Cannot merge." -Tony - 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
Subject: [PATCH] More missing terms in glossary.txt
Describe a DAG and octopus, and change wording of tree object. Signed-off-by: Johannes Schindelin <[EMAIL PROTECTED]> --- Documentation/glossary.txt | 14 -- 1 files changed, 12 insertions(+), 2 deletions(-) e077919262930f6ce494c963d23317eb2aaf0dd3 diff --git a/Documentation/glossary.txt b/Documentation/glossary.txt --- a/Documentation/glossary.txt +++ b/Documentation/glossary.txt @@ -27,14 +27,20 @@ blob object:: tree object:: An object containing a list of file names and modes along with refs - to the associated blob and/or tree objects. A tree object is - equivalent to a directory. + to the associated blob and/or tree objects. A tree is equivalent + to a directory. tree:: Either a working tree, or a tree object together with the dependent blob and tree objects (i.e. a stored representation of a working tree). +DAG:: + Directed acyclic graph. The commit objects form a directed acyclic + graph, because they have parents (directed), and the graph of commit + objects is acyclic (there is no chain which begins and ends with the + same object). + index:: A collection of files with stat information, whose contents are stored as objects. The cache is a stored version of your working @@ -142,6 +148,10 @@ merge:: merge uses heuristics to accomplish that. Evidently, an automatic merge can fail. +octopus:: + To merge more than two branches. Also denotes an intelligent + predator. + resolve:: The action of fixing up manually what a failed automatic merge left behind. - 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] Gitk tree view (correction)
Hey, that's a nice one. Now I can easily go through my code without using the web interface. It would be nice if you could mark the lines that have changed in bold or whatever. It would also be nice, to add the current uncommitted working version as "newest revision". Stagger (Please CC me, as I'm not on the list) -- ___ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm - 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
Daniel Barkalow wrote: [...] > > The parents which should be visible to the outside, will always be versions > > of my development tree, which I have previously pushed out. My way of > > working would become: > > * make changes, all over the place, using stgit > > * still make changes (none of these gets tracked, intermittent versions are > > lost) > > * having a good day: changes looks good, I want to push this out: > > * push my tree out > > * stgit-free (which makes the pushed out commits, the new parents of my > > stgit patches) > > * restart from top > > I'm not sure how applicable to this situation stgit really is; I see stgit > as optimized for the case of a patch set which is basically done, where > you want to keep it applicable to the mainline as the mainline advances. Maybe I forgot to mention this: I would also like to have my development tree split up in a patch stack. The separate patches makes tracking the mainline a lot easier (conflicts are a lot easier to solve) > > For your application, I'd just have a git branch full of various stuff, > and then generate clean commits by branching mainline, diffing development > against it, cutting the diff down to just what I want to push, and > applying that. Then the clean patch goes into stgit. But this would assume that once the patch goes into stgit, it won't change except when the parent gets updated. I think we will still change the patches quite a bit and simultanious by a couple of people. > > > [...] > > my proposal does something like this, but a little more: not only does it > > keep track of the link between old-top and new-top, it also keeps track of > > the links between old-patch-in-between and new-patch-in-between. > > (This makes sense when the top is being removed or reordered) > > I was thinking of this as being the top and bottom commits for a single > tracked patch, not as a whole series. I think patches lower wouldn't be > affected, and patches higher would see this as a rebase. > ah, ok, I misunderstood that part Best regards, Jan PS. sorry if my responses are sometimes a bit late, I'm trying to find more time to spend on this list ;-) - 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] Looking at multiple ancestors in merge
Hi, Daniel Barkalow wrote:
> My proposal is actually to detect when a merge is ambiguous. In order to
> determine that, however, you have to evaluate multiple potential outcomes
> and see if they are actually different. I'm working on an efficient way to
> do that.
Good.
There's also a related problem which I've hit last month or so, where one
view has the same file (or at least one with the same name) added to both
sides of the branch, but the other view doesn't.
Unfortunately, that can happen to both branches independently, so you
really need to choose a merge base per file instead of globally. I suspect
that many of the problem cases simply go away when you do that.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Jones' Second Law:
The man who smiles when things go wrong has thought of someone
to blame it on.
-
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
