* 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
* [PATCH] Do check_repository_format() early
From: Nguyễn Thái Ngọc Duy @ 2007-11-28 16:58 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Junio C Hamano
Repository version check is only performed when
setup_git_directory() is called. This makes sure
setup_git_directory_gently() does the check too.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
My worktree work still not done yet, so push this first.
setup.c | 12 +++++++++---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/setup.c b/setup.c
index faf4137..19a8a77 100644
--- a/setup.c
+++ b/setup.c
@@ -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();
retval = get_relative_cwd(buffer, sizeof(buffer) - 1,
get_git_work_tree());
if (!retval || !*retval)
@@ -287,6 +292,7 @@ const char *setup_git_directory_gently(int *nongit_ok)
if (!work_tree_env)
inside_work_tree = 0;
setenv(GIT_DIR_ENVIRONMENT, ".", 1);
+ check_repository_format();
return NULL;
}
chdir("..");
@@ -307,6 +313,7 @@ const char *setup_git_directory_gently(int *nongit_ok)
if (!work_tree_env)
inside_work_tree = 1;
git_work_tree_cfg = xstrndup(cwd, offset);
+ check_repository_format();
if (offset == len)
return NULL;
@@ -367,7 +374,6 @@ int check_repository_format(void)
const char *setup_git_directory(void)
{
const char *retval = setup_git_directory_gently(NULL);
- check_repository_format();
/* If the work tree is not the default one, recompute prefix */
if (inside_work_tree < 0) {
--
1.5.3.6.2041.g106f-dirty
^ permalink raw reply related
* Re: stgit: lost all my patches again
From: Jon Smirl @ 2007-11-28 16:58 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Git Mailing List
In-Reply-To: <20071128164113.GA20749@diana.vm.bytemark.co.uk>
On 11/28/07, Karl Hasselström <kha@treskal.com> wrote:
> On 2007-11-28 11:21:05 -0500, Jon Smirl wrote:
>
> > On 11/28/07, Karl Hasselström <kha@treskal.com> wrote:
> >
> > > On 2007-11-28 10:06:57 -0500, Jon Smirl wrote:
> > >
> > > > stg repair -- partial repair, some patches empty, half are pushed
> > >
> > > Modulo any bugs, this should have adjusted the appliedness of your
> > > patches to match the new HEAD (patches are applied iff they are
> > > reachable from HEAD) and made patches of any non-patch commits
> > > sitting between a patch and HEAD. Nothing else. In particular, it
> > > doesn't change your existing patches or change HEAD, so those
> > > empty patches were empty even before the repair. (Modulo any bugs,
> > > of course, but that kind of bug seems really unlikely.)
> >
> > I don't know exactly what is going one, but all of my patches are in
> > commits in front of the rebase. I believe when they were applied
> > again, git detected that the changes were already in the tree and
> > that why the patches are empty. Normally stg would have popped all
> > my patches before doing the rebase.
>
> Ah, yes, if you "stg push" after the repair, that's what you can
> expect to happen. And once you've done that, it gets a little messier
> to recover. (Basically, what you'd do is delete the messed-up patches,
> git-reset to where you were before the git-rebase, and then "stg
> uncommit".)
>
> > I have messed the branch up doing manual recover, but the conditions
> > are easy enough to recreate.
>
> So I guess "stg repair" is working as intended, and what needs
> changing is its documentation: point out in greater detail that you
> should
>
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?
When I ran stg repair after the wrong git rebase command, I compounded
the problem further.
> 1. Figure out where you _want_ HEAD to be.
>
> 2. git-reset your way there.
>
> 3. Run stg repair if necessary. (And if you just reset back to where
> StGit thinks you are, you don't need to. But it's safe to run
> repair in that case too -- it'll just do nothing.)
>
> In that order.
>
> The only thing repair does is fix up StGit's metadata to match what
> HEAD is right now. If HEAD isn't what you want it to be, then you want
> to fix that first. In particular, to just go back to where you were
> the last time StGit heard from you, do
>
> $ git reset --hard $(stg id $(stg top))
>
> We need a proper manual to explain this in. :-)
>
> --
> Karl Hasselström, kha@treskal.com
> www.treskal.com/kalle
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: git-cvsimport bug
From: Jeff King @ 2007-11-28 16:57 UTC (permalink / raw)
To: Emanuele Giaquinta; +Cc: git
In-Reply-To: <20071127150136.GA50697@orion.lan>
On Tue, Nov 27, 2007 at 04:01:36PM +0100, Emanuele Giaquinta wrote:
> a call to git-cvsimport after a 'git-pack-refs --all' seems to mess up
> the origin branch, because the first new change is committed with no
> parent (git-cvsimport reports 'Parent ID (empty)').
> It does not happen if I disable loose refs pruning with --no-prune. A
> tiny test repo you can use to reproduce the problem is
> mextli.tomaw.net/~exg/lzf.tar. Is it expected?
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.
-Peff
^ 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 16:55 UTC (permalink / raw)
To: Bill Priest; +Cc: git
In-Reply-To: <251604.8861.qm@web55007.mail.re4.yahoo.com>
Please do not toppost, and try not to break quoted lines, please.
Thanks in advance.
On Wed, 28 Nov 2007, Bill Priest wrote:
> --- Jakub Narebski <jnareb@gmail.com> wrote:
>> Bill Priest wrote:
>>
>>> I merged from one branch to another and had lots of
>>> conflicts. I've resolved a set of files from the
>>> conflicts (in a directory) and did a git-add on this
>>> set of files. I wasn't able to commit these files.
>>> On IRC I was told that all files must be resolved
>>> before I can commit any of them. This seems pretty
>>> limiting. Why is a commit after a merge all or
>>> nothing; I thought that git figured out merges and
>>> such by the differences between files??
>>
>> You have to resolve _conflicts_ only. The rest is
>> added
>> automatically. See git-status, git diff --merge,
>> git ls-files -u.
> I understand that git requires this. My question
> is git enforcing policy or is there something
> "magic" about a commit after a merge. What if I want
> to make an independent change and check it in on the
> same branch before I am finished with the merge?
A little technical information about failed merge.
First, git tries to merge as mauch as it can automatically,
doing tree-level merge and trying three-way file-level merge
if necessary. Everything that merges cleanly is automatically
added to staging area.
For each file that has unresolved conflicts git adds to staging
are all (three) versions of file: original, from merged in
branch, and common ancestor version, as stages 1, 2, 3 (not
necessary in this order: see documentation). Additionally it
leaves partially merged file in working area with RCS-like
conflicts markes in it. (Note that default checking before
commits refuses to check in file with conflict markers; see
documentation how to force commit anyway).
Additionally git records the fact that it is in the midle of merge
by recording branch(es) merged in in .git/MERGE_HEAD.
To resolve conflicts you have to bring file to some version,
removing conflict markers, add this version using "git add",
then commit.
You can try to git-stash partially done merge; if it doesn't
work send us bugreport.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Rollback of git commands
From: Ingo Molnar @ 2007-11-28 16:50 UTC (permalink / raw)
To: David Symonds; +Cc: Jon Smirl, Junio C Hamano, Git Mailing List
In-Reply-To: <ee77f5c20711271757h724d5fcep38f3c2354c54f20b@mail.gmail.com>
* 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)
and this could all be driven via .git/logs - as long as all other
metadata is imported into the object store and the root of this git tree
would be represented in a single file. The logs are append-only as well,
the loss of them means the loss of undo/redo information, nothing else.
Figuring out the linear history from the logs would be computationally
expensive, but that's not a big issue as 'undo/redo' would be a rare
operation anyway.
But i guess i must be missing some obvious complication?
Ingo
^ permalink raw reply
* Re: Rollback of git commands
From: Nicolas Pitre @ 2007-11-28 16:46 UTC (permalink / raw)
To: Jon Smirl; +Cc: Sean, Junio C Hamano, Git Mailing List
In-Reply-To: <9e4733910711280837o43003e93p470bb403e6bdd3bb@mail.gmail.com>
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?
Nicolas
>
>
> >
> >
> > Nicolas
> > -
> > To unsubscribe from this list: send the line "unsubscribe git" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
>
>
> --
> Jon Smirl
> jonsmirl@gmail.com
>
Nicolas
^ permalink raw reply
* Re: stgit: lost all my patches again
From: Karl Hasselström @ 2007-11-28 16:41 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910711280821s3872eff5m95073ca6b1b8a689@mail.gmail.com>
On 2007-11-28 11:21:05 -0500, Jon Smirl wrote:
> On 11/28/07, Karl Hasselström <kha@treskal.com> wrote:
>
> > On 2007-11-28 10:06:57 -0500, Jon Smirl wrote:
> >
> > > stg repair -- partial repair, some patches empty, half are pushed
> >
> > Modulo any bugs, this should have adjusted the appliedness of your
> > patches to match the new HEAD (patches are applied iff they are
> > reachable from HEAD) and made patches of any non-patch commits
> > sitting between a patch and HEAD. Nothing else. In particular, it
> > doesn't change your existing patches or change HEAD, so those
> > empty patches were empty even before the repair. (Modulo any bugs,
> > of course, but that kind of bug seems really unlikely.)
>
> I don't know exactly what is going one, but all of my patches are in
> commits in front of the rebase. I believe when they were applied
> again, git detected that the changes were already in the tree and
> that why the patches are empty. Normally stg would have popped all
> my patches before doing the rebase.
Ah, yes, if you "stg push" after the repair, that's what you can
expect to happen. And once you've done that, it gets a little messier
to recover. (Basically, what you'd do is delete the messed-up patches,
git-reset to where you were before the git-rebase, and then "stg
uncommit".)
> I have messed the branch up doing manual recover, but the conditions
> are easy enough to recreate.
So I guess "stg repair" is working as intended, and what needs
changing is its documentation: point out in greater detail that you
should
1. Figure out where you _want_ HEAD to be.
2. git-reset your way there.
3. Run stg repair if necessary. (And if you just reset back to where
StGit thinks you are, you don't need to. But it's safe to run
repair in that case too -- it'll just do nothing.)
In that order.
The only thing repair does is fix up StGit's metadata to match what
HEAD is right now. If HEAD isn't what you want it to be, then you want
to fix that first. In particular, to just go back to where you were
the last time StGit heard from you, do
$ git reset --hard $(stg id $(stg top))
We need a proper manual to explain this in. :-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Rollback of git commands
From: Jon Smirl @ 2007-11-28 16:37 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Sean, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.0.99999.0711281125320.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 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.
>
>
> Nicolas
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: The 5th issue of the msysGit Herald
From: Julian Phillips @ 2007-11-28 16:33 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
In-Reply-To: <200711132020.59578.jnareb@gmail.com>
On Tue, 13 Nov 2007, Jakub Narebski wrote:
> Junio C Hamano wrote:
>> Jakub Narebski <jnareb@gmail.com> writes:
>>
>>> Perhaps it is time for git to have besides Git Homepage and Git Wiki also
>>> Git Blog or Git Feed (with announcements, what's in... and herald). What do
>>> you think?
>>
>> I miss the "Kernel Traffic" (and its cousin, the unfortunate
>> first and only issue of "Git Traffic").
>>
>> If you are stepping up as the chief "Git Traffic" editor (with
>> help from others), I'd imagine it would be greatly appreciated
>> by the community.
>>
>> I certainly would.
>
> ...and a buckefull of time, please...
>
> 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/
--
Julian
---
Consensus Terrorism:
The process that decides in-office attitudes and behavior.
-- Douglas Coupland, "Generation X: Tales for an Accelerated
Culture"
^ permalink raw reply
* Re: Rollback of git commands
From: Jeff King @ 2007-11-28 16:28 UTC (permalink / raw)
To: Jon Smirl; +Cc: Geert Bosch, Junio C Hamano, Git Mailing List
In-Reply-To: <9e4733910711280823q5fa14120scb6371a1465efca5@mail.gmail.com>
On Wed, Nov 28, 2007 at 11:23:30AM -0500, Jon Smirl wrote:
> > Assuming that they also retain the "having an object implies having all
> > of the objects it points to" property, then it makes it hard to talk
> > about subsets or single refs. If I fetch from you and you communicate
> > your repo state as some hash, then I am stuck getting _all_ of your
> > refs to complete this property.
>
> push/pull would still work at the branch level. The local state
> tracking objects wouldn't be exchanged.
Fair enough.
My spider sense still tingles about this, and I have the feeling that
you might run into weird merge problems when two refs are updated
simultaneously. I guess that shouldn't happen since you will write out
the complete "here are the refs" after every operation, leaving no room
for simultaneous updates, but I haven't given it enough thought to be
sure there aren't funny corner cases.
-Peff
^ permalink raw reply
* Re: Rollback of git commands
From: Nicolas Pitre @ 2007-11-28 16:26 UTC (permalink / raw)
To: Jon Smirl; +Cc: Sean, Junio C Hamano, Git Mailing List
In-Reply-To: <9e4733910711280758x38ca3cdau4e62bfe8776e5c0d@mail.gmail.com>
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.
Nicolas
^ permalink raw reply
* [PATCH 2/2] Link porcelain commands from gitexecdir to bindir
From: Nguyễn Thái Ngọc Duy @ 2007-11-28 16:26 UTC (permalink / raw)
To: git
This also adds variable my_porcelains. If you are not happy
with the default porcelain list, you can add your favourite
commands too.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
The porcelain list needs eyeballs.
Makefile | 15 +++++++++++++++
git.spec.in | 6 ++++++
2 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 3cf791f..0ab1569 100644
--- a/Makefile
+++ b/Makefile
@@ -262,6 +262,17 @@ BUILT_INS = \
git-fsck-objects$X git-cherry-pick$X git-status$X\
$(patsubst builtin-%.o,git-%$X,$(BUILTIN_OBJS))
+PORCELAINS = \
+ add$X am annotate$X apply$X archive$X bisect blame$X \
+ branch$X bundle$X checkout cherry-pick$X citool$X clean$X \
+ clone commit$X config$X cvsimport archimport \
+ daemon$X describe$X diff$X fetch$X format-patch$X fsck$X \
+ gc$X grep$X gui$X init$X instaweb log$X lost-found \
+ merge mergetool mv$X name-rev$X pull push$X quiltimport \
+ rebase remote rerere$X reset$X revert$X rm$X send-email \
+ show$X stash status submodule svn tag$X var$X \
+ whatchanged$X $(my_porcelains)
+
# what 'all' will build and 'install' will install, in gitexecdir
ALL_PROGRAMS = $(PROGRAMS) $(SCRIPTS)
@@ -1034,6 +1045,10 @@ endif
ifneq (,$X)
$(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), $(RM) '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p';)
endif
+ if test 'z$(bindir_SQ)' != 'z$(gitexecdir_SQ)'; \
+ then \
+ $(foreach p,$(PORCELAINS), ln -f '$(DESTDIR_SQ)$(gitexecdir_SQ)/git-$p' '$(DESTDIR_SQ)$(bindir_SQ)/git-$p' || cp '$(DESTDIR_SQ)$(gitexecdir_SQ)/git-$p' '$(DESTDIR_SQ)$(bindir_SQ)/git-$p';) \
+ fi
./check_bindir 'z$(bindir_SQ)' 'z$(gitexecdir_SQ)' '$(DESTDIR_SQ)$(bindir_SQ)/git-shell$X'
install-doc:
diff --git a/git.spec.in b/git.spec.in
index b6637a7..6830b03 100644
--- a/git.spec.in
+++ b/git.spec.in
@@ -121,6 +121,7 @@ rm -rf $RPM_BUILD_ROOT
%files svn
%defattr(-,root,root)
+%{_bindir}/*svn*
%{_libexecdir}/git-core/*svn*
%doc Documentation/*svn*.txt
%{!?_without_docs: %{_mandir}/man1/*svn*.1*}
@@ -129,6 +130,7 @@ rm -rf $RPM_BUILD_ROOT
%files cvs
%defattr(-,root,root)
%doc Documentation/*git-cvs*.txt
+%{_bindir}/*cvs*
%{_libexecdir}/git-core/*cvs*
%{!?_without_docs: %{_mandir}/man1/*cvs*.1*}
%{!?_without_docs: %doc Documentation/*git-cvs*.html }
@@ -136,6 +138,7 @@ rm -rf $RPM_BUILD_ROOT
%files arch
%defattr(-,root,root)
%doc Documentation/git-archimport.txt
+%{_bindir}/git-archimport
%{_libexecdir}/git-core/git-archimport
%{!?_without_docs: %{_mandir}/man1/git-archimport.1*}
%{!?_without_docs: %doc Documentation/git-archimport.html }
@@ -143,13 +146,16 @@ rm -rf $RPM_BUILD_ROOT
%files email
%defattr(-,root,root)
%doc Documentation/*email*.txt
+%{_bindir}/*email*
%{_libexecdir}/git-core/*email*
%{!?_without_docs: %{_mandir}/man1/*email*.1*}
%{!?_without_docs: %doc Documentation/*email*.html }
%files gui
%defattr(-,root,root)
+%{_bindir}/git-gui
%{_libexecdir}/git-core/git-gui
+%{_bindir}/git-citool
%{_libexecdir}/git-core/git-citool
%{_datadir}/git-gui/
%{!?_without_docs: %{_mandir}/man1/git-gui.1*}
--
1.5.3.6.2041.g106f-dirty
^ permalink raw reply related
* Re: Rollback of git commands
From: Jon Smirl @ 2007-11-28 16:23 UTC (permalink / raw)
To: Jeff King; +Cc: Geert Bosch, Junio C Hamano, Git Mailing List
In-Reply-To: <20071128162002.GB20308@coredump.intra.peff.net>
On 11/28/07, Jeff King <peff@peff.net> wrote:
> On Tue, Nov 27, 2007 at 11:07:29PM -0500, Geert Bosch wrote:
>
> > I have always wondered why refs and tags are not
> > in the regular object store. In a way, there
> > should be just one root pointer (SHA1) pointing
> > to a tree with refs, etc.
>
> Assuming that they also retain the "having an object implies having all
> of the objects it points to" property, then it makes it hard to talk
> about subsets or single refs. If I fetch from you and you communicate
> your repo state as some hash, then I am stuck getting _all_ of your
> refs to complete this property.
push/pull would still work at the branch level. The local state
tracking objects wouldn't be exchanged.
>
> -Peff
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* [PATCH 1/2] Move all dashed-form commands to libexecdir
From: Nguyễn Thái Ngọc Duy @ 2007-11-28 16:21 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Third version. Changes include
- warn users if they have old commands in bindir
- update git.spec.in (I did not use, but rpm2targz output seemed
correct)
Makefile | 3 ++-
check_bindir | 13 +++++++++++++
config.mak.in | 2 +-
git.spec.in | 13 +++++++------
4 files changed, 23 insertions(+), 8 deletions(-)
create mode 100755 check_bindir
diff --git a/Makefile b/Makefile
index 313f9a2..3cf791f 100644
--- a/Makefile
+++ b/Makefile
@@ -154,7 +154,7 @@ STRIP ?= strip
prefix = $(HOME)
bindir = $(prefix)/bin
-gitexecdir = $(bindir)
+gitexecdir = $(prefix)/libexec/git-core
sharedir = $(prefix)/share
template_dir = $(sharedir)/git-core/templates
ifeq ($(prefix),/usr)
@@ -1034,6 +1034,7 @@ endif
ifneq (,$X)
$(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), $(RM) '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p';)
endif
+ ./check_bindir 'z$(bindir_SQ)' 'z$(gitexecdir_SQ)' '$(DESTDIR_SQ)$(bindir_SQ)/git-shell$X'
install-doc:
$(MAKE) -C Documentation install
diff --git a/check_bindir b/check_bindir
new file mode 100755
index 0000000..a1c4c3e
--- /dev/null
+++ b/check_bindir
@@ -0,0 +1,13 @@
+#!/bin/sh
+bindir="$1"
+gitexecdir="$2"
+gitcmd="$3"
+if test "$bindir" != "$gitexecdir" -a -x "$gitcmd"
+then
+ echo
+ echo "!! You have installed git-* commands to new gitexecdir."
+ echo "!! Old version git-* commands still remain in bindir."
+ echo "!! Mixing two versions of Git will lead to problems."
+ echo "!! Please remove old version commands in bindir now."
+ echo
+fi
diff --git a/config.mak.in b/config.mak.in
index 11d256e..1db0338 100644
--- a/config.mak.in
+++ b/config.mak.in
@@ -11,7 +11,7 @@ TCLTK_PATH = @TCLTK_PATH@
prefix = @prefix@
exec_prefix = @exec_prefix@
bindir = @bindir@
-#gitexecdir = @libexecdir@/git-core/
+gitexecdir = @libexecdir@/git-core/
datarootdir = @datarootdir@
template_dir = @datadir@/git-core/templates/
diff --git a/git.spec.in b/git.spec.in
index bdb293d..b6637a7 100644
--- a/git.spec.in
+++ b/git.spec.in
@@ -105,6 +105,7 @@ find $RPM_BUILD_ROOT -type f -name '*.bs' -empty -exec rm -f {} ';'
find $RPM_BUILD_ROOT -type f -name perllocal.pod -exec rm -f {} ';'
(find $RPM_BUILD_ROOT%{_bindir} -type f | grep -vE "archimport|svn|cvs|email|gitk|git-gui|git-citool" | sed -e s@^$RPM_BUILD_ROOT@@) > bin-man-doc-files
+(find $RPM_BUILD_ROOT%{_libexecdir}/git-core -type f | grep -vE "archimport|svn|cvs|email|gitk|git-gui|git-citool" | sed -e s@^$RPM_BUILD_ROOT@@) >> bin-man-doc-files
(find $RPM_BUILD_ROOT%{perl_vendorlib} -type f | sed -e s@^$RPM_BUILD_ROOT@@) >> perl-files
%if %{!?_without_docs:1}0
(find $RPM_BUILD_ROOT%{_mandir} $RPM_BUILD_ROOT/Documentation -type f | grep -vE "archimport|svn|git-cvs|email|gitk|git-gui|git-citool" | sed -e s@^$RPM_BUILD_ROOT@@ -e 's/$/*/' ) >> bin-man-doc-files
@@ -120,7 +121,7 @@ rm -rf $RPM_BUILD_ROOT
%files svn
%defattr(-,root,root)
-%{_bindir}/*svn*
+%{_libexecdir}/git-core/*svn*
%doc Documentation/*svn*.txt
%{!?_without_docs: %{_mandir}/man1/*svn*.1*}
%{!?_without_docs: %doc Documentation/*svn*.html }
@@ -128,28 +129,28 @@ rm -rf $RPM_BUILD_ROOT
%files cvs
%defattr(-,root,root)
%doc Documentation/*git-cvs*.txt
-%{_bindir}/*cvs*
+%{_libexecdir}/git-core/*cvs*
%{!?_without_docs: %{_mandir}/man1/*cvs*.1*}
%{!?_without_docs: %doc Documentation/*git-cvs*.html }
%files arch
%defattr(-,root,root)
%doc Documentation/git-archimport.txt
-%{_bindir}/git-archimport
+%{_libexecdir}/git-core/git-archimport
%{!?_without_docs: %{_mandir}/man1/git-archimport.1*}
%{!?_without_docs: %doc Documentation/git-archimport.html }
%files email
%defattr(-,root,root)
%doc Documentation/*email*.txt
-%{_bindir}/*email*
+%{_libexecdir}/git-core/*email*
%{!?_without_docs: %{_mandir}/man1/*email*.1*}
%{!?_without_docs: %doc Documentation/*email*.html }
%files gui
%defattr(-,root,root)
-%{_bindir}/git-gui
-%{_bindir}/git-citool
+%{_libexecdir}/git-core/git-gui
+%{_libexecdir}/git-core/git-citool
%{_datadir}/git-gui/
%{!?_without_docs: %{_mandir}/man1/git-gui.1*}
%{!?_without_docs: %doc Documentation/git-gui.html}
--
1.5.3.6.2041.g106f-dirty
^ permalink raw reply related
* Re: [PATCH v2] Replace instances of export VAR=VAL with VAR=VAL; export VAR
From: David Kastrup @ 2007-11-28 16:03 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Johannes Sixt, Wincent Colaiuta, Junio C Hamano, Benoit Sigoure,
Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0711281552440.27959@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> It might be POSIX, but there are shells that do not like the
> expression 'export VAR=VAL'.
As long as we have no positive report about any such shell that
_otherwise_ would be usable for git, why bother?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: stgit: lost all my patches again
From: Karl Hasselström @ 2007-11-28 16:04 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910711280706j45fe9c17t928396eb8e1de8bf@mail.gmail.com>
On 2007-11-28 10:06:57 -0500, Jon Smirl wrote:
> I did this:
> all pataches were applied
> git rebase
At this point, a simple "git reset --hard HEAD@{1}" should have fixed
the problem. Not much use knowing that now, I know, but still ... :-)
> stg repair -- partial repair, some patches empty, half are pushed
Modulo any bugs, this should have adjusted the appliedness of your
patches to match the new HEAD (patches are applied iff they are
reachable from HEAD) and made patches of any non-patch commits sitting
between a patch and HEAD. Nothing else. In particular, it doesn't
change your existing patches or change HEAD, so those empty patches
were empty even before the repair. (Modulo any bugs, of course, but
that kind of bug seems really unlikely.)
> moved HEAD back in front of rebase
> stg repair - it show all my patches as popped,
That sounds OK. You reset HEAD to a commit early enough in history
that no patches are reachable from it.
> but when I started doing command it complain that some commits that
> stg needed were not there.
That sounds seriously broken. What exactly was the complaint? Missing
commit objects?
> The complaint was caused by the first repair. The first repair
> altered some of the stg state to point at commits past the rebase.
Yes. It would have made patches out of some of the rebased commits, in
order to give you a consistent state. For example, assume you started
with the following situation:
(cN are commits, pN are commits that are also StGit patches)
...---c0---c1---p0---p1---p2---p3---p4:HEAD
You git-rebase, causing a situation like this:
...---c0---c1---p0---p1---p2---p3---p4
\
c2---c3---c4---c5---c6---c7---c8:HEAD
"stg repair" at this point will see that p2..p4 should be unapplied
since they aren't reachable from HEAD, and c2..c8 need to be made
patches since they are on top of p1.
Generally, what you want to do is to git-reset to the commit you want
HEAD to be, and _then_ run stg repair.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: stgit: lost all my patches again
From: Jon Smirl @ 2007-11-28 16:21 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Git Mailing List
In-Reply-To: <20071128160410.GB19302@diana.vm.bytemark.co.uk>
On 11/28/07, Karl Hasselström <kha@treskal.com> wrote:
> On 2007-11-28 10:06:57 -0500, Jon Smirl wrote:
>
> > I did this:
> > all pataches were applied
> > git rebase
>
> At this point, a simple "git reset --hard HEAD@{1}" should have fixed
> the problem. Not much use knowing that now, I know, but still ... :-)
>
> > stg repair -- partial repair, some patches empty, half are pushed
>
> Modulo any bugs, this should have adjusted the appliedness of your
> patches to match the new HEAD (patches are applied iff they are
> reachable from HEAD) and made patches of any non-patch commits sitting
> between a patch and HEAD. Nothing else. In particular, it doesn't
> change your existing patches or change HEAD, so those empty patches
> were empty even before the repair. (Modulo any bugs, of course, but
> that kind of bug seems really unlikely.)
I don't know exactly what is going one, but all of my patches are in
commits in front of the rebase. I believe when they were applied
again, git detected that the changes were already in the tree and that
why the patches are empty. Normally stg would have popped all my
patches before doing the rebase.
I have messed the branch up doing manual recover, but the conditions
are easy enough to recreate.
>
> > moved HEAD back in front of rebase
> > stg repair - it show all my patches as popped,
>
> That sounds OK. You reset HEAD to a commit early enough in history
> that no patches are reachable from it.
>
> > but when I started doing command it complain that some commits that
> > stg needed were not there.
>
> That sounds seriously broken. What exactly was the complaint? Missing
> commit objects?
>
> > The complaint was caused by the first repair. The first repair
> > altered some of the stg state to point at commits past the rebase.
>
> Yes. It would have made patches out of some of the rebased commits, in
> order to give you a consistent state. For example, assume you started
> with the following situation:
>
> (cN are commits, pN are commits that are also StGit patches)
>
> ...---c0---c1---p0---p1---p2---p3---p4:HEAD
>
> You git-rebase, causing a situation like this:
>
> ...---c0---c1---p0---p1---p2---p3---p4
> \
> c2---c3---c4---c5---c6---c7---c8:HEAD
>
> "stg repair" at this point will see that p2..p4 should be unapplied
> since they aren't reachable from HEAD, and c2..c8 need to be made
> patches since they are on top of p1.
>
> Generally, what you want to do is to git-reset to the commit you want
> HEAD to be, and _then_ run stg repair.
>
> --
> Karl Hasselström, kha@treskal.com
> www.treskal.com/kalle
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] Allow update hooks to update refs on their own
From: Jeff King @ 2007-11-28 16:10 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Steven Grimm, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0711272143470.5349@iabervon.org>
On Tue, Nov 27, 2007 at 10:25:32PM -0500, Daniel Barkalow wrote:
> > It would of course be better if git-push could notice that it needs
> > to do an actual fetch. I think it'd be sufficient to transmit the
> > final remote ref SHA1 back to git-push, and if it doesn't match what
> > was pushed, that's a sign that a fetch is needed. But that change
> > wouldn't be mutually exclusive with this patch, I believe.
>
> Couldn't you do this with a status message? ("ok <refname> changed by
> hook" or something.)
Having just touched this code, I believe the answer is yes. receive-pack
has always sent just "ok <refname>\n", so we could start interpreting
anything after the <refname> bit freely (I think "ok <refname>
changed-to <hash>" is even more informative, but perhaps not useful
given that the sender probably doesn't have that commit object).
-Peff
^ permalink raw reply
* Re: Rollback of git commands
From: Jeff King @ 2007-11-28 16:20 UTC (permalink / raw)
To: Geert Bosch; +Cc: Jon Smirl, Junio C Hamano, Git Mailing List
In-Reply-To: <3AAC5548-A9AC-4236-B1F7-5CFDE11B52C4@adacore.com>
On Tue, Nov 27, 2007 at 11:07:29PM -0500, Geert Bosch wrote:
> I have always wondered why refs and tags are not
> in the regular object store. In a way, there
> should be just one root pointer (SHA1) pointing
> to a tree with refs, etc.
Assuming that they also retain the "having an object implies having all
of the objects it points to" property, then it makes it hard to talk
about subsets or single refs. If I fetch from you and you communicate
your repo state as some hash, then I am stuck getting _all_ of your
refs to complete this property.
-Peff
^ permalink raw reply
* Re: Rollback of git commands
From: Jon Smirl @ 2007-11-28 15:58 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Sean, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.0.99999.0711280951150.9605@xanadu.home>
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.
>
>
> Nicolas
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Jon Smirl
jonsmirl@gmail.com
^ 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 15:53 UTC (permalink / raw)
To: git
In-Reply-To: <820179.5481.qm@web55002.mail.re4.yahoo.com>
Bill Priest wrote:
> All,
> I merged from one branch to another and had lots of
> conflicts. I've resolved a set of files from the
> conflicts (in a directory) and did a git-add on this
> set of files. I wasn't able to commit these files.
> On IRC I was told that all files must be resolved
> before I can commit any of them. This seems pretty
> limiting. Why is a commit after a merge all or
> nothing; I thought that git figured out merges and
> such by the differences between files??
You have to resolve _conflicts_ only. The rest is added
automatically. See git-status, git diff --merge,
git ls-files -u.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH v2] Replace instances of export VAR=VAL with VAR=VAL; export VAR
From: Johannes Schindelin @ 2007-11-28 15:56 UTC (permalink / raw)
To: Johannes Sixt
Cc: Wincent Colaiuta, Junio C Hamano, Benoit Sigoure,
Git Mailing List
In-Reply-To: <474D7D92.2000106@viscovery.net>
It might be POSIX, but there are shells that do not like the
expression 'export VAR=VAL'. To be on the safe side, rewrite them
into 'VAR=VAL' and 'export VAR'.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Wed, 28 Nov 2007, Johannes Sixt wrote:
> Johannes Schindelin schrieb:
> >
> > On Wed, 28 Nov 2007, Johannes Sixt wrote:
> >
> > > Johannes Schindelin schrieb:
> > > > - s/.*/export GIT_'$uid'_NAME='\''&'\''/p
> > > > + s/.*/GIT_'$uid'_NAME='\''&'\''\nexport
> > > > GIT_'$uid'_NAME/p
> > >
> > > 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.
Done.
git-clone.sh | 2 +-
git-filter-branch.sh | 23 +++++++++++++++--------
git-quiltimport.sh | 10 ++++++----
3 files changed, 22 insertions(+), 13 deletions(-)
diff --git a/git-clone.sh b/git-clone.sh
index 24ad179..ecf9d89 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -229,7 +229,7 @@ cleanup() {
trap cleanup 0
mkdir -p "$dir" && D=$(cd "$dir" && pwd) || usage
test -n "$GIT_WORK_TREE" && mkdir -p "$GIT_WORK_TREE" &&
-W=$(cd "$GIT_WORK_TREE" && pwd) && export GIT_WORK_TREE="$W"
+W=$(cd "$GIT_WORK_TREE" && pwd) && GIT_WORK_TREE="$W" && export GIT_WORK_TREE
if test yes = "$bare" || test -n "$GIT_WORK_TREE"; then
GIT_DIR="$D"
else
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 19cab5a..074b2c0 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -66,17 +66,20 @@ set_ident () {
h
s/^'$lid' \([^<]*\) <[^>]*> .*$/\1/
s/'\''/'\''\'\'\''/g
- s/.*/export GIT_'$uid'_NAME='\''&'\''/p
+ s/.*/GIT_'$uid'_NAME='\''&'\''\
+export GIT_'$uid'_NAME/p
g
s/^'$lid' [^<]* <\([^>]*\)> .*$/\1/
s/'\''/'\''\'\'\''/g
- s/.*/export GIT_'$uid'_EMAIL='\''&'\''/p
+ s/.*/GIT_'$uid'_EMAIL='\''&'\''\
+export GIT_'$uid'_EMAIL/p
g
s/^'$lid' [^<]* <[^>]*> \(.*\)$/\1/
s/'\''/'\''\'\'\''/g
- s/.*/export GIT_'$uid'_DATE='\''&'\''/p
+ s/.*/GIT_'$uid'_DATE='\''&'\''\
+export GIT_'$uid'_DATE/p
q
}
@@ -84,7 +87,7 @@ set_ident () {
LANG=C LC_ALL=C sed -ne "$pick_id_script"
# Ensure non-empty id name.
- echo "[ -n \"\$GIT_${uid}_NAME\" ] || export GIT_${uid}_NAME=\"\${GIT_${uid}_EMAIL%%@*}\""
+ echo "case \"\$GIT_${uid}_NAME\" in \"\") GIT_${uid}_NAME=\"\${GIT_${uid}_EMAIL%%@*}\" && export GIT_${uid}_NAME;; esac"
}
USAGE="[--env-filter <command>] [--tree-filter <command>] \
@@ -206,7 +209,8 @@ done < "$tempdir"/backup-refs
ORIG_GIT_DIR="$GIT_DIR"
ORIG_GIT_WORK_TREE="$GIT_WORK_TREE"
ORIG_GIT_INDEX_FILE="$GIT_INDEX_FILE"
-export GIT_DIR GIT_WORK_TREE=.
+GIT_WORK_TREE=.
+export GIT_DIR GIT_WORK_TREE
# These refs should be updated if their heads were rewritten
@@ -231,7 +235,8 @@ done > "$tempdir"/heads
test -s "$tempdir"/heads ||
die "Which ref do you want to rewrite?"
-export GIT_INDEX_FILE="$(pwd)/../index"
+GIT_INDEX_FILE="$(pwd)/../index"
+export GIT_INDEX_FILE
git read-tree || die "Could not seed the index"
ret=0
@@ -267,7 +272,8 @@ while read commit parents; do
git read-tree -i -m $commit:"$filter_subdir"
esac || die "Could not initialize the index"
- export GIT_COMMIT=$commit
+ GIT_COMMIT=$commit
+ export GIT_COMMIT
git cat-file commit "$commit" >../commit ||
die "Cannot read commit $commit"
@@ -401,7 +407,8 @@ if [ "$filter_tag_name" ]; then
[ -f "../map/$sha1" ] || continue
new_sha1="$(cat "../map/$sha1")"
- export GIT_COMMIT="$sha1"
+ GIT_COMMIT="$sha1"
+ export GIT_COMMIT
new_ref="$(echo "$ref" | eval "$filter_tag_name")" ||
die "tag name filter failed: $filter_tag_name"
diff --git a/git-quiltimport.sh b/git-quiltimport.sh
index 6b0c4d2..233e5ea 100755
--- a/git-quiltimport.sh
+++ b/git-quiltimport.sh
@@ -77,8 +77,9 @@ for patch_name in $(grep -v '^#' < "$QUILT_PATCHES/series" ); do
}
# Parse the author information
- export GIT_AUTHOR_NAME=$(sed -ne 's/Author: //p' "$tmp_info")
- export GIT_AUTHOR_EMAIL=$(sed -ne 's/Email: //p' "$tmp_info")
+ GIT_AUTHOR_NAME=$(sed -ne 's/Author: //p' "$tmp_info")
+ GIT_AUTHOR_EMAIL=$(sed -ne 's/Email: //p' "$tmp_info")
+ export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL
while test -z "$GIT_AUTHOR_EMAIL" && test -z "$GIT_AUTHOR_NAME" ; do
if [ -n "$quilt_author" ] ; then
GIT_AUTHOR_NAME="$quilt_author_name";
@@ -104,8 +105,9 @@ for patch_name in $(grep -v '^#' < "$QUILT_PATCHES/series" ); do
GIT_AUTHOR_EMAIL="$patch_author_email"
fi
done
- export GIT_AUTHOR_DATE=$(sed -ne 's/Date: //p' "$tmp_info")
- export SUBJECT=$(sed -ne 's/Subject: //p' "$tmp_info")
+ GIT_AUTHOR_DATE=$(sed -ne 's/Date: //p' "$tmp_info")
+ SUBJECT=$(sed -ne 's/Subject: //p' "$tmp_info")
+ export GIT_AUTHOR_DATE SUBJECT
if [ -z "$SUBJECT" ] ; then
SUBJECT=$(echo $patch_name | sed -e 's/.patch$//')
fi
--
1.5.3.6.2065.gd47ac
^ permalink raw reply related
* Re: QGit: Shrink used memory with custom git log format
From: jhud7196 @ 2007-11-28 15:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn O. Pearce, Marco Costalba, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0711281200070.27959@racer.site>
> Hi,
>
> On Tue, 27 Nov 2007, Jan Hudec wrote:
>
>> On Tue, Nov 27, 2007 at 10:48:00 +0000, Johannes Schindelin wrote:
>> > On Mon, 26 Nov 2007, Shawn O. Pearce wrote:
>> > > [...]
>> > > Otherwise I think what you really want here is a libgit that you can
>> > > link into your process and that can efficiently inflate an object
>> > > on demand for you. Like the work Luiz was working on this past
>> > > summer for GSOC. Lots of downsides to that current tree though...
>> > > like die() kills the GUI...
>> >
>> > But then, die() calls die_routine, which you can override. And C++
>> has
>> > this funny exception mechanism which just begs to be used here. The
>> only
>> > thing you need to add is a way to flush all singletons like the object
>> > array.
>>
>> Unfortunately, exceptions won't really work. Why? Because to use
>> exceptions, you need to have an exception-safe code. That is the code
>> needs to free any allocated resources when it's aborted by exception.
>> And git code is not exceptions safe. Given the lack of destructors in C,
>> it means registering all resource allocation in some kind of pool, so
>> they can be freed en masse in case of failure. Than you can also use
>> longjmp for die (for C they really behave the same).
>
> Sorry, I just assumed that you can read my mind (or alternatively remember
> what I suggested a few months ago, namely to "override" xmalloc(),
> xcalloc(), xrealloc() and xfree() (probably you need to create the
> latter)).
That sounds like the easiest (but not necessarily easy) direction towards
the goal. Thread-local or global (I don't think git is currently reentrant
anyway) would do. Also filehanles would have to be taken care of and
everything checked for using malloc, calloc, strdup and other libc
functions directly.
Than die could longjmp out to a specified buffer and could be safely
overriden to throw exception for C++ apps.
--
- Jan Hudec <bulb@ucw.cz>
^ permalink raw reply
* [PATCH] filter-branch: fix dirty way to provide the helpers to commit filters
From: Johannes Schindelin @ 2007-11-28 15:50 UTC (permalink / raw)
To: git, gitster
The helper functions 'map' and 'skip_commit' were provided to commit
filters by sourcing filter-branch itself. This was done with a certain
environment variable set to indicate that only the functions should be
defined, and the script should return then.
This was really hacky, and it did not work all that well, since the
full path to git-filter-branch was not known at all times.
Avoid that by putting the functions into a variable, and eval'ing
that variable. The commit filter gets these functions by prepending
the variable to the specified commands.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Frankly, I have no idea why this worked, but it did. However,
we had to replace the spawnvpe() function in msysGit with a
custom version (thanks Hannes!) to avoid cmd windows popping up
all over the place, and the method to source the first part of
the script back in commit filters failed.
Independently, I think that this version is nicer.
git-filter-branch.sh | 14 ++++++++------
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index c9f515d..19cab5a 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -8,6 +8,9 @@
# a new branch. You can specify a number of filters to modify the commits,
# files and trees.
+# The following functions will also be available in the commit filter:
+
+functions=$(cat << \EOF
warn () {
echo "$*" >&2
}
@@ -46,6 +49,10 @@ die()
echo "$*" >&2
exit 1
}
+EOF
+)
+
+eval "$functions"
# When piped a commit, output a script to set the ident of either
# "author" or "committer
@@ -80,11 +87,6 @@ set_ident () {
echo "[ -n \"\$GIT_${uid}_NAME\" ] || export GIT_${uid}_NAME=\"\${GIT_${uid}_EMAIL%%@*}\""
}
-# This script can be sourced by the commit filter to get the functions
-test "a$SOURCE_FUNCTIONS" = a1 && return
-this_script="$(cd "$(dirname "$0")"; pwd)"/$(basename "$0")
-export this_script
-
USAGE="[--env-filter <command>] [--tree-filter <command>] \
[--index-filter <command>] [--parent-filter <command>] \
[--msg-filter <command>] [--commit-filter <command>] \
@@ -156,7 +158,7 @@ do
filter_msg="$OPTARG"
;;
--commit-filter)
- filter_commit='SOURCE_FUNCTIONS=1 . "$this_script";'" $OPTARG"
+ filter_commit="$functions; $OPTARG"
;;
--tag-name-filter)
filter_tag_name="$OPTARG"
--
1.5.3.6.2065.gd47ac
^ 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