* Re: Commited to wrong branch
From: Martin Langhoff @ 2009-09-15 13:46 UTC (permalink / raw)
To: Howard Miller; +Cc: git
In-Reply-To: <26ae428a0909150627n4e5935bcxdcdf0fdd33a44aa8@mail.gmail.com>
On Tue, Sep 15, 2009 at 3:27 PM, Howard Miller
<howard@e-learndesign.co.uk> wrote:
> What's to stop me.........
>
> * The "wrong" branch just tracks a remote so I can just dump it once I
> have this fixed - (delete it and recreate it?)
Absolutely perfect plan. In fact, there's a way to "sync" your local
branch to the remote one:
git checkout X
git reset origin/X
(assuming that the remote branch is 'origin/X')
> * after my 'reset' the files I have in my working copy (still the
> wrong branch) should be the latest version ('git reset' does not
> change the working copy I think?)
correct (git reset --hard OTOH will discard your changes)
> * So can I grab these files (they are mostly new), checkout the
> correct version, and just overwrite the existing files? I'll loose
> some history but not much and I don't care
Oh... well if there were other changes to the same files in the other
branch you could be carrying "other" changes. git diff to make sure
you're committing what you want.
> Seems too easy :-)
It is :-)
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: Commited to wrong branch
From: Martin Langhoff @ 2009-09-15 13:54 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Howard Miller, git
In-Reply-To: <20090915130640.GC31846@atjola.homenet>
2009/9/15 Björn Steinbrink <B.Steinbrink@gmx.de>:
> [Please stop top-posting...]
Not everyone is deep in mailing-list lore :-) -- we can help anyway.
Howard, I see you're wondering about it: http://www.idallen.com/topposting.html
> Just don't use patch(1), there's no sane reason to do that, you're
> sacrificing all of what git can offer there.
Oh, yes there is, specially for newcomers used to patch, and how it
handles conflicts.
In this case, I happen to know that Howard is a refugee from CVS land
(the moodle project in this case), and he is familiar with the output
of patch if things go wrong.
It's not what I'd recommend to someone that is deep in git-land. But
even myself (with a bit of code in git) sometimes use patch when
git-apply tries to be too clever and I just want a damn .rej file to
review and edit with emacs.
cheers,
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: [PATCH] gitk: restore wm state to normal before saving geometry information
From: Alexey Borzenkov @ 2009-09-15 13:58 UTC (permalink / raw)
To: Pat Thoyts; +Cc: git
In-Reply-To: <e2480c70909150554p2e211d60y18049b5534f8922e@mail.gmail.com>
On Tue, Sep 15, 2009 at 4:54 PM, Alexey Borzenkov <snaury@gmail.com> wrote:
> On the other hand, when I resize columns and then maximize/restore the
> window repeatedly I see that their sizes change in a strange way (and
> the smaller restored window they stranger are results) until hitting
> some sort of equilibrium, then maximize/restore doesn't have effect on
> their sizes anymore. So maybe there's a bug not in a way my patch
> restores the window, but in a way window resizes are handled.
It seems that I found what's the problem. When the window is very
small, and we maximize it, sash coords would initially be small. Then
we calculate their new positions and set it with $win sash place, but
unfortunately, tk limits them to the OLD pane size for some reason.
Initially I though that maybe Configure is fired too early (before
window is resized), but [winfo width $win] shows $win has the new
size. Here's some output that I got during debugging:
resizing 422 -> 1261 (winfo shows 1261)
s0: 138 1
s1: 288 1
sash0: 412 -> 412 1
sash1: 860 -> 417 1
I'm at a loss why this happens and how to lift this restriction.
^ permalink raw reply
* Re: Commited to wrong branch
From: Johannes Sixt @ 2009-09-15 14:08 UTC (permalink / raw)
To: Howard Miller; +Cc: Martin Langhoff, git
In-Reply-To: <26ae428a0909150645s59e1fb40hbb19e672230077eb@mail.gmail.com>
Howard Miller schrieb:
> (PS. I now even know what 'top-posting' is - but not why it's bad.)
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
^ permalink raw reply
* Re: [PATCH 2/2] Fix the geometry when restoring from zoomed state.
From: Alexey Borzenkov @ 2009-09-15 14:11 UTC (permalink / raw)
To: Pat Thoyts; +Cc: git, Paul Mackerras
In-Reply-To: <8763bkcsxb.fsf@users.sourceforge.net>
On Tue, Sep 15, 2009 at 1:37 PM, Pat Thoyts
<patthoyts@users.sourceforge.net> wrote:
> The patch to handle the geometry of a restored gitk by Alexy Borzenkov
> causes the position of the columns to creep each time the application
> is restarted. This patch addresses this by remembering the application
> geometry for the normal state and saving that regardless of the actual
> state when the application is closed.
I can confirm it works even when the difference between normal and
maximized window are big.
^ permalink raw reply
* Re: Commited to wrong branch
From: Howard Miller @ 2009-09-15 14:11 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Björn Steinbrink, git
In-Reply-To: <46a038f90909150654t73cab47ckfd02f8a2f4353722@mail.gmail.com>
2009/9/15 Martin Langhoff <martin.langhoff@gmail.com>:
> 2009/9/15 Björn Steinbrink <B.Steinbrink@gmx.de>:
>> [Please stop top-posting...]
>
> Not everyone is deep in mailing-list lore :-) -- we can help anyway.
>
> Howard, I see you're wondering about it: http://www.idallen.com/topposting.html
>
>> Just don't use patch(1), there's no sane reason to do that, you're
>> sacrificing all of what git can offer there.
>
> Oh, yes there is, specially for newcomers used to patch, and how it
> handles conflicts.
>
> In this case, I happen to know that Howard is a refugee from CVS land
> (the moodle project in this case), and he is familiar with the output
> of patch if things go wrong.
>
> It's not what I'd recommend to someone that is deep in git-land. But
> even myself (with a bit of code in git) sometimes use patch when
> git-apply tries to be too clever and I just want a damn .rej file to
> review and edit with emacs.
>
> cheers,
>
>
> m
> --
> martin.langhoff@gmail.com
> martin@laptop.org -- School Server Architect
> - ask interesting questions
> - don't get distracted with shiny stuff - working code first
> - http://wiki.laptop.org/go/User:Martinlanghoff
>
...and I still don't understand cvs either :-)
(NB. I have put my reply at the bottom where nobody will see it - this
is why forums are better than mailing lists.... >ducks<)
^ permalink raw reply
* Re: [PATCH 1/2] Work around leftover temporary save file.
From: Alexey Borzenkov @ 2009-09-15 14:14 UTC (permalink / raw)
To: Alex Riesen; +Cc: Pat Thoyts, git, Paul Mackerras
In-Reply-To: <81b0412b0909150601j74d40181pc2308f4f63b4817e@mail.gmail.com>
On Tue, Sep 15, 2009 at 5:01 PM, Alex Riesen <raa.lkml@gmail.com> wrote:
> On Tue, Sep 15, 2009 at 11:26, Pat Thoyts
> <patthoyts@users.sourceforge.net> wrote:
>>
>> If a file exists and is hidden on Windows the Tcl open command will
>> fail as the attributes provided in the CREAT call fail to match those
>> of the existing file. Forcing removal of the temporary file before we
>> begin solves any problems caused by previous failures to save the
>> application settings. An alternative would be to remove the hidden
>> attribute before calling 'open'.
>>
>> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
>> ---
>> gitk | 1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/gitk b/gitk
>> index 1306178..a0214b7 100755
>> --- a/gitk
>> +++ b/gitk
>> @@ -2526,6 +2526,7 @@ proc savestuff {w} {
>> if {$stuffsaved} return
>> if {![winfo viewable .]} return
>> catch {
>> + if {[file exists ~/.gitk-new]} {file delete -force ~/.gitk-new}
>
> maybe another gitk instance is writing it at exactly same moment
> in time? Writing is known to take a few moments. Especially on Windows.
Then deleting would fail, because on Windows opened files cannot be
deleted (unless they are opened in a special way that permits it).
^ permalink raw reply
* Re: [PATCH 1/2] Work around leftover temporary save file.
From: Pat Thoyts @ 2009-09-15 14:47 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Alexy Borzenkov, Paul Mackerras
In-Reply-To: <81b0412b0909150601j74d40181pc2308f4f63b4817e@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> writes:
>On Tue, Sep 15, 2009 at 11:26, Pat Thoyts
><patthoyts@users.sourceforge.net> wrote:
>>
>> If a file exists and is hidden on Windows the Tcl open command will
>> fail as the attributes provided in the CREAT call fail to match those
>> of the existing file. Forcing removal of the temporary file before we
>> begin solves any problems caused by previous failures to save the
>> application settings. An alternative would be to remove the hidden
>> attribute before calling 'open'.
>>
>> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
>> ---
>> gitk | 1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/gitk b/gitk
>> index 1306178..a0214b7 100755
>> --- a/gitk
>> +++ b/gitk
>> @@ -2526,6 +2526,7 @@ proc savestuff {w} {
>> if {$stuffsaved} return
>> if {![winfo viewable .]} return
>> catch {
>> + if {[file exists ~/.gitk-new]} {file delete -force ~/.gitk-new}
>
>maybe another gitk instance is writing it at exactly same moment
>in time? Writing is known to take a few moments. Especially on Windows.
no - 'open $file w' is translated into O_WRONLY|O_CREAT|O_TRUNC
internally and passed to the win32 layer to get converted to a call to CreateFile with
GENERIC_WRITE, CREATE_ALWAYS and FILE_ATTRIBUTE_NORMAL. The file has
got FILE_ATTRIBUTE_HIDDEN though and as it exists and our attributes
do not match we get failed.
'open $file {O_WRONLY O_TRUNC}' would open it but we'd have to check
for non-existence and redo with O_CREAT if it was not already present.
See tclWinChan.c:TclpOpenFileChannel.
--
Pat Thoyts http://www.patthoyts.tk/
PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD
^ permalink raw reply
* git stash list shows timestamp in stead of "stash number", when setting date = local for log in config
From: Alf Kristian Støyle @ 2009-09-15 14:56 UTC (permalink / raw)
To: git
Hi. Searched the lists, but haven't found anyone reporting this problem.
When doing a "git stash list" I get this strange stash record:
stash@{Tue Sep 15 16:28:12 2009}: WIP on master: 2262276 ...
I have a global config setting on log:
[log]
date = local
If setting the date config to default or removing the setting, the
stash record looks correct:
stash@{0}: WIP on master: 2262276 ...
I might be missing something here, but I do find this a bit strange.
Is this a bug or a feature, and is there a setting I can use (for
stash) to always show the latter line? I kind of like having local
timestamps in log.
I am using git version 1.6.4.2 on the Mac.
Thanks
- Alf
^ permalink raw reply
* Per-remote tracking branch
From: Matthieu Moy @ 2009-09-15 15:29 UTC (permalink / raw)
To: git
Hi,
Is there a way, with Git, to specify a tracking branch on a per-remote
basis?
At the moment, I can configure a tracking branch to let me just type
$ git pull
when I want to say
$ git pull origin master
Now, assume I have another remote "foo", I'd like to be able to just
say
$ git pull foo
and put something in my .git/config so that Git knows I mean
$ git pull foo master
Is there a simple way to do that?
(for the motivation: I mostly use Git with a 1-branch-per-repo setup,
so in 99% of my use-cases, when I have to specify a branch, it's
master).
Thanks,
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH JGit 04/19] added utility that generates the contents of the objects/info/packs file as a string from a list of PackFiles
From: Robin Rosenberg @ 2009-09-15 15:35 UTC (permalink / raw)
To: mr.gaffo; +Cc: git, mike.gaffney
In-Reply-To: <1252867475-858-5-git-send-email-mr.gaffo@gmail.com>
> diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/PacksFileContentsCreator.java b/org.spearce.jgit/src/org/spearce/jgit/lib/PacksFileContentsCreator.java
> new file mode 100644
> index 0000000..3dd0418
> --- /dev/null
> +++ b/org.spearce.jgit/src/org/spearce/jgit/lib/PacksFileContentsCreator.java
> @@ -0,0 +1,21 @@
> +package org.spearce.jgit.lib;
> +
> +import java.util.List;
> +
> +public class PacksFileContentsCreator {
> +
> + private List<PackFile> packs;
> +
> + public PacksFileContentsCreator(List<PackFile> packs) {
We want good javadocs for (at least) all public and protected methods and
classes. (We enforce this for Eclipse users). If we had similar configuration files
for, perhaps netbeans we might have those too. (not finished thinking about that
proposition...)
> + this.packs = packs;
> + }
> +
> + public String toString(){
Don't overload toString. Let it be useful for debug like purposes. With this style we cannot
make it useful since the application depends on its exact behaviour. You may define
a toString anyway that does the exact same thing, but please provide a specific method for
assisting with the formatting of the file. A writeTo(OutputStream) is a useful interface in general.
> + StringBuilder builder = new StringBuilder();
> + for (PackFile packFile : packs) {
> + builder.append("P ").append(packFile.getPackFile().getName()).append('\r');
At least my git formats the file with \n as line terminator, so I think JGit should too..
Git ends the file with an extra \n, though I'm not sure it's relevant.
> + }
> + return builder.toString();
> + }
The name is somewhat confusing as the s is hard to spot. The suggestion InfoPacksFileGenerator
perhaps. It's a bit uglier by easier not to mix with generation of pack files.
-- robin
^ permalink raw reply
* Re: [PATCH JGit 01/19] adding tests for ObjectDirectory
From: Robin Rosenberg @ 2009-09-15 15:38 UTC (permalink / raw)
To: mr.gaffo; +Cc: git, mike.gaffney
In-Reply-To: <1252867475-858-2-git-send-email-mr.gaffo@gmail.com>
söndag 13 september 2009 20:44:17 skrev mr.gaffo@gmail.com:
> From: mike.gaffney <mike.gaffney@asolutions.com>
>
> ---
> .../org/spearce/jgit/lib/ObjectDirectoryTest.java | 80 ++++++++++++++++++++
> 1 files changed, 80 insertions(+), 0 deletions(-)
> create mode 100644 org.spearce.jgit.test/tst/org/spearce/jgit/lib/ObjectDirectoryTest.java
>
> diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/ObjectDirectoryTest.java b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/ObjectDirectoryTest.java
> new file mode 100644
> index 0000000..fe019af
> --- /dev/null
> +++ b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/ObjectDirectoryTest.java
> @@ -0,0 +1,80 @@
> +package org.spearce.jgit.lib;
> +
> +import java.io.File;
> +import java.util.UUID;
> +
> +import junit.framework.TestCase;
> +
> +public class ObjectDirectoryTest extends TestCase {
> +
> + private File testDir;
> +
> + @Override
> + protected void setUp() throws Exception {
> + testDir = new File(new File(System.getProperty("java.io.tmpdir")), UUID.randomUUID().toString());
> + }
Good. Now that we're on Java5 we might use this more.
> + public void testGettingObjectFile() throws Exception {
> + ObjectDirectory od = new ObjectDirectory(testDir);
> + assertEquals(new File(testDir, "02/829ae153935095e4223f30cfc98c835de71bee"),
> + od.fileFor(ObjectId.fromString("02829ae153935095e4223f30cfc98c835de71bee")));
> + assertEquals(new File(testDir, "b0/52a1272310d8df34de72f60204dee7e28a43d0"),
> + od.fileFor(ObjectId.fromString("b052a1272310d8df34de72f60204dee7e28a43d0")));
> + }
> +
> + public boolean deleteDir(File dir) {
RepositoryTestcase already contains a recursive delete, including a static one
that you can use even without inheritance since you are within the same package. It is rather
standalone so it could perhaps move to JGitTestUtil.
> + if (dir.isDirectory()) {
> + String[] children = dir.list();
> + for (int i=0; i<children.length; i++) {
> + boolean success = deleteDir(new File(dir, children[i]));
> + if (!success) {
> + return false;
> + }
> + }
> + }
> +
> + // The directory is now empty so delete it
> + return dir.delete();
> + }
> +
> + private void createTestDir(){
> + testDir.mkdir();
No error checking. If mkdirfails the test probably fails for mysterious reasons,
> + }
> +
> +}
^ permalink raw reply
* Re: [PATCH 1/2] Work around leftover temporary save file.
From: Pat Thoyts @ 2009-09-15 15:44 UTC (permalink / raw)
To: Alexey Borzenkov; +Cc: Alex Riesen, git, Paul Mackerras
In-Reply-To: <e2480c70909150714n3b7d6018rcb5bcb42d1d78218@mail.gmail.com>
Alexey Borzenkov <snaury@gmail.com> writes:
>
>Then deleting would fail, because on Windows opened files cannot be
>deleted (unless they are opened in a special way that permits it).
>
The delete occurs before we attempt to open the file which is why it
succeeds when such file is present.
--
Pat Thoyts http://www.patthoyts.tk/
PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD
^ permalink raw reply
* Re: [PATCH JGit 05/19] Made tests for listLocalPacks function on ObjectDirectory and made them pass
From: Robin Rosenberg @ 2009-09-15 16:13 UTC (permalink / raw)
To: mr.gaffo; +Cc: git, mike.gaffney
In-Reply-To: <1252867475-858-6-git-send-email-mr.gaffo@gmail.com>
söndag 13 september 2009 20:44:21 skrev mr.gaffo@gmail.com:
> From: mike.gaffney <mike.gaffney@asolutions.com>
>
> ---
> .../org/spearce/jgit/lib/ObjectDirectoryTest.java | 24 ++++++++++++++++++++
> .../jgit/lib/UpdateDirectoryInfoCacheTest.java | 11 +++++++++
> .../tst/org/spearce/jgit/util/JGitTestUtil.java | 21 ++++++++++++++++-
> .../src/org/spearce/jgit/lib/ObjectDirectory.java | 6 +++++
> .../spearce/jgit/lib/UpdateDirectoryInfoCache.java | 22 ++++++++++++++++++
> 5 files changed, 83 insertions(+), 1 deletions(-)
> create mode 100644 org.spearce.jgit.test/tst/org/spearce/jgit/lib/UpdateDirectoryInfoCacheTest.java
> create mode 100644 org.spearce.jgit/src/org/spearce/jgit/lib/UpdateDirectoryInfoCache.java
>
> diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/ObjectDirectoryTest.java b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/ObjectDirectoryTest.java
> index fe019af..8e4d8e5 100644
> --- a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/ObjectDirectoryTest.java
> +++ b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/ObjectDirectoryTest.java
> @@ -1,11 +1,17 @@
> package org.spearce.jgit.lib;
>
> import java.io.File;
> +import java.util.List;
> import java.util.UUID;
>
> +import org.spearce.jgit.util.JGitTestUtil;
> +
> import junit.framework.TestCase;
>
> public class ObjectDirectoryTest extends TestCase {
> + private static final String PACK_NAME = "pack-34be9032ac282b11fa9babdc2b2a93ca996c9c2f";
> + private static final File TEST_PACK = JGitTestUtil.getTestResourceFile(PACK_NAME + ".pack");
> + private static final File TEST_IDX = JGitTestUtil.getTestResourceFile(PACK_NAME + ".idx");
>
> private File testDir;
>
> @@ -58,6 +64,24 @@ public void testGettingObjectFile() throws Exception {
> od.fileFor(ObjectId.fromString("b052a1272310d8df34de72f60204dee7e28a43d0")));
> }
>
> + public void testListLocalPacksNotCreated() throws Exception {
> + assertEquals(0, new ObjectDirectory(testDir).listLocalPacks().size());
> + }
> +
> + public void testListLocalPacksWhenThereIsAPack() throws Exception {
> + createTestDir();
> + File packsDir = new File(testDir, "pack");
> + packsDir.mkdirs();
> +
> + JGitTestUtil.copyFile(TEST_PACK, new File(packsDir, TEST_PACK.getName()));
> + JGitTestUtil.copyFile(TEST_IDX, new File(packsDir, TEST_IDX.getName()));
> +
> + ObjectDirectory od = new ObjectDirectory(testDir);
> + List<PackFile> localPacks = od.listLocalPacks();
> + assertEquals(1, localPacks.size());
> + assertEquals(TEST_PACK.getName(), localPacks.get(0).getPackFile().getName());
> + }
> +
> public boolean deleteDir(File dir) {
> if (dir.isDirectory()) {
> String[] children = dir.list();
> diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/UpdateDirectoryInfoCacheTest.java b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/UpdateDirectoryInfoCacheTest.java
> new file mode 100644
> index 0000000..11d183e
> --- /dev/null
> +++ b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/UpdateDirectoryInfoCacheTest.java
> @@ -0,0 +1,11 @@
> +package org.spearce.jgit.lib;
> +
> +import junit.framework.TestCase;
> +
> +public class UpdateDirectoryInfoCacheTest extends TestCase {
> +
> + public void testBase() throws Exception {
> + fail("nyi");
> + }
> +
> +}
> diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/util/JGitTestUtil.java b/org.spearce.jgit.test/tst/org/spearce/jgit/util/JGitTestUtil.java
> index eee0c14..04184d7 100644
> --- a/org.spearce.jgit.test/tst/org/spearce/jgit/util/JGitTestUtil.java
> +++ b/org.spearce.jgit.test/tst/org/spearce/jgit/util/JGitTestUtil.java
> @@ -38,6 +38,12 @@
> package org.spearce.jgit.util;
>
> import java.io.File;
> +import java.io.FileInputStream;
> +import java.io.FileNotFoundException;
> +import java.io.FileOutputStream;
> +import java.io.IOException;
> +import java.io.InputStream;
> +import java.io.OutputStream;
> import java.net.URISyntaxException;
> import java.net.URL;
>
> @@ -60,11 +66,24 @@ public static File getTestResourceFile(final String fileName) {
> }
> try {
> return new File(url.toURI());
> - } catch(URISyntaxException e) {
> + } catch (URISyntaxException e) {
> return new File(url.getPath());
> }
> }
>
> + public static void copyFile(final File fromFile, final File toFile) throws IOException {
> + InputStream in = new FileInputStream(fromFile);
> + OutputStream out = new FileOutputStream(toFile);
> +
> + byte[] buf = new byte[1024];
> + int len;
> + while ((len = in.read(buf)) > 0) {
> + out.write(buf, 0, len);
> + }
> + in.close();
> + out.close();
> + }
You need to check for short reads, i.e. read could retrieve
fewer bytes than requested, Less important, a larger buffer size could
perhaps be used too (like 8192 which is the default BufferedReader buffer size).
> private static ClassLoader cl() {
> return JGitTestUtil.class.getClassLoader();
> }
> diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/ObjectDirectory.java b/org.spearce.jgit/src/org/spearce/jgit/lib/ObjectDirectory.java
> index fe219c6..a90ae00 100644
> --- a/org.spearce.jgit/src/org/spearce/jgit/lib/ObjectDirectory.java
> +++ b/org.spearce.jgit/src/org/spearce/jgit/lib/ObjectDirectory.java
> @@ -511,6 +511,12 @@ boolean tryAgain(final long currLastModified) {
>
> @Override
> public List<PackFile> listLocalPacks() {
> + tryAgain1();
mmmm. probably good.
> + public void execute() {
> +// File objectFile = objectDatabase.
> +// String packsContents = new PacksFileContentsCreator(this.objectDatabase.listLocalPacks()).toString();
Out commented code is a no-no.
-- robin
^ permalink raw reply
* Pair Programming Workflow Suggestions
From: Tim Visher @ 2009-09-15 17:43 UTC (permalink / raw)
To: Git Mailing List
Hello Everyone,
I'm interested in hearing how people use Git for pair programming.
Specifically, how do you document that you are programming in pairs.
Typically, of course, you have a driver and a navigator. It seems
natural to have a commit's author be the driver at the time, but that
doesn't seem to do justice to what pair programming is. Really, both
people are normally coding, but one person is doing the typing and
most of the thinking while the other is acting as an in place code
reviewer. There are even cases where there's a third person involved.
I did find [Brian Helmkamp's
script](http://www.brynary.com/2008/9/1/setting-the-git-commit-author-to-pair-programmers-names)
but that's not really what I'm looking for. For instance, that would
break the nice integration we have with Hudson at this point for
displaying when a developer was last active. It would be nicer to
have an arbitrary number of authors that can all exist separately, but
I'm fairly certain that git does not support that.
Thoughts?
--
In Christ,
Timmy V.
http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail
^ permalink raw reply
* Re: Pair Programming Workflow Suggestions
From: Sean Estabrooks @ 2009-09-15 18:14 UTC (permalink / raw)
To: Tim Visher; +Cc: Git Mailing List
In-Reply-To: <c115fd3c0909151043v3216a147v35e18710fbead515@mail.gmail.com>
On Tue, 15 Sep 2009 13:43:17 -0400
Tim Visher <tim.visher@gmail.com> wrote:
[...]
> It would be nicer to
> have an arbitrary number of authors that can all exist separately, but
> I'm fairly certain that git does not support that.
Tim,
If you're just looking for a way to quickly switch the author information
quickly between individual commits. You could create a shell alias for
each of the programmers that does:
export GIT_AUTHOR_NAME="some name" GIT_AUTHOR_EMAIL="name@where.com"
This will override the global and per repo configured author information
for all subsequent commits.
HTH,
Sean
^ permalink raw reply
* Re: Pair Programming Workflow Suggestions
From: Jakub Narebski @ 2009-09-15 18:20 UTC (permalink / raw)
To: Tim Visher; +Cc: Git Mailing List
In-Reply-To: <c115fd3c0909151043v3216a147v35e18710fbead515@mail.gmail.com>
Tim Visher <tim.visher@gmail.com> writes:
> I'm interested in hearing how people use Git for pair programming.
> Specifically, how do you document that you are programming in pairs.
[...]
> I did find Brian Helmkamp's script
> http://www.brynary.com/2008/9/1/setting-the-git-commit-author-to-pair-programmers-names
> but that's not really what I'm looking for. [...]
I'm not sure if this would help you, but take a look at "Pair
Programming & git & github & Gravatar & You & You" blog post by Jon
"Lark" Larkowski from May 30, 2009:
http://blog.l4rk.com/2009/05/pair-programming-git-github-gravatar.html
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 04/14] Set _O_BINARY as default fmode for both MinGW and MSVC
From: Alexey Borzenkov @ 2009-09-15 18:40 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: Johannes.Schindelin, msysgit, git, lznuaa, raa.lkml
In-Reply-To: <badc5d24387c28c752a45f75e8aec6bce64f81fe.1253021728.git.mstormo@gmail.com>
On Tue, Sep 15, 2009 at 5:44 PM, Marius Storm-Olsen <mstormo@gmail.com> wrote:
> +extern int _fmode;
Is it really needed? I might be wrong, but I thought _fmode needed a
more complex declaration, at least on mingw, for which you are
supposed to include stdlib.h. For example, for mingw, in stdlib.h, it
is declared this way:
#if !defined (__DECLSPEC_SUPPORTED) || defined (__IN_MINGW_RUNTIME)
#ifdef __MSVCRT__
extern int* _imp___fmode;
#define _fmode (*_imp___fmode)
#else
/* CRTDLL */
extern int* _imp___fmode_dll;
#define _fmode (*_imp___fmode_dll)
#endif
#else /* __DECLSPEC_SUPPORTED */
#ifdef __MSVCRT__
__MINGW_IMPORT int _fmode;
#else /* ! __MSVCRT__ */
__MINGW_IMPORT int _fmode_dll;
#define _fmode _fmode_dll
#endif /* ! __MSVCRT__ */
#endif /* __DECLSPEC_SUPPORTED */
As you can see it is a little more complex than a simple extern (e.g.
it uses __declspec(dllimport) when it is supported, and a bit of
manual dereferencing otherwise). So maybe you would just include
stdlib.h and use definition from there?
^ permalink raw reply
* Git crashes on pull
From: Guido Ostkamp @ 2009-09-15 18:47 UTC (permalink / raw)
To: git
Hi,
I have a clone of http://git.postgresql.org/git/postgresql.git where head
is at commit 167501570c74390dfb7a5dd71e260ab3d4fd9904.
I'm using Git version 1.6.5.rc1.10.g20f34 (should be at commit
20f34902d154f390ebaa7eed7f42ad14140b8acb from Mon Sep 14 10:49:01 2009
+0200)
Now when I 'git pull' then Git crashes with
git pull 2>&1 > /tmp/git-error
*** glibc detected *** git-remote-curl: free(): invalid pointer:
0xb7d19140 ***
======= Backtrace: =========
/lib/libc.so.6[0xb7c4f4b6]
/lib/libc.so.6(cfree+0x89)[0xb7c51179]
git-remote-curl[0x804d290]
git-remote-curl[0x804df04]
git-remote-curl[0x8065ea5]
git-remote-curl[0x804aac6]
/lib/libc.so.6(__libc_start_main+0xe0)[0xb7bfefe0]
git-remote-curl[0x804a991]
======= Memory map: ========
08048000-080a1000 r-xp 00000000 08:15 1658246
/usr/local/libexec/git-core/git-remote-curl
080a1000-080a2000 r--p 00058000 08:15 1658246
/usr/local/libexec/git-core/git-remote-curl
080a2000-080a3000 rw-p 00059000 08:15 1658246
/usr/local/libexec/git-core/git-remote-curl
080a3000-08143000 rw-p 080a3000 00:00 0 [heap]
b4400000-b4421000 rw-p b4400000 00:00 0
b4421000-b4500000 ---p b4421000 00:00 0
b45ea000-b45f4000 r-xp 00000000 08:13 1097821 /lib/libgcc_s.so.1
b45f4000-b45f6000 rw-p 00009000 08:13 1097821 /lib/libgcc_s.so.1
...
Any idea what's causing this?
Please keep me on CC, as I'm not subscribed on list.
Regards
Guido
^ permalink raw reply
* Re: [PATCH 04/14] Set _O_BINARY as default fmode for both MinGW and MSVC
From: Alexey Borzenkov @ 2009-09-15 19:01 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: Johannes.Schindelin, msysgit, git, lznuaa, raa.lkml
In-Reply-To: <badc5d24387c28c752a45f75e8aec6bce64f81fe.1253021728.git.mstormo@gmail.com>
On Tue, Sep 15, 2009 at 5:44 PM, Marius Storm-Olsen <mstormo@gmail.com> wrote:
> +extern int _fmode;
And indeed. I just ported this patch to my custom msysgit branch
(based on v1.6.4.3) and it didn't compile:
CC git.o
cc1.exe: warnings being treated as errors
In file included from git-compat-util.h:116,
from builtin.h:4,
from git.c:1:
compat/mingw.h:243: error: '_fmode' redeclared without dllimport
attribute: previous dllimport ignored
git.c: In function 'main':
git.c:456: error: the address of '_iob' will always evaluate as 'true'
make: *** [git.o] Error 1
^ permalink raw reply
* Re: [PATCH 04/14] Set _O_BINARY as default fmode for both MinGW and MSVC
From: Alexey Borzenkov @ 2009-09-15 19:07 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: Johannes.Schindelin, msysgit, git, lznuaa, raa.lkml
In-Reply-To: <badc5d24387c28c752a45f75e8aec6bce64f81fe.1253021728.git.mstormo@gmail.com>
GMail ate the bottom half of my message... again. :( Seems like
there's a strange bug in copy/pasting, I better compose long emails in
TextMate from now on. Here's a "reconstruction":
On Tue, Sep 15, 2009 at 5:44 PM, Marius Storm-Olsen <mstormo@gmail.com> wrote:
> +extern int _fmode;
And indeed. I just ported this patch to my custom msysgit branch
(based on v1.6.4.3) and it didn't compile:
CC git.o
cc1.exe: warnings being treated as errors
In file included from git-compat-util.h:116,
from builtin.h:4,
from git.c:1:
compat/mingw.h:243: error: '_fmode' redeclared without dllimport
attribute: previous dllimport ignored
git.c: In function 'main':
git.c:456: error: the address of '_iob' will always evaluate as 'true'
make: *** [git.o] Error 1
> + if (stdin) \
> + _setmode(_fileno(stdin), _O_BINARY); \
> + if (stdout) \
> + _setmode(_fileno(stdout), _O_BINARY); \
> + if (stderr) \
> + _setmode(_fileno(stderr), _O_BINARY); \
Also, at least mingw/gcc that is coming with msysgit thinks that
stdin/stdout/stderr always evaluate to true, and this check causes
problems as well. In the end, your patch should become something like
this:
diff --git a/compat/mingw.c b/compat/mingw.c
index fd642e4..807996c 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -5,7 +5,6 @@
#include "../strbuf.h"
extern int hide_dotfiles;
-unsigned int _CRT_fmode = _O_BINARY;
static int err_win_to_posix(DWORD winerr)
{
diff --git a/compat/mingw.h b/compat/mingw.h
index cfbcc0e..46473c5 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -244,6 +244,10 @@ char **env_setenv(char **env, const char *name);
static int mingw_main(); \
int main(int argc, const char **argv) \
{ \
+ _fmode = _O_BINARY; \
+ _setmode(_fileno(stdin), _O_BINARY); \
+ _setmode(_fileno(stdout), _O_BINARY); \
+ _setmode(_fileno(stderr), _O_BINARY); \
argv[0] = xstrdup(_pgmptr); \
return mingw_main(argc, argv); \
} \
I can't check if it compiles with MSVC, but with msysgit it compiles
fine. Tests pass at least up to 3400 (haven't finished the rest).
^ permalink raw reply related
* Re: [PATCH 04/14] Set _O_BINARY as default fmode for both MinGW and MSVC
From: Marius Storm-Olsen @ 2009-09-15 19:12 UTC (permalink / raw)
To: Alexey Borzenkov; +Cc: Johannes.Schindelin, msysgit, git, lznuaa, raa.lkml
In-Reply-To: <e2480c70909151207v4d89d302m27aecff0d4a11d45@mail.gmail.com>
Alexey Borzenkov said the following on 15.09.2009 21:07:
> GMail ate the bottom half of my message... again. :( Seems like
> there's a strange bug in copy/pasting, I better compose long emails
> in TextMate from now on. Here's a "reconstruction":
>
> On Tue, Sep 15, 2009 at 5:44 PM, Marius Storm-Olsen
> <mstormo@gmail.com> wrote:
>> +extern int _fmode;
>
> And indeed. I just ported this patch to my custom msysgit branch
> (based on v1.6.4.3) and it didn't compile:
Hmmm, I compile this fine with both MinGW from the msysgit 'devel'
branch, and MSVC; but I see your point.
I'll give your updated patch a roll tomorrow. Thanks
--
.marius
^ permalink raw reply
* Re: Git crashes on pull
From: Junio C Hamano @ 2009-09-15 19:22 UTC (permalink / raw)
To: Guido Ostkamp; +Cc: git
In-Reply-To: <alpine.LSU.2.01.0909152044450.10936@bianca.dialin.t-online.de>
Guido Ostkamp <git@ostkamp.fastmail.fm> writes:
> I have a clone of http://git.postgresql.org/git/postgresql.git where
> head is at commit 167501570c74390dfb7a5dd71e260ab3d4fd9904.
>
> I'm using Git version 1.6.5.rc1.10.g20f34 (should be at commit
> 20f34902d154f390ebaa7eed7f42ad14140b8acb from Mon Sep 14 10:49:01 2009
> +0200)
>
> Now when I 'git pull' then Git crashes with
>
> git pull 2>&1 > /tmp/git-error
> *** glibc detected *** git-remote-curl: free(): invalid pointer:
Please try this patch, which I have been preparing for later pushout.
From: Junio C Hamano <gitster@pobox.com>
Date: Mon, 14 Sep 2009 14:48:15 -0700
Subject: [PATCH] http.c: avoid freeing an uninitialized pointer
An earlier 59b8d38 (http.c: remove verification of remote packs) left
the variable "url" uninitialized; "goto cleanup" codepath can free it
which is not very nice.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
http.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/http.c b/http.c
index d0cc1b3..15926d8 100644
--- a/http.c
+++ b/http.c
@@ -866,7 +866,7 @@ static int fetch_pack_index(unsigned char *sha1, const char *base_url)
int ret = 0;
char *hex = xstrdup(sha1_to_hex(sha1));
char *filename;
- char *url;
+ char *url = NULL;
struct strbuf buf = STRBUF_INIT;
if (has_pack_index(sha1)) {
--
1.6.5.rc1
^ permalink raw reply related
* Re: [PATCH 0/4] Colouring whitespace errors in diff -B output
From: Junio C Hamano @ 2009-09-15 20:12 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git
In-Reply-To: <20090915155209.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting Junio C Hamano <gitster@pobox.com>
>
>> The last one hooks "diff -B" logic to the per-line output routines in a
>> way that mimicks how the normal patches are fed to them better, in order
>> to take advantage of all the existing whitespace error detection and
>> colouring logic.
>>
>> Junio C Hamano (4):
>> diff.c: shuffling code around
>> diff.c: split emit_line() from the first char and the rest of the line
>> diff.c: emit_add_line() takes only the rest of the line
>> diff -B: colour whitespace errors
>>
>> diff.c | 327 +++++++++++++++++++++++++++++++++++-----------------------------
>> 1 files changed, 180 insertions(+), 147 deletions(-)
>
> Sorry, but I don't seem to be able to apply these patches anywhere.
There is a subtle bug in "split emit_line()" patch I sent out, but later I
noticed the problem and fixed it in my tree, so please use the updated one
instead from my tree.
The series applies cleanly at the tip of jc/maint-1.6.0-blank-at-eof, but
the result of applying them will have large conflicts whether you are
merging that into 'maint', 'master', or 'next'. It's probably easier to
use the merge I've prepared to resolve them in my tree.
I have these two topics:
- jc/maint-1.6.0-blank-at-eof forks from old 1.6.0 codebase to contain
the above fixes (and the ones that are already in 'next'); and
- jc/maint-blank-at-eof that forks from 1.6.4 codebase and merges the
above branch. This branch does not have any commit on its own, but
does a rather nasty conflict resolution.
I'll push out the result, merging the latter to 'next' (and 'pu'),
sometime in the next few hours.
^ permalink raw reply
* git-svn and rebasing refactored (moved) content
From: Halstrick, Christian @ 2009-09-15 16:11 UTC (permalink / raw)
To: git@vger.kernel.org
In-Reply-To: <1252699129-6961-3-git-send-email-spearce@spearce.org>
Hi,
I have a question regarding git rebase operation when content was moved. I have
the problem when I transfer stuff from a subversion repo into my git repo, but
I wouldn't know the solution even if it would be a pure git scenario. Here is
the problem:
There is a SVN repository "Source" containing that files
"Source":
project/feat1/A.java
project/feat1/B.java
project/C.java
There is git repository "Target" where I work. That repository get's updates
from "Source" by 'git-svn migrate ...'. I had to move the files coming from
"Source" (using 'git mv'). I just moved but did not (and will not in future)
modify the files of "Source". Additionally I added my own new files. The state
of target is:
"Target":
project/src/feat1/A.java (renamed file)
project/src/feat1/B.java (renamed file)
project/src/C.java (renamed file)
project/pom.xml (created file)
Ideally from time to time I would like to rebase my work I do in "Target" on
the latest state of "Source". I use "git rebase ..." for that. But this
sometimes fails. If in "Source" files are only modified everything works fine.
E.g. modifications to "Source":project/feat1/A.java are visible in
"Target":project/src/feat1/A.java. That's great!
But the rebase fails with conflicts when things are moved or deleted in
"Source". E.g. if "Source":project/feat1/A.java becomes
"Source":project/feat2/A.java and I merge that commit into my branch in
"Target" I get
> CONFLICT (rename/rename): Rename
> "project/feat1/A.java"->"project/feat2/A.java" in branch "HEAD" rename
> "project/feat1/A.java"->"project/src/feat1/A.java " ...
I do understand the conflict but I am asking whether there is a better way to
use git so that I can get around these merge problems.
Ciao
Chris
^ 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