Jeff King 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
> them w
Jeff King 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 indicates the need
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 ref
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
These tests cover the basic functionality of retaining
reflogs for deleted refs.
Signed-off-by: Jeff King
---
t/t1413-reflog-deletion.sh | 74 ++
1 file changed, 74 insertions(+)
create mode 100755 t/t1413-reflog-deletion.sh
diff --git a/t/t1413-refl
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 e
When a ref is deleted, we completely delete its reflog on
the spot, leaving very little help for the user to reverse
the action. One can sometimes reconstruct the missing
entries based on the HEAD reflog, but not always; the
deleted entries may not have ever been on HEAD (for example,
in the case o
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
On 19 Jul 2012, at 19:34, Konstantin Khomoutov wrote:
> On Thu, 19 Jul 2012 18:21:21 +0200
> Alexey Muranov 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.
On 07/19/2012 07:24 PM, Junio C Hamano wrote:
> Stefano Lattarini 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 t
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 Thu, 19 Jul 2012 18:21:21 +0200
Alexey Muranov 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 book, for instance.
An
David Aguilar 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, 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
> > ow
Stefano Lattarini writes:
> On 07/19/2012 08:56 AM, Matthieu Moy wrote:
>> Stefano Lattarini 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 inst
Stefano Lattarini 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.
>>
>> GIT_CON
Eric Wong 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 e3bd4ddaa9a60fa4e70efdb143b434b440d6
Jeff King 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 rev-list |
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-track
On Thu, Jul 19, 2012 at 12:40 PM, Alexey Muranov
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 make it into the
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 destructi
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 `
>>
>> to be the default behavior of
>>
>> `git fetch `
>>
>> In fact, i think this is the only reasonable behavior.
>> Keeping copies of de
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 Co
Dan Johnson 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 not introduce such
On Thu, Jul 19, 2012 at 7:55 AM, Jeff King wrote:
> On Thu, Jul 19, 2012 at 09:30:59AM +0200, Alexey Muranov wrote:
>
>> i would like
>>
>> `git fetch --prune `
>>
>> to be the default behavior of
>>
>> `git fetch `
>>
>> In fact, i think this is the only reasonable behavior.
>> Keeping copies of
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 http://vger.kernel.org/ma
On Thu, Jul 19, 2012 at 09:30:59AM +0200, Alexey Muranov wrote:
> i would like
>
> `git fetch --prune `
>
> to be the default behavior of
>
> `git fetch `
>
> In fact, i think this is the only reasonable behavior.
> Keeping copies of deleted remote branches after `fetch` is more confusing
> t
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 a
On Wed, Jul 18, 2012 at 03:39:34PM -0700, Junio C Hamano wrote:
> Jeff King 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 that,
---
MDaemon has detected restricted attachments within an email message
---
>From : git@vger.kernel.org
To: sandyngu...@asmara-vietnam.com
Subject : Messag
From: Tim Henigan
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. Files should only be
Marcin Owsiany wrote:
> On Wed, Jul 18, 2012 at 11:27:22AM +, Eric Wong wrote:
> > Marcin Owsiany wrote:
> > > Turns out that command_noisy()
> > > - has a meaningless return value
> > > - throws an exception on command failure
> > > so the "||" bit does not work.
> > > Also, for some reaso
On Thu, Jun 28, 2012 at 12:51 PM, Junio C Hamano wrote:
> Tim Henigan writes:
>
>> 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 d
On 07/19/2012 09:43 AM, Matthieu Moy wrote:
> Stefano Lattarini 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
>
They are merely useless now, but would get in the way of future changes.
No semantic change is intended.
Signed-off-by: Stefano Lattarini
---
configure.ac | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index 200776f..b453ba5 100644
--- a/conf
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 negat
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
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
---
configure.ac | 28 +---
1 file changed,
They are merely useless now, but would get in the way of future changes.
No semantic change is intended.
Signed-off-by: Stefano Lattarini
---
configure.ac | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/configure.ac b/configure.ac
index 02b9a49..200776f 100644
-
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 ex
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
---
configure.ac
> 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 -> GIT_CON
Stefano Lattarini 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 sufficient for that. I'd s
On 07/19/2012 02:13 AM, Junio C Hamano wrote:
> Stefano Lattarini 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 commits).
>>
>> Once again,
Hello,
i would like
`git fetch --prune `
to be the default behavior of
`git fetch `
In fact, i think this is the only reasonable behavior.
Keeping copies of deleted remote branches after `fetch` is more confusing than
useful.
(Excuse me if this question has already been discussed.)
Thank yo
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.
>
> GIT_CONF_SUBST(GIT_UC_PROGRAM[_PATH], [])
>
On 07/19/2012 08:56 AM, Matthieu Moy wrote:
> Stefano Lattarini 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 clean" to re
47 matches
Mail list logo
