* Re: [RFC] git-split: Split the history of a git repository by subdirectories and ranges
From: Josh Triplett @ 2006-10-23 10:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlko5d3bx.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 3301 bytes --]
Junio C Hamano wrote:
> Josh Triplett <josh@freedesktop.org> writes:
>> Jamey Sharp and I wrote a script called git-split to accomplish this
>> repository split. git-split reconstructs the history of a sub-project
>> previously stored in a subdirectory of a larger repository. It
>> constructs new commit objects based on the existing tree objects for the
>> subtree in each commit, and discards commits which do not affect the
>> history of the sub-project, as well as merges made unnecessary due to
>> these discarded commits.
>
> Very nicely done.
Thanks!
>> We would like to acknowledge the work of the gobby team in creating a
>> collaborative editor which greatly aided the development of git-split.
>
>> from itertools import izip
>> from subprocess import Popen, PIPE
>> import os, sys
>
> How recent a Python are we assuming here? Is late 2.4 recent
> enough?
We ran it with 2.4, so yes. git-split does require at least 2.4,
though, because it uses set(), str.rsplit(), and subprocess, none of
which existed in 2.3.
>> def walk(commits, new_commits, commit_hash, project):
>> commit = commits[commit_hash]
>> if not(commit.has_key("new_hash")):
>> tree = get_subtree(commit["tree"], project)
>> commit["new_tree"] = tree
>> if not tree:
>> raise Exception("Did not find project in tree for commit " + commit_hash)
>> new_parents = list(set([walk(commits, new_commits, parent, project)
>> for parent in commit["parents"]]))
>>
>> new_hash = None
>> if len(new_parents) == 1:
>> new_hash = new_parents[0]
>> elif len(new_parents) == 2: # Check for unnecessary merge
>> if is_ancestor(new_commits, new_parents[0], new_parents[1]):
>> new_hash = new_parents[0]
>> elif is_ancestor(new_commits, new_parents[1], new_parents[0]):
>> new_hash = new_parents[1]
>> if new_hash and new_commits[new_hash]["new_tree"] != tree:
>> new_hash = None
>
> This is a real gem. I really like reading well-written Python
> programs.
Thanks. We had some fun writing this; git's elegant repository
structure made it a joy to work with.
> I wonder if using "git-log --full-history -- $project" to let
> the core side omit commits that do not change the $project (but
> still give you all merged branches) would have made your job any
> easier?
I don't think it would. We still need to know what commit to use as the
parent of any given commit, so we don't want commits in the log output
with parents that don't exist in the log output. And rewriting parents
in git-log based on which revisions change the specified subdirectory
seems like a bad idea.
> You are handling grafts by hand because --pretty=raw is special
> in that it displays the real parents (although traversal does
> use grafts). Maybe it would have helped if we had a --pretty
> format that is similar to raw but rewrites the parents?
Yes, that would help. We could then avoid dealing with grafts manually.
How would you feel about including git-split in the GIT tree? We could
certainly write up the necessary documentation for it.
- Josh Triplett
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.4.3.1
From: Jens Axboe @ 2006-10-23 11:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, linux-kernel
In-Reply-To: <7v4ptyi68s.fsf@assigned-by-dhcp.cox.net>
On Fri, Oct 20 2006, Junio C Hamano wrote:
> The latest maintenance release GIT 1.4.3.1 is available at the
> usual places:
>
> http://www.kernel.org/pub/software/scm/git/
>
> git-1.4.3.1.tar.{gz,bz2} (tarball)
> git-htmldocs-1.4.3.1.tar.{gz,bz2} (preformatted docs)
> git-manpages-1.4.3.1.tar.{gz,bz2} (preformatted docs)
> RPMS/$arch/git-*-1.4.3.1-1.$arch.rpm (RPM)
>
> This is primarily to work around changes in the recent GNU diff output
> format. Also it contains irritation fix for "git diff" which now
> paginates its output by default.
>
> ----------------------------------------------------------------
>
> Changes since v1.4.3 are as follows:
>
> Junio C Hamano (1):
> pager: default to LESS=FRS
It still behaves badly, git diff still shows my an empty pager waiting
for 'q', while LESS=FRS git diff works as desired.
git version 1.4.3.1.g87b78
--
Jens Axboe
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.4.3.1
From: Jens Axboe @ 2006-10-23 11:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, linux-kernel
In-Reply-To: <20061023113956.GN8251@kernel.dk>
On Mon, Oct 23 2006, Jens Axboe wrote:
> On Fri, Oct 20 2006, Junio C Hamano wrote:
> > The latest maintenance release GIT 1.4.3.1 is available at the
> > usual places:
> >
> > http://www.kernel.org/pub/software/scm/git/
> >
> > git-1.4.3.1.tar.{gz,bz2} (tarball)
> > git-htmldocs-1.4.3.1.tar.{gz,bz2} (preformatted docs)
> > git-manpages-1.4.3.1.tar.{gz,bz2} (preformatted docs)
> > RPMS/$arch/git-*-1.4.3.1-1.$arch.rpm (RPM)
> >
> > This is primarily to work around changes in the recent GNU diff output
> > format. Also it contains irritation fix for "git diff" which now
> > paginates its output by default.
> >
> > ----------------------------------------------------------------
> >
> > Changes since v1.4.3 are as follows:
> >
> > Junio C Hamano (1):
> > pager: default to LESS=FRS
>
> It still behaves badly, git diff still shows my an empty pager waiting
> for 'q', while LESS=FRS git diff works as desired.
Ah:
setenv("LESS", "FRS", 0);
axboe@nelson:/home/axboe/git/git $ echo $LESS
-M -I
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH 1/2] New stg command: assimilate
From: Catalin Marinas @ 2006-10-23 11:52 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Petr Baudis, git
In-Reply-To: <20061022181256.GA30295@diana.vm.bytemark.co.uk>
On 22/10/06, Karl Hasselström <kha@treskal.com> wrote:
> On 2006-10-22 19:43:08 +0200, Petr Baudis wrote:
>
> > Dear diary, on Sun, Oct 22, 2006 at 03:08:02PM CEST, I got a letter
> > where Karl Hasselström <kha@treskal.com> said that...
> >
> > > Introduce an "assimilate" command, with no options. It takes any
> > > GIT commits committed on top of your StGIT patch stack and
> > > converts them into StGIT patches.
> >
> > Hmm, isn't this what stg uncommit does?
> >
> > Well, I'm not sure if what uncommit takes is from below the stack or
> > above the stack, but if it's the former, it would still IMHO make
> > more sense to just tell that StGIT with a switch or something.
>
> Yes, you're correct in that uncommit and assimilate add existing
> commits to the StGIT stack, but in different ends: uncommit grows the
> stack by incorporating commits that precede it, while assimilate grows
> the stack by incorporating commits that follows it.
I think I also prefer a separate command for this as they have
slightly different goals and users could easily confuse the options of
a more powerful 'uncommit'.
--
Catalin
^ permalink raw reply
* Re: VCS comparison table
From: David Clymer @ 2006-10-23 11:56 UTC (permalink / raw)
To: Jakub Narebski
Cc: Matthew D. Fuller, Andreas Ericsson, Linus Torvalds, Carl Worth,
bazaar-ng, git
In-Reply-To: <200610222206.13973.jnareb@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2212 bytes --]
On Sun, 2006-10-22 at 22:06 +0200, Jakub Narebski wrote:
> David Clymer wrote:
> > 1. revnos don't work because they don't serve the same purpose as revids
> > or git's SHA1 commit ids.
> Revnos works only locally, or in star-topology configuration. They have
> some consequences: treating first parent specially, need for merges
> instead of fast-forward even if fast-forward would be applicable,
> two different "fetch" operators: "pull" (which uses revids on the
> pulled side) and "merge" (which preserves revids on pullee side).
s/revids/revnos/g but yes, I think I said this later in my previous
email.
>
> > 2. bzr does not support fully distributed development because revnos
> > "don't work" as stated in #1.
> Bazaar is biased towards centralized/star-topology development if we
> want to use revids. In fully distributed configuration there is no
> "simple namespace".
So revnos aren't globally meaningful in fully distributed settings. So
what? I don't see how this translates into bias. There is a lot of
functionality provided by bazaar that doesn't really apply to my use
case, but it doesn't mean that it is indicative of some bias in bazaar.
>
> > 3. Ok, bzr does support distributed development, I just say it doesn't
> > because I think revids are ugly.
> I think that bzr revids are uglier that git commit-ids.
>
> If on the pros side of bzr is "simple namespace", you must remember that
> it is simple namespace only for not fully distributed development. The
> pros of "simple namespace" with cons of "merge" vs "pull" and centralization
> required for uniqueness of revids.
I think you've switched revids and revnos, but I get what you are
saying. In fact, I think I said pretty much the same thing in the email
you are replying to. I don't think that anyone is disagreeing about
anything other than the assertion that bzr is biased because revnos are
used to simplify cases where it is possible to do so.
In any case, Matthew Fuller & Carl Worth cover this in greater detail in
emails further down in this thread (or one of its siblings), so I think
I'll stop here.
-davidc
--
gpg-key: http://www.zettazebra.com/files/key.gpg
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] Allow deletion of several patches at once
From: Catalin Marinas @ 2006-10-23 11:57 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20061022125816.15194.3341.stgit@localhost>
On 22/10/06, Karl Hasselström <kha@treskal.com> wrote:
> + applied = {}
> + unapplied = {}
> + dontexist = {}
> + for patch in args:
Any reason for not using the parse_patches() function in
stgit.command.common? It allows one to specify patch ranges like
patch1..patch2. Have a look at how it is used for the push or float
commands.
--
Catalin
^ permalink raw reply
* Re: [PATCH 2/2] Allow deletion of several patches at once
From: Karl Hasselström @ 2006-10-23 12:37 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0610230457l2ff82a05pd9c7eddfcfac68f2@mail.gmail.com>
On 2006-10-23 12:57:03 +0100, Catalin Marinas wrote:
> On 22/10/06, Karl Hasselström <kha@treskal.com> wrote:
>
> > + applied = {}
> > + unapplied = {}
> > + dontexist = {}
> > + for patch in args:
>
> Any reason for not using the parse_patches() function in
> stgit.command.common? It allows one to specify patch ranges like
> patch1..patch2. Have a look at how it is used for the push or float
> commands.
Ah, no, I just didn't know it existed. I'll send an updated patch (but
it may be a few days).
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-23 12:54 UTC (permalink / raw)
To: David Clymer
Cc: Matthew D. Fuller, Andreas Ericsson, Linus Torvalds, Carl Worth,
bazaar-ng, git
In-Reply-To: <1161604564.22276.173.camel@zepto.home.zettazebra.com>
On Mon, Oct 23, 2006 David Clymer wrote:
> On Sun, 2006-10-22 at 22:06 +0200, Jakub Narebski wrote:
>> David Clymer wrote:
>>> 2. bzr does not support fully distributed development because revnos
>>> "don't work" as stated in #1.
>>
>> Bazaar is biased towards centralized/star-topology development if we
>> want to use revnos. In fully distributed configuration there is no
>> "simple namespace".
>
> So revnos aren't globally meaningful in fully distributed settings. So
> what? I don't see how this translates into bias. There is a lot of
> functionality provided by bazaar that doesn't really apply to my use
> case, but it doesn't mean that it is indicative of some bias in bazaar.
First, bzr is biased towards using revnos: bzr commands uses revnos
by default to provide revision (you have to use revid: prefix/operator
to use revision identifiers), bzr commands outputs revids only when
requested, examples of usage uses revision numbers.
In order to use revnos as _global_ identifiers in distributed development,
you need central "branch", mainline, to provide those revnos. You have
either to have access to this "revno server" and refer to revisions by
"revno server" URL and revision number, or designate one branch as holding
revision numbers ("revno server") and preserve revnos on "revno server"
by using bzr "merge", while copying revnos when fetching by using bzr "pull"
for leaf branches. In short: for revnos to be global identifiers you need
star-topology.
Even if you use revnos only locally, you need to know which revisions are
"yours", i.e. beside branch as DAG of history of given revision you need
"ordered series of revisions" (to quote Bazaar-NG wiki Glossary), or path
through this diagram from given revision to one of the roots (initial,
parentless revisions). Because bzr does that by preserving mentioned path
as first-parent path (treating first parent specially), i.e. storing local
information in a DAG (which is shared), to preserve revnos you need to
use "merge" instead of "pull", which means that you get empty-merge in
clearly fast-forward case. This means "local changes bias", which some
might take as not being fully distributed.
Sidenote 1: Why Bazaar-NG tries to store "branch as ordered series
of revisions"/"branch as path through revisions DAG" in DAG instead
of storing it separately (like reflog stores history of tip of branch,
which is roughly equivalent of "branch as path" in bzr). It needs
some kind of cache of mapping from revno to the revision itself anyway
(unless performance doesn't matter for bzr developers ;-)! All what
left is to propagate this mapping on "pull"...
Sidenote 2: "Fringe" developer using default git configuration of
'origin' branch tracking 'master' branch in cloned (mainline) repo,
and 'master' branch on which he/she does his/her own work, who committed
at least single revision on his/her 'master' branch, and whose changes
are never pulled and if they get into mainline repo it is using "side"
channel like git-enchanced patches sent to project mailing list,
will see the picture similar to the bzr branch which uses "merge".
The whole discussion about validity of revision numbers started
with "simple namespace" feature in SCM comparison matrix on Bazaar-NG
wiki...
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] git-clone: honor --quiet
From: Jim Meyering @ 2006-10-23 13:59 UTC (permalink / raw)
To: git
I noticed that a cron-launched "git-clone --quiet" was generating
progress output to standard error -- and thus always spamming me.
The offending output was due to git-clone invoking git-read-tree with
its undocumented -v option.
This change turns off "-v" for --quiet.
Signed-off-by: Jim Meyering <jim@meyering.net>
---
git-clone.sh | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/git-clone.sh b/git-clone.sh
index 786d65a..3f006d1 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -401,7 +401,8 @@ Pull: refs/heads/$head_points_at:$origin
case "$no_checkout" in
'')
- git-read-tree -m -u -v HEAD HEAD
+ test "z$quiet" = z && v=-v || v=
+ git-read-tree -m -u $v HEAD HEAD
esac
fi
rm -f "$GIT_DIR/CLONE_HEAD" "$GIT_DIR/REMOTE_HEAD"
--
1.4.3.1.g178e-dirty
^ permalink raw reply related
* git bisect with history manipulation
From: Kalle Pokki @ 2006-10-23 14:22 UTC (permalink / raw)
To: git
In-Reply-To: <a425f86c0610230718i556537dei9a4b2a5fa8d7f003@mail.gmail.com>
Hi,
I'm still pretty new with git, and cannot quite figure out how to use
"git bisect" effectively in this special case: I'm running an embedded
powerpc board, to which I need about a dozen platform patches in the
kernel. Originally I made the patches with quilt on top of 2.6.15.4. I
recently started using git, and just applied the patches on top of
v2.6.18. However, the system seems to oops at every boot now. So I did
"git branch downgrade && git reset --hard v2.6.15" and applied my
patches on top of it to create a starting state similar to what I had
previously. There everything is ok.
Wanting to try to bisect the kernel versions, I then merged the master
branch into the downgrade branch. Then I marked my last platform
commit as good, and v2.6.18 as bad. However the bisect algorithm seems
to group the platform patches near v2.6.18 instead of v2.6.15, since I
don't have the platform files in the bisect checkout. And since I
don't have the platform files, I can't compile a kernel that would run
on my board.
So is there any way to insert a few patches to an arbitrary point
backwards in time and start bisecting from that to the present time?
Or am I thinking this somehow all wrong?
^ permalink raw reply
* Re: VCS comparison table
From: James Henstridge @ 2006-10-23 15:01 UTC (permalink / raw)
To: Jakub Narebski
Cc: David Clymer, bazaar-ng, Matthew D. Fuller, Linus Torvalds,
Carl Worth, Andreas Ericsson, git
In-Reply-To: <200610231454.06355.jnareb@gmail.com>
On 23/10/06, Jakub Narebski <jnareb@gmail.com> wrote:
> First, bzr is biased towards using revnos: bzr commands uses revnos
> by default to provide revision (you have to use revid: prefix/operator
> to use revision identifiers), bzr commands outputs revids only when
> requested, examples of usage uses revision numbers.
As has been said before, you can set an alias to always show revision
IDs in "bzr log" output.
> In order to use revnos as _global_ identifiers in distributed development,
> you need central "branch", mainline, to provide those revnos. You have
> either to have access to this "revno server" and refer to revisions by
> "revno server" URL and revision number, or designate one branch as holding
> revision numbers ("revno server") and preserve revnos on "revno server"
> by using bzr "merge", while copying revnos when fetching by using bzr "pull"
> for leaf branches. In short: for revnos to be global identifiers you need
> star-topology.
Why do you continue to repeat this argument? No one is claiming that
a revision number by itself, as Bazaar uses them, is a global
identifier. In fact, we keep on saying that they only have meaning in
the context of a branch. If you want to use a revision number as part
of a globally unique identifier, it needs to be in combination with
its branch.
> Even if you use revnos only locally, you need to know which revisions are
> "yours", i.e. beside branch as DAG of history of given revision you need
> "ordered series of revisions" (to quote Bazaar-NG wiki Glossary), or path
> through this diagram from given revision to one of the roots (initial,
> parentless revisions). Because bzr does that by preserving mentioned path
> as first-parent path (treating first parent specially), i.e. storing local
> information in a DAG (which is shared), to preserve revnos you need to
> use "merge" instead of "pull", which means that you get empty-merge in
> clearly fast-forward case. This means "local changes bias", which some
> might take as not being fully distributed.
I won't dispute that Bazaar has features that make it easier to work
with the revisions in the line of development of the branch you're
working on in comparison to the revisions from merges. But given that
every Bazaar branch has this same bias towards their own main line of
development, how can that affect whether or not it is distributed?
James.
^ permalink raw reply
* Re: git bisect with history manipulation
From: Linus Torvalds @ 2006-10-23 15:34 UTC (permalink / raw)
To: Kalle Pokki; +Cc: git
In-Reply-To: <a425f86c0610230722r2a0ae473o467d303f915b6c1e@mail.gmail.com>
On Mon, 23 Oct 2006, Kalle Pokki wrote:
>
> So is there any way to insert a few patches to an arbitrary point
> backwards in time and start bisecting from that to the present time?
> Or am I thinking this somehow all wrong?
It's possible, but you have to do it the patch-application manually at
each stage, so it's not a lot of fun. I've had to do it for the opposite
reason: hunting down a bug with "git bisect" when there was _another_
unrelated bug that I already had fixed, but that made it impossible to
test for the first one. Again, in order to see the first one, I did git
bisect, but then at each stage applied the fix for the second one if
needed.
So what you would do is to simply do the bisect _as_if_ those patches
weren't there, and then apply the patches on top of the kernel that "git
bisect" suggests. Then (and this is important), when you mark the result
good or bad, don't use just "git bisect good/bad" - but name explicitly
the commit that you applied your patch-series on.
(This gets a bit easier if you instead of actually cherry-picking the
patches you want to apply, just apply it as a single patch _without_
committing it - then all your changes will be effectively "invisible" to
git bisect anyway, and you don't need to do much of anything special,
except do a "git checkout -f" to remove the patch before you say "that was
bad" or "that was good").
HOWEVER. It's quite possibly easier to just do it the other way: if your
series of patches causes problems when rebased on top of a newer kernel,
just bisect your rebased series itself (at which point it's all a totally
normal "git bisect", and you don't need to do anything special). It may be
that once you see _which_ patch in the series caused problems, you'll
immediately say "Oh, duh, that got mis-merged" or (perhaps more likely) by
pointing to a particular commit it will point to a certain area that
changed and you suddenly realize _why_ the series caused a problem.
So depending on the problem, you can try two different approaches.
It might make sense to extend "git bisect" with a "apply this patch at
each point" capability, but that doesn't exist right now. If you do end up
going that way, and automate it, please do send the patches out for
discussion.
Linus
^ permalink raw reply
* Re: git bisect with history manipulation
From: Jakub Narebski @ 2006-10-23 15:42 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0610230826080.3962@g5.osdl.org>
Linus Torvalds wrote:
> So depending on the problem, you can try two different approaches.
[The approaches being: 1) applying patchseries before testing, and marking
the commit before applying as good or bad for bisect; 2) rebasing
(applying) the patch-series on top of current kernel, and bisecting the
series]
You can try yet another approach, namely rebase v2.6.15..v2.6.18 on top of
your patch-series applied to v2.6.15, and bisect that.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git bisect with history manipulation
From: Sean @ 2006-10-23 15:47 UTC (permalink / raw)
To: Kalle Pokki; +Cc: git
In-Reply-To: <a425f86c0610230722r2a0ae473o467d303f915b6c1e@mail.gmail.com>
On Mon, 23 Oct 2006 17:22:41 +0300
"Kalle Pokki" <kalle.pokki@iki.fi> wrote:
> I'm still pretty new with git, and cannot quite figure out how to use
> "git bisect" effectively in this special case: I'm running an embedded
> powerpc board, to which I need about a dozen platform patches in the
> kernel. Originally I made the patches with quilt on top of 2.6.15.4. I
> recently started using git, and just applied the patches on top of
> v2.6.18. However, the system seems to oops at every boot now. So I did
> "git branch downgrade && git reset --hard v2.6.15" and applied my
> patches on top of it to create a starting state similar to what I had
> previously. There everything is ok.
>
> Wanting to try to bisect the kernel versions, I then merged the master
> branch into the downgrade branch. Then I marked my last platform
> commit as good, and v2.6.18 as bad. However the bisect algorithm seems
> to group the platform patches near v2.6.18 instead of v2.6.15, since I
> don't have the platform files in the bisect checkout. And since I
> don't have the platform files, I can't compile a kernel that would run
> on my board.
>
> So is there any way to insert a few patches to an arbitrary point
> backwards in time and start bisecting from that to the present time?
> Or am I thinking this somehow all wrong?
>
Well, there is no way to insert the patches into the history at an old
point so that they're always available at each bisection point in your
search. The history is immutable.
What you will have to do, is apply your patches manually at each
bisection point before you compile/test. After testing you'll have
to remove your manual patches and continue with your next git
bisect command. However, there are a few ways that you can make this
easier to do.
You could use the Stacked Git utility (which is a Quilt like clone
built on top of Git) to help you along in this process. Actually,
you may be able to do the same thing with Quilt itself, but i don't
know i've never used it.
That said, i'll try to outline one way to do this that should work
using just native Git commands. The first thing you need to do is
prepare a git branch based on the first known-good commit that
contains all your extra patches. So:
$ git checkout -b mypatches v2.6.15
$ patch < patch1
$ git commit -a
$ patch < patch2
$ git commit -a
etc...
Then you can go back to the master branch and start the bisection:
$ git checkout master
$ git bisect start
$ git bisect bad
$ git bisect good v2.6.15
At which point git will create and move you to a temporary "bisect"
branch to do your compile/testing. Now before you compile, you want
to append your patch series from the branch you prepared earlier, so:
$ git pull . mypatches
Now compile and test. After you've tested, you will have to remove
your patches from this branch before continuing with the git bisection
process so:
$ git reset --hard ORIG_HEAD
And now continue with your bisection, let's assume the first bisection
point still didn't work:
$ git bisect bad
Which will move you to a new bisection point where you can go back to
the "git pull . mypatches" step to apply your patch series again and
do another compile/test. Continue with this process as needed.
Hope that is clear enough,
Sean
^ permalink raw reply
* Re: [RFC] git-split: Split the history of a git repository by subdirectories and ranges
From: Linus Torvalds @ 2006-10-23 15:52 UTC (permalink / raw)
To: Josh Triplett; +Cc: Junio C Hamano, git
In-Reply-To: <453C96C9.4010005@freedesktop.org>
On Mon, 23 Oct 2006, Josh Triplett wrote:
>
> > I wonder if using "git-log --full-history -- $project" to let the core
> > side omit commits that do not change the $project (but still give you
> > all merged branches) would have made your job any easier?
>
> I don't think it would. We still need to know what commit to use as the
> parent of any given commit, so we don't want commits in the log output
> with parents that don't exist in the log output. And rewriting parents
> in git-log based on which revisions change the specified subdirectory
> seems like a bad idea.
Umm.. You didn't realize that git log already _does_ exactly that?
You need to rewrite the parents in order to get a nice and readable
history, which in turn is needed for any visualizer. So git has long done
the parent rewriting in order to be able to do things like
gitk drivers/char
on the kernel.
And yes, that's done by the core revision parsing code, so when you do
git log --full-history --parents -- $project
you do get the rewritten parent output (of course, it's not actually
_simplified_, so you get a fair amount of duplicate parents etc which
you'd still have to simplify and which don't do anything at all).
Without the "--full-history", you get a simplified history, but it's
likely to be _too_ simplified for your use, since it will not only
collapse multiple identical parents, it will also totally _remove_ parents
that don't introduce any new content.
So there are multiple levels of history simplification, and right now the
internal git revision parser only gives you two choices: "none"
(--full-history) and "extreme" (which is the default when you give a set
of filenames).
Linus
^ permalink raw reply
* Re: git bisect with history manipulation
From: Linus Torvalds @ 2006-10-23 15:59 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ehinsa$a7n$1@sea.gmane.org>
On Mon, 23 Oct 2006, Jakub Narebski wrote:
>
> You can try yet another approach, namely rebase v2.6.15..v2.6.18 on top of
> your patch-series applied to v2.6.15, and bisect that.
Oooh.
Yeah, it's a great idea, but likely not practical (or even possible).
git-rebase really wants a linear set of patches to rebase, which you
definitely don't have for that big history. In fact, even if rebase did
the full history rebasing, if later history did a merge of an earlier
thing (ie if the patch-series that you're trying to rebase onto was based
on something that wasn't an "epoch tip", but that was in the middle of
intertwined history), you'd really be screwed.
Also, let's face it, rebasing isn't _that_ fast. So trying to rebase huge
swaths of code would be painful as hell, even if it was a nice linear
series.
But yes, for simpler situations, you could try to switch the problem
around like you suggest.
Linus
^ permalink raw reply
* Re: git bisect with history manipulation
From: Jakub Narebski @ 2006-10-23 16:19 UTC (permalink / raw)
To: git
In-Reply-To: <BAYC1-PASMTP01856E85F8D54BE3CBF69EAE000@CEZ.ICE>
Sean wrote:
> $ patch < patch1
We have git-apply for that (sometimes git-am would work on whole
series of patches).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* New software uploaded by Brenda on Oct 23 20:10:00 MSK 2006
From: Photoshop Software @ 2006-10-23 16:22 UTC (permalink / raw)
To: git
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit, Size: 6379 bytes --]
Brenda has uploaded some new software for you!
Click here to view available updated software:
http://update.eroemina.com/?Brenda
dollars, though, not hundredths of cents. For example,
in general, the author remembers reading that The RS-232 Bible
purpose. So, simple huh?
Do not include the line numbers, they are just for this discussion.
controller pci0
code for every single port and will take a very long time to download!
o Support Advansys SCSI controller products. Coordinator: Justin T.
/sbin/ifconfig sl$1 down
Tape drives
generates signals that comply with the EIA RS232-C specification.
on your FreeBSD SLIP server and configure it to use the appropriate
shell script that plays some simple songs, and /usr/games/piano
corrected connections:
by Mark Dapoz <mdbsc.no>).
Sometimes sites combine the two types of firewalls, so that only a
# Simply copies stdin to stdout. Ignores all filter arguments.
o You are familiar with your modem's command set, or know where to
k k eeee l l y y
o FWD: Fast Wide Differential
115 ?? I 0:00.10 /usr/libexec/getty V19200 ttyd1
cdb5=0
Sets the flag bits set-bits in the sgttyb structure.
submitted with lpr -l), adjust the printing position for backspaces
for the printer you are debugging in the /etc/printcap file.
signal, because only one DMA channel can be active at any instant.
software. The reason is that the most important table set by
getting `Permission Denied' messages from the server then it is likely
This is done on the Kerberos server only. First make sure that your do
using the the FreeBSD World Wide Web server
# cd /usr/ports
22.3.3. DMA Operational Modes and Settings
printers, NIS-maintained printcaps, and NFS-mounted spooling
masters, special hardware design to replace the PCI bus arbiter
characters. If you forget to do this, COMTEST will report at least
file, so it has no idea whom to charge for printer use. It is also
FreeBSD will also add subnet routes for the local subnet (10.20.30.255
``Wangtek 6200''
xxx.xxx.yy's into the network address of your own SLIP subnet (be sure
which will display the manual page for the user command chmod. Refer-
create a directory there, and make a symbolic link from /usr/ports to
they get bored, hack around with it, borrow from it (licence
an easy way of tracking one central code base, not to keep potential
asamics.berkeley.edu
device cd0
end of a volume. This shell script can be used to change tapes:
The superuser can remove other users' jobs; you can remove only
Contact: sergklara.weizmann.ac.il.
10.4.1.3.1. Adaptec 2320 controllers
the Internet Domain Name Service, a distributed data base, the
options that are available from cpio(1), but tar(1) does not require
You should get a boot prompt something like this:
unavailable.
partition of the floppy read-write ("mount -u -o rw /mnt"). Use your
exec /usr/local/bin/dvips -f | /usr/local/libexec/lprps "$"
make -f bash-Makefile bindir=/usr/local/bin prefix=/usr/local install
piece of paper or adhesive sticker. In addition, on most disks the
number, the destination port number (for protocols which support
command-line `key' program takes as its parameters the iteration count
If you're looking for high-speed serial networking solutions, then
maintaining multiple FreeBSD machines with different hardware, it is a
Print accounting information for the given user names only.
with the lpr command:
Occasionally, the files that make up a job are not properly
# Clean up and exit
sio13: type 16550A (multiport)
Parts in this section marked with an asterisk (*) are incomplete.
This is the mailing list for users of freebsd-current. It
printer that has a conventional serial or parallel interface on one
conditions and other flaws. The original IBM BIOS includes code
#
select the devices address.
6.4.1. What is a firewall?
special bits are added to each word which are used to synchronize the
"D". A blank indicates a plain 10 Mbits/second controller. An "A-8"
the bus at the same time, the device that has the highest SCSI ID will
You could put these commands in your /etc/rc.local file to set the
If you do not already have a custom kernel configuration file set up,
grunt# kerberos &
no capability to send initialization sequences to a printer, it is
10.4.5.3.3.
was actually found.
Unlike an X terminal, FreeBSD allows many applications to be run
quick way to get printer accounting working for plain text, or if
`post-install' over-ride the instructions in bsd.port.mk about what to
:sh:sd=/var/spool/lpd/bamboo:\
to define which workaround is needed.
write the results to standard output, which will get printed. For
file, but with _sum appended to the name. It then truncates the
booting information to client. The name of this file is
./support/install.sh -c -m 644 features.info /usr/local/info/bash.info
This meant losing a lot of disk space.
Reorganization of the source tree for multiple platform ports.
ports-distfiles: /usr/ports/distfiles original tarballs
In the interim, there is a nice application available in the ``The
data cannot be directly printed, but you can install a conversion
LPD, LPD will refuse them.
0, in the above example, which was the first parameter in the list
(4 x 4 x 1 inches; 100 x 100 x 25 mm). The cartridge has a swinging
We now have to extract all the instances which define the services on
Reported by: Pedro A M Vazquez vazquezIQM.Unicamp.BR
key is.
sio3: type 16550A (multiport)
/project
PostScript files and can render their pages onto a variety of devices,
are reported. All events that caused the
options
respond using a set of jumpers, or a dip switch, or something similar.
place of 10.0.0.1.
cause of a Framing Error is that the sender and receiver clocks were
----- begin /etc/sliphome/slip.login for "proxy ARP" -----
a few years old.)
grunt# ls
simply converted into a -D switch for the CFLAGS line of the kernel
to the law (PKP's patent on public key crypto, ITAR (export of crypto
:if=/usr/local/libexec/if-simple:
===> Patching for bash-1.14.5
actually being sent over the media, not the amount of data that is
17.2.5. Future plans for CTM
On the 8250/16450 UART, this bit is zero.
workaround that will allow satisfactory operation. If the FreeBSD
5.3.5. SCSI Device Support
device cy0 at isa? tty irq 10 iomem 0xd4000 iosiz 0x2000 vector cyintr
[...]
^ permalink raw reply
* Re: git bisect with history manipulation
From: Catalin Marinas @ 2006-10-23 16:21 UTC (permalink / raw)
To: Sean; +Cc: Kalle Pokki, git
In-Reply-To: <BAYC1-PASMTP01856E85F8D54BE3CBF69EAE000@CEZ.ICE>
Sean <seanlkml@sympatico.ca> wrote:
> On Mon, 23 Oct 2006 17:22:41 +0300
> "Kalle Pokki" <kalle.pokki@iki.fi> wrote:
>
>> So is there any way to insert a few patches to an arbitrary point
>> backwards in time and start bisecting from that to the present time?
>> Or am I thinking this somehow all wrong?
[...]
> You could use the Stacked Git utility (which is a Quilt like clone
> built on top of Git) to help you along in this process. Actually,
> you may be able to do the same thing with Quilt itself, but i don't
> know i've never used it.
It's on my todo list to actually add bisect support to StGIT (someone
suggested it on the mailing list) but I can't give any estimates about
when this would be done. The idea is that it will only bisect the base
and push the patches on top of the new tree (at a first though, it
doesn't look difficult at all).
Otherwise, use StGIT to manage the patches and the following sequence
for bisecting:
$ git bisect start
$ stg init
$ stg pick <patch@branch>
$ stg pick <patch@branch>
$ ...
$ stg pop -a
$ git bisect good v2.6.x
$ git bisect bad
$ stg push -a
$ ... test ...
$ stg pop -a
$ git bisect good|bad
$ stg push -a
$ ...
--
Catalin
^ permalink raw reply
* Re: git bisect with history manipulation
From: Sean @ 2006-10-23 16:25 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ehiq2l$lkq$1@sea.gmane.org>
On Mon, 23 Oct 2006 18:19:56 +0200
Jakub Narebski <jnareb@gmail.com> wrote:
> Sean wrote:
>
> > $ patch < patch1
>
> We have git-apply for that (sometimes git-am would work on whole
> series of patches).
Point taken. git-rebase and git-cherrypick may also be appropriate
to snag the commits from another branch rather than reapplying them
from patches. In fact you may already have a branch that works
which contains just your patches on top of it. I was trying to
make the example as clear as possible rather than exhaustive.
Sean
^ permalink raw reply
* [PATCH] prune-packed: Fix uninitialized variable.
From: Alexandre Julliard @ 2006-10-23 16:26 UTC (permalink / raw)
To: git
The dryrun variable was made local instead of static by the previous
commit, and local variables aren't initialized to zero.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
builtin-prune-packed.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-prune-packed.c b/builtin-prune-packed.c
index e12b6cf..24e3b0a 100644
--- a/builtin-prune-packed.c
+++ b/builtin-prune-packed.c
@@ -56,7 +56,7 @@ void prune_packed_objects(int dryrun)
int cmd_prune_packed(int argc, const char **argv, const char *prefix)
{
int i;
- int dryrun;
+ int dryrun = 0;
for (i = 1; i < argc; i++) {
const char *arg = argv[i];
--
1.4.3.1.g7d714
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
* [PATCH] Documentation for the [remote] config
From: Santi Béjar @ 2006-10-23 16:42 UTC (permalink / raw)
To: Git Mailing List
Signed-off-by: Santi Béjar <sbejar@gmail.com>
---
Documentation/config.txt | 12 ++++++++++++
Documentation/urls.txt | 8 ++++++++
2 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 84e3891..ee51fe3 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -230,6 +230,18 @@ pull.octopus::
pull.twohead::
The default merge strategy to use when pulling a single branch.
+remote.<name>.url::
+ The URL of a remote repository. See gitlink:git-fetch[1] or
+ gitlink:git-push[1].
+
+remote.<name>.fetch::
+ The default set of "refspec" for gitlink:git-fetch[1]. See
+ gitlink:git-fetch[1].
+
+remote.<name>.push::
+ The default set of "refspec" for gitlink:git-push[1]. See
+ gitlink:git-push[1].
+
show.difftree::
The default gitlink:git-diff-tree[1] arguments to be used
for gitlink:git-show[1].
diff --git a/Documentation/urls.txt b/Documentation/urls.txt
index 26ecba5..670827c 100644
--- a/Documentation/urls.txt
+++ b/Documentation/urls.txt
@@ -51,6 +51,14 @@ lines are used for `git-push` and `git-f
respectively. Multiple `Push:` and `Pull:` lines may
be specified for additional branch mappings.
+Or, equivalently, in the `$GIT_DIR/config` (note the use
+of `fetch` instead of `Pull:`):
+
+[remote "<remote>"]
+ url = <url>
+ push = <refspec>
+ fetch = <refspec>
+
The name of a file in `$GIT_DIR/branches` directory can be
specified as an older notation short-hand; the named
file should contain a single line, a URL in one of the
--
1.4.3.1.gf8f0bb
^ permalink raw reply related
* Re: renames in StGIT
From: Catalin Marinas @ 2006-10-23 16:47 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20061022013943.GA16341@diana.vm.bytemark.co.uk>
On 22/10/06, Karl Hasselström <kha@treskal.com> wrote:
> It doesn't seem like StGIT uses any of git's rename tracking stuff.
> Specifically, pushing patches doesn't seem to use rename-aware
> merging, and there is no way to tell diff to detect renames and
> copies.
They are indeed not supported by StGIT. One of the reasons is that the
push operation would probably take (much) longer (I haven't looked at
the algorithm in detail but some comments in the git-diff
documentation suggest that this is very expensive). Another reason is
that I (used to) send patches to people not using GIT and therefore
renames in the diff output were not welcomed.
> Should this perhaps be an item in the TODO list?
Only if it doesn't drastically affect the performance.
--
Catalin
^ permalink raw reply
* Re: VCS comparison table
From: David Lang @ 2006-10-23 16:57 UTC (permalink / raw)
To: Matthew D. Fuller
Cc: Carl Worth, Erik Bågfors, bazaar-ng, git, Jakub Narebski
In-Reply-To: <20061022185350.GW75501@over-yonder.net>
>> This special treatment influences or directly causes many of the
>> things in bzr that we've been discussing:
> [...]
>> I've been arguing that all of these impacts are dubious. But I can
>> understand that a bzr user hearing arguments against them might fear
>> that they would lose the ability to be able to see a view of commits
>> that "belong" to a particular branch.
>
> Dead center.
>
>
>> The mainline..featureA syntax literally just means:
>>
>> the set of commits that are reachable by featureA
>> and excluding the set of commits reachable by mainline
>
> From what I can gather from this, though, that means that when I merge
> stuff from featureA into mainline (and keep on with other stuff in
> featureA), I'll no longer be able to see those older commits from this
> command. And I'll see merged revisions from branches other than
> mainline (until they themselves get merged into mainline), correct?
> It sounds more like a 'bzr missing --mine-only' than looking down a
> mainline in log...
one thing you are missing 'mainline' in this git command is not saying
'everything that's in the 'main' published branch'. it's saying 'everything
reachable by the tag 'mainline'
so when you branched off for your feature development you could set a tag that
says 'branchpoint' and no matter what gets merged in mainline after that you can
always do branchpoint..featureA and find what you've done.
that being said, mainline..featureA is also extremely useful, it tells you what
development stuff you have done that have not yet been merged into mainline
David Lang
^ permalink raw reply
* Re: VCS comparison table
From: Aaron Bentley @ 2006-10-23 17:18 UTC (permalink / raw)
To: James Henstridge
Cc: Jakub Narebski, bazaar-ng, Matthew D. Fuller, Linus Torvalds,
Andreas Ericsson, Carl Worth, git
In-Reply-To: <a7e835d40610230801m4ac92409gbddcf66dcd1bb429@mail.gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
James Henstridge wrote:
> Why do you continue to repeat this argument? No one is claiming that
> a revision number by itself, as Bazaar uses them, is a global
> identifier. In fact, we keep on saying that they only have meaning in
> the context of a branch.
And, unlike git, Bazaar branches are all independent entities[1], and
they each have a URL.
So:
http://code.aaronbentley.com/bzrrepo/bzr.ab 1695
is a name for
abentley@panoramicfeedback.com-20060927202832-9795d0528e311e31
And it does not depend on any other branch, especially not bzr.dev
Since:
1. anyone with write access to the urls can create them
2. anyone with read access to the urls can read them
3. the maintainers of the mainline have no control over them
(except as provided by 1)
these identifiers are not centralized.
Aaron
[1] The fact that they may share storage is not important to the model.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFFPPlm0F+nu1YWqI0RAlmLAJ9cpw5X7UXQ82EmoIeUrKzEaFbhdACfZPsS
CRJ69XWi7XAWJRi7Fgt9ICU=
=WrV9
-----END PGP SIGNATURE-----
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox