* Re: RFC: grafts generalised
From: Stephen R. van den Berg @ 2008-07-02 18:37 UTC (permalink / raw)
To: Mike Hommey; +Cc: Michael J Gruber, git
In-Reply-To: <20080702182510.GC29559@glandium.org>
Mike Hommey wrote:
>> These edits are numerous and spread over many months, so the typical
>> history fixup-sessions involve periods where you make 30 random
>> historicaledits per hour (which need to be viewed and checked every time
>> immediately after making the change). And say once every 4 months, you
>> run it through git filter-branch to cast everything into stone. A
>> typical git filter-branch run takes 15 minutes on a repository this
>> size.
>I think the point was more about making a tool to do exactly what you
>want, based on the new git sequencer. Note that git filter-branch could
>also be rewritten to use the sequencer.
As far as I understood it, the new git sequencer rewrites history
proper. That is timeconsuming by definition, and thus it is *not*
possible to make a tool based on the sequencer that supports the desired
iterative-history-rewrite workflow.
--
Sincerely,
Stephen R. van den Berg.
You are confused; but this is your normal state.
^ permalink raw reply
* Re: RFC: grafts generalised
From: Michael J Gruber @ 2008-07-02 18:34 UTC (permalink / raw)
To: git
In-Reply-To: <20080702182510.GC29559@glandium.org>
Mike Hommey venit, vidit, dixit 02.07.2008 20:25:
> On Wed, Jul 02, 2008 at 07:42:55PM +0200, Stephen R. van den Berg wrote:
>> Michael J Gruber wrote:
>>> Maybe the upcoming git-sequencer could be the appropriate place? It
>>> tries to achieve just that: edit history by specifying a list of
>>> commands. The currently planned set of commands would need to be
>> That's the problem. Like git filter-branch, git sequencer needs you to
>> parameterise the changes, which, in my case, is hardly possible, since
>> the changes are randomlike.
>> Also, having to run the sequencer to dig 20000 commits into the past,
>> then change something, then come back up and rewrite all following
>> history and relations (parents/tags/merges) will take a sizeable amount
>> of time. I need something that can be changed at will, then viewed with
>> gitk a second later.
>>
>> These edits are numerous and spread over many months, so the typical
>> history fixup-sessions involve periods where you make 30 random
>> historicaledits per hour (which need to be viewed and checked every time
>> immediately after making the change). And say once every 4 months, you
>> run it through git filter-branch to cast everything into stone. A
>> typical git filter-branch run takes 15 minutes on a repository this
>> size.
>
> I think the point was more about making a tool to do exactly what you
> want, based on the new git sequencer. Note that git filter-branch could
> also be rewritten to use the sequencer.
Yes, that was at least my point. As I understand, git filter-branch -i
is a candidate for that rewrite.
But I understand now that OP wants to do lots of history edits and see
them immediately before doing the actual (time consuming) rewrite; and
then do the rewrite occasionally. Rewriting is surpirsingly slow even on
tmpfs.
Michael
^ permalink raw reply
* Re: RFC: grafts generalised
From: Dmitry Potapov @ 2008-07-02 18:33 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: git
In-Reply-To: <20080702181021.GD16235@cuci.nl>
On Wed, Jul 2, 2008 at 10:10 PM, Stephen R. van den Berg <srb@cuci.nl> wrote:
> Dmitry Potapov wrote:
>>On second thought, it may be not necessary. You can extract an old commit
>>object, edit it, put it into Git with a new SHA1, and then use the graft file to
>>replace all references from an old to a new one. And you will be able to see
>>changes immediately in gitk.
>
> Hmmmm, interesting thought. That just might solve my problem.
This script is just a prove of the concept. It seems to work for me, but
I don't really tested it.
===========================================
#!/bin/bash
set -e
# creating some silly repo
git init
# creating some history
for ((i=0; $i<10; i++))
do
echo foo$i > foo$i
git add foo$i
git commit -m "add foo$i"
done
# run gitk to see it
gitk --all &
# dump all graft info to text file
git rev-list --parents --all > .git/info/grafts.tmp
mv .git/info/grafts.tmp .git/info/grafts
# please choose what commit you want to edit
echo
while read -p 'Edit commit: ' C
do
C=$(git rev-parse "$C") || continue
# edit commit C
git cat-file commit $C > .git/COMMIT_OBJ
vim .git/COMMIT_OBJ
C2=$(git hash-object -w -t commit .git/COMMIT_OBJ)
# replace all references from C to C2
sed -e 's/\<'$C'\>/'$C2'/g' < .git/info/grafts > .git/info/grafts.tmp
mv .git/info/grafts.tmp .git/info/grafts
done
===========================================
Dmitry
^ permalink raw reply
* Re: [PATCH] git-add--interactive: manual hunk editing mode
From: Junio C Hamano @ 2008-07-02 18:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, Thomas Rast, git
In-Reply-To: <alpine.DEB.1.00.0807021412300.9925@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> I wonder why bother trying to import things when you do not need them to
> begin with! I mean, it is _obvious_ that in this case, we want .git/ to
> be writable _anyway_, so why not stick with a fixed name in that?
Good suggestion -- I love that simplicity. Thomas?
^ permalink raw reply
* Re: RFC: grafts generalised
From: Mike Hommey @ 2008-07-02 18:25 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: Michael J Gruber, git
In-Reply-To: <20080702174255.GB16235@cuci.nl>
On Wed, Jul 02, 2008 at 07:42:55PM +0200, Stephen R. van den Berg wrote:
> Michael J Gruber wrote:
> >Maybe the upcoming git-sequencer could be the appropriate place? It
> >tries to achieve just that: edit history by specifying a list of
> >commands. The currently planned set of commands would need to be
>
> That's the problem. Like git filter-branch, git sequencer needs you to
> parameterise the changes, which, in my case, is hardly possible, since
> the changes are randomlike.
> Also, having to run the sequencer to dig 20000 commits into the past,
> then change something, then come back up and rewrite all following
> history and relations (parents/tags/merges) will take a sizeable amount
> of time. I need something that can be changed at will, then viewed with
> gitk a second later.
>
> These edits are numerous and spread over many months, so the typical
> history fixup-sessions involve periods where you make 30 random
> historicaledits per hour (which need to be viewed and checked every time
> immediately after making the change). And say once every 4 months, you
> run it through git filter-branch to cast everything into stone. A
> typical git filter-branch run takes 15 minutes on a repository this
> size.
I think the point was more about making a tool to do exactly what you
want, based on the new git sequencer. Note that git filter-branch could
also be rewritten to use the sequencer.
Mike
^ permalink raw reply
* Re: RFC: grafts generalised
From: Stephen R. van den Berg @ 2008-07-02 18:10 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: git
In-Reply-To: <37fcd2780807021058r5ed820cfmdc98f98f36d5c8ae@mail.gmail.com>
Dmitry Potapov wrote:
>On second thought, it may be not necessary. You can extract an old commit
>object, edit it, put it into Git with a new SHA1, and then use the graft file to
>replace all references from an old to a new one. And you will be able to see
>changes immediately in gitk.
Hmmmm, interesting thought. That just might solve my problem.
In that case, I will stick to extending git fsck to check grafts more
rigorously and fix git clone to *refrain* from looking at grafts.
If anyone still wants the extended format, I'd be willing to implement
it, but my immediate itch for it is gone.
--
Sincerely,
Stephen R. van den Berg.
You are confused; but this is your normal state.
^ permalink raw reply
* Re: RFC: grafts generalised
From: Stephen R. van den Berg @ 2008-07-02 17:59 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: git
In-Reply-To: <37fcd2780807021019t76008bbfq265f8bf15f59c178@mail.gmail.com>
Dmitry Potapov wrote:
>I don't think that the grafts file is the right place for this kind of
>information.
Yet the grafts file is exactly the place where this type of
"overlay-information" is being placed now. It seems to be the natural place.
> Perhaps, it would be better to have a separate file or
>even a directory with files where commit-id identifies a text file with
>a new commit object, which should be placed instead of an old one. So,
>it will be easy to tell git filter-branch to use this new information.
Not quite sure why this makes it easier. The point is that there
is not supposed to be a grafts file in a proper repository. Thus,
having a lot of these files means a larger disruption to the core, and
I'd like the core to be as efficient and lean as possible given an empty
grafts file. So I'd prefer to keep it to one file.
>However, if you want more than just ability to edit commits in a text
>file but also inspect changes using normal git commands and gitk (as it
>is possible with grafts), it will require changes to the git core, which,
>perhaps, not difficult to implement using pretend_sha1_file(), but I am
>not sure that everyone will welcome that...
I'd want to avoid a plethora of files, and the changes that can be
specified are supposed to be partial overrides, not complete rewrites.
So using pretend_sha1_file() is a bit overkill and more than I was
aiming for.
The point is, that the changes in grafts (as they are now) are *not*
used when cloning. I.e. the only thing you mess up is your *own*
repository, not someone else's. I.e. you can't make someone remote
think that the repository has been altered. That would require git
filter-branch, which immediately changes all the historical SHA1s, and
makes the changes in history blatantly visible.
--
Sincerely,
Stephen R. van den Berg.
You are confused; but this is your normal state.
^ permalink raw reply
* Re: RFC: grafts generalised
From: Dmitry Potapov @ 2008-07-02 17:58 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: git
In-Reply-To: <37fcd2780807021019t76008bbfq265f8bf15f59c178@mail.gmail.com>
On Wed, Jul 2, 2008 at 9:19 PM, Dmitry Potapov <dpotapov@gmail.com> wrote:
>
> However, if you want more than just ability to edit commits in a text
> file but also inspect changes using normal git commands and gitk (as it
> is possible with grafts), it will require changes to the git core, which,
> perhaps, not difficult to implement using pretend_sha1_file(), but I am
> not sure that everyone will welcome that...
On second thought, it may be not necessary. You can extract an old commit
object, edit it, put it into Git with a new SHA1, and then use the graft file to
replace all references from an old to a new one. And you will be able to see
changes immediately in gitk.
Dmitry
^ permalink raw reply
* Re: RFC: grafts generalised
From: Stephen R. van den Berg @ 2008-07-02 17:42 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <g4gb7a$ket$1@ger.gmane.org>
Michael J Gruber wrote:
>Maybe the upcoming git-sequencer could be the appropriate place? It
>tries to achieve just that: edit history by specifying a list of
>commands. The currently planned set of commands would need to be
That's the problem. Like git filter-branch, git sequencer needs you to
parameterise the changes, which, in my case, is hardly possible, since
the changes are randomlike.
Also, having to run the sequencer to dig 20000 commits into the past,
then change something, then come back up and rewrite all following
history and relations (parents/tags/merges) will take a sizeable amount
of time. I need something that can be changed at will, then viewed with
gitk a second later.
These edits are numerous and spread over many months, so the typical
history fixup-sessions involve periods where you make 30 random
historicaledits per hour (which need to be viewed and checked every time
immediately after making the change). And say once every 4 months, you
run it through git filter-branch to cast everything into stone. A
typical git filter-branch run takes 15 minutes on a repository this
size.
--
Sincerely,
Stephen R. van den Berg.
You are confused; but this is your normal state.
^ permalink raw reply
* Re: [PATCH 11/12] verify_path(): do not allow absolute paths
From: Johannes Schindelin @ 2008-07-02 17:31 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Junio C Hamano, Johannes Sixt, git, msysgit
In-Reply-To: <6F445BD9-CE59-435A-AAF3-F380A7BCE29E@zib.de>
Hi,
On Wed, 2 Jul 2008, Steffen Prohaska wrote:
> On Jul 2, 2008, at 6:15 PM, Johannes Schindelin wrote:
>
> >On Wed, 2 Jul 2008, Junio C Hamano wrote:
> >
> > >Steffen Prohaska <prohaska@zib.de> writes:
> > >
> > > >Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > > >Signed-off-by: Steffen Prohaska <prohaska@zib.de>
> > >
> > >No commit log message? Justification?
> >
> >Justification: adding absolute paths was not caught properly on
> >Windows, and this was the easiest patch.
> >
> >However, IIRC, in the meantime we are nice to the user, and allow
> >absolute paths (which we turn into a relative path, or error out if it
> >is not under the current working directory).
> >
> >Steffen, can you revert the patch and verify that my memory does not
> >fail me?
>
> Is
>
> git add /c/msysgit/git/read-cache.c
>
> an appropriate test?
>
> It fails with
>
> error: 'c:/msysgit/git/read-cache.c' is outside repository
>
> no matter if the commit is reverted or not.
Yes, that is enough. It proves that the patch 11/12 is unnecessary and
should be removed from 4msysgit.git.
Thanks,
Dscho
^ permalink raw reply
* Re: RFC: grafts generalised
From: Stephen R. van den Berg @ 2008-07-02 17:32 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3lk0kfdo1.fsf@localhost.localdomain>
Jakub Narebski wrote:
>First, if I remember correctly (from KernelTrap and now defunct Kernel
>Traffic and one issue of Git Traffic) the 'graft' mechanizm was
>created so it would be possible to "graft" (join) historical
>conversion repository with the "current work" git repository (started
>from zero when git was deemed good enough for Linux kernel
>development).
Quite. Which is exactly the spirit I'm extending here.
I need it to stitch together history, but it needs to be more perfect
than mere connecting parents.
Also, the graft mechanism specifically is intended as a temporary
solution until one uses filter-branch to "finalise" the result into a
proper repository which becomes cloneable.
>The fact that git-filter-branch (and earlier cg-admin-rewrite-hist)
>respects grafts, and rewrites history so that grafts are no-op and are
>not needed further is a bit of side-effect.
I beg to differ. It's not a side effect, it's the proper way to get
rid of the grafts file. Grafts are temporary and ugly. In proper
repositories they are a sign of transition to a proper state.
The proper state is attained by using git filter-branch.
> So I think that it would
>be better to provide generic git-filter-branch filter which can
>understand this "generalized grafts" file format, or rather
>'description of changes' file. Put it in contrib/, and here you
>go...
The problem is that the process of fixing history is an iterative one,
which can take many months, and everytime you make a change, the
correctness needs to be viewed using gitk.
For argument sake, consider the repository at hand which I'm trying to
"fix", it has 33000 commits, distributed over eight branches with
roughly 3500 merges over a timeperiod of 13 years.
The eight branches were eight separate CVS repositories which have
intersecting histories, and 3500 merges between CVS repositories (i.e.
branches).
If I need to backpatch a certain patch into history, it is likely that
in order to let the change ripple through, it will take 20000 commits to
be rewritten every time I make a slight change to history.
It's not really workable to ripple through 20000 commits everytime I
make a historical change, yet I need to view the change in gitk.
Using git filter-branch, or git sequencer basically has the same
problem, I need to ripple through most of history to get to a state
which is viewable using gitk again. That is too long a turnaround
cycle.
Using the proposed grafts format, I can make changes incrementally, and
immediately viewable (though not cloneable) on the local repository using gitk.
Then after making all the necessary changes, one git filter-branch run
will "burn" the changes into the repository proper in one go
(renumbering all tags, branches and merges along the way).
--
Sincerely,
Stephen R. van den Berg.
You are confused; but this is your normal state.
^ permalink raw reply
* Re: [PATCH 11/12] verify_path(): do not allow absolute paths
From: Steffen Prohaska @ 2008-07-02 17:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Johannes Sixt, git, msysgit
In-Reply-To: <alpine.DEB.1.00.0807021713290.9925@racer>
On Jul 2, 2008, at 6:15 PM, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 2 Jul 2008, Junio C Hamano wrote:
>
>> Steffen Prohaska <prohaska@zib.de> writes:
>>
>>> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
>>> Signed-off-by: Steffen Prohaska <prohaska@zib.de>
>>
>> No commit log message? Justification?
>
> Justification: adding absolute paths was not caught properly on
> Windows,
> and this was the easiest patch.
>
> However, IIRC, in the meantime we are nice to the user, and allow
> absolute
> paths (which we turn into a relative path, or error out if it is not
> under
> the current working directory).
>
> Steffen, can you revert the patch and verify that my memory does not
> fail
> me?
Is
git add /c/msysgit/git/read-cache.c
an appropriate test?
It fails with
error: 'c:/msysgit/git/read-cache.c' is outside repository
no matter if the commit is reverted or not.
Steffen
^ permalink raw reply
* Re: RFC: grafts generalised
From: Dmitry Potapov @ 2008-07-02 17:19 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: git
In-Reply-To: <20080702143519.GA8391@cuci.nl>
On Wed, Jul 02, 2008 at 04:35:19PM +0200, Stephen R. van den Berg wrote:
>_
> - Extend the grafts file format to support something like the following syntax:
>_
> commit eb03813cdb999f25628784bb4f07b3f4c8bfe3f6
> Parent: 7bc72e647d54c2f713160b22e2e08c39d86c7c28
> Merge: 3b3da24960a82a479b9ad64affab50226df02abe 13b8f53e8ccec3b08eeb6515e6a10a2a
> Merge: ac719ed37270558f21d89676fce97eab4469b0f1
> Tree: 32fc99814b97322174dbe97ec320cf32314959e2
> Author: Foo Bar (FooBar) <foo@bar>
> AuthorDate: Sat Jun 6 13:50:44 1998 +0000
> Commit: Foo Bar (FooBar) <foo@bar>
> CommitDate: Sat Jun 7 13:50:44 1998 +0000
> Logmessage: First line of logmessage override
> Logmessage: Second line of logmessage override
> Logmessage: Etc.
I don't think that the grafts file is the right place for this kind of
information. Perhaps, it would be better to have a separate file or
even a directory with files where commit-id identifies a text file with
a new commit object, which should be placed instead of an old one. So,
it will be easy to tell git filter-branch to use this new information.
However, if you want more than just ability to edit commits in a text
file but also inspect changes using normal git commands and gitk (as it
is possible with grafts), it will require changes to the git core, which,
perhaps, not difficult to implement using pretend_sha1_file(), but I am
not sure that everyone will welcome that...
Dmitry
^ permalink raw reply
* Re: [PATCH 02/12] Do not complain about "no common commits" in an empty repo
From: Johannes Schindelin @ 2008-07-02 17:07 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Junio C Hamano, Johannes Sixt, Git Mailing List, msysGit
In-Reply-To: <FCE9D8BE-BA1A-46D1-AC45-2DC4E419DE8E@zib.de>
Hi,
On Wed, 2 Jul 2008, Steffen Prohaska wrote:
> Dscho, will you send it? You are the original author.
Done,
Dscho
^ permalink raw reply
* [PATCH] git fetch-pack: do not complain about "no common commits" in an empty repo
From: Johannes Schindelin @ 2008-07-02 17:06 UTC (permalink / raw)
To: Steffen Prohaska, gitster, git
If the repo is empty, it is obvious that there are no common commits
when fetching from _anywhere_.
So there is no use in saying it in that case, and it can even be
annoying. Therefore suppress the message unilaterally if the repository
is empty prior to the fetch.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
This patch was originally developed in the 4msysgit branch.
builtin-fetch-pack.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/builtin-fetch-pack.c b/builtin-fetch-pack.c
index f4dbcf0..2175c6d 100644
--- a/builtin-fetch-pack.c
+++ b/builtin-fetch-pack.c
@@ -309,7 +309,8 @@ done:
}
flushes--;
}
- return retval;
+ /* it is no error to fetch into a completely empty repo */
+ return count ? retval : 0;
}
static struct commit_list *complete;
--
1.5.6.1.300.gca3f
^ permalink raw reply related
* Re: [PATCH 12/12] [TODO] setup: bring changes from 4msysgit/next to next
From: Steffen Prohaska @ 2008-07-02 17:08 UTC (permalink / raw)
To: Johannes Schindelin, Johannes Sixt
Cc: Git Mailing List, msysGit, Junio C Hamano, Dmitry Kakurin
In-Reply-To: <alpine.DEB.1.00.0807021716030.9925@racer>
On Jul 2, 2008, at 6:17 PM, Johannes Schindelin wrote:
> On Wed, 2 Jul 2008, Steffen Prohaska wrote:
>
>>
>> From: Johannes Sixt <johannes.sixt@telecom.at>
>>
>> Hannes,
>> You introduced "minoffset" in 861429a7c37c7.
>
> AFAICT it was redone differently in 'next', because 'next' has this
> ceiling dir thingie, which allows a different (much smaller) patch.
>
> It might be more sensible to base your patch series on 'next'...
Hmm.. it is based on next. But obviously I needed to merge
mingw's master to 4msysgit's master and resolve conflicts.
Maybe I made the wrong decisions then.
Hannes,
If you believe that your setup.c is good, then I'll copy your version
to 4msysgit's master.
Steffen
^ permalink raw reply
* Re: [PATCH 08/12] fast-import: MinGW does not have getppid(). So do not print it.
From: Johannes Schindelin @ 2008-07-02 16:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: prohaska, Johannes Sixt, git, msysgit
In-Reply-To: <7vzlp0bq2l.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 2 Jul 2008, Junio C Hamano wrote:
> Steffen Prohaska <prohaska@zib.de> writes:
>
> > diff --git a/fast-import.c b/fast-import.c
> > index e72b286..271b93c 100644
> > --- a/fast-import.c
> > +++ b/fast-import.c
> > @@ -391,7 +391,9 @@ static void write_crash_report(const char *err)
> >
> > fprintf(rpt, "fast-import crash report:\n");
> > fprintf(rpt, " fast-import process: %d\n", getpid());
> > +#ifndef __MINGW32__
> > fprintf(rpt, " parent process : %d\n", getppid());
> > +#endif
> > fprintf(rpt, " at %s\n", show_date(time(NULL), 0, DATE_LOCAL));
> > fputc('\n', rpt);
> >
> > --
> > 1.5.6.1.255.g32571
>
> It does not matter too much for this part that writes crash report, but
> keeping the file format the same across platforms will make it easier for
> tools to read output, so as a general principle, I think this is a
> suboptimal solution to the issue. How about throwing something like this
> in MinGW specific header files?
>
> #define getppid() 0
Of course, we could also implement it, using NtQueryInformationProcess()
as suggested by Google.
Ciao,
Dscho
^ permalink raw reply
* Re: RFC: grafts generalised
From: Michael J Gruber @ 2008-07-02 16:43 UTC (permalink / raw)
To: git
In-Reply-To: <m3lk0kfdo1.fsf@localhost.localdomain>
Jakub Narebski venit, vidit, dixit 02.07.2008 18:35:
> "Stephen R. van den Berg" <srb@cuci.nl> writes:
>
>> I'm in the process of converting and stitching and patching vast amounts
>> of initially disjunct CVS and SVN repositories into larger complete
>> histories inside a single git repository. Recreating history as
>> accurately as possible.
>>
>> The problem I encounter is that any number of times I have to "edit"
>> history in a non-parameterable fashion, in any of the following ways:
>> - Change parents.
>> - Add merges.
>> - Change author, committer, commitdate, authordate.
>> - Change the tree (because of conversion errors in the automated
>> conversion process) belonging to a single commit.
>> - Retrofit a patch which has to ripple through all of history until
>> the present.
>>
>> The only things which are easily done at the moment are:
>> Change parents and add merges. This can be accomplished fairly easily
>> using the grafts file.
>> The other changes are messy at best and need to be parameterised into the
>> form of a shell script so that git filter-branch can have a go at it.
> [...]
>
>> I propose the following:
>> - Extend git fsck to do more sanity checks on the content of the grafts
>> file (to make it more difficult to shoot yourself in the foot with
>> that file; my feet will be grateful).
>> - Extend the grafts file format to support something like the following syntax:
>>
>> commit eb03813cdb999f25628784bb4f07b3f4c8bfe3f6
>> Parent: 7bc72e647d54c2f713160b22e2e08c39d86c7c28
>> Merge: 3b3da24960a82a479b9ad64affab50226df02abe 13b8f53e8ccec3b08eeb6515e6a10a2a
>> Merge: ac719ed37270558f21d89676fce97eab4469b0f1
>> Tree: 32fc99814b97322174dbe97ec320cf32314959e2
>> Author: Foo Bar (FooBar) <foo@bar>
>> AuthorDate: Sat Jun 6 13:50:44 1998 +0000
>> Commit: Foo Bar (FooBar) <foo@bar>
>> CommitDate: Sat Jun 7 13:50:44 1998 +0000
>> Logmessage: First line of logmessage override
>> Logmessage: Second line of logmessage override
>> Logmessage: Etc.
> [...]
>
> First, if I remember correctly (from KernelTrap and now defunct Kernel
> Traffic and one issue of Git Traffic) the 'graft' mechanizm was
> created so it would be possible to "graft" (join) historical
> conversion repository with the "current work" git repository (started
> from zero when git was deemed good enough for Linux kernel
> development). The same mechanism is used for shallow clone, where one
> goes in the opposite direction, shortening history instead of joining
> two repositories (two histories).
>
> The fact that git-filter-branch (and earlier cg-admin-rewrite-hist)
> respects grafts, and rewrites history so that grafts are no-op and are
> not needed further is a bit of side-effect. So I think that it would
> be better to provide generic git-filter-branch filter which can
> understand this "generalized grafts" file format, or rather
> 'description of changes' file. Put it in contrib/, and here you
> go...
>
Maybe the upcoming git-sequencer could be the appropriate place? It
tries to achieve just that: edit history by specifying a list of
commands. The currently planned set of commands would need to be
amended, but the framework should be in place.
Michael
^ permalink raw reply
* Re: RFC: grafts generalised
From: Jakub Narebski @ 2008-07-02 16:35 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: git
In-Reply-To: <20080702143519.GA8391@cuci.nl>
"Stephen R. van den Berg" <srb@cuci.nl> writes:
> I'm in the process of converting and stitching and patching vast amounts
> of initially disjunct CVS and SVN repositories into larger complete
> histories inside a single git repository. Recreating history as
> accurately as possible.
>
> The problem I encounter is that any number of times I have to "edit"
> history in a non-parameterable fashion, in any of the following ways:
> - Change parents.
> - Add merges.
> - Change author, committer, commitdate, authordate.
> - Change the tree (because of conversion errors in the automated
> conversion process) belonging to a single commit.
> - Retrofit a patch which has to ripple through all of history until
> the present.
>
> The only things which are easily done at the moment are:
> Change parents and add merges. This can be accomplished fairly easily
> using the grafts file.
> The other changes are messy at best and need to be parameterised into the
> form of a shell script so that git filter-branch can have a go at it.
[...]
> I propose the following:
> - Extend git fsck to do more sanity checks on the content of the grafts
> file (to make it more difficult to shoot yourself in the foot with
> that file; my feet will be grateful).
> - Extend the grafts file format to support something like the following syntax:
>
> commit eb03813cdb999f25628784bb4f07b3f4c8bfe3f6
> Parent: 7bc72e647d54c2f713160b22e2e08c39d86c7c28
> Merge: 3b3da24960a82a479b9ad64affab50226df02abe 13b8f53e8ccec3b08eeb6515e6a10a2a
> Merge: ac719ed37270558f21d89676fce97eab4469b0f1
> Tree: 32fc99814b97322174dbe97ec320cf32314959e2
> Author: Foo Bar (FooBar) <foo@bar>
> AuthorDate: Sat Jun 6 13:50:44 1998 +0000
> Commit: Foo Bar (FooBar) <foo@bar>
> CommitDate: Sat Jun 7 13:50:44 1998 +0000
> Logmessage: First line of logmessage override
> Logmessage: Second line of logmessage override
> Logmessage: Etc.
[...]
First, if I remember correctly (from KernelTrap and now defunct Kernel
Traffic and one issue of Git Traffic) the 'graft' mechanizm was
created so it would be possible to "graft" (join) historical
conversion repository with the "current work" git repository (started
from zero when git was deemed good enough for Linux kernel
development). The same mechanism is used for shallow clone, where one
goes in the opposite direction, shortening history instead of joining
two repositories (two histories).
The fact that git-filter-branch (and earlier cg-admin-rewrite-hist)
respects grafts, and rewrites history so that grafts are no-op and are
not needed further is a bit of side-effect. So I think that it would
be better to provide generic git-filter-branch filter which can
understand this "generalized grafts" file format, or rather
'description of changes' file. Put it in contrib/, and here you
go...
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] prevent checkout from creating branches that start with a dash
From: Bart Trojanowski @ 2008-07-02 16:34 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List
In-Reply-To: <486BA0DD.5030608@viscovery.net>
* Johannes Sixt <j.sixt@viscovery.net> [080702 12:00]:
> Bart Trojanowski schrieb:
> > It was previously possible to create a -f branch with git-checkout, which
> > could not be used or deleted.
> >
> > $ git checkout -b -f master
> > Switched to a new branch "-f"
>
> "-f" *is* a valid branch name and can be used and deleted:
Thanks, that I didn't know.
-Bart
--
WebSig: http://www.jukie.net/~bart/sig/
^ permalink raw reply
* Leave git-shell in $(bindir) ?
From: Mark Burton @ 2008-07-02 16:21 UTC (permalink / raw)
To: git
Hi,
I see that the bulk of git programs are moving out of $(bindir).
Should git-shell be one of those that stay to make it easy to reference from /etc/passwd or scripts?
Cheers,
Mark
^ permalink raw reply
* Re: [msysGit] [PATCH 12/12] [TODO] setup: bring changes from 4msysgit/next to next
From: Johannes Schindelin @ 2008-07-02 16:17 UTC (permalink / raw)
To: Steffen Prohaska
Cc: Johannes Sixt, git, msysgit, Junio C Hamano, Dmitry Kakurin
In-Reply-To: <1214987532-23640-12-git-send-email-prohaska@zib.de>
Hi,
On Wed, 2 Jul 2008, Steffen Prohaska wrote:
>
> From: Johannes Sixt <johannes.sixt@telecom.at>
>
> Hannes,
> You introduced "minoffset" in 861429a7c37c7.
AFAICT it was redone differently in 'next', because 'next' has this
ceiling dir thingie, which allows a different (much smaller) patch.
It might be more sensible to base your patch series on 'next'...
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 11/12] verify_path(): do not allow absolute paths
From: Johannes Schindelin @ 2008-07-02 16:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: prohaska, Johannes Sixt, git, msysgit
In-Reply-To: <7vvdzobq0k.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 2 Jul 2008, Junio C Hamano wrote:
> Steffen Prohaska <prohaska@zib.de> writes:
>
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > Signed-off-by: Steffen Prohaska <prohaska@zib.de>
>
> No commit log message? Justification?
Justification: adding absolute paths was not caught properly on Windows,
and this was the easiest patch.
However, IIRC, in the meantime we are nice to the user, and allow absolute
paths (which we turn into a relative path, or error out if it is not under
the current working directory).
Steffen, can you revert the patch and verify that my memory does not fail
me?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 3/3] git-branch -v: show the remote tracking statistics
From: Johannes Schindelin @ 2008-07-02 15:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ingo Molnar, Bruce Stephens, git
In-Reply-To: <7vhcb8en92.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 2 Jul 2008, Junio C Hamano wrote:
> This teaches "git branch -v" to insert the remote tracking statistics in
> the form of [ours/theirs] just before the one-liner commit log message
> for the branch.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> ... which means that you would see something like this.
>
> * jc/report-tracking 41666f7 [3/117] git-branch -v: show the remo...
Actually, I would like to have something like
$ git branch --explain-relationship master next
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] prevent checkout from creating branches that start with a dash
From: Johannes Sixt @ 2008-07-02 15:38 UTC (permalink / raw)
To: Bart Trojanowski; +Cc: Git Mailing List
In-Reply-To: <20080702150128.GH26300@jukie.net>
Bart Trojanowski schrieb:
> It was previously possible to create a -f branch with git-checkout, which
> could not be used or deleted.
>
> $ git checkout -b -f master
> Switched to a new branch "-f"
"-f" *is* a valid branch name and can be used and deleted:
$ git checkout -b -f next
Switched to a new branch "-f"
$ git checkout next
Switched to branch "next"
Your branch is ahead of the tracked remote branch 'origin/next' by 2 commits.
$ git checkout -- -f
Switched to branch "-f"
$ git checkout next
Switched to branch "next"
Your branch is ahead of the tracked remote branch 'origin/next' by 2 commits.
$ git branch -d -- -f
Deleted branch -f.
-- Hannes
^ 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