* 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: 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: 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
* [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: 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
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