* Re: [PATCH] shrink git-shell by avoiding redundant dependencies
From: Johannes Schindelin @ 2008-06-28 14:51 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Git Mailing List
In-Reply-To: <1214602538-7888-1-git-send-email-dpotapov@gmail.com>
Hi,
On Sat, 28 Jun 2008, Dmitry Potapov wrote:
> A lot of modules that have nothing to do with git-shell functionality
> were linked in, bloating git-shell more than 8 times.
/me wonders if "strip git-shell" would not take care of all that.
Just curious,
Dscho
^ permalink raw reply
* RE: Make test on AIX
From: Craig L. Ching @ 2008-06-28 15:35 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20080628051500.GF9451@sigill.intra.peff.net>
(I apologize in advance if the quoting is bad, using owa since I don't want an outlook client installed on my home system)
-----Original Message-----
From: git-owner@vger.kernel.org on behalf of Jeff King
Sent: Sat 6/28/2008 12:15 AM
To: Craig L. Ching
Cc: git@vger.kernel.org
Subject: Re: Make test on AIX
On Fri, Jun 27, 2008 at 04:13:41PM -0500, Craig L. Ching wrote:
> The first thing I encountered was that because the tests all use
> #!/bin/sh the exit code was not what the tests expected. So I ended up
> running 'make SHELL=`which bash` all' directly in the git/t/ directory.
> That seemed to shake out and work for most of the tests except for
> t/t7502-commit.sh. Try as I might, I could not get SHELL_PATH set to
> anything but /bin/sh except to hard-code the SHELL_PATH in this script.
> > The SHELL_PATH actually comes from the build options for all of git. So
> > you should be able to go to the toplevel of your git repo and do a "make
> > SHELL_PATH=`which bash`". This means that we will also use bash for all
> > of the script components of git.
Well, I swear I tried 'make SHELL_PATH=`which bash` test' and that *didn't* work, but I just rebuilt adding SHELL_PATH to even the build step and the tests are running. I do know I upgraded bash somewhere in between trying that and now, maybe that had some affect, the bash that was installed was fairly old. The tests are running now, I'll post back if I run into any other problems.
> > I don't know how necessary that is on AIX, but it certainly is on
> > Solaris, where /bin/sh is unusable.
I didn't have this problem at all on Solaris, the tests ran just great apart from needing to install a pretty hefty GNU tool chain since a lot of the tests wouldn't work with non-GNU equivalents (e.g. patch, diff, sed, etc.). Not a huge deal, just glad to see it building and passing tests on these platforms ;-)
> > -Peff
Thanks again!
Cheers,
Craig
^ permalink raw reply
* Re: An alternate model for preparing partial commits
From: Robert Anderson @ 2008-06-28 15:53 UTC (permalink / raw)
To: Dmitry Potapov, Git Mailing List
In-Reply-To: <20080628123522.GL5737@dpotapov.dyndns.org>
On Sat, Jun 28, 2008 at 5:35 AM, Dmitry Potapov <dpotapov@gmail.com> wrote:
>> Fine, you like doing extra work for no benefit. Enjoy yourself.
>
> I don't see where you find this extra work.
You aren't trying to. You're knee-jerk defending the status quo, as
is the case of 95% of reply mail sent to any SCM mailing list.
I worked in this model for years. It is inconvenient and creates
redundant work. It is a PITA.
Thanks,
Bob
^ permalink raw reply
* Re: An alternate model for preparing partial commits
From: Robert Anderson @ 2008-06-28 16:00 UTC (permalink / raw)
To: Stephen Sinclair; +Cc: Git Mailing List
In-Reply-To: <9b3e2dc20806280734i6ca17cc8i447c2e2db67e8051@mail.gmail.com>
On Sat, Jun 28, 2008 at 7:34 AM, Stephen Sinclair <radarsat1@gmail.com> wrote:
> The answer is simple: you should not be making partial commits to a
> repo that has been cloned. You should instead be working somewhere
> else and then pushing to it. So this whole sentence is just a moot
> point itself.
Ah, now you've hit the crux. Thank you for the "svn style" response
here. I "should not" because git has a deficiency. Absolutely no
other reason.
Thanks,
Bob
^ permalink raw reply
* Re: An alternate model for preparing partial commits
From: Robert Anderson @ 2008-06-28 16:30 UTC (permalink / raw)
To: Stephen Sinclair; +Cc: Git Mailing List
In-Reply-To: <9b3e2dc20806280734i6ca17cc8i447c2e2db67e8051@mail.gmail.com>
On Sat, Jun 28, 2008 at 7:34 AM, Stephen Sinclair <radarsat1@gmail.com> wrote:
> The answer is simple: you should not be making partial commits to a
> repo that has been cloned. You should instead be working somewhere
> else and then pushing to it. So this whole sentence is just a moot
> point itself.
Let me amplify my objection to this.
Who has 100% foresight that what they are doing is going to end up in
a state where they'd like to make partial commits? To take a quote
from a blog post, 'Git means never having to say, "you should have"'.
And mostly it doesn't, and that's big improvement over other systems.
But, that is what you are saying here. I "should have" realized that
I should have pulled and fiddled with my changes there, and then
pushed.
Well, Dmitri and others will now say, why not just always pull and
work somewhere else? And the reason is that because this creates
extra, unnecessary steps the vast majority of the time when I do
create a commit that I like and want to keep as-is in the first try.
Why should I have to pull, commit, hack, and push, when hack and
commit is all I need to do the vast majority of the time? It is
redundant, unnecessary work and complexity that I should not have to
pay for when I don't need it.
Thanks,
Bob
^ permalink raw reply
* Re: [PATCH] shrink git-shell by avoiding redundant dependencies
From: Dmitry Potapov @ 2008-06-28 16:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0806281542160.9925@racer>
On Sat, Jun 28, 2008 at 6:51 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>
> /me wonders if "strip git-shell" would not take care of all that.
"strip" removes only debug information. It has no affect on text, data, and bss
sections. You can try to run "size git-shell" before and after
"strip", and you'll
see the same numbers.
BTW, it is possible to reduce the "text" and "data" size twice more
using the whole
program optimization, as it will discard some functions that are not
actually used,
but I don't think it is worth pursuing as it will complicate complication.
Dmitry
^ permalink raw reply
* [PATCH] avoid off-by-one error in run_upload_archive
From: Jochen Voss @ 2008-06-28 16:04 UTC (permalink / raw)
To: git; +Cc: gitster
Make sure that buf has enough space to store the trailing \0 of
the command line argument, too.
Signed-off-by: Jochen Voss <voss@seehuhn.de>
---
builtin-upload-archive.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-upload-archive.c b/builtin-upload-archive.c
index 48ae09e..371400d 100644
--- a/builtin-upload-archive.c
+++ b/builtin-upload-archive.c
@@ -30,7 +30,7 @@ static int run_upload_archive(int argc, const char **argv, const char *prefix)
if (argc != 2)
usage(upload_archive_usage);
- if (strlen(argv[1]) > sizeof(buf))
+ if (strlen(argv[1]) + 1 > sizeof(buf))
die("insanely long repository name");
strcpy(buf, argv[1]); /* enter-repo smudges its argument */
--
1.5.3.7
^ permalink raw reply related
* Re: An alternate model for preparing partial commits
From: Dmitry Potapov @ 2008-06-28 16:52 UTC (permalink / raw)
To: Robert Anderson; +Cc: Git Mailing List
In-Reply-To: <9af502e50806280853i4c8564daxde2041aedc7fcb8d@mail.gmail.com>
On Sat, Jun 28, 2008 at 08:53:04AM -0700, Robert Anderson wrote:
> On Sat, Jun 28, 2008 at 5:35 AM, Dmitry Potapov <dpotapov@gmail.com> wrote:
> >> Fine, you like doing extra work for no benefit. Enjoy yourself.
> >
> > I don't see where you find this extra work.
>
> You aren't trying to. You're knee-jerk defending the status quo, as
> is the case of 95% of reply mail sent to any SCM mailing list.
Nice... and you are an arrogant and narrow-minded individual who
believes that he knows better anyone else, but you are incapable to
produce neither code nor any solid logical argument to support your
view. So you limit yourself to verbal masturbation about some Git
deficiency and blah-blah-blah, which no one but you can notice here.
And then the workflow that you call you call as "inconvenient and
creates redundant work" produced Git, which has become self-hosted
in three days and has been developed very rapidly ever since then.
You can do better with your workflow? Prove it! Until then, I have
no interest in any further communication on this subject with you.
Thanks,
Dmitry
^ permalink raw reply
* Re: An alternate model for preparing partial commits
From: Jakub Narebski @ 2008-06-28 17:12 UTC (permalink / raw)
To: Robert Anderson; +Cc: Stephen Sinclair, Git Mailing List
In-Reply-To: <9af502e50806280930u788f81e2j77adf147a0e4d135@mail.gmail.com>
"Robert Anderson" <rwa000@gmail.com> writes:
> On Sat, Jun 28, 2008 at 7:34 AM, Stephen Sinclair <radarsat1@gmail.com> wrote:
> > The answer is simple: you should not be making partial commits to a
> > repo that has been cloned. You should instead be working somewhere
> > else and then pushing to it. So this whole sentence is just a moot
> > point itself.
>
> Let me amplify my objection to this.
>
> Who has 100% foresight that what they are doing is going to end up in
> a state where they'd like to make partial commits? To take a quote
> from a blog post, 'Git means never having to say, "you should have"'.
> And mostly it doesn't, and that's big improvement over other systems.
> But, that is what you are saying here. I "should have" realized that
> I should have pulled and fiddled with my changes there, and then
> pushed.
>
> Well, Dmitri and others will now say, why not just always pull and
> work somewhere else? And the reason is that because this creates
> extra, unnecessary steps the vast majority of the time when I do
> create a commit that I like and want to keep as-is in the first try.
> Why should I have to pull, commit, hack, and push, when hack and
> commit is all I need to do the vast majority of the time? It is
> redundant, unnecessary work and complexity that I should not have to
> pay for when I don't need it.
I think that in most cases the setup looks like the following: there
is private non-bare repository, ehere you can use topic branches,
and change and rewrite those changes at will, be it using plain rebase,
rebase --interactive, or some patch management interface like StGit
or Guilt. That is where you clean up your commits till they all fill
some standards / convention, like compiling (at least), or pass the
testsuite.
Then you merge it into one of long-lived "development" branches, and
push to your public (usually bare) publishing repository, which can
be for example on repo.or.cz, or on kernel.org.
That said "git stash (save|apply) --interactive" would be good
improvement for the situation where you have realized that you have
several unrelated changes in working directory, and want to decouple
them. One solution would be to commit, then split using interactive
rebase (or patch management tool), but with stash I guess it could be
simpler.
You should avoid such situation by stashing and changing the branch,
or refrshing current patch (to return to it later) and generating new
one if you use StGit or Guilt...
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] GIT-VERSION-GEN: do not fail if a 'HEAD' file exists in the working copy
From: Lea Wiemann @ 2008-06-28 17:13 UTC (permalink / raw)
To: git; +Cc: Lea Wiemann
Signed-off-by: Lea Wiemann <LeWiemann@gmail.com>
---
I had a created a "HEAD" file for test purposes (to see under what
conditions commands would fail). This patch allows git to still be
built even if such a file exists.
GIT-VERSION-GEN | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
index f221447..cb7cd4b 100755
--- a/GIT-VERSION-GEN
+++ b/GIT-VERSION-GEN
@@ -16,7 +16,7 @@ elif test -d .git -o -f .git &&
case "$VN" in
*$LF*) (exit 1) ;;
v[0-9]*)
- test -z "$(git diff-index --name-only HEAD)" ||
+ test -z "$(git diff-index --name-only HEAD --)" ||
VN="$VN-dirty" ;;
esac
then
--
1.5.6.1.205.g55df3e
^ permalink raw reply related
* Re: An alternate model for preparing partial commits
From: Wincent Colaiuta @ 2008-06-28 17:23 UTC (permalink / raw)
To: David Jeske; +Cc: Stephen Sinclair, Git Mailing List, Jakub Narebski
In-Reply-To: <willow-jeske-01l7ZyqpFEDjC=91ms>
El 27/6/2008, a las 22:45, David Jeske escribió:
> - I could supercede 2-commits with 1, effectively making the bad-
> commit
> disappear in the linear history. Users who already have the history,
> however,
> would be unaffected, because the start/end endpoints are the same.
You can't do that. The start might be the same but the end point would
not, even if the file contents happened to be the same as they were
before. This is because each commit is identified by its SHA-1 hash,
and changing any ancestor anywhere in the DAG will have a trickle-down
effect to all subsequent commits which stem from it, changing their
SHA-1 hashes too. So you wind up with a different end point. This is
by design (see below).
El 27/6/2008, a las 22:51, David Jeske escribió:
> What git can't do, is let me "supercede" the old DAG-subset, so
> people I shared
> them with can get my new changes without hurting their world.
> Currently git
> seems to rely on the idea that "if you accept changes into your tree
> that will
> be later rebased, it's up to you to figure it out". I don't see why
> that is the
> case.
It has to be this way because it is the only way to do distributed
SCM. Imagine for a minute that one developer has a commit "feedface",
fetched from another repo. If the commit or any parent (grand parent,
great grandparent etc) is changed then the hash _has_ to be different.
Otherwise you would have the untenable situation that two developers,
two repos, could refer to a particular commit "feedface" and it
wouldn't actually be the same thing. Distributed development would be
unworkably flakey if you couldn't rely on the stability of each
commit's SHA-1 hash, and that fact that it embodies not just that
particular state in the history, but all prior states too.
It's a totally basic, fundamental, central, non-negotiable concept to
Git's design. And not just an idiosyncrasy either; if you do a review
of other distributed SCMs out there you'll find that _all_ of them
have a similar underlying precept, as it's literally the only way to
do working distributed SCM.
Wincent
^ permalink raw reply
* Re: [PATCH] shrink git-shell by avoiding redundant dependencies
From: Johannes Schindelin @ 2008-06-28 17:31 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Git Mailing List
In-Reply-To: <37fcd2780806280948y143b619p60f05495ca85454b@mail.gmail.com>
Hi,
Thanks for the explanation. Somehow I thought "strip" would do what an
efficient linker should have done before, but I was wrong.
On Sat, 28 Jun 2008, Dmitry Potapov wrote:
> BTW, it is possible to reduce the "text" and "data" size twice more
> using the whole program optimization, as it will discard some functions
> that are not actually used, but I don't think it is worth pursuing as it
> will complicate complication.
Heh. Indeed, the complication will be complicated ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 11/15] Add strbuf_vaddf(), use it in strbuf_addf(), and add strbuf_initf()
From: Johannes Schindelin @ 2008-06-28 17:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, git, Olivier Marin
In-Reply-To: <7vk5gal3my.fsf@gitster.siamese.dyndns.org>
Hi,
On Fri, 27 Jun 2008, Junio C Hamano wrote:
> Do you really think these two patches belong to the series, I seriously
> have to wonder?
Heh. I suggested it, as I thought this was a perfect excuse to introduce
strbuf_initf(), which has been on my wishlist since long.
Anyway, I'm fine with having them only in my personal fork.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH, next version] git bisect: introduce 'fixed' and 'unfixed'
From: Junio C Hamano @ 2008-06-28 17:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, git
In-Reply-To: <alpine.DEB.1.00.0806281446260.9925@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>> > When you look for a fix instead of a regression, it can be quite hard
>> > to twist your brain into choosing the correct bisect command between
>> > 'git bisect bad' and 'git bisect good'.
>>
>> Hmm, I do not currently see any differene between master and next version
>> of bisect. In what way is this 'next' version?
>
> It has a "BAD" and a "GOOD" variable that are reset to "fixed" and
> "unfixed" if the user said "fixed" or "unfixed".
Ah, Ok, you did not mean "this is meant to applied to 'next' branch", but
meant "[PATCH v$N]" for some N > 1.
> But that, together with the visualize part, would take more time than I am
> willing to spend on this issue.
Other people would find itch (or they may not). Either way is fine.
^ permalink raw reply
* Re: An alternate model for preparing partial commits
From: Robert Anderson @ 2008-06-28 18:25 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Stephen Sinclair, Git Mailing List
In-Reply-To: <m3d4m1iivq.fsf@localhost.localdomain>
On Sat, Jun 28, 2008 at 10:12 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> "Robert Anderson" <rwa000@gmail.com> writes:
>
>> On Sat, Jun 28, 2008 at 7:34 AM, Stephen Sinclair <radarsat1@gmail.com> wrote:
>> > The answer is simple: you should not be making partial commits to a
>> > repo that has been cloned. You should instead be working somewhere
>> > else and then pushing to it. So this whole sentence is just a moot
>> > point itself.
>>
>> Let me amplify my objection to this.
>>
>> Who has 100% foresight that what they are doing is going to end up in
>> a state where they'd like to make partial commits? To take a quote
>> from a blog post, 'Git means never having to say, "you should have"'.
>> And mostly it doesn't, and that's big improvement over other systems.
>> But, that is what you are saying here. I "should have" realized that
>> I should have pulled and fiddled with my changes there, and then
>> pushed.
>>
>> Well, Dmitri and others will now say, why not just always pull and
>> work somewhere else? And the reason is that because this creates
>> extra, unnecessary steps the vast majority of the time when I do
>> create a commit that I like and want to keep as-is in the first try.
>> Why should I have to pull, commit, hack, and push, when hack and
>> commit is all I need to do the vast majority of the time? It is
>> redundant, unnecessary work and complexity that I should not have to
>> pay for when I don't need it.
>
> I think that in most cases the setup looks like the following: there
> is private non-bare repository, ehere you can use topic branches,
> and change and rewrite those changes at will, be it using plain rebase,
> rebase --interactive, or some patch management interface like StGit
> or Guilt. That is where you clean up your commits till they all fill
> some standards / convention, like compiling (at least), or pass the
> testsuite.
In my opinion it looks like that because git has poor support for
creating good partial commits the first time around.
I also think all of this rebase -i style approach is fine for an
experienced power user if they like that approach, but that splitting
the changes in a working tree is a very basic usage that should be a
part of a "Git in 20 minutes" tutorial. StGit, rebase -i, etc.,
should not.
In my experience this is pretty much the *first* thing a developer
faces when they decide that having a good incremental change history
is a good practice they want to follow. They usually shrug, commit
the hairball, and resolve to do better next time. But this is an
unavoidable scenario in real world development, and a good SCM manager
should have convenient facilities for dealing with it, that don't
reach into the power user toolbox like rebase -i (and let's face it,
that is an absurdly counterintuitive command for the job at hand), or
require auxilliary tools like StGit. The index is a start. But, IMO,
it isn't sufficient.
Stay tuned for some proposals about improving partial commit support.
Thanks,
Bob
^ permalink raw reply
* Re: An alternate model for preparing partial commits
From: Stephen Sinclair @ 2008-06-28 19:13 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <9af502e50806280930u788f81e2j77adf147a0e4d135@mail.gmail.com>
On Sat, Jun 28, 2008 at 12:00 PM, Robert Anderson <rwa000@gmail.com> wrote:
> On Sat, Jun 28, 2008 at 7:34 AM, Stephen Sinclair <radarsat1@gmail.com> wrote:
>> The answer is simple: you should not be making partial commits to a
>> repo that has been cloned. You should instead be working somewhere
>> else and then pushing to it. So this whole sentence is just a moot
>> point itself.
>
> Ah, now you've hit the crux. Thank you for the "svn style" response
> here. I "should not" because git has a deficiency. Absolutely no
> other reason.
No, you said that a certain operation (testing partial commits) was
impossible. I told you how I approach the problem with git and tried
to show that it was entirely possible. That is all.
On Sat, Jun 28, 2008 at 12:30 PM, Robert Anderson <rwa000@gmail.com> wrote:
> Why should I have to pull, commit, hack, and push, when hack and
> commit is all I need to do the vast majority of the time?
But what you have described here, the difference between "commit/push"
and just "commit", is _exactly_ what differentiates distributed and
centralized SCM systems.
To go back to the basic problem that you suggested, that partial
commits can easily go untested, in the "hack and commit" model this is
impossible to work around. In the "hack, commit, go back and fix,
commit, push" model, which git makes possible, it _is_ possible to do
the testing that you desire.
Steve
^ permalink raw reply
* Re: An alternate model for preparing partial commits
From: David Jeske @ 2008-06-28 19:12 UTC (permalink / raw)
To: Robert Anderson; +Cc: Jakub Narebski, Stephen Sinclair, Git Mailing List
In-Reply-To: <9af502e50806281125v5459f7deuc14256044b3e726@mail.gmail.com>
-- Robert Anderson wrote:
> If I come back to a branch on which there are several
> commits which have not been pushed yet, how do I know which are
> "temporary" and which are "for real" commits? I cannot. It is
> impossible. The information is not there.
This comment resonates with me Robert. Because git's concept of a workspace
is a "non-tracking branch", git doesn't automate having "temporary" and "for
real" commits intermixed in the workspace, or having more than one "named set
of temporary commits".
Imagine if we use git's mechanisms to setup a "p4 change" style workflow. In
that workflow, we can have multiple outstanding named changes in the same
working-files. This seems simple and reasonable to me, I use it quite a bit in
p4. My most common use of it is to prevent myself from accidentally publishing
a set of edited files that are supposed to remain local as I'm iterating (I
throw them in a "don't submit this yet" pending change).
If we dynamically compose a "workspace" out of 2 temporary "changes" it might
look like this:
: /---PQ workspace/1
: |<- Q / change/feature1
: |<---- P change/feature2
: |
: --A<--B master
You're working in workspace 1, and you could pretty easily make the equivilant
of "git commit -c change/feature2". That would say, "hey, commit this change,
and then merge it down to "change/feature2 branch" as R'.
: /---PQ---R workspace/1
: |<- Q / / change/feature1
: |<---- P<---R' change/feature2
: |
: --A<--B master
This seems doable, and git's mechanisms would make it pretty easy (though it
feels dangerous to me).
You can then merge either change onto the master when it's done. Your little
wrapper could give you a "workspace rebase" which could destroy the workspace,
rebase all the features, and recompose the workspace. If you want to rebase one
of the changes onto the master, again, your wrapper destroys the workspace,
rebases and pushes the change, rebases the rest of the changes, and recreates
your workspace.
All of that "destroying the workspace" is required because rebase is a change
operation which does not contain merge-history. In the setup above, your
"change/*" branches are effectively "published to your workspace", so if you
rebase either of them, you're technically rebasing something that's published,
and "workspace" will be in a world of hurt. Therefore, one solution is to
destroy the workspace, making the rebase a valid operation, then recompose it.
Personally, I'd like to see rebase made to have merge history, using some kind
of "soft-dag-link" that would cause it to work for anyone who had those
changes, while not causing the history to show or hold onto those parents.
^ permalink raw reply
* Re: An alternate model for preparing partial commits
From: David Jeske @ 2008-06-28 19:12 UTC (permalink / raw)
To: Robert Anderson; +Cc: Jakub Narebski, Stephen Sinclair, Git Mailing List
In-Reply-To: <9af502e50806281125v5459f7deuc14256044b3e726@mail.gmail.com>
-- Robert Anderson wrote:
> If I come back to a branch on which there are several
> commits which have not been pushed yet, how do I know which are
> "temporary" and which are "for real" commits? I cannot. It is
> impossible. The information is not there.
This comment resonates with me Robert. Because git's concept of a workspace
is a "non-tracking branch", git doesn't automate having "temporary" and "for
real" commits intermixed in the workspace, or having more than one "named set
of temporary commits".
Imagine if we use git's mechanisms to setup a "p4 change" style workflow. In
that workflow, we can have multiple outstanding named changes in the same
working-files. This seems simple and reasonable to me, I use it quite a bit in
p4. My most common use of it is to prevent myself from accidentally publishing
a set of edited files that are supposed to remain local as I'm iterating (I
throw them in a "don't submit this yet" pending change).
If we dynamically compose a "workspace" out of 2 temporary "changes" it might
look like this:
: /---PQ workspace/1
: |<- Q / change/feature1
: |<---- P change/feature2
: |
: --A<--B master
You're working in workspace 1, and you could pretty easily make the equivilant
of "git commit -c change/feature2". That would say, "hey, commit this change,
and then merge it down to "change/feature2 branch" as R'.
: /---PQ---R workspace/1
: |<- Q / / change/feature1
: |<---- P<---R' change/feature2
: |
: --A<--B master
This seems doable, and git's mechanisms would make it pretty easy (though it
feels dangerous to me).
You can then merge either change onto the master when it's done. Your little
wrapper could give you a "workspace rebase" which could destroy the workspace,
rebase all the features, and recompose the workspace. If you want to rebase one
of the changes onto the master, again, your wrapper destroys the workspace,
rebases and pushes the change, rebases the rest of the changes, and recreates
your workspace.
All of that "destroying the workspace" is required because rebase is a change
operation which does not contain merge-history. In the setup above, your
"change/*" branches are effectively "published to your workspace", so if you
rebase either of them, you're technically rebasing something that's published,
and "workspace" will be in a world of hurt. Therefore, one solution is to
destroy the workspace, making the rebase a valid operation, then recompose it.
Personally, I'd like to see rebase made to have merge history, using some kind
of "soft-dag-link" that would cause it to work for anyone who had those
changes, while not causing the history to show or hold onto those parents.
^ permalink raw reply
* git-svn messed up import, badly
From: Björn Steinbrink @ 2008-06-28 19:48 UTC (permalink / raw)
To: git; +Cc: Eric Wong, Adam Roben, Avery Pennarun, Samuel Bronson
Hi,
Samuel reported on #git that a git-svn import was failing for him. I
tried to reproduce that, and while it failed on a different svn revision
for me, it still failed pretty badly.
The repo is at:
svn://scm.gforge.inria.fr/svn/coq/
I cloned with:
git svn clone -s svn://scm.gforge.inria.fr/svn/coq/
And with my current git-svn import, I'm getting this error message:
Checksum mismatch: trunk/.depend 16e748c219f9f95bf3d05c6b2af5444290bc8471
expected: 05fb5edb8c8057be006c7e913ae0c764
got: 763b9a426c5bd61e0a85252459d37cfa
I got that when it bailed out from "git svn clone" and I get it on each
"git svn fetch" run, trying to resume the import.
Looking at the history of trunk/.depend and comparing the diffs that git
gives me to those that "svn diff" gives me, I noticed that the diffs for
changes to .depend introduced in svn revision 2314 differ heavily
between svn and my git-svn import.
Tarball of the repo and the two diffs is at:
http://people.linux-vserver.org/~doener/broken-git-svn-import.tbz
[4.8MB]
$ git --version
git version 1.5.6.1.78.gde8d9
git svn --version
git-svn version 1.5.6.1.78.gde8d9 (svn 1.4.6)
Avery and Adam on Cc:, because Avery reported a somewhat similar issue
that he bisected down to the git-svn speed-up patch by Adam.
Unfortunately, I currently don't have enough time on my hands to perform
a bisection.
If you need anything else, let me know.
Thanks,
Björn
^ permalink raw reply
* [PATCH] fix git config example syntax
From: Joey Hess @ 2008-06-28 20:02 UTC (permalink / raw)
To: git
git-config expects a space, not '=' between option and value.
Also, quote the value since it contains globs, which some shells will not
pass through unchanged, or will abort if the glob doesn't expand.
Signed-off-by: Joey Hess <joey@kitenet.net>
---
Documentation/git-svn.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 97bed54..c350ad0 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -513,7 +513,7 @@ have each person clone that repository with 'git clone':
cd project
git-init
git remote add origin server:/pub/project
- git config --add remote.origin.fetch=+refs/remotes/*:refs/remotes/*
+ git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/*'
git fetch
# Initialize git-svn locally (be sure to use the same URL and -T/-b/-t options as were used on server)
git-svn init http://svn.foo.org/project
--
1.5.5.4
^ permalink raw reply related
* Re: Errors building git-1.5.6 from source on Mac OS X 10.4.11
From: Alex Riesen @ 2008-06-28 20:34 UTC (permalink / raw)
To: Ifejinelo Onyiah; +Cc: git
In-Reply-To: <2eb980790806270143i5caec64fs498d9ca08acb0a1c@mail.gmail.com>
Ifejinelo Onyiah, Fri, Jun 27, 2008 10:43:05 +0200:
> > could you try the command _without_ "bash -x"?
> > Like this:
> >
> > cd t
> > ./t2004-checkout-cache-temp.sh -d -v -i
> >
>
> I've just done that and here's the output:
>
> io1@mib19412i[00m:~/Desktop/git-1.5.6/t$ ./t2004-checkout-cache-temp.sh -d -v -i
> * expecting success:
...
> * passed all 18 test(s)
So it succeeded... Complicated, then. You can try removing the
command-line options (except -i, which just makes the script stop
after the first failure):
./t2004-checkout-cache-temp.sh -i -v
./t2004-checkout-cache-temp.sh -i -d
and see if it breaks. Either -d or -v will help to pinpoint the test,
which failed more precisely.
Or, you can also try to build everything from scratch first (by
re-cloning your git repo somewhere and building it there). As far as
I understood, the "make test" failed after you tried to build things
first time, right?
P.S. sorry for slow communication. I'm rarely on the net. A more
active debugging session can be had on IRC, there is some experienced
folk hanging around there (irc.freenode.net, channel #git).
^ permalink raw reply
* Re: [RFC/PATCH] Documentation: Don't assume git-sh-setup and git-parse-remote are in the PATH
From: Alex Riesen @ 2008-06-28 20:58 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
In-Reply-To: <20080627151001.BIA19424@m4500-01.uchicago.edu>
Jonathan Nieder, Fri, Jun 27, 2008 22:10:01 +0200:
> --------
> +[verse]
> +'PATH=$(git --exec-path):$PATH'
> '. git-parse-remote'
You missed quoting. exec-path can contain whitespace. What do you need
exec-path in PATH for?
^ permalink raw reply
* [PATCH] Revert "git-svn: Speed up fetch"
From: Avery Pennarun @ 2008-06-28 20:57 UTC (permalink / raw)
To: Eric Wong, Adam Roben, Samuel Bronson, B.Steinbrink, git; +Cc: Avery Pennarun
In-Reply-To: <20080628194808.GA29908@atjola.homenet>
This reverts commit ffe256f9bac8a40ff751a9341a5869d98f72c285, because it
was causing errors of the form:
Checksum mismatch: trunk/.depend 16e748c219f9f95bf3d05c6b2af5444290bc8471
expected: 05fb5edb8c8057be006c7e913ae0c764
got: 763b9a426c5bd61e0a85252459d37cfa
Note that the exact failing file and checksum seems to vary if you clear
the repository and try again.
Conflicts:
git-svn.perl
---
Obviously it would be better to actually fix the bug here than the revert
the patch (because the patch really *does* make fetch go a lot faster), but
I don't know where to begin, and it's a pain to debug because of the
variability.
git-svn.perl | 42 ++++++++++++++++++++++--------------------
1 files changed, 22 insertions(+), 20 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 4c9c59b..a02bcf4 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -4,7 +4,7 @@
use warnings;
use strict;
use vars qw/ $AUTHOR $VERSION
- $sha1 $sha1_short $_revision $_repository
+ $sha1 $sha1_short $_revision
$_q $_authors %users/;
$AUTHOR = 'Eric Wong <normalperson@yhbt.net>';
$VERSION = '@@GIT_VERSION@@';
@@ -223,7 +223,6 @@ unless ($cmd && $cmd =~ /(?:clone|init|multi-init)$/) {
}
$ENV{GIT_DIR} = $git_dir;
}
- $_repository = Git->repository(Repository => $ENV{GIT_DIR});
}
my %opts = %{$cmd{$cmd}->[2]} if (defined $cmd);
@@ -305,7 +304,6 @@ sub do_git_init_db {
}
}
command_noisy(@init_db);
- $_repository = Git->repository(Repository => ".git");
}
my $set;
my $pfx = "svn-remote.$Git::SVN::default_repo_id";
@@ -322,7 +320,6 @@ sub init_subdir {
mkpath([$repo_path]) unless -d $repo_path;
chdir $repo_path or die "Couldn't chdir to $repo_path: $!\n";
$ENV{GIT_DIR} = '.git';
- $_repository = Git->repository(Repository => $ENV{GIT_DIR});
}
sub cmd_clone {
@@ -3040,7 +3037,6 @@ use vars qw/@ISA/;
use strict;
use warnings;
use Carp qw/croak/;
-use File::Temp qw/tempfile/;
use IO::File qw//;
# file baton members: path, mode_a, mode_b, pool, fh, blob, base
@@ -3196,9 +3192,14 @@ sub apply_textdelta {
my $base = IO::File->new_tmpfile;
$base->autoflush(1);
if ($fb->{blob}) {
- print $base 'link ' if ($fb->{mode_a} == 120000);
- my $size = $::_repository->cat_blob($fb->{blob}, $base);
- die "Failed to read object $fb->{blob}" if ($size < 0);
+ defined (my $pid = fork) or croak $!;
+ if (!$pid) {
+ open STDOUT, '>&', $base or croak $!;
+ print STDOUT 'link ' if ($fb->{mode_a} == 120000);
+ exec qw/git-cat-file blob/, $fb->{blob} or croak $!;
+ }
+ waitpid $pid, 0;
+ croak $? if $?;
if (defined $exp) {
seek $base, 0, 0 or croak $!;
@@ -3239,18 +3240,14 @@ sub close_file {
sysseek($fh, 0, 0) or croak $!;
}
}
-
- my ($tmp_fh, $tmp_filename) = File::Temp::tempfile(UNLINK => 1);
- my $result;
- while ($result = sysread($fh, my $string, 1024)) {
- syswrite($tmp_fh, $string, $result);
+ defined(my $pid = open my $out,'-|') or die "Can't fork: $!\n";
+ if (!$pid) {
+ open STDIN, '<&', $fh or croak $!;
+ exec qw/git-hash-object -w --stdin/ or croak $!;
}
- defined $result or croak $!;
- close $tmp_fh or croak $!;
-
+ chomp($hash = do { local $/; <$out> });
+ close $out or croak $!;
close $fh or croak $!;
-
- $hash = $::_repository->hash_and_insert_object($tmp_filename);
$hash =~ /^[a-f\d]{40}$/ or die "not a sha1: $hash\n";
close $fb->{base} or croak $!;
} else {
@@ -3576,8 +3573,13 @@ sub chg_file {
} elsif ($m->{mode_a} =~ /^120/ && $m->{mode_b} !~ /^120/) {
$self->change_file_prop($fbat,'svn:special',undef);
}
- my $size = $::_repository->cat_blob($m->{sha1_b}, $fh);
- croak "Failed to read object $m->{sha1_b}" if ($size < 0);
+ defined(my $pid = fork) or croak $!;
+ if (!$pid) {
+ open STDOUT, '>&', $fh or croak $!;
+ exec qw/git-cat-file blob/, $m->{sha1_b} or croak $!;
+ }
+ waitpid $pid, 0;
+ croak $? if $?;
$fh->flush == 0 or croak $!;
seek $fh, 0, 0 or croak $!;
--
1.5.4.3
^ permalink raw reply related
* Re: [RFC/PATCH] Documentation: Don't assume git-sh-setup and git-parse-remote are in the PATH
From: Junio C Hamano @ 2008-06-28 21:05 UTC (permalink / raw)
To: Alex Riesen; +Cc: Jonathan Nieder, git
In-Reply-To: <20080628205817.GB3172@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
> Jonathan Nieder, Fri, Jun 27, 2008 22:10:01 +0200:
>> --------
>> +[verse]
>> +'PATH=$(git --exec-path):$PATH'
>> '. git-parse-remote'
>
> You missed quoting. exec-path can contain whitespace.
Do you understand shell quoting rules?
$ foo='c d'
$ foo=$(echo a b):$foo
$ echo "$foo"
a b:c d
$ exit
> What do you need exec-path in PATH for?
When git-parse-remote is not installed in $(bindir) anymore, the shell
script library won't be found on user's $PATH in general.
^ permalink raw reply
* Re: An alternate model for preparing partial commits
From: Junio C Hamano @ 2008-06-28 21:53 UTC (permalink / raw)
To: Jeff King; +Cc: Robert Anderson, Johannes Schindelin, Git Mailing List
In-Reply-To: <20080628085359.GA29619@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Actually, I oversimplified a little bit in my "buckets" description.
> Stash actually stashes two things: the current index and the current
> worktree. So in that sense, it is not just another bucket as I
> described. For the purposes of the workflow we're discussing, I think
> that is how we want it to function. But the implementation will be a bit
> trickier than it might otherwise be because of this. I just didn't want
> to have to introduce another, slightly different type of stash.
You do *not* have to use stash that has different index and work tree
components and then your buckets description makes sense.
The index is to hold good changes verified to be fine to make commits, the
work tree is to test and verify outstanding changes, and the stash is to
hold the remainder (i.e. further changes that does not belong to what you
are currently looking at in your work tree).
When your workflow is to "verify and immediately commit", then the need
for buckets to your particular workflow can degenerate to a one that does
not need the index. That is essentially Robert's workflow (but it does
not mean it is the only valid one).
What I do these days is this:
* Fork a new topic from the commit I pushed out the last time to the
public ("git checkout -b jc/topic ko/master").
* Think, hack, commit, think, hack, commit, lather, rinse, repeat.
* Make sure everything is worthy for the final state. There can be (and
need to be to use the current set of tools) some uncommitted changes.
Make a stash, so that the work tree component records the final tree,
and mentally name it the "commit goal".
* I have never grew comfortable operating "edit" insn in "rebase -i", so
the workflow from this point does not use it. Instead, I detech the
HEAD to the root of the series ("git checkout ko/master^0") at this
point. Now, none of my change is in the work tree.
* Repeat the following:
* Recreate the work tree state for the next round to be built on HEAD
and make a commit, after verifying what I have in the commit is good.
Examples of the tools at my disposal are:
* "cherry-pick jc/topic~$N" to get the necessary changes from my
earlier "snapshots", which can possibly be followed by a "git
commit --amend". This "going forward" is easiest especially in the
early part of the sequence.
"format-patch --stdout jc/topic~$N..jc/topic~$M | git am" is a
slight variant of the above when I already had a good logical
sequence (someday we probably will have "cherry-pick A..B").
* "read-tree -m -u stash" to read the final state of the tree,
selectively _remove_ the parts I do not want in this round, and
make a commit ("git add -i && git commit && git reset --hard").
This "going backward" is easier near the end of the sequence than
other method that goes forward.
* If I find some issues to be fixed in the state that was stashed
(which I earlier thought was perfect) during the above:
* "read-tree -m -u stash" to read the (previous) final state, fix it
up, "stash drop" and "stash save" to update our "commit goal".
The above is repeated until "git diff HEAD stash" does not have
anything I need in the final series.
The lower-level "read-tree -m -u" probably can be replaced with "stash
apply" in real life, but I tend to try to ask for the final tree
explicitly, because there is no reason to perform three-way merge dance
"stash apply" does for these steps.
* Final re-review:
* "git diff jc/topic HEAD" to see if I did not miss anything (and review
the "oops, the earlier commit goal was faulty" fixes).
* "git log --reverse -p ko/master.." to see the final shape of the
series.
* "git branch -f jc/topic" to finish it off.
The commits from the session are merely convenient snapshot points that I
can use during the clean-up phase for series of cherry-picks to prepare
bulk of each of the logical change in the final series. If somebody
subscribes to a dogma not to make commits of unproven changes, that is
fine, and such a person may not have any commits during "think, hack,
lather, rinse, repeat" phase, and that is fine. But fortunately I don't.
^ 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