On 07/19/2012 08:56 AM, Matthieu Moy wrote:
Stefano Lattarini stefano.lattar...@gmail.com writes:
for example, an autotools old-timer that has run:
./configure --prefix /opt/git
in the past, without running make distclean afterwards, would
expect a make install issued after a make
On 07/19/2012 02:13 AM, Junio C Hamano wrote:
Stefano Lattarini stefano.lattar...@gmail.com writes:
The new name fits better with the macro signature, and underlines the
similarities with the autoconf-provided macro AC_SUBST (which will be
made even more pronounced in planned future
Stefano Lattarini stefano.lattar...@gmail.com writes:
Should I add Acked-by: Matthieu Moy then? (Sorry if it's a dumb
question, but I'm not sure which the preferred policy is around here).
Not necessarily needed if the patch is not otherwise controversial. The
email discussions are usually
Except for miniscule nits in the the bottom two, I didn't find
anything objectionable---nicely done.
Thanks.
Here is the re-roll, which should address all the reported nits.
Stefano Lattarini (7):
autoconf: GIT_CONF_APPEND_LINE: change signature
autoconf: GIT_CONF_APPEND_LINE -
From:
GIT_CONF_APPEND_LINE([VAR=VAL])
to:
GIT_CONF_APPEND_LINE([VAR], [VAL])
This is only a preparatory change in view of future refactorings.
No semantic change is intended. In fact, the generated configure
file doesn't change at all.
Signed-off-by: Stefano Lattarini
The new name fits better with the macro signature, and underlines the
similarities with the autoconf-provided macro AC_SUBST (which will be
made even more pronounced in planned future commits).
Once again, no semantic change is intended, and indeed no change to the
generated configure script is
They are merely useless now, but would get in the way of future changes.
No semantic change is intended.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
configure.ac | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/configure.ac b/configure.ac
This will allow ./config.status --recheck; ./config.status to work
correctly as a mean of reconfiguring the tree with the same configure
argument used in the previous ./configure invocation.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
configure.ac | 28
This provides a reduced but still useful sibling of the Automake's
automatic Makefile rebuild feature. It's important to note that
we take care to enable the new rules only if the tree that has already
be configured with './configure', so that users relying on manual
configuration won't be
Those filed hold variables, settings and information set by the
configuration process run by './configure'; in Autotools-based
build system that kind of stuff should only be removed by
make distclean. Having it removed by make clean is not only
inconsistent, but causes real confusion for that
They are merely useless now, but would get in the way of future changes.
No semantic change is intended.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
configure.ac | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index
Marcin Owsiany mar...@owsiany.pl wrote:
On Wed, Jul 18, 2012 at 11:27:22AM +, Eric Wong wrote:
Marcin Owsiany mar...@owsiany.pl wrote:
Turns out that command_noisy()
- has a meaningless return value
- throws an exception on command failure
so the || bit does not work.
Also,
From: Tim Henigan tim.heni...@gmail.com
When 'difftool --dir-diff' is used to compare working tree files,
it always copies files from the tmp dir back to the working tree
when the diff tool is closed, even if the files were not modified
by the diff tool.
This causes the file timestamp to change.
---
MDaemon has detected restricted attachments within an email message
---
From : git@vger.kernel.org
To: sandyngu...@asmara-vietnam.com
Subject :
On Wed, Jul 18, 2012 at 03:39:34PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
So leaving aside the --graph issues, we would need to decide what to
show in the non-graph case. And I think your suggestion is good; there
is no real need to dereference the blob (if you want
On Wed, Jul 18, 2012 at 03:47:21PM -0700, Junio C Hamano wrote:
I don't care too deeply either way, and it is technically a behavior
change. So there is a chance of regression for something that nobody has
actually complained about.
Thanks. I share the same feeling, but the code after
On Thu, Jul 19, 2012 at 09:30:59AM +0200, Alexey Muranov wrote:
i would like
`git fetch --prune remote`
to be the default behavior of
`git fetch remote`
In fact, i think this is the only reasonable behavior.
Keeping copies of deleted remote branches after `fetch` is more confusing
I've the problem described here:
http://code.google.com/p/git-core/issues/detail?id=16
Kind Regards,
Rafal
Sent from my iPhone
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On Thu, Jul 19, 2012 at 7:55 AM, Jeff King p...@peff.net wrote:
On Thu, Jul 19, 2012 at 09:30:59AM +0200, Alexey Muranov wrote:
i would like
`git fetch --prune remote`
to be the default behavior of
`git fetch remote`
In fact, i think this is the only reasonable behavior.
Keeping copies
Dan Johnson computerdr...@gmail.com wrote:
In the meantime, would it make sense to introduce a configuration
variable to request this behavior?
fetch.prune = always
Of course, this might be just a waste of time to introduce a feature
no one would use, in which case we obviously should
Dear sir
We supply solar PV system (including solar panels , frame,
cable ,inverter and controller , power distribution cabinet) with
1.6$/w FOB shenzhen.
Email me or just call me directly if needed. Thank you!
Best wishes
lala
Ecosol PV Tech
On 19 Jul 2012, at 13:55, Jeff King wrote:
On Thu, Jul 19, 2012 at 09:30:59AM +0200, Alexey Muranov wrote:
i would like
`git fetch --prune remote`
to be the default behavior of
`git fetch remote`
In fact, i think this is the only reasonable behavior.
Keeping copies of deleted
On 19 Jul 2012, at 13:55, Jeff King wrote:
I agree it would be much less confusing. However, one downside is that
we do not keep reflogs on deleted branches (and nor did the commits in
remote branches necessarily make it into the HEAD reflog). That makes
git fetch a potentially destructive
On Thu, Jul 19, 2012 at 12:40 PM, Alexey Muranov
alexey.mura...@gmail.com wrote:
On 19 Jul 2012, at 13:55, Jeff King wrote:
I agree it would be much less confusing. However, one downside is that
we do not keep reflogs on deleted branches (and nor did the commits in
remote branches necessarily
On 19 Jul 2012, at 18:48, Dan Johnson wrote:
From the git-gc man page:
git gc tries very hard to be safe about the garbage it collects. In
particular, it will keep not only objects referenced by your current
set of branches and tags, but also objects referenced by the index,
remote-tracking
Jeff King p...@peff.net writes:
Unlike elements of the commit object itself, like --parents or
--timestamp, notes do not really gain any efficiency by being printed as
part of the traversal. So modulo the cost of piping the list of commits,
it would not really be any more efficient than git
Eric Wong normalper...@yhbt.net writes:
Probably, I'm not sure if it'd break existing uses. Anyways, that's a
separate issue we can deal with another day.
I've added my Signed-off-by: to your latest patch and pushed
to master of git://bogomips.org/git-svn.git
(commit
Stefano Lattarini stefano.lattar...@gmail.com writes:
On 07/19/2012 02:29 AM, Junio C Hamano wrote:
The inconsistency between the existing one that does not quote the
string that is not substituted, i.e.
GIT_UC_PROGRAM[]_PATH=$withval
and the new one that quotes _PATH, i.e.
Stefano Lattarini stefano.lattar...@gmail.com writes:
On 07/19/2012 08:56 AM, Matthieu Moy wrote:
Stefano Lattarini stefano.lattar...@gmail.com writes:
for example, an autotools old-timer that has run:
./configure --prefix /opt/git
in the past, without running make distclean
On Thu, Jul 19, 2012 at 10:20:18AM -0700, Junio C Hamano wrote:
So for plumbing, I think this is the wrong direction, anyway. The real
value of this patch is that the pretty-printed code path would work more
like git-log (especially the %N format, which lets callers make their
own
David Aguilar dav...@gmail.com writes:
Perhaps something like this...
Yeah, like that ;-).
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 19 Jul 2012 18:21:21 +0200
Alexey Muranov alexey.mura...@gmail.com wrote:
[...]
I do not still understand very well some aspects of Git, like the
exact purpose of remote tracking branches (are they for pull or for
push?), so i may be wrong.
This is wery well explained in the Pro Git
The problem is as follow:
1. git svn fetch
2.
Found possible branch point: https://xxx/svn/xxx/branches/11-07 D t-m
= https://xxx/svn/xxx/branches/11-09 S t-m, 4332
fatal: Not a valid object name refs/remotes/1-11 M R 2.6
cat-file commit refs/remotes/1-11 M R 2.6: command returned error: 128
I'm
On 19 Jul 2012, at 19:34, Konstantin Khomoutov wrote:
On Thu, 19 Jul 2012 18:21:21 +0200
Alexey Muranov alexey.mura...@gmail.com wrote:
[...]
I do not still understand very well some aspects of Git, like the
exact purpose of remote tracking branches (are they for pull or for
push?), so i
On Thu, Jul 19, 2012 at 07:55:58AM -0400, Jeff King wrote:
So I think it would be a lot more palatable if we kept reflogs on
deleted branches. That, in turn, has a few open issues, such as how to
manage namespace conflicts (e.g., the fact that a deleted foo branch
can conflict with a new
The previous commit introduced graveyard reflogs, where the
reflog for a deleted branch foo appears in
logs/graveyard/refs/heads/foo~.
This patch teaches dwim_log to search for these logs if the
ref does not exist, and teaches read_ref_at to fall back to
them when the literal reflog does not
These tests cover the basic functionality of retaining
reflogs for deleted refs.
Signed-off-by: Jeff King p...@peff.net
---
t/t1413-reflog-deletion.sh | 74 ++
1 file changed, 74 insertions(+)
create mode 100755 t/t1413-reflog-deletion.sh
diff --git
I just want to correct my mistake in what i've just sent:
On 19 Jul 2012, at 23:20, Alexey Muranov wrote:
because the owner of the branch can reset or rebase it anytime. I do not
develop on tracking branches. In fact, i am not even using git pull.
I do not develop on tracking branches.
Jeff,
i have no idea about Git source and little idea of how it is working
internally, but reading through your message i wonder: wouldn't it be a good
idea to timestamp the dead reflogs ?
Alexey.
On 19 Jul 2012, at 23:33, Jeff King wrote:
When a ref is deleted, we completely delete its
Jeff King p...@peff.net writes:
Only one test needed to be updated; t7701 tries to create
unreachable objects by deleting branches. Of course that no
longer works, which is the intent of this patch. The test
now works around it by removing the graveyard logs.
I think the work-around
Jeff King p...@peff.net writes:
The previous commit introduced graveyard reflogs, where the
reflog for a deleted branch foo appears in
logs/graveyard/refs/heads/foo~.
This patch teaches dwim_log to search for these logs if the
ref does not exist, and teaches read_ref_at to fall back to
41 matches
Mail list logo
