* Re: [PATCH] reset: add --quiet option
From: Stephen Boyd @ 2009-11-30 21:45 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <94a0d4530911300219j51e21e2cwae17d4248400a345@mail.gmail.com>
On Mon, Nov 30, 2009 at 2:19 AM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> I thought somebody would complain about loosing that string. In any
> case, first step is adding --query to 'git reset', second step is
> moving all OPT_BOOLEAN('q' to OPT__QUIET; there are other commands
> doing the same.
>
If you're already touching the line why not just do it once? I agree a
follow-up patch to cover the other commands would be good.
^ permalink raw reply
* Re: equal-tree-merges as way to make rebases fast-forward-able
From: Nanako Shiraishi @ 2009-11-30 22:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Bernhard R. Link, git
In-Reply-To: <7v8wdnooza.fsf@alter.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>
> To avoid that, I think (1) the marker has to be more reliable than just
> "happens to have the same tree", and (2) the traversal done by Porcelains
> (your patches 3 thru 5) by default should be unaware of eqt.
>
> I don't know what a suitable marker should look like, though. The marker
> must be easily identifiable by the lowest level rev-list machinery, so it
> needs to be a sign left somewhere in the commit object. Perhaps making it
> require to have the same tree as all its parents _and_ a well-known marker
> string in the log message (and nothing else) would be a good start.
I think you can record a merge commit that has an unusual
list of parents for this. For example, you can record the
latest version twice, as the first and the second parents,
and make the previous version the third parent. Because
such a merge can't be created with git-merge command, you
can reliably tell that it is an unusual 'marker' merge.
No matter what techinique is used to mark the special
'marker', if it happens in real life for two or more people
who worked independantly to arrive at the same conclusion,
I don't think dismissing it as 'by chance' and discarding
the contribution from the second branch is a good solution.
If git is meant to work smoothly in projects where more than
one person see and accept patches from the same origin, the
condition is not met 'by chance'; the tool is by design
supposed to handle it as a regular situation.
On the other hand, if you made the marker reliable, I think
you don't have to disable this feature by default like you
said in your (2).
As a side note, I have a bug to report. I tried this sequence
of commands to make sure git-merge doesn't record the same
parent twice (the last git-merge is made on the slave branch
and tries to have slave, master and slave as its three
parents).
% git init
% echo hello >world
% git add . ; git commit -m first
% echo again >world
% git commit -a -m master
% git checkout -b slave master^
% echo again >world
% git commit -a -m slave
% git merge master slave
But I got the "usage: ..." error message from git-merge.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH] tests: handle NO_PYTHON setting
From: Johan Herland @ 2009-11-30 22:31 UTC (permalink / raw)
To: Jeff King; +Cc: git, Brandon Casey, Junio C Hamano, Sverre Rabbelier
In-Reply-To: <tzCtKYIbFlbIbn30IPnqgVxpN1o3NxDP88NXFHHufBYXMjZJIG1Gyw@cipher.nrlssc.navy.mil>
On Monday 30 November 2009, Brandon Casey wrote:
> Jeff King wrote:
> > On Mon, Nov 30, 2009 at 12:07:40PM -0600, Brandon Casey wrote:
> >> ps. There's something eerily familiar about this patch.
> >
> > Hmmm. Yes, I didn't search before writing it, but you probably mean:
> >
> > http://article.gmane.org/gmane.comp.version-control.git/127172
> >
> :) yeah, that was it, nbd.
Oops. I got Brandon's patches in my local tree, but I never got around to
resend the series until Sverre picked up and refactored it. Sorry for the
screwup.
> > But that is missing the NO-PYTHON bit in GIT-BUILD-OPTIONS (did you
> > forget it there, or was it part of some other patch that also didn't
> > get applied?).
>
> It was 1/2 of that series.
Indeed.
> > Also, I am tempted to move the GIT-BUILD-OPTIONS invocation _up_. It
> > is about reading config and should probably come before we start doing
> > _anything_.
> >
> > So maybe this instead:
>
> <snip the patch>
>
> Looks fine to me.
As with Brandon's original patch, this is of course
Acked-by: Johan Herland <johan@herland.net>
> No strong opinion on whether the BUILD-OPTIONS thing should be
> at the beginning of the script, or in the place where you placed
> it.
Me neither.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Git open calls fail on NFS-mounted NTFS volume
From: Kai Lanz @ 2009-11-30 23:09 UTC (permalink / raw)
To: git
There are several places in the code where git calls open() with the
flag
O_EXCL. This causes a problem for us when the current directory is on an
NFS-mounted NTFS volume shared by an NAS fileserver. The open fails with
"EACCES: Permission denied", even though the user has full read/write
permissions on the target directory.
I used a tiny C program to confirm that the O_EXCL flag is the culprit;
removing that flag from the open() call allows the open to succeed. Of
course, the call also succeeds, with the O_EXCL flag in place, if the
current directory is on an NFS-mounted UNIX filesystem.
We're looking into ways to work around this; one way would be to hack
the git
source and remove all the O_EXCL flags (are they really needed?), but
I'm
afraid that might break git in horrible ways. Another way might be to
mount
the NTFS volume via CIFS instead of NFS. But first I wanted to ask if
anyone
here can offer a solution based on changing our git configuration or
our NFS
mount options or the NTFS volume settings. (At present we have no
gitconfig
file, so all settings are default).
Git version is 1.6.5.3, running on x86_64 RHEL-4, kernel 2.6.9-89.
The error
the user sees is:
> cd /WWW
> git init
fatal: cannot copy '/usr/local/share/git-core/templates/info/exclude' to
'/WWW/.git/info/exclude': Permission denied
Using strace, we can see the offending call:
open("/WWW/.git/info/exclude", O_WRONLY|O_CREAT|O_EXCL, 0666) = -1
EACCES
(Permission denied)
We know the user has permission to create this file because he can cd
into
/WWW/.git/info and copy exclude there from the templates directory by
hand.
--
Kai Lanz Stanford University School of Earth Sciences
^ permalink raw reply
* [PATCH] get_ref_states: strdup entries and free util in stale list
From: Bert Wesarg @ 2009-11-30 23:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Jay Soffian, git, Bert Wesarg
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
---
builtin-remote.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/builtin-remote.c b/builtin-remote.c
index 7916626..bb72e27 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -272,7 +272,9 @@ static int get_ref_states(const struct ref *remote_refs, struct ref_states *stat
die("Could not get fetch map for refspec %s",
states->remote->fetch_refspec[i]);
- states->new.strdup_strings = states->tracked.strdup_strings = 1;
+ states->new.strdup_strings =
+ states->tracked.strdup_strings =
+ states->stale.strdup_strings = 1;
for (ref = fetch_map; ref; ref = ref->next) {
unsigned char sha1[20];
if (!ref->peer_ref || read_ref(ref->peer_ref->name, sha1))
@@ -768,7 +770,7 @@ static void clear_push_info(void *util, const char *string)
static void free_remote_ref_states(struct ref_states *states)
{
string_list_clear(&states->new, 0);
- string_list_clear(&states->stale, 0);
+ string_list_clear(&states->stale, 1);
string_list_clear(&states->tracked, 0);
string_list_clear(&states->heads, 0);
string_list_clear_func(&states->push, clear_push_info);
--
1.6.6.rc0.253.g1ec3
^ permalink raw reply related
* Re: [PATCH 1/6] stg mail: Refactor __send_message and friends
From: Alex Chiang @ 2009-11-30 23:58 UTC (permalink / raw)
To: Karl Wiberg; +Cc: catalin.marinas, git
In-Reply-To: <4B123B48.4050405@treskal.com>
* Karl Wiberg <kha@treskal.com>:
> Alex Chiang wrote:
>
>> + if (smtppassword and not smtpuser):
>> + raise CmdException, 'SMTP password supplied, username needed'
>> + if (smtpusetls and not smtpuser):
>> + raise CmdException, 'SMTP over TLS requested, username needed'
>
> Python style nit: Use "raise Exception('message')" in new code. (And
> yes, I know you just moved these lines around.)
Changed, thanks.
^ permalink raw reply
* Re: [PATCH 3/6] stg mail: make __send_message do more
From: Alex Chiang @ 2009-11-30 23:59 UTC (permalink / raw)
To: Karl Wiberg; +Cc: catalin.marinas, git
In-Reply-To: <b8197bcb0911291323l35cb3624td3cbc393bf4513b3@mail.gmail.com>
* Karl Wiberg <kha@treskal.com>:
> On Sat, Nov 28, 2009 at 8:50 PM, Alex Chiang <achiang@hp.com> wrote:
>
> > Factor out the common code required to send either a cover mail
> > or patch, and implement it in __send_message.
>
> Nice code size reduction.
Thanks.
> > + msg_id = email.Utils.make_msgid('stgit')
> > + build = { 1: __build_cover, 4: __build_message }
> > + msg = build[len(args)](tmpl, msg_id, options, *args)
> > +
> > + from_addr, to_addrs = __parse_addresses(msg)
> > + msg_str = msg.as_string(options.mbox)
> > + if options.mbox:
> > + out.stdout_raw(msg_str + '\n')
> > + return msg_id
> > +
> > + outstr = { 1: 'the cover message', 4: 'patch "%s"' % args[0] }
> > + out.start('Sending ' + outstr[len(args)])
>
> You could consolidate the two dictionaries like this, to avoid making
> the same choice twice and make the code more pleasant to read:
>
> (build, outstr) = { 1: (__build_cover, 'the cover message'), 4:
> (__build_message, 'patch "%s"' % args[0]) }
Hm, I don't think that's valid. I ended up doing something like
this:
d = { 'cover': (__build_cover, 'the cover message'),
'patch': (__build_message, 'patch "%s"' % args[0]) }
(build, outstr) = d[type]
> > + # give recipients a chance of receiving related patches in correct order
> > + # patch_nr < total_nr
> > + if len(args) == 1 or (len(args) == 4 and args[1] < args[2]):
> > + sleep = options.sleep or config.getint('stgit.smtpdelay')
> > + time.sleep(sleep)
>
> Hmm. I must say I find all the args[x] a bit hard to read. I'd prefer
> symbolic names.
Ok, I changed this up.
Thanks for the review.
/ac
^ permalink raw reply
* Re: [PATCH 5/6] stg mail: add basic support for git send-email
From: Alex Chiang @ 2009-12-01 0:00 UTC (permalink / raw)
To: Karl Wiberg; +Cc: catalin.marinas, git
In-Reply-To: <b8197bcb0911291354m674d3698m929a1d542a59ed9f@mail.gmail.com>
* Karl Wiberg <kha@treskal.com>:
> On Sat, Nov 28, 2009 at 8:50 PM, Alex Chiang <achiang@hp.com> wrote:
>
> > + # XXX: yuck, there's gotta be a more pythonic way. Ideally we'd like
> > + # to use the git_opts dictionary as our mapping between stg mail and
> > + # git send-email; extract k, v pairs from git_opts, and use those
> > + # to iterate across options somehow.
> > + git_opts = { 'to': '--to=', 'cc': '--cc=', 'bcc': '--bcc=' }
> > + if options.to:
> > + for a in options.to:
> > + cmd.append("--to=%s" % a)
> > + if options.cc:
> > + for a in options.cc:
> > + cmd.append("--cc=%s" % a)
> > + if options.bcc:
> > + for a in options.bcc:
> > + cmd.append("--bcc=%s" % a)
> > + if not options.auto:
> > + cmd.append("--suppress-cc=body")
>
> Like this?
>
> for x in ['to', 'cc', 'bcc']:
> if getattr(options, x):
> cmd.extend('--%s=%s' % (x, a) for a in getattr(options, x))
Yeah, that looks nice. Re-implemented with your suggestion.
> > + (fd, path) = mkstemp()
> > + os.write(fd, msg.as_string(options.mbox))
> > + os.close(fd)
> > +
> > + try:
> > + cmd.append(path)
> > + call(cmd)
> > + except Exception, err:
> > + os.unlink(path)
> > + raise CmdException, str(err)
> > +
> > + os.unlink(path)
>
> To avoid having to remember to call unlink in all paths, you can write
>
> try:
> try:
> cmd.append(path)
> call(cmd)
> except Exception, e:
> raise CmdException(str(e))
> finally:
> os.unlink(path)
>
> (The combined try...except...finally statement didn't appear until
> python 2.5, but we'd like to stay compatible with 2.4.)
This statement confuses me a bit. The way I read it, I shouldn't
use your suggestion due to compat reasons?
Thanks,
/ac
^ permalink raw reply
* Re: [StGit RFC PATCH 0/6] add support for git send-email
From: Alex Chiang @ 2009-12-01 0:02 UTC (permalink / raw)
To: Karl Wiberg; +Cc: catalin.marinas, git
In-Reply-To: <b8197bcb0911291405i6f052216q8717c34063320592@mail.gmail.com>
* Karl Wiberg <kha@treskal.com>:
> On Sat, Nov 28, 2009 at 8:50 PM, Alex Chiang <achiang@hp.com> wrote:
>
> > stg mail still has some nice features over git send-email, such
> > as the -v command line parameter and --prefix. Maybe at some point
> > in the future, we can migrate those features into git send-email and
> > continue thinning out stg mail.
>
> Yes. But note that we tend to be conservative and not require a
> too-new git, so a patch adding such a dependency would have to wait a
> while. (I'm currently carrying two such patches in my experimental
> branch.)
Understood. For now, of course, all the changes that I'm
proposing should work with bog-standard, oldish git, since I
don't think the git send-email interface has changed in a while.
> > But I wanted to get some feedback first to make sure I'm going in the
> > right direction before going too much further.
>
> I've read the patches, and it looks about right from where I stand.
Thank you very much for the review.
> Did you remember to run the regression tests? It's very helpful when
> reviewing to know that the regression suite passes at every point in
> the series.
Good idea. I've been running t/t1900-mail.sh at each stage since
my changes seem rather localized to sending mail.
Should I be running the entire suite?
/ac
^ permalink raw reply
* Re: help reverting a merge
From: Justin P. Mattock @ 2009-12-01 0:06 UTC (permalink / raw)
To: Jeff King; +Cc: Christian Couder, git
In-Reply-To: <20091130081315.GA587@coredump.intra.peff.net>
First things first is I owe you a great thanks
for teaching me how to do a rebase.. :-)
took a while, and still a bit confusing
but I managed to do exactly what you
had written down.
bad thing is somehow the bisect came up
with no results. probably will do another bisect,
just to make sure things are in the right
direction, and the try the rebase again.
Again Thanks for the help/info on this.
Justin P. Mattock
^ permalink raw reply
* Re: equal-tree-merges as way to make rebases fast-forward-able
From: Junio C Hamano @ 2009-12-01 0:20 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, Bernhard R. Link, git
In-Reply-To: <20091201071234.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> I think you can record a merge commit that has an unusual
> list of parents for this. For example, you can record the
> latest version twice, as the first and the second parents,
> and make the previous version the third parent. Because
> such a merge can't be created with git-merge command, you
> can reliably tell that it is an unusual 'marker' merge.
That's too ugly a hack, and hints an undesirable attitude that this will
be the last feature that needs such cleverness, without leaving the door
open for others who need similar "magic marker" capability added to commit
objects. The approach will not scale, unless you consider "first and
second parents being the same means it is 'rebased branches magic', and
first, second and third parents being the same means some other matic,
etc." as scalable.
As I said, if the approach this series takes turns out to be useful, it is
Ok to implement it as a new header in the commit object if necessary.
We try very hard to avoid adding random headers to commits because a
commit that records the same history should be named the same way in the
object store namespace and adding random headers will make it easier to
create the same commit with different names, but what we are discussing
is a special purpose pseudo commit and it _is_ a feature that the object
name of a commit, after SHA-1 hashing, is different with and without the
special header in this case.
> No matter what techinique is used to mark the special
> 'marker', if it happens in real life for two or more people
> who worked independantly to arrive at the same conclusion,
> I don't think dismissing it as 'by chance' and discarding
> the contribution from the second branch is a good solution.
> If git is meant to work smoothly in projects where more than
> one person see and accept patches from the same origin, the
> condition is not met 'by chance'; the tool is by design
> supposed to handle it as a regular situation.
I said the same thing, and I agree that two (or more) people creating the
same state should be treated as a normal event. But I am not so sure
about a merge that binds two such histories together. The person who
makes such a merge can go on without making one as far as tree-state is
concerned (i.e. such a merge will result in the same tree with both
parents), and the _only_ reason a merge between the two branches is
created is to cauterize one (or both) of the branches, declare that
everything that happened in the branch is now part of this branch.
In other words, such a merge is an operation to purely affect the history
and not contents.
As J6t pointed out, when we tell the revision walking machinery to limit
by path, we already simplify the history we show to the user, and if path
happens to name the whole tree, such a history is already simplified to
show only one side of the story. So perhaps it is not as grave an offence
to ignore contribution from one side when both of the parents of a merge
record the same tree as I originally thought. It also justifies not
introducing a new header in commits. The implementation of Bernhard's
series might become simpler if it used the trick to use "." pathspec
internally instead of introducing a new traversal option to the revision
machinery.
> On the other hand, if you made the marker reliable, I think
> you don't have to disable this feature by default like you
> said in your (2).
That is true, but as you may be able to tell, I am undecided if the marker
should be _that_ explicit, or should be implicit and the fact that a merge
that whose all parents have the same tree should make it automatically a
marker (iow, I earlier said "misidentify" but now I am wondering if it
makes sense to define any merge with the property an "alternative history
binding marker", no matter how it was created).
> As a side note, I have a bug to report. I tried this sequence
> of commands to make sure git-merge doesn't record the same
> parent twice (the last git-merge is made on the slave branch
> and tries to have slave, master and slave as its three
> parents).
>
> % git init
> % echo hello >world
> % git add . ; git commit -m first
> % echo again >world
> % git commit -a -m master
> % git checkout -b slave master^
> % echo again >world
> % git commit -a -m slave
> % git merge master slave
>
> But I got the "usage: ..." error message from git-merge.
Well, you did not quote the usage string you got, but it should have began
like this:
usage: git merge [options] <remote>...
or: git merge [options] <msg> HEAD <remote>
The parser misinterpreted your request as the latter form (which is
ancient and probably predates your involvement with the git project),
noticed that you did not give any <remote> commit, and then gave the
usage message.
I think we really should start deprecating the ancient form, but the
original sample script using this syntax from Linus was copied by many
people and are still found everywhere, I think, and people may still
use their scripts that were written with the ancient syntax.
In any case, at least this patch will make it start behaving a bit
more sanely.
-- >8 --
Subject: Do not misidentify "git merge foo HEAD" as an old-style invocation
This was misinterpreted as an ancient style "git merge <message> HEAD
<commit> <commit>..." that merges one (or more) <commit> into the current
branch and record the resulting commit with the given message. Then a
later sanity check found that there is no <commit> specified and gave
a usage message.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
diff --git a/builtin-merge.c b/builtin-merge.c
index e95c5dc..e5cf795 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -792,7 +792,7 @@ static int suggest_conflicts(void)
static struct commit *is_old_style_invocation(int argc, const char **argv)
{
struct commit *second_token = NULL;
- if (argc > 1) {
+ if (argc > 2) {
unsigned char second_sha1[20];
if (get_sha1(argv[1], second_sha1))
^ permalink raw reply related
* Re: [PATCH] get_ref_states: strdup entries and free util in stale list
From: Junio C Hamano @ 2009-12-01 0:21 UTC (permalink / raw)
To: Bert Wesarg; +Cc: Junio C Hamano, Johannes Schindelin, Jay Soffian, git
In-Reply-To: <0458f16c6ce906997aaf357c0c7368841ae83c36.1259625072.git.bert.wesarg@googlemail.com>
Bert Wesarg <bert.wesarg@googlemail.com> writes:
> Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
Hmm, the Subject: matches what the code does, but nobody mentions why it
is necessary (iow, what breaks in the current code and what becomes better
if the patch is applied). The blank space before your "S-o-b:" line is
for you to describe these things.
> ---
> builtin-remote.c | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/builtin-remote.c b/builtin-remote.c
> index 7916626..bb72e27 100644
> --- a/builtin-remote.c
> +++ b/builtin-remote.c
> @@ -272,7 +272,9 @@ static int get_ref_states(const struct ref *remote_refs, struct ref_states *stat
> die("Could not get fetch map for refspec %s",
> states->remote->fetch_refspec[i]);
>
> - states->new.strdup_strings = states->tracked.strdup_strings = 1;
> + states->new.strdup_strings =
> + states->tracked.strdup_strings =
> + states->stale.strdup_strings = 1;
> for (ref = fetch_map; ref; ref = ref->next) {
> unsigned char sha1[20];
> if (!ref->peer_ref || read_ref(ref->peer_ref->name, sha1))
> @@ -768,7 +770,7 @@ static void clear_push_info(void *util, const char *string)
> static void free_remote_ref_states(struct ref_states *states)
> {
> string_list_clear(&states->new, 0);
> - string_list_clear(&states->stale, 0);
> + string_list_clear(&states->stale, 1);
> string_list_clear(&states->tracked, 0);
> string_list_clear(&states->heads, 0);
> string_list_clear_func(&states->push, clear_push_info);
> --
> 1.6.6.rc0.253.g1ec3
^ permalink raw reply
* [PATCH] git-merge: a deprecation notice of the ancient command line syntax
From: Junio C Hamano @ 2009-12-01 0:23 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Bernhard R. Link, git
In-Reply-To: <7vmy23bl4o.fsf@alter.siamese.dyndns.org>
The ancient form of git merge command used in the original sample script
has been copied from Linus and are still found everywhere, I think, and
people may still have it in their scripts, but on the other hand, it is so
unintuitive that even people reasonably familiar with git is surprised by
accidentally triggering the support to parse this ancient form.
Gently nudge people to upgrade their script to more recent and readable
style for eventual removal of the original syntax.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
And this is the first step of such a deprecation. Perhaps we start
warning in 1.7.0 and remove it in 1.8.0, or something like that.
builtin-merge.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/builtin-merge.c b/builtin-merge.c
index e5cf795..4cb695e 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -789,6 +789,11 @@ static int suggest_conflicts(void)
return 1;
}
+static const char deprecation_warning[] =
+ "'git merge <msg> HEAD <commit>' is deprecated. Please update\n"
+ "your script to use 'git merge -m <msg> <commit>' instead.\n"
+ "In future versions of git, this syntax will be removed.";
+
static struct commit *is_old_style_invocation(int argc, const char **argv)
{
struct commit *second_token = NULL;
@@ -802,6 +806,7 @@ static struct commit *is_old_style_invocation(int argc, const char **argv)
die("'%s' is not a commit", argv[1]);
if (hashcmp(second_token->object.sha1, head))
return NULL;
+ warning(deprecation_warning);
}
return second_token;
}
^ permalink raw reply related
* Re: "git merge" merges too much!
From: Greg A. Woods @ 2009-12-01 0:24 UTC (permalink / raw)
To: The Git Mailing List; +Cc: Dmitry Potapov
In-Reply-To: <20091130211744.GA27278@dpotapov.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2349 bytes --]
At Tue, 1 Dec 2009 00:17:44 +0300, Dmitry Potapov <dpotapov@gmail.com> wrote:
Subject: Re: "git merge" merges too much!
>
> It depends on the project and what tools are used, but using ccache and
> proper dependencies help a lot to reduce the cost of switching. In fact,
> it may be faster to switch to another branch and have to recompile a few
> files than to go into another working directory, because when you go to
> another working directory, you hit cold cache and things get very slow.
perhaps, sometimes, but at least with some tools that can more often
than not just end up with a confusing mess if you happen to change
something at exactly the wrong time, and with Git it seems almost too
easy to wildly change many files in the working directory, even if you
can get them back into their previous state relatively quickly
Things get even weirder if you happen to be playing with older branches
too -- most build tools don't have ability to follow files that go back
in time as they assume any product files newer than the sources are
already up-to-date, no matter how much older the sources might become on
a second build.
From a good software hygiene perspective the only safe way I can see to
build a Git working directory after manipulating any branches with Git
is to do a complete "make clean && make" cycle. That is until Git also
incorporates, or integrates with, really good build tools.... :-)
> And then if a project is huge and takes a lot of time to compile and
> test everything, I do not think, it is a good idea to build that in your
> work tree. Instead, you make a shanshot using git-archive and then run
> full build and test on it. In this way, you know that you test exactly
> what you have committed (you can amend any commit later until you
> publish it).
I think this "git-new-workdir" script is the thing to try. It probably
means keeping separate "configuration" branches, one for each build
working directory, but I think that's OK.
These source trees are big enough that one doesn't just go throwing
around entire copies of them willy-nilly. Disk bandwidth is also a
limited resource we are very concerned about, not just disk space.
--
Greg A. Woods
Planix, Inc.
<woods@planix.com> +1 416 218 0099 http://www.planix.com/
[-- Attachment #2: Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: equal-tree-merges as way to make rebases fast-forward-able
From: Junio C Hamano @ 2009-12-01 0:25 UTC (permalink / raw)
To: Bernhard R. Link; +Cc: git
In-Reply-To: <20091130185540.GA5764@pcpool00.mathematik.uni-freiburg.de>
"Bernhard R. Link" <brlink@debian.org> writes:
>> 3-------.
>> / \
>> 0---2---W---B
>> \ /
>> 1-------Z
>>
>> That is, Z and W records the interdifff between 1 to 3 and 2 to 3
>> respectively, and B is a same-tree merge of 3, W and Z.
>
> I think changing it to get this would be easy (though only in the case
> where the very last commit was such an equal tree merge), but I do not
> think it would be actually better:
>
> - it is no longer possible to see the history of changes by just walking
> right on every equal-tree-merge.
> - commit a no longer exists. If some downstream already has
> cloned/pulled, no fast-forward is possible any more.
Oh, I wasn't suggesting you to change it to use an octopus. I however did
want to know if you considered pros-and-cons with such an alternative
(there perhaps are other approaches as well), and I agree recording one
iteration at a time like you do is better.
^ permalink raw reply
* [PATCH] builtin-commit: add --date option
From: Miklos Vajna @ 2009-12-01 0:27 UTC (permalink / raw)
To: git
This is useful in case git commit --amend is used but the user wants to
set the date of the new commit to a specified one, since GIT_AUTHOR_DATE
is ignored in such a situation.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
Documentation/git-commit.txt | 6 +++++-
builtin-commit.c | 6 +++++-
t/t7501-commit.sh | 15 +++++++++++++++
3 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 3ea80c8..3b9a7c3 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -11,7 +11,7 @@ SYNOPSIS
'git commit' [-a | --interactive] [-s] [-v] [-u<mode>] [--amend] [--dry-run]
[(-c | -C) <commit>] [-F <file> | -m <msg>]
[--allow-empty] [--no-verify] [-e] [--author=<author>]
- [--cleanup=<mode>] [--] [[-i | -o ]<file>...]
+ [--date=<date>] [--cleanup=<mode>] [--] [[-i | -o ]<file>...]
DESCRIPTION
-----------
@@ -80,6 +80,10 @@ OPTIONS
an existing commit that matches the given string and its author
name is used.
+--date=<date>::
+ Override the date used in the commit. The format is the Git
+ native one and is `<time> SP <offutc>`.
+
-m <msg>::
--message=<msg>::
Use the given <msg> as the commit message.
diff --git a/builtin-commit.c b/builtin-commit.c
index 09d2840..594328e 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -52,7 +52,7 @@ static char *edit_message, *use_message;
static char *author_name, *author_email, *author_date;
static int all, edit_flag, also, interactive, only, amend, signoff;
static int quiet, verbose, no_verify, allow_empty, dry_run;
-static char *untracked_files_arg;
+static char *untracked_files_arg, *force_date;
/*
* The default commit message cleanup mode will remove the lines
* beginning with # (shell comments) and leading and trailing
@@ -90,6 +90,7 @@ static struct option builtin_commit_options[] = {
OPT_FILENAME('F', "file", &logfile, "read log from file"),
OPT_STRING(0, "author", &force_author, "AUTHOR", "override author for commit"),
+ OPT_STRING(0, "date", &force_date, "DATE", "override date for commit"),
OPT_CALLBACK('m', "message", &message, "MESSAGE", "specify commit message", opt_parse_m),
OPT_STRING('c', "reedit-message", &edit_message, "COMMIT", "reuse and edit message from specified commit "),
OPT_STRING('C', "reuse-message", &use_message, "COMMIT", "reuse message from specified commit"),
@@ -409,6 +410,9 @@ static void determine_author_info(void)
email = xstrndup(lb + 2, rb - (lb + 2));
}
+ if (force_date)
+ date = force_date;
+
author_name = name;
author_email = email;
author_date = date;
diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
index a603f6d..a529701 100755
--- a/t/t7501-commit.sh
+++ b/t/t7501-commit.sh
@@ -211,6 +211,21 @@ test_expect_success 'amend commit to fix author' '
'
+test_expect_success 'amend commit to fix date' '
+
+ test_tick &&
+ newtick=$GIT_AUTHOR_DATE &&
+ git reset --hard &&
+ git cat-file -p HEAD |
+ sed -e "s/author.*/author $author $newtick/" \
+ -e "s/^\(committer.*> \).*$/\1$GIT_COMMITTER_DATE/" > \
+ expected &&
+ git commit --amend --date="$newtick" &&
+ git cat-file -p HEAD > current &&
+ test_cmp expected current
+
+'
+
test_expect_success 'sign off (1)' '
echo 1 >positive &&
--
1.6.5.2
^ permalink raw reply related
* Re: Git open calls fail on NFS-mounted NTFS volume
From: Junio C Hamano @ 2009-12-01 0:38 UTC (permalink / raw)
To: Kai Lanz; +Cc: git
In-Reply-To: <F7CE7D3D-9237-494C-B6C8-6B6D7AB7CE45@stanford.edu>
Kai Lanz <lanz@stanford.edu> writes:
> There are several places in the code where git calls open() with the
> flag
> O_EXCL. This causes a problem for us when the current directory is on an
> NFS-mounted NTFS volume shared by an NAS fileserver.
> ...
> Git version is 1.6.5.3, running on x86_64 RHEL-4, kernel 2.6.9-89.
I do not use nor have access to RHEL, but does this ring a bell?
https://bugzilla.redhat.com/show_bug.cgi?id=524520
^ permalink raw reply
* Re: [RFC/PATCH] gitweb: Make linking to actions requiring JavaScript a feature
From: Junio C Hamano @ 2009-12-01 1:18 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Stephen Boyd, git, Martin Koegler
In-Reply-To: <7veinjn7nc.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I had to step back a bit and ask myself what we are trying to achieve
> here. When the current blame and incremental one are both working
> perfectly and well, will there be a reason for the end users to choose
> between them when they click?
>
> My answer is no. If the incremental one gives nicer user experience in
> all cases, it will be shown without the non-incremental one; if the
> incremental one makes the server or network load too heavy, a site owner
> may decide to show only the non-incremental one.
>
> That makes my addLinks suggestion a change that would help _only_ while we
> are working kinks out of the incremental one.
>
> Let's not waste too much effort doing that. Sorry for suggesting.
>
> Letting the site owner choose if the site wants to set the "incremental if
> possible" boolean would be more than adequate, I think.
Sorry, but I guess I dropped the ball after this message. If I understand
correctly, the conclusion is that I can apply the patch in this one
From: Jakub Narebski <jnareb@gmail.com>
Subject: [RFC/PATCH] gitweb: Make linking to actions requiring JavaScript a feature
Date: Thu, 26 Nov 2009 21:12:15 +0100
Message-ID: <200911262112.16280.jnareb@gmail.com>
and shipping 1.6.6 with it (perhaps setting 'default' to '[0]' instead)
would be both reasonably safe and allows easy experimentation by willing
site owners (or individual gitweb deployment), right?
Please advice if I am mistaken.
Thanks.
^ permalink raw reply
* Re: [PATCH] git-merge: a deprecation notice of the ancient command line syntax
From: Nicolas Pitre @ 2009-12-01 3:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, Bernhard R. Link, git
In-Reply-To: <7vaay3bkyx.fsf_-_@alter.siamese.dyndns.org>
On Mon, 30 Nov 2009, Junio C Hamano wrote:
> The ancient form of git merge command used in the original sample script
> has been copied from Linus and are still found everywhere, I think, and
> people may still have it in their scripts, but on the other hand, it is so
> unintuitive that even people reasonably familiar with git is surprised by
> accidentally triggering the support to parse this ancient form.
>
> Gently nudge people to upgrade their script to more recent and readable
> style for eventual removal of the original syntax.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>
> And this is the first step of such a deprecation. Perhaps we start
> warning in 1.7.0 and remove it in 1.8.0, or something like that.
If this is going to be removed in the future, then it is already
deprecated. Therefore it is much better to start warning now and not
wait for 1.7.0. There is just no point delaying the advice.
Nicolas
^ permalink raw reply
* Re: [PATCH] git-merge: a deprecation notice of the ancient command line syntax
From: Junio C Hamano @ 2009-12-01 4:07 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Nanako Shiraishi, Bernhard R. Link, git
In-Reply-To: <alpine.LFD.2.00.0911302251270.5820@xanadu.home>
Nicolas Pitre <nico@fluxnic.net> writes:
> On Mon, 30 Nov 2009, Junio C Hamano wrote:
>
>> The ancient form of git merge command used in the original sample script
>> has been copied from Linus and are still found everywhere, I think, and
>> people may still have it in their scripts, but on the other hand, it is so
>> unintuitive that even people reasonably familiar with git is surprised by
>> accidentally triggering the support to parse this ancient form.
>>
>> Gently nudge people to upgrade their script to more recent and readable
>> style for eventual removal of the original syntax.
>>
>> Signed-off-by: Junio C Hamano <gitster@pobox.com>
>> ---
>>
>> And this is the first step of such a deprecation. Perhaps we start
>> warning in 1.7.0 and remove it in 1.8.0, or something like that.
>
> If this is going to be removed in the future, then it is already
> deprecated. Therefore it is much better to start warning now and not
> wait for 1.7.0. There is just no point delaying the advice.
Very true.
What I am not absolutely sure about is if the presense of the support for
ancient usage hurts people in real life so much that it is better to
remove it than keep it. At least we saw one example of a user (who is not
a novice) getting puzzled by it, but that may not be enough datapoint to
decide with.
^ permalink raw reply
* Re: Unable to checkout a particular SVN revision
From: Marc Liyanage @ 2009-12-01 4:59 UTC (permalink / raw)
To: git; +Cc: Daniele Segato
In-Reply-To: <1259513411.32532.22.camel@localhost>
On 29.11.2009, at 08:50, Daniele Segato wrote:
> You had to understand the difference between a distributed version
> control system (git) and a centralized version control system (svn).
I understand that, I use (pure) git for all my personal projects, and it works great.
And even as a front end for SVN, I am *very* happy with what I got from git-svn so far, I think it is an excellent tool, even better than the actual SVN client. I track an SVN repository in my local git master branch, then branch off locally for development, send patches for review, reorder/consolidate/squash commits back onto my master branch and then dcommit that back to SVN. All that is great.
I would like to understand why
git svn clone -r n <url>
does not work as expected while
git svn clone -r m <url>
does work perfectly fine, if that m revision number happens to have been committed on the particular SVN branch I cloned (you left off that -r in your git svn clone examples). As it is, I have to hunt for the next lower or higher revision number that happens to be on that branch.
I might be doing a poor job explaining what my question is... Basically, what prevents that operation from doing the same thing that SVN does? Lack of information, i.e. should I just clone higher up in the tree?
______________________________
Marc Liyanage
www.entropy.ch
skype mliyanage
iChat liyanage@mac.com
^ permalink raw reply
* Re: "git merge" merges too much!
From: Dmitry Potapov @ 2009-12-01 5:47 UTC (permalink / raw)
To: The Git Mailing List
In-Reply-To: <m1NFGXS-000kn2C@most.weird.com>
On Mon, Nov 30, 2009 at 07:24:14PM -0500, Greg A. Woods wrote:
>
> Things get even weirder if you happen to be playing with older branches
> too -- most build tools don't have ability to follow files that go back
> in time as they assume any product files newer than the sources are
> already up-to-date, no matter how much older the sources might become on
> a second build.
No, files do not go back in time when you switch between branches. The
timestamp on files is the time when they are written to your working
tree (and it is so with other VCSes that I worked with, so I do not
know where you get idea of file timestamps going back in time). Thus any
building tool such as 'make' should work fine provided you have correct
dependencies. I have switched between widely diversed branches, and I
have never had any problem with that.
Dmitry
^ permalink raw reply
* Re: [PATCH] get_ref_states: strdup entries and free util in stale list
From: Bert Wesarg @ 2009-12-01 6:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Jay Soffian, git
In-Reply-To: <7viqcrbl22.fsf@alter.siamese.dyndns.org>
On Tue, Dec 1, 2009 at 01:21, Junio C Hamano <gitster@pobox.com> wrote:
> Bert Wesarg <bert.wesarg@googlemail.com> writes:
>
The entries of the stale branches string list are made of the stale
refs, which are immediately free'ed after the string list creation.
Therefore the list entries use memory after free. This resulted for me
in a corrupted branch list for 'git remote show' (duplicate entries
and cut-off entries). The .util member of the string list entries are
also strdup() of the branch (full)name itself, but at clear time we
request not to free the .util member. Which results in a memory leak.
>> Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
>
> Hmm, the Subject: matches what the code does, but nobody mentions why it
> is necessary (iow, what breaks in the current code and what becomes better
> if the patch is applied). The blank space before your "S-o-b:" line is
> for you to describe these things.
Sure. unfortunately the code where the string list is filled is not in
the patch. But if you look at the code it should be self-explanatory.
>
>> ---
There is actually also an other solution: we could first strdup the
ref name to the .util member and take this as the input for the
abbrev_ref()/string list entry and safe there the strdup.
Bert
>> builtin-remote.c | 6 ++++--
>> 1 files changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/builtin-remote.c b/builtin-remote.c
>> index 7916626..bb72e27 100644
>> --- a/builtin-remote.c
>> +++ b/builtin-remote.c
>> @@ -272,7 +272,9 @@ static int get_ref_states(const struct ref *remote_refs, struct ref_states *stat
>> die("Could not get fetch map for refspec %s",
>> states->remote->fetch_refspec[i]);
>>
>> - states->new.strdup_strings = states->tracked.strdup_strings = 1;
>> + states->new.strdup_strings =
>> + states->tracked.strdup_strings =
>> + states->stale.strdup_strings = 1;
>> for (ref = fetch_map; ref; ref = ref->next) {
>> unsigned char sha1[20];
>> if (!ref->peer_ref || read_ref(ref->peer_ref->name, sha1))
>> @@ -768,7 +770,7 @@ static void clear_push_info(void *util, const char *string)
>> static void free_remote_ref_states(struct ref_states *states)
>> {
>> string_list_clear(&states->new, 0);
>> - string_list_clear(&states->stale, 0);
>> + string_list_clear(&states->stale, 1);
>> string_list_clear(&states->tracked, 0);
>> string_list_clear(&states->heads, 0);
>> string_list_clear_func(&states->push, clear_push_info);
>> --
>> 1.6.6.rc0.253.g1ec3
>
^ permalink raw reply
* Umlaut in filename makes troubles
From: rick23 @ 2009-12-01 7:15 UTC (permalink / raw)
To: git
I have problems with my repository under slackware vs. windows. I
created a repo in linux and every time I use it under msysgit, the
files containing umlauts in the filename are marked as deleted (and
vice versa).
For instance: the repo perfectly synced under msysgit leads to:
user@sauron:/media/disk-2$ git status |grep Auszug
# deleted: "trunk/007_Literatur/Auszug aus Ergonomische
Untersuchung des Lenkgef\374hles.docx"
# "trunk/007_Literatur/Auszug aus Ergonomische Untersuchung des
Lenkgef\303\274hles.docx"
in linux. But the file exists and is displayed correctly in the shell
or in dolphin (my filemanager under X):
user@sauron:/media/disk-2$ ls trunk/007_Literatur/Auszug*
trunk/007_Literatur/Auszug aus Ergonomische Untersuchung des
Lenkgefühles.docx
Can you please give me a hint what to do?
TIA
^ permalink raw reply
* Re: [PATCH 3/6] stg mail: make __send_message do more
From: Karl Wiberg @ 2009-12-01 7:26 UTC (permalink / raw)
To: Alex Chiang; +Cc: catalin.marinas, git
In-Reply-To: <20091130235935.GK12733@ldl.fc.hp.com>
On Tue, Dec 1, 2009 at 12:59 AM, Alex Chiang <achiang@hp.com> wrote:
> * Karl Wiberg <kha@treskal.com>:
>
> > You could consolidate the two dictionaries like this, to avoid
> > making the same choice twice and make the code more pleasant to
> > read:
> >
> > (build, outstr) = { 1: (__build_cover, 'the cover message'), 4: (__build_message, 'patch "%s"' % args[0]) }
>
> Hm, I don't think that's valid. I ended up doing something like
> this:
>
> d = { 'cover': (__build_cover, 'the cover message'), 'patch': (__build_message, 'patch "%s"' % args[0]) }
> (build, outstr) = d[type]
Duh. That's what I get for posting untested code. It should be
(build, outstr) = { 1: (__build_cover, 'the cover message'), 4:
(__build_message, 'patch "%s"' % args[0]) }[len(args)]
That is, we create a dictionary only to immediately use it once,
without ever explicitly storing a reference to it.
--
Karl Wiberg, kha@treskal.com
subrabbit.wordpress.com
www.treskal.com/kalle
^ 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