* Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Junio C Hamano @ 2008-07-28 20:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, sverre, Git Mailinglist, Miklos Vajna
In-Reply-To: <alpine.DEB.1.00.0807282008470.8986@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Well, I have to say that the workflow is a bit backwards if the person who
> _publishes_ the thing is the one saying "Ooops, my version no goodie,
> other version please, but so that pull still works".
>
> I would have expected the one who has the good version to make the choice.
That reminds me of:
http://thread.gmane.org/gmane.comp.version-control.git/89178
to one of whose messages I sent a response today.
^ permalink raw reply
* Re: [PATCH] Allow installing in the traditional way
From: Johannes Sixt @ 2008-07-28 20:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vod4itrgg.fsf@gitster.siamese.dyndns.org>
Zitat von Junio C Hamano <gitster@pobox.com>:
> In an earlier commit c70a8d9 (Makefile: Do not install a copy of 'git' in
> $(gitexecdir), 2008-07-21), we tried to avoid installing two git, one in
> /usr/bin/git and the other in /usr/libexec/git-core/git. It mistakenly
> removed the only copy of git when gitexecdir and bindir are set to the
> same directory, i.e. the traditional layout.
The patch looks fine. Thanks for fixing up my mistakes.
-- Hannes
^ permalink raw reply
* Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Avery Pennarun @ 2008-07-28 20:00 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, sverre, Git Mailinglist, Miklos Vajna
In-Reply-To: <20080728192651.GA26677@sigill.intra.peff.net>
On 7/28/08, Jeff King <peff@peff.net> wrote:
> My situation was two long-running branches, "stable" and "devel",
> both of which were worked on by many developers. One person was in
> charge of integration and branch management. They wanted "stable" to
> get the contents of "devel" (which were now ready for release), ignoring
> any small fixes that had been done on "stable" (since they had all been
> moved over to "devel" previously, but in subtly different ways that
> would create conflicts). And "git reset" was not an option, because they
> wanted to keep the history of "stable" in case those fixes needed to be
> looked at later.
>
> So the logical sequence was:
>
> git checkout production
> git merge -s theirs master
I have to say, this somehow feels wrong to me. What you're saying is
essentially that "stable has already been merged into devel" followed
by "and now we want to catch stable up to devel."
It really is two separate thoughts, and merging devel directly into
stable - literally by *undoing* all the changes from stable - doesn't
sound like it should be considered a safe operation.
Personally, I've started enjoying the "--no-ff" option to git-merge.
That way I can do
git checkout master
git merge production
git checkout production
git merge --no-ff master
The latter merge isn't really a "merge" since it could have been just
fast forwarded. But it avoids the aesthetic problems of commits like
"merge production into master" showing up in the master branch. It
also means that "git reset --hard HEAD^" works whether or not a
fastforward would have been theoretically possible.
Of course, this whole discussion is really just about how to make your
log look cleaner, and we could debate forever about that. It may make
sense to simply provide "theirs" as an exact mirror of "ours" if only
in the name of symmetry.
Have fun,
Avery
^ permalink raw reply
* Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Sverre Rabbelier @ 2008-07-28 19:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, Git Mailinglist, Miklos Vajna
In-Reply-To: <alpine.DEB.1.00.0807282008470.8986@racer>
On Mon, Jul 28, 2008 at 21:09, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Well, I have to say that the workflow is a bit backwards if the person who
> _publishes_ the thing is the one saying "Ooops, my version no goodie,
> other version please, but so that pull still works".
Why so? In this case the other branch was also owned by the publishing
person. I don't quite follow how this is any stranger than ours?
(Which is stranger to me, why would you want to merge in a branch if
you're not going to do anything with it anyway? I'm sure there are
valid workflows for it, which is why we have it, just saying that I
think 'theirs' makes more sense to me than 'ours')
> I would have expected the one who has the good version to make the choice.
Why have the person with the good version merge with... a bad version?
Isn't it usually "I will merge with you, because I know your branch
makes things go twice as fast" (paraphrasing Linus from his git talk
at google).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Sverre Rabbelier @ 2008-07-28 19:48 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Git Mailinglist, Johannes Schindelin
In-Reply-To: <20080728181424.GM32057@genesis.frugalware.org>
On Mon, Jul 28, 2008 at 20:14, Miklos Vajna <vmiklos@frugalware.org> wrote:
> On Mon, Jul 28, 2008 at 04:54:17PM +0200, Sverre Rabbelier <alturin@gmail.com> wrote:
>> So, in short: what does the list think about adding
>> "git-merge-theirs", that does (although possibly less 'hackish'):
>>
>> cat > git-merge-theirs << EOF
>> #!/bin/sh
>> eval git read-tree --reset -u \\\$\$#
>> EOF
>
> Isn't this the stupid one?
No, the stupid one did "take all non-conflicting hunks from our side,
and any for conflicting hunks, take theirs", which was rather silly I
must say, although I have heard one use-cases where it makes sense (no
I don't think we should have a git-merge-theirs-on-conflict).
> It's perfect for my testing needs, but this is not something that people
> should ever use on a real repo.
What about the use-case I described in my first mail?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Jeff King @ 2008-07-28 19:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: sverre, Git Mailinglist, Miklos Vajna
In-Reply-To: <alpine.DEB.1.00.0807282008470.8986@racer>
On Mon, Jul 28, 2008 at 08:09:55PM +0100, Johannes Schindelin wrote:
> Well, I have to say that the workflow is a bit backwards if the person who
> _publishes_ the thing is the one saying "Ooops, my version no goodie,
> other version please, but so that pull still works".
>
> I would have expected the one who has the good version to make the choice.
My situation was two long-running branches, "stable" and "devel",
both of which were worked on by many developers. One person was in
charge of integration and branch management. They wanted "stable" to
get the contents of "devel" (which were now ready for release), ignoring
any small fixes that had been done on "stable" (since they had all been
moved over to "devel" previously, but in subtly different ways that
would create conflicts). And "git reset" was not an option, because they
wanted to keep the history of "stable" in case those fixes needed to be
looked at later.
So the logical sequence was:
git checkout production
git merge -s theirs master
-Peff
^ permalink raw reply
* Re: GTP/0.1 terminology 101: commit reels and references
From: Sam Vilain @ 2008-07-28 19:26 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Joshua Roys, gittorrent, git, Jonas Fonseca
In-Reply-To: <alpine.DEB.1.00.0807281350590.2725@eeepc-johanness>
On Mon, 2008-07-28 at 14:01 +0200, Johannes Schindelin wrote:
> > - the reel has a defined object order (which as I hoped to demonstrate
> > in the test cases, is just a refinement of rev-list --date-order)
>
> Do you mean that the commit reel is a list pointing to bundles that can be
> sorted topologically by their contained commits?
Yes, but it is more defined than that. There are still ambiguities with
topological sort, so the gittorrent spec specified exactly how all ties
are broken. They happen to be a further refinement of --date-order,
with respect to the ordering of commits.
> > - deltas always point in one direction, to objects "earlier" on
> > the reel, so that slices of the reel sent on the network can be made
> > thin without resulting in unresolvable deltas (which should be
> > possible to do on commit boundaries using rev-list --objects-edge)
> That is exactly what bundles do. They are thin, as they assume that a few
> "preconditions", i.e. refs, are present.
Ok. I think there are also some other trivial differences such as
bundles containing refs (which in the context of gittorrent will be
useless).
> > - the behaviour at the beginning of the reel is precisely defined
> > (although as I said, I think that the decision might be worth
> > revisiting - perhaps getting just the latest reel is a useful
> > 'shallow clone')
>
> If you want to allow shallow clones, you must make the bundles non-thin.
> That would be a major bandwidth penalty.
>
> I'd rather not allow shallow clones with Gitorrent.
By "Shallow" I think I mean a different thing to you. I mean something
akin to just the last pack's worth of commits.
> > It's the lack of guarantees which is the issue, really.
>
> It should not be too difficult to provide a rev-list option (which is
> inherited by git-bundle, then) to pay an extra time to make sure that the
> bundle is minimal.
Ok. But from the current implementation's perspective, this is not yet
needed, we are just using the existing API.
Actually what would be useful would be for the thin pack generation to
also allow any object to be specified as its input list, not just
commits... then we wouldn't have to break blocks on commit boundaries
(see http://gittorrent.utsl.gen.nz/rfc.html#org-blocks).
> > In order to take the download work of the entire pack and distribute it
> > over multiple peers, you need a way to carve the bundle up. This has to
> > happen in such a way that the fragments that you get back will actually
> > fit together at the end, and also in such a way that you don't lose the
> > benefits of delta compression.
>
> That should be relatively easy.
>
> > The way I thought would be best to do that would be to line up all the
> > objects in an exactly defined way - hence, the "reel" concept - and then
> > chop that up.
>
> What exactly is that exact definition?
http://gittorrent.utsl.gen.nz/rfc.html#org-reels
> Is it the output of "rev-list --all --objects", chopped into equal chunks
> at commit boundaries? If so, it should probably be equal in terms of
> size, right?
No. It's chopped by uncompressed size.
http://gittorrent.utsl.gen.nz/rfc.html#org-blocks
> The tricky thing, of course, is to make that thing incremental, i.e.
> replace only a minimal amount of items in the "commit reel" (if I
> understood correctly, and the commit reel refers to a list of sets of
> commits with their objects) when a branch was modified.
You would make a new reel to cover a new bunch of updates. It's
important that the reels don't change too often for reasons I describe
in the RFC.
> Hmm. Maybe it would be time for you to draw a tiny diagram for all the
> people too lazy like me, which shows roughly how the communication between
> the peers should look like, and how the reel fits in.
As I said in my recent message to the list, I wrote another top level
overview here:
http://gittorrent.utsl.gen.nz/rfc.html#org-blocks
Cheers,
Sam.
^ permalink raw reply
* Re: [PATCHv2] git-mv: Keep moved index entries inact
From: Junio C Hamano @ 2008-07-28 19:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: SZEDER Gábor, Petr Baudis, git
In-Reply-To: <alpine.DEB.1.00.0807281605330.8986@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Mon, 28 Jul 2008, SZEDER Gábor wrote:
>
>> there is a race somewhere in these 'git-mv: Keep moved index entries
>> inact' changes.
>>
>> The test cases 'git mv should overwrite symlink to a file' or 'git mv
>> should overwrite file with a symlink' fail occasionaly. It's quite
>> non-deterministic: I have run t7001-mv.sh in a loop (see below) and
>> one or the other usually fails around 50 runs (but sometimes only
>> after 150). Adding some tracing echos to the tests shows that both
>> tests fail when running 'git diff-files' at the end.
>
> To make it more convenient to test: with this patch it fails all the time:
It's because we rename(2) but do not read back ctime, and reuse the cached
data from the old path that was renamed. After the failed test that moves
a regular file "move" to "symlink":
$ stat symlink
File: `symlink'
Size: 2 Blocks: 8 IO Block: 4096 regular file
Device: 30ah/778d Inode: 18104337 Links: 1
Access: (0664/-rw-rw-r--) Uid: ( 1012/ junio) Gid: ( 40/ src)
Access: 2008-07-28 11:49:55.000000000 -0700
Modify: 2008-07-28 11:48:41.000000000 -0700
Change: 2008-07-28 11:48:42.000000000 -0700
But the cached stat information looks like this:
$ ../../git-ls-files --stat
ctime=1217270921, mtime=1217270921, ino=18104337, mode=100644, uid=1012, gid=40symlink
We need to refresh the entry to pick up potential ctime changes.
read-cache.c | 7 ++++++-
builtin-ls-files.c | 21 +++++++++++++++------
2 files changed, 21 insertions(+), 7 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index 1cae361..834096f 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -40,7 +40,7 @@ static void replace_index_entry(struct index_state *istate, int nr, struct cache
void rename_index_entry_at(struct index_state *istate, int nr, const char *new_name)
{
- struct cache_entry *old = istate->cache[nr], *new;
+ struct cache_entry *old = istate->cache[nr], *new, *refreshed;
int namelen = strlen(new_name);
new = xmalloc(cache_entry_size(namelen));
@@ -51,6 +51,11 @@ void rename_index_entry_at(struct index_state *istate, int nr, const char *new_n
cache_tree_invalidate_path(istate->cache_tree, old->name);
remove_index_entry_at(istate, nr);
+
+ /* the renaming could have smudged the ctime */
+ refreshed = refresh_cache_entry(new, 0);
+ if (refreshed && refreshed != new)
+ new = refreshed;
add_index_entry(istate, new, ADD_CACHE_OK_TO_ADD|ADD_CACHE_OK_TO_REPLACE);
}
diff --git a/builtin-ls-files.c b/builtin-ls-files.c
index e8d568e..a6b30c8 100644
--- a/builtin-ls-files.c
+++ b/builtin-ls-files.c
@@ -16,6 +16,7 @@ static int show_deleted;
static int show_cached;
static int show_others;
static int show_stage;
+static int show_stat;
static int show_unmerged;
static int show_modified;
static int show_killed;
@@ -205,16 +206,20 @@ static void show_ce_entry(const char *tag, struct cache_entry *ce)
tag = alttag;
}
- if (!show_stage) {
- fputs(tag, stdout);
- } else {
+ if (show_stage)
printf("%s%06o %s %d\t",
tag,
ce->ce_mode,
abbrev ? find_unique_abbrev(ce->sha1,abbrev)
: sha1_to_hex(ce->sha1),
ce_stage(ce));
- }
+ else if (show_stat)
+ printf("ctime=%u, mtime=%u, ino=%u, mode=%o, uid=%u, gid=%u\t",
+ ce->ce_ctime, ce->ce_mtime, ce->ce_ino,
+ ce->ce_mode, ce->ce_uid, ce->ce_gid);
+
+ else
+ fputs(tag, stdout);
write_name_quoted(ce->name + offset, stdout, line_terminator);
}
@@ -235,7 +240,7 @@ static void show_files(struct dir_struct *dir, const char *prefix)
if (show_killed)
show_killed_files(dir);
}
- if (show_cached | show_stage) {
+ if (show_cached | show_stage | show_stat) {
for (i = 0; i < active_nr; i++) {
struct cache_entry *ce = active_cache[i];
int dtype = ce_to_dtype(ce);
@@ -488,6 +493,10 @@ int cmd_ls_files(int argc, const char **argv, const char *prefix)
show_stage = 1;
continue;
}
+ if (!strcmp(arg, "-S") || !strcmp(arg, "--stat")) {
+ show_stat = 1;
+ continue;
+ }
if (!strcmp(arg, "-k") || !strcmp(arg, "--killed")) {
show_killed = 1;
require_work_tree = 1;
@@ -593,7 +602,7 @@ int cmd_ls_files(int argc, const char **argv, const char *prefix)
/* With no flags, we default to showing the cached files */
if (!(show_stage | show_deleted | show_others | show_unmerged |
- show_killed | show_modified))
+ show_killed | show_modified | show_stat))
show_cached = 1;
read_cache();
^ permalink raw reply related
* gitk crashes when quitting gitk while it is is reading commits (was Re: gitk crashing on Windows.)
From: Steffen Prohaska @ 2008-07-28 19:18 UTC (permalink / raw)
To: Eric Raible; +Cc: git
In-Reply-To: <loom.20080728T162025-946@post.gmane.org>
On Jul 28, 2008, at 6:29 PM, Eric Raible wrote:
> Jurko Gospodnetić <jurko.gospodnetic <at> docte.hr> writes:
>
>> When you run gitk from a git repository on Windows it starts up and
>> starts updating its 'Row X/Y' output labels. This lasts for a few
>> seconds but if you terminate the application before this updating is
>> complete you get a Windows message stating:
>>
>> 'Wish Application has encountered a problem and needs to close. We
>> are sorry for the inconvenience.'
>>
>> and the standard 'Send Error Report'/'Don't Send' buttons.
>>
>> Hope this helps.
>>
>> Best regards,
>> Jurko Gospodnetić
>
> Though I can't find the relevant commit at the moment
> I believe that this is one already fixed in the latest
> from git://repo.or.cz/git/mingw/4msysgit.git.
I don't think so. The error Jurko reported might be the same error
that was reported earlier and filed as issue 125:
http://code.google.com/p/msysgit/issues/detail?id=125
I don't think the problem is Windows-specific. At least on Mac I am
seeing similar problems. When I hit CTRL-q while gitk is still reading
the commits, it crashes with as segfault.
Steffen
^ permalink raw reply
* Re: short log and email address
From: Johannes Schindelin @ 2008-07-28 19:11 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910807281157u44c08a59ld3bdc0416e8a1d03@mail.gmail.com>
Hi,
On Mon, 28 Jul 2008, Jon Smirl wrote:
> On 7/28/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > On Mon, 28 Jul 2008, Jon Smirl wrote:
> >
> > > Using the -e option in shortlog changes the results by spitting
> > > things out by email address instead of leaving them combined by
> > > name. That's probably not what you want. Instead you want
> > > everything combined by name and then display the most recent email
> > > address used.
> >
> > What is so wrong with _not_ using -e (since you do not want to see the
> > email address stored in the commit message, and -e would be asking for
> > that _exactly_)?
>
> I wanted -e to give me the most recent email so that I would know how
> to sort the mailmap alias list.
As I explained, that is not what -e is _supposed_ to do. In Git, content
is king, and as such -e should look at the content. Unsurprisingly, that
is exactly what it does.
Nothing prohibits you from post-processing the output, though.
Ciao,
Dscho
^ permalink raw reply
* Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Johannes Schindelin @ 2008-07-28 19:09 UTC (permalink / raw)
To: Jeff King; +Cc: sverre, Git Mailinglist, Miklos Vajna
In-Reply-To: <20080728185604.GA26322@sigill.intra.peff.net>
Hi,
On Mon, 28 Jul 2008, Jeff King wrote:
> On Mon, Jul 28, 2008 at 04:54:17PM +0200, Sverre Rabbelier wrote:
>
> > Thus resulting in a 'wrong way around' merge as part of master? It
> > would say "Merge branch 'master' into otherbranch", while what
> > happened was "Merge branch 'otherbranch' into master".
> >
> > So, in short: what does the list think about adding
> > "git-merge-theirs", that does (although possibly less 'hackish'):
> >
> > cat > git-merge-theirs << EOF
> > #!/bin/sh
> > eval git read-tree --reset -u \\\$\$#
> > EOF
>
> I ran into this exact situation while showing somebody how awesome git
> was, and it was a little embarrasing to say "oops, now we have to do
> this backwards."
Well, I have to say that the workflow is a bit backwards if the person who
_publishes_ the thing is the one saying "Ooops, my version no goodie,
other version please, but so that pull still works".
I would have expected the one who has the good version to make the choice.
Ciao,
Dscho
^ permalink raw reply
* Re: short log and email address
From: Jon Smirl @ 2008-07-28 18:57 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0807281928400.8986@racer>
On 7/28/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
>
> On Mon, 28 Jul 2008, Jon Smirl wrote:
>
> > Using the -e option in shortlog changes the results by spitting things
> > out by email address instead of leaving them combined by name. That's
> > probably not what you want. Instead you want everything combined by name
> > and then display the most recent email address used.
>
>
> What is so wrong with _not_ using -e (since you do not want to see the
> email address stored in the commit message, and -e would be asking for
> that _exactly_)?
I wanted -e to give me the most recent email so that I would know how
to sort the mailmap alias list.
>
> After the fact, you can annotate the names with all you like. For
> example, the most recent email address for that person.
>
> But as Mark pointed out, the name might be a bad key. Maybe you will have
> to do something completely different, namely maintain a separate list of
> (correct) names and emails, and then having line numbers in .mailmap,
> like:
>
> 1 <davem@sunset>
> 1 <davem@sunrise>
> 1 <davem@moonshine>
> 2 <dave.miller@miller.com>
> 2 <dave.miller@highnoon.miller.com>
>
> etc
>
> However, I have to say that I see small value in that, and an inordinate
> amount of work that nobody wants to do.
We could order the aliases until the correct alias is the last one. An
initial proxy would be to use the most recent email address on the
person's commits.
The trick is automating the maintenance. Modify checkpatch,pl to look
up the person's name up in the mailmap file and retrieve all matching
aliases.
If the name isn't in mailmap, tell them to make a patch adding their
name or to change their name.
If the name is there but the email is not the last one in the list,
tell them to make a patch rearranging mailmap to reflect their current
name/email.
If name is there and email is last on list, don't complain.
>
> Ciao,
> Dscho
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Jeff King @ 2008-07-28 18:56 UTC (permalink / raw)
To: sverre; +Cc: Git Mailinglist, Miklos Vajna, Johannes Schindelin
In-Reply-To: <bd6139dc0807280754x76b6ffedg6bf756dfce23f1e3@mail.gmail.com>
On Mon, Jul 28, 2008 at 04:54:17PM +0200, Sverre Rabbelier wrote:
> Thus resulting in a 'wrong way around' merge as part of master? It
> would say "Merge branch 'master' into otherbranch", while what
> happened was "Merge branch 'otherbranch' into master".
>
> So, in short: what does the list think about adding
> "git-merge-theirs", that does (although possibly less 'hackish'):
>
> cat > git-merge-theirs << EOF
> #!/bin/sh
> eval git read-tree --reset -u \\\$\$#
> EOF
I ran into this exact situation while showing somebody how awesome git
was, and it was a little embarrasing to say "oops, now we have to do
this backwards."
So I think it would be nice for completeness, although I admit that my
situation was rare (but no rarer, perhaps, than "-s ours").
-Peff
PS You may find your shell snippet a bit more readable by quoting 'EOF'.
^ permalink raw reply
* Re: short log and email address
From: Johannes Schindelin @ 2008-07-28 18:34 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910807281106y56f8b67ao86f78822c4b4ad58@mail.gmail.com>
Hi,
On Mon, 28 Jul 2008, Jon Smirl wrote:
> Using the -e option in shortlog changes the results by spitting things
> out by email address instead of leaving them combined by name. That's
> probably not what you want. Instead you want everything combined by name
> and then display the most recent email address used.
What is so wrong with _not_ using -e (since you do not want to see the
email address stored in the commit message, and -e would be asking for
that _exactly_)?
After the fact, you can annotate the names with all you like. For
example, the most recent email address for that person.
But as Mark pointed out, the name might be a bad key. Maybe you will have
to do something completely different, namely maintain a separate list of
(correct) names and emails, and then having line numbers in .mailmap,
like:
1 <davem@sunset>
1 <davem@sunrise>
1 <davem@moonshine>
2 <dave.miller@miller.com>
2 <dave.miller@highnoon.miller.com>
etc
However, I have to say that I see small value in that, and an inordinate
amount of work that nobody wants to do.
Ciao,
Dscho
^ permalink raw reply
* Re: short log and email address
From: Jon Smirl @ 2008-07-28 18:25 UTC (permalink / raw)
To: Mark Brown; +Cc: Git Mailing List
In-Reply-To: <20080728181101.GA9148@sirena.org.uk>
On 7/28/08, Mark Brown <broonie@sirena.org.uk> wrote:
> On Mon, Jul 28, 2008 at 02:06:06PM -0400, Jon Smirl wrote:
> > Using the -e option in shortlog changes the results by spitting things
> > out by email address instead of leaving them combined by name. That's
> > probably not what you want. Instead you want everything combined by
> > name and then display the most recent email address used.
>
> Apart from anything else you're assuming that people's names are
> globally unique - they aren't. I'm aware of several Mark Browns active
> in the free software world, for example.
There is a conflicting problem, multiple people with the same name and
people using multiple email addresses. The only solution I can see is
for the Mark Brown developers to get together and come up with a way
to differentiate their signatures (initial, nickname, etc), otherwise
I can't tell them apart from someone using multiple email addresses.
Mark Brown <broonie@opensource.wolfsonmicro.com>
Mark Brown <broonie@sirena.org.uk>
Same or two different people? These two names have committed to the kernel.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCHv2] git-mv: Keep moved index entries inact
From: Johannes Schindelin @ 2008-07-28 18:24 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Junio C Hamano, Petr Baudis, git
In-Reply-To: <alpine.DEB.1.00.0807281610270.8986@racer>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2110 bytes --]
Hi,
On Mon, 28 Jul 2008, Johannes Schindelin wrote:
> On Mon, 28 Jul 2008, Johannes Schindelin wrote:
>
> > On Mon, 28 Jul 2008, SZEDER Gábor wrote:
> >
> > > there is a race somewhere in these 'git-mv: Keep moved index entries
> > > inact' changes.
> > >
> > > The test cases 'git mv should overwrite symlink to a file' or 'git
> > > mv should overwrite file with a symlink' fail occasionaly. It's
> > > quite non-deterministic: I have run t7001-mv.sh in a loop (see
> > > below) and one or the other usually fails around 50 runs (but
> > > sometimes only after 150). Adding some tracing echos to the tests
> > > shows that both tests fail when running 'git diff-files' at the end.
> >
> > To make it more convenient to test: with this patch it fails all the
> > time:
>
> Ooops. Seems like I changed the test 23 to fail, instead of test 24.
> However, I think it is the same bug: the index is newer by one second,
> so it seems that the patch for builtin-mv.c did not really keep the data
> "intact".
>
> Note that a test case should use test-chmtime to force this scenario,
> not sleep a second.
>
> Unfortunately, I already spent my Git time budget for today, so the ball
> is out of my half for now.
Hah! I had a few minutes, and this is my analysis:
Just try to "mv" a file, and look at the _ctime_ before and after. Yes,
that is right, at least on my system (ext3) it _changes_.
So the test 23 and 24 in t7001-mv.sh are totally bogus. They purport to
test that git-mv retains the whole meta-information in the cache and
therefore the index does not need to be updated.
However, it _does_ need to be updated, exactly because ctime changed.
Only that the test failed to test what it tried to test, instead
succeeding erroneously, just because the index was racy most of the time
and got silently updated.
So, this is the analysis. The fixes will have to be done by somebody
else, because /me goes running now.
(Possible fixes I envisage: update ctime via stat() after rename(), or
just give up and scrap the whole "leave cache_entry inact" thing.)
Ciao,
Dscho
^ permalink raw reply
* Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Miklos Vajna @ 2008-07-28 18:14 UTC (permalink / raw)
To: sverre; +Cc: Git Mailinglist, Johannes Schindelin
In-Reply-To: <bd6139dc0807280754x76b6ffedg6bf756dfce23f1e3@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 448 bytes --]
On Mon, Jul 28, 2008 at 04:54:17PM +0200, Sverre Rabbelier <alturin@gmail.com> wrote:
> So, in short: what does the list think about adding
> "git-merge-theirs", that does (although possibly less 'hackish'):
>
> cat > git-merge-theirs << EOF
> #!/bin/sh
> eval git read-tree --reset -u \\\$\$#
> EOF
Isn't this the stupid one?
It's perfect for my testing needs, but this is not something that people
should ever use on a real repo.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git-scm.com
From: Tom Werner @ 2008-07-28 18:12 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.1.00.0807281201350.2725@eeepc-johanness>
On Mon, Jul 28, 2008 at 3:50 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> On Sun, 27 Jul 2008, Tom Werner wrote:
>> I find it a bit confusing that some here seem to have a strong dislike
>> for GitHub. It's true that we haven't been active on the developer list
>> or in the #git channel on freenode, but we are constantly in #github and
>> have answered a *great* many questions from developers that are new to
>> git.
>
> Speaking for myself, I will probably direct some users from #git to
> #github, then.
>
> The deeper reasoning: if you really do help by that channel, by all means
> I want to provide you with the opportunity to do so.
By all means! The users might be a bit confused about why you're
sending them to #github, but we're happy to help them out if you don't
care to. We actually employ a support person to man the channel and
help out where he can.
>> Perhaps it is the commercial aspect of GitHub that offends.
>
> In my opinion you can be as commercial as you want. Nevertheless, I would
> like to see some direct benefit for me, too, for obvious reasons. That
> does not need to be money; like Junio said, watching out for user
> questions on the Git list would already be very useful, in two respects:
>
> - the core developers have more time for hacking on Git itself (which
> would be good both for the developers as well as for you),
Using this same logic, it follows that we GitHub developers would be
better suited to hacking on GitHub (which would be good for the git
community). There are only so many hours in the day. I've had many a
GitHub user tell me that the GitHub interface and functionality helped
them finally understand git and feel comfortable switching to it from
SVN or CVS. It seems we can help bigger populations of git users by
making the site as clear and easy to use as possible, so that is what
we choose to do.
> - if your advices can be enhanced (such as my gripe that "git show" is not
> even so much as mentioned, in spite of being _the_ porcelain to inspect
> objects in Git's object database, not cat-file, whose only role in
> tutorials can be to shoo new users away) it will be early, which again
> is a win-win situation for both core developers as well as for you, and
Can you clarify what you are referring to here? I'm not sure I understand.
> - just as in the past, I fully expect the main thrust of the major changes
> in Git to be driven by user experience (just think of Git 1.5.0), and by
> driving users away (and indeed, by driving yourself away, a bunch of
> power-users), you would make that much more unlikely to happen in the
> future. So, having you closer to the Git mailing list and #git would
> again be a win-win situation.
I totally agree with the direction that 1.5 has taken git. You guys
are doing an awesome job with user experience. As I come across
usability problems I'll be sure to bring them up here in the future.
>> Having had to implement a git-daemon replacement that fit our needs, I
>> have some ideas on how to improve git-daemon and fetch-pack with
>> regards to error messages and logging.
>
> I might mention here that I think you are committing one of the biggest
> sins in Open Source: you do not reap the full power of the community.
>
> I am sure, if you would have mentioned your needs first, possibly followed
> by an early version of a patch, git-daemon would already be enhanced to
> your liking, and these enhancements would be available to everyone
> (including me, for example). But maybe that being available to everyone
> is not in the best interest of a commercial outfit?
The problem is that I'm only a casual C coder. It takes me a while to
figure out what's going on in the git source. We needed a way to serve
public git repositories from a hashed directory structure (e.g.
/a/b/c/user/repo.git) and we needed it fast. In a few days worth of
coding Erlang, I was able to meet that need (and also add logging and
better error messages returned to the client). If I had, as you
suggest, created a badly written patch and asked for help on the list,
I'd probably still be trying to solve the problem. It's dubious that
anyone other than us currently needs to satisfy the hashed directory
requirement, and as such I would not assume or expect that anyone
would be motivated to spend a bunch of time helping a C amateur
satisfy that need. In the end I was responsible for making it work,
and I did that the best and most efficient way I knew how.
Like I said before, I'm happy to share my suggestions for better error
messages and logging behavior, but I'm probably not going to be much
help with providing patches.
>> We like to design from first principles, see how good we can do, and
>> then get feedback from the users.
>
> Maybe this is so contrary to Open Source that many are uncomfortable with
> it.
>
> Also note that one of the major gripe with you making money off of Git
> could be the following: we have over 500 contributors, and most of them --
> first and foremost of all, the two major contributors, Junio and Shawn --
> cannot make money from Git. Envy is wrong, but it is real.
This is clearly false and does not do Junio or Shawn justice. It's not
hard to imagine that these two (or any of the other contributors)
could make money doing training for git at companies that have adopted
it, or as consultants to firms that use git in novel ways, or as
authors of git books. Scott Chacon gets paid right now to work on
tools that use git as an underlying file system. In fact, by helping
bring corporate interest to git, GitHub is paving the way for more and
more people to make money from git if they so choose. I wouldn't be
surprised if, down the road, Junio could be paid to hack on git full
time via corporate sponsorship. The continuing advancement of git is
of interest to a great many people. Some of which would gladly pay for
it.
Tom Preston-Werner
github.com/mojombo
^ permalink raw reply
* Re: short log and email address
From: Mark Brown @ 2008-07-28 18:11 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910807281106y56f8b67ao86f78822c4b4ad58@mail.gmail.com>
On Mon, Jul 28, 2008 at 02:06:06PM -0400, Jon Smirl wrote:
> Using the -e option in shortlog changes the results by spitting things
> out by email address instead of leaving them combined by name. That's
> probably not what you want. Instead you want everything combined by
> name and then display the most recent email address used.
Apart from anything else you're assuming that people's names are
globally unique - they aren't. I'm aware of several Mark Browns active
in the free software world, for example.
--
"You grabbed my hand and we fell into it, like a daydream - or a fever."
^ permalink raw reply
* short log and email address
From: Jon Smirl @ 2008-07-28 18:06 UTC (permalink / raw)
To: Git Mailing List
Using the -e option in shortlog changes the results by spitting things
out by email address instead of leaving them combined by name. That's
probably not what you want. Instead you want everything combined by
name and then display the most recent email address used.
Is there some way to fix this for the future? Maybe use Reply-to:
instead of From: on email import?
998 David S. Miller <davem@sunset.davemloft.net>
689 David S. Miller <davem@davemloft.net>
6 David S. Miller <davem@huronp11.davemloft.net>
5 David S. Miller <davem@hutch.davemloft.net>
4 David S. Miller <davem@bnsf.davemloft.net>
2 David S. Miller <davem@t1000.davemloft.net>
2 David S. Miller <davem@ultra5.davemloft.net>
1 David S. Miller <davem@goma.davemloft.net>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] Optional grouping of projects by category.
From: Sébastien Cevey @ 2008-07-28 18:03 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3zlo3u2r2.fsf@localhost.localdomain>
At Sun, 27 Jul 2008 01:53:43 -0700 (PDT), Jakub Narebski wrote:
> Thanks a lot. I don't know if it is a good time, with git being in
> feature freeze, and GSoC project about adding caching to gitweb in
> the works, but I'll take this patch and resend it if needed. I'll
> try to comment on it soon.
Great, looking forward to that, thanks!
--
Sébastien Cevey / inso.cc
^ permalink raw reply
* [StGIT] Not working on Windows with msysgit.
From: Jurko Gospodnetić @ 2008-07-28 17:29 UTC (permalink / raw)
To: git
Hi.
I believe StGIT fails to work on Windows with msysgit installed
because of the way it runs its external executables. It assumes that the
executable is available on the path and is named exactly 'git'.
This however is not the case on Windows with msysgit installed. There
the 'git executable' is a batch script named git.cmd and stgit fails to
find it causing all git calls to return an error code.
Popen() calls in StGIT's run.py module seem to run their executables
(git & gitk only as far as I saw from the sources) directly instead of
running them through the shell in order to have the shell try all the
default extensions (configured on Windows using the PATHEXT environment
variable).
One 'fix' that corrects this in all the use cases on Windows that I
tried is to add the shell=True parameter to all Popen() calls in StGIT's
run.py module (one in __run_io() and one in __run_noio()). This would
however require more testing as I do not know how this would affect
other OSs or whether there might be some problems with how Windows's
default cmd shell handles quoting in the executed command lines. I do
recall Python having some serious problems with these quoting in
executed commands... something about external quotes getting stripped in
some cases... I might be able to dig up a workaround from somewhere if
needed...
I'm using Windows XP SP3 and my git/StGIT/Python version information is:
> Stacked GIT 0.14.3
> git version 1.5.6.1.1071.g76fb
> Python version 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)]
Anyone using StGIT on Windows with sysgit?
The place where I originally detected this problem is that StGIT
fails to read the stgit.editor configuration option with
Windows/msysgit. I think it got so far though only because I also had
cygwin git a bit later on the path.
Best regards,
Jurko Gospodnetić
^ permalink raw reply
* [StGit] StGit documentation on its configuration file usage.
From: Jurko Gospodnetić @ 2008-07-28 17:01 UTC (permalink / raw)
To: git
Hi.
StGIT's project page links to the
http://wiki.procode.org/cgi-bin/wiki.cgi/StGIT_Tutorial page for its
tutorial information.
There the 'Configuration file' notes state that StGIT uses
/etc/stgitrc, ~/.stgitrc and then .git/stgitrc configuration files in
that order and that there is an example configuration file under the
examples folder. However, grepping through the StGIT sources I found no
references to the stgitrc file but only wrappers for using the native
GIT configuration system. Also, looking at the examples folder I found
only an example that seems to indicate that StGIT's configuration
options should be integrated with other regular GIT configuration options.
Did I miss something? Or is this wiki information outdated?
Testing this I see that StGIT does not read the git configuration
correctly on Windows with msysgit anyway, but that's a story for a
different thread.
Best regards,
Jurko Gospodnetić
^ permalink raw reply
* Importing patches from email, which address?
From: Jon Smirl @ 2008-07-28 16:59 UTC (permalink / raw)
To: Git Mailing List
When working with the list of author emails for the kernel, I noticed
that a lot of the author's email address are from internal mail
servers. How is the handled in git (stgit, etc..)? Is the import using
the email From:, would it be better to use Reply-to:?
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: gitk crashing on Windows.
From: Eric Raible @ 2008-07-28 16:29 UTC (permalink / raw)
To: git
In-Reply-To: <g6kmqf$q9p$1@ger.gmane.org>
Jurko Gospodnetić <jurko.gospodnetic <at> docte.hr> writes:
>
> Hi.
>
> When you run gitk from a git repository on Windows it starts up and
> starts updating its 'Row X/Y' output labels. This lasts for a few
> seconds but if you terminate the application before this updating is
> complete you get a Windows message stating:
>
> 'Wish Application has encountered a problem and needs to close. We
> are sorry for the inconvenience.'
>
> and the standard 'Send Error Report'/'Don't Send' buttons.
>
> Hope this helps.
>
> Best regards,
> Jurko Gospodnetić
Though I can't find the relevant commit at the moment
I believe that this is one already fixed in the latest
from git://repo.or.cz/git/mingw/4msysgit.git.
- Eric
^ 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