* Re: Rollback of git commands
From: Jon Smirl @ 2007-11-28 17:03 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Sean, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.0.99999.0711281141150.9605@xanadu.home>
On 11/28/07, Nicolas Pitre <nico@cam.org> wrote:
> On Wed, 28 Nov 2007, Jon Smirl wrote:
>
> > On 11/28/07, Nicolas Pitre <nico@cam.org> wrote:
> > > On Wed, 28 Nov 2007, Jon Smirl wrote:
> > >
> > > > On 11/28/07, Nicolas Pitre <nico@cam.org> wrote:
> > > > > On Tue, 27 Nov 2007, Jon Smirl wrote:
> > > > >
> > > > > > Of course you've never screwed up a repository using git commands,
> > > > > > right? I've messed up plenty. A good way to mess up a repo is to get
> > > > > > the data in .git/* out of sync with what is in the repo. I'm getting
> > > > > > good enough with git that I can fix most mess up with a few edits, but
> > > > > > it took me two years to get to that point. Rolling back to a check
> > > > > > point is way easier. User error and a command failing are both equally
> > > > > > valid ways to mess up a repo.
> > > > >
> > > > > The reflog contains all your check points, for every modifications you
> > > > > make, even the stupid ones. You should look at it.
> > > >
> > > > The state contained in the other config files in .git/* is not getting
> > > > check pointed. I can use reflog to move my branch heads around. But
> > > > doing that does not undo the changes to the state recorded in .git/*.
> > > > After the error I encountered I moved my branch head back, but the
> > > > state stgit had stored in .git/* was out of sync with where the branch
> > > > had been moved to.
> > >
> > > It's up to stgit to version control its state then. It may even use a
> > > reflog for it. All the machinery is there already.
> >
> > Git has state in .git/* too, shouldn't it be version controlling it
> > too? If git was version controlling the state in .git/* you'd have
> > checkpoints with the ability to roll back.
>
> Well, the .git directory contains data to identify what is actually
> version controlled. If you start versioning the data used to implement
> the versioning, don't you get into endless recursion here?
You would end up with a single non-version controlled sha pointer that
would need to be stored externally. That pointer would be the
beginning of the rollback log. It's just a normal commit chain.
In a totally version controlled system. .git/* would only contain
objects and the one pointer to the current state of the system.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: The 5th issue of the msysGit Herald
From: Jakub Narebski @ 2007-11-28 17:03 UTC (permalink / raw)
To: Julian Phillips; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0711281632510.1706@kaos.quantumfyre.co.uk>
On Tue, 28 Nov 2007, Julian Phillips wrote:
> On Tue, 13 Nov 2007, Jakub Narebski wrote:
>> What I meant to have on blog, or rather in feed was those "What's in...",
>> "What's cooking...", "[ANNOUNCE]..." and "msysGit Herald" posts, not
>> git traffic digest. Because while I think first can be automated and
>> does not need manual intervention, doing the digest... well...
>
> Something like this perhaps?
>
> http://gitrss.q42.co.uk/
Thanks a lot!
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Do check_repository_format() early
From: Johannes Schindelin @ 2007-11-28 17:05 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Junio C Hamano
In-Reply-To: <20071128165837.GA5903@laptop>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 555 bytes --]
Hi,
On Wed, 28 Nov 2007, Nguyễn Thái Ngọc Duy wrote:
> @@ -246,8 +246,13 @@ const char *setup_git_directory_gently(int *nongit_ok)
> static char buffer[1024 + 1];
> const char *retval;
>
> - if (!work_tree_env)
> - return set_work_tree(gitdirenv);
> + if (!work_tree_env) {
> + retval = set_work_tree(gitdirenv);
> + /* config may override worktree */
> + check_repository_format();
> + return retval;
> + }
> + check_repository_format();
Why not move this check before the if? Other than that, ACK.
Ciao,
Dscho
^ permalink raw reply
* Re: StGit hooks
From: Andreas Ericsson @ 2007-11-28 17:06 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Jon Smirl, Git Mailing List
In-Reply-To: <20071128154059.GA19302@diana.vm.bytemark.co.uk>
Karl Hasselström wrote:
> On 2007-11-28 15:58:13 +0100, Andreas Ericsson wrote:
>
>> Jon Smirl wrote:
>>
>>> I would expect 'stg init' to switch the branch to using the stgit
>>> hooks and only those hooks. Branches that were not inited would
>>> continue to use the user hooks. I don't have any user hooks, but
>>> this is what I would expect to happen.
>> Obviously the stgit-installed hook will have to check if the branch
>> the user is operating on is managed by stgit before it prevents git
>> rebase (or whatever it's supposed to do).
>
> Yes. The point is, hooks are per repository, not per branch. So
> there's no concept of "replacing the hooks for just this one branch".
>
True, but there are ways of figuring out which branch you're on, using
the arguments passed to the hook.
The rebase hook (which is where this discussion started) gets the
branches passed to "git rebase" as arguments. Figuring out if either
of those branches are actually under stgit control shouldn't be overly
tricky for one so familiar with stgit as yourself.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Do check_repository_format() early
From: Nguyen Thai Ngoc Duy @ 2007-11-28 17:10 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0711281703470.27959@racer.site>
On Nov 29, 2007 12:05 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Wed, 28 Nov 2007, Nguyen Thai Ngoc Duy wrote:
>
> > @@ -246,8 +246,13 @@ const char *setup_git_directory_gently(int *nongit_ok)
> > static char buffer[1024 + 1];
> > const char *retval;
> >
> > - if (!work_tree_env)
> > - return set_work_tree(gitdirenv);
> > + if (!work_tree_env) {
> > + retval = set_work_tree(gitdirenv);
> > + /* config may override worktree */
> > + check_repository_format();
> > + return retval;
> > + }
> > + check_repository_format();
>
> Why not move this check before the if? Other than that, ACK.
If so it would be called twice if work_tree_env is not set.
> Ciao,
> Dscho
>
--
Duy
^ permalink raw reply
* Re: [PATCH] Do check_repository_format() early
From: Johannes Schindelin @ 2007-11-28 17:18 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git, Junio C Hamano
In-Reply-To: <fcaeb9bf0711280910x40fecdd5mf6d86e4a9b656d01@mail.gmail.com>
Hi,
On Thu, 29 Nov 2007, Nguyen Thai Ngoc Duy wrote:
> On Nov 29, 2007 12:05 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> > On Wed, 28 Nov 2007, Nguyen Thai Ngoc Duy wrote:
> >
> > > @@ -246,8 +246,13 @@ const char *setup_git_directory_gently(int *nongit_ok)
> > > static char buffer[1024 + 1];
> > > const char *retval;
> > >
> > > - if (!work_tree_env)
> > > - return set_work_tree(gitdirenv);
> > > + if (!work_tree_env) {
> > > + retval = set_work_tree(gitdirenv);
> > > + /* config may override worktree */
> > > + check_repository_format();
> > > + return retval;
> > > + }
> > > + check_repository_format();
> >
> > Why not move this check before the if? Other than that, ACK.
>
> If so it would be called twice if work_tree_env is not set.
Well, I would have left the original
if (!work_tree_env)
return set_work_tree(gitdirenv);
alone...
If that is not possible, it might be good to add a comment as to why.
Ciao,
Dscho
^ permalink raw reply
* Re: stgit: lost all my patches again
From: Karl Hasselström @ 2007-11-28 17:19 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910711280858j5d03b3acleac0ece7b0a67f66@mail.gmail.com>
On 2007-11-28 11:58:14 -0500, Jon Smirl wrote:
> After someone runs the wrong command their first instinct will be to
> run stg repair. Can stg repair be made smart enough to not attempt a
> repair if it is unable to do so and print a message referring people
> back to the manual on how to move the head back?
Well, the thing is, it's never unable to repair.
However, I could add another repair mode: reset the branch head to the
latest point in the reflog where it was consistent with StGit's
metadata.
repair would have two flags to select the original or this new repair
mode, and if the user doesn't give either flag, repair points out that
she has two choices, and what they mean:
"If you want to undo the last 3 git commands
pull : Fast forward
commit (amend): fix
reset --hard kha/experimental: updating HEAD
call stg repair --undo. If you want StGit to adjust to the new
situation, call stg repair --assimilate."
> When I ran stg repair after the wrong git rebase command, I
> compounded the problem further.
Not that much. It was the push following the repair that killed you.
The repair alone is totally benign; doing
$ stg repair && git reset --hard foobar && stg repair
gives the same result as just
$ git reset --hard foobar && stg repair
except for creating a few new patches that you can safely delete.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: StGit hooks
From: Karl Hasselström @ 2007-11-28 17:21 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Jon Smirl, Git Mailing List
In-Reply-To: <474DA01C.8010901@op5.se>
On 2007-11-28 18:06:36 +0100, Andreas Ericsson wrote:
> True, but there are ways of figuring out which branch you're on,
> using the arguments passed to the hook.
>
> The rebase hook (which is where this discussion started) gets the
> branches passed to "git rebase" as arguments. Figuring out if either
> of those branches are actually under stgit control shouldn't be
> overly tricky for one so familiar with stgit as yourself.
No, that part is trivial. The hard part is not messing up the user's
existing hook scripts.
If I do go ahead and do this, I have a feeling I'll be beefing up
git's hook dispatch mechanism first -- if I can get it past Junio,
obviously. :-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] Do check_repository_format() early
From: Nguyen Thai Ngoc Duy @ 2007-11-28 17:24 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0711281717460.27959@racer.site>
On Nov 29, 2007 12:18 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Thu, 29 Nov 2007, Nguyen Thai Ngoc Duy wrote:
>
> > On Nov 29, 2007 12:05 AM, Johannes Schindelin
> > <Johannes.Schindelin@gmx.de> wrote:
> > >
> > > On Wed, 28 Nov 2007, Nguyen Thai Ngoc Duy wrote:
> > >
> > > > @@ -246,8 +246,13 @@ const char *setup_git_directory_gently(int *nongit_ok)
> > > > static char buffer[1024 + 1];
> > > > const char *retval;
> > > >
> > > > - if (!work_tree_env)
> > > > - return set_work_tree(gitdirenv);
> > > > + if (!work_tree_env) {
> > > > + retval = set_work_tree(gitdirenv);
> > > > + /* config may override worktree */
> > > > + check_repository_format();
> > > > + return retval;
> > > > + }
> > > > + check_repository_format();
> > >
> > > Why not move this check before the if? Other than that, ACK.
> >
> > If so it would be called twice if work_tree_env is not set.
>
> Well, I would have left the original
>
> if (!work_tree_env)
> return set_work_tree(gitdirenv);
>
> alone...
>
> If that is not possible, it might be good to add a comment as to why.
I did, and the tests failed. I also added a comment "config may
override worktree". set_work_tree() will reset git_work_tree_cfg but
the correct behaviour is config takes precedence (from comment of
set_work_tree). The comment is clearly not clear enough. Maybe this?
+ if (!work_tree_env) {
+ retval = set_work_tree(gitdirenv);
+ /* config may override worktree (see
set_work_tree comment) */
+ check_repository_format();
+ return retval;
+ }
> Ciao,
> Dscho
>
>
--
Duy
^ permalink raw reply
* Re: git guidance
From: Al Boldi @ 2007-11-28 17:14 UTC (permalink / raw)
To: Johannes Schindelin, Rogan Dawes; +Cc: git, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0711281545170.27959@racer.site>
Johannes Schindelin wrote:
> Hi,
Hi!
git@vger sometimes bounces, so let's leave lkml as backup.
> On Wed, 28 Nov 2007, Rogan Dawes wrote:
> > Al Boldi wrote:
> > > Willy Tarreau wrote:
> > > > It should not turn into an endless thread led by people who want to
> > > > redefine GIT's roadmap, but experience sharing helps a lot with GIT.
> > >
> > > Well, now that you mentioned it, if there is one thing I dislike, it's
> > > for version control to start mutilating your sources. Version Control
> > > should be completely transparent. GIT isn't.
> >
> > Care to explain? Git is quite happy handling arbitrary binary content,
> > so I find it difficult to believe that it is changing your source code
> > in strange ways.
>
> It is nice of you to ask him to explain: Unless this handwaving claim is
> substantiated, it is quite hard to argue with.
Sure, the problem with GIT is that it stores the sources inside a backend
container that is only accessible via GIT; iow, you can't retrieve your
sources directly / transparently.
One way to achieve transparency could be to allow mounting GIT on a dir-mount
point. And just use that dir normally, while GIT manages all the rest in
the background.
Thanks!
--
Al
^ permalink raw reply
* Re: can't commit files that have been git add'ed because "fatal: you need to resolve your current index first"
From: Jakub Narebski @ 2007-11-28 18:11 UTC (permalink / raw)
To: Bill Priest; +Cc: git
In-Reply-To: <993937.9873.qm@web55013.mail.re4.yahoo.com>
Bill Priest wrote:
> I understand what git is doing in terms of trying to
> merge. But it sounds like it is enforcing policy on
> the merge by not allowing me to check in files as I
> resolve them. I have two separate branches w/ a
> similar but not identical hardware platform where I
> will always get conflicts when I merge back and forth.
> Usually I cherry-pick between the two branches and
> this works until there are massive changes on one
> branch w/o time to move the changes to the other. In
> the latter case I do a merge and live w/ resolving
> conflicts.I guess w/ this workflow I have more
> conflicts than is "normal".
>
> It seems pretty heavy handed to force all merges to be
> complete before I can commit any files; git knows
> which files are unmerged. Does git track which files
> have been merged w/ conflicts? I'd like the option to
> be able to check in files that I have indicated have
> conflicts resolved (maybe w/ a flag to bypass the
> checking).
Yes, git does track which files have conflict, but I don't
think it does track which files were merged on file-level
without conflicts.
The problem is that git remember which files are yet not
resolved, and remembers that it is in the middle of the
merge by remembering parents of a merge. So I think if you
want to commit before doing merge, you would have to move
MERGE_HEAD away, and commit specifying paths using
"git commit <file1> <file2>". Or you can always resort
to low-level plumbing, for example creating temporary
staging area (index) etc.
But if you want to just make some commit to be cherry-picked
for example before merge, I think it would be easier to just
stash away merge, do a commit, then unstash it.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Do check_repository_format() early
From: Johannes Schindelin @ 2007-11-28 18:11 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git, Junio C Hamano
In-Reply-To: <fcaeb9bf0711280924v34160eddsf8a75f8f8cee389c@mail.gmail.com>
Hi,
On Thu, 29 Nov 2007, Nguyen Thai Ngoc Duy wrote:
> The comment is clearly not clear enough. Maybe this?
>
> + if (!work_tree_env) {
> + retval = set_work_tree(gitdirenv);
> + /* config may override worktree (see
> set_work_tree comment) */
> + check_repository_format();
> + return retval;
> + }
Perfect. Please make it so, and add my ACK.
Thanks,
Dscho
^ permalink raw reply
* Re: git guidance
From: Johannes Schindelin @ 2007-11-28 18:14 UTC (permalink / raw)
To: Al Boldi; +Cc: Rogan Dawes, git, linux-kernel
In-Reply-To: <200711282014.27299.a1426z@gawab.com>
Hi,
On Wed, 28 Nov 2007, Al Boldi wrote:
> git@vger sometimes bounces, so let's leave lkml as backup.
Fair enough.
> Johannes Schindelin wrote:
> > On Wed, 28 Nov 2007, Rogan Dawes wrote:
> > > Al Boldi wrote:
> > > > Willy Tarreau wrote:
> > > > > It should not turn into an endless thread led by people who want
> > > > > to redefine GIT's roadmap, but experience sharing helps a lot
> > > > > with GIT.
> > > >
> > > > Well, now that you mentioned it, if there is one thing I dislike,
> > > > it's for version control to start mutilating your sources.
> > > > Version Control should be completely transparent. GIT isn't.
> > >
> > > Care to explain? Git is quite happy handling arbitrary binary
> > > content, so I find it difficult to believe that it is changing your
> > > source code in strange ways.
> >
> > It is nice of you to ask him to explain: Unless this handwaving claim
> > is substantiated, it is quite hard to argue with.
>
> Sure, the problem with GIT is that it stores the sources inside a
> backend container that is only accessible via GIT; iow, you can't
> retrieve your sources directly / transparently.
That is a very funny way to define a "transparent SCM". Are you
complaining about SQL servers being "not transparent"?
By that definition, no SCM, not even CVS, is transparent. Nothing short
of unpacked directories of all versions (wasting a lot of disk space)
would.
IOW the issue you raised is a non-issue.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Document all help keys in "git add -i" patch mode.
From: Ralf Wildenhues @ 2007-11-28 18:21 UTC (permalink / raw)
To: git
---
Documentation/git-add.txt | 2 ++
git-add--interactive.perl | 1 +
2 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 63829d9..f4aad90 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -210,6 +210,8 @@ patch::
k - do not decide on this hunk now, and view the previous
undecided hunk
K - do not decide on this hunk now, and view the previous hunk
+ s - split the current hunk into smaller hunks
+ ? - print help
+
After deciding the fate for all hunks, if there is any hunk
that was chosen, the index is updated with the selected hunks.
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index fb1e92a..613cf3c 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -551,6 +551,7 @@ J - leave this hunk undecided, see next hunk
k - leave this hunk undecided, see previous undecided hunk
K - leave this hunk undecided, see previous hunk
s - split the current hunk into smaller hunks
+? - print help
EOF
}
--
1.5.3.6.959.g1ab5
^ permalink raw reply related
* Cover grafting in the Git User's Manual
From: Markus Armbruster @ 2007-11-28 18:23 UTC (permalink / raw)
To: git
The only mention of grafting in the manual is in the glossary:
Grafts enables two otherwise different lines of development to
be joined together by recording fake ancestry information for
commits. This way you can make git pretend the set of parents
a commit has is different from what was recorded when the
commit was created. Configured via the .git/info/grafts file.
I believe it would be useful to cover this better, perhaps in chapter
5. Rewriting history and maintaining patch series. It certainly would
have saved me a few hours of digging. I already understood enough of
git to *know* that what I wanted must be possible (supply missing
parents of merges in a repository imported with parsecvs), but I
didn't know the magic keyword was graft. I managed to figure it out
from the glossary, git-filter-branch(1) and GitWiki's GraftPoint page.
I'm neither writer nor git expert, but here's my try anyway:
Rewriting ancestry with grafts
Grafts enables two otherwise different lines of development to be
joined together by recording fake ancestry information for commits.
This way you can make git pretend the set of parents a commit has is
different from what was recorded when the commit was created.
Why would you want to do that? Say, you imported a repository from an
SCM that doesn't record merges properly, e.g. CVS. Grafts let you add
the missing parents to the merge commits. Or you switched your
project to git by populating a new repository with current sources,
and later decide you want more history. Committing old versions is
easy enough, but you also need to graft a parent to your original root
commit.
Graft points are configured via the .git/info/grafts file. It has one
record per line describing a commit and its fake parents by listing
object names separated by a space and terminated by a newline.
<commit sha1> <parent sha1> [<parent sha1>]*
A graft point does not actually change its commit. Nothing can. What
can be done is rewriting the commit and its descendants.
git-filter-branch does that:
$ cat .git/info/grafts
db5a561750ae87615719ae409d1f50c9dfc3fa71 08f2fa81d104b937c1f24c68f56e9d5039356764 8c231303bb995cbfdfd1c434a59a7c96ea2f0251
git-filter-branch HEAD ^08f2fa81d104b937c1f24c68f56e9d5039356764 ^8c231303bb995cbfdfd1c434a59a7c96ea2f0251
This rewrites history between head and the graft-point to include the
grafted parents.
^ permalink raw reply
* Re: git guidance
From: Al Boldi @ 2007-11-28 18:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Rogan Dawes, git, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0711281811500.27959@racer.site>
Johannes Schindelin wrote:
> By that definition, no SCM, not even CVS, is transparent. Nothing short
> of unpacked directories of all versions (wasting a lot of disk space)
> would.
Who said anything about unpacking?
I'm talking about GIT transparently serving a Virtual Version Control dir to
be mounted on the client.
Thanks!
--
Al
^ permalink raw reply
* Re: Rollback of git commands
From: Sergei Organov @ 2007-11-28 18:39 UTC (permalink / raw)
To: Ingo Molnar; +Cc: David Symonds, Jon Smirl, Junio C Hamano, Git Mailing List
In-Reply-To: <20071128165033.GA31218@elte.hu>
Ingo Molnar <mingo@elte.hu> writes:
> * David Symonds <dsymonds@gmail.com> wrote:
>
>> On Nov 28, 2007 12:49 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
>> > Rollback is too strong of name for this. Checkpoints would be better.
>> > The idea is to record the total system state at convenient moments and
>> > then allow moving back to the checkpointed state. The object store
>> > supports this, but the rest of the state in .git/* isn't being
>> > recorded.
>>
>> rsync -a .git /somewhere/safe
>>
>> I fear that what you ask becomes a chicken-and-egg scenario: where/how
>> is this checkpointing information going to be stored? If it's tightly
>> integrated with Git, what happens when you want to roll-back a
>> checkpoint-restore?
>
> well, it would/could be the normal undo/redo semantics of editors: you
> can undo-redo in a linear history fashion, in an unlimited way, but the
> moment you modify any past point of history then the redo future is
> overriden. (but the 'past' up to that point is still recorded and
> available)
Or it could be Emacs-like: 'undo' is just another operation that is a
subject for further undo's ;) Then there is no need for 'redo', and no
need to override either the future or the past. Besides this obvious
technical superiority will help to maintain git's reputation of being
hard to grok ;)
--
Sergei.
^ permalink raw reply
* Re: git guidance
From: Jakub Narebski @ 2007-11-28 18:41 UTC (permalink / raw)
To: git; +Cc: linux-kernel
In-Reply-To: <200711282130.12864.a1426z@gawab.com>
Al Boldi wrote:
> Johannes Schindelin wrote:
>> By that definition, no SCM, not even CVS, is transparent. Nothing short
>> of unpacked directories of all versions (wasting a lot of disk space)
>> would.
>
> Who said anything about unpacking?
>
> I'm talking about GIT transparently serving a Virtual Version Control dir to
> be mounted on the client.
Are you talking about something like (in alpha IIRC) gitfs?
http://www.sfgoth.com/~mitch/linux/gitfs/
Besides, you can always use "git show <revision>:<file>". For example
gitweb (and I think other web interfaces) can show any version of a file
or a directory, accessing only repository.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Cover grafting in the Git User's Manual
From: Peter Baumann @ 2007-11-28 18:42 UTC (permalink / raw)
To: Markus Armbruster; +Cc: git
In-Reply-To: <87ejeateka.fsf@pike.pond.sub.org>
On Wed, Nov 28, 2007 at 07:23:01PM +0100, Markus Armbruster wrote:
> The only mention of grafting in the manual is in the glossary:
>
> Grafts enables two otherwise different lines of development to
> be joined together by recording fake ancestry information for
> commits. This way you can make git pretend the set of parents
> a commit has is different from what was recorded when the
> commit was created. Configured via the .git/info/grafts file.
>
> I believe it would be useful to cover this better, perhaps in chapter
> 5. Rewriting history and maintaining patch series. It certainly would
> have saved me a few hours of digging. I already understood enough of
> git to *know* that what I wanted must be possible (supply missing
> parents of merges in a repository imported with parsecvs), but I
> didn't know the magic keyword was graft. I managed to figure it out
> >from the glossary, git-filter-branch(1) and GitWiki's GraftPoint page.
>
> I'm neither writer nor git expert, but here's my try anyway:
>
> Rewriting ancestry with grafts
>
> Grafts enables two otherwise different lines of development to be
> joined together by recording fake ancestry information for commits.
> This way you can make git pretend the set of parents a commit has is
> different from what was recorded when the commit was created.
>
> Why would you want to do that? Say, you imported a repository from an
> SCM that doesn't record merges properly, e.g. CVS. Grafts let you add
> the missing parents to the merge commits. Or you switched your
> project to git by populating a new repository with current sources,
> and later decide you want more history. Committing old versions is
> easy enough, but you also need to graft a parent to your original root
> commit.
>
> Graft points are configured via the .git/info/grafts file. It has one
> record per line describing a commit and its fake parents by listing
> object names separated by a space and terminated by a newline.
>
> <commit sha1> <parent sha1> [<parent sha1>]*
>
> A graft point does not actually change its commit. Nothing can. What
> can be done is rewriting the commit and its descendants.
> git-filter-branch does that:
>
> $ cat .git/info/grafts
> db5a561750ae87615719ae409d1f50c9dfc3fa71 08f2fa81d104b937c1f24c68f56e9d5039356764 8c231303bb995cbfdfd1c434a59a7c96ea2f0251
> git-filter-branch HEAD ^08f2fa81d104b937c1f24c68f56e9d5039356764 ^8c231303bb995cbfdfd1c434a59a7c96ea2f0251
>
> This rewrites history between head and the graft-point to include the
> grafted parents.
Did I overlook something or isn't
git-filter-branch HEAD ^db5a561750ae87615719ae409d1f50c9dfc3fa71
what you are looking for? Only db5a56 could get rewritten and obviously
all the commits having it as a parent.
-Peter
^ permalink raw reply
* Re: Rebase/cherry-picking idea
From: Junio C Hamano @ 2007-11-28 18:44 UTC (permalink / raw)
To: Wincent Colaiuta
Cc: Johannes Schindelin, Johannes Sixt, Benoit Sigoure,
Git Mailing List
In-Reply-To: <1570EAD5-9F47-4105-B3DA-49CA6FA57369@wincent.com>
Wincent Colaiuta <win@wincent.com> writes:
> I'm still a little concerned that nobody commented when I pointed out
> that export VAR=VAL is used elsewhere in Git, especially in git-
> clone.sh, which is very commonly-used porcelain. Is it a problem?
We are waiting to find out, aren't we, after having the discussion.
^ permalink raw reply
* Re: [PATCH] Replace instances of export VAR=VAL with VAR=VAL; export VAR
From: Junio C Hamano @ 2007-11-28 18:49 UTC (permalink / raw)
To: Johannes Sixt
Cc: Johannes Schindelin, Wincent Colaiuta, Benoit Sigoure,
Git Mailing List
In-Reply-To: <474D7D92.2000106@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Johannes Schindelin schrieb:
> ...
>>> Recently there was a report that \n in the substitution side of s/// is not
>>> supported by all seds :-(
>>
>> Okay, how about replacing the line with
>>
>> + s/.*/GIT_'$uid'_NAME='\''&'\''\
>> +export GIT_'$uid'_NAME/p
>>
>> Hmm? (It works here.)
>
> This looks good. The other case I'm refering to was also solved in this way.
That looks ugly to me.
Is there a particular reason to force linebreak when a semicolon would
do?
^ permalink raw reply
* Re: Rollback of git commands
From: Nicolas Pitre @ 2007-11-28 18:52 UTC (permalink / raw)
To: Sergei Organov
Cc: Ingo Molnar, David Symonds, Jon Smirl, Junio C Hamano,
Git Mailing List
In-Reply-To: <87lk8imcxv.fsf@osv.gnss.ru>
On Wed, 28 Nov 2007, Sergei Organov wrote:
> Ingo Molnar <mingo@elte.hu> writes:
>
> > well, it would/could be the normal undo/redo semantics of editors: you
> > can undo-redo in a linear history fashion, in an unlimited way, but the
> > moment you modify any past point of history then the redo future is
> > overriden. (but the 'past' up to that point is still recorded and
> > available)
>
> Or it could be Emacs-like: 'undo' is just another operation that is a
> subject for further undo's ;) Then there is no need for 'redo', and no
> need to override either the future or the past.
The reflog does just that in fact, when it records your 'git reset'
operations.
> Besides this obvious technical superiority will help to maintain git's
> reputation of being hard to grok ;)
Sure! ;)
Nicolas
^ permalink raw reply
* [PATCH 1/3] Add basic cvsimport tests
From: Jeff King @ 2007-11-28 18:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Emanuele Giaquinta, git
In-Reply-To: <20071128185504.GA11236@coredump.intra.peff.net>
We weren't even testing basic things before, so let's at
least try importing and updating a trivial repository, which
will catch total breakage.
Signed-off-by: Jeff King <peff@peff.net>
---
t/t9600-cvsimport.sh | 99 ++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 99 insertions(+), 0 deletions(-)
create mode 100755 t/t9600-cvsimport.sh
diff --git a/t/t9600-cvsimport.sh b/t/t9600-cvsimport.sh
new file mode 100755
index 0000000..1ee06bb
--- /dev/null
+++ b/t/t9600-cvsimport.sh
@@ -0,0 +1,99 @@
+#!/bin/sh
+
+test_description='git-cvsimport basic tests'
+. ./test-lib.sh
+
+if ! ( type cvs && type cvsps ) >/dev/null 2>&1
+then
+ test_expect_success 'skipping cvsimport tests, cvs/cvsps not found' ''
+ test_done
+ exit
+fi
+
+CVSROOT=$(pwd)/cvsroot
+export CVSROOT
+# for clean cvsps cache
+HOME=$(pwd)
+export HOME
+
+test_expect_success 'setup cvsroot' 'cvs init'
+
+test_expect_success 'setup a cvs module' '
+
+ mkdir $CVSROOT/module &&
+ cvs co -d module-cvs module &&
+ cd module-cvs &&
+ cat <<EOF >o_fortuna &&
+O Fortuna
+velut luna
+statu variabilis,
+
+semper crescis
+aut decrescis;
+vita detestabilis
+
+nunc obdurat
+et tunc curat
+ludo mentis aciem,
+
+egestatem,
+potestatem
+dissolvit ut glaciem.
+EOF
+ cvs add o_fortuna &&
+ cat <<EOF >message &&
+add "O Fortuna" lyrics
+
+These public domain lyrics make an excellent sample text.
+EOF
+ cvs commit -F message &&
+ cd ..
+'
+
+test_expect_success 'import a trivial module' '
+
+ git cvsimport -a -z 0 -C module-git module &&
+ git diff module-cvs/o_fortuna module-git/o_fortuna
+
+'
+
+test_expect_success 'update cvs module' '
+
+ cd module-cvs &&
+ cat <<EOF >o_fortuna &&
+O Fortune,
+like the moon
+you are changeable,
+
+ever waxing
+and waning;
+hateful life
+
+first oppresses
+and then soothes
+as fancy takes it;
+
+poverty
+and power
+it melts them like ice.
+EOF
+ cat <<EOF >message &&
+translate to English
+
+My Latin is terrible.
+EOF
+ cvs commit -F message &&
+ cd ..
+'
+
+test_expect_success 'update git module' '
+
+ cd module-git &&
+ git cvsimport -a -z 0 module &&
+ git merge origin &&
+ cd .. &&
+ git diff module-cvs/o_fortuna module-git/o_fortuna
+
+'
+
+test_done
--
1.5.3.6.2039.g0495
^ permalink raw reply related
* Re: git-cvsimport bug
From: Jeff King @ 2007-11-28 18:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Emanuele Giaquinta, git
In-Reply-To: <20071128165746.GC20308@coredump.intra.peff.net>
On Wed, Nov 28, 2007 at 11:57:46AM -0500, Jeff King wrote:
> Some of git-cvsimport is quite old, and it accesses the ref files
> directly. It should be fairly easy to fix; I will post a patch in a few
> minutes.
The patch series is:
1/3: Add basic cvsimport tests
We had no tests before, so this at least gives a sanity check. I
added a t9600 series, though perhaps the cvs-related tests
(cvsserver and exportcommit) should collapse to a single t9[0-9]*
series.
2/3: cvsimport: use show-ref to support packed refs
This fix is hopefully obvious, and the included test fails
without it (and this should probably fix Emanuele's problem).
3/3: cvsimport: miscellaneous packed-ref fixes
This fixes all of the packed-ref problem spots I could find.
However, I have no tests that show the problems or that verify
that the fixes are sane. So apply with caution.
Probably cvsimport would benefit greatly from a conversion to
Git.pm, but that is likely to involve a lot of rewriting, and I
have neither the time nor the inclination for that right now.
-Peff
^ permalink raw reply
* [PATCH 2/3] cvsimport: use show-ref to support packed refs
From: Jeff King @ 2007-11-28 18:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Emanuele Giaquinta, git
In-Reply-To: <20071128185504.GA11236@coredump.intra.peff.net>
Previously, if refs were packed, git-cvsimport would assume
that particular refs did not exist. This could lead to, for
example, overwriting previous 'origin' commits that were
packed.
Signed-off-by: Jeff King <peff@peff.net>
---
git-cvsimport.perl | 24 +++++++++---------------
t/t9600-cvsimport.sh | 2 ++
2 files changed, 11 insertions(+), 15 deletions(-)
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index efa6a0c..b852f2f 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -527,18 +527,12 @@ sub is_sha1 {
return $s =~ /^[a-f0-9]{40}$/;
}
-sub get_headref ($$) {
- my $name = shift;
- my $git_dir = shift;
-
- my $f = "$git_dir/$remote/$name";
- if (open(my $fh, $f)) {
- chomp(my $r = <$fh>);
- is_sha1($r) or die "Cannot get head id for $name ($r): $!";
- return $r;
- }
- die "unable to open $f: $!" unless $! == POSIX::ENOENT;
- return undef;
+sub get_headref ($) {
+ my $name = shift;
+ my $r = `git show-ref -s '$name'`;
+ return undef unless $? == 0;
+ chomp $r;
+ return $r;
}
-d $git_tree
@@ -698,7 +692,7 @@ my (@old,@new,@skipped,%ignorebranch);
$ignorebranch{'#CVSPS_NO_BRANCH'} = 1;
sub commit {
- if ($branch eq $opt_o && !$index{branch} && !get_headref($branch, $git_dir)) {
+ if ($branch eq $opt_o && !$index{branch} && !get_headref($branch)) {
# looks like an initial commit
# use the index primed by git-init
$ENV{GIT_INDEX_FILE} = "$git_dir/index";
@@ -722,7 +716,7 @@ sub commit {
update_index(@old, @new);
@old = @new = ();
my $tree = write_tree();
- my $parent = get_headref($last_branch, $git_dir);
+ my $parent = get_headref($last_branch);
print "Parent ID " . ($parent ? $parent : "(empty)") . "\n" if $opt_v;
my @commit_args;
@@ -733,7 +727,7 @@ sub commit {
foreach my $rx (@mergerx) {
next unless $logmsg =~ $rx && $1;
my $mparent = $1 eq 'HEAD' ? $opt_o : $1;
- if (my $sha1 = get_headref($mparent, $git_dir)) {
+ if (my $sha1 = get_headref($mparent)) {
push @commit_args, '-p', $mparent;
print "Merge parent branch: $mparent\n" if $opt_v;
}
diff --git a/t/t9600-cvsimport.sh b/t/t9600-cvsimport.sh
index 1ee06bb..3338d44 100755
--- a/t/t9600-cvsimport.sh
+++ b/t/t9600-cvsimport.sh
@@ -57,6 +57,8 @@ test_expect_success 'import a trivial module' '
'
+test_expect_success 'pack refs' 'cd module-git && git gc && cd ..'
+
test_expect_success 'update cvs module' '
cd module-cvs &&
--
1.5.3.6.2039.g0495
^ permalink raw reply related
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