* Re: [ANNOUNCE] Git-1.6.0.2-preview20080923
From: Johannes Schindelin @ 2008-09-23 9:36 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: msysGit, Git Mailing List
In-Reply-To: <B463062F-DD48-44A7-B2BB-8E5E0D177616@zib.de>
Hi,
On Tue, 23 Sep 2008, Steffen Prohaska wrote:
> I apologize for the quality of Git-1.6.0.2-preview20080921.
> It was unacceptable.
No, that is too harsh. There is some meaning in the infix "preview", and
given that you gave everybody (me included, I have to admit) the chance to
work on this installer earlier, there is nothing to apologize for.
Ciao,
Dscho
^ permalink raw reply
* Re: rebasing merges
From: Stephen Haberman @ 2008-09-23 9:30 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Johannes Sixt, git
In-Reply-To: <48D8B2C1.5070800@op5.se>
> > Does this sound reasonable?
>
> It sounds very reasonable indeed
Ah, cool, thanks for validating our approach. We have so far been
slowly figuring it out and it has been nice.
> but then I don't understand why you held off pushing the merge.
Ah, yes, that is the trick, to get it out quickly. Usually it is not a
problem, but in ~2-3 months of using git, it's happened on high-churn
branches about 4-5 times (usually it is the next release candidate
branch where people are actively making small bug fixes and one guy
gets caught with a non-trivial merge in from stable).
Not all that bad, really, other than it caused a few "wtf git"
comments. Which is unfortunate as, while I enjoy git, the team as a
whole is still learning. Seeing the DAGs, and understanding the
patch/apply approach of the non-interactive rebase, it makes sense to
me what git is doing. And so while I know to watch for it, I'm trying to
find a more bullet proof approach.
> That's beside the point though, as I firmly believe git should be more
> helpful in this situation. If "git rebase -i -p" doesn't help you fix
> the problems, I'll see what I can do to help.
That's very cool, thanks. I'll start writing a test now.
- Stephen
^ permalink raw reply
* Re: rebasing merges
From: Andreas Ericsson @ 2008-09-23 9:11 UTC (permalink / raw)
To: Stephen Haberman; +Cc: Johannes Sixt, git
In-Reply-To: <20080923040302.c4d0d33b.stephen@exigencecorp.com>
Stephen Haberman wrote:
>>> ---A--B--C--D <-- origin/stable
>>> \ |
>>> E--F | <-- origin/topica
>>> \ |
>>> g--h <-- topica
>>>
>>> All the upper case commits have been published to origin. Other
>>> devs, etc., know about them, their hashes are in the bug tracking
>>> system.
>>>
>>> I'm bringing topica up to date, but with a merge because I have
>>> published history already on topica, so I merge stable and get a
>>> new merge commit: g. And maybe make another change: h.
>>>
>> Why do you merge stable at this point?
>
> Good question--I appreciate the sanity check.
>
> I merged stable because we had a new release of the software. E.g.
> A=1.0, B=1.1, C=1.2, and finally D=1.3.
>
> So, topica is a new feature, "Add widgets/whatever", but it's not ready
> for stable (production) yet, so, yes, I think it is a topic branch.
>
> However, D=1.4 is now out the door, I've had two commits E and F on
> topica that I had already committed and pushed out for code review, our
> email list, and our bug tracker, and now, post-1.4, qa wants to see
> topica up and running to see if it's good enough to go into the next
> release.
>
> If our deployment guy pushes out F, qa is going to (and did) complain
> that they're not seeing the latest features from 1.4 in topica.
>
> As you said, integration testing.
>
> Okay, so I merge g, however, I really want to push it back out so that
> the deployment guy can push it to qa (he would rather not resolve my
> conflicts by making his own local g). And even if I did the deployment
> myself, locally against g, I would prefer to share g in case another
> dev working on the same topic gets feedback about funkiness from qa and
> would like to see the code as it is in qa. E.g.: g.
>
> I can appreciate that if I was doing integration testing all by myself,
> with only automated tests, I could throw g away. However, even then, I
> would prefer to push g out and let our integration server run the tests
> for me.
>
> Does this sound reasonable?
>
It sounds very reasonable indeed, but then I don't understand why you
held off pushing the merge.
That's beside the point though, as I firmly believe git should be more
helpful in this situation. If "git rebase -i -p" doesn't help you fix
the problems, I'll see what I can do to help.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: rebasing merges
From: Stephen Haberman @ 2008-09-23 9:03 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Johannes Sixt, git
In-Reply-To: <48D8A6EA.4020805@op5.se>
> > ---A--B--C--D <-- origin/stable
> > \ |
> > E--F | <-- origin/topica
> > \ |
> > g--h <-- topica
> >
> > All the upper case commits have been published to origin. Other
> > devs, etc., know about them, their hashes are in the bug tracking
> > system.
> >
> > I'm bringing topica up to date, but with a merge because I have
> > published history already on topica, so I merge stable and get a
> > new merge commit: g. And maybe make another change: h.
> >
>
> Why do you merge stable at this point?
Good question--I appreciate the sanity check.
I merged stable because we had a new release of the software. E.g.
A=1.0, B=1.1, C=1.2, and finally D=1.3.
So, topica is a new feature, "Add widgets/whatever", but it's not ready
for stable (production) yet, so, yes, I think it is a topic branch.
However, D=1.4 is now out the door, I've had two commits E and F on
topica that I had already committed and pushed out for code review, our
email list, and our bug tracker, and now, post-1.4, qa wants to see
topica up and running to see if it's good enough to go into the next
release.
If our deployment guy pushes out F, qa is going to (and did) complain
that they're not seeing the latest features from 1.4 in topica.
As you said, integration testing.
Okay, so I merge g, however, I really want to push it back out so that
the deployment guy can push it to qa (he would rather not resolve my
conflicts by making his own local g). And even if I did the deployment
myself, locally against g, I would prefer to share g in case another
dev working on the same topic gets feedback about funkiness from qa and
would like to see the code as it is in qa. E.g.: g.
I can appreciate that if I was doing integration testing all by myself,
with only automated tests, I could throw g away. However, even then, I
would prefer to push g out and let our integration server run the tests
for me.
Does this sound reasonable?
Thanks,
Stephen
^ permalink raw reply
* Re: [ANNOUNCE] Git-1.6.0.2-preview20080923
From: Christian MICHON @ 2008-09-23 8:51 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: msysGit, Git Mailing List
In-Reply-To: <B463062F-DD48-44A7-B2BB-8E5E0D177616@zib.de>
On Tue, Sep 23, 2008 at 8:09 AM, Steffen Prohaska <prohaska@zib.de> wrote:
> On Sep 21, 2008, at 7:33 PM, Steffen Prohaska wrote:
>
>> Git-1.6.0.2-preview20080921 for Windows is available at
>>
>> http://code.google.com/p/msysgit/downloads
>
>
> I updated the installer to Git-1.6.0.2-preview20080923.
> The problems reported on the mailing list during the
> last two days should be fixed.
>
> I apologize for the quality of Git-1.6.0.2-preview20080921.
> It was unacceptable.
>
> Steffen
working fine now on existing or new repositories.
good work!
--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
^ permalink raw reply
* Re: Locking binary files
From: Andreas Ericsson @ 2008-09-23 8:31 UTC (permalink / raw)
To: Mario Pareja, Git Mailing List
In-Reply-To: <94c1db200809230054t20e7e61dh5022966d4112eee6@mail.gmail.com>
Mario, please don't reply in private. That way your mails won't
get indexed and you don't have a chance to get help from others
on the mailing list.
While we're at it; don't top-post. Most people who frequent email
lists with moderate to high traffic read hundreds of emails every
day, so a quick reminder of what the discussion was about is useful
when getting a reply. That reminder gets a lot trickier to get to
if you first have to scroll down and then back up. Besides that,
it feels totally backwards.
Mario Pareja wrote:
> Andreas,
>
> Thanks for the quick reply. You asked how I thought locking could
> have helped. I think locking helps notify a developer that a file is
> being modified _before_ the developer begins his/her own
> modifications. If I followed your example correctly, the conflict is
> identified after the work has been done - this is too late if you ask
> me.
>
So it's a communication issue then. The way I understand locks in svn
and cvs is that they also only bother you when you want to check in the
file you've just recently modified, or if multiple people want to lock
the same file at the same time.
If that's the case, I see no problem what so ever with teaching specific
git commands to interact with a locking server. git lock (and git unlock)
would have to be coupled with a git-lock-daemon with wich everyone
communicates. It should probably have the ability to run a hook or
something (centrally) when a lock is obtained and released, so as to be
able to notify others that a lock is held.
I might write this for fun some day, but it's really not my itch to
scratch, and it would be a terrible mistake to add something like a
central repository to take care of it when a single rather stupid
daemon and an equally stupid program could do the same work but much
more efficiently.
Note that locking would be completely advisory though, and nothing
would prevent people from committing changes to a locked file. Then
again, insofar as I understand SVN/CVS locking, that's how those
work too, except that an SVN "checkin" would be the equivalent of
"git commit && git push" (the push part of the git sequence won't
work).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: rebasing merges
From: Andreas Ericsson @ 2008-09-23 8:20 UTC (permalink / raw)
To: Stephen Haberman; +Cc: Johannes Sixt, git
In-Reply-To: <20080923024653.a3bb8666.stephen@exigencecorp.com>
Stephen Haberman wrote:
>> This is the expected behavior and not up for debate.
>
> Cool, thanks for the reply. However, I debate... :-)
>
>> ---o--o--o--o--o--o <-- origin
>> \
>> A'--B' <-- master
>
> Nice. That makes sense in your scenario.
>
> Here is mine:
>
> ---A--B--C--D <-- origin/stable
> \ |
> E--F | <-- origin/topica
> \ |
> g--h <-- topica
>
> All the upper case commits have been published to origin. Other
> devs, etc., know about them, their hashes are in the bug tracking
> system.
>
> I'm bringing topica up to date, but with a merge because I have
> published history already on topica, so I merge stable and get a
> new merge commit: g. And maybe make another change: h.
>
Why do you merge stable at this point?
If you want the latest and greatest for testing/conflict resolution
purposes, you can simply throw away the merge later and just know
that it works.
If you need some bugfix on stable but not everything else, cherrypick
only that change. Otherwise you're applying a huge patch to fix a
small problem.
> Everything's cool...now, with surprising frequency, someone beats
> me to moving origin/topica:
>
> ---A--B--C--D <-- origin/stable
> \ |
> E--F---|--I <-- origin/topica
> \ |
> g--h <-- topica
>
> Pushing h gets rejected as a rewind. Good. I want to pull, which
> we had previously always used "--rebase" for, and the desired output
> of a pull --rebase, to me, would be:
>
> ---A--B--C--D <-- origin/stable
> \ \
> E--F--I | <-- origin/topica
> \|
> g'--h' <-- topica
>
> Instead, I get:
>
> ---A--B--C--D <-- origin/stable
> \
> E--F--I <-- origin/topica
> \
> B'-C'-D'-h'<-- topica
>
> So, yes, linearized history with no merges. However, this leads
> to quizzical looks when B'/C'/D' hit the email list, bug tracker, etc.
> as new commits.
>
> Currently I just try to pull/merge/push in quick succession, but
> it's a manual collaboration hack ("okay, I'm merging now, no
> committing...") that would be nice to not have to worry about.
>
I think you just need to ask yourself *why* you're doing that
first merge of "stable" into your topic. If they aren't really
separate, using a topic-branch doesn't make so much sense. If
they *are* separate, doing the merge doesn't make much sense,
unless you're integration testing a snapshot build, but in that
case you'd want to throw away the merge once it's done and
tested.
> I need to investigate the interactive rebase more, but my hesitant
> assertion is that it's parent rewriting seems smart enough to handle
> this. Perhaps not, and I admit our desired DAG output may not be
> attainable without manual intervention.
>
> I apologize--I should have included the example DAGs in my first
> post, but since I didn't I felt the need to clarify. So, humoring
> me, is the B'/C'/D' from this example really the expected behavior?
>
Assuming the person who did "h" doesn't have the merge commit, then
yes.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: rebasing merges
From: Andreas Ericsson @ 2008-09-23 8:06 UTC (permalink / raw)
To: Samuel Tardieu; +Cc: Johannes Sixt, Stephen Haberman, git
In-Reply-To: <2008-09-23-09-30-47+trackit+sam@rfc1149.net>
Samuel Tardieu wrote:
>
> Btw, would it be a good idea to unconditionally enable "rerere"
> conflict resolution *recording*, and add an option to "rebase" and
> "merge" to use "rerere" even when it is not enabled in the
> configuration file? I can't think of any drawback.
>
I'm all for that. I actually thought (4 months ago) that that was
how it worked.
It would be a backwards incompatible change though, as we currently
fall back to "does rr-cache exist?" to determine if rerere is enabled
in case it isn't explicitly so in the configuration. Perhaps print
a warning if !rerere.enabled but $GIT_DIR/rr-cache exists. OTOH,
that will create a lot of warnings since we'd have to create that
rr-cache directory to record the resolutions.
To maintain backwards compatibility, we could ofcourse do like this;
* move rr-cache to rere ("recorded resolutions"; bikeshed color goes here)
* if rr-cache exists, implicitly enable rerere
* if rr-cache holds resolutions when setting up rerere, move them
to rere
OR
* look for resolutions in both rr-cache and rere indefinitely.
It's not exactly performance critical, so swapping the pattern from
O(n) (or whatever it is now) to O(2n) for replaying resolutions
probably won't make that much of a difference.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: rebasing merges
From: Johannes Sixt @ 2008-09-23 8:00 UTC (permalink / raw)
To: Stephen Haberman; +Cc: git
In-Reply-To: <20080923024653.a3bb8666.stephen@exigencecorp.com>
Stephen Haberman schrieb:
>> This is the expected behavior and not up for debate.
>
> Cool, thanks for the reply. However, I debate... :-)
>
>> ---o--o--o--o--o--o <-- origin
>> \
>> A'--B' <-- master
>
> Nice. That makes sense in your scenario.
>
> Here is mine:
I understand your problem very well. pull --rebase does not help your case
because it was not designed for your workflow (it was designed to help the
one that I sketched).
You are probably better served using fetch + rebase -i -p.
-- Hannes
^ permalink raw reply
* Re: [ANNOUNCE] Git-1.6.0.2-preview20080923
From: Peter Krefting @ 2008-09-23 7:57 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: msysGit, Git Mailing List
In-Reply-To: <B463062F-DD48-44A7-B2BB-8E5E0D177616@zib.de>
Steffen Prohaska:
> The problems reported on the mailing list during the last two days
> should be fixed.
Works without crashing for me now. The installer issue is still there,
but I guess it takes another iteration to get to work (i.e, next time I
install?)
> I apologize for the quality of Git-1.6.0.2-preview20080921.
> It was unacceptable.
Nah, that's the joy of being first to test software :-) Nothing broke,
just a few things that didn't quite work as expected, so no worries.
Thanks for doing the job of publishing, fixing and republishing!
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: rebasing merges
From: Johannes Sixt @ 2008-09-23 7:52 UTC (permalink / raw)
To: Samuel Tardieu; +Cc: Stephen Haberman, git
In-Reply-To: <2008-09-23-09-30-47+trackit+sam@rfc1149.net>
Samuel Tardieu schrieb:
>>>>>> "Johannes" == Johannes Sixt <j.sixt@viscovery.net> writes:
>
> Johannes> i.e. linearized history without merges.
>
> A few days ago, I had a question in my team quite similar to Stephen
> concern. A developer had performed a merge of a complex feature and
> was ready to commit it
>
> --o--o--o--o--X <-- origin
> \ \
> A--B--C--D--E <-- master
>
> when he realized that someone just pushed another change on origin
> while he was doing the complicating merge (with lots of conflicts to
> resolve). The configuration was then:
>
> --o--o--o--o--X--Y <-- origin
> \ \
> A--B--C--D--E <-- master
>
> He would have wanted to have the merge rebased on E and Y instead of E
> and X before pushing, without going through all the conflicts
> resolution again (he didn't have "rerere" enabled).
If you mean "merge", and you are willing to keep E, then you do another
merge to get this history:
--o--o--o--o--X--Y <-- origin
\ \ \
A--B--C--D--E--F <-- master
and the previous conflicts will not show up again. But if you do not want
E to show up in the history, like this:
--o--o--o--o--X--Y <-- origin
\ \
A--B--C--D-----F <-- master
then you will have to resolve all conflicts again. Of course, you can keep
E in a temporary branch, and you can selectively check out files from
that tree to safe some work, but whether this is possible depends on the
changes that Y introduces.
If you mean "rebase", then you get this after the first rebase:
--o--o--o--o--X--Y <-- origin
\
A'--B'--C'--D' <-- master
Then you can rebase again to get this:
--o--o--o--o--X--Y <-- origin
\
A"--B"--C"--D' <-- master
at which time you don't see the old conflicts again.
-- Hannes
^ permalink raw reply
* Re: out of memory problem
From: Andreas Ericsson @ 2008-09-23 7:50 UTC (permalink / raw)
To: guo tang; +Cc: Git mailing list
In-Reply-To: <4120f6ec0809220828i3b38eda3tfc4974df8a2568cb@mail.gmail.com>
guo tang wrote:
> On Mon, Sep 22, 2008 at 12:32 AM, Andreas Ericsson <ae@op5.se> wrote:
>
>> Guo Tang wrote:
>>
>>> Gentlemen,
>>>
>>> I try to run "git gc" on linux kernel tree. The virtual memory keeps going
>>> up until over 3GB, then crash. Tried twice with the v1.6.0.2, same result.
>>> Then I used the git coming with FC9 (v1.5.5.1), the peak virutal memory
>>> usage is about 1.5GB. "git gc" finished without any trouble.
>>> Could there be a memory leak in v1.6.0.2?
>>>
>>>
>> There could be, but most likely it's commit
>> 38bd64979a2a3ffa178af801c6a62e6fcd658274 (Enable threaded delta
>> search on BSD and Linux). Do you have multiple cpu's in the
>> computer where 'git gc' was running? If so, and if you've set
>> pack.threads = 0, or --threads=0 it will autodetect the number
>> of CPU's you have and then saturate all of them with work. Each
>> thread will however consume memory close to that of a single
>> process running the repack, so for large repositories you might
>> want to set pack.threads = 1 in such large repositories.
>
>
> It is a Pentium M single core machine. But I am not sure whether it is using
> just a single thread or
> multiple threads. I will try setting pack.threads parameter next I run into
> trouble.
>
Unless you explicitly told it to run multiple threads (which
would be a bit silly on a single-core machine), it just ran
one thread.
>> It's a shame you didn't save the unpacked repository, or this could
>> have been properly debugged. While it's possible there is a memory
>> leak, it's a dismal project trying to locate it by staring at the
>> code, and the time it takes to repack huge repositories with memory
>> intensive parameters is sort of prohibitive for finding the possible
>> leak by bisection.
>
>
> Yes, the repository is already packed now. One question, beside the
> bisecting method, do we have
> this ability built into kernel:
> 1. Turn a flag on for a process.
> 2. OS will keep track off process malloc(), free() calls and the call stack.
>
> 3. For the malloc() calls without the the free() call (a memory leak), OS
> will keep it count based on malloc() call stack.
> 4. After some time, be able to dump this information out based on biggest
> leak spot.
>
No, there's not. The kernel isn't the one handing out the memory when you
call malloc(). That's handled by the C library, which can (and usually does)
allocate a larger area of memory than the application needs, so that it
doesn't have to run a system call for every malloc() call you do.
You can pre-load a different memory allocator though, which can do whatever
it wants with calls to malloc(), including ofcourse logging which function
called them and how much memory was requested.
Google for "memory leak check linux" and you'll get something like 750000
results.
> The complain when I ran out of memory if from mmap failure. Is it the same
> as malloc() failure?
>
Sort of. Read 'man 2 mmap' for a more exhaustive description.
> This kind of tool is available in Windows with its umdh (user mode heap
> dump) tool.
>
There are a number of tools to detect leaks under Linux/Unix as well.
valgrind is probably the most frequently used of all such leak checkers.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: rebasing merges
From: Stephen Haberman @ 2008-09-23 7:46 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <48D88813.9060400@viscovery.net>
> This is the expected behavior and not up for debate.
Cool, thanks for the reply. However, I debate... :-)
> ---o--o--o--o--o--o <-- origin
> \
> A'--B' <-- master
Nice. That makes sense in your scenario.
Here is mine:
---A--B--C--D <-- origin/stable
\ |
E--F | <-- origin/topica
\ |
g--h <-- topica
All the upper case commits have been published to origin. Other
devs, etc., know about them, their hashes are in the bug tracking
system.
I'm bringing topica up to date, but with a merge because I have
published history already on topica, so I merge stable and get a
new merge commit: g. And maybe make another change: h.
Everything's cool...now, with surprising frequency, someone beats
me to moving origin/topica:
---A--B--C--D <-- origin/stable
\ |
E--F---|--I <-- origin/topica
\ |
g--h <-- topica
Pushing h gets rejected as a rewind. Good. I want to pull, which
we had previously always used "--rebase" for, and the desired output
of a pull --rebase, to me, would be:
---A--B--C--D <-- origin/stable
\ \
E--F--I | <-- origin/topica
\|
g'--h' <-- topica
Instead, I get:
---A--B--C--D <-- origin/stable
\
E--F--I <-- origin/topica
\
B'-C'-D'-h'<-- topica
So, yes, linearized history with no merges. However, this leads
to quizzical looks when B'/C'/D' hit the email list, bug tracker, etc.
as new commits.
Currently I just try to pull/merge/push in quick succession, but
it's a manual collaboration hack ("okay, I'm merging now, no
committing...") that would be nice to not have to worry about.
I need to investigate the interactive rebase more, but my hesitant
assertion is that it's parent rewriting seems smart enough to handle
this. Perhaps not, and I admit our desired DAG output may not be
attainable without manual intervention.
I apologize--I should have included the example DAGs in my first
post, but since I didn't I felt the need to clarify. So, humoring
me, is the B'/C'/D' from this example really the expected behavior?
I can work on a new test in t3400/etc. if that is of interest.
Thanks for your time,
Stephen
^ permalink raw reply
* Re: rebasing merges
From: Samuel Tardieu @ 2008-09-23 7:30 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Stephen Haberman, git
In-Reply-To: <48D88813.9060400@viscovery.net>
>>>>> "Johannes" == Johannes Sixt <j.sixt@viscovery.net> writes:
Johannes> i.e. linearized history without merges.
A few days ago, I had a question in my team quite similar to Stephen
concern. A developer had performed a merge of a complex feature and
was ready to commit it
--o--o--o--o--X <-- origin
\ \
A--B--C--D--E <-- master
when he realized that someone just pushed another change on origin
while he was doing the complicating merge (with lots of conflicts to
resolve). The configuration was then:
--o--o--o--o--X--Y <-- origin
\ \
A--B--C--D--E <-- master
He would have wanted to have the merge rebased on E and Y instead of E
and X before pushing, without going through all the conflicts
resolution again (he didn't have "rerere" enabled).
Is that possible with "git rebase"?
Btw, would it be a good idea to unconditionally enable "rerere"
conflict resolution *recording*, and add an option to "rebase" and
"merge" to use "rerere" even when it is not enabled in the
configuration file? I can't think of any drawback.
Sam
--
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/
^ permalink raw reply
* Re: Locking binary files
From: Andreas Ericsson @ 2008-09-23 7:18 UTC (permalink / raw)
To: Mario Pareja; +Cc: git
In-Reply-To: <94c1db200809222339t7d65081eq7471fef86fb5ec73@mail.gmail.com>
Mario Pareja wrote:
> Hi,
>
> For one and a half years, I have been keeping my eyes on the git
> community in hopes of making the switch away from SVN. One particular
> issue holding me back is the inability to lock binary files.
> Throughout the past year, I have yet to see developments on this
> issue. I understand that locking files goes against the fundamental
> principles of distributed source control, but I think we need to come
> up with some workarounds. For Linux kernel development this is may
> not be an issue; however, for application development this is a major
> issue. How else can one developer be sure that time spent editing a
> binary file will not be wasted because another developer submitted a
> change?
>
Because they will cause merge conflicts when you try to bring the
histories together. Some binary formats can be edited by multiple
users at the same time, while others can't, so git will try to merge
those binary files for you. For images, that almost certainly won't
go so well so it will result in a conflict.
> To achieve the effects of locking, a "central" repository must be
> identified.
To achieve distributedness no central repository must exist. Locking
can be done by some other means.
> Regardless of the distributed nature of git, most
> _companies_ will have a "central" repository for a software project.
Actually, all projects with some sort of userbase will probably have
some official "here's the published code suitable for production use"
repository. To say that it's the "central" one is a bit off though.
It's merely a public place that can be referred to for convenience.
> We should be able to mark a file as requiring a lock from the
> governing git repository at a specified address. Is this made
> difficult because git tracks file contents not files?
>
> In any case, I think this is a crucial issue that needs to be
> addressed if git is going to be adopted by companies with binary file
> conflict potential. I don't see how a web development company can take
> advantage of git to track source code and image file changes. Any
> advice would be great!
>
Try and find out.
mkdir foo && cd foo && git init
cp /random/binary/file.png image.png
git add image.png && git commit -m"first commit"
git checkout -b A
cp /other/random/binary/file.png image.png
git add image.png && git commit -m"conflicting commit"
git checkout -b B master
cp /third/random/binary/file.png image.png
git add image.png && git commit -m"non-conflicting commit"
git checkout master
cp /third/random/binary/file.png image.png
git add image.png && git commit -m"master says 'so be it'"
git merge B; # works, since the binary files are the same
git merge A; # produces a conflict message
In which way is that not exactly the right behaviour?
How would locking have helped?
If your colleagues are replacing files you committed so
that your code suddenly fails, you have a communication
(and QA) issue at work. Adding locking to git is not the
solution to that problem. Introducing a sort of builtin
notion of a central repository is, frankly, disgusting.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH] compat/mingw: Support a timeout in the poll emulation if no fds are given
From: Johannes Sixt @ 2008-09-23 6:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, msysGit
From: Johannes Sixt <johannes.sixt@telecom.at>
Our poll() emulation did not support the timeout argument. With this patch
we support it for the simple case where poll() does not need to wait on
file descriptors as well because this case amounts to a mere Sleep().
This is needed if the user sets help.autocorrect is set to a positive
value.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
compat/mingw.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index ccfa2a0..7eed60d 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -263,8 +263,13 @@ int poll(struct pollfd *ufds, unsigned int nfds, int timeout)
{
int i, pending;
- if (timeout != -1)
+ if (timeout >= 0) {
+ if (nfds == 0) {
+ Sleep(timeout);
+ return 0;
+ }
return errno = EINVAL, error("poll timeout not supported");
+ }
/* When there is only one fd to wait for, then we pretend that
* input is available and let the actual wait happen when the
--
1.6.0.2.1220.gd1ae.dirty
^ permalink raw reply related
* Re: TopGit: how to deal with upstream inclusion
From: martin f krafft @ 2008-09-23 6:35 UTC (permalink / raw)
To: Petr Baudis, git
In-Reply-To: <20080921141924.GI10360@machine.or.cz>
[-- Attachment #1: Type: text/plain, Size: 895 bytes --]
also sprach Petr Baudis <pasky@suse.cz> [2008.09.21.1619 +0200]:
> > Yes, it does. One might want to consider to make the use of -s ours
> > in (iiii) configurable, but otherwise that's it.
>
> That might be pretty dangerous, since then your topic branch will have
> outstanding branches of the retired branch, but they will _NOT_ be
> visible to tg patch and others since they will be in both the base and
> head.
Well, but what if upstream implemented our solution slightly
differently, and if it's only because they used tabs instead of
spaces? We wouldn't want -s ours then, huh?
--
martin | http://madduck.net/ | http://two.sentenc.es/
"on the other hand, with the advent of msvc 5, i can claim i use
emacs because it's smaller and more efficient." :-)"
-- darin johnson
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Locking binary files
From: Mario Pareja @ 2008-09-23 6:39 UTC (permalink / raw)
To: git
In-Reply-To: <94c1db200809222333q4953a6b9g8ce0c1cd4b8f5eb4@mail.gmail.com>
Hi,
For one and a half years, I have been keeping my eyes on the git
community in hopes of making the switch away from SVN. One particular
issue holding me back is the inability to lock binary files.
Throughout the past year, I have yet to see developments on this
issue. I understand that locking files goes against the fundamental
principles of distributed source control, but I think we need to come
up with some workarounds. For Linux kernel development this is may
not be an issue; however, for application development this is a major
issue. How else can one developer be sure that time spent editing a
binary file will not be wasted because another developer submitted a
change?
To achieve the effects of locking, a "central" repository must be
identified. Regardless of the distributed nature of git, most
_companies_ will have a "central" repository for a software project.
We should be able to mark a file as requiring a lock from the
governing git repository at a specified address. Is this made
difficult because git tracks file contents not files?
In any case, I think this is a crucial issue that needs to be
addressed if git is going to be adopted by companies with binary file
conflict potential. I don't see how a web development company can take
advantage of git to track source code and image file changes. Any
advice would be great!
Regards,
Mario
^ permalink raw reply
* [ANNOUNCE] Git-1.6.0.2-preview20080923
From: Steffen Prohaska @ 2008-09-23 6:09 UTC (permalink / raw)
To: msysGit, Git Mailing List
In-Reply-To: <691F01A6-CA78-46DA-8388-C8339A3F0F04@zib.de>
On Sep 21, 2008, at 7:33 PM, Steffen Prohaska wrote:
> Git-1.6.0.2-preview20080921 for Windows is available at
>
> http://code.google.com/p/msysgit/downloads
I updated the installer to Git-1.6.0.2-preview20080923.
The problems reported on the mailing list during the
last two days should be fixed.
I apologize for the quality of Git-1.6.0.2-preview20080921.
It was unacceptable.
Steffen
^ permalink raw reply
* Re: rebasing merges
From: Johannes Sixt @ 2008-09-23 6:09 UTC (permalink / raw)
To: Stephen Haberman; +Cc: git
In-Reply-To: <20080922231927.ef18f420.stephen@exigencecorp.com>
Stephen Haberman schrieb:
> I noticed the t3400.sh test explicitly tests for the flattening
> behavior, but I can't tell if that is because it's testing for
> explicitly desired behavior or if the "linear-izing" is something
> that is up for debate (or a command line/config option).
This is the expected behavior and not up for debate.
Consider this use-case, for example: You keep a private patch or two on
top of upstream, and you also regularly pull from upstream. You get this
history:
---o--o--o--o--o--o <-- origin
\ \ \
A--B--M--------N <-- master
A and B are the private patches. From time to time you want to update them
if they get out of date, which is indicated by merge conflicts in the
merges M and N. Then you want this result:
---o--o--o--o--o--o <-- origin
\
A'--B' <-- master
i.e. linearized history without merges.
-- Hannes
^ permalink raw reply
* Re: [PATCH] builtin-prune.c: prune temporary packs in <object_dir>/pack directory
From: David Tweed @ 2008-09-23 5:37 UTC (permalink / raw)
To: Brandon Casey; +Cc: Petr Baudis, Git Mailing List, Junio C Hamano
In-Reply-To: <KKSursEoVthEbqc_O82_QIafgU9zgb4bQYP7w6x9ulU85L2Nixe_9g@cipher.nrlssc.navy.mil>
On Tue, Sep 23, 2008 at 12:34 AM, Brandon Casey <casey@nrlssc.navy.mil> wrote:
> Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
> ---
>
> Re: [PATCH] Do not perform cross-directory renames when creating packs
>
> I think something like this should be applied on top.
>
> -brandon
>
>
> builtin-prune.c | 18 ++++++++++--------
> 1 files changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/builtin-prune.c b/builtin-prune.c
> index c767a0a..fc8be45 100644
> --- a/builtin-prune.c
> +++ b/builtin-prune.c
> @@ -13,7 +13,7 @@ static const char * const prune_usage[] = {
> static int show_only;
> static unsigned long expire;
>
> -static int prune_tmp_object(char *path, const char *filename)
> +static int prune_tmp_object(const char *path, const char *filename)
> {
> const char *fullpath = mkpath("%s/%s", path, filename);
> if (expire) {
> @@ -113,21 +113,19 @@ static void prune_object_dir(const char *path)
> * files begining with "tmp_") accumulating in the
> * object directory.
> */
Good spotting. I haven't been remotely involved with git recently but
for what little it's worth looks the right thing to me. It'd be nice
to modify the patch to keep the comment up to date, something like:
* accumulating in the
* object directory (older git versions) or pack directory.
*/
--
cheers, dave tweed__________________________
david.tweed@gmail.com
Rm 124, School of Systems Engineering, University of Reading.
"while having code so boring anyone can maintain it, use Python." --
attempted insult seen on slashdot
^ permalink raw reply
* Re: [CORRECTION] Git-1.6.0.2-preview20080921 on Windows
From: Peter Krefting @ 2008-09-23 5:08 UTC (permalink / raw)
To: Frederik Hohlfeld; +Cc: git
In-Reply-To: <loom.20080922T101605-640@post.gmane.org>
Frederik Hohlfeld:
> Do I understand it right, that this is also without working git-svn (or
> maybe even without git-svn at all)?
Yes, like the previous releases, git-svn is not included in the build. There
is an older release availabe which has a git-svn in it, but it says that it
doesn't quite work right. I guess it needs a volunteer to look at it and
figure out how to fix it...
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: rebasing merges
From: Stephen Haberman @ 2008-09-23 4:19 UTC (permalink / raw)
To: git
In-Reply-To: <20080922155749.c8070681.stephen@exigencecorp.com>
> [1] seems to solve this with some fairly complex cherry-picking and
> ancestry manipulation that, admittedly, I don't quite understand, but
> it seems like it might be able to bring along a merge's multiple
> parents information throughout the rebase and maintain the merge as a
> single, non-flattened merge commit.
Hm. Sorry for the noise about that Mercurial link--mostly talking to
myself now, but I've discovered `git rebase -i -p` does exactly what I
want (I think).
Is there a reason the "preserve merge" option in the
git-rebase--interactive isn't also in the non-interactive git-rebase
that is invoked by a git pull --rebase?
I noticed the t3400.sh test explicitly tests for the flattening
behavior, but I can't tell if that is because it's testing for
explicitly desired behavior or if the "linear-izing" is something
that is up for debate (or a command line/config option).
Would it be foolish for me to work on something like this? I can
probably hold my own at copy/pasting around in the shell scripts.
Thanks,
Stephen
^ permalink raw reply
* Re: [PATCH] diff funcname_pattern: Allow HTML header tags without attributes
From: Johan Herland @ 2008-09-23 2:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Brandon Casey
In-Reply-To: <7v7i93ws64.fsf@gitster.siamese.dyndns.org>
On Tuesday 23 September 2008, Junio C Hamano wrote:
> Johan Herland <johan@herland.net> writes:
> > After looking over this once more, I think the HTML regexp should be
> > changed as follows. This fixes a buglet that was part of my original
> > HTML pattern, and although this patch textually depends on Brandon's
> > work, it is conceptually independent of his refactorization.
> > ...
> > - { "html", "^[ \t]*(<[Hh][1-6][ \t].*>.*)$", REG_EXTENDED },
> > + { "html", "^[ \t]*(<[Hh][1-6]([ \t].*)?>.*)$", REG_EXTENDED },
>
> I do not think these two particularly would make much difference. Why
> isn't it simply...
>
> "<[Hh][1-6].*"
>
> without even any capture or anchor?
>
> It would falsely hit oddball cases like <h1foo> which is not <h1>, but
> anybody who uses such a nonstandard thing deserves it, imnvho ;-).
Ok. I agree. Go ahead.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH] diff funcname_pattern: Allow HTML header tags without attributes
From: Junio C Hamano @ 2008-09-23 1:46 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Brandon Casey
In-Reply-To: <200809230249.23298.johan@herland.net>
Johan Herland <johan@herland.net> writes:
> After looking over this once more, I think the HTML regexp should be
> changed as follows. This fixes a buglet that was part of my original
> HTML pattern, and although this patch textually depends on Brandon's
> work, it is conceptually independent of his refactorization.
> ...
> - { "html", "^[ \t]*(<[Hh][1-6][ \t].*>.*)$", REG_EXTENDED },
> + { "html", "^[ \t]*(<[Hh][1-6]([ \t].*)?>.*)$", REG_EXTENDED },
I do not think these two particularly would make much difference. Why
isn't it simply...
"<[Hh][1-6].*"
without even any capture or anchor?
It would falsely hit oddball cases like <h1foo> which is not <h1>, but
anybody who uses such a nonstandard thing deserves it, imnvho ;-).
^ 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